PGM-CTR errors

[Robert E. Carneal]

In compile, my programs run fine. When I turn them into EXE
files however, I encounter the pgm-ctr error. The following is
the most common one.

7 at pgm-ctr 308

I can't even tell which program is triggering this error
because my program constantly shells another EXE file. I have one
"control" program that shells which ever program needed to run. Only
variables in the "Control" program need to stay intact- the
shelled to EXE variables do not need to be preserved.

Example:
If Invntry < MinReqs then
if Invntry < 0 then
Shell "C:\stock\autordr.exe"
else
Shell "c:\Stock\MinReqs.exe" :'Min inventory required!
end if
else
if Invntry > 40 then
Shell "C:\Stock\Ovrstck.exe":' TOO MUCH inventory!
end if
end if

And so on. Is there a way to determine which line and program s
triggering this type of error? I am hoping for a relatively easy
way to do this so I can do it myself. I counted the Shells, and
I have a total of 37 SHELLs. Is that the problem?

Thanks!

------------------

[Mel Bishop]

I would recommend putting a pause before each shell. Your
code modified: This is not exact of course, but it'll give
you the idea.

If Invntry < MinReqs then
if Invntry < 0 then

print;"Shelling to autordr.exe"
while instat=0:wend
temp$ = inkey$

Shell "C:\stock\autordr.exe"
else

print;"Shelling to MinRegs.exe"
while instat=0:wend
temp$ = inkey$


Shell "c:\Stock\MinReqs.exe" :'Min inventory required!
end if
else
if Invntry > 40 then

print;"Shelling to Ovrstock.exe"
while instat=0:wend
temp$ = inkey$


Shell "C:\Stock\Ovrstck.exe":' TOO MUCH inventory!
end if
end if

This should give you the program where the error occurs. Then
you should be able to take care of it from there.

Cheers
Mel


------------------

[Michael Mattias]

The "pgm-ctr" error is NOT a "prgm-ctr" error. "Error 7" (insufficient memory) is the important value, and you can use the IDE option "Compile/Find Error" to convert a "pgm-ctr" into a distinct line of source code.

Oops, forgot: if you are shelling your own PB/DOS programs, you can trap the errors simply by installing error traps with ON ERROR GOTO xxx. In your error-handler, you can PRINT the name of the program, the error code and ERRADR (ERRADR returns a "pgm-ctr" value which you can then trace back to a source code line as shown above).

MCM




[This message has been edited by Michael Mattias (edited August 14, 2001).]

[Robert E. Carneal]

Michael, currently I only check for a few errors at the ON ERROR,
the rest of them I simply RESUME NEXT. I will fix it to report
each and every error. I had been using ERRADR wrong, thanks for
pointing that out. A BIG thank you!

Robert

------------------

[Mike Luther]

But wait!

Isn't there more here? Grin!

RESUME NEXT has a price tag, doesn't it? If you use it you
generate a larger finished product as to the operational size
of your program, no? Next means the code has to know where next
is, as I understand all this.

As well, I may be learning something here again too, but isn't
the whole intrinsic error level operation keyed to NUMERIC line
labels?

I think I've learned a long time ago that an error only romps
back to the closest NUMERIC line label. For code stability
purposes I've never asked an error routine to ever even return
to a non-numeric line label. At least in BASIC. Can PB RESUME
at a non-numeric label? I think so, but it doesn't trap an
error to same as far as I know.

I wish it did in some further incantation of whatever, but I'm
not holding my breath or an avoidance on that wish.

That said, if I have to have error trap location information
in a block of code which doesn't have numeric line lables, I
create my own numeric trace variable pointer as the block
executes. Sort of my own line numbers if you please. Then
on error I can analyze that checkpoint variable and tell where
to resume even if there are no line lables that PB could use
to tell me other than even, say, only the first line in the
program has a number (10) for example.

That's particulary important when using in-line assembler, such
as a Btrieve file interface where things can go bump. You either
get to use line numbers for a trace purpose only, or code your
own substitute for that, as you wish.

As well, for very, very large projects, I've found it convenient
to plan for the lowest level subroutine library modules to carry
further and further numbers for the line labels toward the
allowable cap level of 64555 or so. Your master line numbers in
these subroutimes are, for example, all above 50000. That way
you can create one key numeric line number lable in each SUB at the
beginning of it, with the few critical other numeric lables at
critical places in it. That will let you trap back to the places
where things go wrong down deeper in nested code.

From there we use, as Lance Edmonds taught me quite a while ago
here, to be sure and use EXIT FAR to properly reflect back where
we went bumppity bump! The use of this is NOT, as best as I
can tell enhanced at all by the concept of RESUME NEXT. In fact,
isn't such a thing totally counterproductive and at odds with
the assignment of numerical line lables? They are limited you
know! And you can have a number of lines of code inbetween
consecutive numeric line labels as well.

