Chuck,
YIKES - mighty complicated! I will continue to study this, and I am
totally grateful for EACH AND EVERY response from EVERYONE who has
responded with an interest from my concern!!!
Thanks,
Don
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, May 14, 2008 7:00 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CPYSPLF - but don't know JOB() submitted by a vendor pgm
calledby 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].
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
