IBM Mainframe OS: history - development - structural overview

     The first OS was called PCP - Primary Control Program. While this eventually evolved into MFT, MFT-II, MVT, OS/VS1, OS/VS2 MVS, MVS ESA, OS/390 and the now zOS, the underlying design has endured and still constitutes the "guts" of the Operating System. Most of the changes since then have been in the areas of user tools, reliability/availablity and expanded functionality. Today, OS consists of several major components, to handle the major areas of computing.

     PCP was a single-thread OS, with no Spooling of card/printer data, so programs might have been limited to the speed of a card reader or printer at times.

     MFT and MFT-II supported multiple jobs, each in its own Partition. Partitions were also dedicated to driving card readers and printers, providing Spooling of both input and output so that user programs were not limited to the speed of card/printer operation. Partitions were of fixed size. Although users could adjust these sizes, it was a clumsy system to operate.

     MVT was the next incarnation of OS and was the system originally targeted when the hardware was designed. MVT supported Regions of whatever size was required by a specific job, thus allowing more flexibility. Small regions continued to drive card/print Spooling and RJE (Remote Job Entry - work from remote computers). The system is limited to 15 user regions at any given time, as there are only 16 Storage Protection keys and OS uses Key Zero.

     Storage Protection is a feature of the hardware, whereby blocks of memory have a particular key assigned and a program must have a matching key to access and/or alter that memory. The system can protect a block of memory from being written or even from being read, thus preventing bugs in one program from affecting other programs or the OS itself and one program from accessing another's data. It's rather like protecting the kernel of a UNIX-type system, but the IBM hardware/software also protects one process from another and it's done at the hardware level. In modern systems, memory protection and execution privileges have become much more sophisticated and involve both hardware and software as well as security controls.

     There are several security packages available for OS/390-zOS. Candle's ACF2 and Top Secret are widely used, but we use IBM's RACF. This software controls TSO UserIDs and their access to datasets and functions as well as the ability of jobs to process particular datasets. We do not run a particularly detailed or sophisticated RACF environment, largely because we have few TSO users and they are mostly HealthServe or Siemens employees. The few VMBC users have very limited TSO functionality, controlled by the TSO envelope in which they run, which is enforced by RACF.

     A user job is presented/invoked through Job Control Language. JCL consists of a set of control statements defining characteristics of the job such as the amount of memory required, maximum execution time, jobname (for identification), accounting data (to bill jobs to particular users/departments), etc. Jobs consist of Steps, which specify a particular program as well as the datasets used and/or created.

     Job Management is the Operating System facility which handles this job as an entire unit, as well as handling the individual steps of the job. It is probably the simplest, conceptually, of the OS components.

     The programs invoked by the steps are handled by the Task Management facility, which also intercepts and deals with program failures. Detecting and handling abnormal conditions is extremely sophisticated in the OS environment and there are several IBM manuals dealing with just this aspect of OS.

     Data Management is responsible for handling the I/O component of processing. There are several types of datasets, some unique to OS. Disk datasets can be shared, but tape, card (pretty much obsolete) or printer datasets are single-thread.

   Simple Sequential datasets.

   Direct Access: random-access disk files.

   Partitioned Datasets: Collection of sequential data. Libraries of JCL, Programs and such are kept in PDS datasets.

   These three dataset types may also be members of a GDG (Generation Data Group) although most GDGs are sequential data.

   VSAM datasets. These files can be accessed both sequentially and randomly, as they contain both data and indexes to that data. DB2, for example, is IBM's Database offering (and the most powerful DB extant) and its data files are VSAM, albeit used in an extremely complicated and sophisticated fashion.

     OS has Access Methods, which are a set of facilities designed to provide access (surprise!) to data. The Sequential Access Method consists of the tools to create, read, write, modify or delete sequential datasets. The Direct Access Method does the same for Direct (Random) Access datasets, Partitioned Access Method for PDS datasets, VSAM for the Indexed datasets. VTAM is an AM for establishing communications with terminals and other computers. A few other special-purpose AMs exist which I will not bother with here, since we either do not have and probably will never have them or they are buried so deeply in the bowels of the Operating System that users do not knowingly interface with them. In addition the the Access Methods used by the programs, the OS has facilities for keeping track of datasets, archiving and retrieving them and organizing their location.

     Some jobs are 'batch' - they are invoked to do specific tasks. Other jobs remain operational for long periods of time. CICS, for example, is a software platform for real-time applications. At Healthserve, the Invision system from Siemens is a CICS application. We run two CICS regions, A2K (Production Invision for VMBC use) and A2KTEST (Test Invision for our development use).

     While the operator interface is usually thru a 3278 'dumb' terminal driven directly by OS, user access is usually via VTAM. A session may be purely VTAM, such as from the 3270 terminals in the machine room or by a TCPIP Interface to VTAM, which converts a Telnet session to a VTAM session. The Invision application was coded to use the CICS VTAM interface. (Current CICS supports direct Telnet sessions, but the application was designed long ago, when only VTAM or its precuror BTAM were supported). There are many flavors of Telnet, with TN3270 being the IBM flavor that we use when we invoke Rumba for the mainframe. Rumba for the AS400, for example, invokes a different flavor of Telnet, emulating the usual AS400 terminals.

     CICS is accessible directly as a VTAM application. We also sometimes run Omegamon (a OS monitoring tool), which is also a VTAM application. Aside from Invision, the most common application we use is TSO. TSO is mostly used by Healthserve, although a few VMBC and other personnel have a very limited TSO functionality. TSO is one of IBM's Time Sharing applications for OS. It allows multiple users to logon and perform OS-related activity thru ISPF panels (screens). This provides an interactive environment for executing and monitoring jobs; editing JCL and programs; compiling programs, displaying data, copying, duplicating, deleting files, etc.

     Many components of the Operating System have an ISPF interface and most 3rd-party software has an ISPF interface. At Healthserve, the most common use of TSO/ISPF is to invoke the SDSF subsystem to monitor and control job execution and display/modify/delete Spool files; create/change PDS members of JCL or program source code; invoke TSO CLISTS (a CLIST is an IBM scripting language) provided by Siemens to support the Invision application and Dayend processing. We also have an ISPF interface to VPS, the 3rd-party sofware that drives the printer network.


     A detailed documentation for both IBM hardware and the Operating System can be found on IBM's websites.
The zOS overview is a good place to start.