S 3.39 Introduction to the zSeries platform

Initiation responsibility: Head of IT

Implementation responsibility: Head of IT, Administrator

The zSeries architecture is successor to the S/360 architecture introduced in 1964 and is often used nowadays in mainframe installations. The zSeries systems (as part of the IBMs eServer family) can be used both for batch processing and transactions and for e-business applications.

The OS/390 (31-bit architecture) and z/OS (64-bit architecture) operating systems are available for the operation of the zSeries platform. As the z/OS operating system is considered to be the successor to OS/390, it should be used in new installations.

The following sections contain an overview of the zSeries platform components; however, no claim is made to completeness. Comprehensive and detailed information can be found in the applicable literature of the manufacturer, IBM (see bibliography at the end of this safeguard description).

The z/OS operating system is described in safeguard S 3.40 Introduction to the z/OS operating system, the Linux operating system for z/OS in safeguard S 3.41 Introduction to Linux and z/VM for Series systems.

History

The basis for the zSeries architecture came into existence in 1964, when IBM developed and introduced the S/360 architecture. From the start, it was the objective of the architecture that it should be possible to run machine code on all current and future models without significant modification.

Over the years, IBM has successively expanded the S/360 architecture. During this time, the name has changed several times, first to S/370, then to S/390 and now to the current zSeries. The essential basic features of the architecture (e.g. machine code, registers and addressing or even the definition of the relation between bit and byte), however, have been retained and are still applicable today.

Mainframe architecture

IBM's documentation z/Architecture Principles of Operations divides the zSeries system into the elements

. The I/O devices are connected to so-called Control Units (CUs), which in turn are connected to the channel subsystem.

The S/390 architecture is essentially the same as the zSeries architecture, with the exception of the new zSeries functions. In the following, a few aspects of the z/architecture are described:

EBCDIC code

When saving data, zSeries systems use the so-called EBCDIC code (Extended binary coded decimal interchange code) with a length of eight bits, unlike other computer architectures, which use ASCII code (seven bits). If computers that use different formats communicate with each other, it is necessary to convert the codes.

Registers

A zSeries computer uses various registers with a length of 64 bits (e.g. control registers or general-purpose registers). The Instruction Operation Code (IOC) defines which register is used.

On the S/390 computer, the registers have a length of 32 bits.

Program branching (linkage convention)

The zSeries architecture uses several general-purpose registers when a subprogram is called. The use of specific registers is also known as linkage convention in the literature.

As an alternative, it is possible to use a linkage stack; for this purpose, other assembler instructions are available.

Memory protection

An additional memory protection feature in the zSeries architecture ensures that errors are largely prevented during memory access. The hardware divides the memory into 4 kB blocks and assigns a memory protection key to each block; this key is then checked during subsequent processing.

This type of memory protection is one of the advantages of the operating system, as overwriting other memory in the normal problem mode is largely prevented.

Input/output

The zSeries input/output traffic is controlled by a channel subsystem. Up to 65536 input/output units can be connected to the channel subsystem using (control units) and linked to the system suing channel paths.

The individual connections are managed by the channel subsystem as logical connections (subchannels). They are connected to the channel subsystem using channel paths.

Operator facilities

With this function, the system administrator can connect to the zSeries system and make changes to the system configuration, similar to BIOS communication on the PC.

A conventional PC is used for the communication; this PC is connected to the service element and is referred to as management console (see also section Input/output - zSeries mainframe consoles). This console is used only by the system administrator and/or the manufacturer's maintenance personnel.

Operating system support

The z/architecture supports all three existing hardware addressing ranges, 24-bit, 31-bit and 64-bit addressing. Operating systems and middleware products have been modified for the use of extended addressing. Many restrictions, e.g. the 2 GB limit on S/390 systems or functions that are now largely unnecessary, such as the transfer of pages in the main memory to the expanded memory (expanded storage), have been removed in this process. As a result, the system throughput can be increased in many cases. Expanded storage will, however, continue to be supported in S/390 (31-bit) applications and z/VM.

Comments: Although the S/390 system is in relation to the hardware a 32-bit system, the software runs on this system with 31 bits, as the first bit is required for switching between the 24- and 31-bit mode.

Differences between the S/390 architecture and the zSeries architecture

The main difference between S/390 and zSeries systems is the extended addressing available. While the S/390 architecture only supports 31-bit addressing, almost all registers have been extended to 64 bits in zSeries computers. It is possible to switch between the two modes at any time.

The latest zSeries systems are, however, still compatible with 31-bit programs developed earlier; even 24-bit programs still run.

Hardware

Mainframe hardware is available in a very wide range of variants. Models and equipment can be flexibly combined; peripheral units can be connected largely as required. It is not possible to provide a complete description at this point.

A brief overview of the most important features is given in the following:

Models

