[H390-MVS] job execution order

[[e-mail] [H390-MVS]]

With a single initiator active, I expected submitted
jobs to be run in order.

But that is not happening, as per below log, ie
SMPJOB08 is run before SMPJOB01.

Is there anything I can do to make the jobs run
in order? Do they all need to have the same
job name?

Thanks. Paul.



23:24:18 devinit 012 jcl/alljcl.jcl
23:24:18 HHCPN098I Device 0:0012 initialized
23:24:18 HHCPN011I Pausing SCRIPT file processing for 5 seconds...
23:24:18 $HASP100 SMPJOB00 ON READER1 PREP FOR RECEIVE
23:24:18 $HASP100 SMPJOB01 ON READER1 RECEIVE PRODUCT TAPE
23:24:18 $HASP100 SMPJOB02 ON READER1
23:24:18 $HASP100 SMPJOB03 ON READER1
23:24:18 $HASP100 SMPJOB04 ON READER1
23:24:18 $HASP100 SMPJOB05 ON READER1
23:24:18 $HASP100 SMPJOB06 ON READER1
23:24:18 $HASP100 SMPJOB07 ON READER1
23:24:18 $HASP100 SMPJOB08 ON READER1
23:24:18 $HASP104 SMPJOB08 ************************************************************
23:24:18 $HASP104 SMPJOB08 * AN IPL IS REQUIRED AFTER THIS JOB HAS COMPLETED!!! *
23:24:18 $HASP104 SMPJOB08 ************************************************************
23:24:18 $HASP373 SMPJOB00 STARTED - INIT 1 - CLASS A - SYS H158
23:24:19 HHCCD002I Writer thread 2 started: tid=00003310, pid=8636
23:24:20 $HASP395 SMPJOB00 ENDED
23:24:20 $HASP150 SMPJOB00 ON PRINTER1
23:24:20 $HASP373 SMPJOB08 STARTED - INIT 1 - CLASS A - SYS H158
23:24:20 $HASP160 PRINTER1 INACTIVE - CLASS=AJ
23:24:20 $HASP250 SMPJOB00 IS PURGED
23:24:20 $HASP395 SMPJOB08 ENDED
23:24:20 $HASP150 SMPJOB08 ON PRINTER1
23:24:20 $HASP373 SMPJOB01 STARTED - INIT 1 - CLASS A - SYS H158
23:24:20 $HASP160 PRINTER1 INACTIVE - CLASS=AJ
23:24:20 $HASP250 SMPJOB08 IS PURGED

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
Is there anything I can do to make the jobs run
in order? Do they all need to have the same
job name?

Note that on my normal system I submit my
jobs on class C, and even though the last
job is very small and a different job name,
it always runs last.

BFN. Paul.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
Is there anything I can do to make the jobs run
in order? Do they all need to have the same
job name?

Note that on my normal system I submit my
jobs on class C, and even though the last
job is very small and a different job name,
it always runs last.
BFN. Paul.

I depends on the operating system.

MVS 3.8j absolutely guaranteed that if you submitted
multiple JOBs in one JOB stream and if all had the
same CLASS and PRTY that they would start in order.
If only one INITiator of the CLASS, they would also
run in order.
We also used JOB-locks in the JCL so two JOBs
that conflict could not run together.
Some programmers used JOB-locks and condition
codes to maintain and insure order and handle
automatic order when a JOB stream was resubmitted.

Later, IBM had complaints that one long submit with
low JES2 priorities set would slow submits of TSO users.
Their severely broken fix was to allow multiple
JCL converters sub-tasks to run at a time with no
regard to input source. JOBs with much JCL or
PROCs took a long while to convert. A JOB with
just one PGM=IEFBR14 and one DD statement
flew through it's converter subtask to jump ahead.

I called IBM and they said that a new requirement
against users, as in me and us, was that each
JOB in a JOB stream should have a last step added
that releases the next JOB. I complained that then I
would have to give all users an authorized program
that could issue a release for any and all JOBs.
If any JOBs had the same JOBname, users would
need to have someway to automate releasing by
JES2 JOB number. Not an easy task.
Still bad, but a better bypass would be for the last
step of each JOB should submit the next so users
would not be able release every JOB on SPOOL.

I sent IBM a list of 57 IBM manuals that guaranteed
that JOB streams would be kept in order and
requested that the idiot way that they added subtasks
without accounting for input source be patched.
MVS system generation was over but other products
gens needed JOB streams to run in order.
They apparently didn't understand MVS so refused
to correct their botched code to account for input
source. They instead updated the 57 manuals.

