Arev Resetting (AREV Specific)
At 04 DEC 2001 03:37:45PM Paul Navarro wrote:
I have a process which clears all my Arev screens and returns the user to the main menu for some unknown reason. There is no consistant pattern to where it happens, other than it happens near the end of the process. It is a lengthly process where 5 or 6 windows may be used and dozens of files opened, read and updated. It will flash a message at the bottom of the screen for a fraction of a second. Unfortunately no one has been fast enough to catch this error message. An user did happen to catch part of it today. The message was "ERRMSG2217". Because it happens so fast we are not 100 sure this is the message. This is totally random. It may happen to a user 10 times a day or none at all. It tend to happen on a certain screen. We have been trying to trap where exactly this is happening on the screen but am unable to determine exactly on which prompt it is reseting on. When we use this screen by itself it will never reset.
Is there any contraints on the number of open files or screens that Arev (2.12) can handle.?
At 04 DEC 2001 04:06PM Victor Engel wrote:
My guess is that it's ERRMSG 27.4, judging by the behavior. This would mean your program stack is full. There are 299 entries. Each program and dictionary used uses up an entry until the main program finishes, unless the program is expendable.
Usually this problem is caused by having to many dictionary references.
If this doesn't sound like your problem, do a search on the board using the key term ERRMSG to find other possibilities.
At 04 DEC 2001 10:52PM Paul Navarro wrote:
Thanks Victor.. I will gave it a try.
Does Arev 3.12 have the same limitations?
At 05 DEC 2001 06:24AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Assuming this is memory related, and not due to a GFE (check your indexes)…
You could try using expendable subroutines, nulling out @TCL.STACK in the template initialization, reducing the instance of PDISK calls, looking for symbolics which use {FIELDNAME} instead of the more preferable @RECORD references. Other options include creating a workalike for CALCULATEX which is expendable.
Common variables can also be culprits.
Check for symbolics which reference other symbolics as a first step.
You could also recompile your program objects without linemarks to reduce their size (thus increasing string space for data).
If it only occurs on one workstation consider looking at hardware (eg. cheap mouse drivers and buggy video drivers are possible causes of weird crash-outs).
World leaders in all things RevSoft
At 05 DEC 2001 10:01AM Victor Engel wrote:
Yes.
At 18 DEC 2001 07:33PM Paul Navarro wrote:
Works like a Charm!. Thanks for all the help!