IBM Mainframe hardware

Mainframe concepts :

The original S/360™ architecture— based on CPUs, memory, channels, control units, and devices, and the way these are addressed— is fundamental to understanding mainframe hardware, because the concepts and terminology of the original design still permeate today's mainframe descriptions and designs.

The ability to partition a large system into multiple smaller systems, called logical partitions or LPARs, is now a core requirement in practically all mainframe installations. The flexibility of the hardware design, allowing any processor to access and accept interrupts for any channel, control unit, and device connected to a given LPAR, contributes to the flexibility, reliability, and performance of the complete system.

Unique to mainframes is the availability of a pool of processors that can be configured, or characterized, to do specific work. Having this processor capability provides great flexibility in meeting customer requirements, some of which are based on the cost structures of some mainframe software.

In addition to this pool of primary processors, mainframes have a network of controllers (special microprocessors) that control the system as a whole. These controllers are not visible to the operating system or application programs.

Mainframe hardware: Terminology :

In the early S/360™ days a system had a single processor, which was also known as the central processing unit (CPU). The terms system, processor, and CPU were used interchangeably. However, these terms became confusing when systems became available with more than one processor.

Processor and CPU can refer to either the complete system box, or to one of the processors (CPUs) within the system box. Although the meaning may be clear from the context of a discussion, even mainframe professionals must clarify which processor or CPU meaning they are using in a discussion. IBM® uses the term central processor complex (CPC) to refer to the physical collection of hardware that includes main storage, one or more central processors, timers, and channels. (Some system programmers use the term central electronic complex (CEC) to refer to the mainframe "box," but the preferred term is CPC.)

Briefly, all the S/390® or z/Architecture® processors within a CPC are processing units (PUs). When IBM delivers the CPC, the PUs are characterized as CPs (for normal work), Integrated Facility for Linux® (IFL), Integrated Coupling Facility (ICF) for Parallel Sysplex® configurations, and so forth.

Mainframe professionals typically use system to indicate the hardware box, a complete hardware environment (with I/O devices), or an operating environment (with software), depending on the context. They typically use processor to mean a single processor (CP) within the CPC.

Mainframe hardware: Processing units

Early mainframes had a single processor, which was known as the central processing unit (CPU). Today's IBM® mainframes have a central processor complex (CPC), which may contain several different types of z/Architecture® processors that can be used for slightly different purposes.

Several of these purposes are related to software cost control, while others are more fundamental. All of the processors in the CPC begin as equivalent processor units (PUs) or engines that have not been characterized for use. Each processor is characterized by IBM during installation or at a later time. The potential characterizations are:

Central Processor (CP)

This processor type is available for normal operating system and application software.

System Assistance Processor (SAP)

Every modern mainframe has at least one SAP; larger systems may have several. The SAPs execute internal code to provide the I/O subsystem. An SAP, for example, translates device numbers and real addresses of channel path identifiers (CHPIDs), control unit addresses, and device numbers. It manages multiple paths to control units and performs error recovery for temporary errors. Operating systems and applications cannot detect SAPs, and SAPs do not use any "normal" memory.

Integrated Facility for Linux® (IFL)

This is a normal processor with one or two instructions disabled that are used only by z/OS®. Linux does not use these instructions and can be executed by an IFL. Linux can be executed by a CP as well. The difference is that an IFL is not counted when specifying the model number of the system. This can make a substantial difference in software costs.

zAAP

This is a processor with a number of functions disabled (interrupt handling, some instructions) such that no full operating system can be executed on the processor. However, z/OS can detect the presence of zAAP processors and will use them to execute Java™ code. The same Java code can be executed on a standard CP. Again, zAAP engines are not counted when specifying the model number of the system. Like IFLs, they exist only to control software costs.

zIIP

The System z9® Integrated Information Processor (zIIP) is a specialized engine for processing eligible database workloads. The zIIP is designed to help lower software costs for select workloads on the mainframe, such as business intelligence (BI), enterprise resource planning (ERP) and customer relationship management (CRM). The zIIP reinforces the mainframe's role as the data hub of the enterprise by helping to make direct access to DB2® more cost effective and reducing the need for multiple copies of the data.

Integrated Coupling Facility (ICF)

These processors run only Licensed Internal Code. They are not visible to normal operating systems or applications. A coupling facility is, in effect, a large memory scratch pad used by multiple systems to coordinate work. ICFs must be assigned to LPARs that then become coupling facilities.

Spare

An uncharacterized PU functions as a "spare." If the system controllers detect a failing CP or SAP, it can be replaced with a spare PU. In most cases this can be done without any system interruption, even for the application running on the failing processor.

In addition to these characterizations of processors, some mainframes have models or versions that are configured to operate slower than the potential speed of their CPs. This is widely known as kneecapping , although IBM prefers the term capacity setting, or something similar. It is done by using microcode to insert null cycles into the processor instruction stream. The purpose, again, is to control software costs by having the minimum mainframe model or version that meets the application requirements. IFLs, SAPs, zAAPs, zIIPs, and ICFs always function at the full speed of the processor because these processors "do not count" in software pricing calculations. 

Mainframe hardware: Disk devices

BM® 3390 disk drives are commonly used on current mainframes.

Conceptually, this is a simple arrangement, as shown in Figure 1

 

The associated control unit (3990) typically has four channels connected to one or more processors (probably with a switch), and the 3390 unit typically has eight or more disk drives. Each disk drive has the characteristics explained earlier. This illustration shows 3990 and 3390 units, and it also represents the concept or architecture of current devices.

The current equivalent device is an IBM 2105 Enterprise Storage Server®, simplistically illustrated in Figure 2.

The 2105 unit is a very sophisticated device. It emulates a large number of control units and 3390 disk drives. It contains up to 11 TB of disk space, has up to 32 channel interfaces, 16 GB cache, and 284 MB of non-volatile memory (used for write queueing). The Host Adapters appear as control unit interfaces and can connect up to 32 channels (ESCON® or FICON®).

The physical disk drives are commodity SCSI-type units (although a serial interface, known as SSA, is used to provide faster and redundant access to the disks). A number of internal arrangements are possible, but the most common involves many RAID 5 arrays with hot spares. Practically everything in the unit has a spare or fallback unit. The internal processing (to emulate 3990 control units and 3390 disks) is provided by four high-end RISC processors in two processor complexes; each complex can operate the total system. Internal batteries preserve transient data during short power failures. A separate console is used to configure and manage the unit.

The 2105 offers many functions not available in real 3390 units, including FlashCopy®, Extended Remote Copy, Concurrent Copy, Parallel Access Volumes, Multiple Allegiance, a huge cache, and so forth.

A simple 3390 disk drive (with control unit) has different technology from the 2105 just described. However, the basic architectural appearance to software is the same. This allows applications and system software written for 3390 disk drives to use the newer technology with no revisions.

There have been several stages of new technology implementing 3390 disk drives; the 2105 is the most recent of these. The process of implementing an architectural standard (in this case the 3390 disk drive and associated control unit) with newer and different technology while maintaining software compatibility is characteristic of mainframe development. Maintaining application compatibility over long periods of technology change is an important characteristic of mainframes.