TechTip: Using *PSSR: The Good, the Bad, and the Ugly

[MCWebsite.Staff]

** This thread discusses the article: TechTip: Using *PSSR: The Good, the Bad, and the Ugly **
** This thread discusses the Content article: TechTip: Using *PSSR: The Good, the Bad, and the Ugly **
0

[bernhard.enderle@uta.de]

TechTip: Using *PSSR: The Good, the Bad, and the Ugly

** This thread discusses the article: TechTip: Using *PSSR: The Good, the Bad, and the Ugly **
you wrote: A program in a batch job fails. The *PSSR subroutine handles the error and returns to the calling program using a RETURN opcode. The next program higher in the stack doesn't fail or end because the previous program ended "normally." The batch job completes normally, and the users receive the message that "job xxx/xxx/xxx submitted by xxx completed successfully." The users/operators have no idea that a problem occurred. I think, you can avoid that the caller will be not informed about the error. You can leave the program with *CANCL in the ENDSR OPCode (factor_2) like: C *PSSR BEGSR * CALL Errorhandler... C CALL 'ERRORHDL' C PARM SDS C DUMP C MOVE '*CANCL' EXEC C PSSRZ ENDSR EXEC

[Guest.Visitor]

TechTip: Using *PSSR: The Good, the Bad, and the Ugly

** This thread discusses the article: TechTip: Using *PSSR: The Good, the Bad, and the Ugly **
We use the *PSSR routine pretty much as it is coded in the IBM RPG programmer's guide. Unless you code a return parameter on the prototype statement in a procedure you cannot use any of the * keywords on the ENDSR statement in the *PSSR subroutine. We have found that the most effective (and ugly) way of ensuring that programs crash all the way up the stack is to turn on the H1 indicator. And yes all of the programs within the stack must include the same trap, burn and die routines in order to stop a batch program in its tracks. This also includes writing a PSSR stype global MONMSG routine for every single CL program.

[mlemon@corrpro.com]

TechTip: Using *PSSR: The Good, the Bad, and the Ugly

** This thread discusses the article: TechTip: Using *PSSR: The Good, the Bad, and the Ugly **
So, how SHOULD we code the PSSR to issue an error message? You certainly told us what NOT to do, but left me looking for an example of what I should be doing. More please.

[gotto@islandpacific.com]

TechTip: Using *PSSR: The Good, the Bad, and the Ugly

** This thread discusses the article: TechTip: Using *PSSR: The Good, the Bad, and the Ugly **
The CEE4ABN API provides a way to end a procedure abnormally which "kills" the program calling the procedure and "ends the activation group nearest the control boundary" (from IBM's API information web site). There are parameters that give you some additional control as to what happens.

[bharder@nlrha.ab.ca]

TechTip: Using *PSSR: The Good, the Bad, and the Ugly

** This thread discusses the article: TechTip: Using *PSSR: The Good, the Bad, and the Ugly **
I think this was your theme here, to make sure as developers that the error handling "holds together" and does reasonable things. If so, then we agree. My technique, although it does have some theoretical holes, has held up extremely well under real world conditions. I check after every I/O operation for the status of that I/O. I use the result values available on the I/O operations (CHAIN, READ, etc.) and indicators. Alternatively, I have sometimes used the extended opcodes and the %Error and %EOF functions afterwards. My goal is to have the local program handle the error and continue on if at all possible. The majority of the time, I've found that it is possible to continue processing. I'm not interested in an error model where an application hits a slight snag and immediately bails out. My experience is that clients react better if they can get partial results, even it isn't perfect. Of course, an error message is always issued somewhere regardless. As for the higher level calling programs, I've found that I'm really only interested in sending them roughly 3 status values. Either something really bad happened and the calling process needs to end immediately, or something sort of bad happened but processing continues anyway, or a minor error happened and the calling program might even be able to ignore it completely. It's a sort of large/medium/small setup. Rarely do I want multiple dumps or other error reports from each level in the command stack. Only the first error really contains the directly relevant information. Everything else is a cascade error and secondary. The one thing that I've never been able to do is to, at my local application level, is explicitly generate a dump and keep the joblog. That is, when the application experiences a problem and keeps going anyway, it would be nice to have some supporting information available. It hasn't been a big problem and so I really haven't focused on it much, but it still would be nice.

[jeffolen4]

TechTip: Using *PSSR: The Good, the Bad, and the Ugly

** This thread discusses the article: TechTip: Using *PSSR: The Good, the Bad, and the Ugly **
You are correct. So long as the ENDSR in the *PSSR is reached (e.g. the RETURN opcode is not used) then the action determined by the factor 2 entry will be taken. Jeff

[Guest.Visitor]

TechTip: Using *PSSR: The Good, the Bad, and the Ugly

** This thread discusses the article: TechTip: Using *PSSR: The Good, the Bad, and the Ugly **
One way to do the dumps is to use the "A" extender with the "Dump" opcode (i.e. Dump(a) ). This forces a program dump regardless of whether the program was compiled with the "Debug" header keyword. To ensure that you keep the logs after performing a dump a simple call to a CL program that uses CHGJOB to change the job log retention to *SECLVL from *NOLIST and also to change LOGCLPGM to *YES. This could also be done by calling "QCMDEXC' instead of a CL program.

---

Code

[bharder@nlrha.ab.ca]

TechTip: Using *PSSR: The Good, the Bad, and the Ugly

** This thread discusses the article: TechTip: Using *PSSR: The Good, the Bad, and the Ugly **
Thanks a bunch! I have to say, the code to answer my problem turns out to be awfully simple! That's a good tip.