Page 1 of 1

job steps execution disorder

PostPosted: Thu Sep 27, 2018 2:10 pm
by bahareh
Hi!
I have written a JCL which has 2 steps. in the first step, a procedure is called and executed:
//STEP1   EXEC ACBJBAOB,            
//        TABL2=IBMUSER.TEST.ISPTABL
//SYSUDUMP DD  SYSOUT=*              
//SYSTSIN  DD *                      
PROFILE PREFIX(SYS1)                
ISPSTART CMD(ACBQBAS1 ALTER +        
SCDS(DFSMS.SCDS) +                  
STCNAME(STGCLS1) +                  
GURNTSPC(Y) +                        
)  

In the second step, a program is called and executed:
//step2 EXEC PGM=IEFBR14                  
//C1 COMMAND 'SETSMS SCDS(SYS1.DFSMS.SCDS)'
 

When I submit this job, Step 2 is executed sooner. But I need it to be executed after step 1 finished.
can anyone help me why this happens?

I am new to JCL, if my question is easy.

Thanks.

Re: job steps execution disorder

PostPosted: Thu Sep 27, 2018 2:19 pm
by NicC
Step 2 does not run before the first step- look at the step start/stop times.

The command statement is nothing to do with your IEFBR14. IEFBR14 does noting but the DD statements are actioned so you can allocate/delete data sets. You have a COMMAND statement. I am not going to check the manuals for you but I suspect that the COMMAND is actioned either at job submission time or at job start time.

Please use the code tags when posting code and data. Samples exist in the forum. Look for recent posts by Expat.

Re: job steps execution disorder

PostPosted: Thu Sep 27, 2018 5:24 pm
by Robert Sample
The manual will tell you that COMMAND statements are NOT executed in step order, but rather when the job starts executing. Hence the behavior you are seeing is normal and expected.

Re: job steps execution disorder

PostPosted: Fri Sep 28, 2018 12:26 am
by Robert Sample
I checked the manual (MVS JCL Reference) and it says:
Because the system usually executes an in-stream command as soon as it is converted, execution of the command will not be synchronized with the execution of any job or job step in the input stream. To synchronize a command with job processing, tell the operator the commands you want entered and when they should be issued, and let the operator enter them from the console.

Re: job steps execution disorder

PostPosted: Fri Sep 28, 2018 8:15 am
by steve-myers
Mr.Sample and NicC are both correct.

MVS Job Flow

Jobs are processed in z/OS by both JESx subsystems in the same way. For convenience I am going to use JES2 terminology, but JES3 works basically the same, though it uses different terms.

When you submit a batch job, it is not instantly and immediately placed into a queue of jobs ready to execute. Rather it is placed into a sort of hidden queue called the "conversion" queue. "Conversion" analyzes the JCL. Its primary output, in addition to messages for your consumption, is a hidden internal (to JES) data set containing "internal text," which is your JCL transformed into a binary format that is easier for an initiator to process. Your operator commands - if the job class is authorized to submit them - are submitted to MVS for processing while your job is being "converted" and are then, for all intents and purposes, discarded. After your job has been "converted," it is added to the regular execution queues.

For your purposes, there are a couple of flaws in this processing flow.
  • In a system running Multi-access SPOOL, e.g., the JES2 checkpoint and SPOOL volumes are shared by 2 or more systems, the job may be "converted" on a different system than the system where the job will run. In other words, the command will execute on a different system than used to run the job. You can force JES2 to run conversion and execution on the same system by using the /*JOBPARM SYSAFF=system ID JECL control statement as described in the JCL manual, but this is discouraged.
  • In many real world production systems job execution may be delayed for an extended period after JCL conversion completes.
  • As both Mr. Sample and NicC have mentioned, the command is executed before your job runs rather than while your job runs.