Currently, the types S/390 (G5, G6 and Multiprise) are available with the S/390 architecture and the types z800 server, z900 server and z990 server with the zSeries architecture (as at the end of 2003).

Processors

The systems can be upgraded to up to 32 processors; these processors can be dynamically added to the zSeries architecture (i.e. during operation).

Main memory

Depending on the type, it is possible to use between 1 GB and max. 256 GB of the main memory.

Channels

256 to max. 512 channels are available; different channel types can be operated together (Escon, Ficon). There are restrictions depending on the configuration.

Logical partitioning

A zSeries system can be divided into up to 15 so-called Logical Partitions, (LPAR); z990 servers can be divided into up to 30 logical partitions. This aspect is supported by the internal PR/SM feature (partly hardware, partly microcode in the licensed internal code). Each individual partition behaves like a separate system. Different operating systems can be installed on the LPARs so that it is possible to use Linux (for zSeries) in parallel with the z/OS operating system on the same computer.

Components

Processors and use

The processors are located on MCMs and essentially comprise the following types:

The number of CPs and SAPs supplied as standard is dependent on the model ordered in the specific case. The number of spare PUs is dependent on how many PUs are available in total and are not yet used for functions.

It is easy to allocate the following functions to spare PUs using the Licensed Internal Code Configuration Control (LICCC) via Host Management Console (HMC):

Cryptographic components

The zSeries provides various cryptographic hardware components that support data encryption and decryption.

Input/output

On the zSeries platform, data is input or output over a network of connections which are briefly described in the following:

Channel Subsystem (CSS)

The Channel Subsystem is a unit (comprising hardware and software) responsible for the processing of the data from and to the input/output units and reduces the load on the CPU. This subsystem consists of channels (channel paths) which in turn are divided into subchannels. The subchannels run the channel programs. On the zSeries system z990, the CSS has been expanded to form the Logical Channel Subsystem (LCSS) and now supports more than 15 CPUs.

Escon / MIF

Escon channels are serial channels that can be considered a further development of the old parallel channel development. The Multiple Image Facility (EMIF up to z/900 or MIF from z/990) supports parallel access to resources beyond LPAR boundaries (resource sharing). Escon channels are allocated to the units using so-called directors.

Ficon

Ficon express channels (fibre channels) can be operated in parallel with Escon channels. Up to 120 of such Ficon channels can be connected on the z990. The transmission rate is up to 100 MB per second. Ficon channels are also allocated to the units using directors.

Integrated Cluster Bus (ICB)

ICBs are used, among other aspects, in the Sysplex communication as coupling link for high-speed connections between systems.

OSA/Express

OSA/Express provides a zSeries channel connection for Ethernet devices such as switches or routers.

Channel-To-Channel (CTC)

Channel-To-Channel connections permit rapid connections between two zSeries computers and are supported by various software products such as JES3 and VTAM.

zSeries mainframe consoles

The Host Management Console (HMC) makes possible the following actions:

Two consoles (primary and alternate) can be connected. They are responsible for the complete system (all LPARs) and not just for a specific operating system. Access to these consoles must be well protected for security reasons.

The z/OS system consoles (MVS) are responsible for the control and monitoring of a z/OS operating system and can be configured for various purposes, e.g. as console for all messages from the tape pool. There can be several MVS consoles per z/OS; of these consoles, only one can be the master console. In case of an error, this console switches to the next available console. The access to the MVS consoles (especially to the master console) must be well protected for security reasons.

Remote Support Facility (RSF)

In most cases, zSeries systems are connected to the manufacturer via a remote console. This function automatically reports detected hardware and software problems so that errors can often be rectified before the user actually perceives an error. In principle, this connection also supports the installation of patches by the manufacturer; however, this action must be agreed in advance and the remote access connection must be protected adequately.

Parallel Sysplex concept

If the requirements can no longer be met by a system (of one LPAR), several LPARs can be combined into a logical cluster, the Parallel Sysplex. This cluster represents a unit to the outside.

The Parallel Sysplex is a combination of up to 32 z/OS systems; this corresponds to a maximum of 512 processors in a computer system. Within this system, loads can be distributed between the computers. If problems occur on a machine, the related machine can be removed from the system. The load is distributed across the machines remaining in the Sysplex.

Peripherals

Disks

Unlike other operating systems, the disk area of a z/OS operating system is divided into so-called volumes. A volume has a size (memory area) of approx. 2.7 GB with the emulation of a disk of type 3390 mod. 3 and is divided into cylinders and tracks.

The volumes are connected to control units. To increase the performance and operational security, it is possible to connect various control units in parallel. These control units are allocated specific tasks (e.g. JES spool file or system residence) and can be addressed using subchannel addresses.

Tape

