Whereabout of Fix668.prg that may solve error 668.
Posted: Thu Jul 29, 2010 5:21 pm
Hi All,
We are experiencing an occassional clipper error 668.
-------------------------------------
Errror description:
668 Runtime error handler error (eval stack fault)
There could be an error in the runtime error handler. It is calling itself until the stack overflows.
The evaluation stack expanded into a locked VMM segment. The CA-Clipper VM System will use the DGROUP Free Space when conventional DOS memory is very low.
Action: Free up conventional DOS memory by reducing the application's load size and/or increasing free DOS memory as reported by DOS's MEM.EXE command.
----------------------------------------
It is happening at the end of the day when we summirze the transactions for the day. We made a log of Memory values and found that the failure happens when Memory(2) is less than 60K and succeed when freshly started.
So far we had tried the following suggestions:
1. Increase conventional memory. DosX.exe is not loaded in high memory area. We tried to resolve this but found to be a hardware issue.
2. Increased the procedure in Blinker by adding the following lines in Blinker script.
blinker procedure depth 175
blinker lowmem reserve 32
We found an article in the internet about Clipper Memory Management a mention of fix668.prg that may solve this problem but unfortunately even the author of the article cannot find a copy. The PRG was written by Robert Montgomery.
What we can find is just a trace of this file in Mirror Service.
./unzipped/compiler/dcon94/donnay/fix668.prg
Is anybody have this prg file or an idea of how a prg can solve error 668 or any suggestions?
Thank you.
We are experiencing an occassional clipper error 668.
-------------------------------------
Errror description:
668 Runtime error handler error (eval stack fault)
There could be an error in the runtime error handler. It is calling itself until the stack overflows.
The evaluation stack expanded into a locked VMM segment. The CA-Clipper VM System will use the DGROUP Free Space when conventional DOS memory is very low.
Action: Free up conventional DOS memory by reducing the application's load size and/or increasing free DOS memory as reported by DOS's MEM.EXE command.
----------------------------------------
It is happening at the end of the day when we summirze the transactions for the day. We made a log of Memory values and found that the failure happens when Memory(2) is less than 60K and succeed when freshly started.
So far we had tried the following suggestions:
1. Increase conventional memory. DosX.exe is not loaded in high memory area. We tried to resolve this but found to be a hardware issue.
2. Increased the procedure in Blinker by adding the following lines in Blinker script.
blinker procedure depth 175
blinker lowmem reserve 32
We found an article in the internet about Clipper Memory Management a mention of fix668.prg that may solve this problem but unfortunately even the author of the article cannot find a copy. The PRG was written by Robert Montgomery.
What we can find is just a trace of this file in Mirror Service.
./unzipped/compiler/dcon94/donnay/fix668.prg
Is anybody have this prg file or an idea of how a prg can solve error 668 or any suggestions?
Thank you.