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