S 3.40 Introduction to the z/OS operating system

Initiation responsibility: Head of IT

Implementation responsibility: Head of IT, Administrator

In its basic structures, z/OS is hardly different to other operating systems. It is divided into hardware-related functions, operating system processes and user processes. Between the actual operating system (Base Control Program) and the user processes, there are a series of subsystems, of which the most well known are the Job Entry Subsystem for handling batch processing, the Time Sharing Option for supporting the interactive operation and the Unix System Services for operation compatible with Unix.

The following description applies to the OS/390 and z/OS operating systems. For reasons of simplification, only z/OS is referred to in the test; any differences to OS/390 will be mentioned where they exist.

Base Control Program (BCP)

This part of the z/OS operating system is comparable with the Unix kernel. The BCP contains the key operating system functions, which run in the kernel mode accordingly.

Subsystems

Subsystems perform tasks in the operating system that are not based in the kernel and run in a separate address space. If a subsystem is activated by the MVS kernel prior to JES start, it is interpreted by the z/OS itself (this action is then performed by the master scheduler), a situation that involves certain restrictions. Otherwise, the Job Entry Subsystem starts further subsystems. A definition in the z/OS configuration file (PARMLIB) specifies how and in which order such subsystems are started.

Subsystems are supplied by IBM and other software manufacturers.

Job Entry Subsystem (JES2/3)

A batch processing job is called a batch job in z/OS. This job comprises a series of procedural instructions that are structured as per the Job Control Language (JCL). A batch job can comprise one or more steps. TSO users or started tasks are also made known to the system via JCL.

The Job Entry Subsystem (JES) is used to manage the job processing (primarily batch jobs, but also started tasks and TSO users) and their input and output. For historic reasons, there are two different systems, JES2 and JES3.

The JES2/3 is managed as primary subsystem in the z/OS subsystem table and should be the first task started in a z/OS system, as batch jobs can only be started subsequently.

The processing of the jobs is monitored using so-called initiators. Here, among other aspects, classes, priorities and the number of jobs that are processed in parallel in the system are defined.

Inputs and outputs are saved in a central file referred to as the spool. Several Logical Partitions (LPARs) can be combined to form a JES group; for JES3, this group is called a complex, for JES2 a Multiple Access Spool (MAS).

Both JES subsystems contain similar functions. Beyond the standard, JES3 provides functions such as networking (for the automation of batch jobs), clustering (LPAR-like cluster with global/local function, however, only based on JES) and locate (job is only started if all resources are available). Many functions are available to the operator in parallel to the JES subsystems via other z/OS functions (e.g. via GRS, Sysplex, job scheduler programs).

NJE (Network Job Entry) enables files, batch jobs and also other outputs to be sent and received between the individual network nodes in a group. It is therefore possible, for example. to send a batch job from system A to system B, to process it there and to output the output from the job on system C.

Time Sharing Option (TSO)

In online operation, TSO provides multi-tasking and multi-user operation.

The TSO Terminal Control Address Space (TCAS), a dedicated address space, manages the process. It initiates and terminates the individual user address spaces (one space per user) and administers the flow of messages between terminal and address space.

Using a simple script language, TSO supports so-called Command Lists (Clists); however, the more modern interpreter language REXX is frequently used. A further software package is available to the user to simplify the communication, i.e. the Interactive System Productivity Facility (ISPF). This package allows a dialog box in the full screen mode. In addition to the ISPF standard functions, the users can develop their own dialog boxes for new applications.

Communications Server (CS)

The Communications Server for z/OS contains the software components that are required for the communication from and to a mainframe. TCP/IP components, such as FTP server and TN server, as well as SNA components are included in this package.

The Communications Server provides the following functionalities:

Systems Network Architecture (SNA)

A node in the SNA network is defined by a Network Addressable Unit (NAU). The paths between the individual nodes are configured in the form of routes. The further development of the static SNA network, called Advanced Peer-to-Peer Networking (APPN), enables dynamic network configurations similar to the TCP/IP network.

The Communications Server forms a gateway function between the IP network infrastructures in common use today and the SNA/APPN-based components that are often still in use, such as TSO, IMS or CICS applications.

SNA communication links are often operated via the IP network using Enterprise Extender. A prerequisite for this configuration is APPN/HPR (High Performance Routing).

Classic SNA networks are considered relatively secure, as the network accesses must be fully defined and the overall network is therefore closed. As a further security safeguard, the Session Management Exit (SME) from VTAM can be used.

TCP/IP

