override scope in a procedure -- RPG400-L

Thanks Scott

JDHorn@xxxxxxxxxxxxxx wrote:
> We have a long conversion process, still getting some stuff out of
> the 36 environment, that needs to coexist until we are done.

Scott wrote:
I seem to be missing the point. The stuff in the S/36 environment can't
call your procedures anyway, so what difference does the S/36
environment make to this discussion?

Jim writes:
I was referring to an override with *job issued by a program, which could
have been called by a program which was loaded or called by a s36
procedure, could mess up an override when returning to a previous call
level, or maybe wouldn't "go away" after the current program ends and
would affect a future call from the same job. (Code has been around a
long time.)

As always your explanations and examples are great.

Am leaving soon to go bird hunting in North Dakota for a week. When I get
back, it's another round of Cajun duck gumbo made with great Klement
sausage. Thanks for all the help.

Jim Horn

------------------------------

message: 2
date: Fri, 10 Oct 2008 11:34:48 -0500
from: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
subject: Re: override scope in a procedure

JDHorn@xxxxxxxxxxxxxx wrote:
> We have a long conversion process, still getting some stuff out of
> the 36 environment, that needs to coexist until we are done.

I seem to be missing the point. The stuff in the S/36 environment can't
call your procedures anyway, so what difference does the S/36
environment make to this discussion?

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

A prototype (PR in the D-spec) is a mechanism for CALLing something. It
can call a procedure, program or Java method (depending on how it's
coded). It is the "new" (if you consider 1995 to be "new") replacement
for CALL/PARM, CALL/PLIST, CALLB/PARM and CALLB/PLIST. It has many
similarities to CALL/PARM (et al) but has lots more features. All of
the new features IBM has added to the way calls are made over the past
13 years have been made to prototypes, not to CALL/CALLB/PARM/PLIST.

A procedure is a routine, sort of like a subroutine, or perhaps a
"sub-program". It's one of the things you can call.

The difference between a procedure and a prototype is the difference
between "making a call" and "a routine that gets called"

Here's an example of a prototype for the QCMDEXC API:

D QCMDEXC PR ExtPgm('QCMDEXC')
D cmd 32702a const options(*varsize)
D len 15p 5 const
D igc 3a const options(*nopass)

This prototype is named QCMDEXC -- the PR identifies it as a prototype.
The ExtPgm('QCMDEXC') tells the prototype to call a program named
QCMDEXC. By default, a prototype calls a procedure, but specifying
ExtPgm makes it call a program instead.

The line that starts with 'cmd' is the definition of one parameter to
the API. the word 'cmd' isn't an actual variable -- it's just
documentation that helps me remember what the first parameter does. The
'32702a' is the definition of that parameter. The word 'CONST' means
that the called progrma (in this case, the QCMDEXC API) won't change the
parameter, which lets RPG do some extra work, such as coding expressions
for the parameter. The options(*varsize) means that I can pass smaller
strings to the API if I like.

The len and igc lines are additional parameters. options(*nopass) means
that I don't have to pass the 3rd parameter -- it's optional. I can
leave it off of the call if I don't need it.

With that prototype, you can code the following to run your override and
check for success/fail:

D cmd s 200A varying

/free

cmd = 'OVRPRTF'
+ ' FILE(' + %TRIM(XXPRTF) + ')'
+ ' OUTQ(MIS_SYS/MONRDAR)'
+ ' USRDTA(ARADD)';

monitor;
QCMDEXC(cmd: %len(cmd));
success='Y';
on-error;
success='N';
endmon;

The options(*varsize) is largely for performance, because I squirm at
the thought of the RPG runtime automatically adding 32,000 (or so)
blanks to the end of the string for me.

For an override, where I probably wont' need 32702 characters, and where
I am not too worried about an error occurring, I might take some short
cuts and code it more like this:

D QCMDEXC PR ExtPgm('QCMDEXC')
D cmd 200a const
D len 15p 5 const

/free

QCMDEXC('OVRPRTF'
+ ' FILE(' + %TRIM(XXPRTF) + ')'
+ ' OUTQ(MIS_SYS/MONRDAR)'
+ ' USRDTA(ARADD)': 200);

So now I've forced the 'cmd' parameter to be only 200 long -- but it's
always 200 (it's not *VARSIZE). That means that RPG can evaluate an
expression, store it in a 200A field for me (under the covers), and pass
that to the API for me. That saves me having to code a string ahead of
time. Since it's always 200 long, I simply pass 200 for the length
parameter, so I don't need to calculate it.

With that syntax, it's really easy to code an OVRPRTF (as above) without
needing to call a subprocedure.

In your example, you constructed the override string, called a
subprocedure. The subprocedure then called the QCMDEXC API. So you had
two calls, and that means an extra call-stack level which is messing up
your override.

In my examples, above, I called QCMDEXC directly. No subprocedurre as
an intermediary! Therefore, there was no extra call stack level, and
the override will work as expected.

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.