My fix was to update JES2PARM to only run one
subtask for the converter. I believe that IBM had
set the default to two? It can be updated with an
operator command for testing.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com [H390-MVS]
My fix was to update JES2PARM to only run one
subtask for the converter. I believe that IBM had
set the default to two? It can be updated with an
operator command for testing.

I'm guessing the parameter is NUMINRS in
JES2PARM, but I was unable to find a JES2
operator command to change that for testing.

Can you please confirm what that is? Note
that it is MVS 3.7 that is running jobs out
of order.

Thanks. Paul.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
My fix was to update JES2PARM to only run one
subtask for the converter. I believe that IBM had
set the default to two? It can be updated with an
operator command for testing.

I'm guessing the parameter is NUMINRS in
JES2PARM, but I was unable to find a JES2
operator command to change that for testing.
Can you please confirm what that is? Note
that it is MVS 3.7 that is running jobs out
of order.
Thanks. Paul.

MVS 3.7 and MVS 3.8j do not run JOBs out of order.

Number of internal readers have nothing to do with it.

Your JCL runs JOBs out of order.

What CLASS= and PRTY= are on the JOB statements?

Do you have a user exit to scramble selection CLASS
or selection priority?

Post your JOB statements.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com [H390-MVS]
MVS 3.7 and MVS 3.8j do not run JOBs out of order.

Ok.

Post by ***@yahoo.com [H390-MVS]
What CLASS= and PRTY= are on the JOB statements?

CLASS A, not PRTY.

Post by ***@yahoo.com [H390-MVS]
Do you have a user exit to scramble selection CLASS
or selection priority?

Only if the MVS 3.7 starter system does so.

Post by ***@yahoo.com [H390-MVS]
Post your JOB statements.

I previously showed you job #1 and #8 being
submitted in correct order:

23:24:18 $HASP100 SMPJOB01 ON READER1 RECEIVE PRODUCT TAPE
...
23:24:18 $HASP100 SMPJOB08 ON READER1

But run in incorrect order:

23:24:20 $HASP373 SMPJOB08 STARTED - INIT 1 - CLASS A - SYS H158
...
23:24:20 $HASP373 SMPJOB01 STARTED - INIT 1 - CLASS A - SYS H158

Here are the job statements for both of those jobs:

//SMPJOB01 JOB (SYSGEN),'RECEIVE PRODUCT TAPE',
// CLASS=A,MSGLEVEL=(1,1),MSGCLASS=A
/*JOBPARM LINES=100


//SMPJOB08 JOB 'GENERATE ICKDSF',CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)


And thanks for the info in the other message
about converters.

BFN. Paul.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
MVS 3.7 and MVS 3.8j do not run JOBs out of order.

Ok.

Post by ***@yahoo.com [H390-MVS]
What CLASS= and PRTY= are on the JOB statements?

CLASS A, not PRTY.

- - - remainder snipped - - -

I posted a long explanation on how your JES2PARM is
lowering your selection priority because of:
/*JOBPARM LINES=100
but not all JOBs have that line so have different PRTY=

The post may show up someday?
I may be able to repost in a couple of weeks?

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
MVS 3.7 and MVS 3.8j do not run JOBs out of order.

Ok.

Post by ***@yahoo.com [H390-MVS]
What CLASS= and PRTY= are on the JOB statements?

CLASS A, not PRTY.

- - - most of remainder snipped - - -

You do indirectly specify a different PRTY.

Post by ***@yahoo.com.au [H390-MVS]
/*JOBPARM LINES=100

Your JES2PARMs have code for &RPRI, &RPRT, &XPRI,
and XLIN that changes the priority.

Perhaps your other system's JES2PARM was fixed?

You can fix by:

1. Fixing your JES2PARM

or

2. Removing /*JOBMARM or changing the
/*JOBPARM LINES=100 to the default estimated lines.

or

3. Adding either the same PRTY= or /*PRIORITY to
each JOB.

A description of the issue from a manual for
MVS V1 so old, but:

OS/VS2
HASP II Version 4

Systems System Programmer’s Guide
Program Number 370H-TX—001
VS2 SVS Release 1.7
GC27-6992-0
Page of GC27-6992-0
Revised September 15, 1976
By TNL GN27-1553
and
Revised May 30. 1975
By TNL GN25-0121

Page 66

1. The queueing priority is computed as:
priority=[&RPRI(n)+&XPRI(m)1/2

The subscript n is the smallest number for
t<&RPRT(n)

The subscript m is the smallest number for
o<&XLIN(m)

where t is the estimated execution time from the accounting
field of the JOB card or from the /*JOBPARM control card, and
o is the sum of the estimated output lines and cards from the
accounting field of the JOB card or from the /*JOBPARM
control card.

2. See the description of &RPRT(n).

3. See also the description of &XPRI(m).

[Joe Monk [e-mail] [H390-MVS]]

Paul,

WHY are you submitting all these jobs at once? They are SMP jobs and depend
on the DLIBs being updated correctly before the next step is executed...

Joe

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
MVS 3.7 and MVS 3.8j do not run JOBs out of order.

Ok.

Post by ***@yahoo.com [H390-MVS]
What CLASS= and PRTY= are on the JOB statements?

CLASS A, not PRTY.

Post by ***@yahoo.com [H390-MVS]
Do you have a user exit to scramble selection CLASS
or selection priority?

Only if the MVS 3.7 starter system does so.

Post by ***@yahoo.com [H390-MVS]
Post your JOB statements.

I previously showed you job #1 and #8 being
23:24:18 $HASP100 SMPJOB01 ON READER1 RECEIVE PRODUCT TAPE
....
23:24:18 $HASP100 SMPJOB08 ON READER1
23:24:20 $HASP373 SMPJOB08 STARTED - INIT 1 - CLASS A - SYS H158
....
23:24:20 $HASP373 SMPJOB01 STARTED - INIT 1 - CLASS A - SYS H158
//SMPJOB01 JOB (SYSGEN),'RECEIVE PRODUCT TAPE',
// CLASS=A,MSGLEVEL=(1,1),MSGCLASS=A
/*JOBPARM LINES=100
//SMPJOB08 JOB 'GENERATE ICKDSF',CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
And thanks for the info in the other message
about converters.
BFN. Paul.

[[e-mail] [H390-MVS]]

Post by Joe Monk ***@gmail.com [H390-MVS]
WHY are you submitting all these jobs at once?
They are SMP jobs and depend on the DLIBs
being updated correctly before the next step is executed...

I'm not doing that any more because of this
problem, but originally I thought it would be
simpler to do a "type smp*.jcl" to put all the
JCL into a single file so that just one devinit
was required in the .rc file, and then I would
insert appropriate delays to answer all the
questions and provide all the tapes.

In time I had hoped to premount all the tapes
and remove the expiration date from the
various files, so that there were no timing
issues and I could just trigger off the last job
completing to terminate.

But I don't think I can premount the tapes
anyway, because the product and ptf tapes
have the same volser.

BFN. Paul.

Post by Joe Monk ***@gmail.com [H390-MVS]
MVS 3.7 and MVS 3.8j do not run JOBs out of order.

Ok.

Post by Joe Monk ***@gmail.com [H390-MVS]
What CLASS= and PRTY= are on the JOB statements?

CLASS A, not PRTY.

Post by Joe Monk ***@gmail.com [H390-MVS]
Do you have a user exit to scramble selection CLASS
or selection priority?

Only if the MVS 3.7 starter system does so.

Post by Joe Monk ***@gmail.com [H390-MVS]
Post your JOB statements.

I previously showed you job #1 and #8 being
submitted in correct order:

23:24:18 $HASP100 SMPJOB01 ON READER1 RECEIVE PRODUCT TAPE
....
23:24:18 $HASP100 SMPJOB08 ON READER1

But run in incorrect order:

23:24:20 $HASP373 SMPJOB08 STARTED - INIT 1 - CLASS A - SYS H158
....
23:24:20 $HASP373 SMPJOB01 STARTED - INIT 1 - CLASS A - SYS H158

Here are the job statements for both of those jobs:

//SMPJOB01 JOB (SYSGEN),'RECEIVE PRODUCT TAPE',
// CLASS=A,MSGLEVEL=(1,1), MSGCLASS=A
/*JOBPARM LINES=100

//SMPJOB08 JOB 'GENERATE ICKDSF',CLASS=A,MSGCLASS=A, MSGLEVEL=(1,1)

And thanks for the info in the other message
about converters.

BFN. Paul.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
My fix was to update JES2PARM to only run one
subtask for the converter. I believe that IBM had
set the default to two? It can be updated with an
operator command for testing.

I'm guessing the parameter is NUMINRS in
JES2PARM, but I was unable to find a JES2
operator command to change that for testing.
Can you please confirm what that is? Note
that it is MVS 3.7 that is running jobs out
of order.
Thanks. Paul.

None of this applies to MVS 3.7 or MVS 3.8j, but:

Th current zOS JES2 manual says that it takes a
hot-start to change, which is a JES2PARM update,
$PJES2,ABEND, reply, S JES2,PARM=NOREQ,
and maybe another reply.

So it's more than just a single console command.
Blame my poor memory but I hot started JES2 often
on my production systems. Sometimes several times
per day so didn't consider it more than console
commands.

z/OS
JES2 Initialization and Tuning Reference
Version 2 Release 3
SA32-0992-30
CNVTNUM=nn|10
Specifies the number (1-25) of converter processors defined to JES2.
Considerations: Specifying 2 or more conversion processors alleviates
constraints in converter processing. However, when you define multiple
converter PCEs, or if you accept the default of ten converter PCEs, jobs will
not always be queued for execution in the order in which they were submitted.
Setting CNVTNUM=1 can be a way to run jobs in the order in which they
were submitted; either you must have a single member MAS to do this or if
you have a multi-member MAS, the system affinity of each job must be the
same. With CNVTNUM=1, the system can "hang" depending on the
characteristics of the job stream. See z/OS JES2 Initialization and Tuning Guide
for more information on job queuing and how to control job execution
sequence.
Modification: Hot start.

- - - - - - - - - - -

Wow, the CNVTNUM=1 is now documented.

['[e-mail]' [e-mail] [H390-MVS]]

On Monday, February 19, 2018, 11:34:06 PM GMT+11, ***@yahoo.com.au [H390-MVS] <H390-***@yahoogroups.com> wrote:
 

Is there anything I can do to make the jobs run
in order?

______________________________
Get each job to submit the next?
Cheers,Greg

[Joe Monk [e-mail] [H390-MVS]]

Please heed the notices:

*These are serial steps, since the output of each is required before the
next may begin.*

If you just absolutely must submit them all at once, do so with
TYPRUN=HOLD. Then use $a'jobname' to release them.

Joe

Post by ***@yahoo.com.au [H390-MVS]
With a single initiator active, I expected submitted
jobs to be run in order.
But that is not happening, as per below log, ie
SMPJOB08 is run before SMPJOB01.
Is there anything I can do to make the jobs run
in order? Do they all need to have the same
job name?
Thanks. Paul.
23:24:18 devinit 012 jcl/alljcl.jcl
23:24:18 HHCPN098I Device 0:0012 initialized
23:24:18 HHCPN011I Pausing SCRIPT file processing for 5 seconds...
23:24:18 $HASP100 SMPJOB00 ON READER1 PREP FOR RECEIVE
23:24:18 $HASP100 SMPJOB01 ON READER1 RECEIVE PRODUCT TAPE
23:24:18 $HASP100 SMPJOB02 ON READER1
23:24:18 $HASP100 SMPJOB03 ON READER1
23:24:18 $HASP100 SMPJOB04 ON READER1
23:24:18 $HASP100 SMPJOB05 ON READER1
23:24:18 $HASP100 SMPJOB06 ON READER1
23:24:18 $HASP100 SMPJOB07 ON READER1
23:24:18 $HASP100 SMPJOB08 ON READER1
23:24:18 $HASP104 SMPJOB08 ******************************
******************************
23:24:18 $HASP104 SMPJOB08 * AN IPL IS REQUIRED AFTER THIS JOB HAS
COMPLETED!!! *
23:24:18 $HASP104 SMPJOB08 ******************************
******************************
23:24:18 $HASP373 SMPJOB00 STARTED - INIT 1 - CLASS A - SYS H158
23:24:19 HHCCD002I Writer thread 2 started: tid=00003310, pid=8636
23:24:20 $HASP395 SMPJOB00 ENDED
23:24:20 $HASP150 SMPJOB00 ON PRINTER1
23:24:20 $HASP373 SMPJOB08 STARTED - INIT 1 - CLASS A - SYS H158
23:24:20 $HASP160 PRINTER1 INACTIVE - CLASS=AJ
23:24:20 $HASP250 SMPJOB00 IS PURGED
23:24:20 $HASP395 SMPJOB08 ENDED
23:24:20 $HASP150 SMPJOB08 ON PRINTER1
23:24:20 $HASP373 SMPJOB01 STARTED - INIT 1 - CLASS A - SYS H158
23:24:20 $HASP160 PRINTER1 INACTIVE - CLASS=AJ
23:24:20 $HASP250 SMPJOB08 IS PURGED