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

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