Re: Exception vs function-check; ILE vs OPM

["David Morris" <dmorris@xxxxxxxxxxxxx>]

Barbara,

Out of curiosity, how does the return code 
relate to the status?  Is this non-standard 
behavior caused because this is a system 38 
command?  Are there other cases where this 
would happen and should they be handled?

Thanks

David Morris

>>> bmorris@ca.ibm.com 01/07/00 09:28AM >>>

>Date: Thu, 6 Jan 2000 16:30:09 -0800
>From: "Peter Dow" <pcdow@yahoo.com>

Peter, you've run into one of the differences between RPG III
and RPG IV regarding programs or commands that return with
high return codes but no exception.  CHGDTA does not end with
an escape message when if fails.  Instead, it gives a information
message (there is an escape message in the joblog, but it's not
the final message), and sets the languages-and-utilities return
code to 2.  This is the return code you see on option 1 of
DSPJOB.  It is set by RPG and COBOL and a few utilities.

RPG III interprets this as an error, while RPG IV ignores the
return code since it was unaccompanied by an exception.

(For the documentation of the difference, see Appendix A of the
Programmer's Guide, in the section called "Running", bullet #3).

You could change the RPG IV program to also check the return
code, and assume failure if the return code is not 0 or 1.

D LUWRKA          PR              *   EXTPROC('_LUWRKA')
D luwork          ds                  based(pLuWrkArea)
D   lu_rc                        5i 0
 * Initialization
C                   eval      pLuWrkArea = LUWRKA
 ...
 * Try the command
C                   call      'QCMDEXC'             10
C                   PARM                    cmd
C                   parm                    cmdlen
C                   if        *in10 or (lu_rc > 1)
C                       error ...

Regarding some of the other responses to your question:
1. Jon Paris is correct in general, that exception handling
   oddities are    possible in DFTACTGRP(*NO) programs, and
   that DFTACTGRP(*YES) programs should behave the same regarding
   exception handling.  But in this case, with an error indicator,
   the activation group should not make any difference.
2. Even if there were a condition handler, it would never "beat"
   the error indicator.
3. Using a prototyped call woudn't cause this problem.  (The
   problem with prototyped calls to QCMDEXC is that you can't
   code an error indicator, so failed commands cause the program
   to crash.  (Solved in V4R2 with the (E) extender which takes
   the place of the error indicator.))

Barbara

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---