File Exception/Error Subroutine - INFSR

[Dan <dbcerpg@xxxxxxxxx>]

In a new shop that takes production issues seriously.  They don't want
operations staff to deal with any more error messages than absolutely
necessary - a laudable goal.

To do this, every, and I mean *every*, I/O operation involving a data
file is checked with %error.  For example:

   C   Key_PTMEPTO   SETLL(E)  PCPTMEPTP
    **
    ** Check for Error
    **
   C  ...      IF        %ERROR
   C  ...      EVAL      MESSAGEDTA  = *BLANKS
   C  ...      EVAL      MESSAGEID   = 'PD00001'
   C  ...      EVAL      MESSAGEDTA1 = 'PCPTMEPTO'
   C  ...      EXSR      BUILD_MSG
   C  ...      LEAVESR
   C  ...      ENDIF

Frankly, I find it somewhat ridiculous to test for errors on a SETLL or
other relatively benign file I/O ops.  (Yes, I check for record locks
and duplicate keys.)  But, I digress, it's a standard, and one that I'm
generally in favor of.  I just would desire to "hide" the code in a
faraway routine, tucked even lower than the *inzsr SR.

So I check the RPG reference and find the INFSR (File Exception/Error
Subroutine) keyword, which I've known about for years, but have never
put into practice.

Does anyone have practical experience using INFSRs?  Any gotchas to
watch out for?

The biggest problem I see is when I want to trap a record lock and
display a message window in an interactive app with a retry option, or,
in the case of a batch application, retry with short waits X number of
times; if successful on a retry, processing should pick up where it
left off after the input operation.  I don't see how one can do that
with an INFSR, cuz you can't return to the point just after the input
operation.  Any suggestions?

TIA, Dan

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com