RTP57 Maximum Number of variables exceeded... (AREV Specific)
At 16 NOV 2009 04:19:25PM John Jones wrote:
This is an old installation of AREV 3.01. This company has been successfully running the application for 12 years. Workstations run Windows 98, and using Windows 2003 Server for past few years without problems. In past few weeks they are receiving the following error msg: "RTP57 Line 1 (B114), Maximum number of variables exceeded". Pressing a key will restart the application. The company states that there have been no recent changes to their hardware. This is all 2nd hand information but they are asking for my assistance. Can someone explain what may be causing their problem?
At 16 NOV 2009 07:52PM Eric wrote:
Possibly there is less memory in the newer configuration, or else EMS memory is not configured adequately (the WHO window at TCL (F5) will show the report).
Another option is to pepper the application code with additional FLUSH and GARBAGECOLLECT statements in commonly used processes.
At 17 NOV 2009 10:57AM John Jones wrote:
thank you for the advice Eric. I will check with the company on the EMS memory configuration on the workstations.
At 02 DEC 2009 04:23PM Ted Archibald wrote:
Hi
I support a large AREV/OI site and I have seen this message many times.
The cause I have found is that the server is not responding fast enough and the workstation client times out and crashed with max variables message.
Perhaps there is a problem with client's server - load from other apps or the switches/routers have a problem.
At 02 DEC 2009 04:44PM Jared Bratu wrote:
It could also be the client's data files have grown too numerous. There are several problems that can occur if too many files are locked or different tables are opened. I'm not sure how AREV 3.01 would handle such a situation but it could explain why the trouble has started all of a sudden. This post is for Arev 3.12 but it may help diagnose the issue or open other alternatives.
It might also depend on what network drive is in use. RTP57 deals with the linear hash filing system.
Ultimately AREV32 would be the best long term solution. AREV32 maintains the text front end while providing a 100% windows environment. the 32K memory limitations are nonexistent and modern printers are widely supported because the Windows print drivers are available to AREV32.
At 02 DEC 2009 08:12PM Richard Hunt wrote:
I think that there is an issue with "sizelock" and it causing the excessive overflow of the linear hashed file.
I would check each file's sizelock and verify it is not greater than 1.