1. Chapter 4a: z/OS Overview
Slide Animation

2. Chapter 4a objectives
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.

3. Key terms in this chapter
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

4. What is z/OS? The most widely used mainframe operating system
64-bit operating system (tri-modal addressing)
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
The operating system we discuss in this course is z/OS, the most widely used of all
mainframe operating systems. z/OS is designed to offer a stable, secure, and
continuously available environment for applications running on the mainframe.
To understand how and why z/OS functions as it does, it is important to understand the
environment in which it functions. The special features that make z/OS unique reflect the
computer environments that z/OS manages.
z/OS gets work done by dividing it into pieces and giving portions of the job to various system
components and subsystems that function interdependently. At any point in time, one
component or another gets control of the processor, makes its contribution, and then
passes control along to a user program or another component.

5. Hardware resources managed by z/OS
Mainframe hardware consists of processors and a multitude of peripheral devices such as
disk drives (called direct access storage devices or DASD), magnetic tape drives, and
various types of user consoles. Tape and DASD are used for system
functions and by user programs executed by z/OS.
Not shown here, for example, are the hardware control units, such as the director, which connect the
mainframe to the other tape drives, DASD devices, and consoles.

6. The Virtual Partitioning Environment
z/OS runs as one of many Operating Systems on the mainframe
Different versions of z/OS can run in different LPARs as separate runtime
environments or servers
The System Programmer uses the Hardware Management Console (HMC) to
elect which operating system is configured into each logical partition
Each Logical Partition is managed by the hypervisor called
Processor Resource Systems Manager (PR/SM) *
PR / SM
Logical
Partition
z/OS

7. Hypervisor Partitioning allows for different runtime environments
Each LPAR contains a configuration of processors, storage and I/O
Each LPAR can run a different OS and version level
Each LPAR is assigned a processor weight
zVM
v4.2
z/OS
V1.7
V1.6
V1.8
VSE
V3.1 L I N U X
V3.2
V1.5
v4.4
***
15 – 60 LPARs
Hypervisor
Processor Resource / System Manager
Re-inforce

8. Dedicated – Shared Logical CPs
Processor Resource / System Manager cp cp cp cp cp cp cp cp cp cp cp cp cp cp cp cp cp cp cp cp cp cp cp
VSE
V3.2
VSE
V3.2 L I N U X L I N U X
zVM
v4.2
z/OS
V1.8 L I N U X
zVM
v4.4
z/OS
V1.9
VSE
V3.1
z/OS
V1.6
z/OS
V1.8
***
z/OS
V1.7
z/OS
V16 cp
= Dedicated cp
= Shared (pooled)

9. Application Modules, System Programs (Macros), System Components
Source
Code
Source
Code
Source
Code
Source
Code
Runtime
System
LOAD
Modules
Source
Code
Application
LOAD
Modules
Source
Code

10. z/OS internal concepts and components
Comprised of modules, system programs (macros), system components
Management of physical storage:
Real storage
Auxiliary storage
Virtual storage
Techniques of multiprogramming and multiprocessing
Information about the system, resources, and tasks is contained in control blocks
Use of the program status word (PSW)
A group of related instructions is called a routine or module. A set of related modules that
make a particular possible is called a system component.
Sequences of instructions that perform frequently used system functions can be invoked
with executable macro instructions, or macros. z/OS macros exist for functions such as
opening and closing data files, loading and deleting programs, and sending messages to
the computer operator.
The program status word (PSW) is a 64-bit data area in the processor that, along with
control registers, timing registers, and prefix registers, provides details crucial to both the
hardware and the software. The current PSW includes the address of the next program
instruction and control information about the program that is running. Each processor has
only one current PSW. Thus, only one task can execute on a processor at a time.
z/OS is capable of multiprogramming, or executing many programs concurrently, on
behalf of many users at once. In multiprogramming, when a job cannot use the processor,
the system can suspend, or interrupt, the job, freeing the processor to work on another
job. z/OS can also perform multiprocessing, which is the simultaneous operation of two or
more processors that share the various hardware resources, such as memory and external
disk storage devices.
As instructions execute the work of a computer system, they keep track of this work in
storage areas known as control blocks. Generally speaking, there are three types of z/OS
control blocks:
System-related control blocks
Resource-related control blocks
Task-related control blocks
Each system-related control block represents one z/OS system and contains system-wide
information, such as how many processors are in use. Each resource-related control block
represents one resource, such as a processor or storage device. Each task-related control
block represents one unit of work.
Conceptually, mainframes and all other computers have two types of physical storage.
The physical storage located with the mainframe processor itself. This is called
processor storage or real storage; think of it as memory for the mainframe.
The physical storage external to the mainframe, including storage on direct access
devices, such as disk drives and tape drives. This storage is called auxiliary storage.

