How can I get the job no. after SBMJOB in a CL program?
Or should I call an API to perform SBMJOB for me?
Thanks.
Regards,
Steven
I send it to a PF then parse it looking for "active" status then I
extract the jobno, clumsy but it works!
In article <8mosl1$1r9$1...@hfc.pacific.net.hk>,
Sent via Deja.com http://www.deja.com/
Before you buy.
Dieter
In article <8mou8c$s97$1...@nnrp1.deja.com>,
--
Programming today is a race between software engineers striving to
build bigger and better idiotproof programs, and the Universe trying to
produce bigger and better idiots. So far the Universe is winning.
(Rick Cook)
Tlili fayçal
tl...@mapsys.fr
***********************************************
"Stephen NG Sze-ho" <ngs...@pacific.net.hk> a écrit dans le message news:
8mosl1$1r9$1...@hfc.pacific.net.hk...
A little more detail: Using DSPMSGD CPC1221, you can see the message
replacement data has 5 fields, of which the first 3 (job name elements)
are of interest. To use the job name elements in another CL command (eg
WRKJOB), your CL should look something like this:
DCL VAR(&msgdta ) TYPE(*CHAR) LEN(46)
DCL VAR(&jobname ) TYPE(*CHAR) LEN(10)
DCL VAR(&jobuser ) TYPE(*CHAR) LEN(10)
DCL VAR(&jobseq ) TYPE(*CHAR) LEN(6)
SBMJOB ...
RCVMSG MSGTYPE(*COMP) RMV(*NO) MSGDTA(&msgdta)
CHGVAR &jobname %SST(&msgdta 1 10)
CHGVAR &jobuser %SST(&msgdta 11 10)
CHGVAR &jobseq %SST(&msgdta 21 6)
WRKJOB JOB(&jobseq/&jobuser/&jobname)
Asides: 1) The RMV() parameter of RCVMSG can be used to retain or delete
the message from the job log. 2) The &msgdta variable need only be
large enough to contain the message replacement values you need; in this
case 26 characters. 3) The command SBMDBJOB (submit job from database
file) also returns CPC1221.
--
Karl Hanson
And a little more commentary <a CLProgramming tip>:
In the above pgm example it is fine since nothing precedes the SBMJOB, but
beware usage of MSGTYPE(*COMP) when other actions were taken in a program
before the request of interst. Per "Message type (MSGTYPE) - Help"
Note: Non-exception messages are received in first-in
first-out (FIFO) order.
In those cases, MSGTYPE(*LAST) may be more appropriate; I prefer to do
this by default, in case someone changes the code to add something before
the SBMJOB. Finally adding comparison for the expected RTNTYPE and MSGID
before continuing, to ensure the assumptions are met.
An example of a change that could break the above pgm; insert only the
following request, before the SBMJOB, and CPC0904 is received instead:
CRTDTAARA DTAARA(QTEMP/JOBINF) TYPE(*CHAR) LEN(26)
Regards, Chuck
All comments provided "as is" with no warranties of any kind whatsoever.