Long time no talk, but of course I come running back as soon as I have a problem :)

We have a long-running process that will occasionally die, taking ARev down with it. No error messages are displayed to the screen; the whole app just shuts down.

My guess is that it's an out-of-memory issue. It happens on some user's PCs but not others. I've never been able to reliably duplicate it on my machine. I've verified that all of the users have the memory settings on the PIF configured the same, and they do.

I'm wondering if putting Flush and GarbageCollect within the main loop of the program would help any at all. I wouldn't do it ever iteration, but say every 100 or 1000 records. The program does make one external function call, but it's a minor one. It's purely a wrapper to the LOCK operand to allow a program to wait until a lock is available.

The other possible issue is that the program makes extensive use of VSCREEN. I'm thinking perhaps VSCREEN is chewing up too much memory, and that if I take it out then perhaps the process will run faster.

Any ideas, thoughts, suggestions?

Oh, yeah. We're running a Ceridian-modified version of ARev 3.02. The users have Win98 virtual machines running within VirtualPC 2007 on WinXP clients. However, this issue pre-dates the move to VirtualPC and was occurring under pure Win98 clients as well.

FLUSH and GARBAGECOLLECT are expensive in terms of processing time. They usually cause a perceptible pause, FLUSH being the biggest culprit.

I'd avoid putting them within the main loop. A limit check of every 1000th iteration maybe too small - you'll have to run tests.

Normally I put them before and/or after SELECT or PERFORM statements and before exiting the program.

Setting variables to null ("") when they are no longer needed helps as does the TRANSFER statement. Care must be taken with the TRANSFER statement because of the processing time hit if you redefine a variable that had been TRANSFERed previously.

VSPACE is known to crash you to "DOS". ARev 1.1x was famous for this when paging through a large RLIST report on screen. I haven't used it often enough to suggest any solutions.

I was wondering about the VSPACE/VSCREEN being the culprit. I have other program that process as many or more records, and do much more intensive processing, yet they don't bomb out.

I think I'll remove all of the VSPACE/VSCREEN calls and just use the age-old 'UB' and 'DB' message types.

Thanks for the info.

Hi Matt,

Make sure that the CONFIG.SYS file contains the Files=200 entry.

The Sprezzatura Group

World leaders in all things RevSoft

I forgot about FILES=200.

I'll go ahead and verify that as well.

I have found that the program does run a bit faster now without all of the screen update overhead of the VSCREEN calls.

View this thread on the forum...