What would happen to RESUME NEXT in that case?

Inquiring mind wants to know!

I think one is wise to contemplate all this for another interesting
reason.

If you ever have to port PowerBASIC to another language, one of
the things you will greatly miss is ... numeric line labels!
They are both a pest and savior, as you may have already discovered.

In a major port process for to take PB source to C of C++, I think
you will find that you'll wind up creating pseudo-lables for each
of the line lables you have in the PB source! That's what I wound
up doing in the translator here.

From there I created a trace trap integer counter for each location
which takes the place of that line number. It then is the directive
for the error trap routine you have to then use in the other
programming forum to do what is so easy in PB.

Since we started at RESUME NEXT for this pig trail,

how would you suggest one contemplate finding
the NEXT acorn for an error ****ing piglette,
without a numeric ear tag for each step 'e takes?


No, for those who have read Winnie The Pooh, I think RESUME NEXT
is rather akin to poor Pooh with the honey bucket stuck on 'is
head. A real bother indeed ..




Plus ..


It becomes a heck of a lot more introspective if your programs
are up in the 25,000 line source range, I clue you. As does
the burden of RESUME NEXT from an overhead standpoint.

The code's not done, 'till there's too much to run!

------------------
Mike Luther
[email protected]

[Doris Leeyin]

PB supports Line Numbers, put a Line Number in front of each Line
and break the code smaller in each line, then use on error goto
and check the error code then use resume (resume next is risky)

------------------

[Doris Leeyin]

Sorry, I forget to tell you can use "PRINT ERR,ERL" to check code

------------------

[Robert E. Carneal]

Michael- You are right about RESUME NEXT being risky. Blame my
college professor. Her opinion, at the time anyway, was to
track on paper what errors you wanted to catch. Then write
+only+ for those. Assume I have written a routine for the
errors I want to trap, then my next statement after the error
point would go back to "default" values for the variables so
the program could continue. I thought it was risky and asked
her if it wasn't better to prepare for all errors? Her response?
"Do it my way for the grade. I like RESUME NEXTs, and you will
too!" It is a habit I am working on breaking.

Doris, thank you for pointing out using line numbers. Previously
I was NOT a line number user due to the fact my Quickbasic did
not allow line numbers in SELECT CASE statements? I was pleased
to find that not the case with PB. Now I got to number all my
routines now.

------------------

[Doris Leeyin]

Robert,
You don't need to number all Lines, only those you suspect
a problem, like the one on "SHELL".

------------------

[Michael Mattias]

ERL reports the most recently numbered line executed.
ERRADR reports the "pgm-ctr" which you can then use to find the line of source code.

Compile/Find Error is such a really cool feature of the DOS compiler; it should get more use.

RESUME NEXT?

If you use ...

 ON ERROR ERROR RESUME NEXT

.. and don't check ERR after each possible ERR-generating statment, you are (IMPO) trolling for trouble.


Better you should write your code for development with ...

ON ERROR GOTO somewhere

..and after you have the major errors out and have code in place where ERR is EXPECTED (i.e., disk not ready, file not found), recompile, changing 'GOTO somewhere' with RESUME NEXT.

MCM

[Robert E. Carneal]

From Michael:

.. and don't check ERR after each possible ERR-generating
statment, you are (IMPO) trolling for trouble.


You are right. I have a rudementary routine now that tells me the
Error Number and Line Number (if there is one).

Robert

------------------

[Mike Luther]

Now ..

You are right. I have a rudementary routine now that tells me
the Error Number and Line Number (if there is one).

as you do this, think about one more step. Even if you do not have
a hard Line Number in view of (if there is one.), there is one
more thing you can do.

You can carry an otherwise not used integer variable that is
set to what might have been a line number at various points in
your program!

It doesn't have to be a for-real line number.

You just keep making it larger and larger, just line line numbers
only just like

LABLE1:

        LNR% = 1

LABLE2: 

        LNR% = 2

Then if something blows up between LNR% = 1 and LNR% = 2, you just
look at the value of LNR% and that takes the place of the formal
line number in the error trap routine! If at the time the error
takes place the value of LNR% is equal to one (1), you have your
conditional answer on what label you should return to on RESUME.

The error happened somewhere between LNR% = 1 and LNR% = 2.

Takes the place of formal line numbers, kind of!

Of course PB does the work for you with numeric labels. But the
point is that the logic process on how this works may come in
very handy when you might want to consider error trapping in other
than raw PB code .. in assembler .. or C or whatever!

If you know how to use line numbers for choosing the place to which
you wish to RESUME in BASIC, that's one thing. But if you understand
the process by which this works, you can immediately jump to the
same or at least similar capability in other ways. And that goes
not only to the process of error happenings, but the whole basic
process of IF / THEN on which error trapping is just a specialized
sugar coated variation on the theme.



------------------
Mike Luther
[email protected]