z/OS: z/OS, a widely used mainframe operating system, is designed to offer a stable, secure, and continuously available environment

for applications running on the mainframe. z/OS today is the result of decades of technological advancement. It evolved from an operating system that could process a single program at a time to an operating system that can handle many thousands of programs and interactive users concurrently. To understand how and why z/OS functions as it does, it is important to understand some basic concepts about z/OS and the environment in which it functions. In most early operating systems, requests for work entered the system one at a time. The operating system processed each request or job as a unit, and did not start the next job until the one being processed had completed. This arrangement worked well when a job could execute continuously from start to completion. But often a job had to wait for information to be read in from, or written out to, a device such as a tape drive or printer. Input and output (I/O) take a long time compared to the electronic speed of the processor. When a job waited for I/O, the processor was idle. Finding a way to keep the processor working while a job waited would increase the total amount of work the processor could do without requiring additional hardware. z/OS gets work done by dividing it into pieces and giving portions of the job to various system components and subsystems that function interdependently. At any point in time, one component or another gets control of the processor, makes its contribution, and then passes control along to a user program or another component.

Features of z/Architecture: 64-bit storage: Increased capacity of central memory from 2 GB to 16 exabytes eliminates most storage constraints. 64-bit storage also allows for 16 exabytes of virtual address space, a huge step in the continuing evolution of increased virtual storage. In addition to improving DB2 performance, 64bit storage improves availability and scalability, and it simplifies storage management. Special Engines: With special processors, such as the System z Integrated Information Processor (zIIP), DB2 achieves higher degrees of query parallelism and higher levels of transaction throughput. The zIIP is designed to improve resource optimization and lower the cost of eligible workloads, enhancing the role of the mainframe as the data hub of the enterprise.

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. High Security: z/OS and its predecessors have provided robust security for decades. Security features deliver privacy for users, applications, and data, and these features protect the integrity and isolation of running processes. Current security functions have evolved to include comprehensive network and transaction security that operates with many other operating systems. Enhancements to the z/OS Security Server provide improved security options, such as multilevel security. Cluster technology: The z/OS Parallel Sysplex provides cluster technology that achieves availability 24 hours a day, 7 days a week. Cluster technology also provides the capability for horizontal growth. Horizontal growth solves the problems of performance overheads and system management issues that you typically encounter when combining multiple machines to access the same database. With horizontal growth, you achieve more scalability; your system can grow beyond the confines of a single machine while your database remains intact. Solid-state drives: Solid-state drives (SSDs) are more reliable, consume less power, and generate less heat than traditional hard disk drives (HDDs). SSDs can also improve the performance of online transaction processing. SSDs are especially efficient at performing random access requests, and they provide greater throughput than HDDs. Some IBM System Storage series allow a combination of HDDs and SSDs. FICON channels: These channels offer significant performance benefits for transaction workloads. FICON features, such as a rapid data transfer rate (4 GB per second), also result in faster table scans and improved utility performance.

The DB2 address spaces DB2 requires several different address spaces.

Various tasks are performed in the different address spaces, as follows: DSN1MSTR for system services that perform a variety of system-related functions. DSN1DBM1 for database services that manipulate most of the structures in user-created databases. DSN1DIST for distributed data facilities that provide support for remote requests. IRLMPROC for the internal resource lock manager (IRLM), which controls DB2 locking. DSN1SPAS for stored procedures, which provide an isolated execution environment for user-written SQL.

Intersystem Resource Lock Manager (IRLM) Address Space The third address space required by DB2 is the IRLM, or Intersystem Resource Lock Manager. The IRLM is responsible for managing DB2 locks (including deadlock detection). The default name of this address space is IRLMPROC. 1. Provides necessary controls for managing concurrent access to data using the IRLM. 2. IRLM-IMS resource manager is an MVS system and a general-purpose lock managerthat aids in maintaining data integrity.

System Services Address Space The SSAS, or System Services Address Space, coordinates the attachment of DB2 to other subsystems (CICS, IMS/DC, or TSO). SSAS is also responsible for all logging activities (physical logging, log archival, and BSDS). DSNMSTR is the default name for this address space. 1. Controlling connections to other MVS subsystems like CICS, IMS/DC, TSO etc. 2. Handles system start-up, shutdown and operator communication. Managing the system log, which records the information necessary for recovering user and system data in case of system failure. When the active log dataset becomes full the system shifts to a new dataset and copies the old data to archive log. 3. Information regarding the log datasets is recorded on a system dataset called the bootstrap dataset.

