× 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.


  • Subject: Re: Exception vs function-check; ILE vs OPM
  • From: "David Morris" <dmorris@xxxxxxxxxxxxx>
  • Date: Fri, 07 Jan 2000 10:47:10 -0700

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.