Mainframe Overview

"What is a mainframe?" Today, the term mainframe can best be used to describe a style of operation, applications, and operating system facilities. To start with a working definition, a mainframe is what businesses use to host the commercial databases, transaction servers, and applications that require a greater degree of security and availability than is commonly found on smaller-scale machines

z/OS is a 64-bit operating system for Mainframe.z/OS supports stable mainframe systems and standards such as CICS, IMS, DB2, RACF, SNA, WebSphere MQ, record-oriented data access methods, REXX, CLIST, SMP/E, JCL, TSO/E, and ISPF, among others. However, z/OS also supports 64-bit Java, C,C++, and UNIX (Single UNIX Specification) APIs and applications through UNIX System Services  — The Open Group certifies z/OS as a compliant UNIX operating system — with UNIX/Linux-style hierarchical HFS^{[NB 2]} and zFS file systems. As a result, z/OS hosts a broad range of commercial and open source software.^[2] z/OS can communicate directly via TCP/IP, including IPv6,^[3] and includes standard HTTP servers (one from Lotus, the other Apache-derived) along with other common services such as FTP, NFS, andCIFS/SMB. Another central design philosophy is support for extremely high quality of service (QoS), even within a single operating system instance, although z/OS has built-in support for Parallel Sysplex clustering.

Mainframe workloads: Batch and online transaction processing Mainframe concepts

