I have a program that intermittently (sp?) crashes out on some machines with a B114 Maximum number of variables exceeded in RTP50.

Usually, closing the ARev session and logging back in will allow the process to run normally.

ARev is running under Win95, and the PIF is set up according to RevTech recommendations. The NLM is being used as well. I have checked memory statistics using WHO at login, and there is ample memory available.

About all I can figure is the memory space is either leaking or becoming corrupt during the process, which, BTW, can take over an hour to complete.

Basically what the process does is read a flat file and then apply updates to records in a table.

My question is, what are the ramifications of executing FLUSH and GARBAGECOLLECT periodically from inside the loop, say every 500 - 1000 records?

Will this completely farble my memory space, will I take a massive performance hit? Just wondering if this is worth doing at all?

TIA,

msorrel@greyhound.com

I first encountered this on a Novell system some 15 years ago. Updating hundreds of records would break the routine until I inserted a flush/garbagecollect every 100 or so lock/unlocks.

The garbagecollect compacts string space, so it is worth periodic use.

The flush closes all open file handles, and is also worthwhile.

Yes there is a performance hit, but it's better to have a reliable process than a crashing fast one.

You might try reducing the DOS file handles and buffers - this can free up memory under 640 kB which may lift the ceiling.

Also, don't use matrices, but use dynamic arrays. Also, I

recall a bug where TRANSFER caused a memory leak, so if you

are using this, remove it and use the standard=variable assignments.

Look to nulling @TCL.STACK periodically, as it can be a hog (and dynamically changes in response to your program)

All the standard memory relief tricks apply here (expendable routines especially, and no use of squiggly brackets, and no symbolics referencing other symbolics).

Steve

Matt,

You say it's happening on SOME machines.  

The questions I would look to answer are:

  On the machines that crash, does WHO at login show fewer available variables?

  On the machines that crash, is the hardware setup in the computer setup (usually in the 3rd selection) show video memory being cached (not bios, but memory)?  How about on the other machines?

 On the machines that crash, is the PIF memory setting set to PROTECT?

 I would make sure that all machines (because the problem may not originate on the machine that crashes) have video ram cache turned off and that the PIF has conventional memory set to PROTECT, and that the Windows Performance tab in My Computer has write-behind caching turned off (ok, the write-behind won't run you out of variables, but it's always a good thing to check, as is turning off transaction processing for the Novell using the server configuration utilities.)

Please let me know if any of this helps so I can include all of this in a troubleshooting guide I'm putting together.

Larry

tardis_systems@yahoo.com

http://rehabsw.tripod.com (I have an AREV forum with free utilties)

View this thread on the forum...