IBM Session-1

IBM System z10 is a line of IBM mainframes. The System z10 represents the first model family powered by the z10 quad core processing engine. Its successors are the zEnterprise System models introduced in 2010 and 2012.

The number of "characterizable" (or configurable) processing units (PUs) is indicated in the hardware model designation (e.g., the E26 has 26 characterizable PUs). Depending on the capacity model, a PU can be characterized as a Central Processor (CP), Integrated Facility for (IFL) processor, z Application Assist Processor (zAAP), z10 Integrated Information Processor (zIIP), or Internal (ICF) processor.

The System z10 supports the following IBM operating systems: z/OS, z/VSE, z/VM, and z/TPF

The z10 is a microprocessor chip made by IBM for their System z10 mainframe computers, released February 26, 2008.[1] It was called "z6" during development.[2]

The processor implements the CISC z/Architecture and has four cores. Each core has a 64 KB L1 instruction cache, a 128 KB L1 data cache and a 3 MB L2 cache (called the L1.5 cache by IBM). Finally, there is a 24 MB shared L3 cache (referred to as the L2 cache by IBM).

A million service units (MSU) is a measurement of the amount of processing work a computer can perform in one hour. It reflects how IBM rates the machine in terms of charging capacity. The technical measure of processing power on IBM mainframes, however, are Service Units per second (or SU/sec).

One “service unit” originally related to an actual hardware performance measurement (a specific model’s instruction performance). Most mainframe software vendors use a licensing and pricing model in which the customers are charged per MSU consumed (i.e. the number of operations the software has performed) in addition to hardware and software installation costs. Others charge by total MSU system capacity. Thus, while MSU is an artificial construction, it does have a direct financial implication. In fact, software charges are why the MSU measurement exists at all.

CPU seconds is still often, used by programmers to measure performance and chargeback. The problem is that the work done by a zEC 12 machine in one CPU second is not the same as other models. One z12 CPU second is different from one z10 CPU second. So, IBM introduced a standard measure called Service Units (SU). SU’s and MSU’s are an ingenious way to measure mainframe capacity irrespective of theprocessor or the workload.

IBM has published a table of SU_SEC SRM constants for every processor type. SU_SEC represents the amount of service units of work that can be processed in 1 second. E.g.: the SU_SEC rating for IBM z900 is 11,585. So, if a batch workload runs for 200 secs, it would consume 200 x 11,585 = 2,317,000 SU’s or 2.3 MSU’s. The total capacity of this box is 11,585 x 60 x 60 = 41,706,000 SU’s an hour or 41 MSU’s.

Customer Information Control System (CICS) is a transaction server that runs primarily on IBM mainframe systems under z/OS and z/VSE. It is middleware designed to support rapid, high-volume online transaction processing. A CICS transaction is a unit of processing initiated by a single request that may affect one or more objects. This processing is usually interactive (screen-oriented), but background transactions are possible.

Microcode is firmware (software that “lives” at a lower level than the operating system) that provides the actual hardware architecture customer programs expect. Advantages of microcoding include the ability to add new capabilities to existing hardware and also to fix incorrect operations without hardware changes. The S/360 line ranged from heavily microcoded machines at the low end to largely hardwired, high-end machines. All recent mainframes are microcoded; the Plug- Compatible Manufacturers (PCMs), including Amdahl and Hitachi, also used microcode, although Amdahl insisted on calling it “macrocode.” The existence of microcode is invisible to the user and to operations staff. On the latest IBM System z machines— the Business Class and Enterprise Class—microcode updates usually can be performed transparently without a system outage.

ESCON (Enterprise Systems Connection) is a data connection created by IBM, and is commonly used to connect their mainframe computers to peripheral devices such as disk storage and tape drives. ESCON is an optical fibre, half-duplex, serial interface. It originally operated at a rate of 10 Mbyte/s, which was later increased to 17Mbyte/s. The current maximum distance is 43 kilometers.

Optical fiber is smaller in diameter and weight, and hence could save installation costs. Space and labor could also be reduced when fewer physical links were required - due to ESCON's switching features. ESCON is being supplanted by the substantially faster FICON, which runs over Fibre Channel.

ESCON allows the establishment and reconfiguration of channel connections dynamically, without having to take equipment off-line and manually move the cables. ESCON supports channel connections using serial transmission over a pair of fibres. It also allows the distance between units to be extended up to 60 km over a dedicated fiber. “Permanent virtual circuits” are supported through the switch.