TCP/IP is implemented on the Unix System Services (USS) in z/OS. The TCP/IP service on z/OS provides functions similar to the IP services on other Unix versions. Using the Telnet TN3270 IP service, it is possible to access SNA-based applications (TSO, CICS, IMS etc.). On TCP/IP, a whole series of applications are available for z/OS, such as an HTTP web server, support for the file transfer via FTP, e-mail via SMTP, Network File System (NFS), Domain Name Service (DNS) and other services. TCP/IP supports encryption via IPSec, SSH and TLS (SSL).

By means of the use of dynamic VIPA (Virtual IP Address), it is possible that an IP address is adopted by a backup system automatically in the event of a system failure of in a Parallel Sysplex cluster. If the application supports this functionality, availability can be considerably increased.

By using the Workload Manager, it is also possible to distribute the load for the network services to several CPUs in a Sysplex cluster.

TCP/IP is gaining increasing importance, while the importance of the SNA network is decreasing (especially in the development of new applications).

Kerberos

z/OS supports the authentication system Kerberos.

AnyNet

The term AnyNet stands for two functionalities that are supplied with the Communications Server:

SNA over TCP/IP enables applications that support only the SNA log to be connected to a TCP/IP network without the need to customise the applications.

AnyNet Sockets over SNA enables applications on z/OS Unix System Services (USS) to establish connections via an existing SNA network.

System Authorization Facility (SAF)

The SAF is part of the z/OS operating system and is used as security interface between the system and the security subsystem (e.g. RACF, TopSecret, ACF2).

Resource managers, for example IMS, DFHSM, JES or CICS, query via the SAF interface for RACF or the respective security subsystem (RACROUTE Macro) as to whether a user is authorised to access a resource. SAF provides the reply of the security subsystem to the resource manager; this then either allows access (return code is equal to zero) or denies access (return code is greater than zero).

Secure Way Security Server for z/OS

The Secure Way Security Server for z/OS forms a security platform for the mainframe system. The Secure Way Security Server comprises the following components:

RACF (Resource Access Control Facility)

RACF is an additional software package to protect the z/OS operating system. RACF uses IDs, groups and resources (files, classes) that must be entered in the RACF database. Using these definitions, RACF not only controls access to the system, but also the access to resources. Each resource, e.g. a file, must be protected with a corresponding RACF profile. Using wildcards, it is possible to protect a group of resources using a generic profile, whereby management is simplified. Access to the resources protected in this manner must then either be granted to individual users or user groups using the RACF administration.

In the RACF, there are attributes that can provide the owner with increased rights:

These rights can also be granted at the group level (Group Special, Group Operations, Group Auditor).

RACF provides additional segments for the authorisation to use interactive programs, e.g. TSO or Unix System Services. In these segments, the rights on the use of the interactive programs are defined. In addition, accounting information or resource restrictions (main memory available to the user, the number of tasks to be started) can be specified in these segments.

Each user (this term also includes the IDs of batch jobs, TSO users and started tasks) is managed in the running system by RACF using so-called ACEEs (Accessor Environment Elements). These elements are control blocks that are created on the initialisation of the address space.

Public Key Infrastructure (PKI)

RACF provides secure system access using digital certificates. This feature is particularly useful for use in the Internet/Intranet. RACF can generate, sign, check and manage certificates. The certificates can be saved in the RACF database or in special hardware. In this way, it is possible to set up a public key infrastructure using dedicated RACF certificates. Access to protected web server areas can also be controlled using certificates.

Firewall technologies

The firewall technologies of the Secure Way Security Server for z/OS enable internal and external network areas to be separated. These features support the following functionalities:

For the use of IPSec, the Communications Server for z/OS is also required.

LDAP

Together with the Secure Way Security Server, IBM provides a LDAP server. This server supports common LDAP clients and can thus be used as an information system. To manage large amounts of data, both the RACF database and independent DB2 database can be used.

Distributed Computing Environment (DCE)

DCE is a collection of tools and services that support the creation, use and maintenance of distributed applications.

DCE on z/OS supports the Distributed File System (DFS), which facilitate the common use of data (sharing) in the DCE environment, and Network File System (NFS), which, among other aspects, enables Unix workstations to access data on z/OS computers.

Integrated Cryptographic Service Facility (ICSF)

The ICSF is a software element that works together with the crypto hardware and the Secure Way Security Server to accelerate encryption and decryption.

Sysplex Failure Management (SFM)

The SFM policy detects whether errors have occurred on a system operating in the Sysplex cluster and initiates appropriate actions as necessary. Without SFM, a message is sent to the operator if a machine in the cluster has problems. The operator can then remove the defective system from the cluster and initiate recovery actions. SFM allows a policy to be installed that initiates automatic recovery actions for specific errors and thus makes it possible to maintain the operation of the machine.

