Mr.Sample and NicC are both correct.
MVS Job FlowJobs 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.