Re: Program failure analysis

Buck,

IMHO...

Dump is useful in an ON-ERROR, as you don't know where the error might have
come from.

In ON-EXIT, using IBM APIs, if an error is returned, you know what few
pieces are involved, you can just send a message passing along those pieces
of data. Dump, if it worked, would be overkill (or lazy ;)

Charles

On Thu, Oct 12, 2017 at 8:54 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 10/12/2017 8:55 AM, Justin Taylor wrote:

Don't you still need an ON-ERROR? Can't you just put your DUMP in there?

As much as I like a good philosophical discussion, this is actual
program code that I'm working on. There are two 'abnormal' code paths
within the ON-EXIT block:
1) An exception like array index error. This will be trapped by
MONITOR...ON-ERROR.
2) An API call that executes with no exceptions, but returns an
unexpected result in the error code parameter. MONITOR...ON-ERROR
doesn't trap these.

Neither case can use DUMP inside an ON-EXIT block.

If I want to use ON-EXIT to /guarantee/ that 'cleanup' always runs
AND
'cleanup' uses multiple IBM APIs
AND
DUMP cannot be coded in ON-EXIT
THEN
How do I log (possible) multiple 'abnormal' results within 'cleanup' for
later analysis?

-----Original Message-----
From: Buck Calabro [mailto:kc2hiz@xxxxxxxxx]
Sent: Wednesday, October 11, 2017 12:45 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Program failure analysis

BLUF: How do you perform failure analysis of a program hours or days

after the program fell over?

I have a programming pattern that I use in order to capture a post

mortem dump in the case of a catastrophic error that I didn't foresee.

I wrap the entire cycle main program in a MONITOR block and run the

cleanup everywhere I RETURN, as well as in the ON-ERROR block; it looks
like this:

monitor;
...
// all is well
wrkReturnCode = '1';
wrkReturnMsg = 'All is well';
exsr setReturnState;
return;
...
on-error;
wrkReturnCode = '0';
wrkReturnMsg = 'Casters up!';
exsr setReturnState;
return;
endmon;

begsr setReturnState;
QsyReleaseProfileHandle(profile_current_handle: errorStruc);
if err_use <> 0;
dump(a) 'release current';
endif;
...
endsr;


Then, ON-EXIT came along! Following the hint in the manual, I moved all

the code into a single sub-procedure and called that from the mainline.

Within that sub-procedure, I put this:

dcl-proc...

ON-EXIT;
QsyReleaseProfileHandle(profile_current_handle: errorStruc);
if err_use <> 0;
dump(a) 'release current';
endif;
...
end-proc;

DUMP is disallowed by RNF0203 (in capital letters, no less!) What do

other RPGers think about this programming pattern? How do you handle post
failure diagnosis? Log4RPG? Spooled file? CEE4RAGE + *NEW activation
group?
--
--buck


--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD