IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

JES2 doesn't honor the priority of the output for printing


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Aron Lendvai

New User


Joined: 01 Aug 2007
Posts: 6
Location: Hungary

PostPosted: Thu Jun 29, 2017 1:41 pm
Reply with quote

Hello,

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:

Code:

MVSV      2017174  14:51:05.42            -$DOUTDEF                                                       
MVSV      2017174  14:51:05.42             $HASP836 OUTDEF                                                 
                                           $HASP836 OUTDEF  COPIES=255,DMNDSET=YES,JOENUM=180000,         
                                           $HASP836         JOEFREE=157971,JOEWARN=80,OUTTIME=CREATE,     
                                           $HASP836         PRTYLOW=0,PRTYHIGH=255,PRTYOUT=YES,PRYORATE=0,
                                           $HASP836         SEGLIM=100,STDFORM=STD,USERSET=YES,           
                                           $HASP836         JOERBLDQ=NONE,DSLIMIT=10M,SAPI_OPT=NO,WS_OPT=NO
MVSV      2017174  14:53:53.67            -$DOUTPRTY                                                       
MVSV      2017174  14:53:53.67             $HASP848 OUTPRTY(1)  PRIORITY=144,RECORD=2000,PAGE=50           
MVSV      2017174  14:53:53.67             $HASP848 OUTPRTY(2)  PRIORITY=128,RECORD=5000,PAGE=100         
MVSV      2017174  14:53:53.67             $HASP848 OUTPRTY(3)  PRIORITY=112,RECORD=15000,PAGE=300         
MVSV      2017174  14:53:53.67             $HASP848 OUTPRTY(4)  PRIORITY=96,RECORD=16777215,PAGE=16777215 
MVSV      2017174  14:53:53.67             $HASP848 OUTPRTY(5)  PRIORITY=80,RECORD=16777215,PAGE=16777215 
MVSV      2017174  14:53:53.67             $HASP848 OUTPRTY(6)  PRIORITY=64,RECORD=16777215,PAGE=16777215 
MVSV      2017174  14:53:53.67             $HASP848 OUTPRTY(7)  PRIORITY=48,RECORD=16777215,PAGE=16777215 
MVSV      2017174  14:53:53.67             $HASP848 OUTPRTY(8)  PRIORITY=32,RECORD=16777215,PAGE=16777215 
MVSV      2017174  14:53:53.67             $HASP848 OUTPRTY(9)  PRIORITY=16,RECORD=16777215,PAGE=16777215 
MVSV      2017174  15:35:31.24            -$DOJ(21836),OUTGRP=2.1.1,LONG
MVSV      2017174  15:35:31.24  JOB21836   $HASP686 OUTPUT(AAAA)                                         
                                           $HASP686 OUTPUT(AAAA)   OUTGRP=2.1.1,STATUS=(ON PRT19/MVSV), 
                                           $HASP686                   BURST=NO,FCB=****,FLASH=****,         
                                           $HASP686                   FORMS=PILD,HOLD=(NONE),OFFS=(),       
                                           $HASP686                   OUTDISP=WRITE,PRIORITY=152,           
                                           $HASP686                   PRMODE=LINE,QUEUE=H,                 
                                           $HASP686                   RECORDS=(149 OF 149),ROUTECDE=LOCAL, 
                                           $HASP686                   SECLABEL=,TSOAVAIL=NO,UCS=****,       
                                           $HASP686                   USERID=,WRITER=,REBUILD=NO,   
                                           $HASP686                   CRTIME=(2017.174,14:35:01)           
MVSV      2017174  15:35:33.71            -$DOJ(21839),OUTGRP=2.1.1,LONG                                   
MVSV      2017174  15:35:34.18  JOB21839   $HASP686 OUTPUT(BBBB)                                         
                                           $HASP686 OUTPUT(BBBB)   OUTGRP=2.1.1,STATUS=(ON PRT19/MVSV), 
                                           $HASP686                   BURST=NO,FCB=****,FLASH=****,         
                                           $HASP686                   FORMS=PILD,HOLD=(NONE),OFFS=(),       
                                           $HASP686                   OUTDISP=WRITE,PRIORITY=128,           
                                           $HASP686                   PRMODE=LINE,QUEUE=H,                 
                                           $HASP686                   RECORDS=(2400 OF 2400),ROUTECDE=LOCAL,
                                           $HASP686                   SECLABEL=,TSOAVAIL=NO,UCS=****,       
                                           $HASP686                   USERID=,WRITER=,REBUILD=NO,   
                                           $HASP686                   CRTIME=(2017.174,14:35:01)           

MVSV     2017174 15:37:29.80 JOB21839 00000281  $HASP150 BBBB  OUTGRP=2.1.1 ON PRT19    2,400 (2,400) RECORDS
MVSV     2017174 15:38:21.06 JOB21836 00000281  $HASP150 AAAA  OUTGRP=2.1.1 ON PRT19    149 (149) RECORDS
Back to top
View user's profile Send private message
Aron Lendvai

New User


Joined: 01 Aug 2007
Posts: 6
Location: Hungary

PostPosted: Thu Jun 29, 2017 3:00 pm
Reply with quote

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:

Code:

17174 15:35:02.68 JOB21839 00000291  $HASP395 BBBB  ENDED
17174 15:35:02.72 JOB21836 00000291  $HASP395 AAAA  ENDED
Back to top
View user's profile Send private message
Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK

PostPosted: Thu Jun 29, 2017 4:16 pm
Reply with quote

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.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Thu Jun 29, 2017 4:49 pm
Reply with quote

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.
Back to top
View user's profile Send private message
Aron Lendvai

New User


Joined: 01 Aug 2007
Posts: 6
Location: Hungary

PostPosted: Thu Jun 29, 2017 5:02 pm
Reply with quote

Nic Clouston wrote:
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.

Great tip, thank you Nic!
Back to top
View user's profile Send private message
Aron Lendvai

New User


Joined: 01 Aug 2007
Posts: 6
Location: Hungary

PostPosted: Thu Jun 29, 2017 5:25 pm
Reply with quote

steve-myers wrote:
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.
Back to top
View user's profile Send private message
Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK

PostPosted: Thu Jun 29, 2017 5:53 pm
Reply with quote

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.
Back to top
View user's profile Send private message
Aron Lendvai

New User


Joined: 01 Aug 2007
Posts: 6
Location: Hungary

PostPosted: Thu Jun 29, 2017 7:15 pm
Reply with quote

Nic Clouston wrote:
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.
Back to top
View user's profile Send private message
Aron Lendvai

New User


Joined: 01 Aug 2007
Posts: 6
Location: Hungary

PostPosted: Fri Jul 28, 2017 12:40 pm
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts Sortjoin and Search for a String and ... DFSORT/ICETOOL 1
No new posts Joinkeys - 5 output files DFSORT/ICETOOL 7
No new posts Build a record in output file and rep... DFSORT/ICETOOL 11
No new posts XDC SDSF output to temp dataset CLIST & REXX 4
No new posts XL C Trace Preprocessor Output All Other Mainframe Topics 3
Search our Forums:

Back to Top