IBM z/OS MVS Spooling : a Brief Introduction —
Spooling means a holding area on disk is used for input jobs waiting to run and output waiting to print.
This is a brief introduction to IBM z/OS MVS mainframe spooling.
The holding area is called spool space. The imagery of spooling was probably taken from processes that wind some material such as thread, string, fabric or gift wrapping paper onto a spindle or spool. In effect, spooling is a near-synonym for queueing. Those paper towels on that roll in the kitchen are queued up waiting for you to use each one in turn, just like a report waiting to be printed or a set of JCL statements waiting for its turn to run.
On very early mainframe computers, the system read input jobs from a punched card reader, one line at a time, one line from each punched card. It wrote printed output to a line printer, one line at a time. Compared to disks – even the slower disks used decades ago – the card readers and line printers were super slow. Bottlenecks, it might be said. The system paused its other processing and waited while the next card was read, or while the next line was printed. So that methodology was pretty well doomed. It was okay as a first pass at getting a system to run — way better than an abacus — but that mega bottleneck had to go. Hence came spooling.
HASP, Houston Automatic Spooling Priority program (system, subsystem) was early spooling software that was used with OS/360 (the ancestral precursor of z/OS MVS). (See HASP origin story, if interested.) HASP was the basis of development for JES2, which today is the most widely used spooling subsystem for z/OS MVS systems. Another fairly widely used current spooling sub-system is JES3, based on an alternate early system called ASP. We will focus on JES2 in this article because it is more widely used. JES stands for Job Entry Subsystem. In fact JES subsystems oversee both job entry (input) and processing of sysout (SYStem OUTput).
Besides simply queueing the input and output, the spooling subsystem schedules it. The details of the scheduling form the main point of interest for most of us. Preliminary to that, we might want to know a little about the basic pieces involved.
The Basic pieces
There are input classes, also called job classes, that control scheduling and resource limits
There are output classes, also called sysout classes, that control output print
There are real physical devices (few card readers, but many variations of printers and vaguely printer-like devices)
There are virtual devices. One virtual device is the “internal reader” used for software-submitted jobs, such as those sent in using the TSO submit command or FTP. Virtual output devices include “external writers”. An external writer is a program that reads and processes sysout files, and such a program can route the output to any available destination. Many sysout files are never really printed, but are viewed (and further processed) directly from the spool space under TSO using a software product like SDSF.
There is spool sharing. A JES2 spool space on disk (shared disk, called shared DASD) can be shared between two or more z/OS MVS systems with JES2 (with a current limit of 32 systems connected this way). Each such system has a copy of JES2 running. Together they form a multi-access spool configuration (MAS). Each JES2 subsystem sharing the same spool space can start jobs from the waiting input queues on the shared spool, and can also select and process output from the shared spool.
There is checkpointing. This is obviously especially necessary when spool sharing is in use.
There is routing. Again, useful with spool sharing, to enable you to route your job to run on a particular system, but also useful just to route your job’s output print files to print on a particular printer.
There are separate JES2 operator commands that the system operator can use to control the spooling subsystem, for example to change what classes of sysout can be sent to a specific printer, or what job classes are to be processed. (These are the operator commands that start with a dollar sign $, or some alternative currency symbol depending on where your system is located.)
There is a set of very JCL-like control statements you can use to specify your requirements to the spooling subsystem. (Sometimes called JECL, for Job Entry Control Language, as distinct from plain JCL, Job Control Language.) For JES3, these statements begin with //* just like an ordinary JCL comment, so a job that has been running on a JES3 system can be copied to a system without JES3 and the JES3-specific JECL statements will simply be ignored as comments. For JES2, on which we will focus here, the statements generally begin with /* in columns 1 and 2. Common examples you may have seen are /*ROUTE and /*OUTPUT but notice that the newer OUTPUT statement in JCL is an upgrade from /*OUTPUT and the new OUTPUT statement offers more (and, well, newer) options. Though the OUTPUT statement is newish, it is over a decade old, so you probably do have it on your system.
There are actual JCL parameters and statements that interact with JES2, such as the OUTPUT parameter on the DD statement, and the just-mentioned OUTPUT statement itself, which is pointed to by the parameter on the DD.
Another example is the CLASS parameter on the JOB statement, which is used to designate the job class for job scheduling and execution. The meanings of the individual job classes are totally made up for each site. Some small development company might have just one job class for everything. Big companies typically create complicated sets of job classes, each class defined with its own limits for resources such as execution time, region size, even the time of day when the jobs in each class are allowed to run. Your site can define how many jobs of the same class are allowed to run concurrently, and the scheduling selection priority of each class relative to each other class. Sometimes sites will set up informal rules which are not enforced by the software, but by local working rules, so that everyone there is presumed to know that they are only allowed to specify, for example, CLASS=E for emergency jobs. (That’s one I happened to see someplace.) If you want to know what job CLASS to specify for your various work, your best bet is to ask your co-workers, the people who are responsible for setting up the job classes, or some other knowledgeable source at your company. Remember you can be held accountable for following rules you know nothing about that are not enforced by any software configuration, so don’t try to figure it out on your own, ask colleagues and other appropriate individuals what is permissible and expected. Not joking. JES2 Init & Tuning (Guide and reference) are the books that define how JES2 job classes have been configured, if you’re just curious to get a general idea of what the parameters are. The JES2 proc in proclib usually contains a HASPPARM DD statement pointing to where to find the JES2 configuration parameters on any particular system.
In some cases similar considerations can apply for the use of SYSOUT print classes and the routing of such output to go to particular printers or to be printed at particular times. The SYSOUT classes, like JOB classes, are entirely arbitrary and chosen by the responsible personnel at each site.
MSGCLASS on the JOB statement controls where the job log goes — the JCL and messages portion of your listing. The values you can specify for MSGCLASS are exactly the same as those for SYSOUT (whatever way that may be set up at your site). If you want all your SYSOUT to go to the same place, along with your JCL and messages, specify that class as the value for MSGCLASS= on your job statement, and then specify SYSOUT=* on all of the DD statements for printed output files. (That is, specify an asterisk as the value for SYSOUT= on the DD statements.)
In many places, SYSOUT class A indicates real physical printed output on any printer, class X indicates routing to a held queue where it can be viewed from SDSF, and class Z specifies that the output immediately vanishes (Yup, that's an option). However, there is no way to know for sure the details of how classes are set up at your particular site unless you ask about it.
Sometimes places maintain “secret” classes for specifying higher priority print jobs, or jobs that go to particular special reserved printers, and the secrets don’t stay secret of course. Just because you see someone else using some print class, don’t assume it means it’s okay for you to use it for any particular job. Ask around about the local rules and expectations.
So, for MSGCLASS (aka SYSOUT classes), as for JOB classes, the best thing is to ask whoever sets up the classes at your site; or, if that isn't practical, ask people working in the same area as you are, or just whoever you think is probably knowledgeable about the local setup. Classes are set up by your site, for your site.
An example of a JES2-related JCL statement that you have probably not yet seen is introduced with z/OS 2.2 — the JOBGROUP statement, and an entire set of associated statements (ENDGROUP, SCHEDULE, BEFORE, AFTER, CONCURRENT), there are about ten of them – but that would be a topic for a follow-on post. You probably don’t have z/OS 2.2 yet anyway, but it can be fun to know what’s coming. JOBGROUP is coming.
That’s probably enough for an overview basic introduction.
The idea for this post came from a suggestion by Ian Watson.
References and Further Reading
z/OS concepts: JES2 compared to JES3
z/OS JES2 Initialization and Tuning Guide, SA32-0991-00
How to initialize JES2 in a multi-access SPOOL configuration
z/OS MVS JCL Reference (z/OS 2.2)
JES2 Execution Control Statements (This is where you can see the new JOBGROUP)
z/OS MVS JCL Reference, SA23-1385-00 (z/OS 2.1)
JES2 control statements
OUTPUT JCL statement
z/OS JES2 Initialization and Tuning Reference, SA32-0992-00
Parameter description for JOBCLASS(class…|STC|TSU)
z/OS JES2 Initialization and Tuning Guide, SA32-0991-00
Defining the data set for JES2 initialization parameters
IBM z/OS MVS spooling IBM z/OS MVS spooling IBM z/OS MVS spooling IBM z/OS MVS spooling IBM z/OS MVS spooling IBM z/OS MVS spooling IBM z/OS MVS spooling IBM z/OS MVS spooling IBM z/OS MVS spooling IBM z/OS MVS spooling IBM z/OS MVS spooling