Database Services Address Space: The DBAS, or Database Services Address Space provides the facility for manipulating DB2 data structures. The default name for this address space is DSNDBM1, but each individual shop may rename any of the DB2 address spaces. The DBAS is responsible for running SQL statements and managing data buffers. It contains the core logic of the database management system. Three individual components make up the DBAS: the Relational Data System, the Data Manager, and the Buffer Manager. Each of these components perform specific tasks. 1. Supports the definition, retrieval and update of DB2 data using a series of six sub components. Distributed Data Facility : It is used to communicate with other DB2 Subsystems. The fourth DB2 Version 3 address space, DDF, or Distributed Data Facility, is the only optional one. The DDF is required only if distributed database functionality is required. 1. Distributed DB2 requests are carried out through DDF 2. Enables database access by remote systems SPAS: The newest address space, SPAS, or Stored Procedure Address Space, has been added to DB2 Version 4 to support stored procedures and remote procedure calls (RPC's). The SPAS runs as an allied address space providing an independent environment for stored procedures to execute. This effectively isolates the user-written stored procedure code in its own little world so that it cannot interfere with the system code of DB2 itself.

How CICS connects to DB2 A CICS DB2 attachment facility is provided with CICS. The CICS DB2 attachment facility provides CICS applications with access to DB2 data while operating in the CICS environment. CICS coordinates recovery of both DB2 and CICS data if transaction or system failure occurs. The CICS DB2 attachment facility creates an overall connection between CICS and DB2. CICS applications use this connection to issue commands and requests to DB2. The connection between CICS and DB2 can be created or terminated at any time, and CICS and DB2 can be started and stopped independently. You can name an individual DB2 subsystem to which CICS connects, or (if you have DB2 Version 7 or later) you can use the group attach facility to let DB2 choose any active member of a data-sharing group of DB2 subsystems for the connection. You also have the option of CICS automatically connecting and reconnecting to DB2. A DB2 system can be shared by several CICS systems, but each CICS system can be connected to only one DB2 subsystem at a time. You define the CICS DB2 connection using three different CICS resource definitions: DB2CONN (the DB2 connection definition), DB2ENTRY (the DB2 entry definition), and DB2TRAN (the DB2 transaction definition). You must install a DB2CONN resource definition before you can start the CICS DB2 connection. (Do not confuse this resource definition with the DB2CONN system initialization parameter, which specifies whether you want CICS to start the DB2 connection automatically during initialization.) You can also create DB2ENTRY and, if necessary, DB2TRAN definitions to ensure that your important transactions are prioritized. Overview: How you can define the CICS DB2 connection has more information about these resource definitions. Attachment commands display and control the status of the CICS DB2 attachment facility, and are issued using the CICS supplied transaction DSNC. The attachment commands are:

STRT - start the connection to DB2 STOP - stop the connection to DB2 DISP - display the status of threads, and display statistics MODI - modify characteristics of the connection to DB2 DISC - disconnect threads

The connection between CICS and DB2 is a multithread connection. Within the overall connection between CICS and DB2, there is a threadan individual connection into DB2for each active CICS transaction accessing DB2. Threads allow each CICS transaction to access DB2 resources, such as a command processor or an application plan (the information that tells DB2 what the application program's SQL requests are, and the most efficient way to service them). See Overview: How threads work for a full explanation of how threads work. When an application program operating in the CICS environment issues its first SQL request, CICS and DB2 process the request as follows:

A language interface, or stub, DSNCLI, that is link-edited with the application program calls the CICS resource manager interface (RMI). The RMI processes the request, and passes control to the CICS DB2 attachment facility's task-related user exit (TRUE), the module that invokes DB2 for each task. The CICS DB2 attachment facility schedules a thread for the transaction. At this stage, DB2 checks authorization, and locates the correct application plan. DB2 takes control, and the CICS DB2 attachment facility waits while DB2 services the request. When the SQL request completes, DB2 passes the requested data back to the CICS DB2 attachment facility. CICS now regains control, and the CICS DB2 attachment facility passes the data and returns control to the CICS application program. The DB2 address spaces DB2 requires several different address spaces.

DFSMS: Data Facility Product (DFSMSdfp) is the heart of the storage management subsystem; it provides the logical and physical input and output for z/OS storage, it keeps track of all data and programs managed within z/OS, and it provides data access both for native z/OS applications and other platforms such as AIX/UNIX, the Windows family, AS/400, or OS/2. DFSMSdfp provides storage, data, program, and device management functions. You can use the DFSMSdfp Storage Management Subsystem (SMS) to manage DB2 disk data sets. The purpose of DFSMS is to automate as much as possible the management of physical storage by centralizing control, automating tasks, and providing interactive controls for system administrators. DFSMS can reduce user concerns about physical details of performance, space, and device management. Consult with your storage administrator about using DFSMS for DB2 private data, image copies, and archive logs. Data that is especially performance-sensitive might necessitate more manual control over data set placement. Table spaces or indexes with data sets larger than 4 GB require DFSMS-managed data sets. Extended partitioned data sets (PDSE), a feature of DFSMSdfp, are useful for managing stored procedures that run in a stored procedures address space. PDSE enables extent information for the load libraries to be dynamically updated, reducing the need to start and stop the stored procedures address space. You can use the Storage Management Subsystem (DFSMS) to manage DB2 data sets automatically and reduce the administrative workload for database and systems administrators. DFSMS enables easier allocation and movement of data, better availability and performance management, and automated space management. The performance benefit is most important: DFSMS lets you set performance goals for each class of data, thereby reducing the need for manual tuning. This environment also uses the cache provided by the storage hardware.

Role of DFSMS in managing space z/OS concepts

The primary means of managing space in z/OS is through the Data Facility Storage Management Subsystem (DFSMS), which comprises a suite of related data and storage management products. DFSMS performs the essential data, storage, program, and device management functions of the system. In a z/OS system, space management involves the allocation, placement, monitoring, migration, backup, recall, recovery, and deletion of data sets. These activities can be done either manually or through the use of automated processes. When data management is automated, the operating system determines object placement and automatically manages data set backup, movement, space, and security. A typical z/OS production system includes both manual and automated processes for managing data sets. Depending on how a z/OS system and its storage devices are configured, a user or program can directly control many aspects of data set usage, and in the early days of the operating system, users were required to do so. Increasingly, however, z/OS customers rely on installationspecified settings for data and resource management, and space management products, such as DFSMS, to automate the use of storage for data sets. Data management includes these main tasks:

Setting aside (allocating) space on DASD volumes. Automatically retrieving cataloged data sets by name. Mounting magnetic tape volumes in the drive. Establishing a logical connection between the application program and the medium. Controlling access to data. Transferring data between the application program and the medium.

DFSMS, together with hardware products and installation-specific settings for data and resource management, provides system-managed storage in a z/OS environment. The heart of DFSMS is the Storage Management Subsystem (SMS). Using SMS, the system programmer or storage administrator defines policies that automate the management of storage and hardware devices. These policies describe data allocation characteristics, performance and availability goals, backup and retention requirements, and storage requirements for the system. SMS governs these policies for the system, and the Interactive Storage Management Facility (ISMF) provides the user interface for defining and maintaining the policies. The data sets allocated through SMS are called system-managed data sets or SMS-managed data sets. When you allocate or define a data set to use SMS, you specify the data set requirements

through a data class, a storage class, and a management class. Typically, you do not need to specify these classes because a storage administrator has set up automatic class selection (ACS) routines to determine which classes are used for a given data set. DFSMS provides a set of constructs, user interfaces, and routines (using the DFSMS products) to help the storage administrator. The core logic of DFSMS, such as the ACS routines, ISMF code, and constructs, resides in DFSMSdfp. DFSMShsm and DFSMSdss are involved in the management class construct. With DFSMS, the z/OS system programmer or storage administrator can define performance goals and data availability requirements, create model data definitions for typical data sets, and automate data backup. DFSMS can automatically assign, based on installation policy, those services and data definition attributes to data sets when they are created. IBM storage management-related products determine data placement, manage data backup, control space usage, and provide data security. What is RACF? Security on z/OS

Resource Access Control Facility or RACF provides the tools to help the installation manage access to critical resources. Any security mechanism is only as good as the management control of the people who access the system. Access, in a computer-based environment, means the ability to do something with a computer resource (for example, use, change, or view something). Access control is the method by which this ability is explicitly enabled or restricted. It is the responsibility of the installation to see that access controls that are implemented are working the way they are supposed to work, and that variances are reported to and acted on by management. Computer-based access controls are called logical access controls. These are protection mechanisms that limit users' access to information to only what is appropriate for them. Logical access controls are often built into the operating system, or can be part of the logic of application programs or major utilities, such as database management systems. They may also be implemented in add-on security packages that are installed into an operating system; such packages are available for a variety of systems, including PCs and mainframes. Further, logical access controls might be present in specialized components that regulate communications between computers and networks. To be effective, access control must allow management to adopt the principle of least possible privilege for those resources that are deemed to be highly sensitive. This principle says that access to these resources is controlled in such a way that permission to use them is restricted to just those people whose normal duties require their use. Any unusual use of the resource should be approved by an administrator or manager, as well as the owner of the resource. Resource Access Control Facility or RACF provides the tools to manage user access to critical resources. RACF is an add-on software product that provides basic security for a mainframe

system (examples of other security software packages include ACF2 and Top Secret, both from Computer Associates). RACF protects resources by granting access only to authorized users of the protected resources. RACF retains information about users, resources, and access authorities in special structures called profiles in its database, and it refers to these profiles when deciding which users should be permitted access to protected system resources. To help your installation accomplish access control, RACF provides the ability to:

Identify and authenticate users Authorize users to access protected resources Log and report various attempts of unauthorized access to protected resources Control the means of access to resources Allow applications to use the RACF macros

RACF uses a user ID and a system-encrypted password to perform its user identification and verification. The user ID identifies the person to the system as a RACF user. The password verifies the user's identity. Often exits are used to enforce a password policy such as a minimum length, lack of repeating characters or adjacent keyboard letters, and also the use of numerics as well as letters. Popular words such as "password" or the use of the user ID are often banned. The other important policy is the frequency of password change. If a user ID has not been used for a long time, it may be revoked and special action is needed to use it again. When someone leaves a company, there should be a special procedure that ensures that the user IDs are deleted from the system. RACF, with its lists of users and lists of resources, allows management to delegate the authority to the owners of these entities in such a way as to maintain the separation of duties while maintaining a flexible, responsive access control strategy. The delegation mechanism in RACF and the easy, nontechnical commands that change the relationship of a user to a resource mean that adopting the principle of least possible privilege need not be burdensome nor inflexible when unusual circumstances dictate that access permission should be changed. When an unforeseen circumstance requires a change in access privilege, the change can be made by a nontechnical person with access to a TSO terminal, and management can be alerted to review the fact that the change was made. Major subsystems such as CICS and DB2 can use the facilities of RACF to protect transactions and files. Much of the work to configure RACF profiles for these subsystems is done by the CICS and DB2 system programmers. So, there is a need for people in these roles to have a useful understanding of RACF and how it relates to the software they manage.

Parallel Sysplex:

IBM System z

IBM System z

DB2 has the ability to run in a Parallel Sysplex environment. This environment is a requirement to support DB2 data sharing (for details about data sharing, see Chapter 9). Parallel Sysplex technology lets you configure an environment in which several processors can share data and the DB2 subsystems can have concurrent read/write access to the data. It also gives you the flexibility to add new processors for increased throughput, the ability to seamlessly rout workload away from failed processors, and the capacity to balance diverse work across multiple processors.

1. A group of mainframe servers interconnected to each other. So that they can share among each other. Mainframe servers are connected through Sysplex timer, so that they can synchronies with each other and act as single unit. 2. When ever it executes transaction it distributes among different servers. So it can execute in parallel. FICON is 8 times more capacity than ESCON A Sysplex is a group of z/OS systems that communicate and cooperate with one another using specialized hardware and software. 3. They are connected and synchronized through a Sysplex Timer or System z Server Time Protocol z(STP), and enterprise systems connection (ESCON) or fiber connection (FICON) channels. A Parallel Sysplex is a Sysplex that uses one or more coupling facilities (CFs), which provide high-speed caching, list processing, and lock processing for any applications on the Sysplex.