FICON (Fibre Connection) is the IBM proprietary name for the ANSI FC-SB-3 Single-Byte Command Code Sets-3 Mapping Protocol for Fibre Channel (FC) protocol. It is a FC layer 4 protocol used to map both IBM’s antecedent (either ESCON or parallel) channel-to-control-unit cabling infrastructure and protocol onto standard FC services and infrastructure. FICON uses two Fibre Channel exchanges for a channel - control unit connection—one for each direction. Each FICON channel port is capable of multiple concurrent data exchanges (a maximum of 32) in full duplex mode. Information for active exchanges is transferred in Fibre Channel sequences mapped as FICON Information Units (IUs) which consist of one to four Fibre Channel frames, only the first of which carries 32 bytes of FICON (FC-SB-3) mapping protocol. Each FICON exchange may transfer one or many such IUs. FICON channels use five classes of IUs to conduct information transfers between a channel and a control unit. They are: Data, Command, Status, Control, Command and Data, and lastly Link Control. Only a channel port may send Command or Command and Data IUs, while only a control unit port may send Status IUs.

IBM DB2 is a family of database server products developed by IBM. These products all support the relational model, but in recent years some products have been extended to support object-relational features and non- relational structures, in particular XML.

In IBM System z9 (and successor) mainframes, the System z Integrated Information Processor (zIIP) is a special purpose processor. It was initially introduced to relieve the general mainframe central processors (CPs) of specific DB2 processing loads, but currently is used to offload other z/OS workloads as described below. The idea originated with previous special purpose processors, the zAAP and IFL, which offload Java and Linux processing, respectively. A System z PU (processor unit) is "characterized" as one of these processor types, or as a CP (Central Processor), or SAP (Service Assist Processor). These processors do not contain microcode or hardware features that accelerate their designated workloads. Instead, by relieving the general CP of particular workloads, they often lead to a higher workload throughput at reduced license fees.

DB2 for z/OS V8 was the first application to exploit the zIIP, but now there are several IBM and non-IBM products and technologies that exploit Ziip

The IBM System z Application Assist Processors (zAAPs) is available on all IBM zEnterprise EC12, IBM zEnterprise, IBM System z10, and IBM System z9 servers. The zAAP specialty engine provides an attractively priced execution environment for web-based applications and SOA-based technologies, such as: • Java™ - for customers who desire the powerful integration advantages and traditional Qualities of Service of the IBM mainframe platform. • XML — for customers who desire cost effective XML parsing services on z/OS, z/OS XML System Services can exploit the zAAP for eligible XML workloads. When configured with general purpose processors within logical partitions running z/OS, zAAPs may help increase general purpose processor productivity and may contribute to lowering the overall cost of computing for z/OS Java technology-based applications. zAAPs are designed to operate asynchronously with the general processors to execute Java programming under control of the IBM Java Virtual Machine (JVM). This can help reduce the demands and capacity requirements on general purpose processors which may then be available for reallocation to other mainframe workloads.

The amount of general purpose processor savings will vary based on the amount of Java application code executed by zAAP(s). This is dependent upon the amount of Java cycles used by the relevant application(s) and on the zAAP execution mode selected by the customer.

use of zAAPs could reduce the number of TCP/IP programming stacks, firewalls, and physical interconnections (and their associated processing latencies) that might otherwise be required when the application servers and their database servers are deployed on separate physical server platforms.

The Integrated Facility for Linux (IFL) is a processor dedicated to Linux workloads on IBM System z servers. The IFL is supported by the z/VM virtualization and IBM Wave for z/VM software and the Linux operating system; it cannot run other IBM operating systems.

The attractively priced IFL processor enables you to add processing capacity exclusively for Linux workloads.

The fast speed of the IFL on the zEnterprise servers enables you to host more virtual servers per processor core than other server platforms. Combined with the up to 101 user-configurable IFLs on the zEC12 and up to 13 user-configurable IFLs on the zBC12, the total Linux processing capacity has enormously increased with the latest zEnterprise servers.

The Linux deployment on IFL’s can reduce your expenses in the areas of operational efforts, energy, floor space and especially in software.

A (LPAR) is the division of a computer's processor s, memory , and storageinto multiple sets of resources so that each set of resources can be operated independently with its own operating system instance and application s. The number of logical partitions that can be created depends on the system's processor model and resources available.

A Parallel Sysplex relies on one or more Coupling Facilities (CFs). A coupling facility is a mainframe processor (runs in an own LPAR, with dedicated physical CP, defined thru HMC), with memory and special channels (CF Links), and a specialised operating system called Coupling Facility Control Code (CFCC). It has no I/O devices, other than the CF links. The information in the CF resides entirely in memory as CFCC is not a virtual memory operating system. A CF typically has a large memory – of the order of several gigabytes. In principle any IBM mainframe can serve as a coupling facility. The CF runs no application software.