The z/OS operating system supports various tape units, from individual stations to robot systems, in which the tapes are managed and provided automatically. In addition, there are also virtual tape systems (e.g. VTS from IBM or VSM from StorageTek) that first cache files on integrated hard disks. These files are then written to tape in these units in a very effective manner (compression and utilisation of the entire tape length).

VTS or VSM are processed by the z/OS operating system as tape unit 3490, i.e. a normal tape from the point of view of the operating system.

Printers

Printers are supported by the z/OS operating systems both directly on the channel and as network printers in the SNA or TCP/IP network. With a correspondingly large volume of printing, e.g. in print shops, z/OS systems also perform pure printing tasks.

Terminal family 327x

Classic 3270 terminals on the related control units are today practically no longer in operation. 3270-based terminals are, however, important in the form of PC terminal emulation and are still often in use (known as "green screen"). These terminals are based on the TN3270 protocol and can be operated like the earlier 327x terminals (from model 2 to model 5 in various screen formats).

SNA components (Systems Network Architecture)

SNA is a hierarchical network technology with pre-defined connections. The nodes in the network are usually hardware components and are referred to as Physical Units (PUs). The terminal points in the network are either software interfaces for an application (Application Control Block, ACB) or a terminal and/or terminal emulator or printer. In addition, the APPN (Advanced Peer-to-Peer Network) technology has also been available for some time; this technology is considerably different to the hierarchical form.

Today, SNA is rarely used as the only network protocol. SNA network installations are often replaced or supplemented with a TCP/IP network; as a result, the number of SNA hardware components in use is rapidly decreasing.

SNA topology

The hierarchical SNA network was laid out in such a manner that a front-end processor 3745/46 was connected under a VTAM. The control units, on which the end devices (terminals, printers or applications) were operated, were connected to the front-end processor. Although this constellation is still in use today, front-end processors and also control units are, however, no longer marketed by IBM (but they are still supported). Today, the connection to TCP/IP networks is mostly provided via the Enterprise Extender software function. SNA in its current version is primarily still used in computer centres to connect SNA-based applications such as TSO (Time Sharing Option), while the network is covered by TCP/IP.

Further information on SNA can be found in safeguard S 3.40 Introduction to the z/OS operating system in the section Communications Server.

Support Elements (SEs)

Each item of zSeries hardware has two Support Elements (S/390-G5 models have only one SE) that enable the system to be configured and controlled. SEs are connected with each other and to the processors via a fast internal Ethernet network (a Support Element is an IBM laptop PC). They provide system communication in the context of the Operator Facilities.

Firmware

Licensed Internal Code (LIC)

The microcode is on a further level between the hardware and software (Licensed Internal Code). There is no directly comparable feature on PCs for the LIC; the closest is the BIOS on a PC (see the section on the topic of IML).

Processor Resource/System Manager (PR/SM)

The Processor Resource/System Manager is an LIC function and enables the physical zSeries hardware to be logically divided into different parts, referred to as Logical Partitions (LPARs). Each logical computer has its own operating system; here, various operating systems can be utilised in parallel (for example, z/OS, OS/390, TPF, Linux or VSE/ESA on one item of hardware). The sharing of all resources is controlled by the PR/SM.

Initial Microcode Load (IML)

The IML is a process that loads the LIC into an inaccessible memory area. The IML always relates to the entire machine, i.e. IML entails that all LPARs on the machine are re-initialised (and, as a result, the operating systems stopped). IML is part of the Operator Facilities and can be activated using the HMC console. The calling of the IML must be protected appropriately.

Hardware Configuration Definition (HCD)

To adapt the software configuration to the hardware, a file (I/O Definition File, IODF) is generated, in which the logical subchannels are mapped to the physical channel path ID.

For this purpose, various tools are available to the operator. Only authorised personnel should have access to these tools.

Operating system

Various operating systems are available for the S/390 and the zSeries architectures (as at January 2004):

S/390 architecture (24 and 31 bit):

z/Series architecture (64 bit):

Further information on the OS/390 and z/OS operating systems can be found in safeguard S 3.40 Introduction to the z/OS operating system.

Operation

IML

A zSeries system is started with the Initial Microcode Load (IML). This operation is either initiated manually via the HMC console or is initiated automatically using appropriate definitions. The IML process loads the microcode and provides the system infrastructure (all LPARs available, no operating system loaded). During the IML process, the operator selects the required I/O configuration.

IPL

The z/OS operating system is activated with the Initial Program Load (IPL) from the Host Management Console (HMC). Here, the IPL load address and the IPL parameter string (load address of the IOCDS file) must be provided as a minimum. After the NIP-Phase (Nucleus Initialization Process), the z/OS system communicates with the operator using the MVS master console. The remaining steps depend on the operating system definitions. The system is activated either manually (exception) or automatically.

Operation

The operational tasks include the starting and stopping of tasks and jobs, activation of resources, responding to system queries (replies) and the provision of tape stations (if necessary).

