RE: Passing data structure to batch job

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.

Chris Hiebert
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, May 28, 2012 11:42 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Passing data structure to batch job

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

Regards, Chuck

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

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.