Automatic Restart Manager (ARM)

The ARM enables subsystems stopped due to critical resources (e.g. deadlocks) to be restored quickly. In this way, the active system access by the operator is reduced.

Global Resource Serialization (GRS)

In a multi-tasking/multi-processing environment GRS ensures that the access to resources used by more than one computer is coordinated. GRS should always be used in a Sysplex configuration.

On the one hand, GRS can be configured in the RING mode. Here, a RSA message control block (Ring System Authority) is transported sequentially from z/OS system to z/OS system; each system enters its requirements in this block. Each system copies the RSA message to its own memory, i.e. the information is not more up to date than the last RSA information that came past.

The STAR mode is available as a further, more modern configuration. Here, all z/OS systems in the Sysplex are connected to a lock structure in the Coupling Facility; each z/OS system only needs to keep its own information in the local memory. The request for resources using GRS is more effective in the STAR mode than in the RING mode.

Unix System Services (USS)

USS is not a Unix porting, but a POSIX-compatible subsystem of MVS. It used to be marketed as Open Edition MVS. The task of the USS subsystem is in the operation of POSIX-compatible applications. For this purpose, the Hierarchical File System (HFS) and a Unix Shell were introduced.

The file system zFS has also been available in parallel to HFS for some time; this file system is used for all new developments (see also the following section File systems and access types).

Many programs that can be run on POSIX-compliant Unix operating systems can also run on USS. The TCP/IP functions for z/OS are largely implemented on USS. An HTTP web server is also available; it can be run as a daemon on USS or as a started task on MVS.

System Managed Storage (SMS)

SMS simplifies the management of data on hard disks, as this function takes over many tasks, e.g. the addition of files to specific hard disks, the definition of characteristics for the datasets etc. For this purpose, so-called ACS routines (Automated Control Storage) are defined; these routines manage the hard disk space in accordance with the stipulated rules. Datasets are saved in previously defined disk pools based on their name. As it is not unusual for mainframe systems to have a large number of disks, SMS significantly simplifies the management of files. SMS can be managed using the interactive dialog box system ISMF (Interactive Storage Management Facility).

As part of the SMS concept, a series of software products is available, which allow the efficient management data in an environment using the z/OS operating system (e.g. DFHSM or DFxxx products). In addition, a series of utilities is available as storage management functions which support the management of databases.

Hierarchical Storage Manager (HSM)

HSM is a key part of the z/OS SMS concept. The program product supports the management of z/OS files, data backup as well as the effective utilisation of storage media. Controlled using so-called policies (rule definitions), files are moved to various other media (migrated) and compressed by HSM at stipulated times. There are two migration levels:

Migrated files can only be read again if they have been restored using HSM. This function can be initiated manually or can be performed automatically when the file is addressed (recall function).

Furthermore, logical dumps (specific files) or Full Volume Dumps (the contents of an entire hard disk) can be started at specific times and, thus, data backed up automatically.

System Management Facility (SMF)

SMF is the central logging function in the z/OS operating system. Almost all components and also a large number of ISV products (Independent Software Vendor) write SMF records in which activities are logged. RACF also writes such records. Here, record type 80 is particularly important for later evaluations.

Resource Measurement Facility (RMF)

RMF logs the system behaviour in relation to capacity and performance. The log data is written as SMF records and is available for later evaluations. RMF is optional; alternative programs (monitors) are available on the market.

Generalized Trace Facility (GTF)

The term trace represents the ability to record the flow of data between two components in the system (e.g. an application and an end user) and to provide this information in a file for later evaluation. GTF is the central trace function for z/OS; this function enables traces on a large number of z/OS components. In addition, traces of the network functions are also supported. To evaluate the traces, a number of programs are available, e.g. ACFTAP for network analyses. For online traces, there is also NLDM (Network Logical Data Manager), a component of the NetView software package.

Transaction monitors and database systems

IMS TM (Information Management System Transaction Monitor)

The transaction component of the IMS system, with which the IMS transactions are managed and controlled in an IMS system, is referred to as IMS TM. (In older IMS versions, this function is also called DC.)

IMS DB (Information Management System Database)

The database component of the IMS system, which the IMS databases can be managed in an IMS system, is referred to as IMS DB. IMS databases are hierarchical database models.

CICS TS (Customer Information Control System Transaction Server)

CICS TS is a further transaction monitor. Using CICS TS, the CICS transactions in a system can be managed and controlled. Often, VSAM files or DB2 databases are used as database.

