There's a job (let's call it AAAA) which creates an output on the JES2 spool to print, and submits another job (let's call it BBBB), which also creates an output to print. Both outputs are destined for the same printer. The first job assigns the priority 152 to the output AAAA via the OUTPUT JES2 statement. The second job doesn't assign a priority to output BBBB, thus it gets the default value from the OUTPRTY JES2 init statement, which can vary based on the size of the output, but can never be higher than 144.
The owner of the job wants and expects that the first output AAAA will printed before the output BBBB, because of the higher priority (and perhaps even because it gets created first, via the first job AAAA).
But what happens is exactly the opposite, the second output BBBB gets printed before AAAA, and this fact of course can be seen at the printer, and it is also evidenced by the $HASP150 messages in the syslog.
After a little investigation I realized that there's a parameter on the OUTDEF JES2 init statement, called PRTYOUT, which controls whether JES2 should honor the priority of the outputs or not. It is set to YES, so this should not be a problem.
At this point I'm stumped as to why it happens.
Is there any other option or condition which would cause JES2 to not honor the priority?
Here are some displays which show the priority of the two outputs, the PRTYOUT and OUTPRTY setting, and the $HASP150 messages:
Hm, I'm thinking, could the problem be that the output for the first job (AAAA) is created in the first step of that job, and then a later step submits the second job (BBBB), and then are more steps that do some other stuff. So the job BBBB could finish before job AAAA does.
When does an output go to the output queue from a jobstep? When the step finishes or when the job finishes? If the latter, the problem could be that the job BBBB finishes first, so its output gets picked up by the printer first, and the priority doesn't matter, because there's no output AAAA at that time yet.
I checked the syslog, and indeed, job BBBB finished just a wee bit earlier (4 ms) than AAAA:
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
I believe it is not released for printing until the job ends unless you specify a parameter on the DD record of the SYSOUT. I cannot remember what that parameter is, though.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
The order in which output queued through JES2 hits printers is far more complex than you think.
First, by using output class definitions and JCL, you can persuade JES2 to print at least some output before a job completes. The major exceptions are the JESMSGLG, JESJCL and JESYSMSG data sets. These data sets cannot be printed until after the job completes.
Second, output combined with the three system data sets mentioned in the last paragraph is not immediately available for printing when the job ends execution. After a job completes execution the job, as an entity, enters JES2 "output" processing. This processing, which is rather more complex than it seems it should be, takes any output that was not queued for hard copy while the job executed and adds the output for hard copy. Most of the time this is nearly invisibly fast, but it can be delayed for any number of reasons.
After output processing, the job is placed in the rather nebulous "hard copy" queue. It stays there until all the job output has been printed or otherwise disposed of.
The actual priority assigned to the output is a complex combination of the job priority at the time the output is queued for printing and the volume of output as determined by the JES2 initialization parameters. This is discussed in more detail than I can replicate here in JES2 Initialization and Tuning Guide for your z/OS release. You should examine this publication as well as the MVS JCL Reference publication for more details.
I, personally, in the 1970s, submitted a PMR, along with a proposed code change, so this priority matched the JCL manual at the time. This resulted in a PTF that lasted one update cycle that incorporated my code change. The PTF was PE-e and my code was removed. After some thought at the time, I concluded the NJE (this was when NJE was a separate product from JES2, though it incorporated all of JES2) code that I thought was in error was "correct," and the JCL manual needed a doc update.
I believe it is not released for printing until the job ends unless you specify a parameter on the DD record of the SYSOUT. I cannot remember what that parameter is, though.
I went and looked through the parameters for the DD statement, and found it. It's the SPIN parameter. If I specify SPIN=UNALLOC, it should be available for output processing when the dataset is unallocated, in our case, at the end of the step. And it works, at least in our test setup. From the result it looks like it will solve our problem, but we will only know for sure when it's implemented in production.
The order in which output queued through JES2 hits printers is far more complex than you think.
First, by using output class definitions and JCL, you can persuade JES2 to print at least some output before a job completes. The major exceptions are the JESMSGLG, JESJCL and JESYSMSG data sets. These data sets cannot be printed until after the job completes.
Second, output combined with the three system data sets mentioned in the last paragraph is not immediately available for printing when the job ends execution. After a job completes execution the job, as an entity, enters JES2 "output" processing. This processing, which is rather more complex than it seems it should be, takes any output that was not queued for hard copy while the job executed and adds the output for hard copy. Most of the time this is nearly invisibly fast, but it can be delayed for any number of reasons.
After output processing, the job is placed in the rather nebulous "hard copy" queue. It stays there until all the job output has been printed or otherwise disposed of.
The actual priority assigned to the output is a complex combination of the job priority at the time the output is queued for printing and the volume of output as determined by the JES2 initialization parameters. This is discussed in more detail than I can replicate here in JES2 Initialization and Tuning Guide for your z/OS release. You should examine this publication as well as the MVS JCL Reference publication for more details.
I, personally, in the 1970s, submitted a PMR, along with a proposed code change, so this priority matched the JCL manual at the time. This resulted in a PTF that lasted one update cycle that incorporated my code change. The PTF was PE-e and my code was removed. After some thought at the time, I concluded the NJE (this was when NJE was a separate product from JES2, though it incorporated all of JES2) code that I thought was in error was "correct," and the JCL manual needed a doc update.
Thanks for the insight, it is really not simple.
It looks like it was not even a priority related problem afterall, but more related to when outputs get queued to output processing. Hopefully the SPIN=UNALLOC will solve our problem.
If it does resolve the problem then could you please confirm it with a post later on?
As it stands, this thread is in the position of "maybe" which does not help other people later - they want to know if it did or didn't.
Thank you.
Sure, I will update. It may take a week or more though, due to certain processes which dictate how you can introduce a change into this environment. I will try not to forget it.
Now I can confirm that the SPIN=UNALLOC parameter really did solve the problem.
To sum up: my premise was wrong, my problem had nothing to do with output priority, simply because the two outputs were never on the output queue at the same time. The problem was that even though job B was submitted by job A, but job B finished before job A, so its output was printer before job A's. The SPIN=UNALLOC parameter on job A's output allowed it to go to the output queue as soon as that jobstep finished, guaranteeing that it gets there before job B's output, because that step is earlier than which submits job B.