Monitoring

The system communicates with the operator using messages and replies that are entered and output on the MVS console. It is therefore necessary to check the messages on a continuous basis. This action can be performed either manually (relatively time-consuming) or, preferably, by automatic means (separate programs). The same applies to the monitoring of batch processing.

Bibliography

A large amount of literature and documentation is available for the zSeries system. The following list is limited to the most important items that are also particularly relevant to the security of the zSeries system and available from IBM. However, this list makes no claim to completeness.

Redbooks

Form number Title
SG24-5975-nn IBM @server zSeries 900 Technical Guide
SG24-6863-nn IBM @server zSeries 990 Technical Introduction
SG24-6851-nn z/OS Version 1 Release 3 and 4 Implementation
SG24-6540-nn Putting the latest z/OS Security Features to work
SG24-7023-nn Linux on IBM eServer zSeries and S/390: Best Practices
SG24-6981-nn ABCs of z/OS System Programming Volume 1 (Introduction to z/OS and storage concepts, TSO/E, ISPF, JCL, SDSF, MVS delivery and installation)
SG24-6982-nn ABCs of z/OS System Programming Volume 2 (z/OS implementation and daily maintenance, defining subsystems, JES2 and JES3, LPA, LNKLST, authorized libraries, catalogs)
SG24-5653-nn ABCs of System Programming Volume 3 (Introduction to DFSMS, storage management)
SG24-5654-nn ABCs of System Programming Volume 4 (Communication Server, TCP/IP, and VTAM)
SG24-5655-nn ABCs of System Programming Volume 5 (Base and Parallel Sysplex, system logger, global resource serialization, z/OS system operations, automatic restart management, hardware management console, performance)
SG24-6989-nn ABCs of z/OS System Programming Volume 9 (z/OS UNIX System Services)
SG24-6990-nn ABCs of z/OS System Programming Volume 10 (Introduction to z/Architecture, zSeries processor design, zSeries connectivity, LPAR concepts, and HCD)
TIPS0382 z/OS V1R3 and V1R5 Technical Guide
SG24-7035-nn Unix System Services z/OS V1R4 Implementation
SG24-6968-nn Implementing PKI Services on z/OS
SG24-5637-nn OS/390 Parallel Sysplex Configuration Volume 1
SG24-5638-nn OS/390 Parallel Sysplex Configuration Volume 2
SG24-5639-nn OS/390 Parallel Sysplex Configuration Volume 3

IBM documentation

Form number Title
SA22-7832-nn z/Architecture Principles of Operation
SA22-7591-nn z/OS Initialization and Tuning Guide
SA22-7592-nn z/OS Initialization and Tuning Reference
SA22-7683-nn Security Server RACF Security Administrator's Guide
SA22-7681-nn Security Server RACF System Programmer's Guide
SA22-7682-nn Security Server RACF Macros and Interfaces
SA22-7684-nn Security Server RACF Auditor's Guide
SA22-7801-nn z/OS Unix System Services Users Guide
GA22-7800-nn z/OS Unix System Services Planning
SA22-7670-nn z/OS SDSF Operation and Customization
SA22-7532-nn z/OS JES2 Initialization and Tuning Guide
SA22-7533-nn z/OS JES2 Initialization and Tuning Reference
SA22-7549-nn z/OS JES3 Initialization and Tuning Guide
SA22-7550-nn z/OS JES3 Initialization and Tuning Reference
SA22-7783-nn z/OS TSO/E Customization
SA22-7692-nn z/OS MVS Planning: Workload Management
SA22-7597-nn z/OS MVS JCL Reference
SA22-7593-nn z/OS MVS Installation Exits
SC34-4826-nn HTTP Server Planning, Installing and Using
SC31-8775-nn z/OS CS: IP Configuration Guide
SC31-8776-nn z/OS CS: IP Configuration Reference
SA22-7600-nn z/OS MVS Planning: Global Resource Serialization
SA22-7623-nn z/OS MVS Recovery and Reconfiguration Guide
SA22-7625-nn z/OS MVS Setting up a Sysplex
SA22-7630-nn z/OS MVS System Management Facilities (SMF)
SA22-7642-nn z/OS MVS Using the Subsystem Interface
SC26-7402-nn z/OS DFSMSdfp Storage Administration Reference
SC35-0422-nn z/OS DFSMShsm Storage Administration Reference
SC26-7405-nn z/OS DFSMSrmm Implementation and Cust. Guide
SC26-7414-nn z/OS DFSMSdfp Utilities
SC33-7989-nn z/OS HCM User's Guide
GC35-0033-nn Device Support Facilities User's Guide and Reference
SH19-8163-nn MVS/DITTO V2 User's Guide and Reference
SC33-1701-nn CICS RACF Security Guide
SG24-5363-nn IMS V6 Security Guide