× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.