Routine but Varying Runtime Error under 5.01a

I use Clipper 5.01 to design "front ends" to several DOS .COM and .EXE
programs that I didn't write. Most of these use the RUN command to
invoke these programs, usually in a loop. I will usually get an error
somewhere during runtime - this can happen at about 1000 cycles or so,
but can run as high as 60,000 cycles - there doesn't seem to be
consistency where the error occurs.

The error message is presented in a Windows pop-up msg box  running
W98SE and is as follows:

================
This program has performed an illegal operation and will be
terminated. Quit all programs, and then restart your computer.

If the program consistently encounters problems, click the Start
button, then select Help, Troubleshooting, and "If you have trouble
running MS-DOS programs".

The program encountered a general exception.
Fault location:  49AB : 0984
Interrupts in service:  None
=================

The first part of the fault address will vary, but the second part is
always 0984. I have used the MEMORY() function to monitor memory
during program execution, since I suspected memory was slowly leaking
away, but the number shown (about 367K) remains constant as the loop
cycles through. I monitor MEMORY(0) and MEMORY(2) by printing to the
screen every cycle.

I am using the original Clipper 5.01a disks with no modifications, I
am compiling/linking a single .PRG file and the size of the .EXE is
around 145K. The .EXE doesn't do much more than open and close
sequential disk files (all text) related to the external program; the
external .COM in the RUN command is only about 30K.

Is this something relatively easy to diagnose and fix, or should I
explore using another programming language? I'm using Clipper because
I own it and it's easy to use, even though I'm not interfacing with
databases in this case.

Thanks in advance, and I apologize for the somewhat vague problem.

Carl

There are several well known memory leaks in 5.01a, but most of them are
related to DBFNTX issues.  I suggest you start monitoring memory 1, 3, & 4
as well as 0 and 2.  If Clipper is the cause of your problems, you're likely
running out of VM or EMS.

Memory(0)    ->Conventional memory
Memory(1)    ->Largest available block
Memory(2)    ->Run memory
Memory(3)    ->VM
Memory(4)    ->EMS

You may also want to start monitoring Windows resources, specifically
available memory.

"Carl Ritner" <Carl@CarlRitner.com> wrote in message
news:24737a51.0403181326.288aa45e@posting.google.com...
> I use Clipper 5.01 to design "front ends" to several DOS .COM and .EXE
> programs that I didn't write. Most of these use the RUN command to
> invoke these programs, usually in a loop. I will usually get an error
> somewhere during runtime - this can happen at about 1000 cycles or so,
> but can run as high as 60,000 cycles - there doesn't seem to be
> consistency where the error occurs.
>
> The error message is presented in a Windows pop-up msg box  running
> W98SE and is as follows:
>
> ================
> This program has performed an illegal operation and will be
> terminated. Quit all programs, and then restart your computer.
>
> If the program consistently encounters problems, click the Start
> button, then select Help, Troubleshooting, and "If you have trouble
> running MS-DOS programs".
>
> The program encountered a general exception.
> Fault location:  49AB : 0984
> Interrupts in service:  None
> =================
>
> The first part of the fault address will vary, but the second part is
> always 0984. I have used the MEMORY() function to monitor memory
> during program execution, since I suspected memory was slowly leaking
> away, but the number shown (about 367K) remains constant as the loop
> cycles through. I monitor MEMORY(0) and MEMORY(2) by printing to the
> screen every cycle.
>
> I am using the original Clipper 5.01a disks with no modifications, I
> am compiling/linking a single .PRG file and the size of the .EXE is
> around 145K. The .EXE doesn't do much more than open and close
> sequential disk files (all text) related to the external program; the
> external .COM in the RUN command is only about 30K.
>
> Is this something relatively easy to diagnose and fix, or should I
> explore using another programming language? I'm using Clipper because
> I own it and it's easy to use, even though I'm not interfacing with
> databases in this case.
>
> Thanks in advance, and I apologize for the somewhat vague problem.
>
> Carl

"Carl Ritner" <Carl@CarlRitner.com> wrote in message
news:24737a51.0403181326.288aa45e@posting.google.com...
> I use Clipper 5.01 to design "front ends" to several
> DOS .COM and .EXE programs that I didn't write.
> Most of these use the RUN command to invoke these
> programs, usually in a loop. I will usually get an error
> somewhere during runtime - this can happen at about
> 1000 cycles or so, but can run as high as 60,000
> cycles - there doesn't seem to be consistency where
> the error occurs.

I'm not sure about the memory problems, but I do know of a way to avoid
using the RUN command - self-modifying batch files.  Instead of running your
program which in turn calls the others, you call the batch file.  Inside the
batch file, you call your program which modifies the rest of the batch file
to call your utilities with the desired parameters and then loop back to the
start (if desired).

Here's an example batch file that does this:

:Start
myprog frombatch
util -a -b -c -d
goto Start

What myprog does is rewrite the batch file (you have to know where it is -
probably best to put the batch file & myprog in the same directory) using
the choices selected by the user.  Something like this:

function Main(cCmdLine)

if cCmdLine <> 'frombatch'
? 'You shouldn't run this program directly.  Please use the batch file.'
Return(NIL)
endif

// User picks choices here

h := fcreate(cBatchfile, FC_NORMAL)
fwrite(h, ':Start' + CRLF)
fwrite(h, 'myprog.exe frombatch' + CRLF)
if lRunUtility then
fwrite(h, 'util ' + cOptions + CRLF)
if lDoItAgain
fwrite(h, 'goto Start' + CRLF)
endif
endif
fclose(h)

Return(NIL)

