RM-COBOL runtime error #204
>I receive a runtime error #204 while running a program.
>(RM-COBOL under MS-DOS)
>I know it has something to do with insufficient memory.
Just off the top of my head, I'd say that error has to do
with a called program
not being accessible. I'm not sure
such an inaccessibility error status means scarcity
of memory - as far as I'm able to recall, it should mean
unresolved path or wrong compiled version (as seen
by the underlying runtime).
>The program uses a couple of huge tables and it's not possible to make
Sure? Not even writing their contents down to a file (or files)?
>The moment I call another program from within this program the error
>Is it possible to use the upper or other memory (switch or parameter)
I lost contact with rm-cobol's *.cobs running under Dos for
sometime now, but remember that if you had your DOS
memory management well tuned, nammely if you had
free Upper Memory Blocks, then the runtime might use them
as well. But all this should be implemented on the Dos front.
As for the runtime parameters, you may reduce memory alloccated
to sorting (t=?/may be zero if you don't sort/merge), reduce the
accept/display buffering (b parameter) and little else. The terminfo
file can also be modified and give you something more of what you
need. You can also switch off the pop-up windows manager
if you don't use that feature.
Anyway I can tell you that once I had a couple hundred programs
running in Dos (Novell network), windowing at full steam(Panels),
sort/merging, lots of tables, permanent sub-program calling (and
cancelling) and I was even able to call a very interesting tool that
Liant sold at that time and that enabled you to display true
graphics of data supplied to an appropriate template. Well, this
utility, unlike Rm-runtime, depended on the extended memory
available. One feature I used not to be bothered by memory
complaints was 'overlay' sections.
Luckily all those programs (in a newer version) are running
under Unix and I had no more concerns on the subject.
Anyway , let's hope someone may turn out with more
>Bert van de Bovenkamp