× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hello Bob,

Jumping in here ...

You wrote:
>But then how do you check for the error condition's status error code?
>If %STATUS is truly set all the time?

You must specify (E) if you want to catch the error -- or use one of the
alternatives (e.g., indicator or MONITOR) -- otherwise you won't get a
chance to check %STATUS due to the RPG exception handling kicking in.

>I thought the philosophy was use (E), then check for an error by looking
>at %ERROR, if it was *ON, then you'd look at %STATUS to see what the
>specific error was. But if %STATUS is always set, why do you still need
>%ERROR? Is %STATUS always set or not?

The manual says:
"The operation code extender 'E' can be specified. When specified, before
the operation begins, this extender sets the %ERROR and %STATUS built-in
functions to return zero. If an exception/error occurs during the operation,
then after the operation %ERROR returns '1' and %STATUS returns the file
status. The optional file information data structure is updated with the
exception/error information. You can determine the action to be taken by
testing %ERROR and %STATUS."

The manual also says, reagrding the INFDS, that "Location *STATUS is updated
after every file operation", and by implication %STATUS, which I've always
found to be true.  However, some status codes do not indicate errors in the
true sense e.g., 00011 (EOF) and 00012 (Not found) which are normal
occurrences.  For these status codes %ERROR will not be set but the
corresponding %EOF and %FOUND BIFs will be set.

Your error handling approach is fine but you've never NEEDED to check %ERROR
-- even on pre-RPG IV code.  For example:

FFILE ....                              KINFDS  FILEDS

IFILEDS DS
I                               *STATUS         STATUS

C               OPCODE                                  HILOEQ
C               SETLL  FILE                               66
C       STATUS  DOWEQ  0
C               READE  FILE                               6666
C               whatever
C               ENDDO

*IN66 is simply used to catch any exception, it is never explicitly checked.
The STATUS field from the INFDS is used to determine whether things are OK
or not.  I'm not advocating this coding style, merely pointing out that it
has always been possible.  Checking %ERROR allows an easy way to distinguish
between normal status codes and exception/error status codes without having
to code explicitly for each group.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.