Re: PSDS and Monitor

While your global *PSSR is overkill for me at this time, the concept of a /COPY *PSSR for any procedure has a lot of merit. Especially since I can limit it to only those routines which can break (I use LOTS of subprocedures, but many of them are very safe, either calling other subprocedures or doing simple calculations). I like the idea of checking a global data area for debug level, and then dumping as needed. And then I can just set the line number into a global variable and exit out.

This has potential. I'm going to look into it!

Joe

Joe,

I got this exact same thing, and eventually, I just stopped trying to use
the line number in the calling procedure.

If process() is in the same program, then as soon as an error occurs within
process(), you could save the line number, but then you may as well have
full error processing within process() itself. Which is what I did - I
added error processing to every procedure (using a *PSSR) and then just
returned a non-zero iRC value, which the caller processed explicitly.

Basically, every called procedure contains essentially the same code in its
*PSSR (in an in-line copybook):

1. Check a global data area to see what level of debugging/dumping/error
handling should take place
2. Determine its own name (using QWVRCSTK)
3. If the procedure should be dumped, dump it (using the procedure name as
the dump name)
4. Perform any other error handling as required by #1.
5. Return a non-zero return code (or whatever return value will be treated
as an error by the caller)

The global control data area contains information about what processing
should occur and about how far up the call stack it should happen. For
instance, if a procedure fails, I can specify that a dump should be taken
for that procedure and the next two procedures up the call stack. I can
also specify that some procedures shouldn't ever be dumped or should always
be dumped or whatever.

The only thing I use the PSDS for is to get the program name at the
top-level, in non-error circumstances.

Rory

On Thu, Apr 5, 2012 at 10:25 AM, Joe Pluta<joepluta@xxxxxxxxxxxxxxxxx>wrote:

I've run into a little hitch when attempting to use the program status
data structure in conjuction with a monitor block.

Here's the skeleton of a standard mainline for me:

iRC = 0;
monitor;

iRC = process();

on-error;

iRC = 999;
PSDSInfo =
' (' + %char(PSDS_Status) + ')@' + PSDS_Line;

endmon;

if iRC<> 0;
dump(a);
ExceptionInfo =
'** Internal error ' + %char(iRC) + PSDSInfo;
dsply (ExceptionInfo);
endif;

*inlr = *on;

Pretty straightforward. Set error code to zero. Execute process()
which returns zero or an error. On error, set iRC to 999 and get the
status and failing line from the program status data structure. After
the monitor block, check the return code. If it's non-zero, display
the error.

The problem? By the time I hit the on-error block, the line number for
the PSDS is the call to process, not the line that actually failed.
Let's assume this is a normal program with H specs and a prototype and
so on. In that case, the line iRC = process() would be, say, line 18.
So every time I get an error, the line number would be 18.00.

So evidently any entry in the call stack causes the PSDS to be changed.
Is there a way to identify the actual failing line?

Joe