message: 8
date: Mon, 19 Jan 2009 13:56:48 -0800
from: David Wright <opendave@xxxxxxxxx>
Hi Dave,
<snip>
Anyhow, we are trapping errors and sending dumps and job logs directly
to our support queue, etc. In the past an error would prompt the user
to 'Contact IT' - a prompt that was largely ignored. This new process
has allowed us to clean up our daily operations a lot.
</snip>
Good idea. We have similar software. However, we take the joblog, job details (libl, open files, call stack, etc), and the module dump for specified objects and email them to Helpdesk. We also put out a Pause Screen which the user can't exit without getting a 3-byte code from Helpdesk.
<snip>
One area I see that we could still improve on is Record locks. Every
now and then we see two users attempting to lock the same record,
which causes one of the programs to dump. Obviously we could recode
every chain/read to handle lock errors using monitor or (E), but we
want something more universal that will not require touching so many
members. The original authors did not believe in error handling at
all :(
</snip>
Apart from using the OS-supplied handling software of course. ;-)
<snip>
Is there a way to capture this type of error in *PSSR, display an
error panel, and allow processing to continue once the lock is
resolved? Basically looking for a way to tell the PSSR that it is ok
to resume the program and retry the operation on this specific type of
error.
Is that possible?
</snip>
Short answer - No.
However, you should not be looking at *PSSR for this kind of exception handling. It is cycle-based and IMHO inappropriate for a modern RPG programming environment. You should be using ILE Condition Handlers.
As an example of what you can do:
Our software uses a ILE Condition Handler (within a service program) registered at the top-level of all our menus. This means that ALL exceptions that cause a *ESCAPE or *NOTIFY message to be sent to the message queue of a program in the call stack (assuming no control boundaries between) will cause the ILE Condition Manager to pass the token for the condition to the Condition Handler sub-procedure. Here you can do whatever you want. We have tables which define what to do based on the exception type, the object in error, etc. The standard process is to send the emails listed above. However, we send additional emails to the developer who leads a specific area if a program in that area crashes within 7 days of it being promoted. We also wrote a program which retrieves the variables and values and writes a module dump for a module in an active *PGM or *SRVPGM object. This effectively allows us to dump anything that is running in a job which has thrown an exception.
The most important point about using Condition Handlers though is the fact that the environment is completely untouched when it is called. We can debug a job in the pause screen which has thrown an exception for a divide by zero and manually amend the variable values and then instruct the job to ignore the failing instruction and continue. We can do this for array index errors too.
So, you could put a *PSSR subroutine into every program and use the DUMP op-code or simply create a single Condition Handler sub-procedure and use it to handle unhandled exceptions in your code. You can even lexically nest them so parts of your software have their own set of rules for handling exceptions.
The only downside is that littering your code with *PSSR subroutines short-circuits the top-level Condition Handler - the *PSSR will get invoked before the Condition Handler at a level above. We removed all our *PSSR subroutines from our code and have never looked back!
OK, specific to record locks - our code captures the RNX1218 message which is sent prior to the RNQ1218 message. We display a modified pause screen with a retry option. If the user takes the option the condition is handled and the default reply sent to the original message. This provides a much cleaner way to handle the locks. If the record is still locked the user must call helpdesk to handle the problem. Our users NEVER see a black message screen for ANY exceptions.
Have a look at chapter 13 in the RPG Programmers Guide:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzari_web/banner.htm
and chapter 9 in the ILE Concepts manual:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzari_web/banner.htm
for more information on ILE Condition Handlers.
Cheers and HTH
Larry Ducie
_________________________________________________________________
It's simple! Sell your car for just $40 at CarPoint.com.au
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT
midrange.com
