Carl wrote:
But if the parent routine uses any "permanent"
(100-1999) or "ordinary" (A-Z, 0-9) S/Gs -- values that stay memory-
resident after the program terminates -- you're asking for trouble.
Yes, I use S/Gs in the range 555-599. I can avoid that if necessary. But
wouldn't CLEARSGTS take care of that? I could (manually) do CLEARSGTS 555 -
559. That's the only range above 99 that I use. {I used to also use 101 -
105 in this program (as you'll see a reference to 101 below) but using EX1
allowed me to get rid of those.}
BUT -- but -- many of our routines use special-purpose S/Gs in the
600-799 range, which is reserved to the Jumbo U2 (documented in
README.1ST, in the XYWEBnnn.ZIP file).
No problem. I don't use them (I know about U2's having exclusive rights to
them).
But if your personal subroutines call our U2 routines and then terminate
early with EX1
I don't call any U2 routine *within a subroutine*--only within mainline code.
So, if you do call
a U2 frame as a child process, be aware of the S/G ranges used by
that frame -- and of the ranges used by all of the frames called by
that frame, and by all of the frames called by those frames, and so
on, down to the very last generation of child processes -- a non-
trivial exercise, because U2 is modular, with frames calling other
frames calling other frames all over the place.
But are you talking about S/G ranges outside the 600-799? I use a lot of
S/Gs below 50 (50 is of course reserved for U2), and sometimes in 51 - 99.
Hmmm maybe this accounts for some intermittent problems I've had using
PUTCR and UNPUTCR in my programs.
If you absolutely
MUST use EX1 in your routine, position the EX1 so that all Jumbo U2
frames have terminated by the time EX1 is encountered.
I have a couple of calls like jm 2.CHR$ q2 and jm 2.PUTCR q2. Wouldn't
those terminate immediately? I assume they are called, do their thing, and
are done before I get to the next thing in my XPL code. No es verdad?
> I want to do this kind of termination when there is an error
> condition in running the daughter program--it will make it
> easier to add ad hoc displays into the code.
I don't know what you mean by "ad hoc displays". Error messages?
And are you talking about temporary code, for purposes of debugging,
or permanent features of the program?
Temporary, for debugging when something unforeseen goes wrong (which only
happens about once every 4 months now).
Let's assume you mean error reporting. If the child routine
encounters an error condition, you want to report it to the user and
end the entire program in an orderly way. Instead of EX1 in the
child, set a return code, exit normally () to the parent, and
report the error _in the parent routine_, then terminate the parent.
Yes, that's exactly the way I have been doing it for the last couple of
years. I set S/G 101, because I thought (when I started this program 5
years ago) that a lower one would be wiped out in going back to the parent
program. An earlier post says that even the lower ones "stick" when going
back to the parent.
There's one thing I don't understand, though, in your sample code (which
I've otherwise erased here):
.. JM 2.childQ2 ;*; call to child process
I have the parent program do BX RUN CHILD.PGM Q2
I use JM for U2 frames, but can I and should I be using JM instead of RUN here?
There are SO many demands on parents these days that it's tempting
to plunk an EX1 in front of the child, just to shut it up. But you
know, Harry, and I know, that that's no way to raise a child
process. Spend some quality time with your daughter and son
routines, train them to confide in the parent if problems arise, and
put the solutions where they belong, with the parent that caused the
problem by deciding to have child processes in the first place!
There's a lot riding on this, Harry. It's not just your future,
it's all our futures. So, please...
LOL. And I hear playing in the background... "I believe the child are the
future ..."
Maybe you're right. You've almost got me persuaded, especially now that
I've gotten the (seemingly self-evident) idea of having the parent program
not merely report the error code on its command line, but open up a new
window with space for a more complete error report, including longer text
messages and giving the present value of several S/Gs.
All I've been using the parent's error codes for thus far is to show me
where in the program the problem arose: I sprinkled incrementing numbers
throughout, so if I saw on the command line: "error code 11" I could look
back at the (long) source code (because it's written in my XyBasic) and
know that the trouble lies somewhere after where I set error code to 11 but
before where I set it to 12.
So I had traps in the child program like: >BC
Just last night, I realized I could have: >BC Then at , which is at the very end of the program, after an for
normal termination, I can have it open a new window, give a lot of info,
not just S/G 101, then .
Thanks very much, Carl. An admirably clear and complete reply as always.
Much appreciated.
Harry Binswanger
hb@xxxxxxxx