IBM Introducción A Mainframe

Introduction to the new mainframe: z/OS basics Chapter 1: The new mainframe
Copyright IBM Corp., 2005. All rights reserved.
Introduction to the new mainframe
Chapter 1 objectives
Be able to:
List ways in which the mainframe of today challenges the traditional thinking on centralized computing versus distributed computing Explain how businesses make use of mainframe processing power, the typical uses of mainframes, and how mainframe computing differs from other forms of computing Outline the major types of workloads for which mainframes are best-suited Name five jobs or responsibilities related to mainframe computing List four mainframe operating systems.
Key terms in this chapter

application programmer architecture batch processing compatibility e-Business EBCDIC high availability infrastructure mainframe online processing
platform production control punched card RAS scalability server farm system administrator system operator system programmer transaction processing
Evolving architecture
CMOS HW S/360 S/370 S/370XA 31 bits ESA/390 Parallel Sysplex z/Architecture 64 bits
1964
1970
1980
1990
2000
2004
MVT, PCP MFT SW
MVS - VTAM
MVS/XA
MVS/ESA OS/390
USS TCP/IP
z/OS
Linux CICS VM DB2 WebSphere z/VM

Mainframes in our midst

Mainframes: Are prevalent, yet hidden from public eye Not often publicized stable, reliable, dependable. Contrast with other forms of computing, such as PCs. Present opportunities for college graduates in a variety of technical fields.
What is a mainframe? A mainframe is a computing system that 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. The power of a mainframe provides computing speed and capacity, enabling it to perform high volumes of processing. The mainframe can process a mixed workload of jobs from different time zones and of different types.
Mainframe facts
Who uses mainframes?
Most Fortune 1000 companies use a mainframe environment 60% of all data available on the Internet is stored on mainframe computers
Why mainframes?
Large-scale transaction processing
Thousands of transactions per second
Support thousands of users and application programs Simultaneously accessing resources Terabytes of information in databases Large-bandwidth communications
There are more CICS transactions processed daily than Web pages served
Factors contributing to mainframe use RAS -- reliability, availability, serviceability Security Scalability Centralized control Workload management Partitioning / virtualization Continuing compatibility Evolving architecture Application enablement, complexity, variety Potential for thousands of users
Typical mainframe workloads

Application Program
Batch job
Input Data
Process data to perform a particular task Output Data
Application Program Query Reply Access shared data on behalf of online user
Online (real time) transaction
Typical batch use

Residence
CREDIT CARD
Branch offices
1234 9012 1234 5678 9012

VALID FROM GOOD THRU
XX/XX/XX XX/XX/XX XX/XX/XX PAUL FISCHER PAUL FISCHER
Account balances bills, etc
Main office 5
Processing reports 7
Reports Statistics,
4 summaries,
exceptions
Partners and clients exchange information
Mainframe
Processing batch jobs Reports
2 1
Reports
Backup
s 3
Data update
Tape Storage 10
Sequential data sets
Disk Storage
Production Control System Operator databases
Typical online use

ATMs
Account activities
SNA or TCP/IP network
4
Requests
Branch offices
Branch office automation systems
2 3
Office automation systems
Mainframe
Accesses database
queries and updates
Central office Business analysts Inventory control Disk storage controller

Stores database files
Roles in the mainframe world

Roles
Application Developer Production Control Analyst
Operator End User
System Programmer
System Administrator
Mainframe operating systems z/OS z/VM VSE Linux for zSeries z/TPF
Summary
The New Mainframe:
Plays a central role in the daily operations of the worlds largest organizations and the daily lives of most people. Is known for its reliability, security, and enormous processing capabilities. Is designed for processing large scale workloads and serving thousands of users and transactions concurrently. Is managed by highly skilled technical support staff. Runs a variety of operating systems.
Introduction to the new mainframe: z/OS basics Chapter 2: z/OS Overview
Be able to:
Give examples of how z/OS differs from a single-user operating system. List the major types of storage used by z/OS. Explain the concept of virtual storage and its use in z/OS. State the relationship between pages, frames, and slots. List several defining characteristics of the z/OS operating system. List several software products used with z/OS to provide a complete system. Describe several differences and similarities between the z/OS and UNIX operating systems.

address space addressability auxiliary storage dynamic address translation (DAT) frame input/output (I/O) middleware multiprocessing multiprogramming page / paging page data set program product real storage slot swap data set UNIX virtual storage z/OS
What is z/OS?
The most widely used mainframe operating system 64-bit operating system Ideally suited for processing large workloads for many concurrent users Designed for:
Serving 1000s of users concurrently I/O intensive computing Processing very large workloads Running mission critical applications securely
Hardware resources managed by z/OS

Mainframe computer (CPU, processor storage)
z/OS running here...

System Console (hardware)
Master Console (z/OS) Operator Console (z/OS)
... Director links mainframes with DASD controllers
Tape drive DASD Tape cartridges
controller
Disk storage (DASD volumes)
Overview of z/OS internals

Comprised of modules, system programs (macros), system components Use of the program status word (PSW) Techniques of multiprogramming and multiprocessing Information about the system, resources, and tasks is contained in control blocks Management of physical storage:
Real storage Auxiliary storage Virtual storage
Virtual storage concepts

Virtual storage is an illusion created through z/OS management of real storage and auxiliary storage through tables. The running portions of a program are kept in real storage; the rest is kept in auxiliary storage Range of addressable virtual storage available to a user or program or the operating system is an address space Each user or separately running program is represented by an address space (each user gets a limited amount of private storage)
The address space concept

16 EB
64-bit addresing (z/OS)
2GB The Bar
31-bit addresing (MVS/XA) 16 MB 24-bit addresing (MVS) The Line
How virtual storage works

Virtual storage is divided into 4-kilobyte pages Transfer of pages between auxiliary storage and real storage is called paging When a requested address is not in real storage, an interruption is signaled and the system brings the required page into real storage z/OS uses tables to keep track of pages Dynamic address translation (DAT) Frames, pages, slots are all repositories for a page of information
How virtual storage works (continued)
Pages, Frames, and Slots

The pieces of a program executing in virtual storage must be moved between real and auxiliary storage:
A block of real storage is a frame. A block of virtual storage is a page. A block of auxiliary storage is a slot.
A page, a frame, and a slot are all the same size: 4096 bytes (4 kilobytes). To the programmer, the entire program appears to occupy contiguous space in real storage at all times.
Pages, Frames, and Slots (continued)
Page Stealing
z/OS tries to keep an adequate supply of available real storage frames on hand. When this supply becomes low, z/OS uses page stealing to replenish it. Pages that have not been accessed for a relatively long time are good candidates for page stealing. z/OS also uses various storage managers to keep track of all pages, frames, and slots in the system.
Swapping
Swapping is one of several methods that z/OS uses to balance the system workload and ensure that an adequate supply of available real storage frames is maintained. Swapping has the effect of moving an entire address space into, or out of, real storage:
A swapped-in address space is active, having pages in real storage frames and pages in auxiliary storage slots. A swapped-out address space is inactive; the address space resides on auxiliary storage and cannot execute until it is swapped in.
Brief history of z/OS addressability
1970: System/370 defined storage addresses as 24 bits in length. 1983: System/370-XA extended the addressability of the architecture to 31 bits. 2000: z/Architecture extended the addressability to 64 bits.
Addressing value of a byte
Bits
0 2
0 3
0 4
0 0 0 0 5 6 7 8 8 4 2 1 (binary, power of 2)
Bit count 1
Bit value 128 64
32 16
In summary: One byte can address 256 locations Three bytes can address 16 million locations
Brief history of z/OS addressability (continued)
Whats in an address space?

z/OS provides each user with a unique address space and maintains the distinction between the programs and data belonging to each address space. Because it maps all of the available addresses, however, an address space includes system code and data as well as user code and data. Thus, not all of the mapped addresses are available for user code and data.
64-bit address space map

16 exabytes
User Extended Private Area
512 terabytes
Shared Area
2 terabytes
User Extended Private Area

2 gigabytes The Bar
16 megabyte
The Line
Common Area User Private Area

0
z/OS address spaces

z/OS and its related subsystems require address spaces of their own to provide a functioning operating system:
System address spaces are started after initialization of the master scheduler. These address spaces perform functions for all the other types of address spaces that start in z/OS. Subsystem address spaces for major system functions and middleware products such as DB2, CICS, and IMS. TSO/E address spaces are created for every user who logs on to z/OS Address spaces for every batch job that runs on z/OS.
How is peripheral storage managed? Management of peripheral storage devices involves file allocation, placement, monitoring, migration, backup, recall, recovery, and deletion. A typical z/OS production system includes both manual and automated processes for managing storage. A user or program can directly control many aspects of z/OS storage use. The primary means of managing storage in z/OS is through DFSMS.
Summary of z/OS facilities

Address spaces and virtual storage for users and programs. Physical storage types available: real and auxiliary. Movement of programs and data between real storage and auxiliary storage through paging. Dispatching work for execution, based on priority and ability to execute. An extensive set of facilities for managing files stored on disk or tape. Operators use consoles to start and stop z/OS, enter commands, and manage the operating system.
Summary of z/OS facilities (continued)
Address spaces
Operator communication
AUX
REAL
Physical storage
Reliability, availability, and serviceability
Paging
Data integrity
AUX
REAL
Defining characteristics of z/OS

Uses address spaces to ensure isolation of private areas Ensures data integrity, regardless of how large the user population might be. Can process a large number of concurrent batch jobs, with automatic workload balancing Allows security to be incorporated into applications, resources, and user profiles. Allows multiple communications subsystems at the same time Provides extensive recovery, making unplanned system restarts very rare. Can manage mixed workloads Can manage large I/O configurations of 1000s of disk drives, automated tape libraries, large printers, networks of terminals, etc. Can be controlled from one or more operator terminals, or from application programming interfaces (APIs) that allow automation of routine operator functions.
Program products for z/OS
A z/OS system usually contains additional program products (priced software) that are needed to create a practical working system:
security manager database manager compilers utility programs vendor products
Middleware for z/OS

Middleware is typically something between the operating system and an end user or end-user applications. Middleware supplies major functions not provided by the operating system. Typical z/OS middleware includes:
Database systems Web servers Message queuing and routing functions Transaction managers Java virtual machines XML processing functions
A brief comparison of z/OS and UNIX
Quite a few concepts are common to both:

Boot the system versus IPL the system Files versus data sets Editors vi, ed, sed, and emacs (UNIX) versus ISPF (z/OS) telnet or rlogin (UNIX) versus TSO logon (z/OS)
Summary
z/OS, the most widely used mainframe operating system, is ideally suited for processing large workloads for many concurrent users. Virtual storage is an illusion created by the architecture, in that the system seems to have more storage than it really has. Each user of z/OS gets an address space containing the same range of storage addresses. z/OS is structured around address spaces, which are ranges of addresses in virtual storage. Production systems usually include add-on products for middleware and other functions.
Introduction to the new mainframe: z/OS basics

Chapter 3: Interactive facilities of z/OS: TSO/E, ISPF, and UNIX
Be able to:
Log on to z/OS Run programs from the TSO READY prompt Navigate through the menu options of ISPF Use the ISPF editor to make changes to a file Use the UNIX interfaces on z/OS, including the z/OS UNIX command shell.

3270 and 3270 emulator CLIST ISHELL ISPF logon native mode OMVS command path READY prompt Restructured Extended Executor (REXX) shell Time Sharing Option / Extensions (TSO/E)
How do we interact with z/OS? TSO/E Allows users to logon to z/OS and use a limited set of basic commands. This is sometimes called using TSO in its native mode. ISPF Provides a menu system for accessing many of the most commonly used z/OS functions. z/OS UNIX shell and utilities Allows users to write and invoke shell scripts and utilities, and use the shell programming language.
TSO overview
TSO/E
Acronym for Time Sharing Option/Extensions (TSO/E) Allows users to create an interactive session with z/OS Provides a single-user logon capability and a basic command prompt interface to z/OS Most users work with TSO through its menu-driven interface, Interactive System Productivity Facility (ISPF)
TSO overview (continued)

In a z/OS system, each user gets a user ID and a password authorized for TSO logon. During TSO logon, the system displays the TSO logon screen on the users 3270 display device or TN3270 emulator. z/OS system programmers modify the layout and text of the TSO logon panel to better suit the needs of the systems users.
TSO/E logon screen

------------------------------- TSO/E LOGON ----------------------------------Enter LOGON parameters below: Userid ===> ZPROF New Password ===> Group Ident ===> RACF LOGON parameters:
Password ===> Procedure ===> IKJACCNT Acct Nmbr ===> ACCNT# Size ===> 860000
Perform ===> Command ===> Enter an 'S' before each option desired below: -Nomail -Nonotice -Reconnect -OIDcard PF1/PF13 ==> Help PF3/PF15 ==> Logoff PA1 ==> Attention PA2 ==> Reshow You may request specific help information by entering a '?' in any entry field
Using TSO commands in native mode

Usually, ISPF provides the interface for TSO. However, TSO includes a limited set of basic commands independent of ISPF and other programs. Using TSO in this way is called using TSO in its native mode.
When you logon to TSO, the z/OS system responds by displaying the READY prompt, and waits for input (similar to a DOS prompt).
TSO Ready Prompt
TSO is ready to accept commands Cursor, where you enter commands

1 2 3
1 - You enter a command (like a DOS prompt) 2 - TSO displays the command output and 3 - TSO is ready to accept new commands
Using CLISTs under native TSO
Place a command list or CLIST (see list) in a file and execute the list as if it were a single command. A CLIST issues the commands in sequence. CLISTs are used for performing routine tasks and working more efficiently with TSO. TSO users create CLISTs with the CLIST command language.
CLISTs versus REXX

REXX is Restructured Extended Executor language, a command language used with TSO Both CLISTs and REXX offer shell script-type processing. Both are interpretive languages, not compiled languages (although REXX can be compiled as well). Some z/OS users write functions directly as CLISTs or REXX programs CLIST programming is unique to z/OS, while the REXX language is used on many platforms.
ISPF overview Acronym for Interactive System Productivity Facility ISPF is a menu-driven interface for user interaction with z/OS system. The ISPF environment is executed from native TSO. ISPF provides utilities, an editor and ISPF applications to the user. To the extent permitted by various security controls an ISPF user has full access to most z/OS system functions.
Using ISPF allocate screen

