Re: Exception vs function-check; ILE vs OPM

Hi David,

Actually, the CHGDTA command exhibiting the behavior is the AS/400 version
from QSYS. Barbara could tell you if the System/38 version does the same
thing.

Are you referring to the status in the program status data structure? If so,
I'm curious too - that would be even easier than checking the return code
with Barbara's method. If not, where can we find out about return code
values? Are they different for every program that sets it? Or are there some
standard codes + pgm-specific codes?

Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax

----- Original Message -----
From: David Morris <dmorris@plumcreek.com>
To: <RPG400-L@midrange.com>
Sent: Friday, January 07, 2000 9:47 AM
Subject: Re: Exception vs function-check; ILE vs OPM


> 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
> +---


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

+---
| 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
+---