11. Physical storage concepts and usage
Virtual storage is divided into 4-kilobyte (1-mb) pages
Frames, pages, slots are all repositories for a page of information
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
Dynamic address translation (DAT)
z/OS uses tables to keep track of pages
Use of Storage Protection

12. Physical storage management
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)
Virtual storage means that each running program can assume it has access to all of the
real storage defined by the architecture’s addressing scheme. The only limit is the
number of bits in a storage address.
To allow each user to act as though this much storage really exists in the computer
system, z/OS keeps only the active portions of each program in real storage. z/OS keeps
the rest of the code and data in special files on auxiliary storage, which usually consists
of a number of high-speed direct access storage devices (DASDs).
An address space is the area of contiguous virtual
addresses available for executing instructions and storing data. The range of virtual
addresses in an address space starts at zero and can extend to the highest address
permitted by the operating system architecture.
z/OS provides each user with a unique address space and maintains the distinction
between the programs and data belonging to each address space.

13. Pages, Frames and Slots = 4K Address

14. 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.

15. 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.
“Working set” is the number of active pages in an application. The inactive pages have been paged out, leaving the active pages in memory. The number of applications that can fit comfortably in a system concurrently is a function of the working set of each.
When an entire application is moved to auxiliary storage, it is “swapped out”. This means that all of the pages (including the working set) are moved to a separate swap data set. When resources are freed up, the application is brought back into memory.

