RE: Passing data structure to batch job

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.



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

I agree that a CL procedure is probably a good choice; better than
most of the proposed solutions :-) IMO, including mine. However I am
unclear why that response would be a reply to my messages, because my
replies had intended to describe to the OP how to keep the work within
the SQLRPGLE program just as easily and effectively as had "normally"
been done in their RPG programs [but apparently prior works had not
dealt with a DS]. Also FWiW, the same suggestion for using a CL module
was also already made by Brian Johnson, albeit not as clearly and
robustly defined; no RPG declares and no submitted versus not submitted
described there. IMO the quoted message below, would have been a better
reply to that, Brian's message:
http://archive.midrange.com/rpg400-l/201205/msg00252.html

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.

So anyhow, while each of the other solutions offered may have their
value... using any of the LDA, a server job, "temporary" permanent
objects [presumably deleted by the submitted or server job; though I do
not recall anyone dealt with that], adding another procedure\programs
[as discussed here], or whatever else that may have been alluded to for
effective IPC [though none of the InterProcess Communication APIs was
mentioned in the thread], they all seemed a bit overkill to effect a
relatively simple CL request directly from RPG; i.e. passing some data
on a parameter effectively the same way as one might have done with a
scalar variable versus a data structure, using a SBMJOB
CMD(CALL...PARM...) command string on the QCMDEXC API.

Regards, Chuck

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

// Then just call the program to submit it.
CALLP submitprovsn('Y':NMS_DS);

Your data parm would just need to be defined bigger than your NMS_DS
data structure. And the OutDS in the CL should be defined as 1
character bigger than the input.

A small problem with using QCMDEXC it that its limited to processing
strings at most 32702 characters long. So, if you wanted to submit
anything with a huge parm QCMDEXC won't work for you.

CRPence on Thursday, May 24, 2012 7:08 PM wrote:

I had copied an untested version of code into my earlier response
[quoted message below]. Within the second SQL SET, I had accidentally

both included a prompt request character for the command and omitted
a closing parenthesis [for either CMD or PARM; depending on
perspective, I suppose]. Both issues have been corrected inline to
that quoted message.

If anyone knows how to cause the declaration of the standalone based
variable NMS_DS to have a declared length of %len(NMS_OrderDetails),
I am curious. I realize [now, with testing] that I can specify the
length on the DS and then use the
LIKE(NMS_OrderDetails) on the declare of NMS_DS [while omitting the
length and type], but that seems almost as silly as hard-coding the
length on the based variable.

On 24 May 2012 14:43, CRPence wrote:

This is how I would accomplish it. Sorry, but I am unaware of how to

make the 51A be based on the size of the DS; i.e. using LIKE is of
no assist to define that based variable as type-A with the
length(DS).

d NMS_DS s 51a based(NMS_DS@)
d NMS_DS@ s * inz(%addr(NMS_OrderDetails))

Exec SQL
Set :ParmInHex = 'X''' CONCAT HEX(:NMS_DS) CONCAT '''';

Exec SQL
set :Command =
'SBMJOB CMD(CALL PGM(PROVSN_NMS) PARM('
concat :ParmInHex concat ')) JOB(NMS) JOBQ(QBATCH4)';

On 24 May 2012 13:18, Koester, Michael wrote:

<<SNIP>>

d NMS_OrderDetails...
d ds qualified
d Order 6a
d OrderType 2a
d Phone# 10S 0 inz(0)
d PhoneExch 6s 0 overlay(Phone# : 1)
d PhoneLine 4s 0 overlay(Phone# : *next)
d OldPh# 10s 0 inz(0)
d OldExch 6s 0 overlay(OldPh# : 1)
d OldLine 4s 0 overlay(OldPh# : *next)
d CableType 6 inz
d PriorCableType...
d 6 inz
d COE 11a inz

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