I sometimes think that there should be a charge for Chris Craddock's advice.
As usual it would be hard to improve upon:
<begin snippet>
Most of the time the better path of valor is to request diagnostics, burp up a
message about what went wrong and then percolate.
You will seldom get in trouble for bailing out, but a surprising number of
major failures come from ill-advised retry efforts.
</end snippet>
It is not only that "illl-advised retry efforts" too often produce major
failures. Even when they merely fail they muddy the waters: the situation at
ABEND is obscured, making the diagnosis of what triggered it much more
difficult.
Galen's old maxim for physicians---Above all do no harm---should be kept
constantly in mind in writing recovery-attempt code. In particular, diagnostic
information supplied after a recovery attempt will be worse than useless. In
practical terms, it is always necessary to provide diagnostics and messages
before recovery is attempted (tacitly assuming that recovery will fail) because
the diagnostics and messages provided afterwards will be actively misleading.
Finally---I am fresh from an experience in which it was not---recovery code
must be kept at the same maintenance level as the routines for which it
provides recovery. Again in practical terms, this means that it must be
changed and reassembled every time these routines are changed.
John Gilmore Ashland, MA 01721-1817 USA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
