Example: the ZOS Company data center

The sample configuration illustrates a medium-to-large z/OS data center. Processing is divided up physically by central processor complexes and logically by logical partitions.

A central processor complex (CPC) is a physical collection of hardware that consists of main storage, one or more central processors, timers, and channels.
A logical partition (LPAR) is a subset of a single physical system that contains resources (processors, memory, and input/output devices), and which operates as an independent system.

Figure 1. Sample configuration

Figure 1 shows a TCP/IP stack and VTAM address space running under each z/OS operating system. It is normal to run only one instance of TCP/IP per LPAR, but some situations may dictate additional TCP/IP stacks on an LPAR (for example, where a business requires external partners to connect through a separate connection or network).

Other components in Figure 1 are:

CICS: Customer Information Control System. Provides transaction management functions and connectivity to application programs. Runs as an address space in z/OS.
CF: Coupling Facility. Enables sharing of data between multiple LPARs using high speed channels. Communicates LPAR status information.
DB2 for z/OS: Relational database product used on most mainframe customer sites. Runs as an address space in z/OS.
OSA: Open Systems Adapter. High speed integrated cards used for network communication.
OSPF: Open Shortest Path First. Routing protocol used to communicate between router and mainframe TCP/IP OMPROUTE application.
TSO: Time Sharing Option. An element of z/OS that enables users to create an interactive session with the z/OS system. TSO provides a single-user logon capability and a basic command prompt interface to z/OS. Similar to a PC command prompt window.
VTAM: Virtual Telecommunications Access Method. The original SNA networking protocol for mainframes. Provides services to TCP/IP as well. Runs as an address space in z/OS.
TCP/IP: TCP/IP server address spaces.

In reality, there would be more CPCs and LPARs. Most large organizations would duplicate this data center at another location as a backup for disaster recovery or site swap, in which processing is moved to this duplicate site. The disks would be also mirrored between sites.

Mainframe servers require minimal downtime, but sometimes microcode updates are required that might include resetting the server (this is called a power-on reset). There are also external influences that can cause an outage, such as changes to the data center infrastructure or router (connectivity) changes. In our sample configuration, in order to allow business processes to continue during downtime, the ZOS Company has two mainframe CPCs. When one CPC is down, the second CPC can continue to run the business.

For the purposes of this example only three LPARs per CPC are shown. In reality there might be many more. A minimum configuration might include three LPARs per CPC (one production LPAR, one development or quality assurance LPAR, and one systems programming test LPAR).

Production LPAR. The primary Production1 LPAR would normally run on a different CPC than that of the secondary or backup Production2 LPAR, again to allow for flexibility or outages. The Primary Production1 LPAR might be the normal network owner, but the Production2 LPAR should also be able to take over this function, along with the production applications.
Development LPAR. The Development/QA1 LPAR might also need a backup; this is insurance in case application programmers run tests on new applications that affect the LPAR. The development LPAR is used to develop new software.
Most large organizations have in-house programmers responsible for creating and maintaining applications that are specific to the organization's needs. These applications are created, tested, and maintained on the development LPAR.
Test LPAR. A test LPAR is sometimes also referred to as a system programming LPAR. A test LPAR generally provides the basis for software delivery and early testing of changes and new functions. It is also where maintenance would be applied and tested prior to the fixes being implemented in production.
Ideally, the test LPAR should be as similar to the production LPAR as possible. This might then include a second systems programming LPAR on each CPC, providing an extra level of confidence when migrating changes through the system (though there is nothing like the real production acid test).

The LPARs would also have network connections to each other by way of inter-CPC and intra-CPC hardware and software features.

Isolating the production LPARs

Production LPARs are critical to maintaining an organization's viability.

Although Figure 1 does not show it, the production LPARs are normally isolated logically (and sometimes physically) from the test and development LPARs. This is achieved by using a Parallel Sysplex, usually just called a sysplex. A sysplex is a clustering technique involving software and physical components. This technique helps with availability and workload balancing and protects environments from each other.

There would be a production sysplex for the production LPARs and a test or development sysplex for the remaining systems. Some organizations may have many sysplex systems. With the ability to define multiple independent sysplexes, even LPARs within a single CPC can be isolated logically by participating in separate sysplexes.

The main lesson to learn from Figure 1 is that duplicate components are in place to allow for scheduled and unscheduled outages, and provide the availability that z/OS customers expect.