Getting RC of a job from rexx
Ramaswamy Saraswathy, Hari , Cognizant
I have a doubt. I have a rexx routine which will submit jobs. But I want to
get the RC from a job before submitting the next one. This I have to do from
the rexx itself. I have no much idea about CVT, eventhough i have used
existing rexx routines which used pointers to CVT area.
I was able to find a rexx routine which gives the list of all active jobs,
in a cbt tape.
Can you give some suggestion so that I can either call a either a rexx
routine or assembler program to check the return code from with in the rexx
routine which submits the jobs in sequence.(I have done some programming
using assembler).
Thanks and Regards,
HARI.R.S
COGNIZANT TECHNOLOGY SOLUTIONS
Elnet software city,
Taramani, Chennai - 600 113
*Office 254 1281 Extn : 4469
Home 372 0402
*Rama...@Chn.Cognizant.com
har...@yahoo.com
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Dave Salt
"job" without having to generate and submit JCL. For example, it could
allocate all the appropriate ddnames and directly call whatever program
needs to be executed. It would then know the return code from each program
it called and be able to decide whether to execute the next "job" (etc.).
Presumably the REXX program itself is executing in batch, so another
advantage of doing it like this is the user only has to submit and check the
return code of a single job. If the REXX program is executing in foreground,
you might want to reconsider the design. Having a foreground process wait on
the execution of batch jobs defeats the whole purpose of submitting jobs in
batch. HTH,
Dave Salt
><< InterScan_Disclaimer.txt >>
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Harrington, Mark
job if the first job is good and the second job submits the third job if the
second one is good. that way you dont need to worry about cvt or whatever.
in other words, the last step of every job is a little rexx that submits the
next one.
m.h.
-----Original Message-----
From: Ramaswamy Saraswathy, Hari (Cognizant)
[mailto:Rama...@CHN.COGNIZANT.COM]
Sent: Sunday, January 26, 2003 8:35 PM
To: TSO-...@VM.MARIST.EDU
Subject: Getting RC of a job from rexx
Tina Hilton
to a internal reader) along with the proper condition code checking.
Harrington, Mark
Dave Salt
execute other programs and get the return code that's set by each one, then
why wouldn't the REXX just invoke those other programs directly? In other
words, why does it need to spawn batch jobs?
Dave Salt
>From: Tina Hilton <Tina....@ARVATOSYSTEMS.COM>
>Reply-To: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
Paul A Redhead
Hari,
I remember participating in a discussion of this sort on this list a looong
time ago. I remember offering some information as to how this could potentially
be done and I still have some of those old ideas and code which I haven't run
for a long time but I'm happy to pass along for what they're worth (my stupidity
disclaimer).
As someone commented at the time "why don't you just buy a job
scheduler"...however, the idea was basically to submit a job that ran some REXX
code which itself submitted jobs and kept track of other jobs. When the REXX
submitted the job it captured the output which includes the jobname and job
number, it enquires of SDSF as to the status of the job on a regular basis (and
goes to sleep for a while in between) and when it finds the job has finished it
prints the output to a dataset. From there you could perform some sort of
processing on that dataset to find whatever your after. I'm not suggesting this
as a solution, I'm merely presenting the information to you.
OK, let's see, checklist for "Submitting code to REXX list"...
include code...tick
pour large helping of Dr. Marmadukes skin thickener into robust coffee....tick
imbibe large amount...tick
shields up...tick
deep breath...tick
Click Send............
Click Send............
CLICK SEND DAMMIT !.....(gulp) tick
Paul. (Although I may use another name for a while...)
/* Rexx to submit a job and then put the results to a dataset */
arg DSN
x=OUTTRAP("SUB.")
address TSO " SUBMIT " DSN
x=OUTTRAP("OFF")
do i = 1 TO SUB.0
parse var SUB.i 'JOB' JOBNAME '(' JOBID ')' STATUS
end i
SUBJOBNAME = strip(JOBNAME,B)
SUBJOBID = strip(JOBID,B)
SUBJOB = SUBJOBNAME ¦¦ "(" ¦¦ SUBJOBID ¦¦ ")"
say "SUBMITTED JOB =" SUBJOB
JOBDONE = 'NO'
do until JOBDONE = 'YES'
say; say 'OUTPUT FROM STATUS CMD...'
x=OUTTRAP("OUT.")
address TSO "STATUS" SUBJOB
x=OUTTRAP("OFF")
do i = 1 TO OUT.0
say OUT.i
parse var OUT.I 'JOB ' JOBNAME '(' JOBID ')' STATUS
STATUS = strip(STATUS)
if POS('ON OUTPUT QUEUE',STATUS) > 0
then JOBDONE = 'YES'
else ADDRESS ATTCHMVS "WAIT 00000100" /* Format hhmmssmm *
end i
end /* do until JOBDONE = 'YES' */
USRID = USERID()
PRINTDSN = "'"¦¦USRID¦¦".TEMP."¦¦JOBNAME¦¦"."¦¦JOBID¦¦"'"
ADDRESS TSO "OUTPUT " SUBJOB " PRINT("PRINTDSN") KEEP HOLD"
"Ramaswamy Saraswathy, Hari (Cognizant)" <Rama...@CHN.COGNIZANT.COM> on
27/01/2003 14:34:31
Please respond to TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
To: TSO-...@VM.MARIST.EDU
cc: (bcc: Paul A Redhead/CorpServ/qdot/au)
Subject: Getting RC of a job from rexx
************************************************************
Opinions contained in this e-mail do not necessarily reflect
the opinions of the Queensland Department of Main Roads,
Queensland Transport or National Transport Secretariat, or
endorsed organisations utilising the same infrastructure.
If you have received this electronic mail message in error,
please immediately notify the sender and delete the message
from your computer.
************************************************************
Craddock, Chris
There is no way to get RC information through the traditional
job submit interface. However, you can open an FTP connection
to the JES and then PUT jobs and GET their results. Its in the
books. Check it out.
Chris
> -----Original Message-----
> From: Dave Salt [mailto:ds...@HOTMAIL.COM]
> Sent: Monday, January 27, 2003 8:42 AM
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: Getting RC of a job from rexx
>
>
> In the scenario you describe, the REXX program could/should
> execute each
> "job" without having to generate and submit JCL. For example, it could
> allocate all the appropriate ddnames and directly call
> whatever program
> needs to be executed. It would then know the return code from
> each program
> it called and be able to decide whether to execute the next
> "job" (etc.).
>
> Presumably the REXX program itself is executing in batch, so another
> advantage of doing it like this is the user only has to
> submit and check the
> return code of a single job. If the REXX program is executing
> in foreground,
> you might want to reconsider the design. Having a foreground
> process wait on
> the execution of batch jobs defeats the whole purpose of
> submitting jobs in
> batch. HTH,
----------------------------------------------------------------------
Dave Salt
let the REXX program directly call whatever programs need to be executed.
That way, the REXX is always in control and always knows if the called
program executed successfully or not. FTP connection to JES? PUT and GET?
Having to trap the submitted job name, sleep, wake up to see if the batch
job has finished yet? Whoa; way too hard!
Dave Salt
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
----------------------------------------------------------------------
Robert Zenuk
I hope we are not attempting to solving a problem for someone that is just
new to the game and trying to force the solution into a REXX wrapper. When
the only tool someone knows how to use is a hammer, everything starts to look
like a nail...
Maybe we need a better description of what the original poster needs.
Many times (as already mentioned) this is a Job Scheduler issue. If a Job
Scheduler is not available, the IEBGENER approach with COND or IF processing
is commonly used. I have even seen (and written) a REXX "SUB" utility that
did slightly more than the IEBGENER approach. Spawning jobs almost always
creates headaches for the Job Scheduler (if one is available). If additional
auditing is needed, the REXX wrapper or "pre" and "post" logging step
approaches could be used. If this is just a historical tracking issue, SMF
could be used. Then we could get into the idea of a STC (possibly REXX) and
coordinated job/program design to create "work-in-progress" files that could
be used to make decisions. If we want to write authorized programs...
I think we all agree it doesn't make sense to run an interactive REXX EXEC
from TSO to monitor batch or wait on jobs. Tools like SDSF and others
already exist for the main reasons to check batch from TSO/ISPF.
The bottom-line is, what is the real problem trying to be solved?
Thanks,
Robert Zenuk
robz...@aol.com
Ramaswamy Saraswathy, Hari , Cognizant
Actually my aim is not to have a rexx routine just to get return code
from a job. I have a series of jobs (cycle) which I am planning to try
out in test region. I have to manually submit the programs and wait for
the return code from each job before submitting the next one. So I
thought of creating a rexx routine and I am not adamant that the
solution has to be necessarily through rexx!!
Anyways i have developed a routine(a prototype) which scans a submitted
job ,gets the return code, and submits the next job.
I am including the main code here. Please give your suggestion on this,
bcos I am a novice.
/*REXX
The purpose of this rexx routine is to submit a job depending on the
return code from a previously submitted job. The rexx can be run in
batch.
Work flow:
1. Submit the first job. For the example given here, the job is
present is a skel. The job is assigned a jobname and is submitted
from the rexx.
2. Check for the completion of job. This is done here using another
rexx routine(From CBT tape) which gives the information whether
the job is active or not.
3. Submit SDSF in batch. This job will find the last run first job and
prints the JESMSGLG to another dataset.
4. perform step 2.
5. Run an edit macro on the dataset obtained from last step. This
macro determines whether the "first job" abended or not. It puts
the information in a variable MACRC.
6. Submit the second job depending on the value in MACRC variable.
*/
address ispexec
"libdef ispslib dataset id('hlq.test.skels') uncond"
if rc \= 0 then do
say "s--> libdef failed for ispslib .rc="rc
say zerrlm
signal main_exit
end
address ispexec
"libdef ispfile dataset id('hlq.test.jcllib')"
if rc \= 0 then do
say "s--> libdef failed for ispfile .rc="rc
say zerrlm
signal main_exit
end
/*submit the first job*/
jbname = frstjob
jbname = strip(jbname)
skelvar = jclskl
skelvar = strip(skelvar)
outvar = jbjcl
outvar = strip(outvar)
call skel_call
address tso "submit 'hlq.test.jcllib(jbjcl)'"
/*wait for a moment*/
do i = 1 to 10000
end
/* check whether the job is completed. The rexx routine "JOBLIST"(from
CBT tape) is used here. The input given is the jobname. The output
from this routine is trapped. The element Y.2 will be empty when the
job is over.
*/
x = outtrap(y.)
call joblist jbname
x = outtrap(off)
do while y.2 \= 'Y.2'
y.2 = 'Y.2'
x = outtrap(y.)
call joblist jbname
x = outtrap(off)
end
/*Submit SDSF in batch. The job is present in a skel. This job finds the
last run "first job" and prints the JESMSGLG of this job to a dataset.
*/
skelvar = sdsfjcl
skelvar = strip(skelvar)
outvar = sdjcl
outvar = strip(outvar)
call skel_call
address tso "submit 'hlq.test.jcllib(sdjcl)'"
do i = 1 to 10000
end
drop y
/*Check whether the job is over*/
x = outtrap(y.)
call joblist sdsfjb
x = outtrap(off)
do while y.2 \= 'Y.2'
y.2 = 'Y.2'
x = outtrap(y.)
call joblist sdsfjb
x = outtrap(off)
end
/* Run edit macro on the output dataset produced. This macro gives the
status of the last run job. This value is populated in the variable
MACRC.
*/
address ispexec
macrc = 0
"vput ( macrc ) asis"
"edit dataset('hlq.test.text') macro(abndmac)"
"vget ( macrc ) asis"
/*Check the value in the variable MACRC. The macro is such that if there
is any abend in the first job run, it gives a MACRC of zero. Submit the
next job depending on that value.
*/
if macrc = 0 then do
say 'oops abend'
end
else do
/*Submit the next job.(edit the code)*/
say 'submit next job'
end
main_exit:
address ispexec
"libdef ispfile"
"libdef ispslib"
exit
skel_call:
address ispexec
"ftclose"
"ftopen"
if rc \= 0 then do
say "s--> ftopen failed for "skelvar".rc="rc
say zerrlm
signal main_exit
end
"ftincl "skelvar""
if rc \= 0 then do
say "s--> ftincl failed for "skelvar".rc="rc
say zerrlm
signal main_exit
end
"ftclose name("outvar")"
if rc \= 0 then do
say "s--> ftclose failed for "skelvar".rc="rc
say zerrlm
signal main_exit
end
return
Thanks,
Hari
Rupert Reynolds
Could you use OPC/A, or whatever, to do this for you? //*NET JCL
cards to build the dependencies? And I seem to remember NetView
being used for this as well, although we had a lot of extensions on
that product at the time.
> Actually my aim is not to have a rexx routine just to get return
> code
> from a job. I have a series of jobs (cycle) which I am planning to
> try
> out in test region.
Roo
Tina Hilton
any data from the user that affects the jcl being created. Instead of using
a rexx to submit multiple jobs, can't you just have one job with multiple
steps and have condition code checking on each step? If you need to set
symbolics, then make it a proc. Or, if jcl is dependent on something that
can only be resolved with a rexx, then have the rexx generate one job with
multiple steps.
I assume the "do 1 to 10000" is your way of making the rexx wait so the
first job will finish. Why not use use "sleep" USS function instead?
call syscalls('ON') /*enable USS-Calls*/
address syscall
"sleep" sleep_time /*sleep for ?? seconds*/
call syscalls 'OFF'
You'd have better control and use less CPU.
Tina
-----Original Message-----
From: Ramaswamy Saraswathy, Hari (Cognizant)
[mailto:Rama...@CHN.COGNIZANT.COM]
Sent: January 28, 2003 10:47 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: Getting RC of a job from rexx
Hi,
Actually my aim is not to have a rexx routine just to get return code
from a job. I have a series of jobs (cycle) which I am planning to try
Thanks,
Hari
----------------------------------------------------------------------
UHRIG, PETER
hi tina,
i read this with "uss"-syscalls with interrest.
where( manuals ) are this feature described ?
regards peter
Tina Hilton
Rexx). The USS commands like sleep are in the "Unix System Services Command
Reference" manual. The syscalls thing is in the "Using REXX and OS/390 UNIX
System Services" manual.
Tina
-----Original Message-----
From: UHRIG, PETER [mailto:PETER...@BHF.ING.COM]
Sent: January 29, 2003 7:38 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: Getting RC of a job from rexx
Schwarzbauer, Joe
This sounds just like you want a job scheduler.
You have a series of jobs that get submitted one after another
which doesn't proceed until you get satisfaction that each job
completed successfully (rc less than some target value).
I point this out because my contribution to your REXX was going
to be that you want some outer loop that does something like this:
set up a group of related stem variables where all the .n items
describe info about the jobs we are running and then run through
the list submitting and checking each one.
and then I realized: but this is what our job scheduler does,
this is just more limited, with fewer options and harder to use.
[I sent my REXX efforts by private email]
-----------------------------------------
CONFIDENTIALITY NOTICE: The information contained in this e-mail and attached document(s) may contain confidential information that is intended only for the addressee(s). If you are not the intended recipient, you are hereby advised that any disclosure, copying, distribution or the taking of any action in reliance upon the information is prohibited. If you have received this e-mail in error, please immediately notify the sender and delete it from your system.