I will begin by stating that the title above - JES2 Queue Management - is an overstatement of the intent of this page. I am adding this page, which I expect will be linked to from several points in my site, to address the singular problem of the JES2 Queue filling to its maximum capacity when MVS 3.8j is utilized by those who are inexperienced in the details of managing a system as complex as MVS. MVS, in a real world scenario, required a staff of operations personnel, at the very minimum a single operator (which would have been multiple people in order to cover a 24 hour time period), who had the responsibility of monitoring the MVS system, and all of its subsystems, and circumventing problems before they reached the level of impacting any of the users of the system. These operations personnel, who were not considered users of the system themselves, had a full time job of ensuring that the system continued to operate for the many users who were submitting jobs from terminals or workstations, either locally or distant from the physical computer. Running MVS under Hercules, you are both the user of the system and the operator. There are tasks that must be completed on the operations side of the equation or the system will come to a grinding halt. Once the system has reached that point, it is almost certainly a bigger task to bring the system back into a normal operational status.
Which brings us to the main topic of this particular page: JES2. First I want to include some statements broadly describing JES2 [extracted from the IBM manual: JES2 Introduction GC28-1794]:
What is a JES? MVS uses a job entry subsystem (JES) to receive jobs into the operating system, schedule them for processing by MVS, and to control their output processing. JES2 is descended from HASP (Houston automatic spooling priority). HASP is defined as: a computer program that provides supplementary job management, data management, and task management functions such as: scheduling, control of job flow, and spooling. HASP remains within JES2 as the prefix of most module names and the prefix of all messages sent by JES2 to the operator.
What is Spooling? Simultaneous peripheral operations online (spool) has several meanings as used in this book and throughout JES2 documentation. Spooling is a process by which the system manipulates its work. This includes:
* Using storage on direct access storage devices (DASD) as a buffer storage to reduce processing delays when transferring data between peripheral equipment and a program to be run.
* Reading and writing input and output streams on an intermediate device for later processing or output.
* Performing an operation such as printing while the computer is busy with other work.
Spool also refers to the direct access device that contains the spool datasets.
Spooling is critical to maintain performance in the MVS-JES2 environment. As noted previously, spooling provides simultaneous processing and a temporary storage area for work that is not yet completed. Once JES2 reads a job into the system, JES2 writes the job, its JCL, its control statements, and its data to a spool data set until further processing can occur.
From these definitions, it is apparent that JES2 is the most critical element of the MVS system, and without its resources operating correctly, the operation of MVS itself will grind to a halt. A frequent query posted to the Hercules forums goes something like this:
I got a message on the console: $HASP050 JES2 RESOURCE SHORTAGE. What do I do?
Before you can understand how to fix the problem, you need some basic facts on the JES2 resources. If you are using a system generated using my instructions that has not been subsequently modified, here are the pertinent facts about the JES2 system on your MVS:
you have a single DASD volume, VOL=SER=SPOOL1, which is a 3350 type DASD.
On the SPOOL1 volume there is a single dataset: SYS1.HASPACE. The dataset occupies 16,620 tracks; the remaining tracks on the volume are allocated to: 1 track for the volume label, 1 track for the Volume Table of Contents, and 28 tracks that are left open because the allocation algorithm for SPOOL space cannot use those leftover odd tracks for the SYS1.HASPACE dataset.
There is also a checkpoint dataset - SYS1.HASPCKPT - on the volume MVS000, where JES2 maintains information about the SYS1.HASPACE dataset. Both the SYS1.HASPACE and SYS1.HASPCKPT datasets are allocated in the job SYSGEN02.
JES2 parameters that most significantly affect queue capacity: MAXJOBS=128, MINJOES=100, NUMCMBS=256, NUMJOES=1024 [increased from 512 on 18 September 2020], NUMDA=2 [increased from 1 on 18 September 2020]. These parameters, along with many other parameters that define and control the operation of JES2, are also set up in the job SYSGEN02. The parameters are stored in SYS1.PARMLIB, in the member JES2PM00.
The JES2 parameters listed above are defined as:
MAXJOBS Specifies the maximum number of jobs that can be in the JES2 job queue at any given time. The lower limit is 10, the upper limit is 8000, and the default is 100. MINJOES Specifies the minimum number of free job output elements (JOES). When the free count drops below this value, no new work is added to the in-storage queues until the termination of a print or punch activity raises the free count. If the free job output element count is allowed to go to 0 by means of operator use of the $1 command in a congested system, output devices may become interlocked waiting for resources. Note: JES2 reduces the value specified for MINJOES, if necessary, so that the value is at least 2 less than the value specified for the NUMJOES parameter. The lower limit is 2, the upper limit is 4998, and the default is NUMJOES/5. NUMCMBS Specifies the number of console message buffers to be provided for JES2. The number of buffers specified should be sufficient to accommodate all outstanding operator requests and still allow message processing to continue. Message buffers are allocated from the Common Storage Area so you should be careful in determining this number. When RJE is used, more message buffers are usually needed. This is especially true with console support for MULTI-LEAVING terminals. Also, specifying too few message buffers can cause serious system degradation. During periods of high console activity, when no message buffers are available, certain noncritical JES2 messages are discarded to avoid delaying the associated process. These noncritical messages include certain RIE-oriented messages, excession messages (for execution time, lines, cards), and certain I/O error messages on JES2-controlled devices. For a MULTI-LEAVING terminal console, if more messages are queued than the number of buffers specified in this parameter, the excess messages are spooled and later printed. Normal message processing resumes after the terminal accepts those messages that were queued prior to reaching the NUMCMBS limit. The lower limit is 3, the upper limit is 999, and the default is 15. NUMJOES Specifies the number of job output elements to be generated. Although a value as small as 10 will be accepted, performance is degraded if a value smaller than the default is specified. One job output element is required for: • Each unique SYSOUT class that appears in a job that is queued for output, • Each active printer or punch, • Each interrupted or restarted job that is not currently active on a printer or punch, • Each unique combination of Forms ID, UCS ID, and FCB ID for all jobs currently queued for output, and • Each job that was interrupted by a system failure while being printed or punched and has not yet been restarted on an output device. Specifying too small a value results in jobs waiting for in-storage queuing in order to complete active print or punch work. The lower limit is 10, the upper limit is 5000, the default is 10 times the total number of local and remote printers and card punches. NUMDA Specifies the maximum number of direct-access volumes that can be mounted concurrently as spool volumes. All direct-access devices supported in OS/VS2 are eligible for use as spooling devices. Specifying a large number for NUMDA may require increasing the value of BUFSrZE. Refer to the information on the NUMTGV parameter for related information. The lower limit is 1, the upper limit is 36, and the default is 2.
There are other JES2 parameters that impact the capacity of the queue dataset. This was one of the more frequently discussed topics on the Hercules forums over the past two decades. Several sets of JES2 parameters were submitted and have been utilized on MVS running under Hercules. The set of parameters that I use in job SYSGEN02 are distilled from those sets of parameters and further adjusted by many discussions on the forums. The manual that describes the JES2 parameters in detail is: GC23-0002-0 MVS System programming Library JES2 (MAY 1976) [the link is for the pdf version of the manual at bitsavers.org]. It is possible that some of the parameters may be adjusted to provide more capacity, but the best solution is to monitor your JES2 queue to avoid depleting all of the JES2 resources.
If you change some/any of the JES2 parameters, at the least you will need to cycle JES2; that is, shut JES2 down and restart it. After stopping JES2 - command: $PJES2 - and allowing JES2 to bring all of its processes to an orderly close and reach normal end-of-job, JES2 may then be restarted with the MVS command: S JES2. The JES2 parameters are only read during JES2 initialization, so any changes you make to SYS1.PARMLIB(JES2PM00) will only take effect after a JES2 restart. It should not be necessary to advise you to make a copy of the original JES2 parameter member before introducing changes and to make only one or a few changes at a time, to see if they work before making more changes.
Here is a safe strategy for testing changes to the JES2 parameters:
Create a new member of SYS1.PARMLIB - perhaps JES2PMTS - and copy the contents of JES2PM00 into the new member,
Make your changes in the new member and save it,
Shut down JES2,
Start JES2 and specify that it read parameters from your test member: S JES2,M=JES2PMTS,
If everything works as expected, edit SYS1.PARMLIB, rename the original JES2PM00 (to have a safe restore point), and rename your test member to JES2PM00.
Changing some of the parameters will require you to reformat the JES2 queue; the GC23-0002 manual includes detailed descriptions of all the JES2 parameters and will indicate which ones, when changed, will require a queue format. In order to reformat the queue, when you reply to the $HASP426 SPECIFY OPTIONS prompt, reply: r 0,format,noreq. This will lose all job information stored on the queue, so make certain you do not need any of the job content on the queue before proceeding.
The parameters I have supplied in my instructions were not intended to be the perfect set of JES2 parameters for everyone forever; the intent was to supply a set of parameters that work for most hobby users of MVS 3.8j. As I said above, I arrived at this set of choices by spending a number of days comparing side-by-side listings of (I believe) five different sets of JES2 parameters that were obtained from various sources. Some of those originated from running MVS systems, so they were proven choices. And modifications to the final set of parameters I have passed along also came from discussions over a long period of time on the Hercules forums. If you read some of the manuals I have suggested above, you will soon see that many of the parameters are interconnected; that is, if you change one parameter, you impact one or more additional parameters. Also, some of the JES2 parameters have an impact on other system resources, such as NUMCMBs which will impact Common Storage pool.
I have already received feedback from Giuseppe Vitillaro on this topic, which I will pass along:
Giuseppe has followed a good strategy in comparing the JES2 parameters from two systems he was familiar with and changing the obvious choice to make the change he wanted to see. It worked and has continued to work for him, and probably is a good change to make for anyone who is consistently running out of JOEs. Thank you for the feedback Peppe. If there are additional suggestions sent to me, I will include them here.
In order to manage the jobs in the JES2 queue, you will need to be familiar with the TSO program QUEUE, which you installed following my instructions to build your MVS 3.8j system. Help for using QUEUE is available in the program itself by pressing Function Key 1 after QUEUE is started.
Alternatively you may use JES2 console operator commands to manipulate jobs stored on the queue. I have created a document containing a subset of useful JES2 console operator commands that is available at https://www.jaymoseley.com/downloads/pdf/JES2 Command Subset pdf. Note that I am calling this a Subset, because I have only included the JES2 commands that I think most useful to you under MVS 3.8j. This subset was derived from: GC23-0007-1 Operators Library OSVS2/MVS JES2 Commands (JAN 1979 [the link is for the pdf version of the manual at bitsavers.org].
If TSO is still responding and you can start QUEUE or if the console is still responsive and you can enter commands: You need to remove some (or all) of the jobs in the queue.
In the TSO QUEUE command, display the held jobs with the command HO, type P in front of all the jobs that you can do without and press Enter to purge them from the queue. If you really need the output from one or more jobs, you can type O in front of the jobs you want to print to release them to be printed to the host Operating System (Windows, Linux, Mac) file for the printer servicing that output print class. If you are viewing jobs in class X, which is a held output class [ie not eligible for selection to be printed], you will need to use the QUEUE command REQ <jobname> A to change the class of the output so that it is selected and printed; after printing the output will be deleted from the queue.
From the MVS console, you can remove output from the queue with the command: $pJn and substitute a jobnumber (or range of job numbers) for n in the command.
There is more control over the jobs utilizing the QUEUE command, because you can see exactly what jobs are on the queue and the details of their various output classes.
If TSO and the system console are not responding, the only recourse is to terminate Hercules (and with it MVS) and restart. When you are presented with the prompt: $HASP426 SPECIFY OPTIONS - HASP-II, VERSION JES2 4.1 you should respond, r 0,format,noreq to format the queue (thereby purging all content) and JES2 will start with a completely empty queue.
Your best solution to this problem is to ensure that you do not reach the point of having the problem. Police your JES2 queue and frequently remove job output that it is not necessary to keep. If you want to keep output from a job, you should release it to print, retrieve the output from the Hercules managed printer file, and save it on your host Operating System where you can find it. There are several MVS print output managers available to help you separate and manage the output from a Hercules managed printer file. Two of these are described on my Frequently Asked Questions page.
Only operate your 3270 MVS console in Roll Delete mode. If you allow messages to 'back up' because they cannot be displayed, they will not be removed from the JES2 queue, where they are stored until they are deleted. This can cause a shortage of Console Message Buffers. If all CMBs are depleted, your system will be completely non-functional, and the only solution will be to kill Hercules and restart both Hercules and MVS.
I hope that you have found my instructions useful. If you have questions that I can answer to help expand upon my explanations and examples shown here, please don't hesitate to send them to me:
Return to Site Home Page Frequently Asked Questions
This page was last updated on September 19, 2020.