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