Re: override scope in a procedure

[Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx]

that's because the override exists only in the called procedure when the 
procedure returns to the calling procedure (main or otherwise) that call 
stack entry is removed and thus the override is gone since it occurs at 
the call stack level.

Thanks,
Tommy Holden


From:
JDHorn@xxxxxxxxxxxxxx
To:
rpg400-l@xxxxxxxxxxxx
Date:
10/10/2008 09:02 AM
Subject:
override scope in a procedure
Sent by:
rpg400-l-bounces@xxxxxxxxxxxx



   Hi Scott
 
   Thanks for the reply.
 
   We have a long conversion process, still getting some stuff out of the 
36
   environment, that needs to coexist until we are done.
 
   Sorry, I guess I'm not sure of the difference between using a procedure 
in
   the existing program (not in a service program) and a prototype.
 
   when I create a program like this
 
   D qqcmdexc        PR             1A 
   D   qqcommand                  512A   options(*varsize) const 
   D 
    /free 
     qqcmd   = 'OVRPRTF' 
             + ' FILE(' + %TRIM(XXPRTF) + ')' 
             + ' OUTQ(MIS_SYS/MONRDAR)' 
             + ' USRDTA(ARADD)'; 
     success = qqcmdexc(qqcmd) - does not work 
     /end-free 
   -call report program-
   P qqcmdexc 
   B  
   D qqcmdexc        PI 
   1 
   D   qqcommand                  512A   options(*varsize)
   const 
   D  
   D  SUCCESS        S 
   1 
   D  qcommand       S 
   512 
    /free  
     SUCCESS=
   'Y';  
     qcommand  = qqcommand
   ; 
     qcommandl =
   %len(%trim(qcommand));  
    /end-free  
   C 
   MONITOR 
   C                   call 
   'QCMDEXC' 
   C                   parm 
   qcommand 
   C                   parm                    qcommandl        15
   5 
   C 
   ON-ERROR 
   C                   EVAL      SUCCESS=
   'N' 
   C 
   ENDMON 
   C  
   C                   RETURN 
   SUCCESS 
   P qqcmdexc        E 
 
   the override only exists while procedure qqcmdexec is running.  When I
   leave the procedure, the override disappears.  (I am running this in 
debug
   and using dspovr to see the overrides).
 
 
   When the program looks like this.
 
   /free 
    qqcmd   = 'OVRPRTF' 
            + ' FILE(' + %TRIM(XXPRTF) + ')' 
            + ' OUTQ(MIS_SYS/MONRDAR)' 
            + ' USRDTA(ARADD)'; 
    exsr xcallqcmd; 
    /end-free 
   -call report program-
   C     XCALLQCMD     BEGSR
   C                   eval      QQcmdl = %len(%trim(QQcmd))
   C                   call 
   'QCMDEXC' 
   C                   parm                    QQcmd 
   512 
   C                   parm                    QQcmdl           15
   5 
   C                   ENDSR  
 
   The override exists after the subrouting is finished processing.
 
   Since we are not using different activation groups for functional 
purposes
   within a job, we have tried scope(*job) also.  This works most of the
   time, but sometimes leaves an override that wasn't being expected 
(Qsysprt
   being a good example). I am concerned that the whole system being
   originally designed with the concept of calllvl scoping, we could run 
into
   unforseen consequences when we implement program changes and the new
   programs wind up being called from older, non ile, programs.
 
   Thanks again
 
   Jim
   ----------------------------------------------------------------------

   message: 1
   date: Thu, 09 Oct 2008 22:12:50 -0500
   from: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
   subject: Re: override scope in a procedure

   JDHorn@xxxxxxxxxxxxxx wrote:
   >    I am trying to write a procedure or service program call to 
execute
   >    override printer file commands.

   A procedure *or* service program?  Did you mean to say a procedure *in*
   a service program?

   >    It seems that in either case the scope of the call level is 
greater
   than
   >    the call level of the program that called it.

   Yes.  That's the way procedures work, each call to a procedure creates 
a
   new call level.

   >    Is there a way, other than using creating a string and calling
   qcmdexc
   >    using Call/Parm to get the override to be at the same level as the
   calling
   >    program?

   You don't have to use call/parm -- you can (and should!!) use a 
prototype.

   But, if your override logic is complex enough to warrant calling a
   procedure (not just a prototype) then you might consider using
   OVRSCOPE(*ACTGRPDFN) and running your program and override subprocedure
   in the same ILE (non-default) activation group.

   You see... the call-level only matters when you use OVRSCOPE(*CALLLVL)
   or when you run your override from the DFTACTGRP.  When using proper 
ILE
   activation groups with *ACTGRPDFN the override applies to the entire
   activation group, regardless of call stack level.

   That's one of many ways that activation groups make life better.

   This email is intended only for the person or entity
   to which it is addressed and may contain information
   that is privileged, confidential or otherwise protected
   from disclosure. If you are not the named addressee
   or an employee or agent responsible for delivering
   this message to the named addressee, you are not
   authorized to read, print, retain copy, and disseminate
   this message or any part of it. If you have received this
   message in error please notify us immediately by email,
   discard any paper copies and delete all electronic files
   of this message.