For reasons of size, this section concentrates on the MVT option of OS/360; PCP and MFT are very similar; with changes in nomenclature and some minor differences.
OS/VS1 and
SVS have much the same structure as MFT II and MVT, while
MVS, although retaining much of the logic of MVT, has major enhancements better addressed in a separate article. This article adheres to IBM's usage of the term
storage rather than
memory.
CPU allocation OS/360 assigns processors to tasks, which are analogous to
light-weight processes or
threads in other systems. Each task has a
Task Control Block (TCB) and a stack of
Request Blocks (RBs). A task is either dispatchable or nondispatchable and an RB is either waiting or not waiting. The
Dispatcher selects the highest priority dispatchable task whose current RB is not waiting. MVS assigns processors to
address spaces, which are analogous to processes, and to
Service Request Block (SRBs) and tasks within address spaces. Each address space has an Address Space Control Block (ASCB), a queue of SRBs and a queue of TCBs.
Storage layout In OS/360 all storage is visible to all code, although
fetch protection may prevent access by unprivileged code to some control blocks or between jobs. Main storage for MVT is divided into a
system (
fixed) area at the bottom of real storage, a
common area at the top and a
private area in the middle. These contain the following areas. ;Fixed area : This area starts at absolute location 0 and contains :;The Nucleus. ::This is a section of storage at location 0, loaded from , where xx is normally 01. For Model 65 MP (M65MP), there is a separate copy of the prefix (locations 0-4095) for each processor (LPA) ::This is an area into which MVT loads reentrant access method routines and other programs at IPL time that can subsequently be shared by all jobs.
SVS storage layout SVS is similar except that the system area is at the top and bottom of virtual storage rather than real storage, the Nucleus is in Virtual=Real (V=R) storage, the private area contains a Local System Queue Area (LSQA) for each region and the LPA is split into: ;Pageable Link Pack Area (PLPA) :This is an area containing all of the modules in SYS1.LPALIB; the page dataset backing it up is retained across IPLs, except when the create LPA (CLPA) option is specified. ;Modified Link Pack Area (MLPA) :This is an area containing modules listed in an IEALPAxx member of SYS1.PARMLIB and replacing modules in the PLPA for the duration of an IPL. ;Fixed Link Pack Area (FLPA). :This is an area containing page-fixed modules listed in an IEAFIXxx member of SYS1.PARMLIB and replacing modules in the PLPA for the duration of an IPL.
MVS/370 Storage layout In MVS all address spaces share the system area but not the private area. MVS adds: ;Common Storage Area (CSA) :This is an area from which MVS can dynamically allocate storage shared by all address spaces. ;System Work Area (SWA) :This is an area containing control blocks that in OS/360 and SVS had been contained in SYS1.SYSJOBQE.
MVS/XA, MVS/ESA and OS/390 storage layout In MVS/XA and later, there are system, private and common areas below the (224 bytes)
line, and extended areas between and (231 bytes).
z/OS storage layout In
z/OS, the storage layout is similar to that of MVS/XA, MVS/ESA and OS/390; storage above the
bar is managed by different services than storage below the bar.
IPL process When the operators initially selects , The system sends a command to the selected device, reading 24 bytes from cylinder 0, track 0, record 1, into storage location 0. Bytes 8-23 read and transfer to the bootstrap record cylinder 0, track 0, record 2, which in turn reads and transfers to the IPL Loader. The IPL Loader does initial housekeeping, locates the requested nucleus and loads it with relocation; the interrupt handler csect is always at location 0 and the Nucleus Initialization csect is always last, so that it can eventually be discarded. The Nucleus Initialization Program (NIP) initializes various system components. Initially NIP must provide services that it needs. However, as it initializes various OS facilities it begins using standard services, e.g., it uses the macro to read a
Data Set Control Block (DSCB) from a
Volume Table of Contents (VTOC). NIP reads members from the dataset to obtain various operational data. These members may be specified by default, by the operator, or by parameters in other members. NIP eventually creates a Master Schedule region from the private area and transfers to IEEVIPL to initialize the Master Scheduler and Communication Task, which completes system Initialization.
Job-like units of work In addition to batch jobs, OS/360 supports several categories of work that it handles similarly to batch jobs. In all cases the system has to process JCL, allocate a region, allocate devices and initiate the job-step program. For a batch job, the Reader/Interpreter processes JCL from an external device; for commands, commands and
TSO , the system generates JCL invoking a cataloged procedure. For each job-like unit of work, the
Reader/Interpreter converts the JCL to control blocks (
tables) on SYS1.SYSJOBQE (system job queue) and the
Initiator uses those control blocks to run the job. The details below are for MVT and SVS; PCP does not support spooling and MFT partition handling is somewhat different from MVT region handling.
Reader/Interpreter The Reader/Interpreter (R/I) performs two functions, depending on how the system calls it. When the OS initializes the
Master Scheduler, processes a command, processes a command or processes a
TSO , the system generates JCL invoking a cataloged procedure and invokes the R/I, followed by the
Initiator. For a Reader procedure, the R/I creates a separate input job entry on the job queue for each job in the input stream. The R/I recognizes explicit DD *, implicit DD* and explicit DD DATA in-stream (SYSIN) data sets, and allocates a separate DASD dataset for each, using a special DSNAME that includes the job name and a timestamp.
Initiator The Initiator performs two functions, depending on how the system calls it. For Master Scheduler Initiation, processing commands and processing
TSO s, the system calls the Initiator to run the job just constructed by the R/I, in a newly acquired region. For batch jobs, the Initiator selects work from the input queue, acquires a region for each step and runs the steps in sequence, skipping steps when requested in the JCL.
Interfaces API OS/360 has a control block known as the Communications Vector Table (CVT), which contains pointers to other control blocks and to various routines. Some of the OS/360 macro-instructions refer to fields in the CVT and other control blocks. OS/360 has macros to provide dsect mappings of some control blocks, although many macros have hard coded offsets rather than the names in the mapping macros. OS/360 services typically have parameters in register 1; some use registers 0 and 1 and some use registers 0, 1 and 15. OS/360 service macros often have three forms: ;Execute form :Perform the function using a provided parameter list ;List form :Generate a parameter list with preset parameters that can be used by an execute form macro. ;Standard form :Generate any required parameter list and perform the function. Many of the important services are implemented in
SVC routines, and preserve registers 2-14. Others are implemented as directly callable subroutines, with entry addresses in system control blocks, and require that Register 13 point to a standard save area; these typically preserve registers 2–13. In either case, register 15 at exit normally contains a return code; many services return additional data in registers 0 and 1.
Synchronization OS/360 relies heavily on serialization using an Event Control Block (ECB), which represents an event that can be waited for; an ECB contains a completion code for an event or the address of a Request Block (RB) waiting for that event. The
WAIT macro puts a task into a wait state until the specified events occur; the
POST macro marks an ECB as complete, stores the completion code into the ECB and decrements the wait count in the waiting RB, if any, possibly causing the associated task to be dispatched.
MVS adds other synchronization methods.
Serialization OS/360 uses the
ENQ and
DEQ to serialize access to resources, identified by a queue name (
qname or major) and resource name (
rname or minor). The ENQ macro delays a task until all of the requested resources are available. The DEQ macros returns named resources previously requested by an ENQ. A DEQ need not release all resources obtained by corresponding ENQ requests, but subsequent DEQ requests must eventually release all of them. MVS adds other serialization methods.
Operator consoles OS/360 requires at least one operator console; there are two levels of support ;Primary :This is a basic level of support allowing only one primary console, one optional alternate console ;Multiple Console Support (MCS) :MCS allows one master console and up to 31 secondary consoles. Any of the 32 consoles may have an alternate console to receive its message traffic in the event it fails. MCS allows recording of message traffic on a hardcopy log, which may be either a secondary console or the system log (SYSLOG) on DASD. MCS includes Device Independent Display Operator Console Support (DIDOCS), a unified framework for supporting CRT-based consoles. Each message issued by a Write To Operator (WTO) or Write To Operator with Reply (WTOR) has associated with it one or more routing codes. The operator can limit a console to displaying only specific routing codes. A typical use for this would be placing a console in a tape library and displaying only messages relevant to the tape librarian on it. The special routing code 7 causes the message text to be included in the job's message log. Each message also has a descriptor that controls how it is processed. One of the key operator commands is , which provides a response to the macro. The operator can only reply to a WTOR at a console that received its message text. A key command for display consoles, e.g.,
2250,
2260,
3270, is
CONTROL (
K), which sets processing options for, e.g., scrolling.
JCL ==Timeline==