And one of the subtle, easily overlooked points made in the first section of that JES2 documentation about "The JES2 job queue", is "All jobs are queued by job class, priority, and the order in which they finished conversion."
Notice it does not say anything about the order in which they were submitted, only the order they finish conversion. In the usual case of multiple JES2 converters , identical jobs submitted at the same time are likely to run in different converter tasks and could complete in a different order than submitted just from random timing differences in the running of the two tasks or based on the complexity of the jobs. If a very complex job and a simple job are submitted at the same time, or even if the more complex job is submitted barely ahead of the simpler job, the more complex job will likely take longer in the conversion process and get queued behind and run after the simpler job. In the absence of some kind of Job Scheduler support, it used to be the only way to guarantee that Job B ran after Job A was to either have the last step of Job A submit Job B using an Internal Reader, or wait until Job A completes (or has started execution and holds a resource Job B needs) before submitting Job B. JC Ewing On 4/14/20 3:33 PM, ITschak Mugzach wrote: > Complex answer. See this link (for 2.2): > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.hasa300/has2v5_Job_selection_and_execution.htm > ITschak Mugzach > *|** IronSphere Platform* *|* *Information Security Continuous Monitoring > for z/OS, x/Linux & IBM I **| z/VM comming son * > > > > > On Tue, Apr 14, 2020 at 11:00 PM Farley, Peter x23353 < > [email protected]> wrote: > >> I have been confused by this behavior in z/OS for a long time now. Can >> anyone explain to me how JES2 selects which job will be executed next from >> a set of identically-named jobs at the same priority level in the same job >> class? >> >> Recently observed behavior has been all over the map. E.G., today I >> submitted four jobs from TSO all with the same job name. Each was assigned >> a sequential job number, like this: >> >> TSOUSERM 1001 >> TSOUSERM 1002 >> TSOUSERM 1003 >> TSOUSERM 1004 >> >> Observed execution order was: >> >> TSOUSERM 1004 >> TSOUSERM 1002 >> TSOUSERM 1003 >> TSOUSERM 1001 >> >> On a different day I saw that the order executed was third, second, >> fourth, first. >> >> These jobs execute the same number of PROC's and programs in the same >> order just using a different initial input file name. They are identical >> in every way except for the input file name. >> >> Why are these jobs not executed in the order submitted? That I guess is >> what I really don't understand. Fortunately I don't *need* them to execute >> in a particular order, I just don't understand why they do NOT execute in >> submission order. >> >> TIA for curing my ignorance. >> >> Peter >> -- >> ... -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