Control blocks are the memory units which represents/contains the status of what is going on or what has just happened, in short the TASK information when task is executed in the operating system. It provides the information about the job, CICS task and much other information.

Types of Control Blocks:

System Related Control Blocks Resource Related Control Blocks Job Related Control Blocks Task Related Control Blocks z/OS® is made up of programming instructions that control the operation of the computer system.

These instructions ensure that the computer hardware is being used efficiently and is allowing application programs to run. z/OS includes sets of instructions that, for example, accept work, convert work to a form that the computer can recognize, keep track of work, allocate resources for work, execute work, monitor work, and handle output. A group of related instructions is called a routine or module. A set of related modules that make a particular system function possible is called a system component. The workload management (WLM) component of z/OS, for instance, controls system resources, while the recovery termination manager (RTM) handles system recovery.

Sequences of instructions that perform frequently used system functions can be invoked with executable macro instructions, or macros. z/OS macros exist for functions such as opening and closing data files, loading and deleting programs, and sending messages to the computer operator.

As programs execute the work of a z/OS system, they keep track of this work in storage areas known ascontrol block. In general, there are four types of z/OS control blocks:

• System-related control blocks

• Resource-related control blocks

• Job-related control blocks

• Task-related control blocks

Each system-related control block represents one z/OS system and contains system-wide information, such as how many processors are in use. Each resource-related control block represents one resource, such as a processor or storage device. Each job-related control block represents one job executing on the system. Each task-related control block represents one unit of work.

Control blocks serve as vehicles for communication throughout z/OS. Such communication is possible because the structure of a control block is known to the programs that use it, and thus these programs can find needed information about the unit of work or resource. Control blocks representing many units of the same type may be chained together on queues, with each control block pointing to the next one in the chain. The operating system can search the queue to find information about a particular unit of work or resource, which might be:

• An address of a control block or a required routine

• Actual data, such as a value, a quantity, a parameter, or a name

• Status flags (usually single bits in a byte, where each bit has a specific meaning) z/OS uses a huge variety of control blocks, many with very specialized purposes. The three most commonly used control blocks are:

• Task control block (TCB), which represents a unit of work or task

• Service request block (SRB), which represents a request for a system service

• Address space control block (ASCB), which represents an address space

Physical storage used by z/OS z/OS concepts

Conceptually, mainframes and all other computers have two types of physical storage: Internal and external.

• Physical storage located on the mainframe processor itself. This is called processor storage, real storage or central storage; think of it as memory for the mainframe.

• Physical storage external to the mainframe, including storage on direct access devices, such as disk drives and tape drives. This storage is called paging storage or auxiliary storage.

The primary difference between the two kinds of storage relates to the way in which it is accessed, as follows:

• Central storage is accessed synchronously with the processor. That is, the processor must wait while data is retrieved from central storage.

• Auxiliary storage is accessed asynchronously. The processor accesses auxiliary storage through an input/output (I/O) request, which is scheduled to run amid other work requests in the system. During an I/O request, the processor is free to execute other, unrelated work.

As with memory for a personal computer, mainframe central storage is tightly coupled with the processor itself, whereas mainframe auxiliary storage is located on (comparatively) slower, external disk and tape drives. Because central storage is more closely integrated with the processor, it takes the processor much less time to access data from central storage than from auxiliary storage. Auxiliary storage, however, is less expensive than central storage. Most z/OS® installations use large amounts of both.

In 1976, IBM® set the standard for security products when RACF® was introduced! From the beginning, the RACF Development Team has proudly brought you RACF, thepremier product for securing your most valuable corporate data. Working closely with your operating system's existing features, IBM's award-winning Resource Access Control Facility (RACF) licensed program provides improved security for an installation's data. RACF protects your vital system resources and controls what users can do on the operating system.

You decide which resources you want to protect and which users need access to them. RACF provides the functions that let you:

• identify and verify system users • identify, classify, and protect system resources • authorize the users who need access to the resources you've protected • control the means of access to these resources • log and report unauthorized attempts at gaining access to the system and to the protected resources • administer security to meet your installation's security goals.

RACF - Resource Access Control Facility, is an IBM software product. It is a security system that provides access control and auditing functionality for the z/OS and z/VM operating systems. RACF was introduced in 1976. Its main features are:[1]

• Identification and verification of a user via user id and password check (authentication)

• Identification, classification and protection of system resources

• Maintenance of access rights to the protected resources (authorization)

• Control the means of access to protected resources

• Logging of accesses to a protected system and protected resources (auditing)

RACF establishes security policies rather than just permission records. It can set permissions for file patterns — that is, set the permissions even for files that do not yet exist. Those permissions are then used for the file (or other object) created at a later time .