RE: Program failure analysis

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




-----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