DB2 (Database 2)

DB2 is a program package that can be used to prepare and manage relational databases. Using IMS TM, CICS TS or using SQL (Structured Query Language), data can be saved in the database in table or extracted from this database.

IMS, CICS and DB2 are not part of the focus of module S/390 and zSeries-Mainframe and are thus only examined marginally here.

File Transfer Protocol (FTP)

FTP programs enable data to be transported both between z/OS system and to and from other platforms.

FTP is not part of the focus of the module S/390 and zSeries mainframe and is thus only examined marginally here.

Middleware

MQSeries (Message Queueing System)

MQSeries establishes a connection between different applications based on messages, for example, between CICS, IMS or batch applications. Using appropriate APIs (Application Programming Interfaces), the messages are forwarded to MQSeries and then delivered to the specified destination. If delivery is not possible, the messages are cached (queued) and only forwarded when it is possible to establish the connection again.

MQSeries is not covered in the module S/390 and zSeries mainframe.

File systems and access types

Files are created in z/OS with specific characteristics, e.g. size, type of storage (inner structure), on which disk the file is located and under which file name the file is saved and can normally be found. Particularly in relation to the inner structure of the files, in some areas, there are significant differences to other operating systems that are in common use. The most important file types are as follows:

HFS (Hierarchical File System)

The HFS file system is comparable to typical Unix file systems. It is saved in a MVS dataset, which can be processed in MVS using the usual tools (e.g. data backup using HSM). The file system is hierarchical in relation to USS. Data in this file system is saved in the EBCDIC character set.

z/OS File System (zFS)

zFS is conceptionally similar to HFS; in this case, however, several file systems can be saved in one z/OS dataset and the data can also be saved in the ASCII character set. According to IBM, zFS is the strategic file system, in which only new functions are developed. zFS cannot be used as root file system yet.

MVS Physical Sequential (PS) datasets

In this type of dataset, data can only be read or written sequentially. Physical sequential datasets are often used in the system environment for processing large amounts of data.

MVS Partitioned Organized (PO) datasets

Partitioned organized datasets can be compared to a library. In a PO dataset, there is an index (directory) and the individual books (members). The members contain the information.

If members are saved frequently, the file must be reorganised from time to time. The need to perform this action can be circumvented by using a PDSE file (Partitioned Dataset Enhanced).

Virtual Storage Access Method (VSAM)

In the z/OS operating system, VSAM is one of the most important file access methods. The data records are found using an index or a relative byte address. A distinction can be made between four VSAM file types:

Other access methods

In addition to the familiar VSAM method, there are other methods such as the Sequential Access Method (SAM) and Queued Sequential Access Method (QSAM) as well as a number of other methods which are only mentioned in passing, because they are only used very rarely.

Server and client concepts

By expanding the z/OS operating system with the Unix System Server (USS), computers with this operating system can perform additional server and client functions. Examples of such server functions are, among others, the HTTP server, the FTP server or the domain name server. The FTP function can also be used, e.g. as a client. Furthermore, the z/OS system in the current 2-layer or 3-layer architecture is often used as a database server, in which case it communicates with other platforms.

Configuration of the z/OS (OS/390)

I/O config

The input/output constellation of a z/OS operating system is defined in the HCD dialog box using an I/O configuration and saved for the respective LPAR using the Operator Facility (via HMC console). At the time of IML, it has already been defined which I/O profiles are available for subsequent selection. Dynamic re-configuration during operation is possible at any time (see safeguard S 3.39 Introduction to the zSeries platform).

IPL volume

To start a z/OS operating system, the system requires a special IPL volume, a disk with a special bootstrap routine that loads and starts the necessary operating system programs. This process is similar to a boot process in Unix and is called the Initial Program Load (IPL) in z/OS.

Parmlib / Proclibs

One (or more) parameter file(s) are available via the Parmlib mechanism for the definition of all key z/OS system parameters. These parameters include, for example, which subsystems are to be started, which security mechanisms are activated and which libraries are to be authorised. All important system jobs, also referred to as started tasks, are available in procedure libraries (Proclibs) so that they can activated at the start time (see safeguard S 3.39 Introduction to the zSeries platform). This area must be defined very carefully and protected, as key security mechanisms are anchored here.

Catalogues

Files are managed and made known to the system using catalogues. The highest instance is the master catalogue to which various user catalogues are linked using alias definitions.

Work files

Several work files also form part of the minimum configuration of a z/OS operating system; these files must have been created when starting production:

© Federal Office for Information Security. All rights reserved.