Most mainframe workloads fall into one of two categories: Batch processing or online transaction processing, which includes Web-based applications. One key advantage of mainframe systems is their ability to process terabytes of data from high-speed storage devices and produce valuable output. For example, mainframe systems make it possible for banks and other financial institutions to perform end-of-quarter processing and produce reports that are necessary to customers (for example, quarterly stock statements or pension statements) or to the government (for example, financial results). With mainframe systems, retail stores can generate and consolidate nightly sales reports for review by regional sales managers. The applications that produce these statements are batch applications, which are illustrated at the top of Figure 1. In contrast to batch processing, transaction processing occurs interactively with the end user. This interaction is outlined at the bottom of Figure 1. Typically, mainframes serve a vast number oftransaction systems. These systems are often mission-critical applications that businesses depend on for their core functions. Transaction systems must be able to support an unpredictable number of concurrent users and transaction types. Most transactions are executed in short time periods— fractions of a second in some cases. Figure 1. Typical mainframe workloads SAP on Mainframe Delivers High Availability and More he first, “Where SAP and System z Intersect,” outlined the components that make up an SAP system while the final looks at the benefits of running SAP on System z. Why do customers choose to run their SAP systems on System z? The primary reason is their applications require 24x7x52 availability and operation. Each of the SAP components represent a single point of failure, but System z hardware features and z/OS software features, along with changes to SAP technology layer components, eliminate those single points of failure. Let’s examine several in more detail. Parallel Sysplex IBM Parallel Sysplex technology provides the hardware-supported clustering functions exploited by DB2 in data-sharing mode. This makes the SAP database server nearly continuously available. With the I/O subsystem design, all DASD is shared by all System z boxes in the Sysplex. The data is always available to the application. In concert, the SAP application severs have function (called Sysplex failover) to quickly reconnect to surviving DB2 members in the DB2 data-sharing group. As noted previously, if the SAP database server is unavailable, the SAP system is down. In the event of some error, users will experience a momentary interruption—rather than an unplanned outage. This is made possible by special functionality built into the SAP application server to move workload automatically from one DB2 member to another. Other special built-in functions permit SAP system programmers to gracefully move SAP workload from one DB2 member to another, thereby decreasing the duration of planned outages of the SAP system. IBM DB2 development’s goal is the elimination of all resource unavailable conditions (i.e., SQL Code -904), and all applications, including SAP, benefit from this. SAP Central Services The SAP central services (SCS) function provides the locking mechanism SAP applications use to ensure transactional integrity. Early adopters of SAP on DB2 for z/OS (zSAP) pointed out to SAP that its central instance was a single point of failure. SAP responded with a redesigned version, enhanced to have a mirrored copy of the lock table on another server maintained by the enqueue replication server (ERS). This enhancement makes SCS continuously available. There’s no outage whatsoever in the SAP locking function when the primary enqueue server fails and is restarted on the backup server. SAP end users will see only a slight delay while automation software relocates the SCS. The SCS has been enhanced recently to enable customers to store the backup lock table in the IBM System z coupling facility. This enhancement speeds up SAP lock processing a bit but, more importantly, it increases availability. Also, it simplifies the Tivoli system automation policy for monitoring this component. The SCS can be restarted in any LPAR of the Parallel Sysplex, rather than having to be restarted in the z/OS LPAR where the ERS is running. SAP Application Server SAP application server availability is typically accomplished by having more than one of them. Through the SAP logon-groups function, if an application server fails, the user gets logged out. The user must log back in and the logon-groups function will determine which surviving application server the end user can use. Note that when users log in, they will be assigned to one application server. The end user remains connected to that particular application server for the life of the logon session. In the case of the SAP application server running on Linux on System z under z/VM, a customer can avoid a planned application outage by exploiting z/VM's single system image (SSI) and live guest relocation (LGR). Exploiting this feature allows maintenance of z/VM and Linux on System z guests without an application outage. Network All SAP components communicate with each other using TCP sessions. This means the network has the potential to be a single point of failure. The z/OS communications server solves this problem with something called a virtual IP address. Basically, the z/OS TCPIP stack allows creation of an IP address that belongs to an application or host, rather than an I/O port. Under the open shortest path first (OSPF) protocol, the network software learns the network high-availability topology (i.e., multiple network ports per LPAR). So if a network link fails, the OSPF protocol will allow network software to choose the next path between SAP components. The end user and application will see an extended response time while the session’s path is being re-routed. Virtualization and Workload Management The latest generations of System z machines are very powerful, and it’s rare a single SAP system can utilize the entire machine. System z firmware allows the physical box to be divided into LPARS. One can share the physical capacity in almost any combination. This is a perfect match for customers who have multiple SAP landscapes. The basic idea is to create LPARs for each lifecycle system in an SAP landscape. They could create separate LPARs for those systems related to: sandboxing, development, testing, quality assurance and production. If the application server is run under Linux on System z, they could create the LPARs in pairs—one for z/OS and one for z/VM. This setup is perfect for IT folks to slowly rollout hardware and software maintenance. By the time the new software level reaches the SAP production systems, it has been thoroughly tested. In the latest firmware, the intelligent resource director (IRD) and workload manager (WLM) enable the system to move CPU resource to LPARs that need the extra horsepower. IRD with WLM can vary only regular engines on and offline. With the edition of the HiperDispatch function, the system can make better use of limited cache memory by ensuring the same workload is run repeatedly against the same physical CPUs. HiperDispatch works for regular System z Integrated Information Processor (zIIP) and System z Application Assist Processor (zAAP) engines. All of this function allows you to do more with less. Resource utilization is maximized, with few idle MIPS. Vertical and Horizontal Scalability SAP systems scale smoothly with either vertical or horizontal growth of System z hardware. For vertical scaling, the latest enhancement in DB2 V10 allows for thousands of sessions from the call-level interface (CLI) driver into the DB2 subsystem. For horizontal scaling, SAP provides function to control which application servers communicate with which DB2 data-sharing members. This helps eliminate DB2 inter-systems interest and allows for better use of DB2 memory buffers—resulting in less churn. zIIP Engine Exploitation SAP was the first application/solution to exploit zIIP engines. Its application server connects to the SAP database server via the DB2 CLI driver. It, in turn, uses the distributed relational database architecture (DRDA) protocol over TCP to introduce work to the database server. This applies to all of the distributed SAP application servers—AIX, Linux and Windows—as well as Linux on System z. IFL Engine and Internal HiperSockets Exploitation When the SAP application server runs on Linux on System z, with or without z/VM, more economical IFL engines can be used. If the application server is running on the same physical System z box as the SAP database server, then HiperSockets (network in a box) can be exploited as well. HiperSockets allows network packets to be sent and received at main-memory and CPU speeds. They’re also very secure. Database Management DB2 for z/OS can compress the data on disk thereby reducing costs associated with DASD. DB2 exploits hardware instructions to compress the data in tables, and the indices are compressed as well with software-based algorithms. The DB2 backup system utility, in concert with hierarchical storage management (HSM) and FlashCopy functions, enables non-disruptive, online, full-system and incremental backups. All 80,000-plus tables and 100,000-plus indices are backed up with one utility invocation. The SAP systems keep up chugging. The DB2 restore system utility is available to restore very rapidly to current time or to a prior point in time, determined by the business. HSM and FlashCopy are also used on the restore side. In customer environments that run combinations of SAP applications, all of the applications can be recovered to a common point in time, if necessary. This is enabled by the DB2 log record sequence number (LRSN), which is basically a timestamp on DB2 log records. Integration with DB2 for z/OS DB2 V5 was the first version to support SAP. Since those early days, IBM and SAP have worked to optimize DB2 for SAP and for SAP to exploit the HA features in DB2 and System z. From DB2 V6 to V10, hundreds of enhancements have been added. The latest, DB2 V10, nearly eliminates all virtual memory constraints to allow for very high vertical scalability. Even with these enhancements, customers should still consider at least two DB2 members hosted on separate System z central electronics complex to ensure no single points of failure—such as a system operator error—can take down the SAP system.