Menu RefList Utilities Help Allocate New Data Set Command ===> Data Set Name . . . : ZSCHOL.TEST.CNTL . . . . . . . . . . . . . . . EBBER1 . . . TRACK (Blank for default management class) (Blank for default storage class) (Blank for system default volume) ** (Generic unit or device address) ** (Blank for default data class) (BLKS, TRKS, CYLS, KB, MB, BYTES or RECORDS) (M, K, or U) (In above units) (In above units) (Zero for sequential data set) *
Management class Storage class . Volume serial . Device type . . Data class . . . Space units . .
Average record unit Primary quantity . Secondary quantity Directory blocks . Record format . . . Record length . . . Block size . . . . Data set name type
. 2 1 . 0 . FB . 80 . 27920 :
(LIBRARY, HFS, PDS, or blank) (YY/MM/DD, YYYY/MM/DD F3=Exit F7=Backward F8=Forward
F1=Help F10=Actions
F2=Split F12=Cancel
F9=Swap
Navigating through ISPF menus
To access ISPF under TSO, the user enters a command from the READY prompt to display the ISPF Primary Option Menu. You can access online help from any of the ISPF panels (press the PF1 key) ISPF includes a text editor and browser, and functions for locating files and performing other utility functions.
ISPF Menu Structure
Primary option menu

0 Settings 1 Browse 2 Edit 3 Utilities 4 DS List 5 ...
Settings
/ Cursor at .. _ ... _ ... _ ...
View
Proj ____ Group ____ Type ____ Other Dsn__
Edit
Proj ____ Group ____ Type ____ Other Dsn__
Utilities
1 Dataset 2 Library 3 Copy/Move 4 DS List
Dialog Test
1 ...... 2 ...... 3 ...... 4 ......
Copy/Move Library Edit

**************** 0 //JOB1 JOB 0 //S1 EXEC 0 //DD1 DD 0 .. .. *************** C Copy M Mo CP Cop MP ____ b Display Group ____ D Delete Type ____ ____ Proj ______ Group ____ Group ____ Type ____
Dataset
Type ____
General structure of ISPF panels

Action Bar Panel Options Dynamic Status Area
Menu Utilities Compilers Options Status Help --------------------------------------------------------------------------ISPF Primary Option Menu 0 1 2 3 4 5 6 7 8 9 10 11 S Settings View Edit Utilities Foreground Batch Command Dialog Test LM Facility IBM Products SCLM Workplace SDSF Terminal and user parameters Display source data or listings Create or change source data Perform utility functions Interactive language processing Submit job for language processing Enter TSO or Workstation commands Perform dialog testing Library administrator functions IBM program development products SW Configuration Library Manager ISPF Object/Action Workplace System Display and Search Facility User ID . : Time. . . : Terminal. : Screen. . : Language. : Appl ID . : TSO logon : TSO prefix: System ID : MVS acct. : Release . : AUES100 16:14 3278 1 ENGLISH ISR LOGON AUES100 SYS1 ACCNT# ISPF 5.2
Enter X to Terminate using log/list defaults
Command Line Function Keys
Option ===> F1=Help F10=Actions F2=Split F12=Cancel F3=Exit F7=Backward F8=Forward F9=Swap
Common functions provided in ISPF menus

Action Bar
Menu Utilities Compilers Options Status Help ---------------------------------------------------------
Point-and-Shoot
0 1 2 3 . Settings View Edit Utilities Terminal and user parameters Display source data or listings Create or change source data Perform utility functions
Option Number
0 Settings 1 View 2 Edit 3 Utilities . . Options ===> 3 Terminal and user parameters Display source data or listings Create or change source data Perform utility functions
Function Keys
F1=Help F10=Actions F3=Exit F7=Bkwd F11=Retrieve F12=Cancel F8=Fwd
Keyboard mapping:
Function Enter Exit, end, or return Help PA1 or Attention PA2 Cursor movement Clear Page up Page down Scroll left Scroll right Reset locked keyboard Key Ctrl (right side) PF3 PF1 Alt-Ins or Esc Alt-Home Tab or Enter Pause PF7 PF8 PF10 PF11 Ctrl (left side)
ISPF Edit Panel - some line commands

Command I
Description
D R C M A B ( < ) > X
Insert lines Delete lines Repeat lines Copy lines Move lines After line Before line Shift right columns Shift right data Shift left columns Shift left data Exclude lines
ISPF Edit Panel - Inserting lines

Screen 1
Screen 2
z/OS UNIX interactive interfaces Like TSO and ISPF, the z/OS UNIX shell and utilities provide an interactive interface to z/OS. Use the UNIX shell to:
Invoke shell scripts and utilities Write shell scripts (a list of shell commands created with the shell programming language) Run shell scripts and C language programs interactively.
Invoking the UNIX shell You can invoke the UNIX shell in any of these ways:
From a 3270 display or a workstation running a 3270 emulator From a TCP/IP-attached terminal, using the rlogin and telnet commands From TSO by entering the OMVS command or the ISHELL command.
TSO commands used with z/OS UNIX

ISHELL -- This command invokes the ISPF shell.
Intended for users more familiar with TSO/ISPF than UNIX Provides panels for working with UNIX files, mounting and unmounting file systems, and z/OS UNIX administration. z/OS programmers can do much of their work under ISHELL.
OMVS -- This command invokes the z/OS UNIX shell.
Intended for users more familiar with UNIX than TSO/ISPF Allows the user to alternate between the shell and TSO UNIX programmers should find the z/OS UNIX shell programming environment familiar.
ISHELL command (ish) A good starting point for TSO/ISPF users who want to use z/OS UNIX. Under ISHELL, you can use action codes to:
b e d r a c Browse a file or directory Edit a file or directory Delete a file or directory Rename a file or directory Show the attributes of a file or directory Copy a file or directory
OMVS command shell session

You use the OMVS command to invoke the z/OS UNIX shell. Under the UNIX shell, users can:
Invoke shell commands or utilities that request services from the system. Write shell scripts using the shell programming language. Run shell scripts and C-language programs interactively (in the foreground), in the background, or in batch.
Direct login to the shell rlogin

When the inetd daemon is active, you can rlogin to the shell from a workstation. To log in, use the rlogin (remote log in) command syntax supported at your site.
telnet
Also uses the inetd daemon inetd must be active and set up to recognize and receive the incoming telnet requests.
Summary
TSO allows users to logon to z/OS and use a limited set of basic commands in native mode. ISPF is a menu-driven interface for user interaction with z/OS. ISPF provides utilities, an editor and ISPF applications to the user. To the extent permitted by various security controls an ISPF user has full access to most z/OS system functions. TSO ISPF should be viewed as a system management interface and a development interface for traditional z/OS programming. The z/OS UNIX shell and utilities provide a command interface to the z/OS UNIX environment. You can access the shell either by logging on to TSO/E or by using the remote login facilities of TCP/IP (rlogin). If you use TSO/E, a command called OMVS creates a shell for you. You can work in the shell environment until exiting or temporarily switching back to the TSO/E environment.
Chapter 4: Working with data sets
Be able to:
Explain what a data set is Describe data set naming conventions and record formats List some access methods for managing data and programs Explain what catalogs and VTOCs are used for Create, delete, and modify data sets Explain the differences between UNIX file systems and z/OS data sets Describe the z/OS UNIX file systems use of data sets.

block size catalog data set high level qualifier or HLQ library logical record length or LRECL member PDS and PDSE record format or RECFM system managed storage or SMS virtual storage access method or VSAM volume table of contents or VTOC
What is a data set? A data set is a collection of logically related data records stored on one disk storage volume or a set of volumes. A data set can be:
a source program a library of macros a file of data records used by a processing program.
You can print a data set or display it on a terminal. The logical record is the basic unit of information used by a program running on z/OS.
How data is stored in a z/OS system Data is stored on a direct access storage device (DASD), magnetic tape volume, or optical media. You can store and retrieve records either directly or sequentially. You use DASD volumes for storing data and executable programs, including the operating system itself, and for temporary working storage. You can use one DASD volume for many different data sets, and reallocate or reuse space on the volume.
Data management in z/OS Data management involves all of the following tasks:
allocation, placement, monitoring, migration, backup, recall, recovery, and deletion.
Storage management is done either manually or through automated processes (or through a combination or both). In z/OS, Data Facility: System-Managed Storage (DFSMS) is used to automate storage management for data sets.
What an access method is Defines the technique used to store and retrieve data. Includes system-provided programs and utilities to define and process data sets. Commonly used access methods include the following:
VSAM, QSAM, BSAM, BDAM, and BPAM.
DASD: Use and terminology Direct Access Storage Device (DASD) is another name for a disk drive. DASD volumes are used for storing data and executable programs. Data sets in a z/OS system are organized on DASD volumes.
A disk drive contains cylinders Cylinders contain tracks Tracks contain data records.
Using a data set To use a data set, you first allocate it. Then, access the data using macros for the access method that you have chosen. Various ways to allocate a data set:
ISPF data set panel, option 3.2 Access Method Services TSO ALLOCATE command job control language (JCL)
Allocating space on DASD volumes How space is specified:

explicitly (SPACE parameter) implicitly (SMS data class)
Logical records and blocks:

Smallest amount of data to be processed Grouped in physical records named blocks
Data set extents:

Space for a disk data set is assigned in extents
Data set record formats

F
record record record record Fixed records. block block record record record record
FB
record
record
Fixed blocked records. BLKSIZE = n * LRECL
V
RDW
record
record
record
Variable records. block block record

record
VB
BDW
record
record
record
Variable blocked records. BLKSIZE >= 4 + n * largest LRECL record

record
record
record
Undefined records. No defined internal structure for access method. Record and block descriptors words are each 4 bytes long
Types of data sets We discuss three types in this class:

Sequential, partitioned, and VSAM
A sequential data set is a collection of records written and read in sequential order from beginning to end. A partitioned data set (PDS) is a collection of sequential data sets, called members.
Consists of a directory and one or more members. Also called a library.
A PDSE is a partitioned data set extended.
PDS versus PDSE PDS data sets:

Simple and efficient way to organize related groups of sequential files.
PDSE data sets:

Similar to a PDS, but advantages include:
Space reclaimed automatically when a member is deleted Flexible size Can be shared Faster directory searches
What is a data set, and how is it stored

Sequential Data Set DASD Partitioned and Sequential
Record 1 Record 2 Record 3 Record 4 etc ...
Directory
Partitioned Data Set

Entry for COMPJCL Entry for JCOPY Entry for SORT1
COMPJCL
Previously used space recoverable by compress utility
JCOPY SORT1
Available space
VSAM VSAM is Virtual Storage Access Method VSAM provides more complex functions than other disk access methods VSAM record formats:
Key Sequence Data Set (KSDS) Entry Sequence Data Set (ESDS) Relative Record Data Set (RRDS) Linear Data Set (LDS)
Simple VSAM control interval
R1
R2
R3
free space in CI
R D F
R D F
R D F
CI D F
Record Descriptor Fields
How data sets are named Data set naming convention

Unique name
Maximum 44 characters
Maximum of 22 name segments: level qualifier

The first name in the left: high level qualifier (HLQ) The last name in the right: low level qualifier (LLQ) Level qualifiers are separated by '.'
Each level qualifier:

From 1 up to 8 characters The first must be alphabetical (A-Z) or special (@ # $) The 7 remaining: alphabetical, national, numeric (0-9) or hyphen (-) Upper case only
Example: MYID.JCL.FILE2 HLQ: MYID 3 qualifiers
Member name of partitioned data set

8 bytes long First byte: alphabetical (A-Z) or special (@ # $) The 7 remaining: alphabetical, special, numeric (0-9)
Catalogs and VTOCs z/OS uses a catalog and a volume table of contents (VTOC) on each DASD volume to manage the storage and placement of data sets. VTOC:
Lists the data sets on a volume Lists the free space on the volume.
VTOC
LABEL (volser)
VTOC MY.DATA YOUR.DATA
free space
tracks
tracks
tracks
Extents
How a catalog is used A catalog associates a data set with the volume on which the data set is located. Locating a data set requires:
Data set name Volume name Unit (volume device type)
Typical z/OS system includes a master catalog and numerous user catalogs.
Catalog Structure
SYSTEM.MASTER.CATALOG Master Catalog Data Set-SYS1.A1 or HLQs (alias) IBMUSER...USER
USERCAT.IBM User Catalog
USERCAT.COMPANY User Catalog Data Set with HLQ=USER
Data Set with HLQ=IBMUSER
Catalog Structure
volume (wrk002) unit (3390)
volume (wrk001) unit (3390) IBMUSER.A1 USER.A1 SYS1.A1 volume (012345) unit (tape) USER.TAPE.A1
IBMUSER.A2 IBMUSER.A3
z/OS UNIX file systems

z/OS UNIX System Services (z/OS UNIX) allows z/OS to access UNIX files. A z/OS UNIX file system is hierarchical and byte-oriented. Files in the UNIX file system are sequential files and are accessed as byte streams. UNIX files and traditional z/OS data sets can reside on the same DASD volume.
UNIX file system structure

Directory
Directory
Directory
Directory
File File File File
Directory
File File File File File File File File
Directory
File File File
Summary A data set is a collection of logically related data (programs or files) Data sets are stored on disk drives (DASD) and tape. Most z/OS data processing is record-oriented. Byte stream files are not present in traditional processing, except in z/OS UNIX. z/OS records follow well-defined formats, based on record format (RECFM), logical record length (LRECL), and the maximum block size (BLKSIZE). z/OS data set names have up to 44 characters, divided by periods into qualifiers.
Summary (continued) Catalogs are used to locate data sets. VSAM is an access method that provides more complex functions than other disk access methods. z/OS libraries are known as partitioned data sets (PDS or PDSE) and contain members. A file in the hierarchical file system can be either a text file or a binary file. z/OS treats an entire UNIX file system hierarchy as a collection of data sets. Each data set is a mountable file system.

Chapter 5: Batch processing and the Job Entry Subsystem (JES)
Batch processing and JES Copyright IBM Corp., 2005. All rights reserved.
Be able to: Give
an overview of batch processing and how work is initiated and managed in the system. Explain how the job entry subsystem (JES) governs the flow of work through a z/OS system.

batch processing execution initiator job job entry subsystem (JES) output procedure purge queue spool symbolic reference workload manager (WLM)
What is batch processing?

Much of the work running on z/OS consists of programs called batch jobs. Batch processing is used for programs that can be executed: With minimal human interaction At a scheduled time or on an as-needed basis. After a batch job is submitted to the system for execution, there is normally no further human interaction with the job until it is complete.
What is JES? In the z/OS operating system, JES manages the input and output job queues and data. JES handles the following aspects of batch processing for z/OS:
Receives jobs into the operating system Schedules them for processing by z/OS Controls their output processing
What is JES? (continued) z/OS offers two types: JES2 and JES3 Some important differences, but both JES2 and JES3:
Accept and queue jobs submitted for execution Queue jobs for an initiator -- a JES program that requests the next job in the queue Accept output from a job while it is running and queue the output Can print the output, or save it on spool for an output manager to retrieve.
Batch flow (simplified)

JCL Processing
JOBs submit
JES
Initiator
- Allocation Initiator - Allocation - Cleanup
- Execution - Cleanup - Execution
SPOOL SPOOL
Printer
What is spooling? Spooling is a method for queuing and holding data for input or output. JES uses one or more disk data sets for spooling. Input jobs and printed output from many jobs are stored in the single (conceptual) spool data set.
What an initiator does

To run multiple jobs asynchronously, z/OS uses initiators to:
Ensure that jobs do not conflict in data set usage Ensure that single-user devices (tape drives) are allocated correctly Find executable programs requested by jobs Clean up after the job ends and request the next job
Preventing two users from accessing the same data at the same time is critical to z/OS and the ability to do this is one of the defining characteristics of the operating system.
Symbolic references to files
z/OS normally uses symbolic references to files (data sets) rather than actual file names. The use of symbolic references provides a naming redirection between a data set-related name used in a program and the actual data set used during execution of that program.
How a symbolic file system is used

DDNAME DSNAME
program
OPEN FILE=XYZ READ FILE=XYZ
JCL for JOB
//XYZ DD DSNAME=MY.PAYROLL ... CLOSE FILE=XYZ
MY.PAYROLL
How a symbolic file system is used (continued)

DDNAME DSNAME
program
OPEN FILE=XYZ READ FILE=XYZ
JCL for JOB
//XYZ DD DSNAME=DIV1.PAYROLL ... CLOSE FILE=XYZ
DIV1.PAYROLL
JES, job management, and JCL Job control language (JCL) is the language used by a batch job to request resources and services from the operating system. Through JCL, you specify:
Who you are (important for security reasons). Which resources (programs, files, memory) and services are needed from the system to process your program.
The use of JCL is covered in detail in the next module.
Related actions with JCL

IT USER ACTIONS SYSTEM ACTIONS
Determine the need and characteristics of the Job Create the JCL Submit the Job JES interprets JCL and passes it to z/OS initiator
System Messages
z/OS manages each step of execution
User views and interprets output
JES prints output
JES collects the output and information about the Job
Spooling
JCL
//DD1 DD * ............... data ............... /*
program read 2
JES 1
spool
//DD2
DD SYSOUT=A
JES 4
SYSOUT
write 3
Printer
Two-step job
First step Second step
Master
Updates
Master
Program
Program
Tape
Master
Printer
Job flow through the system During execution, a job goes through the following phases:
Input Conversion Processing Output Print (to hardcopy or a console display) Purge
Phases of job flow: input

JOB
CONVERSION QUEUE
INPUT
CONVERSION
PROCESSING
OUTPUT
HARD-COPY
PURGE
JCL & SYSIN
SPOOL DISK
Phases of job flow: conversion

JOB
CONVERSION QUEUE EXECUTION QUEUE
INPUT
CONVERSION
PROCESSING
OUTPUT
HARD-COPY
PURGE
JCL
SPOOL DISK
Phases of job flow: execution

JOB
EXECUTION QUEUE OUTPUT QUEUE
INPUT
CONVERSION
PROCESSING
OUTPUT
HARD-COPY
PURGE
SYSIN
SYSOUT
SPOOL DISK
Phases of job flow: output and hardcopy
JOB
OUTPUT QUEUE HARD-COPY QUEUE PURGE QUEUE
INPUT
CONVERSION
PROCESSING
OUTPUT
HARD-COPY
PURGE
SYSOUT
NON-PRINT/PUNCH OUTPUT
SPOOL DISK
Phases of job flow: purge

JOB
PURGE QUEUE
INPUT
CONVERSION
PROCESSING
OUTPUT
HARD-COPY
PURGE
SPOOL DISK
Job flow through the system

JOB
CONVERSION QUEUE EXECUTION QUEUE OUTPUT QUEUE HARD-COPY QUEUE PURGE QUEUE
INPUT
CONVERSION
PROCESSING
OUTPUT
HARD-COPY
PURGE
SYSIN
SYSOUT
SYSOUT
JCL JCL & SYSIN
Network job entry (NJE)
SPOOL DISK
JES2 compared to JES3

In a multi-processor configuration: JES2:
Each JES2 processor controls its own job input, job scheduling, and job output processing. It is possible to configure JES2 to share spool and checkpoint data sets with other JES2 systems (multi-access spool or MAS).
JES3:
Centralized control over processing through a single global JES3 processor, which does job selection, scheduling, and device allocation the other JES3 systems. The centralized control of JES3 provides increased job scheduling control, deadline scheduling capabilities, and increased control by providing its own device allocation.
Most installations use JES2, as do the examples in this text.
What is workload manager? Workload manager (WLM): The component of z/OS that manages the processing of workload in the system according to the companys business goals, such as response time. Also manages the use of system resources, such as processors and storage, to accomplish these goals.
Summary
Batch processing is a fundamental function of z/OS. z/OS shares with JES the management of jobs and resources. JES receives jobs into the system, schedules them for processing, and controls their output. JES manages jobs in queues. An initiator sets up the necessary environment for running a batch job. Multiple initiators permit the parallel execution of batch jobs. During the life of a job, both JES and the z/OS base control program control different phases of the overall processing.

Chapter 6: Using Job Control Language (JCL) and System Display and Search Facility (SDSF)
Be able to: Explain how JCL works with the system, give an overview of JCL coding techniques, and know a few of the more important statements and keywords Create a simple job and submit it for execution Check the output of your job through SDSF

concatenation DD statement job control language (JCL) JOB statement EXEC statement job name procedure (PROC) record format (RECFM) system display and search facility (SDSF) step name system catalog system library utility
What is JCL? Job control language (JCL) tells the system what program to execute and provides a description of program inputs and outputs. There are three basic JCL statements:
JOB statement EXEC statement DD statement
Basic JCL coding syntax

JCL must be uppercase
Forward slash in column 1 and 2 Name (1-8 characters) follow the slashes Space separators
//JOBNAME JOB //STEPNAME EXEC //DDNAME DD //* comment - upper or lower case /* ....end of JCL stream
JCL example
//MYJOB JOB 1 //MYSORT EXEC PGM=SORT //SORTIN DD DISP=SHR,DSN=IBMUSER.AREA.CODES //SORTOUT DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSIN DD * SORT FIELDS=(1,3,CH,A) /*
In the preceding example MYJOB MYSORT SORTIN SORTOUT SYSOUT SYSIN Job name Step name DD name for program input DD name for program output Where to send system output messages (such as a data set) Specifies whether the input will be data or control statements.
JCL: JOB statement

Create a member using ISPF edit Create JCL statements JOB statement
Accounting information Execution classes
JCL: EXEC statement

EXEC statement
Region size
JCL: DD statement
DD statement DD name (referenced in the program) DSN= (the data set name as cataloged on disk)
Specifying a data set disposition: DISP is an operand of the DD statement DISP indicates what to do with the data set (the disposition) at step start, end, or abnormal end (if the job fails) DISP helps to prevent unwanted simultaneous access to data sets, which is very important for general system operation.
Uses of the DISP= operand

DISP=(status,normal end,abnormal end) DISP=(status,normal end) DISP=status
where status can be NEW OLD SHR MOD
Creating a new data set

New data sets can be created through JCL by using the DISP=NEW parameter. For a DISP=NEW request, you need to supply more information, including: A data set name, DSN= The type of device for the data set, UNIT=sysda If a disk is used, the amount of space to be allocated for the primary extent must be specified, SPACE= If it is a partitioned data set, the size of the directory must be specified within the SPACE parameter Optionally, DCB parameters can be specified.
Continuation and concatenation
Needed to overcome the limitations of the 80-column punched cards used in earlier systems.
Continuation allows a JCL statement to span multiple records. Concatenation allows a single ddname to have multiple DD statements.
Continuation and concatenation (example)

Continuation example //JOBCARD JOB 1, // REGION=8M, // NOTIFY=IBMUSER Concatenation example //DATAIN DD DISP=OLD,DSN=MY.INPUT1 // DD DISP=OLD,DSN=MY.INPUT2 // DD DISP=SHR,DSN=YOUR.DATA
JCL procedures - example

//MYJOB //MYPROC //MYSORT //SORTIN //SORTOUT //SYSOUT // JOB 1 PROC EXEC PGM=SORT DD DISP=SHR,DSN=&SORTDSN DD SYSOUT=* DD SYSOUT=* PEND
JCL procedures (continued)

//MYJOB JOB 1 //*---------------------------------* //MYPROC PROC //MYSORT EXEC PGM=SORT //SORTIN DD DISP=SHR,DSN=&SORTDSN //SORTOUT DD SYSOUT=* //SYSOUT DD SYSOUT=* // PEND //*---------------------------------* //STEP1 EXEC MYPROC,SORTDSN=IBMUSER.AREA.CODES //SYSIN DD * SORT FIELDS=(1,3,CH,A)
JCL procedures -- statement override

//MYJOB JOB 1 //*---------------------------------* //MYPROC PROC //MYSORT EXEC PGM=SORT //SORTIN DD DISP=SHR,DSN=&SORTDSN //SORTOUT DD SYSOUT=* //SYSOUT DD SYSOUT=* // PEND //*---------------------------------* //STEP1 EXEC MYPROC,SORTDSN=IBMUSER.AREA.CODES //MYSORT.SORTOUT DD DSN=IBMUSER.MYSORT.OUTPUT, // DISP=(NEW,CATLG),SPACE=(CYL,(1,1)), // UNIT=SYSDA,VOL=SER=SHARED, // DCB=(LRECL=20,BLKSIZE=0,RECFM=FB,DSORG=PS) //SYSIN DD * SORT FIELDS=(1,3,CH,A)
Using SDSF
After submitting a job, z/OS users use System Display and Search Facility (SDSF) to review the job output for successful completion or JCL errors. SDSF allows users to:
View and search the system log Enter system commands Hold, release, cancel, and purge jobs Monitor jobs while they are processed Display job output before deciding to print it Control the order in which jobs are processed Control the order in which output is printed Control printers and initiators
SDSF panel hierarchy
Primary Option Menu
SYSLOG Panel
Display Active Users Panel
Input Queue Panel
Output Queue Panel
Help Output Queue Panel
Status Panel
Printer Panel
Initiator Panel
Job Data Set Panel
Output Descriptor Panel
Output Data Set Panel

SDSF: Primary option menu
SDSF: Options menu
Viewing the JES2 output files

Screen 1
Screen 2
SDSF: Display active users (DA)

Display Filter View Print Options Help ----------------------------------------------------------------------------SDSF DA SC67 SC67 PAG 0 SIO 7 CPU 6/ 7 LINE 1-25 (64) COMMAND INPUT ===> SCROLL ===> PAG PREFIX=* DEST=LOCAL OWNER=* SORT=JOBNAME/A NP JOBNAME STEPNAME PROCSTEP JOBID OWNER C POS DP REAL PAGING SIO *MASTER* STC06373 +MASTER+ NS FF 1369 0.00 0.00 ALLOCAS ALLOCAS NS FF 190 0.00 0.00 ANTAS000 ANTAS000 IEFPROC NS FE 1216 0.00 0.00 ANTMAIN ANTMAIN IEFPROC NS FF 4541 0.00 0.00 APPC APPC APPC NS FE 2653 0.00 0.00 ASCH ASCH ASCH NS FE 267 0.00 0.00 BPXOINIT BPXOINIT BPXOINIT LO FF 315 0.00 0.00 CATALOG CATALOG IEFPROC NS FF 1246 0.00 0.00 CICSPAAY CICSPAAY CICS520 STC06504 STC NS FE 4330 0.00 0.00 CONSOLE CONSOLE NS FF 597 0.00 0.00 DFRMM DFRMM IEFPROC STC06363 STC NS FE 510 0.00 0.00 DFSMSHSM HSMSC67 DFSMSHSM STC13178 STC NS FE 6199 0.00 0.00 DUMPSRV DUMPSRV DUMPSRV NS FF 160 0.00 0.00 FTPDMVS1 STEP1 STC06477 STC LO FF 470 0.00 0.00 FTPDOE1 STEP1 STC06475 FTPDOE LO FF 469 0.00 0.00 GRS GRS NS FF 894 0.00 0.00 IEFSCHAS IEFSCHAS NS FF 25 0.00 0.00 IMWEBSUF IMWEBSUF WEBSRV STC15245 WEBSRV IN FE 15T 0.00 0.00
Issuing MVS and JES commands
SDSF: Input queue panel
SDSF: Output queue panel
SDSF: Held output queue panel
SDSF: Status panel
Utilities z/OS includes a number of programs useful in batch processing called utilities. Utilities provide many small, obvious, and useful functions. A basic set of system-provided utilities is described in the textbook (Appendix C). Customer sites often write their own utility programs, many of which are shared by the z/OS user community. Some examples of utilities:
IEBGENER IEBCOPY IDCAMS
Copies a sequential data set Copies a partitioned data set Works with VSAM data sets
System Libraries
z/OS has many standard system libraries, including:
SYS1.PROCLIB SYS1.PARMLIB SYS1.LINKLIB SYS1.LPALIB JCL procedures distributed with z/OS Control parameters for z/OS and some program products. Many of the basic execution modules of the system. System execution modules that are loaded into the link pack area at z/OS initialization.
Summary
Basic JCL contains three statements: JOB, EXEC, and DD. A program can access different groups of data sets in different jobs by changing the JCL for each job. New data sets can be created through JCL by using the DISP=NEW parameter. Users normally use JCL procedures for more complex jobs. A cataloged procedure is written once and can then be used by many users. z/OS supplies many JCL procedures, and locallywritten ones can be added easily. A user must understand how to override or extend statements in a JCL procedure to supply the parameters (usually DD statements) needed for a specific job.
Summary - continued
SDSF is a panel interface for viewing the system log and the list of active users and controlling and monitoring jobs and resources. Utility programs make operating on data sets easier System libraries contain JCL procedures, control parameters, and system execution modules.
Introduction to the new mainframe: z/OS basics Chapter 7: Designing and developing applications for z/OS
Chapter 7 objectives Be able to:

List the major considerations for designing an application for z/OS. Describe the advantages and disadvantages of using batch versus online for an application. Briefly describe the process for testing a new application on z/OS. List three reasons for using z/OS as the host for a new application.

application ASCII DFSORT EBCDIC enablement executable user requirements system
What is an application? An application

A piece of software that will satisfy certain specific requirements or resolve certain problems The solution can reside on any platform or combination of platforms
Who designs applications for the mainframe?
Application designer:
Determines the best programming solution for an important business requirement. Understands:
Business objectives of the company Other roles in the mainframe IT organization Companys hardware and software.
Has a global view of the entire project.
Who writes applications for the mainframe? Application programmer: Builds, tests, and delivers the applications that run on the mainframe for end users Works from the application designers specifications Uses a variety of tools Application programming involves many iterations of: Code changes and compiles Application builds Unit testing.
Where applications reside

Internet Enterprise Network
Browser Web Server Appl. Server
Central Site
e-business
Browser Browser Web Server Appl. Server
Business Systems Databases
e-business
with Legacy Systems Browser Server
Business Systems Applications
Client-Server
Personal Computer
GUI Front-End
Personal Computer
Business System s Front End
Term inal Processing

"Dumb" Terminal
Application development lifecycle

Gather requirements Analysis Design
Code & test
User, System tests
Go production
Maintenance
Gathering requirements for the design Requirements: Assess what needs to be accomplished
Based on projects constraints Always keep in mind the end result Conduct interviews with users and stakeholders Verify our assumptions
Types of requirements
Accessibility Client Interoperability Recoverability Serviceability Availability Connectivity Performance Resource can be monitored, controlled, managed, and administered Usability Frequency of data backup Distributed Portability Secure centralized controllable capacity Web services Changeability Inter-communicable Preventing failure and fault analysis
Design phase Users Constraints
Verify
Verify
Requirements
Analysis
Design
Design documents
Business
Technical
Revise
Revise
Design decisions based on requirements Batch versus online Database, tape, flat file, etc. COBOL, PL/I, JAVA, Assembler z/OS, Unix, Linux, Windows Capacity of server Server type Develop or purchase package or both
Development phase
Design documents
Coding
Testing Tested programs Revise
Developing an application for the mainframe Programmer uses as input the specifications of the designer Usually follows this process:
Code a module. Test a module for functionality. Make corrections to the module. Repeat from step 2 until successful.
Programming tools for the mainframe Editor

TSO or ISPF-based
Repository for source code

PDS, SCLM or some other repository
Job monitoring and viewing software

SDSF or equivalent product
Debugging tools
Debugging a program on the mainframe

Log on to TSO Enter ISPF check out source code Edit source and make modifications Submit compile JCL to verify syntax Switch to SDSF to view job status View job output in SDSF check for errors Correct errors Repeat from Submit until errors are corrected Save source code in repository
Interactive Development Environment (IDE)

IDEs accelerate development process
Edit source on work station Run compiles off-platform Perform remote debugging Useful for hybrid applications
Host-based COBOL with CICS, IMS, and Web browser-like interface Provides unified development environment to build OLTP in HLL and HTML front-end interface
90 80 70 60 50 40 30 20 10 0 1st Qtr 2nd Qtr 3rd Qtr 4th Qtr East West North
Test phase
User Tested programs
Validate Test results
Performance
Final tested programs
Integration tests Test data Prod data
Other systems
Test phases (continued) Many levels of testing

User testing for functionality, acceptance Performance (stress) testing Integration testing (with other systems)
Validate the testing results Final step before going production
Production phase
Final tested programs
Promote To production
Production Repository
Go production Document:
Operational procedures Training manuals (users, administrators, etc.)
Promote application to production status

Implement change control process
Hand over to operations
Maintenance phase Ongoing day-to-day changes/enhancements Responsibility for maintenance may change to another group or stay with developers
Maintaining and enhancing existing systems Maintenance and enhancement is a primary role of HLL programmers on the mainframe Large corporations continue to use COBOL and other traditional languages for new development:
Existing applications are in HLLs such as COBOL and PL/I New applications are in JAVA, COBOL and PL/I COBOL, PL/I continue to be enhanced to exploit new technologies and new data formats
Summary
Designing and developing an application for the mainframe is similar to other platforms, but some of the questions and conclusions are different. Life cycle of designing and developing an application to run on z/OS includes phases of:
Requirements gathering and analysis Design Development Test and debugging Production Maintenance
Introduction to the new mainframe: z/OS basics Chapter 8: Using programming languages on z/OS
Be able to: List several common programming languages for the mainframe Explain the differences between a compiled language and an interpreted language Create a simple CLIST or REXX program Choose an appropriate data file organization for an online application Compare the advantages of a high level language to those of Assembler language Explain the relationship between a data set name, a DD name, and the file name within a program Explain how the use of z/OS Language Environment affects the decisions made by the application designer

assembler binder compiler debugging dynamic link library generation I/O (input/output) interpreter load modules pre-processor programming language variable
Overview of programming languages

A programming language is the way that a programmer instructs a computer to perform functions Computers only understand machine language Machine language is in binary form and, thus, very difficult to write Humans write programs in a programming language, which is converted into machine language for the computer to process There are many programming languages that have evolved from machine language
Classification of programming languages
1st generation
Machine language specific to hardware and software
2nd generation
Assembler language Specific to hardware Must be assembled Symbolic machine instructions plus data structures corresponding to machine storage and registers
Classification of programming languages (continued)

3rd generation
Procedural languages, known as high-level languages (HLL) Example: COBOL Must be translated (compiled) before execution Usually portable (to an extent) across hardware and software platforms with a recompile
4th generation 4GL

Non-procedural languages Report generators Query languages Examples: RPG, CSP, QMF, SQL
Classification of programming languages (continued)

Visual programming languages (or event-driven languages)
Visual Basic, Visual C++
Object-Oriented language
used in OO technology, e.g. Smalltalk, Java, C++
Other languages
3D applications
Scripting languages
Perl REXX HTML
Choosing a programming language for z/OS

Which language to use? Factors to consider include: Response time requirements for the application Budget allotted for development and ongoing support Time constraints of the project Whether subroutines will be coded in different languages Whether to use a compiled or an interpreted language
Using Assembler language on z/OS Assembler language

Not usually used for application development Machine-specific
Used when:
Accessing bits or bytes Accessing system control blocks Execution efficiency is needed (performance) Require high performance subroutines that can be called from HLL programs
From Assembler source to executable module

Assembler language source statements
High Level Assembler
Messages and listings
Machine language version of the program
Binder
Executable load module
Using COBOL on z/OS COBOL is an English-like programming language Used for business-oriented applications Capabilities of IBM Enterprise COBOL for z/OS and OS/390
Integrate COBOL applications into Web-oriented business processes Inter-operability with Java Parsing of data in XML and Unicode formats
From HLL source to executable module

HLL Source statements
HLL compiler
Messages and listings
Machine language version of the program
Binder
Executable Load module
HLL relationship between JCL and program files

//MYJOB JOB //STEP1 EXEC IGYWCLG ... INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT INPUT ASSIGN TO INPUT1 ..... SELECT DISKOUT ASSIGN TO OUTPUT1 ... FILE SECTION. FD INPUT1 BLOCK CONTAINS... DATA RECORD IS RECORD-IN 01 INPUT-RECORD ... FD OUTPUT1 DATA RECORD IS RECOUT 01 OUTPUT-RECORD ... /* //GO.INPUT1 DD DSN=MY.INPUT,DISP=SHR //GO.OUTPUT1 DD DSN=MY.OUTPUT,DISP=OLD
HLL relationship between JCL and program (continued)

COBOL SELECT statement makes the link between the DDNAMEs INPUT1 and OUTPUT1 and the COBOL FDs INPUT1 and OUTPUT1 respectively The COBOL FDs are associated with group items INPUTRECORD and OUTPUT-RECORD The program is completely independent of the location of the data or the name of the data sets.
Relationship between JCL, program, and data set

DDNAME
program OPEN FILE=INPUT1 READ FILE=INPUT1 ... CLOSE FILE=INPUT 1
DSNAME
JCL for JOB
//INPUT1 DD DSNAME=MY.INPUT
MY.INPUT
Using PL/I on z/OS Full-function, general-purpose high-level programming language Suited for
System programming Commercial Engineering/scientific, etc.
Less verbose than COBOL Less English-like

Referring to physical files by a symbolic file name is used by all of the HLLs - even Assembler language Isolates your program from changes to data set name and data set location data set name and location can change without recompiling program Hard-coding data set names or other such information in a program is not usually considered a good programming practice Externalize these values from programs

//MYJOB JOB //STEP1 EXEC CLG ... OPEN FILE=INPUT1 OPEN FILE=OUTPUT1 READ FILE=INPUT1 ... WRITE FILE=OUTPUT1 ... CLOSE FILE=INPUT1 CLOSE FILE=OUTPUT1 /* //GO.INPUT1 DD DSN=MY.INPUT,DISP=SHR //GO.OUTPUT1 DD DSN=MY.OUTPUT,DISP=OLD
Using C/C++ on z/OS

C is a multi-purpose programming language Suited for:
System-level code Text processing Graphics, etc.
C language contains concise set of statements, with functionality added through its library C is highly consistent across different platforms
Using Java on z/OS

Java is an object-oriented programming language Enterprise COBOL and Enterprise PL/I provide interfaces to programs written in Java Language. Also, DB2 and IMS. Java is pervasive across the zSeries platform. Java Native Interface (JNI) allows your program to call programs written in other languages. The JNI is part of the Java Development Kit.
Using CLISTs on z/OS

CLIST (pronounced "see list") is short for command list, because the most basic CLISTs are lists of TSO/E commands CLIST language is an interpreted language (that is, you don't have to compile and link-edit it) CLISTs are easy to write and test CLIST and REXX languages:
Two command languages available in TSO/E
CLIST programming language is used for:

Performing routine tasks (entering TSO/E commands) Invoking other CLISTs Invoking applications written in other languages ISPF applications (displaying panels, controlling application flow) One-time quick solutions to problems
Using REXX on z/OS

Restructured Extended Executor (REXX) language is a procedural language REXX is an interpreted and compiled language REXX is a more full-function language than CLIST REXX can be used for:
Performing routine tasks (entering TSO/E commands) Invoking other REXX execs Invoking applications written in other languages ISPF applications (displaying panels, controlling application flow) One-time quick solutions to problems System programming Anywhere that we might use another HLL compiled language
Compiled versus interpreted languages

Compiled versus interpreted:
A design-stage decision Performance is slower with interpreted languages
Both compiled and interpreted languages have their strengths and weaknesses No simple answer as to which is better -- it depends on the application. Within a single application, we might decide to use several programming languages.
Advantages of compiled languages

Assembler, COBOL, PL/I, C/C++ are translated by running the source code through a compiler This results in very efficient code that can be executed any number of times Often, the overhead for the translation is incurred just once, when the source is compiled; thereafter, it need only be loaded and executed Compiled programs will be more efficient and performing Interpreted languages are often parsed, interpreted, and executed each time that the program is run, increasing the cost of running the program
Advantages of interpreted languages

An interpretive language is relatively easy to code, test, and change Good for one-time solutions Good for developing application prototypes Ad hoc versus fixed requests Time saver for command strings that are entered repeatedly
Overview of Language Environment

Goals of application development today:
Modularize and share code Develop applications on a Web-based front end
z/OS Language Environment product provides a common environment for all conforming high-level language (HLL) products:
Establishes a common language development and execution environment for application programmers on z/OS Consolidates in a common runtime library, function previously provided in individual library products eliminating the need to maintain separate language libraries
Advantages of z/OS Language Environment

Establishes a common run-time environment for all participating HLLs Combines essential run-time services, such as routines for run-time message handling, condition handling, and storage management All of these services are available through a set of interfaces that are consistent across programming languages You can use one run-time environment for your applications, regardless of the application's programming language or system resource needs Your program can seamlessly call one language from another, to exploit the functions and features in each language
Language Environment components

C/C++ language specific library Java language specific library COBOL language specific library FORTRAN language specific library PL/I language specific library
Language Environment callable service interface, common services, and support routines
Summary
The mainframe supports most programming languages in use today. Your choice of a programming language depends on several factors, including the requirements of the application and the installations ability to maintain the application. Depending on the application requirements, you might use multiple languages or assembler subroutines for certain parts. Remember: When it is time to update the application, other people must be able to program these languages as well. Complexity in design must always be weighed against ease of maintenance.

Chapter 9 Compiling and link-editing a program on z/OS
Be able to:
Explain the purpose of a compiler Compile a source program Create executable code from a compiled program Explain the difference between an object module and a load module Run a program on z/OS

binder copybook linkage-editor load module object module object-oriented code procedure procedure library program library relocatable source module
Source, object, and load modules

A source program can be divided into logical units or modules -that perform specific functions. Each module is assembled or compiled by one of the language translators Input to a language translator is a source module Output from a language translator is an object module Object modules must be processed by the binder before they can be executed Output of the binder is a load module.
Source code to load module
Source module
Precompiler
Compiler
Object module
Binder
Load module
Object module
An object module:
Is a collection of one or more compilation units produced by an assembler, compiler, or other language translator and used as input to the binder (or linkage editor) Is in relocatable format with machine code that is not executable Is stored in an object library
Load module
A load module:
is also relocatable, but with executable machine code is in a format that can be loaded into virtual storage and relocated by program manager, a program that prepares load modules for execution by loading them at specific storage locations.
More about object modules and load modules
Object modules and load modules consist of:

Information (control dictionaries) to resolve cross-references between sections of different modules Text, containing the instructions and data of the program An end-of-module indication (END statement)
What are source libraries?

Source programs are stored in a PDS known as source library Source libraries contain the source code to be:
submitted for a compilation process retrieved for modification by an application programmer
A copybook is a source library containing prewritten text; it is used to copy text into a source program, at compile time.
Compiling programs on z/OS

Compilers:
Translate source code into object code Assign relative addresses to all instructions, data elements, and labels, starting from zero (required in a virtual storage operating system)
Addresses are in the form of a base address plus a displacement (to allow programs to be relocated) References to external programs or subroutines are left as unresolved
Compiling programs on z/OS
Various ways to compile programs on z/OS:

batch job under TSO/E through commands, CLISTs, or ISPF panels for COBOL programs, you can compile programs in a z/OS UNIX shell by using the cob2 command.
Compilation step Define the data sets needed for the compilation Also, specify any compiler options needed by the program
Compilation step example Data set (library) that contains the source code is specified on the SYSIN DD statement:
//SYSIN // DD DSNAME=dsname, DISP=SHR
You can place source code directly in the input stream use this SYSIN DD statement:
//SYSIN DD *
Compiling with cataloged procedures (PROCs)

A common way to compile a program under z/OS is by using a batch job with a cataloged procedure or PROC A PROC contains a set of JCL statements placed in a data set called the procedure library (PROCLIB) The PROC must include the following information:
Job description Execution statement to invoke the compiler Definitions for the data sets needed but not supplied by the PROC
Sample JCL for compiling a COBOL source program inline

//COMP JOB //COMPILE EXEC IGYWC //SYSIN DD * IDENTIFICATION DIVISION (source program) . . . /* //
COBOL compile, link & go PROC

JCL in next slide executes the IGYWCLG PROC PROC is a three-step procedure for compiling a source program, linking it into a load library and executing the load module
The first two steps are the same as those in the compile and link example We do not need to permanently save the load module in order to execute it
Result of running the JCL is to:

compile our inline source program link-edit the object code store the load module (either temporarily or permanently) execute the load module
Executing COBOL CLG PROC

//CLGO JOB //CLG EXEC IGYWCLG //COBOL.SYSIN DD * IDENTIFICATION DIVISION (source program) . . . /* [//LKED.SYSLMOD DD DSN=MY.LOADLIB(PROG1),DISP=OLD]
COBOL CLG PROC

//IGYWCLG PROC LNGPRFX='IGY.V2R1M0',SYSLBLK=3200, // LIBPRFX='CEE',GOPGM=GO //* //* COMPILE, LINK EDIT AND RUN A COBOL PROGRAM //* //* PARAMETER DEFAULT VALUE USAGE //* LNGPRFX IGY.V2R1M0 //* SYSLBLK 3200 //* LIBPRFX CEE //* GOPGM GO //* //* CALLER MUST SUPPLY //COBOL.SYSIN DD ... //* //COBOL EXEC PGM=IGYCRCTL,REGION=2048K //STEPLIB DD DSNAME=&LNGPRFX..SIGYCOMP, // DISP=SHR //SYSPRINT DD SYSOUT=* //SYSLIN DD DSNAME=&&LOADSET,UNIT=VIO, // DISP=(MOD,PASS),SPACE=(TRK,(3,3)), // DCB=(BLKSIZE=&SYSLBLK) //SYSUT1 DD UNIT=VIO,SPACE=(CYL,(1,1)) //SYSUT2 DD UNIT=VIO,SPACE=(CYL,(1,1)) //SYSUT3 DD UNIT=VIO,SPACE=(CYL,(1,1)) //SYSUT4 DD UNIT=VIO,SPACE=(CYL,(1,1)) //SYSUT5 DD UNIT=VIO,SPACE=(CYL,(1,1)) //SYSUT6 DD UNIT=VIO,SPACE=(CYL,(1,1)) //SYSUT7 DD UNIT=VIO,SPACE=(CYL,(1,1)) //LKED EXEC PGM=HEWL,COND=(8,LT,COBOL),REGION=1024K //SYSLIB DD DSNAME=&LIBPRFX..SCEELKED, // DISP=SHR //SYSPRINT DD SYSOUT=* //SYSLIN DD DSNAME=&&LOADSET,DISP=(OLD,DELETE) // DD DDNAME=SYSIN //SYSLMOD DD DSNAME=&&GOSET(&GOPGM),SPACE=(TRK,(10,10,1)), // UNIT=VIO,DISP=(MOD,PASS) //SYSUT1 DD UNIT=VIO,SPACE=(TRK,(10,10)) //GO EXEC PGM=*.LKED.SYSLMOD,COND=((8,LT,COBOL),(4,LT,LKED)), // REGION=2048K //STEPLIB DD DSNAME=&LIBPRFX..SCEERUN, // DISP=SHR //SYSPRINT DD SYSOUT=* //CEEDUMP DD SYSOUT=* //SYSUDUMP DD SYSOUT=*
Load module creation and loading
Source modules
Assembler or compiler
Object modules
Program management binder Linkage Editor Program object PDSE program library Load modules in PDS program library
Batch loader
A
Program management loader Load modules in virtual storage ready for execution
Linkage Editor
The linkage editor prepares a load module to be brought into real storage for execution As input, the linkage editor accepts object modules, control statements, and user-specified input. Output of the linkage editor is:
A load module placed in a library (a PDS) as a named member Diagnostic output produced as a sequential data set
How a load module is created

The linkage editor assign virtual storage addresses to control sections of the module and resolves references between them. The output load module contains the input object modules and input load modules processed by the linkage editor The load module also contains the text from each input module, and an end-of-module indicator
Using the binder Performs all of the functions of the linkage editor Can also process program objects stored in PDSE data sets Binder removes restrictions of the linkage editor Input can include traditional data sets and z/OS UNIX files
Binder sample
Link-edits an object module The output from the LKED step will be placed in a private library identified by the SYSLMOD DD The input is passed from a previous job step to a binder job step in the same job (for example, the output from the compiler is direct input to the binder)
. . . //LKED EXEC PGM=IEWL,PARM='XREF,LIST', IEWL is IEWBLINK alias // REGION=2M,COND=(5,LT,prior-step) //* //* Define secondary input //* //SYSLIB DD DSN=language.library,DISP=SHR optional //PRIVLIB DD DSN=private.include.library,DISP=SHR optional //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1)) ignored //* //* Define output module library //* //SYSLMOD DD DSN=program.library,DISP=SHR required //SYSPRINT DD SYSOUT=* required //SYSTERM DD SYSOUT=* optional //* //* Define primary input //* //SYSLIN DD DSN=&&OBJECT,DISP=(MOD,PASS) required // DD * inline control statements INCLUDE PRIVLIB(membername) NAME modname(R) /*
Creating load modules for executable programs
A load module is an executable program stored in a partitioned data set program library Creating a load module to execute only will require that you use a batch loader or program management loader Creating a load module that can be stored in a program library requires that you use the binder or linkage editor
Creating load modules for executable programs (continued)
In all cases, the load module is relocatable

That is, it can be located at any address in virtual storage within the confines of the residency mode (RMODE)
Relocatable programs allow an identical copy of a program to be loaded in many different address spaces, each being loaded at a different starting address
Batch loader
The batch loader: Performs link-editing and loading into one job step Accepts object modules and load modules, and loads them into virtual storage for execution Prepares the executable program in storage and passes control to it directly The batch loader is replaced by the binder in later releases of z/OS.
Program management loader The program management loader:

can load program objects reads both program objects and load modules into virtual storage and prepares them for execution resolves any address constants in the program to point to the appropriate areas in virtual storage and supports the 24-bit, 31-bit and 64-bit addressing ranges
//USUAL JOB A2317P,'COMPLGO' Compile, link & execute JCL //ASM EXEC PGM=IEV90,REGION=256K, EXECUTES ASSEMBLER // //SYSPRINT //SYSPUNCH //SYSLIB //SYSUT1 // //SYSLIN // //SYSIN . . . /* //LKED // //SYSPRINT //SYSLIN //SYSUT1 // //SYSLMOD // //GO // //SYSUDUMP //SYSPRINT // //OUTPUT // //INPUT /* // PARM=(OBJECT,NODECK,'LINECOUNT=50') DD SYSOUT=*,DCB=BLKSIZE=3509 PRINT THE ASSEMBLY LISTING DD SYSOUT=B PUNCH THE ASSEMBLY LISTING DD DSNAME=SYS1.MACLIB,DISP=SHR THE MACRO LIBRARY DD DSNAME=&&SYSUT1,UNIT=SYSDA, A WORK DATA SET SPACE=(CYL,(10,1)) DD DSNAME=&&OBJECT,UNIT=SYSDA, THE OUTPUT OBJECT MODULE SPACE=(TRK,(10,2)),DCB=BLKSIZE=3120,DISP=(,PASS) DD * inline SOURCE CODE Source Code EXEC PGM=HEWL, EXECUTES LINKAGE EDITOR PARM='XREF,LIST,LET',COND=(8,LE,ASM) DD SYSOUT=* LINKEDIT MAP PRINTOUT DD DSNAME=&&OBJECT,DISP=(OLD,DELETE) INPUT OBJECT MODULE DD DSNAME=&&SYSUT1,UNIT=SYSDA, A WORK DATA SET SPACE=(CYL,(10,1)) DD DSNAME=&&LOADMOD,UNIT=SYSDA, THE OUTPUT LOAD MODULE DISP=(MOD,PASS),SPACE=(1024,(50,20,1)) EXEC PGM=*.LKED.SYSLMOD,TIME=(,30), EXECUTES THE PROGRAM COND=((8,LE,ASM),(8,LE,LKED)) DD SYSOUT=* IF FAILS, DUMP LISTING DD SYSOUT=*, OUTPUT LISTING DCB=(RECFM=FBA,LRECL=121) DD SYSOUT=A, PROGRAM DATA OUTPUT DCB=(LRECL=100,BLKSIZE=3000,RECFM=FBA) DD * PROGRAM DATA INPUT data
Load library A load library contains programs ready to be executed A load library can be one of the following:
System library Private library Temporary library
System library
Unless a job or step specifies a private library, the system searches for a program in the system libraries when you code: //stepname EXEC PGM=program-name The system looks in the libraries for a member with a name or alias that is the same as the specified program-name The most used system library is SYS1.LINKLIB, which contains executable programs that have been processed by the linkage editor
Private library
Private libraries are useful for storing programs too seldom needed to be stored in a system library User-written programs are usually stored as members in a private library To indicate that a program is in a private library, you code the DD statement defining the library with JOBLIB or STEPLIB Result: The system searches for the program to be executed in the library defined by the JOBLIB or STEPLIB DD statement before searching in the system libraries.
Overview of compilation Afterexecution to Link-edit

After compilation
PROGRAM B PROGRAM A 140 KB 0 80 KB PROGRAM A 0 PROGRAM B 0 60 KB
PROGRAM LIBRARY
2 GB
2-GB Virtual Storage Address Space
80 KB
Common
16 MB
Load Module
MYPROG
20 KB
Object Modules
MYPROG
Using procedures
Saves time and prevents errors Consist of job control statements placed in a PDS or PDSE known as a procedure library When stored in the system procedure library SYS1.PROCLIB (or an installation-defined procedure library) is called a cataloged procedure A procedure in an input stream is called an inline procedure Limit of 15 inline procedures per job.
Sample definition of a procedure

//DEF //NOTIFY //DD1 // //DD2 // PROC STATUS=OLD,LIBRARY=SYSLIB,NUMBER=777777 EXEC PGM=ACCUM DD DSNAME=MGMT,DISP=(&STATUS,KEEP),UNIT=3400-6, VOLUME=SER=888888 DD DSNAME=&LIBRARY,DISP=(OLD,KEEP),UNIT=3350, VOLUME=SER=&NUMBER
Summary
The basic steps for turning a source program into an executable load module are:
1. 2. 3. compile link-edit bind
The compile step translates source code into relocatable machine language, in the form of object code. Object code must be processed by a binder (or linkage editor or loader) before it can be executed.
Summary (continued)
The binder resolves unresolved references in the object code and ensures that everything needed by the program is included in the final load module. To execute a load module, the binder loads the module into real storage and then transfers control to it to begin execution.
Introduction to the new mainframe: z/OS basics Chapter 10 Overview of z/OS online workloads
Be able to:
Describe the role of large systems in a typical online business. List the attributes common to most transactional systems. Explain how databases are used in a typical online business. Describe two models for network connectivity for large systems.

DBMS multithreading multitasking root segment SQL thread transaction
Example of online processing: a travel agency
Mainframe applications designed for:

employee and customer information contacts with car rental companies hotels airline schedules
Changes must be immediately reflected to application end-users (in real time) Contrast with batch processing
Example of online processing (continued)

Car Rental Agency Hotel Airline
WAP Travel Agency
HTTP
A practical example
Car Rental Agency
Hotel
Airline
Travel Agency
HTTP
WAP
Transactional systems Requirements: ACID

Atomicity Consistency Isolation Durability
Transactional systems: terminology Commit and roll back Multitasking and multithreading Thread Reentrancy
Characteristics of a transactional systems

Many Users
Repetitive Short Interactions Shared Data Data Integrity Low
Cost/Transaction
Two-phase commit
A INITIATOR Update local resources Prepare B Agent of A Update local resources Receive Prepare Commit SYNCPOINT Commit SYNCPOINT SYNCPOINT
Phase 2
C Agent of B Update local resources
Phase 1
Receive
What is a database?
Shipment Shipment No Dispatch Date Shipment to Customer Customer Customer No Customer Address Customer Orders Parts Customer Order Order No Quantity Delivery Address
Order for Part Part Part No Name Unit Price Purchase Order Purchase of Part Attributes Order No Quantity Relationships
Why use a database? Reduce programming effort Manage data more efficiently Easy to separate confidential/sensitive info Provide a greater level of security Access & update simultaneously Ensure consistency Provide backup and recovery Utilities to monitor and tune Structure change does not impact existing developments
Role of the database administrator

Provides standards for databases;administers databases Guides, reviews and approves database designs
DBA
Determines rules for accessing data and monitors its security
Controls database integrity & availability; monitors activities for backup and recover
Approves the use of any programs that access production databases
Databases: terminology Entities Data attributes Entity relationships Application functions Access paths
Databases on z/OS Hierarchical databases, such as IMS Relational database management system (RDBMS), such as DB2
Hierarchical DB : Relationships & sequence

Level 1
ROOT (1)
Level 2
Segment A (2)
Segment B (7)
Segment C (9)
Level 3
Segment D (3)
Segment E (4)
Segment F (8)
Segment G (10)
Segment H (12)
Level 4
Segment I (5)
Segment J (6)
Segment K (11)
Hierarchical data structure

Level 1 (or root)
PART
Parent of STOCK and PURCHASE ORDER
Level 2
STOCK
PURCHASE ORDER
Child of Part and Parent of DETAIL
Level 3
DETAIL
DETAIL
Child of PURCHASE ORDER
Segment types and their relationships

Record 1
PART 1
Record 2
PART 2
Record 3
PART 1
Parent of DETAIL
STOCK 11 STOCK 12
ORDER 11
STOCK 21
ORDER 21 ORDER 22
STOCK 31
ORDER 31
These are twins
DETAIL 111 DETAIL 112
Siblings
DETAIL 211
DETAIL 311
All segments are dependents of PART
DETAIL is: Dependent of ORDER Dependent of PART Child of ORDER Grandchild of PART
Relational DBMS: Codds relational principles
Primary key Referential Integrity Easy to use query language Nulls Normalization/Denormalization
1NF: structure of a table 2NF: 1-to-1 3NF: 1-to-many relationships 4NF, 5NF: many-to-many relationships
Relational DBMS: data structures and SQL

Data Structures Databases Tables : column, row and value Indexes Keys
Primary Key Unique Key Foreign Key
SQL DML: SELECT, UPDATE, INSERT, DELETE DDL: CREATE, ALTER, DROP DCL: GRANT, REVOKE
A database comparison: IMS:

Data is relatively static Navigational : need to know the structure to get to the right data
DB2:
Changeable info Change in structure : no impact on existing application Non-Navigational : no need to know the structure to get to the right data (just tablename and columnname(s))
Summary
Interaction with the computer happens online through the help of a transaction manager. Many transaction managers and database managers exist, but their principles are similar. Data can be stored in a flat file, but this can result in duplication or inconsistent data. It is better to create central databases, which can be accessed (reading and changing) from different places. The handling of consistency, security, etc. is done by the database management system.
Introduction to the new mainframe: z/OS basics Chapter 11 Understanding transaction managers on z/OS
Be able to:
Explain the role of CICS in online transaction processing Describe CICS programs, CICS transactions, and CICS tasks Explain what conversational and pseudoconversational programming is Explain CICS and Web-enabling Discuss the IMS components

BMP BMS conversational DBMS CICS TS CICS command IRLM bind transaction CICS command view modified source task/thread region PSB IMS TM transaction unit of work task/thread SPUFI SQLJ SYSADM EXPLAIN
What is CICS? Customer Information Control System Transactional subsystem of z/OS which:
run online applications the same time, many users, same application(s) manages the sharing of resources integrity of data prioritization of execution, with fast response.
CICS in a z/OS system

z/OS
Transactional system
DATA
Application Program
User
Languages & Platforms Languages: COBOL OO COBOL C C++ JAVA PL/I Assembler Platforms: zSeries (z/OS, OS/390, VSE) Intel servers TXSeries (AIX, HP-UX, Solaris and Windows)
CICS Programming roadmap Design application Write & test program (includes compiling) Define program & transaction in CICS resources Define other resources (files, queues, etc) in CICS resources Make resources known to CICS
Conversational
User Types Inputs Menu
Pseudo-Conversational
PROGV000
Conversational:
Enter account ______ Function code______
SEND MAP W AIT Menu Enter account 1234_ Function code M____ RECEIVE MAP READ FILE UPDATE
Record Update User Types Changes Enter account 1234 Nam e: Smith Am ount: $10.00 Date: 05/28/04
SEND MAP W AIT RECEIVE MAP REW RITE FILE
Menu Enter account ______ Function code______ "Update confirmed"
SEND MAP RETURN
Conversational Pseudo-Conversational Pseudo-Conversational:

PROGV000 User Types Inputs Menu Enter account ______ Function code______ SEND MAP... RETURN TRANSID(V001)....
PROGV001 Menu Enter account 1234_ Function code M____ RECEIVE MAP... .... READ FILE... .... SEND MAP... ... RETURN TRANSID (V002)....
Record Update User Types Changes Enter account 1234 Name: Smith Amount: $10.00 Date: 05/28/04
PROGV002 RECEIVE MAP... .... READ FILE UPDATE.... REW RITE FILE.... .... SEND MAP... ... RETURN TRANSID (V000)...
Menu Enter account 1234 Name: Sm ith Amount: $99.50 Date: 05/28/04 "Update Confirmed"
CICS Programming commands

General format: EXECUTE CICS (or EXEC CICS) + command e.g. in COBOL: EXEC CICS function option option ... END-EXEC. CICS command example : EXEC CICS READ FILE(ACCTFIL)
RIDFLD(ACCTC) UPDATE ...
END-EXEC.
CICS transaction flow

Operating System
ABCD
Terminal Control
System Services
3
Storage Mgmt.
Program Library
File or DB
CICS transaction flow (Cont)System Operating
(menu screen)
Program Library
BMS
Program ABCD01
File Control
File or DB
CICS transaction flow (Cont)

Operating System
User's Next Input
Program Library
6
Program ABCD01
File Control
8
BMS
File or DB
CICS services for Application Programs Application program interface: use CICS commands Terminal control services: use Basic Mapping Support (BMS) File & database control services:
CICS file control (mainly VSAM) Database control (DL/I & DB2)
Other CICS Services: Task Control
- Program Control Temporary Storage (TS) & Transient Data Control (TD) Interval Control - Storage Control - Dump & Trace Control
Defining the screens BMS macros: a form of assembler language Result of an assembles : Physical Map Physical map contains info to :
build the screen merge variable data between program & screen send variables back to program
Program Control Level

0 CICS
CICS
Level 1
Program1 LINK ...RETURN
Level 2
Program 2 XCTL
Program 3 LINK ...RETURN
Level 3
Program 4
.....RETURN
Example of CICS application user screen ABCD Average salary by department

Type a department number and press enter. Department number: A02 Average salary($): 58211.58
F3: Exit
CICS and Web-enabling 4 major elements of web-enabled applications: Presentation logic Integration logic Business logic Data logic
W eb Browser
CICS Web support

Direct connection CICS TCP/IP listener W eb-aware presentation logic C O M M A R E A 3270 Web bridge 3270 presentation logic CICS region
C W S
IBM HTTP Server for OS/390
CICS application
CICS WebServer Plugin
EXCI
CICS Transaction Gateway

CICS Transaction Gateway Configuration tool Java client application Gateway daem on CTG.INI ctgcfg
JNI
ECI EPI ESI Client daemon Transport drivers CICS server Network
What is IMS? Information Management System 3 components:

The Transaction Manager (TM) the Database Manager (DB) Set of system services, providing common services to the other 2
IMS overview
z/OS Console
IMS Logs
IMS System
Transaction Manager
Database Manager
IMS Message Queues
IMS Databases
IMS Transaction Manager messages Four types of messages:

Transactions To go to another logical destination Commands for IMS For the IMS APPC feature to process
Summary
The continued growth of the Internet has caused many corporations to consider the best ways to make their legacy systems available to users on the Internet. CICS is a transactional processing subsystem. CICS applications are traditionally run by submitting a transaction request. Information Management System (IMS) consists of three components:
Transaction Manager (TM) Database Manager (DB) A set of system services common to both TM and DB
Introduction to the new mainframe: z/OS basics Chapter 12 Understanding database managers on z/OS
Be able to:
Explain the role of DB2 in online transaction processing. List common DB2 data structures. Compose simple SQL queries to run on z/OS. Give an overview of application programming with DB2. What the IMS components are The structure of the IMS DB subsystem

bind DBMS EXPLAIN modified source SPUFI SQL SYSADM view
DB2 Concepts: Data Structures Storage group

VSAM LDS VSAM LDS
Data base Table Space
Views
Table
Index Space
Index
Schema structures User-defined Data Type (UDT) User-defined Function (UDF) Triggers Large Object (LOB) Stored Procedure
System Structure Catalog & Directory: stores ALL DB2 information Buffer Pool Active and Archive Logs Bootstrap data set (BSDS)
DB2 for z/OS Architecture DB2 Address Spaces

System Service address space (SSAS) Database Service address space (DBAS) Internal Resource Lock Manager (IRLM)
DB2 Attachment Facilities

CICS IMS TSO
Invoke SQL onneed to create First you z/OS: SPUFI
the output file (if not existing)
Select option 1 to enter SPUFI

Invoke SQL on z/OS: SPUFI (CONT)
Enter the input and output dataset, if they are not yet in place. Change the member of the PDS, if you want to enter a new SQL Defaults are set to NO from YES.
Enter the SQL statement you want to execute. Press F3 to return to the previous screen (to execute the SQL).
When you get back to this screen, the edit input is put to *. Press ENTER to execute the SQL and to see the output.
F8 brings the rest of the results on your screen
Application Programming: the flow
Source Program
Modified Source
Precompile
DBRM
Compile
Include Member
Bind
DCLGEN
Object Module
Package
Linkedit
Bind
Load Module
RUN
Plan
Get the access path: EXPLAIN EXPLAIN ALL SET QUERYNO
=1 SELECT EMPNO, LASTNAME FROM EMP WHERE LASTNAME = 'MILLER';
-The query is NOT executed -The access path is placed in userid.PLAN_TABLE, if it exists
Other development options ODBC JAVA SQLJ JDBC XML XML Column Access XML Collection Access
Managing DB2: System Administration Installation System Object Management System and Disaster Recovery Monitoring System Performance
Managing DB2: Database Administration Creation & Management of DB2 Objects Execution of Utilities:
Data Organization Backup & recovery Data Consistency
Commands
Functions of the IMS database manager A DBMS provides:

Multiple-user access to a single copy of data Integrity for all updates Minimal hardware and OS access method dependencies Reduced data redundancy
Implementation of IMS Databases Depending on user' requirements Technologies :

IMS DB or DL/I or DL1 or Full Function Database IMS DEDB
or
Data Entry DB or Fast Path Database
IMS Main storage database (MSDB) IBM DB2
Database Recovery Control (DBRC)
Structure of IMS DB Subsystem

Network
Control Region Address Space
IMS Message Queues
IMS System
Logs
IMS Libraries
Fast Patch DBs
Dependent Region Address Space
DLI Separate Address Space
DBRC Region
MPP
Application Program
IFP
Application Program
BMP
Application Program
Java Message Processing
Java Batch Processing
Full Function DBs
RECONs Application Region Address Space
System Address Space

Up to 99 in total
Databases used by IMS: Database basics
Access paths Normalization within IMS

Unique entities 1 occurrence only No many-to-many relationships
Databases used by IMS: DB Model

Sequence to access the segments
ROOT (1)
Segment A2 (8)
Segment B2 (14)
Segment A1 (2)
Segment D3 (9)
Segment B1 (10)
Segment D2 (4) Segment D1 (3)
Segment E3 (7) Segment E2 (6) Segment E1 (5)
Segment G2 (12) Segment G1 (11) Segment H1 (13)
Databases used by IMS: DB model
Additional access paths to segments

Logical relationships Secondary indices
Application programming overview
Program is subroutine of IMS region controller

Needs a program specification block (PSB) Uses services:
Send/receive message from terminals Access db Issue IMS commands Issue IMS service calls
e.g. Checkpoint calls, Sync call
Program Structure
PCB-Mask E N T R y Call info from DLI
DLI modules
IO AREA Segments to/from databases
E X I T
Application Program PROGRAM ENTRY DEFINE PCB AREAS GET INPUT RECORDS FROM INPUT FILE CALLS TO DL/I DB FUNCTIONS
RETRIEVE INSERT REPLACE DELETE
CHECK STATUS CODES PUT OUTPUT RECORDS TERMINATION

IMS & the World Wide Web
Message flow in IMS transaction
1,2
4,5
NCP
VTAM
IMS
MPP
8,9
3270 Terminal
IMS & the World Wide Web
Message flow between Web Browser & Web Server
1,2
4,5
TCP/IP
TCP/IP
Web Server
7 6
CGI Program
8,9
Web Browser
IMS Message flow IMS transaction & Web Server CGI Programs & the World Wide Web
1,2 3 4,5
NCP
VTAM
IMS
MPP
8,9
3270 Terminal
Program to Program Communications

1,2 3 4,5
TCP/IP
TCP/IP
Web Server
7 6
CGI Program
8,9
Web Browser
Summary
The relational database is the predominant approach to data organization in today's business world. IBMs DB2 implements such relational principles as primary keys, referential integrity, a language to access the database (SQL), nulls, and normalized design. In a relational database, the most fundamental structure is the table with columns and rows.
Summary (continued)
The only way to access the data in DB2 databases is with SQL. On the mainframe, SPUFI is a tool used to enter SQL statements. The DBRM performs a bind process that determines the access path and stores this executable SQL code in a package. SQL can handle both static and dynamic statements, and EXPLAIN can be used to find out what access path the optimizer chose for the SQL.
Chapter 13: z/OS HTTP Server
Objectives After reading this chapter, you will be able to:

List the three server modes Explain static and dynamic Web pages List at least two functions from each of the following modes: Basic Security Caching Understand how to deploy a Web application on z/OS
Key terms in this chapter CGI dynamic FRCA HTTP J2EE LDAP SSL static
Introduction to Web applications on z/OS:
Past:
Many applications are tied to z/OS (CICS, DB2) New developments made on other platforms
Now:
Integrate both on z/OS
z/OS HTTP Server Server modes:

Stand-alone server Scalable server Multiple servers
Static Web pages Dynamic Web pages
Dynamic Web Pages Common Gateway Interface (CGI)

1
http://www.myzseries.com/cgi-bin/test.cgi URL
HTTP Server Address Space
z/OS Address Spaces

test.cgi
2
httpd.conf CGI application
Response Client Browser
test2.cgi CGI application
Dynamic Web Pages - Interaction with WebSphere

WebSphere plug-in, same address space
http://www.myzseries.com/my.jsp URL httpd.conf
HTTP Server
Response Client Browser was.conf WAS plugin

Servlet
CICS Server or IMS Server

Web container inside HTTP Server, separate EJB container
http://www.myzseries.com/my.jsp URL
HTTP Server
J2EE Server
httpd.conf
Response Client Browser was.conf WAS plugin

Servlet
EJB Container
EJB

Separate J2EE server with both Web container and EJB container
http://www.myzseries.com/my.jsp URL
HTTP Server
J2EE Server
EJB Container
httpd.conf
Response Client Browser was.conf
EJB
Web Container
Servlet
WAS plugin
JSPs
HTTP server capabilities Basic functions :

EBCDIC/ASCII file access System Management Facilities Tracing & logging Server Side Includes Simple Network Management Protocol Management Information Base (SNMP MIB) Cookies support Multi Format Processing Persistent connections Virtual hosts
HTTP server capabilities (continued)
Security functions:
Thread level security HTTPS/SSL support LDAP support Certificate authentication Proxy support
HTTP server capabilities (continued) File caching:

HTTP server caching HFS files HTTP server caching z/OS data sets Unix System Service caching HFS files Fast Response Cache Accelerator (FRCA)
Summary In this chapter, you learned about:

The three server modes Static and dynamic Web pages These HTTP server modes: Basic Security Caching Deploying a Web application on z/OS
Chapter 14 WebSphere Application Server on z/OS
Be able to:
List the six qualities of the J2EE Application model Give three reasons for running WebSphere Application Server under z/OS Name three connectors to CICS, DB2, and IMS

cell CS CGI EIS JMX J2EE SR cluster node
Introduction to Web applications on z/OS Past:

Many applications are tied to z/OS (CICS, DB2) New developments made on other platforms
Now:
Integrate both on z/OS
WebSphere Application Server for z/OS Conform Software Development Kit (SDK) Interoperates with other subsystems
Application Server = Instance
SR CR
CR = Controller Region SR = Servant Region

WebSphere Application Server for z/OS Organization based on concepts: Servers Nodes (and Node Agents): a logical grouping of WebSphere-managed servers Cells: a grouping of Nodes Within the address spaces, concept of CONTAINER
J2EE Application Model in z/OS Same as on other platforms, following SDK: Functional Reliable Usable Efficient Maintainable Portable
Running WebSphere Application Server for z/OS
Basics of WebSphere on z/OS Consolidation of workloads WebSphere for z/OS Security Continuous availability (see next foils) Performance
WebSphere on z/OS - continuous availability

WebSphere with Sysplex Distributor
SYSPLEX z/OS cluster WebSphere Application Server RACF RRS
RA
Connection Address space
EIS/DB
TCP/IP memory to memory
SD
WebSphere Application Server
RACF
RRS
RA
z/OS
Connection Address space
EIS/DB

Clustering of Server in Cell
MVS System or LPAR Cluster servers B and D MVS System or LPAR
Deployment Manager
Browser Browser
Daemon CR Server A CR SR Daemon CR Server C CR SR
Server B CR Install Application into Cluster SR Cluster
Server D CR SR
HFS HFS
APP APP APP
HFS HFS
SYSA CF
SYSB

Vertical and Horizontal Cluster
MVS System or LPAR Daemon CR MVS System or LPAR Daemon CF CR
Cell A
Servers are clustered through the administrative interface. Any given server may be a member of only one cluster at a time
You can not have Server_C be a member of two different clusters, for example.
DM CR
Node
Node Agent CR
Node
Node Agent
Node
"Vertical" Cluster
Two or more servers in the same system or LPAR
SR
CR
Hybrid of vertical and horizontal is permitted
Server A CR
Server D CR SR
Server B CR SR
Server E CR SR
"Horizontal" Cluster
Two or more servers across multiple nodes (or systems)
Server C CR SR
Server F CR SR
Running WAS on z/OS - Performance WebSphere uses three distinct functions of WLM: Routing Queuing Prioritizing
Application Server Configuration on z/OS

Base Server Node
Cell Location Service Daemon (BBODMNB) z/OS functions UNIX System Services TCP/IP FTP RRS Workload Management Language Environment Security Server ARM IMS/TM CICS/TS MQ JMS server HTTP internal transport v5 run-time environment Controller Servant
Controller
Application server node
J2EE scalable application server (server1)
HTTP server
Application Server Configuration on z/OS

Network Deployment Manager
Cell Location Service Daemon (BBODMNB) Node 2: Application server Node agent (BBON001) JMS server (BBOJ001) z/OS functions UNIX System Services TCP/IP FTP RRS Workload Management Language Environment Security Server ARM IMS/TM CICS/TS MQ
Controller Controller Controller
Node 1: Deployment manager Deployment manager (BBODMGR)
J2EE scalable application server (server1)
HTTP internal transport
v5 run-time environment Controller Controller Servants
Connectors for Enterprise Information Systems
Some considerations: Expensive Must be secured Need to perform well Must be monitorable Methods needed Quality of devices
Basic Architecture of an connector to an EIS

z/OS
WebSphere Application Server
RACF
RRS
Server A
RA
EIS/DB
memory to memory
C=connector RA=resource adapter

Mainframe Connectors CICS Transaction Gateway IMS Connect DB2 JDBC
Summary In this chapter, you learned to:

List the six qualities of the J2EE Application model List three reasons for running WebSphere Application Server under z/OS Name three connectors to CICS, DB2, and IMS

Chapter 15 WebSphere MQ
Chapter 15 objectives Be able to:

Explain why messaging and queuing is used Describe the asynchronous flow of messages Explain the function of a queue manager List three zSeries-related adapters

local queue channel message-driven MQI asynchronous application dead-letter queue QM remote queue syncpoint
Synchronous communication model

B
MQI
MQI
Que
ue 1
ue 2 Que
MQI
MQI
A
Asynchronous communication model

B
MQI
MQI
ue Que
ue 2 Que
MQI
MQI
A C
Styles of Communication
Conversational
Program A
Program B
Program A
Call and return
Program A
Program A
Messaging
Program B
Program C
Messages Types of messages:

Datagram Request Reply Report
Queue Manager
Program DB2 Data
Program Queue manager Messages
Program
Message Queue Interface (MQI)

Major calls Application
MQCONN MQCONNX MQOPEN MQCLOSE MQPUT MQPUT1 MQGET
MQI
Queue manager
Minor calls
MQBEGIN MQCMIT MQBACK MQINQ MQSET
Process object
Namelist object
Queue manager object
Message layout
Message = Headers + Application data
Headers
Application data
Set by application and queue manager Headers MQMD MQXQH MQDLH and so forth
Any sequence of bytes Private to the sending and receiving applications Not meaningful to the queue manager
Queue types
Channels
Program 1 get put Program 2 get put
MQI
Local Q2 Remote Q1 Local Q1
MQI
Remote Q2
QMA
XmitQ QMB
QMB
XmitQ QMA
Channel QMB.QMA Receiver
Channel QMA.QMB Sender
Channel QMB.QMB Receiver
Channel QMB.QMA Sender
Network
Security
Local Queue Manager
MCA
MCA
MQMD
Application Data
Remote Queue Manager
USERID Context
Database
Data Integrity
Synchronous model Write Send 2-phasa commit Unit of work
DB
Receive Write Syncpoint
DB
Syncpoint
DB
Write
Asynchronous model
q
Unit of work 1 Put Syncpoint
Get Write Syncpoint Unit of work 3
q DB
Unit of work 2
Travel agency example revisited

MQPUT CAR RENTAL MQPUT FLIGHT MQPUT HOTEL Car rental
Car MQPUT
Flight
MQPUT Reply-to queue Hotel
Flight
MQPUT
MQGET Reply-to-queue
Hotel
Interfacing to WebSphere MQ MQ is available on many platforms On z/OS it has interfacing to:

CICS IMS Batch or TSO
MQ functions Common application programming interface (MQI) Assured delivery: messages do not get lost and they arrive only once No synchronous access needed Message driven application Quicker development due to shielding of the network
Summary
Messaging and queuing enables communication between applications on different platforms. WebSphere MQ is an example of software that manages messaging and queuing in the mainframe and other environments. With messaging, programs communicate by through messages, rather than by calling each other directly. With queuing, messages are retained on queues in storage, so that programs can run independently of each other (asynchronously).
Chapter 16 Topics in z/OS system programming
Objectives In this chapter you will learn to:

Discuss the responsibilities of a z/OS system programmer Explain system libraries, their use, and methods for managing their content Configure consoles IPL a system
Key terms
HCD IODF SYSRES SMP/E LNKLST IPL WTOR PARMLIB PROCLIB system symbols PSA LPA nucleus LOADPARM SQA
Considerations for a new application New batch applications to scheduler New JCL procedures to procedure library Document operational procedures Security privileges Add load libraries to system Automation Reload system (if required)
What is systems programming? A systems programmer installs, customizes and maintains the operating system To do this they need knowledge of
Hardware
Storage Processor
Software
System libraries and data sets
Current customization
System programming overview
SYSTEM PROGRAMMING
System performance and workload management Security, Availability and Integrity
System parameters and system libraries management Controlling operating activities and functions
z/OS new features implementation and z/OS system maintenance
iodfxx
Hardware I/O configuration
z/OS operational system administration is:

Software installation and maintenance Customize parameters System libraries for software System data sets z/OS system address spaces and subsystems Real and virtual storage
z/OS Workload Manager

Workload manager (WLM) is an address space which manages the tasks running on the system Uses an installation-defined policy to determine relative priority of competing workloads WLM can also be used to manage hardware resources
System performance
System tuning is constant and iterative Only a real problem when resources are constrained WLM is one component Can only manage what is set up Initial set up of initiators and other resources plays a great part
Job flow
Job entry subsystem (JES) controls job flow Receives jobs into system Initiates the job Controls initial output processing
I/O device management

Input/output device configuration must be defined to both hardware and software HCD is used to build an I/O definition file This definition can be activated to both software and hardware dynamically Sometimes major changes require an IPL of software or POR of hardware
Security
Protection of data against unauthorized disclosure, transfer, modification or destruction Systems programmer installs and maintains the security system
Integrity
Designed, implemented and maintained to protect against unauthorized access Unauthorized software must not be able to access authorized states Unauthorized software must not be able to bypass system security such as RACF
Availability
System availability is designed to be very high Many systems require 24 hour 7 day operation
Change control
I/T organizations achieve their goals through disciplined change management processes and policy enforcement These goals include:
High service availability Increased security Audit readiness Cost savings
z/OS operation
This is the day to day management of the operating environment both software and hardware Operator interaction is message and command based Automated processing of the messages and commands is available and operators now manage by exception
z/OS Production Control

Build batch schedules Promote programs to production Investigate batch failures
z/OS system libraries
z/OS software Customization data
Non-z/OS (CICS, DB2) Mainframe User defined exits
Non-IBM software User data
Types of data
z/OS software on SYSRES volumes Non-z/OS software e.g. CICS Non-IBM software Customization data parmlib, IODF User exits User data often the largest pool of volumes
z/OS system libraries

These are the most important system libraries
SYS1.LINKLIB prime system software library SYS1.LPALIB system subroutines SYS1.NUCLEUS basic supervisor modules SYS1.PROCLIB system procedure JCL SYS1.PARMLIB control parameters
SYS1.LINKLIB
SYS1.LINKLIB is the main software library LNKLST concatenation is a group of system and userdefined libraries which form part of the system search order for load modules Not all on one volume
System search order for programs

Programs (load modules) must be in central storage and therefore in the virtual storage of the address space before they can run System has a defined search order for a newly requested program
Search order for programs

1. STEPLIB if present 2. JOBLIB if present and no STEPLIB 3. Link Pack Area (LPA)
1. 2. 3. 4. Dynamic LPA modules Fixed LPA Modified LPA Pageable LPA
4. Linklist
Overview of LNKLST Fig 17.3

LNKLST SET
System Data Sets
Search order
SYS1.LINKLIB SYS1.MIGLIB SYS1.CSSLIB
Other Load Libraries

Using PROGxx to define LNKLST

A LNKLST set is an ordered list of datasets for processing as the LNKLST concatenation The PROGxx member may be used to define other lists as well as the linklist The linklist must be:
Defined Have libraries added Activated
Example linklist definition:

LNKLST DEFINE NAME(LNKSYSA) COPYFROM(CURRENT) LNKLST ADD NAME(LNKSYSA) DSNAME(SYS1.PROD.LOADLIB) LNKLST ADD NAME(LNKSYSA) DSNAME(SYS1.TEST.LOADLIB) LNKLST ACTIVATE NAME(LNKSYSA)
LLA and VLF

Library LookAside is an address space which maintains a copy of the directories of selected libraries to improve performance By default, LLA always caches the linklist directories Virtual Lookaside Facility is another address space which caches the most popular modules which reduces fetch time VLF can also cache other data objects such as RACF tables to improve response
Libraries and members at IPL time

An number of libraries must be present for the system to load at IPL time
SYS1.PARMLIB contains the required definitions SYSn.IPLPARM searched for LOADxx SYS1.LPALIB SYS1.PROCLIB SYS1.NUCLEUS
LOADxx
LOADPARM defines the address of the IODF and the suffix of the LOADxx member At IPL the system searches for LOADxx in:
SYS0.IPLPARM SYS9.IPLPARM on IODF volume SYS1.PARMLIB on the IODF volume SYS1.PARMLIB on the IPL volume
LOADxx
The LOADxx member specifies:
The IODF data set name The master catalog name and volume The parmlib concatenation The IEASYSxx member to use
Fig 17.4 Defining a logical parmlib

Loadxx
IODF SYSCAT HWNAME LPARNAME PARMLIB PARMLIB PARMLIB 00 SYS6 MOEMVSP1 01 Y MPAT1113CATALOG.MCAT.VMPCAT1 P201 A1 SYS0.IPLPARM SYS1.OS390R7.PARMLIB SYSPROG.SYS1.PARMLIB
Parmlib concatenation
SYS0.IPLPARM SYS1.OS390R7.PARMLIB SYSPROG.SYS1.PARMLIB SYS1.PARMLIB
Search order
IEASYSxx
This is the main parameter member for z/OS IEASYS00 is used by default If essential parameters are not specified then the operator will be prompted Normally all parameters are specified to avoid inconsistent operator response
Parmlib commands
The parmlib concatenation can be displayed using D PARMLIB The parameters used at IPL can be displayed using D IPLINFO The parmlib concatenation can be modified dynamically using SETLOAD xx,PARMLIB
Fig 17.5 Commands to display parmlib
D PARMLIB
IEE251I 17.12.07 PARMLIB DISPLAY 377 PARMLIB DATA SETS SPECIFIED AT IPL ENTRY FLAGS VOLUME DATA SET 1 S TOTSY1 SYS1.SYSPROG.PARMLIB 2 D TOTSY1 SYS1.PARMLIB 3 S Z04CAT CPAC.PARMLIB 4 S Z04RE1 SYS1.IBM.PARMLIB
D IPLINFO
IEE254I 17.15.29 IPLINFO DISPLAY 379 SYSTEM IPLED AT 09.28.14 ON 07/23/2004 RELEASE z/OS 01.04.00 LICENSE = z/OS USED LOADR2 IN SYS0.IPLPARM ON 3800 ARCHLVL = 2 MTLSHARE = N IEASYM LIST = XX IEASYS LIST = (R3,04) (OP) IODF DEVICE 3800 IPL DEVICE 8038 VOLUME Z04RE1
SYS1.LPALIB
The Link Pack Area (LPA) is built at IPL time from the modules defined in the LPALSTxx member of parmlib. SYS1.LPALIB is always the first library used unless overridden by a SYSLIB statement Modules are loaded into common storage at IPL time and so are available to all address spaces
SYS1.LPALIB
Fixed LPA comprises those modules defined in IEAFIXxx that are fixed in central storage Pageable LPA comprises most other modules whose pages are eligible to be stolen Modified LPA has modules which are temporary replacements for PLPA modules and is searched first.
Example of LPALST member

File Edit Edit_Settings Menu Utilities Compilers Test Help ---------------------------------------------------------------------------------------------------------EDIT SYS1.PARMLIB(LPALST5B) - 01.01 Columns 00001 00072 Command ===>_____________________________________ Scroll ===> CSR ******** ***************************** Top of Data **************************************** 000001 SYS2.LPALIB, 000002 SYS1.LPALIB, 000003 SYS1.SERBLPA, 000004 SDF2.V1R4M0.SDGILPA, 000005 SYS1.SIATLPA, 000006 ING.SINGMOD3, 000007 NETVIEW.SCNMLPA1, 000008 REXX.V1R3M0.SEAGLPA, 000009 ISF.SISFLPA, 000010 EOY.SEOYLPA, 000011 SYS1.SBDTLPA, 000012 CEE.SCEELPA, ****** **************************** Bottom of Data ***************************************
IEAFIX member
File Edit Edit_Settings Menu Utilities Compilers Test Help ---------------------------------------------------------------------------------------------------------EDIT SYS1.PARMLIB(IEAFIX01) - 01.01 Columns 00001 00072 Command ===>_____________________________________ Scroll ===> CSR ******** ***************************** Top of Data **************************************** 000001 INCLUDE LIBRARY(SYS1.LPALIB) 000002 MODULES (IEAVAR00, /* 7K RCT INIT/TERM */ 000003 IEAVAR06, /* RCT INIT/TERM ALIAS */ 000004 IGC001G, /* 456 RESTORE(SVC17) */ 000005 ICHRFC00, /* RACF IMS/CICS */ 000006 ICHRFR00) /* RACF IMS/CICS */ 000007 INCLUDE LIBRARY(SYS1.SVCLIB) MODULES(IGC09302) *********************************** Bottom of Data ***************************************
SYS1.PROCLIB
When the system is first IPLd either the MSTJCL00 load module or MSTJCLxx in SYS1.PARMLIB is used to provide the JCL for the master scheduler This JCL at a minimum points to SYS1.PROCLIB to provide the JCL procedures for the required tasks to run the system
Sample master JCL

//MSTJCL05 JOB MSGLEVEL=(1,1),TIME=1440 //EXEC PGM=IEEMB860 //STCINRDR DD SYSOUT=(A,INTRDR) //TSOINRDR DD SYSOUT=(A,INTRDR) //IEFPDSI DD DSN=SYS1.PROCLIB,DISP=SHR //IEFPARM DD DSN=SYS1.PARMLIB,DISP=SHR //SYSUADS DD DSN=SYS1.UADS,DISP=SHR //SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR
A jobs procedure library

The JES cataloged procedure in SYS1.PARMLIB contains lists of procedure libraries to be searched for JCL procedures JCLLIB may also be used to specify a private library to be searched first
Procedure library
//PROC00 // //PROC01 ... //PROCnn ... DD DSN=SYS1.PROCLIB,DISP=SHR DD DSN=SYS3.PROD.PROCLIB,DISP=SHR DD DSN=SYS1.PROC2,DISP=SHR DD DSN=SYS1.LASTPROC,DISP=SHR
//MYJOB JOB //MYLIBS JCLLIB ORDER=(MY.PROCLIB.JCL,SECOND.PROCLIB.JCL) //S1 EXEC PROC=MYPROC1 ...
System symbols
System symbols allow the use of a shared parmlib by two or more systems Each symbol has a name which can be used in various places and then substituted at IPL time Major uses are indirect cataloging and substituting system specific datasets such as the page data sets
System symbols
SYSDEF HWNAME(SCZP801) LPARNAME(A08) SYSNAME(SC04) SYSPARM(R3,04) SYMDEF(&CPCNAME='P801') SYMDEF(&DFHSMHST='ON') SYMDEF(&SYSR2=ZXYSY2) SYMDEF(&SYSR3=&SYSR1(1:5).3)
Use of system symbols

PAGE=(PAGE.&SYSNAME..&PLPADSN1., PAGE.&SYSNAME..&COMMDSN1., PAGE.&SYSNAME..LOCAL1, PAGE.&SYSNAME..LOCAL2,L)
Summary
The role of the system programmer is to install customize and maintain the operating system and must be aware of:
z/OS operational system administration Workload management System performance Job flow I/O device management Security/integrity/availability z/OS Operation Change management
Introduction to the new mainframe: z/OS basics Chapter 17 Security on z/OS
Objectives In this chapter you will learn to:

Explain security and integrity concepts Explain RACF and its interface with the operating system Authorize a program Discuss integrity concepts Explain the importance of change control Explain the concept of risk assessment
Key terms
authorized libraries authorized program facility (APF) encryption SAF SVC PASSWORD firewall hacker page protection bit Resource Access Control Facility (RACF) security policy separation of duties system integrity user ID
Introduction
An installations data and programs are among its most valuable assets and must be protected At one time data was secure because no one knew how to access it As more people become computer literate and able to use simple tools unprotected data is becoming more accessible Data security is now more important than ever including the prevention of inadvertent destruction
Why security? Any system security must allow authorized users the access they need and prevent unauthorized access. Many companies critical data is now on computer and is easily stolen if not protected z/OS Security Server provides a framework of services to protect data
RACF
RACF (part of Security Server) and the other available packages are add-on products which provide the basic security framework on a z/OS mainframe Identify and authenticate users Authorize users to access protected resources Log and report attempted unauthorized access Control means of access to resources
Fig 19-1 RACF functions overview
Security administration
RACF RACF
RACF database
User identification and authorization
Audit and integrity reports violation alerts
Resource authorization checking and system control
Identification and verification of users RACF uses a userid and system encrypted password to perform its user identification and verification The userid identified the person to the system The password verifies the users identity Passwords should not be trivial and exits can be used to enforce policies.
Protection Levels RACF works on a hierarchical structure

ALLOC allows data set creation and destruction CONTROL allows VSAM repro WRITE allows update of data READ allows read of data NONE no access
A higher permission implies all those below
Protecting a dataset A data set profile is created and stored in the database It will give users or groups an access level A universal access level will also be set The profile can be specific or generic, with or without wild cards
RACF typical display

INFORMATION FOR DATASET SYS1.*.** (G) LEVEL OWNER ERASE ---------------00 SYS1 NO AUDITING -------FAILURES(READ) NOTIFY -------NO USER TO BE NOTIFIED YOUR ACCESS CREATION GROUP DATASET TYPE -------------------- -------------------------- --------------------ALTER SYS1 NON-VSAM
UNIVERSAL ACCESS WARNING ------------------------------ ------READ NO
RACF access list for SYS1.*.**

ID -------SYS1 KARRAS WANDRER SCHUBER KURTKR KURTKR2 KURTKR3 CICSRS1 CICSRS2 HEISIG JUSTO GERALD ACCESS ------ALTER ALTER ALTER ALTER UPDATE UPDATE NONE ALTER ALTER UPDATE UPDATE READ
Protecting general resources Many system resources can be protected

DASD volumes Tapes CICS or IMS transactions JES spool datasets System commands Application resources and many more
RACF is flexible and more can be added
Fig 19-2 Operating system and RACF

Operating System RACF Databases 1 Resource manager 2 RACF 3
SAF
5 or storage data
Fig 19-3 Concepts of RACF profile checking

.
RESOURCE MANAGER
SECURITY PRODUCT
RACROUTE
Optional exits
Exit Check
SAF CALLABLE SERVICE

.
Exit RC
S A A F F
databases
RACF call RACF Check RACF RC
Yes / no
.
System Authorization Facility SAF is part of z/OS Uses RACF if it is present Can also use an optional exit routine SAF is a system service and is a common focal point for all products providing resource control. SAF is invoked at control points within the code of the resource manager
RACF Structure Userid Group

Every userid belongs to at least one group Group structures are often used for access to resources
Resource Resource classes Class descriptor table used to customize
Fig19-4 RACF structure overview
RACF ADMINISTRATION
RESOURCE RESOURCE CLASSES CLASSES

SYSTEM OPTIONS SYSTEM OPTIONS
DATASET AND GENERAL DATASET AND GENERAL RESOURCE PROFILES RESOURCE PROFILES
GROUP GROUP PROFILES PROFILES
USER USER PROFILES PROFILES
RACF Functions
Security administration
RACF RACF
RACF database
User identification and authorization
Audit and integrity reports violation alerts
Resource authorization checking and system control
User Identification RACF identifies you when you logon Userid and password are required Each RACF userid has a unique password Password is one way encrypted so no one else can get your password not even the administrator Userid is revoked after a preset number of invalid password attempts
RACF profile checking
Protected Resource?
Yes
Valid user & group?
Yes
Access authority?
Yes
granted
No
No
No
denied (*)
denied
denied
(*) if Protect All option is in effect

Logging and reporting RACF maintains statistical information RACF writes a security log when it detects:
Unauthorized attempts to enter the system Access to resources
This depends on the settings for the resource For example AUDIT(ALL(UPDATE) will record all updates to a resource
Issuing of commands
Security Administration Interpret the security policy to:

Determine which RACF functions to use Identify the level of RACF protection Identify which data to protect Identify administrative structures and users
RACF sysplex data sharing and RRSF If many systems share a RACF database there can be contention problems RACF will propagate commands throughout a sysplex RACF can use a coupling facility in a parallel sysplex to improve performance RRSF can be used to keep distributed RACF databases in line
Authorized programs Authorized tasks running authorized programs are allowed to access sensitive system functions Unauthorized programs may only use standard functions to avoid integrity problems
Fig 19-7 Authorized Program Facility

Authorized libraries
SYS1.LINKLIB SYS1.LPALIB SYS1.SVCLIB
APF
+
List of installation defined libraries
Authorized Libraries A task is authorized when the executing program has the following characteristics:
It runs in supervisor state It runs in PSW key 0 to 7 All previous programs in the same task were APF programs The module was loaded from an APF library
Problem Programs Normal programs are known as problem programs as they run in problem state (as opposed to supervisor state) They run in the problem key 8 They may or may not be in an APF library
APF Libraries
Authorized libraries are defined by the APF list in SYS1.PARMLIB SYS1.LINKLIB, SYS1.SVCLIB and SYS1.LPALIB are automatically authorized Installation libraries are defined in PROGxx By default all libraries in the linklist are authorized but many installations set LNKAUTH=APFTAB, often prompted by auditors, so that this is no longer the case and only those in the list are authorized
Authorizing a program The first, and only the first, load module of the program must be linked with the authorization code AC=1 It and all subsequent modules must be loaded from an authorized library APF libraries must be protected so that only authorized users can store programs there
Fig 19-8 Authorizing libraries

Authorized libraries:
SYS1.LINKLIB SYS1.LPALIB SYS1.SVCLIB List of installation defined libraries
System programs usually:

reside in APF-authorized libraries execute in supervisor state use storage key 0 to through 7
APF authorized programs
Unauthorized
ibraries.
non-authorized programs
Application programs usually:

reside in non-authorized libraries execute in problem state use storage key 8
Authorizing libraries The APF list is built during IPL using those libraries listed in the PROGxx parmlib member If a dynamic list is specified then it may be updated by operator command
An example APF list

BROWSE SYS1.PARMLIB(PROGTT) - 01.01 Line 00000000 Col 001 080 Command ===> Scroll ===> PAGE *************************** Top of Data ******************************** APF FORMAT(DYNAMIC) APF ADD DSNAME(SYS1.VTAMLIB) VOLUME(******) APF ADD DSNAME(SYS1.SICELINK) VOLUME(******) APF ADD DSNAME(SYS1.LOCAL.VTAMLIB) VOLUME(TOTCAT) APF ADD DSNAME(ISP.SISPLOAD) VOLUME(*MCAT*) *************************** Bottom of Data *****************************
Dynamic APF Update a PROGxx member and then activate it with operator command SET PROG=xx Use the SETPROG APF command DISPLAY PROG,APF command will display the current list
D PROG,APF
D PROG,APF CSV450I 12.46.27 PROG,APF DISPLAY 027 FORMAT=DYNAMIC ENTRY VOLUME DSNAME 1 Z04RE1 SYS1.LINKLIB 2 Z04RE1 SYS1.SVCLIB 3 Z04RE1 ANF.SANFLOAD 4 Z04RE2 AOP.SAOPLOAD 5 Z04RE1 AOP.SAOPLOAD 6 Z04RE1 ARTURO.BFSLMOD 7 Z04RE1 ASMA.V1R2M0.SASMMOD1 8 TOTDBZ ASN.V7R1M0.SASNALNK 9 TOTDBZ ASN.V7R1M0.SASNLLNK 10 TOTDBZ ASN.V8R1M0.SASNLOAD 11 TOTPT1 ASNA.V5R1M0.SASNALNK 12 TOTPT1 ASNL.V5R1M0.SASNLLNK
Operator Console Security Consoles are assigned authority levels in CONSOLxx parmlib member Commands are grouped:
INFO informational commands SYS system control commands IO I/O commands CONS console control commands MASTER master console commands
Each console may have one or more levels
Consoles At least one console must have master authority In a sysplex consoles are shared It is possible to require logon to consoles using RACF All extended MCS consoles should require a logon
Security Roles Systems programmer sets up RACF Systems administrator implements the policies Security Manager sets the policies Separation of duties is required to prevent uncontrolled access
Summary z/OS Security Server RACF SAF Authorized Programs APF list Console security
Node D System D2
Node E
System D1
System E
RACF database
RACF database
Node C Node B System C System B System A Node A
RACF database
RACF database
RACF database
Chapter 18
Network Communications on z/OS
Objectives In this chapter, you will learn:

An overview of the communication network model layers The software components of the z/OS Communications Server product The difference between a VTAM subarea and APPN network topology How the IP network can be used to transport data between SNA applications. Commonly used TCP/IP and VTAM commands
IBM Communications Server

z/OS
Applications Applications Applications
RPC TCP/IP Sockets APPC
APPC SNA Sockets RPC
Open Systems Interconnect (OSI) network model

Layered Network Models
OSI
Applications telnet, np, SNMP, SMTP Presentation Session TCP UDP IP ARP RARP ICMP Data Link Physical Transport Network Data Link Physical
TCP/IP
SNA
Transaction Services NAU Services Mgr Func. Mgmt Data Srvc Data Flow Control Transmission Control Path Control Data Link Control Physical
TCP/IP introduction
Network A
xSeries Router
Network B
zSeries Gateway pSeries Router
zSeries
xSeries Router xSeries Gateway
Workstation
pSeries
Workstation
Workstation
Interconnecting TCP/IP networks Router

Gateway Router
Router
Bridge Gateway
Network A
INTER-NETWORK
Network B
Internet addressing
IPv4
Host B Gateway
IP Address 193.15.6.4 IP Address 131.12.8.1
Host C Network 193.15.6

IP Address 193.15.6.3
Host A Network 131.12
IP Address 131.12.8.2
131.12 network ID
8.2 host address
IP address = x.x.x.x (32 bits) = <net-ID> <host addr> Class A = <x> <x.x.x> Class B = <x.x> <x.x> Class C = <x.x.x> <x>
193.15.6 network ID
3 host address
TCP/IP commands TCP/IP Commands can be entered

TSO ready prompt ISPF Command Shell Prefixing the command with TSO on any ISPF command line.
NETSTAT PING TRACERTE NSLOOKUP TELNET FTP
z/OS UNIX shell prompt (prefix o=command)

onetstat
VTAM overview - the SNA environment

Host processor 317x Cluster controller
z/OS CICS VTAM
pSeries PC Windows AIX
zSeries iSeries zSeries
OS/400
z/VM
Communication controller (37xx)
NCP
Workstations
VTAM (SSCP) Subarea A pure VTAM subarea network Configuration

VTAM subarea (1) SSCP (PU Type 5) LU (CICSTS1) LU (IM S1) VTAM subarea (2) SSCP (PU Type 5) LU (CICSTS2) LU (IM S2)
NCP subarea (11) PU Type 4 PU Type 2
LU
New York City Los Angeles

LU LU
LU
Chicago
PU Type 2
NCP subarea (13) PU Type 4
NCP subarea (12) PU Type 4
PU Type 2 VTAM subarea (3) SSCP (PU Type 5) LU (CICSTS3) LU (IM S3)
PU Type 2
LU
LU
LU
LU
APPN topology
VTAM (CP) APPN Configuration

VTAM APPN CP (PU Type 5) LU (CICSTS1) LU (IM S1) VTAM APPN CP (PU Type 5) LU (CICSTS2) LU (IM S2)
OSA HPR/IP
OSA HPR/IP
router
Internet segment
PC
New York City Los Angeles

PC PC
PC
Internet and /or intranet
Chicago
router
internet segment
router
OSA HPR/IP VTAM APPN CP (PU Type 5) LU (CICSTS3) LU (IM S3)
Internet segment
PC
PC
PC
PC
Common VTAM commands

D NET,VTAMOPTS Displays VTAM startup options. D NET,CSM[,OWNERID=ALL] Displays communication storage usage. D NET,APPLS Displays status of defined applications (ACBs). D NET,MAJNODES Displays status of VTAM activated ATCCONxx members. D NET,TOPO,LIST=SUMMARY Displays APPN topology information. D NET,CPCP Displays status of APPN CP-CP sessions. D NET,SESSIONS Displays status of subarea SSCP-SSCP sessions. D NET,CDRMS Displays status of subarea cross domain resource managers. D NET,EXIT Displays status of VTAM exit points.
Summary In this chapter, you have learned:

An overview of the communication network model layers Software components of the z/OS Communications Server product The difference between a VTAM subarea and APPN network topology How the IP network can be used to transport data between SNA applications. Commonly used TCP/IP and VTAM commands
Backup slides
Instructor slides with additional material
SDLC / CICS

Chapter 19 Hardware systems and LPARs
Objectives In this chapter you will learn:

About S/360 and zSeries hardware design About processing units and disk hardware How mainframes differ from PC systems in data encoding About some typical hardware configurations
Introduction Here we look at the hardware in a complete system although the emphasis is on the processor box Terminology is not straightforward
Ever since boxes became multi-engined, the terms system, processor, and CPU have become muddled
Terminology:
System box from IBM possibly a zSeries machine Individual processors in the system "processors"
Sometimes referenced as a "processor"
"CPUs" "engines" "PUs" "CPs" IFLs, ICFs, zAAPs, IFLs spares
Sometimes referenced as a "CPU"
A few people use "CEC"
Many use "system"
"system" = CPs running an operating system
Conceptual S/360
Processors Storage Control Main Storage
Parallel Channels
3 Control Unit
Control Unit
3 Control Unit
Devices
2 3
X
C0 Control Unit
communication line
Channels
Another System
Early system design

System/360 was designed in the early 1960s The central processor box contains the processors, memory, control circuits and channel interfaces
Early systems had up to 16 channels whereas modern systems have over 1000
Channels connect to control units Control units connect to devices such as disk drives, tape drives and communication interfaces
Device address
address: 1 3 2
channel number
contr ol unit number
device number
In the early design the device address was physically related to the hardware architecture Parallel channels had large diameter heavy copper bus and tag cables
Current design Current CEC designs are considerably more complex then the early S/360 design This new complexity includes
I/O connectivity I/O operation Partitioning of the system
I/O Connectivity
CEC box Partition 1 Partition 2
I/O Processing
Channels (CHPIDs or PCHIDs)
01
O
02
E
...
40
E
41
E
42
E
...
Other systems
...
A0
F
A1
F
...
...
LAN
01 Control Unit
ESCON Director (switch)
FICON switch
Control unit addresses (CUA)
C0 Control Unit
C1 Control Unit
01 Control Unit
02 Control Unit
Unit addresses (UA)
E - ESC ON channel F - FICON channel O - OSA-Express channel

I/O Connectivity ESCON and FICON channels Switches to connect peripheral devices to more than one CEC CHPID addresses are two hex digits Multiple partitions can share CHPIDs I/O subsystem layer exists between the operating system and the CHPIDs
I/O Connectivity I/O control layer uses a control file IOCDS that translates physical I/O addresses into devices numbers that are used by z/OS Device numbers are assigned by the system programmer when creating the IODF and IOCDS and are arbitrary (but not random!) On modern machines they are three or four hex digits
I/O Connectivity
External device label Four hex digits in range 0000-FFFF Arbitrarily assigned by sysprog Used in JCL, commands, messages, EREP
FF00 6830 6831 6832 6833 683F
HSA LPAR B Central Storage LPAR A Central Storage UCB 2001 UCB 2000 UCB 183F
FF03 C40 FF02
2000 2001 2002 FF01 2003 2004 2005 2006 2007
2008 2009 200A 200B 200C 200D 200E 200F
V 200A,ONLINE IEE302I 200A ONLINE
V 200B,ONLINE
System Control and Partitioning

Specialized microprocessors for internal control functions
Memory
LPAR1
LPAR2
LPAR3
System Control
HMC
SE
CP
CP
CP
CP
Processors
PC
Think Pads
System Control
Located in operator area
Located inside CEC but can be used by operators
Channels CHPID CHPID CHPID CHPID CHPID
CHPID
CHPID
System Control and Partitioning Among the system control function is the ability to partition the system into logical partitions (LPARs) Initial limit was 15 LPARs but newer machines allow 30 partitions Practical considerations can limit the number to less than this as each LPAR needs memory, I/O, and processing power
LPARs
System administrators assign:
Memory Processors CHPIDs either dedicated or shared
This is done partly in the IOCDS and partly in a system profile on the Support Element (SE) in the CEC. This is normally updated through the HMC. Changing the system profile and IOCDS will usually require a power-on reset (POR) but some changes are dynamic
Characteristics of LPARs
LPARs are the equivalent of a separate mainframe for most practical purposes Each LPAR runs its own operating system Devices can be shared across several LPARs Processors can be dedicated or shared When shared each LPAR is assigned a number of logical processors (up to the maximum number of physical processors) and a weighting Each LPAR is independent
Consolidation of mainframes Many installations used to have several boxes A single larger machines running many LPARs is often more cost effective, as software licenses for multiple small machines can total more than those for a single large one
Processing Units
Modern processor offer many specialist processor types. Most of the additional types are not counted as full processors for software charging
Central Processor (CP) - A full z/OS processor System Assistance Processor (SAP) - Used for the I/O subsystem each machine has at least one Integrated Facility for Linux (IFL) - Special processor for Linux - optional zAAP - Used for JAVA code optional Integrated Coupling Facility (ICF) - For coupling facilities Spares
SAPs, IFLs, ICFs, and zAAPs are not counted in the model number and or against software costs
Capacity on Demand Various forms of Capacity on Demand exist Additional processing power to meet unexpected growth or sudden demand peaks
Disk Devices
IBM 3390 Disk Unit
channels
IBM 3990 Control Unit
Current mainframes use 3390 disk devices The original configuration was simple with a controller connected to the processor and strings of devices attached to the back end
Current 3390 Implementation

Host Adapters (2 channel interfaces per adapter)
HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA
Common Interconnect (across clusters)
Cluster Processor Complex
Cluster Processor Complex
cache
NVS DA
cache
NVS DA
DA
DA
DA
DA
DA
DA
RAID array RAID array
Device Adapters
Modern 3390 devices The 2105 Enterprise Storage Server just shown is very sophisticated It emulates a large number of control units and 3390 disks. It can also be partitioned and connect to UNIX and other systems as SCSI devices. There are 11 TB of disk space up to 32 channel interfaces, 16GB cache and 284MB of non-volatile memory
Modern 3390 Devices The physical disks are commodity SCSI- type units Many configurations are possible but usually it is RAID-5 arrays with hot spares Almost every part has a fallback or spare and the control units are emulated by 4 RISC processors in two complexes.
Modern 3390 Devices The 2105 offers FlashCopy, Extended Remote Copy, Concurrent Copy, Parallel Access Volumes, Multiple Allegiance This is a huge extension of the original 3390 architecture and offers a massive performance boost. To the z/OS operating system these disks just appear as traditional 3390 devices so maintaining backward compatibility
EBCDIC
The IBM S/360 through to the latest zSeries machines use the Extended Binary Coded Decimal Interchange character set for most purposes This was developed before ASCII and is also an 8 bit character set z/OS Web Server stores ASCII data as most browsers run on PCs which expect ASCII data UNICODE is used for JAVA on the latest machines
Clustering Clustering has been done for many years in several forms
Basic shared DASD CTC/GRS rings Basic and Parallel sysplex
Image is used to describe a single z/OS system, which might be standalone or an LPAR on a large box
Basic shared DASD

zSeries ( or LPAR) zSeries ( or LPAR)
z/OS
channels channels
z/OS
Real system would have many more control units and devices control unit control unit
Limited capability Reserve and release against a whole disk Limits access to that disk for the duration of the update
CTC Ring
zSeries ( or LPAR)
zSeries ( or LPAR)
z/OS
channels CTC channels
z/OS
CTC
control unit
control unit
Can have more systems in the CTC"ring"
Global Resource Sharing (GRS) used to pass information between systems via the CTC ring Request ENQueue on a data set, update, the DEQueue Loosely coupled system
Parallel Sysplex
zSeries ( or LPAR)
system or LPAR Coupling Facility
CF channels zSeries ( or LPAR)
z/OS
channels channels
z/OS
control unit
control unit
This extension of the CTC ring uses a dedicated Coupling Facility to store ENQ data for GRS This is much faster The CF can also be used to share application data such as DB2 tables Can appear as a single system
Typical Systems
Standard mainframe control units and devices Selected mainframe control units and devices printer ESCON channels MP3000 System Parallel channels FLEX-ES System printer
SUPPORT element
LAN adapter(s)
LAN adapter(s)
tn3270 terminals
tn3270 terminals
This shows two very small systems

On the left is a Multiprise 3000, which was designed for small installations with internal disk drives On the right is a FLEX-ES emulation system, which runs on a PC running Linux or UNIX
Medium Mainframe Configuration

Enterprise Storage Server1
Printer
Printer
z890
OSA-Express Tape drives Router
LAN
Consoles
This is a completely modern implementation with no older devices A z890 is featured with two external disk controllers, tape drives, printers, LAN attachments and consoles
Medium Single System This system could be running several LPARs

A production z/OS with interactive applications A second production LPAR devoted to batch A test z/OS LPAR for testing new software One or more LPARs running Linux, perhaps running web applications
Moderately Large Configuration

CF
Consoles
OSA Express
LAN
z990
OSA Express
9672 R96
OSA Express OSA Express
LAN LAN
LAN
Escon Director
Escon Director
3490E
Older DASD device 3390
Two machines a new z990 and an older 9672 Parallel Sysplex with coupling facility Multiple ESS and older DASD connected via a switch 3745 communications controllers for an SNA network 3490E tape drives retained for compatibility OSA Express connections to various LANs Consoles
Larger system
This is the sort of mixture of device generations that might be found in any enterprise New devices are brought in but older ones are still viable until they reach the end of their life z/OS will usually run on older devices until an architectural change forces their withdrawal This sort of change is usually well publicized and several years notice is given of any incompatibility which will usually coincide with the machine being at end of life
Summary Terminology is important The classic S/360 design is important as all later designs have enhanced it. The concepts are still relevant New processor types are now available to reduce software costs EBCDIC character set Clustering techniques and parallel sysplex
FSP Support Element
Bulk Power Unit
FSP
Bulk Power Unit
DCA = power + control interface
Ethernet
Support Element FSP HMC DCA DCA DCA DCA DCA DCA DCA DCA FSP FSP FSP FSP FSP FSP FSP
MCM
MCM
...
Connections for up to 28 channel adapter cards
Connections for up to 28 channel adapter cards
Memory
Memory
System frame "Box"
Processor Book 0
Processor Book 1
I/O Cage 2
I/O Cage 3
Introduction to the new mainframe: z/OS basics Chapter 20 Parallel Sysplex
Objectives In this chapter you will learn:

How Parallel Sysplex can achieve continuous availability Dynamic workload balancing Single system image
Sysplex Hardware Overview

IBM zSeries
CF01 ICF
IBM zSeries z/OS
IBM zSeries
Sysplex LPARs
z/OS Sysplex Timer
11 12 1 10 9 8 7 6 5 2 3 4 10 9 8 7 6 5 11 12 1 2 3 4
Sysplex LPARs
CF01 ICF
ESCON / FICON
DASD
DASD
DASD
Sysplex Overview A sysplex is a collection of z/OS systems that cooperate, using certain hardware and software products, to process work Improved growth potential Improved level of availability
What is a parallel sysplex? Innovative multi-system data-sharing technology Direct concurrent read/write access to shared data from all processing nodes No loss of data integrity No performance hit Transactions and queries can be distributed for parallel execution based on available capacity and not restricted to a single node
What is parallel sysplex? (continued) Builds on the strength of zSeries servers by linking up to 32 images to create the industrys most powerful commercial processing clustered system Every cloned application can run on every image Hardware and software can be maintained nondisruptively
Continuous availability Within a parallel sysplex cluster, it is possible to construct an environment with no single point of failure Peer instances can of a failing subsystem can take over recovery responsibility for resources held by the failing instance Alternatively the failing subsystem can be automatically restarted on still healthy systems
Continuous availability In a parallel sysplex it is possible that the loss of a server may be transparent to the application and the server workload redistributed automatically with little performance degradation Each system is still individual Software upgrades can be rolled through one system at a time on a sensible timescale for the business
Capacity The parallel sysplex can scale near linearly from 2 to 32 systems. It can be a mix of any servers that support parallel sysplex
Dynamic workload balancing The entire parallel sysplex cluster can be regarded as a single logical resource to end users and business applications Work can be dynamically distributed to nodes with available capacity Workload balancing also allows running of diverse applications while maintaining response times critical to the business
Ease of use z/OS Workload Manager

Sysplex-wide workload management to one policy
Sysplex Failure Manager

Specify failure detection and recovery actions
Automatic Restart Manager

Fast recovery of critical subsystems
Cloning and symbolics

Used to replicate applications across the nodes
zSeries Parallel Sysplex Resource Sharing This is not to be confused with application data sharing This is sharing of physical system resources such as tape drives, catalogs, consoles This exploitation is built into z/OS Simplifies the management of the system
Single System Image The sysplex should appear as a single image to operator, end user, database administrator and others Single point of control Persistent single image across failures
Applications in a Parallel Sysplex Design goal of no application changes Benefits

Scalability Integration of older applications with new workloads such as web serving With an existing sysplex there is very little infrastructure work required for a new application. The existing infrastructure may even be used without the need for a new server
GDPS A geographically dispersed parallel sysplex is the ultimate disaster recovery and continuous availability solution for a multi-site enterprise Two sites up to 100 fiber kilometers apart may be connected for synchronous updates Asynchronous techniques may be used over this distance
Summary Reduce cost compared to previous offerings of comparable function and performance Continuous availability even during change Dynamic addition and change Parallel sysplex builds on the strengths of the z/OS platform to bring even greater availability serviceability and reliability
Additional materials The following foils contain additional material to demonstrate points about parallel sysplex if one is not available
Parallel sysplex display status
Display of a 16 image sysplex Each image has reported active with the last 5 seconds
D IPLINFO
This shows the first screen of response to D IPLINFO in a sysplex Note that systems have been IPLd at different times and are running different releases of z/OS
D WLM
This shows the display for two of the systems in the sysplex Note they are running the same policy activated at exactly the same time by another system SC53
D XCF,PATHIN
This display shows the connections to the other systems in the sysplex are by both CTC devices and via structures in the coupling facility If the CF were to have a problem then the sysplex would continue with the CTC connections
D XCF,STRUCTURE
This shows a subset of the output from the command to illustrate some points The IXC structures are the ones used by XCF, the main sysplex component The SYSZWLM structures are used by workload manager
Note there is one structure for each physical machine There are two machines: a 2064 (z900) and a 2084 (z990)
D M=CPU
This shows the output from the command with the processor type, serial number and number of logical processors assigned
DC
This shows the console display for a system SC04 in a sysplex Note that the only console is attached to SC47

IBM Introducción A Mainframe

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

IBM Introducción A Mainframe

Hochgeladen von

Copyright:

Verfügbare Formate

Introduction to the new mainframe: z/OS basics Chapter 1: The new mainframe

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Key terms in this chapter

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

MVT, PCP MFT SW

Linux CICS VM DB2 WebSphere z/VM

Introduction to the new mainframe

Mainframes in our midst

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Introduction to the new mainframe

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Typical mainframe workloads

Process data to perform a particular task Output Data

Online (real time) transaction

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Typical batch use

1234 9012 1234 5678 9012

XX/XX/XX XX/XX/XX XX/XX/XX PAUL FISCHER PAUL FISCHER

Account balances bills, etc

Partners and clients exchange information

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Typical online use

SNA or TCP/IP network

Branch office automation systems

queries and updates

Central office Business analysts Inventory control Disk storage controller

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Roles in the mainframe world

Operator End User

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe: z/OS basics Chapter 2: z/OS Overview

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Key terms in this chapter

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Hardware resources managed by z/OS

z/OS running here...

Master Console (z/OS) Operator Console (z/OS)

... Director links mainframes with DASD controllers

Tape drive DASD Tape cartridges

Copyright IBM Corp., 2005. All rights reserved.

Introduction to the new mainframe

Overview of z/OS internals