Re: Passing data structure to batch job

On 28 May 2012 11:37, Hiebert, Chris wrote:

You are correct, that would be more efficient.
However, by coding your applications in this way you are allowing
a program to modify a parameter that you defined as constant.
The CONST keyword doesn't guarantee a temporary copy will be made.

Changing the /constant/ is inappropriate, as I had alluded some would contest. I agree, but figured since the CL was not inhibited\bound by the prototyping rules [and assuming a temporary copy was ensured]... Of course the whole point of the original CL is effectively to override the original prototype of 5000A, to pass an extra trailing non-blank, so it's not like a more direct approach to debasing the prototype is so much worse ;-)

So, even if the described might not guarantee a temporary copy [though the doc seems to suggest a temporary will be used because "the passed parameter has a different format" than the prototyped; surely for a declare that is shorter than prototyped.?], the RPG could do all of the work to both copy and non-blank-pad, rather than deferring any of that work to the CL.

The RPG could effect the temporary copy and set the extra non-blank byte using the identical setup. The RPG would add the non-blank character by passing the expression DS + 'X' as the argument; thus ensuring both the temporary copy and the non-blank trailing extra byte. Because an expression passed as the argument _must_ generate a copy, the CLP can avoid the duplication of copying the parameter data and assigning the extra non-blank last\trailing byte.

/* submitter program PROVSN_SUB */
PGM PARM(&SUBMIT &INPUTDS)
DCL VAR(&SUBMIT) TYPE(*CHAR) LEN(1)
DCL VAR(&INPUTDS) TYPE(*CHAR) LEN(5001)
/* Input was passed as 1 char longer than defined */
/* and the extra byte contains a non-blank character */
IF COND(&SUBMIT *EQ 'Y') THEN(DO)
SBMJOB CMD(CALL PGM(PROVSN_SUB) PARM('N' &INPUTDS)) +
JOB(NMS) JOBQ(QBATCH4)
ENDDO
ELSE CMD(DO)
CALL PGM(PROVSN_NMS) PARM(&INPUTDS)
ENDDO
ENDPGM

D submitprovsn PR EXTPGM('PROVSN_SUB')
D SUBMIT 1A CONST
D DATA 5001A CONST

D my5000aDS DS 5000
D ...

callp submitprovsn('Y' : my5000aDS + 'X');

This is similar to other comments where a suggestion was made to add a byte to the DS to effect the same. However vitiating the DS is, IMO, a much less desirable means to implement passing a non-blank trailing byte. Passing the expression which concatenates the extra character, seems much more appropriate.

Regards, Chuck

Hmmm... I need to clarify then. My suggesting that the 5001 be
coded in the RPG on the prototype for the CLP was not meant to
imply that the CLP would be left unchanged; i.e. being coded in
conflict with the PR. Instead, both that the PR would be coded with
the 5001 *and* the CLP would be coded with the 5001 to match. And
that the CL would set the 5001st character of that temporary
storage, instead of first copying the 5000 characters and then
setting the 5001st character. So my point was merely to eliminate a
_second_ copy of the data, where the first copy is being done by
the RPG, per the CONST spec. Thus for a 5000 byte DS in the RPG
program, the CL and the prototype could be coded as:

/* submitter program PROVSN_SUB */
PGM PARM(&SUBMIT &INPUTDS)
DCL VAR(&SUBMIT) TYPE(*CHAR) LEN(1)
DCL VAR(&INPUTDS) TYPE(*CHAR) LEN(5001)
/* Input was defined as 1 char larger than required */
IF COND(&SUBMIT *EQ 'Y') THEN(DO)
/* Set a char after the last byte to pad for CL variables */
CHGVAR VAR(%SST(&INPUTDS 5001 1)) VALUE('X')
SBMJOB CMD(CALL PGM(PROVSN_SUB) PARM('N' &INPUTDS)) +
JOB(NMS) JOBQ(QBATCH4)
ENDDO
ELSE CMD(DO)
CALL PGM(PROVSN_NMS) PARM(&INPUTDS)
ENDDO
ENDPGM

D submitprovsn PR EXTPGM('PROVSN_SUB')
D SUBMIT 1A CONST
D DATA 5001A CONST

I suppose some might /frown upon/ that utilization because CONST
was coded, but it is _because_ CONST was coded, that making such an
update to the input argument should be completely safe.

Also as Vern noted, I believe the default declared storage for the
CL parameter is 32 bytes vs 64.

On 28 May 2012 07:26, Hiebert, Chris wrote:

The reason the 5001 field is defined inside the CL is because the
last character is used to pad the field when submitting to
batch.
When the program runs it only references the first 5000
characters and never needs to remove the padded 'X' (or whatever
character was used).
This extra character takes care of the CL to CL submission issue
when you have fields defined over 64 bytes long.

On CRPence Friday, May 25, 2012 10:42 AM wrote:

<<SNIP>>

I might suggest however, that if CONST is going to be used on
the prototype, then probably just as well to code the 5001 size
in the RPG program for the prototype of the invoked CL
procedure. There is little reason to copy the nearly 5K bytes
from one place to another again; i.e. such a copy would have
been done already on the call interface, as dictated by the
CONST on the PR, so there is no reason to copy that data into
yet another temporary location in the CLProc.

<<SNIP>>

On 25 May 2012 08:04, Hiebert, Chris wrote:

I will usually wrap a submitted RPG job with a CL program and
code the CL program to be able to submit itself.

/* submitter program PROVSN_SUB */
PGM PARM(&SUBMIT &INPUTDS)
DCL VAR(&SUBMIT) TYPE(*CHAR) LEN(1)
DCL VAR(&INPUTDS) TYPE(*CHAR) LEN(5000)
/* Output defined as 1 char larger than input */
DCL VAR(&OUTDS) TYPE(*CHAR) LEN(5001)
IF COND(&SUBMIT *EQ 'Y') THEN(DO)
CHRVAR VAR(&OUTDS) VALUE(&INPUTDS)
/* Set a char after the last byte to pad for CL variables */
CHGVAR VAR(%SST(&OUTDS 5001 1)) VALUE('X')
SBMJOB CMD(CALL PGM(PROVSN_SUB) PARM('N' &OUTDS)) +
JOB(NMS) JOBQ(QBATCH4)
ENDDO
ELSE CMD(DO)
CALL PGM(PROVSN_NMS) PARM(&INPUTDS)
ENDDO
ENDPGM

Then you just need to prototype the call:

D submitprovsn PR EXTPGM('PROVSN_SUB')
D SUBMIT 1A CONST
D DATA 5000A CONST

<<SNIP>>