Re: Passing data structure to batch job

[CRPence <CRPbottle@xxxxxxxxx>]

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