e i g h t - c u b e d . c o m 

Error error handling

Obviously, error handling in any programming language is a good idea, and something that we as programmers (yes, that means you, Mr Systems Manager) should strive to ensure is well done in our programs/scripts. I find it rather ironic when people with the best of intentions code error routines, only to have them fail.

What do I mean by that? Well, I was looking at an error scenario yesterday, having being asked "Why didn't we get a page when this error occurred?" The DCL command procedure in question had done (nearly) all the right things. An error had occurred during a file copy, and the programmer had specified the appropriate ON ERROR THEN GOTO ERROR_ROUTINE line. Once control had passed to the error routine, the procedure then proceeded to stop a bunch of batch queues, but unfortunately there was a typo in the name of one of the queues, and the resultant error caused the procedure to abort before it could send the email to the pager.

The solution to this is simple once I located the error. At the beginning of an error routine, the programmer should have said to himself "I want this routine to complete, even if further errors occur, because I must send the notification to the pager". So the addition of a SET NOON as the first statement in the error routine is an excellent idea. Oh, and of course I fixed the typo too.