View previous topic :: View next topic
|
Author |
Message |
Anu R
New User
Joined: 09 Apr 2008 Posts: 18 Location: India
|
|
|
|
Hi,
I have 2 jobs in my JCL member.The second job shld execute only after the first jobs execution is over.How can I do this?
EG:
//Job1....
//Step1
//step2
//Job2
//Step3
//step4
Both the jobs are in a single PDS member.On submition I want the second job to be executed only after the first job is over.
Please advise |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
it all depends on Your system setup
one solution could be to use the same execution class
but that will work only if there are classes processed by only one initiator
the best thing is to ask Your support
or ( but there are jcl changes to make )
add a step to the first job to submit the second one
( issue discussed many times search the forums on how to do it )
or use a scheduler
or ( JES3 ONLY ) use DJC ( dependent job control ) "//*NET statements " |
|
Back to top |
|
|
Anu R
New User
Joined: 09 Apr 2008 Posts: 18 Location: India
|
|
|
|
Erico,
Thank you.But I searched the forum and could not find matching results on how to submit a job from another job...I will be glad if u culd help me with this.. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
Back to top |
|
|
karthikr44
Active User
Joined: 25 Aug 2007 Posts: 235 Location: Chennai
|
|
|
|
Hi Anu,
The following JCL will submit another JCl
//C26AP1 JOB (040T,1531),'APL RGN BLD1',
// NOTIFY=C334233,
// MSGCLASS=X,
// CLASS=A
//JSTP0010 EXEC PGM=SORT
.
.
.
.
.
//*
//JSTP0020 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DATA,DLM='??'
//C26AP2 JOB (040T,1531),'APL RGN BLD2',
// NOTIFY=C03526,
// MSGCLASS=X,
// CLASS=A
//*
//JSTP0010 EXEC PGM=SORT
.
.
.
//*
??
//SYSUT2 DD SYSOUT=(*,INTRDR)
//SYSIN DD DUMMY
//*
regards
R KARTHIK |
|
Back to top |
|
|
Anu R
New User
Joined: 09 Apr 2008 Posts: 18 Location: India
|
|
|
|
Thank you.But in the pointer ways o submitting a job which is in a different dataset is discussed.Here both the jobs reside in the same member.I m planning to put the second job on hold by providing TYPRUN=HOLD in the jobcard.Then on completion of the first job I wuld have to release it.For this i have to include a step in my first job which will release the second job which is on hold in spool. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
put Your second job as sysin dd data to the iebgener step |
|
Back to top |
|
|
UmeySan
Active Member
Joined: 22 Aug 2006 Posts: 771 Location: Germany
|
|
|
|
Hi Anu R !
For heavans sake, why so complicated. Two jobs = two member.
second is submitted by last step of first job via internal reader.
One job with two steps using a proc. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
Indeed, why so complicated?
Just give the two jobs the same jobcard in the PDS member. When you submit the member, regardless of how many initiators are available, the second job will be seen as a duplicate and will not be released for execution until the first has completed.
Regards,
Garry. |
|
Back to top |
|
|
jsathishbabu84
New User
Joined: 07 Jun 2007 Posts: 22 Location: India
|
|
Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006 Posts: 1041 Location: Richmond, Virginia
|
|
|
|
Garry -
I'm not sure you can ensure that the first sub'd will start executing first. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
Phil,
Quote: |
I'm not sure you can ensure that the first sub'd will start executing first. |
I don't see why not, the first job in the PDS member hits JES first and will be ahead of the second in the queue. JES is reading one JCL card at a time.
The jobs will be executed in the order submitted unless both are queued and someone intervenes manually to change the order, or unless the second job has a higher PRTY= coded. Both jobs should, of course, be submitted with the same CLASS= parameter.
I've used this technique reliably to submit jobs to run in order where I was unable to use scheduling. Of course, if the first jobs fails, there's nothing to stop the second from running.
Garry |
|
Back to top |
|
|
stodolas
Active Member
Joined: 13 Jun 2007 Posts: 632 Location: Wisconsin
|
|
|
|
I'll chime in and say I've seen the same results as Garry and used it with success when running a test job stream before sending to scheduling. |
|
Back to top |
|
|
UmeySan
Active Member
Joined: 22 Aug 2006 Posts: 771 Location: Germany
|
|
|
|
I aggree with Garry.
Remeber 40 years ago. We had no TSO-Member. We had a CardReader for submitting Jobs. Likely the same as today. Theses old cards are now stored in a member. But processed line after line. That's why we call them JCL-Cards still today. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
The second job shld execute only after the first jobs execution is over |
Please search the forum for "internal reader" or "intrdr". Adding an IEBGENER as the last step in job1 can submit job2.
Quote: |
The jobs will be executed in the order submitted unless both are queued and someone intervenes manually to change the order, or unless the second job has a higher PRTY= coded. |
Not necessarily true. It is possible for jobs with the same jobname to execute in a sequence other than the order submitted. It has caught many people unaware as they had always seen the jobs executed in the order submitted.
One other consideraton is that if job2 should only run if job1 successfully completes. If both are submitted to run serially, job2 will run regardless. Using a "last step" in job1 that conditionally submits job2 will provide for this. |
|
Back to top |
|
|
stodolas
Active Member
Joined: 13 Jun 2007 Posts: 632 Location: Wisconsin
|
|
|
|
Good to know. I really don't do much COBOL/JCL anymore. I switched to a Java web developer long ago, but like to keep the knowledge. We do run our Websphere instance on z/OS and have to interface with the CICS programmers often enough that it helps. |
|
Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006 Posts: 1041 Location: Richmond, Virginia
|
|
|
|
Suppose the first initiator grabs the first job, but then the next time slice goes to the 2nd init, which grabs job2 and has enough time to actually initiate it. Then job2 will run first. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
I'd be interested to hear details of where two jobs, with identical jobcards and submitted as a single JCL stream, execute in a sequence other than that in which submitted. I haven't come across this in 36years.
Quote: |
Suppose the first initiator grabs the first job, but then the next time slice goes to the 2nd init, which grabs job2 and has enough time to actually initiate it. Then job2 will run first. |
When an initiator "grabs" the first job, the second (and subsequent) will be marked "DUP" on the queue while that is dispatched. It doesn't matter how many initiators are active for the class, the second job will not execute as long as the first is executing. Time-slicing doesn't enter into it.
If there are three (or more) jobs of the same name queued with equal priority in the same initiator class, they will move sequentially up to the queue and only one job of that name can be executing at a time.
Garry. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
everything depends on the jes2 setup
there are some parameters which specify the number of service tasks
IIRC they are -
number of purge processors
number of converter tasks
... other ( irrelevant to the thread
the default ,always IIRC, for the converter tasks is 2
since a job gets into the scheduling/execution queue after conversion
that' s when You face the problem
if in a single submit You have two jobs and the first one is a bit complex
and the second is a small one
the second job will be executed before the first one
seen it !
as a general postulate,
when the number of converter tasks is greater than one and many jobs
are submitted with the same command,
the execution order is unpredictable, because it depends on the time taken by the converter to process each job |
|
Back to top |
|
|
|