Obviously, this won't run as-is, but you should get the general idea (I used
to do this with BASIC programs).  When myprog exits, the OS continues to run
the now modified batch file from where it left off.  You must make sure that
you don't change the line count up to the point where myprog is called, but
anything after that is fair game (including eof if you decide you don't want
to run util.exe).

Good luck!

Regardless of the solution, let us know how it turns out.

--
Ray Marron

"Carl Ritner" <Carl@CarlRitner.com> wrote in message
news:24737a51.0403181326.288aa45e@posting.google.com...
> I use Clipper 5.01 to design "front ends" to several DOS .COM and .EXE
> programs that I didn't write. Most of these use the RUN command to
> invoke these programs, usually in a loop. I will usually get an error
> somewhere during runtime - this can happen at about 1000 cycles or so,
> but can run as high as 60,000 cycles - there doesn't seem to be
> consistency where the error occurs.
>
> The error message is presented in a Windows pop-up msg box  running
> W98SE and is as follows:
>
> ================
> This program has performed an illegal operation and will be
> terminated. Quit all programs, and then restart your computer.
>
Carl,
Did you rule out the possibility that the fault may not be caused by
Clipper?  Check what other programs are running at the same time, e.g.
virus/antivirus, printer monitors, etc. Check for power line interference
(e.g. air conditioners).

And what about those .COM and .EXEs that you didn't write? Do they all
experience the problem?  Have you tried just running one of them at a time?

As you may see from the tone of this message, I doubt the fault lies with
Clipper :-)  But if you are convinced that it does, post an example of one
of your "front ends" on this NG (if it's not too big) so that we can check
it for possible bugs.

Kind regards
Norman
--
Norman Perelson
http://www.shopkeeper.co.za  mailto:norman@shoso.co.za

On Fri, 19 Mar 2004 21:46:27 +0200, "Norman Perelson"
<norman@shoso.co.za> wrote:

>
>"Carl Ritner" <Carl@CarlRitner.com> wrote in message
>news:24737a51.0403181326.288aa45e@posting.google.com... 
>Carl,
>Did you rule out the possibility that the fault may not be caused by
>Clipper?  Check what other programs are running at the same time, e.g.
>virus/antivirus, printer monitors, etc. Check for power line interference
>(e.g. air conditioners).
>
>And what about those .COM and .EXEs that you didn't write? Do they all
>experience the problem?  Have you tried just running one of them at a time?
>
>As you may see from the tone of this message, I doubt the fault lies with
>Clipper :-)  But if you are convinced that it does, post an example of one
>of your "front ends" on this NG (if it's not too big) so that we can check
>it for possible bugs.
>

I've seen this before when running a Netware capture command.  Fixed
in the end by using a better command shell - 4DOS, available from:

http://jpsoft.com/

"Ray Marron" <me@privacy.net> wrote in message news:<c3fe3j$26ttgg$1@ID-88259.news.uni-berl
in.de>...
> "Carl Ritner" <Carl@CarlRitner.com> wrote in message
> news:24737a51.0403181326.288aa45e@posting.google.com... 
>
> I'm not sure about the memory problems, but I do know of a way to avoid
> using the RUN command - self-modifying batch files.  Instead of running yo
ur
> program which in turn calls the others, you call the batch file.  Inside t
he
> batch file, you call your program which modifies the rest of the batch fil
e
> to call your utilities with the desired parameters and then loop back to t
he
> start (if desired).
>

[snip details]
>
> Regardless of the solution, let us know how it turns out.

I do understand this concept, and it looks like a plausible
workaround. I'm going to pursue this option pending a few other ideas
I've received by email.

To answer another suggestion, I've tried replacing the shell program
with a "simulator" program that I did write, and the loop executes a
greater number of cycles, but eventually encounters the error. I have
at least three different "front ends" that shell to various programs,
and they all exhibit the same problem, so I'm being fair to discount a
bug in the shelled program.

This happens under W98SE (gives the popup msg box) and XP Home (no
error message - the program just quits). Machines range from PII
400Mhz to AMD 2000 so I'm going to rule out a chip specific issue.

I'm going to monitor MEMORY(x) for 1 thru 5 as also suggested. Thanks
for the helpful replies, and I will post the results.

Carl Ritner
www.carlritner.com

"Steve Lupton" <nospam@nowhere.com> wrote in message news:<cwG6c.5339$Lq4.3114@twister.soca
l.rr.com>...
> There are several well known memory leaks in 5.01a, but most of them are
> related to DBFNTX issues.  I suggest you start monitoring memory 1, 3, & 4
> as well as 0 and 2.  If Clipper is the cause of your problems, you're like
ly
> running out of VM or EMS.
>
> Memory(0)    ->Conventional memory
> Memory(1)    ->Largest available block
> Memory(2)    ->Run memory
> Memory(3)    ->VM
> Memory(4)    ->EMS
>
> You may also want to start monitoring Windows resources, specifically
> available memory.
>
Here are the values displayed on the screen while the program is
running:

Memory(0)    ->376
Memory(1)    ->64
Memory(2)    ->367
Memory(3)    ->367
Memory(4)    ->8092 to 8188 (constantly changing but stays in this
range)

None of these values changed just prior to the general exception
error, nor afterwards. The error occured at 61,175 cycles.

Let me look at Windows resources ~ Carl

I'm going to have to backtrack on this issue and apologize to those
who answered. After examining the source code for several programs and
doing some research, with tremendous help from Ross, it does appear
that there is a single culprit, and it is one of the shelled programs.
I was under the belief that this error happened independant of the
external program, but this is apparently not the case.

Why the error varies in loop count is not known, but I will pursue
this with the vendor. I appreciate all who responded (one of you
should be feeling smug :) and thanks again for tolerating a question
that should have been answered by a little more research on my part.

Cheers,
Carl Ritner