Re: CPYSPLF - but don't know JOB() submitted by a vendor pgm called by my CLP

[CRPence <CRPbottle@xxxxxxxxx>]

  Because the CLP is not the program issuing the SBMJOB, that changes 
the inquiry to "How to determine the job last submitted by JOB(*)"  This 
clarification of the scenario, complicates the issue.  There are a 
number of possible solutions, but probably nothing real pretty.  What 
approaches are better than others, depends both on what is known and how 
any one approach might impact the function of any other work done by the 
vendor application outside of JOB(*).

  Some questions:

    Does the CPC1221 appear in the joblog?  I infer yes, otherwise 
probably that approach would probably have been dismissed earlier.?  If 
so, then DSPJOBLOG OUTPUT(*OUTFILE) and then retrieving the message with 
the data in the row with the desired CPC1221 is _a_ method; similarly 
there is an API to list the message in JOB(*).  DSPLOG or use of Job 
Notifications are variations to these, even if the completion does not 
remain in the joblog upon return from the vendor program.

    Does the submitted job have a static MSGQ() specification?  A 
static JOB name?  If so, then along with a concern others pointed out 
about the spool file even being available, the interactive CLP could 
poll or wait on the event, the message indicating the job completed. 
May require also verifying that it was the job submitted by JOB(*).

    Assuming the CLP processing is interactive, then WRKSBMJOB has an 
option to list jobs submitted from that workstation.  However I am not 
sure if there is an API to get that information easily.  I am not aware 
of, but maybe a 'list jobs' API gives an option to list\filter by 
"submitted from/by job"?

    Can the JOBQ being used by this application be held and then 
released?  Probably not, unless it is a *JOBQ object dedicated to this 
application, and only if multiple users will not be running that 
application concurrently; even so it may not be good option if there 
could be long delay between calling the vendor application and when 
SBMJOB occurs -- e.g. think [coffee] time, in filling in parameters to 
get there, much like record locking concerns, since the concept here is 
to serialize.  If it can be held/released around the call to the vendor 
application, then this might be the best, because then the job queue can 
be queried for the waiting job, the queue released, then poll for the 
end of the job and copy of its spool file.

    Side note:  Depending on how [im]properly the vendor submit 
activity is coded, there may be an option to Trojan Horse the submit 
request to effect desired constant parameter values where values are 
currently unspecified.

    Other questions.?  Well, the Subject update redirects for further 
discussion.

Regards, Chuck

Don Cavaiani wrote:
> my clp calls vendor's rpgle, which asks for the high/low parms, then 
> somehow submits the print pgm.  There is no source code.
>
> CRPence wrote:
> > From the original message, as I recall, it was not absolutely clear
> > if the SBMJOB was in your CLP or if the Submit Job request was
> > being done by the vendor application which was being called by your
> > CLP.  For the RCVMSG MSGTYPE(*LAST) to function, requires that
> > RCVMSG request be in the same CLP as the SBMJOB request *and* that
> > the Submit Job request must immediately precede that RCVMSG
> > MSGTYPE(*LAST) request [except a MONMSG which handles a failed
> > SBMJOB, as a condition for which that RCVMSG would then be
> > bypassed].