16. Transferring addresses to and from auxiliary storage
Transferring frames
in and out of Central Storage
Central
Storage
Paging
Packs
Swap
Packs
The paging and swapping controllers of the auxiliary storage manager attempt to maximize I/O efficiency by incorporating a set of algorithms to distribute the I/O load as evenly as is
practical. In addition, every effort is made to keep the system operable in situations where a
shortage of a specific type of page space exists.
In ESA390 architecture, RSM uses expanded storage as an extension of central storage.
When a page is to be removed from central storage, RSM first considers moving it to
expanded storage instead of auxiliary storage. When a page that is needed is not in central
storage, RSM first checks expanded storage for the page. If the page is in expanded storage,
RSM synchronously retrieves the page. If the page is not in expanded storage, RSM calls
ASM to schedule asynchronously the paging I/O to retrieve the page from auxiliary storage.
When contention for expanded storage increases, the system removes pages from expanded
storage to free expanded storage frames. RSM first moves the pages from expanded storage
to central storage. RSM then calls ASM to schedule the paging I/O necessary to send these
pages to auxiliary storage. This process is called migration. Migration completes when the
pages are actually sent to auxiliary storage.
RSM is responsible for reclaiming the central storage allocated to an address space when the
address space is to be swapped out of central storage. RSM is also responsible for building
the control structures necessary to efficiently swap the address space back into central
storage.
TRANSFERRING PAGES
IN AND OUT OF CENTRAL STORAGE
ONE
PAGE
AT A TIME
(PAGING)
A SET
OF PAGES (
Central Storage Control This parameter, specified by the MCCAFCTH keyword, indicates the number of frames on the available frame queue when stealing begins and ends. The range of values on this keyword determines the block size that SRM uses for stealing. In order to get a block into central storage, the lower value of the range must be greater than the block size. 4K
One page
at a time
(paging)
A set of
pages at
a time
(swapping)

17. How processes and virtual storage works
An address is an identifier of a required piece of information, but not a description of
where in real storage that piece of information is. This allows the size of an address
space (that is, all addresses available to a program) to exceed the amount of real
storage available.
All real storage references are made in terms of virtual storage addresses.
A hardware mechanism is used to map the virtual storage address to a physical
location in real storage. As shown on the slide, the virtual address can
exist more than once, because each virtual address maps to a different address in real
storage.
When a requested address is not in real storage, a hardware interruption is signaled to
z/OS and the operating system brings the required instructions and data into real

18. z/OS architecture address sizes (Tri-modal addressing)
An address size refers to the maximum number of significant bits that can
represent an address.
With z/OS Architecture, three sizes of addresses are provided:
- 24-bit A 24-bit address can accommodate a maximum of 16,777,216 (16M) bytes.
- 31-bit With a 31-bit address, 2,147,483,648 (2 G) bytes can be addressed.
- 64-bit With a 64-bit address, 8,446,744,073,709,551,616 (16 E) bytes can be addressed.
64 – bit addressing places us in the exabyte address range
(An exabyte is slightly more than one billion gigabytes)
128 x the
previous
addressing
range of 24 bit
8 Billion x the
previous
addressing
range of 31 bit

19. The Address Space Concepts - Architecture
An Address Space provides a unique expansion through virtualization
Pgm A
Pgm B
Pgm C
Extend Horizontally
Program Call
Authorized
Memory
Data Spaces
2GB
(Data In Virtual –DIV)
Extend Vertically

20. The address space concept
Each address space, called a 64-bit address space, is 16 exabytes (EB) in size; an exabyte is slightly more than one billion gigabytes. The new address space has logically 264 addresses. The number is 16 with 18 zeros after it: 16,000,000,000,000,000,000 bytes, or 16 EB (see the slide).
The potential size is 16 exabytes because z/OS, by default, continues to create address spaces with a size of 2 GB. The address space exceeds this limit only if a program running in it allocates virtual storage above the 2 GB address. If so, the z/OS operating system increases the storage available to the user from 2 GB to 16 EB.
The 16 MB address became the dividing point between the two previous architectures (24-bit addressability introduced with MVS/370 and the 31-bit addressing introduced in the operating system MVS Extended Architecture or MVS/XA), and is commonly called the line. The area that separates the virtual storage area below the 2 GB address from the user private area is called the bar.
With the release of zSeries mainframes in 2000, IBM extended the addressability
of the architecture to 64 bits. With 64-bit addressing, the potential size of a z/OS address
space expands to a size so vast that we need new terms to describe it. Each address space,
called a 64-bit address space, is 16 exabytes (EB) in size; an exabyte is slightly more than
one billion gigabytes. The new address space has logically 264 addresses. It is 8 billion
times the size of the former 2 GB address space. The number is 16 with 18 zeros after it:
16,000,000,000,000,000,000 bytes, or 16 EB (see the slide).
We say that the potential size is 16 exabytes because z/OS, by default, continues to create
address spaces with a size of 2 GB. The address space exceeds this limit only if a
program running in it allocates virtual storage above the 2 GB address. If so, the z/OS
operating system increases the storage available to the user from 2 GB to 16 EB.
The 16 MB address became the dividing point between the two previous architectures (the 24-bit addressability
introduced with MVS/370 and the 31-bit addressing introduced in the operating system MVS Extended
Architecture or MVS/XA), and is commonly called the line. The area that separates the virtual storage area below the 2 GB address from the user private area is called the bar.

21. Horizontal Scaling using Data Spaces
Programs can use data spaces and hiperspaces to:
Obtain more virtual storage than a single address space gives a user.
Isolate data from other tasks in the address space. Data in an address space is accessible to all programs executing in that address space. You might want to move some data to a Data Space for security restricting access to data in those spaces to certain units of work
Share data among programs that are executing in the same address space or different address spaces.
- Use this space as a way to separate your
data logically by its own use.
Provide an area in which to map a
data-in-virtual (DIV) object.
Pgm A
Pgm B
Pgm C
Memory
Data Spaces
2GB
(Data In Virtual –DIV)

22. Cross Memory is an evolution of Virtual Storage
Dual address space or cross-memory (XM) is an evolution of virtual storage having three objectives:
Move data synchronously between virtual addresses located in distinct address spaces.
2. Pass the control synchronously between instructions located in distinct address spaces.
3. Execute one instruction located in one address space and its operands are located in other address space.
Pgm A
Pgm B
Pgm C
Memory
Data Spaces
2GB
(Data In Virtual –DIV)

23. What’s in an address space?
z/OS provides each user with a unique runtime container 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.
OS Code
Application
Code
Temp
Work Areas
System
Meta
Data
Virtual Storage
components
composing an
address space
Address Space
Control Block
(ASCB) =

24. Address Space Concepts – Common Storage
The z/OS design is a Share-Everything Architecture
Each Address Space uses Common Storage to share code, data and objects
The runtime size of a user address space is controlled by JCL or System Routines
Application
Code
Private
Extended
Common Storage
16 MB
Line
2 GB
BAR
* Full Function Address Spaces *
PSA
Runtime
Container
Meta
Data
System
Code
Address
Space
Temporary
Work Areas
Application
Code
OS Code

25. Address Space Concepts
Pin Objects
in Memory
USER
DATA
ONLY
2**31 – 2**32
PSW – (Program Status Word)
Starts at
4 GB

26. Address Space Data Transfer using Bits-Bytes
4096 bytes / 8bits
512 = bytes
z/OS LPAR
sign digit
Packaging of
byte transfer
= C6
4K-byte
BLOCK
16EB
8-bits (1 byte) = word
A byte is one of the basic integral data types in some programming languages, especially system programming languages.
In computer science a byte (pronounced "bite", IPA: /baɪt/) is a unit of measurement of information storage, most often consisting of eight bits. In many computer architectures it is a unit of memory addressing.
Originally, a byte was a small group of bits of a size convenient for data such as a single character from a Western character set. Its size was generally determined by the number of possible characters in the supported character set and was chosen to be a submultiple of the computer's word size; historically, bytes have ranged from five to twelve bits. The popularity of IBM's System/360 architecture starting in the 1960s and the explosion of microcomputers based on 8-bit microprocessors in the 1980s has made eight bits by far the most common size for a byte. The term octet is widely used as a more precise synonym where ambiguity is undesirable (for example, in protocol definitions).
64-bit word (8 bytes)

27. Address Space Concept – Module Location

28. Address Space Concepts – RMODE/AMODE

29. Processes and Tasks Two types of processes
- Task Control Block (TCB) used as an access token* to track units of work
- Service Request Block (SRB) used as an access token to track
system services
NOTE: These have a dispatch hierarchy
Global SRBs (inter address space) first
Local SRBs (intra address space) second
TCBs (intra address space) third
Process States
- ACTIVE, when its program is executing on a CP
- READY, when being delayed due to CP availability
- WAIT, when delayed by any reason other than a CP
Process Attributes
- State
- Resources
- Priority
- Accounting
- Addressing
- Security
* In z/OS an address space is represented by a control block (ASCB)

30. Levels of Tasks in a Job Step
All of the tasks in the job step compete independently for processor time
Tasks are performed and terminated asynchronously
There is communication between tasks under the same job step
Subtask termination begins with the lowest task and works upward
Job
Task
TASK A
TASK B
TASK A1
TASK A2
TASK B1
TASK
B1a
TASK
A2a

31. Program Status Word and Addressing Mode
Program execution is tracked by a CPU using a Program Status Word (PSW)
The PSW will note which addressing scheme is used in bits 31-32
Programs execute in the first 2GBs of an address space in 24 bit or 31 bit mode
Above the 2GB boundary is known as the “BAR” used for data only, no code.
PSW
AMODE 24 = 00
AMODE 31 = 10
AMODE 64 = 11
127
16EB
(8 Billion x larger
than 2GB)
Address Space
“The BAR”
64-Bit
ADDRESSES
(128 x larger
than 16MBs)
“The LINE”
2GB
Common Storage
straddles the 16 MB LINE
and is used by all
address spaces
31-BIT
ADDRESSES
24-bit
ADDRESSES
V = R
Only 24-bit

32. Storage Protection Access Control (KKKK) – 4 bits
Fetch bit (F), controlled by z/OS to create READ protection
Reference bit ®, ON if the FRAME was read or altered by CP/Channel
Change bit ©, ON if the FRAME was altered by CP or Channel
PSW KEY Central Storage
Key 1 8
Frame
Frame
Frame
Frame
Frame 7 8 … 2
Frame
Frame
Frame
Frame
Frame
Frame
Frame
Storage
K K K K F R C …

33. z/OS address space types
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
- Batch Job address spaces that runs on z/OS.

34. Multi-Programming/Processing: Terminology
Commit and Roll back
Multiprocessing
Multiprogramming
Multitasking
Thread
Reentrancy
Coordinator
Participant
Resource Recovery Services
PGM CP
Memory
Resources
Single copy
of App Pgm
“””” “”
“”” “””
“”” “””
“”” “””
Program
Enter
Exit
TRX

35. (MRO - Multi Region Operation)
Address Space
Implementation
(Region)
Examples
CICS
IMS
Controller
Region
Message
Processing
(MPP)
Region 1
Database
Recovery
(DBRC)
Lock
Mgr.
Terminal
Owning
Region 1
Application
Owning
Region 3
TOR
Application
Owning
Region 2
File
Owning
Region
Terminal
Owning
Region 2
FOR
Application
Owning
Region 1
AOR
L P A R
(MRO - Multi Region Operation)
Controller
Region
(CR)
Servant
Region 3
Region 2
Region 1
(SR)
Daemon
Deploym’t
Agent
Manager
WAS
DB2
Lock Mgr.
Services
Distrib.
Database
Stored
Procedures
System

36. Running Multiple Instances of Products across z/OS Servers
LPAR “A” LPAR “B” LPAR “C” S Y P L E X
“A” – “B”
“B” – “C”
Controller
Region
(CR)
Servant
Region 3
Region 2
Daemon DM
Agent
Manager
WAS 1
Region 1
(SR)
WAS 2
WAS #n
DB2 1
Lock Mgr.
Services
Distrib.
Database
Stored
Procedures
System
DB2 2
DB2 #n
CICS 2 T O R
AOR
FOR
CICS 1
CICS #n

37. Running Multiple Mixed Instances of Products across z/OS Servers
LPAR “A” LPAR “B” LPAR “C”
CICS 2 T O R
AOR
FOR
Controller
Region
(CR)
Servant
Region 2
Daemon DM
Agent
Manager
WAS 1
Region 1
(SR)
DB2 2
Lock Mgr.
Services
Distrib.
Database
Stored
Procedures
System
Region 3
Controller
Region
(CR)
Servant
Region 3
Region 2
Daemon DM
Agent
Manager
WAS #n
Region 1
(SR)
CICS #n T O R
AOR
FOR
Lock Mgr.
Services
DB2 1
Distrib.
Database
Stored
Procedures
System
Stored
Procedures
Services
CICS 1 T O R
AOR
FOR
Daemon
Region
Controller
(CR)
Servant
Region 3
Region 2 DM
Agent
Manager
WAS 2
Region 1
(SR)
DB2 #n
Lock Mgr.
Distrib.
Database
System
Integration
Test
Production
Development

38. Service Level Agreement
WLM - Basics
SLA
SLA
End Users
z/OS
The idea of z/OS Workload Manager is to create a
contract between the users of the applications and
the z/OS Operating System
Service Level Agreement
Starting point for workload control process !
SIE

39. Why z/OS Workload Management (WLM)
The design of z/OS implements a share everything architecture
z/OS runs heterogeneous workloads competing for the same resources
Each workload type requires different levels of services
Workloads are integrated with many different subsystems
On-Demand Computing requires immediate resource availability
Many products and subsystems offer different tuning externals
Provides workload distribution and routing among multiples LPARs
It’s a problem solver providing dynamic and automatic on-going tuning ?
WHY 8

40. a workload having equivalent performance characteristics
WLM - A Service Class
A service class is used to describe a group of work within
a workload having equivalent performance characteristics
containing similar resource service demand.
Batch
File
Updating
Service
Classes
Reporting
Online
Processing
Data
Mining
IMS
NOTE there are three system-provided Service Classes automatically defined in a WLM policy:
SYSTEM: Used as the default Service Class for certain system address spaces. It doesn’t have a
goal and it is assigned fixed DP=255 .
SYSSTC: The default Service Class for system tasks and privileged address spaces. It doesn’t have
a goal and it is assigned fixed DP=254 .
SYSOTHER: As default Service Class for non-STC address spaces when no classification rules
exists for the subsystem type. It is assigned a discretionary goal.
DP = Dispatch Priority

41. Workload Management Concepts
OnLine Processing
Data Base
Processing
Batch File
Updating
Service levels
are maintained
SYSPLEX
Batch Reporting
Introduction, with some policies at the bottom. This is also the prime shift chart. He’ll add a graphic for prime shift for lower right hand corner.
Data
Mining
Transaction type:
Web "buy" vs "browse"
B2B
Batch payroll
Test
User/user type:
Top 100 clients
Typical clients
Executive
Design team
Time periods:
8AM – 5PM
Mon - Fri
Weekends
End of quarter
illustration
Policy
Based
08:00
through
17:00

42. Workload Management Concepts
OnLine Processing
Data Base
Processing
Batch File
Updating
Service levels
are maintained
SYSPLEX
Batch Reporting
Data
Mining
illustration
Policy
Based
17:01
through
23:59

43. Workload Management Concepts
OnLine Processing
OnLine
Shutdown
Data Base
Processing
Batch File
Updating
Service levels
are maintained
SYSPLEX
Batch Reporting
Data
Mining
illustration
Policy
Based
00:00
Through
07:59

44. IRD - LPAR CPU Weight Management
More
Workload
Demand !
LPAR Cluster pu pu pu pu pu pu pu
No operator intervention
Websphere
(SOA)
Traditional
OLTP
Batch
Move resources to
where workload is …
50 weight
20 weight
30 weight
70 Weight
20 Weight
10 Weight
LPAR 3
LPAR 2
LPAR 1
Intelligent Resource Director
Processor Resource / System Manager (PR/SM)
System z10
Linux can participate if non-IFL

45. IRD - Dynamic Channel Management
Example
SOA Disk
OLTP Disk
Director/Switch
IRD modifies channel
distribution to meet
changing workload
Channel Subsystem pu pu pu pu pu pu pu pu pu pu
Websphere
(SOA)
Traditional
OLTP
Batch
Weight
= 50
Weight
= 20
Weight
= 30
= 10
= 70
= 20
LPAR 3
LPAR 2
LPAR 1
Intelligent Resource Director
Processor Resource / System Manager (PR/SM)
System z9
Workload
Workload

46. IRD – Channel System Priority Queuing
I/O Priority Queuing prioritizes
- I/O within an LPAR
- Channel Subsystem Priority
- Queuing prioritizes I/O within an
LPAR cluster
Allows better channel resource management
- High priority work is given
preferential access to the channel
- Can reduce channel requirements
- Managed within System z server
LPAR Cluster
High
Priority
WKL
Med.
Priority
WKL
Low
Priority
WKL
This feature works with the special
engine native to the mainframe called
the System Assist Processor (SAP)
- SAP uses Work Queues for prioritizing
Disk
Directing Resources
through Priority

47. 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
We won’t attempt to list all of the z/OS program products in this course (hundreds exist);
some common choices include:
A security system
z/OS provides a framework for customers to add security through the addition of a
security management product (IBM’s program product is Resource Access Control
Facility or RACF®). Non-IBM security system program products are also available.
Compilers
z/OS includes an assembler and a C compiler. Other compilers, such as the COBOL
compiler, are offered as separate products.
A relational database, such as DB2
Other types of database products, such as hierarchical databases, are also available.
Transaction processing facilities
IBM offers several, including:
– Customer Information Control System (CICS)
– Information Management System (IMS)
– WebSphere
A sort program
Fast, efficient sorting of large amounts of data is highly desirable in batch processing.
IBM and other vendors offer sophisticated sorting products.
A large variety of utility programs
For example, the System Display and Search Facility (SDSF) program that we use
extensively in this course to view output from batch jobs is a program product. Not
every installation purchases SDSF; alternative products available.
A large number of other products are available from various independent software
vendors (commonly called ISVs in the industry).

48. 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
As commonly used, the term usually applies to major software products such as database
managers, transaction monitors, Web servers, and so forth.
Typical z/OS middleware includes:
Database systems
Web servers
Message queuing and routing functions
Transaction managers
Java virtual machines
XML processing functions
A middleware product often includes an application programming interface (API). In
some cases, applications are written completely to this middleware API, while in other
cases it is used only for unique purposes. Some examples of mainframe middleware APIs
include:
The WebSphere suite of products, which provides a complete API that is portable
across multiple operating systems. Among these, WebSphere MQ provides
cross-platform APIs and inter-platform messaging.
The DB2 database management product, which provides an API (expressed in the
SQL language) that is used with many different languages and applications.

49. 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.
The use of address spaces in z/OS holds many advantages: Isolation of private areas
in different address spaces provides for system security, yet each address space also
provides a common area that is accessible to every address space.
The system is designed to preserve data integrity, regardless of how large the user
population might be. z/OS prevents users from accessing or changing any objects on
the system, including user data, except by the system-provided interfaces that enforce
authority rules.
The system is designed to manage a large number of concurrent batch jobs, with no
need for the customer to externally manage workload balancing or integrity problems
that might otherwise occur due to simultaneous and conflicting use of a given set of
data.
The security design extends to system functions as well as simple files. Security can
be incorporated into applications, resources, and user profiles.
The system allows multiple communications subsystems at the same time, permitting
unusual flexibility in running disparate communications-oriented applications (with
mixtures of test, production, and fall-back versions of each) at the same time. For
example, multiple TCP/IP stacks can be operational at the same time, each with
different IP addresses and serving different applications.
The system provides extensive software recovery levels, making unplanned system
restarts very rare in a production environment. System interfaces allow application
programs to provide their own layers of recovery. These interfaces are seldom used
by simple applications—they are normally used by more sophisticated applications.
The system is designed to routinely manage very disparate workloads, with automatic
balancing of resources to meet production requirements established by the system
administrator.
The system is designed to routinely manage large I/O configurations that might
extend to thousands of disk drives, multiple automated tape libraries, many large
printers, large networks of terminals, and so forth.
The system is controlled from one or more operator terminals, or from application
programming interfaces (APIs) that allow automation of routine operator functions.
The operator interface is a critical function of z/OS. It provides status information,
messages for exception situations, control of job flow, hardware device control, and
allows the operator to manage unusual recovery situations.

50. 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.
An operating system is a collection of programs that manage the internal workings of a
computer system. The operating system taught in this course is z/OS, the most widely
used mainframe operating system.
The z/OS operating system’s use of multiprogramming and multiprocessing, and its
ability to access and manage enormous amounts of storage and I/O operations, makes it
ideally suited for running mainframe workloads.
The concept of virtual storage is central to z/OS. Virtual storage is an illusion created by
the architecture, in that the system seems to have more storage than it really has. Virtual
storage is created through the use of tables to map virtual storage pages to pages in real
storage or slots in auxiliary storage. Only those portions of a program that are needed are
actually loaded into real storage. z/OS keeps the inactive pieces of address spaces in
auxiliary storage.
z/OS is structured around address spaces, which are ranges of addresses in virtual
storage. Each user of z/OS gets an address space containing the same range of storage
addresses. The use of address spaces in z/OS allows for isolation of private areas in
different address spaces for system security, yet also allows for inter-address space
sharing of programs and data through a common area accessible to every address space.
Programs running on z/OS and zSeries mainframes can run with 24-, 31-, or 64-bit
addressing (and can switch among these if needed). Programs can use a mixture of
instructions with 24-bit, 64-bit, or 32-bit operands, and can switch among these if
needed.
Mainframe operating systems seldom provide complete operational environments. They
depend on program products for middleware and other functions. Many vendors,
including IBM, provide middleware and various utility products.
Middleware is a relatively recent term that can embody several concepts at the same
time. A common characteristic of middleware is that it provides a programming
interface, and applications are written (or partially written) to this interface.