Home > Archive > Clipper > May 2005 > Conventional Memory Exhausted .... and so is my brain
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Conventional Memory Exhausted .... and so is my brain
|
|
|
| I'm not a programmer and the writer of this prog moved on to Visual
thingies and is mega reluctant to write anymore Clipper code. He says
he forgot it!!!
BRIEF SPEC:
Dos database program used for chart compilation written in Clipper 5.2
and uses Comix indexes. Files is set to 96 and Set Clipper to 91.
A lot of data is processed.
There is no set pattern as to why at the very last stage of the charts
update (i.e. some 45 mins later) the prog bombs out with a
Conventional Memory Exhausted message. Th charts are run daily and
this error happens once or twice a w . This error tends to corrupt a
couple of indexes and one of the databases (usual hieroglyphics at the
tail end of the db). Only solution is to keep re running the prog with
fingers crossed.
Over the years I've run the prog on a local HD on a DOS PC, Win 98 and
Win 2000. The DOS PC fared better with hardly any probs. The downside
is that the DOS pc is a basic Pentium 1 PC so takes about 3 hours to
update this typically 45 min run on a P4 Win 2000 PC.
What tweaks (and precisely where? ) can I apply on the Win 2000 PC to
cure this problem?
Needless to say, any help is much appreciated.
Thanks
Ray
| |
| Markus Wiederstein 2005-05-29, 8:55 am |
| Ray,
send me the sourcecode of your program and i'll compile and link it
for you with latest settings, etc.
also a win32 build using xHarbour is possible, so you're program will have
no
dos mem probs any more.
Mail it to my e-mail address.
Cheers,
Markus
Am Sun, 29 May 2005 11:49:59 +0200 hat Ray
<mcg@promo-only-remove.freeserve.co.uk> geschrieben:
> I'm not a programmer and the writer of this prog moved on to Visual
> thingies and is mega reluctant to write anymore Clipper code. He says
> he forgot it!!!
>
> BRIEF SPEC:
> Dos database program used for chart compilation written in Clipper 5.2
> and uses Comix indexes. Files is set to 96 and Set Clipper to 91.
> A lot of data is processed.
>
> There is no set pattern as to why at the very last stage of the charts
> update (i.e. some 45 mins later) the prog bombs out with a
> Conventional Memory Exhausted message. Th charts are run daily and
> this error happens once or twice a w. This error tends to corrupt a
> couple of indexes and one of the databases (usual hieroglyphics at the
> tail end of the db). Only solution is to keep re running the prog with
> fingers crossed.
>
> Over the years I've run the prog on a local HD on a DOS PC, Win 98 and
> Win 2000. The DOS PC fared better with hardly any probs. The downside
> is that the DOS pc is a basic Pentium 1 PC so takes about 3 hours to
> update this typically 45 min run on a P4 Win 2000 PC.
>
> What tweaks (and precisely where? ) can I apply on the Win 2000 PC to
> cure this problem?
>
> Needless to say, any help is much appreciated.
> Thanks
> Ray
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
| |
| AUGE_OHR 2005-05-29, 8:55 am |
| hi,
are you using 3st party libs ?
show us your *.LNK (Link Script)
"Conventional Memory" is up to 640KB. Open your "DOS / CMD" Box
and type "MEM". if it is less than 530KB your Application might get this
Error.
1.) try to free memory
2.) switch to protect mode using Blinker or Exospace
.... but think of you 3st party libs, they must be protect mode too !
greetings by OHR
Jimmy
"Ray" <mcg@promo-only-remove.freeserve.co.uk> schrieb im Newsbeitrag
news:2l2j91l1cqlh0g3le65stonusj67hnthvt@
4ax.com...
> I'm not a programmer and the writer of this prog moved on to Visual
> thingies and is mega reluctant to write anymore Clipper code. He says
> he forgot it!!!
>
> BRIEF SPEC:
> Dos database program used for chart compilation written in Clipper 5.2
> and uses Comix indexes. Files is set to 96 and Set Clipper to 91.
> A lot of data is processed.
>
> There is no set pattern as to why at the very last stage of the charts
> update (i.e. some 45 mins later) the prog bombs out with a
> Conventional Memory Exhausted message. Th charts are run daily and
> this error happens once or twice a w. This error tends to corrupt a
> couple of indexes and one of the databases (usual hieroglyphics at the
> tail end of the db). Only solution is to keep re running the prog with
> fingers crossed.
>
> Over the years I've run the prog on a local HD on a DOS PC, Win 98 and
> Win 2000. The DOS PC fared better with hardly any probs. The downside
> is that the DOS pc is a basic Pentium 1 PC so takes about 3 hours to
> update this typically 45 min run on a P4 Win 2000 PC.
>
> What tweaks (and precisely where? ) can I apply on the Win 2000 PC to
> cure this problem?
>
> Needless to say, any help is much appreciated.
> Thanks
> Ray
| |
| Norman Perelson 2005-05-29, 3:55 pm |
|
"Ray" <mcg@promo-only-remove.freeserve.co.uk> wrote in message
news:2l2j91l1cqlh0g3le65stonusj67hnthvt@
4ax.com...
> I'm not a programmer and the writer of this prog moved on to Visual
> thingies and is mega reluctant to write anymore Clipper code. He says
> he forgot it!!!
>
(. o 0 I must stay away from Visual thingies)
> BRIEF SPEC:
> Dos database program used for chart compilation written in Clipper 5.2
> and uses Comix indexes. Files is set to 96 and Set Clipper to 91.
> A lot of data is processed.
>
> There is no set pattern as to why at the very last stage of the charts
> update (i.e. some 45 mins later) the prog bombs out with a
> Conventional Memory Exhausted message. Th charts are run daily and
> this error happens once or twice a w. This error tends to corrupt a
> couple of indexes and one of the databases (usual hieroglyphics at the
> tail end of the db). Only solution is to keep re running the prog with
> fingers crossed.
>
> Over the years I've run the prog on a local HD on a DOS PC, Win 98 and
> Win 2000. The DOS PC fared better with hardly any probs. The downside
> is that the DOS pc is a basic Pentium 1 PC so takes about 3 hours to
> update this typically 45 min run on a P4 Win 2000 PC.
>
> What tweaks (and precisely where? ) can I apply on the Win 2000 PC to
> cure this problem?
>
> Needless to say, any help is much appreciated.
> Thanks
> Ray
Clipper 5.2 prior to patch 5.2d had memory leak problems. Check your
Clipper version and apply the free patch if required. The last version of
5.2 is 5.2e. The patch is available from a number of download sites.
HTH
--
Norman Perelson
http://www.shopkeeper.co.za
| |
| Ross McKenzie 2005-05-29, 3:55 pm |
| On Sun, 29 May 2005 10:49:59 +0100, Ray
<mcg@promo-only-remove.freeserve.co.uk> wrote:
>I'm not a programmer and the writer of this prog moved on to Visual
>thingies and is mega reluctant to write anymore Clipper code. He says
>he forgot it!!!
>
>BRIEF SPEC:
>Dos database program used for chart compilation written in Clipper 5.2
>and uses Comix indexes. Files is set to 96 and Set Clipper to 91.
>A lot of data is processed.
>
>There is no set pattern as to why at the very last stage of the charts
>update (i.e. some 45 mins later) the prog bombs out with a
>Conventional Memory Exhausted message. Th charts are run daily and
>this error happens once or twice a w. This error tends to corrupt a
>couple of indexes and one of the databases (usual hieroglyphics at the
>tail end of the db). Only solution is to keep re running the prog with
>fingers crossed.
>
>Over the years I've run the prog on a local HD on a DOS PC, Win 98 and
>Win 2000. The DOS PC fared better with hardly any probs. The downside
>is that the DOS pc is a basic Pentium 1 PC so takes about 3 hours to
>update this typically 45 min run on a P4 Win 2000 PC.
>
>What tweaks (and precisely where? ) can I apply on the Win 2000 PC to
>cure this problem?
>
>Needless to say, any help is much appreciated.
>Thanks
>Ray
Hello Ray,
I am sorry to hear of your situation. Not being a programmer you must
feel somewhat at the mercy of other programmers now. Hopefully, "we"
will be able to be of more help to you than your amnesiac.
As mentioned by one of the other respondents, the cause of the problem
may well be the use of a flawed version of Clipper. If you have the
original source code, the solution may be as simple as recompiling the
code and relinking the resultant .obj file(s). Markus has offered
already to recompile and relink for you.
If you do not have the original source code, it can be recovered from
the .exe file by a process called decompilation. But before offering
to do so for you, you will need to obtain clearance to do so from the
copyright owner (presumably the amnesiac). If he is reluctant to do
so, you might like to remind him of his obligations under the Trade
Practices Act (or your UK equivalent). This is a demonstrably
defective product IMHO. However, it would be preferable to obtain the
original source code. Simply tell him that in return for the code, you
will release him from his legal obligations under the Trade Practices
Act and use the services of competent Clipper programmers in this news
group to remedy his inadequancies.
Regards,
Ross McKenzie
ValuSoft
Melbourne Australia
valusoft AT optusnet DOT com DOT au
| |
|
| Ray,
I agree with previous comments. Just want to add that you should
scandisk after an error like that. If the databases are corrupt then
use Dr. Salvage too. Occasionally run the disk defragmenter. Then
rerun the program.
Good Luck,
Mike
| |
|
| Ray,
I agree with previous comments. Just want to add that you should
scandisk after an error like that. If the databases are corrupt then
use Dr. Salvage too. Occasionally run the disk defragmenter. Then
rerun the program.
Good Luck,
Mike
| |
|
| Ray,
I have experenced similar problems in daily batch programs that take a long
time to run (more than 30 min). They occur occasionally, but only on
computers with the modern, fast processors, whereas there were never
problems on older, slower machines. I use Clipper 5.2d and Blinker 5.1 in
protected mode. As I suspected that the problem had something to do with too
little time for the garbage collection process, I added this line in the
source code (in the program loop) in order to "help" the garbage collector:
?? ""
This command displays a null string on the current position of the screen,
so you won't see anything happening, but somehow the garbage collector takes
the opportunity. You don't have to be a programmer, but you will need to
edit your source and recompile and link your program.
I hope this trick will also work for you ...
"Ray" <mcg@promo-only-remove.freeserve.co.uk> wrote in message
news:2l2j91l1cqlh0g3le65stonusj67hnthvt@
4ax.com...
> I'm not a programmer and the writer of this prog moved on to Visual
> thingies and is mega reluctant to write anymore Clipper code. He says
> he forgot it!!!
>
> BRIEF SPEC:
> Dos database program used for chart compilation written in Clipper 5.2
> and uses Comix indexes. Files is set to 96 and Set Clipper to 91.
> A lot of data is processed.
>
> There is no set pattern as to why at the very last stage of the charts
> update (i.e. some 45 mins later) the prog bombs out with a
> Conventional Memory Exhausted message. Th charts are run daily and
> this error happens once or twice a w. This error tends to corrupt a
> couple of indexes and one of the databases (usual hieroglyphics at the
> tail end of the db). Only solution is to keep re running the prog with
> fingers crossed.
>
> Over the years I've run the prog on a local HD on a DOS PC, Win 98 and
> Win 2000. The DOS PC fared better with hardly any probs. The downside
> is that the DOS pc is a basic Pentium 1 PC so takes about 3 hours to
> update this typically 45 min run on a P4 Win 2000 PC.
>
> What tweaks (and precisely where? ) can I apply on the Win 2000 PC to
> cure this problem?
>
> Needless to say, any help is much appreciated.
> Thanks
> Ray
|
|
|
|
|