IBM Global Services - Training Center - Hortolândia: Mainframe: Concepts

IBM Global Services – Training Center - Hortolândia
Mainframe: Concepts
© Copyright IBM Corp., 2005. All rights reserved.
1
Índice
Páginas Conteúdo
001 .......... Mainframe: Concepts

010 .......... Mainframe: Hardware Systems and Logical Partitions
028 .......... Mainframe: z/VM Concepts
051 .......... Mainframe: z/OS Concepts
075 .......... Mainframe: NETVIEW
106 .......... Mainframe: TSO and ISPF
122 .......... Mainframe: JCL and SDSF
153 .......... Mainframe: Working with Datasets
171 .......... Mainframe: TWS Concepts
2
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.
Today, computer manufacturers don’t always use the

term mainframe to refer to mainframes. Instead, most have taken to calling any
commercial-use computer—large or small—a server, with the mainframe simply
being
the largest type of server in use today. IBM, for example, now refers to its
mainframes as
zSeries servers. We use the term mainframe in this textbook to refer to computers
that
can support dozens of applications and input/output devices to simultaneously
serve
thousands of users.
The presence of a mainframe often implies a centralized form of computing, rather

than a
distributed form of computing. Having data centralized in a single mainframe
repository
saves customers from having to manage updates to more than one copy of their
business
data, and increases the likelihood that the data is current.
3
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
4
Typical mainframe workloads

Application Program
Process data to
Batch job Input perform a
Data particular task
Output Data
Application Program
Query
Access shared
data on behalf of
Reply online user
Online (real time) transaction
A batch job is submitted on the computer,

reads and processes data in bulk, and produces output. A batch job can last for hours.
While batch processing is possible on distributed systems, it is not as commonplace as on

mainframes because distributed systems often lack:
• Sufficient data storage
• Available processor capacity or cycles
• Sysplex-wide management of system resources and job scheduling.
Mainframes serve a vast number of online transaction processing (OLTP) systems.

These are often mission-critical applications that businesses depend on for their core
functions. Some industry uses of online systems:
• Banks – ATMs, teller systems for customer service
• Insurance – Agent systems for policy management and claims processing
• Travel and transport – Airline reservation systems
• Manufacturing – Inventory control, production scheduling
• Government – Tax processing, license issuance and management.
5
Typical batch use

Residence Branch offices
CREDIT CARD Main
Account balances office
1234 5678 9012
VALID FROM
XX/XX/XX
GOOD THRU
XX/XX/XX
PAUL FISCHER
bills, etc
PAUL
5
6 Reports
Processing
reports 7
Statistics,
4 summaries,
exceptions
8 Mainframe
Partners Processing batch jobs
and clients
exchange Reports
information 2
1 Reports
Backups
3
Data
update Tape Storage
10 Sequential
9 data sets
Disk Storage
Production System databases
Control Operator
Consider the following elements at work in the scheduled batch process:

1. At night, many batch jobs executing programs and utilities are processed. These
jobs
consolidate the results of the online transactions executed during the day.
2. The batch jobs generate reports of business statistics.
3. Backups of critical files and databases are made before and after the batch
window.
4. Reports with business statistics are sent to a specific area for analysis during the
following day.
5. Reports with exceptions are sent to the branch offices.
6. Monthly account balance reports are generated and sent to all bank customers.
7. Reports with processing summary are sent to the partner credit card company.
8. A credit card transaction report is received from the partner company.
9. In the production control department, the operations area is monitoring the
messages
on the system console and the execution of the jobs.
10. Jobs and transactions are reading or updating the database (the same
database used by
online transactions) and many files are written to tape.
6
Typical online use

ATMs
Account
activities
SNA or TCP/IP 4
1 network
Requests
Branch office
Branch automation
offices systems
2 Mainframe
3 Accesses
database
Office
automation 5
systems
queries 6
and
updates
Central office
Business analysts Inventory control
Disk
storage
controller
Stores
database
files
Common online transactions using a mainframe:
1. A customer uses an ATM, which presents a user-friendly interface for various

functions: Withdrawal, query account balance, deposit, transfer, or cash advance
from
a credit card account.
2. Elsewhere in the same private network, a bank employee in a branch office
performs
operations such as consulting, fund applications, and money ordering.
3. At the bank’s central office, business analysts tune transactions for improved
performance. Other staff use specialized online systems for office automation to
perform customer relationship management, budget planning, and stock control.
4. All requests directed to the mainframe computer for processing.
5. Programs running on the mainframe computer perform updates and inquires to
the
database management system (for example, DB2).
6. Specialized disk storage systems store the database files.
7
Roles in the mainframe world
Roles
Application Production Control Analyst

Developer
Operator
End User
System Programmer System Administrator
System administrators perform more of the day-to-day tasks

related to maintaining the critical business data that resides on the mainframe, while the
system programmer focuses on maintaining the system itself.
Examples of system administrators include database administrators and
security administrators.
While system programmer expertise lies mainly in the mainframe hardware and software
areas, system administrators are more likely to have experience with the applications.
The application designer and application programmer (or developer) design, build, test,
and deliver mainframe applications for the company’s end users and customers. Based on
requirements gathered from business analysts and end users, the designer creates a design
specification from which the programmer constructs an application. The process includes
many iterations of code changes and compiles, application builds, and unit testing.
The system operator monitors and controls the operation of the mainframe hardware and
software. The operator starts and stops system tasks, monitors the system consoles for
unusual conditions, and works with the system programming and production control staff
to ensure the health and normal operation of the systems.
The production control analyst is responsible for ensuring that batch workloads run to
completion--without error or delay.
Customer Engineers perform the mainframe installation and maintenance
8
Mainframe operating systems

z/VM
z/OS
VSE
Linux for zSeries
z/TPF
z/Virtual Machine (z/VM) has two basic components: A control program (CP) and a
single-user operating system, CMS.
As a control program, z/VM is a hypervisor because it runs other operating systems in the
virtual machines it creates. The control program artificially creates multiple virtual
machines from the real hardware resources. To the user it appears as if they have
dedicated use of the shared real resources. The shared real resources include printers,
disk storage devices, and the CPU. The control program ensures data and application
security among the virtual machines, which are called guest systems. The real hardware
can be shared among the guests, or dedicated to a single guest for performance reasons.
The second major component of z/VM is CMS or Conversational Monitor System. This
component of z/VM runs in a virtual machine and provides both an interactive end-user
interface and the general z/VM application programming interface.
Compared to z/OS, the VSE operating system provides a smaller, less complex base for
batch processing and transaction processing. The design and management structure of
VSE is excellent for running routine production workloads consisting of multiple batch
jobs (running in parallel) and extensive, traditional transaction processing.
Several Linux distributions can be used on a mainframe. These distributions are not from
IBM but their use is supported by IBM.
The z/Transaction Processing Facility (z/TPF) operating system is a special purpose

system used by companies that require very high volume transactions, such as credit card
companies and airline reservation systems. z/TPF was once known as Airline Control
Program and was used for airline reservation systems. It is still used for this purpose and
has been extended for other very large reservation systems and similar high-volume
transaction processing requirements.
9
Summary
The Mainframe:
Plays a central role in the daily operations of the world’s

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.
10
Mainframe: Hardware systems and logical partitions
11
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
12
CPU: 9672
Processadores dos anos 90’s.
Modelo #proc Mips

9672-R11 1 14,8
9672-ZZ7 12 1644,0
13
CPU: 2094
Processadores dos anos 2000
Modelo #proc Mips

2064-1C1 1 250
2094-S54 54 17801
14
DASD: 2105 ESS – Enterprise Storage Server (SHARK)
• Tecnologia multi-plataforma (Mainframe, UNIX, As/400, Windows)

• Capacidade: acima de 50Tb
15
TAPES: 3490, 3590 and VTS (Virtual Tape Server)
3490 e 3480: montagem manual

3592: Unidades com capacidade acima de 300Gb. Montagem através de robot.
VTS: Unidades que emulam montagem de cartucho.
16
PRINTER
Impressão a laser super rápida
17
DATA CENTER
Os equipamentos são distribuídos nos Data Centers e colocados sôbre pisos

falsos.
A ligação entre êles é feito através de cabeamentos (fibras óticas) e estes são
passados sob o piso.
18
Mainframe Basic Installation
Mainframe Dasd Tape VTS
Tape drive
As ligações entre os equipamentos periféricos (Dasd, Tapes, etc) são feitas entre
as Control Units de cada equipamento e os canais
(channels) do box.
Cada periférico deve ser conectado à mais de um canal para haver caminhos
alternativos em caso de quebra e também para uma
melhor performance.
19
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
LPAR – Logical Partition

Ao invés de um único sistema instalado em um box de mainframe (single image),
divide-se em Partições Lógicas.
20
HMC – Hardware Management Console
Accessed by an IP addr
HMC is the tool used to define how each LPAR will work on
one box (Images)
Memory, #Logical Processors and Weight (priority) are the
main characteristics of each LPAR
HMC functions:
POR – Power On Reset
IPL – Initial Program Load
Change Profiles
Operating Systems Commands
O HMC é instalado no SE (Support Element) pelo CE (Customer Engineer).

As definições das LPARs são feitas pelo Capacity Planning Group juntamente com
o Support Group (MVS e/ou VM)
21
HMC – Hardware Management Console
Através de acesso à rede IBM, um IP Address, um ID e PASSWORD no HMC, a

Operação poderá acessar qualquer box de Mainframe
em qualquer instalação.
22
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
LPARs are, in practice, equivalent to separate mainframes. Each LPAR runs its own
operating system. This can be any mainframe operating system; there is no need to run
z/OS, for example, in each LPAR. The installation planners may elect to share I/O
devices across several LPARs, but this is a local decision.
The system administrator can assign one or more system processors for the exclusive use
of an LPAR. Alternately, the administrator can allow all processors to be used on some or
all LPARs. Here, the system control functions (often known as microcode or firmware)
provide a dispatcher to share the processors among the selected LPARs. The
administrator can specify a maximum number of concurrent processors executing in each
LPAR. The administrator can also provide weightings for different LPARs; for example,
specifying that LPAR1 should receive twice as much processor time as LPAR2.
The operating system in each LPAR is IPLed separately, has its own copy3 of its
operating system, has its own operator console (if needed), and so forth. If the system in
one LPAR crashes, there is no effect on the other LPARs.
23
I/O Connectivity
CEC box
Partition 1 Partition 2
I/O Processing
Channels
(CHPIDs or PCHIDs)
01 02 ... 40 41 42 ... ... A0 A1 ... ...
O E E E E F F
Other
systems
01
Control ESCON
LAN Unit FICON
Director
switch
(switch)
C0 C1 01 02
Control unit addresses Control Control Control Control
(CUA) Unit Unit Unit Unit
Unit addresses (UA) 0 1

0 1 0 1 0 1
E - ESC ON channel
F - FICON channel
O - OSA-Express channel
This slide illustrates a recent configuration. (A real system would have

more channels and I/O devices, but this figure illustrates key concepts.) Partitions,
ESCON channels, and FICON channels are described later.
Briefly, partitions create separate logical machines in the CEC. ESCON and FICON
channels are logically similar to parallel channels but they use fiber connections and
operate much faster. A modern system might have 100-200 channels or CHPIDs.
24
Disk Devices
IBM 3390 Disk Unit
IBM 3990
channels
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
IBM 3390 disk drives are commonly used on current mainframes. Conceptually, this
is a
simple arrangement, as shown on this slide.
The associated control unit (3990) typically has four channels connected to one or
more
processors (probably with a switch), and the 3390 unit typically has eight or more
disk
drives. Each disk drive has the characteristics explained earlier. This illustration
shows
3990 and 3390 units, and it also represents the concept or architecture of current
devices.
25
Medium Mainframe Configuration E n te r p r is e

S to r a g e S e r v e r 1
P r in te r
P r in te r
z890
O S A -E x p re s s
Ta p e R o u te r
d r iv e s
LA N
E n t e r p r is e
S to ra g e S e rv e r1
C o n s o le s
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
This slide shows a modest mainframe system and the typical

external elements needed. The particular system shown is an IBM z890 system
with two
recent external disk controllers, a number of tape drives, printers, LAN attachments,
and
consoles.
This is a somewhat idealized configuration in that no older devices are involved.
26
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
27
Moderately Large
Configuration
CF
Consoles
•Two machines – a new z990 and an
older 9672
OSA Express
LAN z990 9672

•Parallel Sysplex with coupling R96 OSA Express
facility LAN
OSA Express OSA Express
LAN
LAN
•Multiple ESS and older DASD
connected via a switch
•3745 communications controllers Escon Escon

Director Director
for an SNA network
•3490E tape drives retained for

compatibility
•OSA Express connections to

various LANs 3490E Enterprise Enterprise Older DASD
Storage Server1 Storage Server1 device 3390
•Consoles
This slide shows a larger mainframe, although this is still a modest configuration
when compared to a large mainframe installation. This example is typical in that
both
older and newer mainframes are present, along with channel switches allowing all
systems to access most I/O devices. Likewise, new and older disk controllers (and
devices) and tape controllers (and devices) are present. The total system is in a
modest
Parallel Sysplex configuration.
28
Mainframe: z/VM Concepts
29
What is z/VM?
An operating system (VM = virtual machine)
A hypervisor, which refers to a system that
virtualizes the real hardware environment
Runs on the zSeries architecture created by IBM
z/VM is an operating system that runs on the zSeries mainframe

servers. It is unique compared to other operating systems since it is a hypervisor.
This term refers to a system that virtualizes the real hardware environment. A
hypervisor operating system differs from a typical supervisor operating system in
that a hypervisor has the ability to present virtual images (or copies) of hardware
that reflect the underlying system architecture, while a supervisor is an operating
system that has complete control and usage of the underlying hardware. The
“guest” operating system created on the z/VM operating system uses virtualized
hardware as if it were real. Each operating system believes it has all the resources
of the host computer at its disposal, when in fact z/VM makes virtual guest systems
to fit the needs of each and every user.
30
z/VM as an Operating System

Running an operating system in a virtual machine should be the
same as running an operating system on a real processor
Storage, processors, and I/O devices should behave in the same

way on a virtual machine as on a real one
z/VM’s user interface is its Control Program (CP) commands
Performance and flexibility are optimized with z/VM and its

virtualization technology. When you use a virtual machine to run an operating
system, you still communicate with that operating system using the CP commands.
The Hypervisor uses two consoles to create user-interactive displays. The first is
the logon console, which displays the fields for signing in. The second is the
operator console, which communicates with the CP. In response to your
commands, the operating system performs the same functions it would if it were
running on a real processor. Storage, processors, and I/O devices also respond in
the same way.
Control Program (CP) is the collection of software modules that make up the core
(nucleus) of z/VM.
31
General z/VM Environment
This shows the general z/VM environment from its real hardware to its
different guest operating systems. On the first level operating system you see z/VM
and the CP commands in the z/VM field. In this example z/VM is the first level
operating system, which contains many second level operating systems. Virtual
Storage Extended (VSE) is an operating system that runs in 31-bit mode on the
zSeries architecture, while z/VM uses both 31-bit and 64-bit modes. The
Conversational Monitor System (CMS) is an operating system running under VM; it
provides timesharing and program development facilities (comparable in function to
TSO but less resource-hungry and generally friendlier). OS/390 is the operating
system on the S/390 architecture. Since z/VM has the capabilities of both S/390
and the new z/Architecture it can run both OS/390 and newer systems such as
z/VM. z/OS is another operating system that runs on zSeries that uses 31-bit and
64-bit mainframe architecture, much like z/VM.
At Marist College, z/VM is used to manage the z/900 (2064-101)
processor. This machine currently has three CPUs (processor chips), and 12GB of
memory (RAM). z/VM 4.4.0 is currently running on the machine with many
secondary guest systems. Among these guest operating systems there are three
OS/390 systems, 20 z/Linux systems providing production services for Foxmail,
IceCast (rebroadcasts the college radio station via the web), event calendars,
Marist College Library web site, etc. Over 500 z/Linux systems are used for classes
such as Web Programming I and II, and E-commerce, for example. z/VM-based
services consist of IMAP (Internet Message Access Protocol), LISTSERV (a List
Server that allows its users to manage email lists on their corporate networks or on
the internet), TSM (Tivoli Storage Manager, which protects and manages a broad
range of data), and many others.
32
What are Virtual Machines?

z/VM uses real resources to create virtual machines that
include processors, memory, I/O devices, and networks
Virtual machines run as if a guest system was running on the
real hardware
Virtualization Technology creates an illusion that z/VM uses
to virtualize hardware components
VM allows users to run multiple copies and different types
of operating systems on the same mainframe system
The virtualization technology found in z/VM is unique because it

allows a guest to have a full functioning system without having complete control of
the hardware resources. This allows z/VM’s virtualization technology to share its
limited resources with as many guests as needed. z/VM uses the real resources at
its disposal (processors, memory, I/O devices, and networks) to create virtual
machines, each able to run its own, independent copy of any operating system that
supports the zSeries architecture (which includes Linux). An operating system
running in a virtual machine does so as if it were executing on real hardware.
Hardware architecture and facilities are presented to the “guest” system by z/VM in
such a way that the guest operating system believes it is using a real system, not a
virtual one. This is an illusion that the virtual machines possess. Therefore,
virtualization technology creates an illusion that z/VM uses to virtualize hardware
components.
VM (virtual machines) enable users to run multiple copies of any
operating system and different types of operating systems. This makes it possible
to migrate (upgrade) to newer releases and versions of software on the same
mainframe system. A user could run a production workload on the old level of
software, while at the same time performing the work required to migrate the
environment to the new operating system. This makes it possible to migrate to
newer versions of a software product without affecting the production system.
Over the last 30 years VM has continually increased in performance,
scalability, and flexibility. VM has continued to increase in these ways because it is
an extra layer of code that is between the hardware and operating systems. When
we improve this layer we improve the entire system of hardware, virtualized
hardware, and software. Every improved version of VM is capable of running
previous versions of VM, all due to its virtualization capabilities.
33
Creating System Level
A first level z/VM is the base operating system that is installed on top
of the real hardware. A second level operating system is a system that is created
upon the base z/VM operating system. Therefore z/VM as a base operating system
runs on the hardware, while a guest operating systems runs on the virtualization
technology. In other words, there is a first level z/VM operating system that sits
directly on the hardware, but the guests of this first level z/VM system are
virtualized. By virtualizing the hardware from the guests we are able to create and
use as many guests as needed with a small amount of hardware.
An example of the functionality of z/VM is if you have a first level z/VM
system and a second level z/VM system, you could continue to create more
operating systems on the second level system. This is not very practical but it is
possible.
34
Introducing z/VM’s Base Components
Conversational Monitor System (CMS)

• An end-user interface for running user programs
Control Program (CP)
• A component that manages the resources of a single system to
make it appear that multiple computing systems exist
REXX/VM
• A programming language that allows you to write customized
application programs and command procedures
Group Control System (GCS)
APPC/VM VTAM Support (AVS)
Dump Viewing Facility
When we speak of z/VM’s base components, we are referring to the different types of environments that
z/VM supports. This slide and the next are here to give you a feel of the types of environments z/VM is capable of using and
will help you understand topics and terms that are presented in the next few modules.
The Conversational Monitor System provides a high-capacity environment that supports large numbers of
interactive users. The Conversional Monitor System (CMS) is a component of z/VM. “Interactive” means supporting two-
way communication between a user and the CMS environment. Although CMS could be called an operating system in itself,
CMS performs two roles within z/VM. First, as an end-user interface, it is part of z/VM that is most often seen by users.
Second, it is the part of the operating system that supports the running of your programs, thus, it is your interface to
application programming languages and facilities.
The Control Program (CP) is primarily a real-machine resource manager. The CP provides each user with
an individual working environment known as a virtual machine. Each virtual machine is a functional equivalent of a real
system, sharing the real processor function, storage, console, and input/output (I/O) device resources. CP is the component
that manages the resources of a single computer so that multiple computing systems appear to exist.
REXX/VM includes the REXX/VM Interpreter, which processes the English-like Restructured EXtended
eXecutor (REXX) programming language. Using REXX, you can write customized application programs and command
procedures. This procedural language allows programs and algorithms to be written in a clear and structured way. REXX
programming has the capability of issuing both commands and conventional inter-language calls to its host environment.
The Group Control System is a virtual machine supervisor, providing multitasking services that allow
numerous tasks to remain active in the virtual machine at one time. A virtual machine supervisor bands many virtual
machines together in a group and supervises their operations. GCS runs in a real XA machine and is installed with z/VM.
This allows all virtual machines in a GCS group to run in XA or XC mode. GCS can not be built or run in a 370-mode
virtual machine.
XA mode means running with the full capabilities of the Extended System Architecture (ESA). Either 24-
bit or 31-bit addressing can be used, as well as the more efficient XA I/O using the Channel Subsystem.
ESA/XC virtual machine architecture is available only when VM/ESA is running on an ESA/390
processor. ESA/XC architecture lets virtual machines share multiple data spaces or address spaces, where an XC virtual
machine can access one or more data spaces of another virtual machine if authorized to do so. 370 mode is a simulation of
the 370 architecture under the Extended System Architecture machine. For migration purposes GCS supports mixed mode
groups that include XC and XA mode (but not 370 mode).
35
What is CMS?
Conversational Monitor System is an operating system
environment itself
Over time CMS became a part of VM
CMS is a single user operating system, which makes it
possible to:
• Create and maintain files
• Write and execute application programs
CMS communicates with users through the console
Unlike Windows 2000, where you can set up multiple users for a single
operating system, such as Admin, User1 and Home, CMS is a single user operating system.
This makes it possible for users to create and update files and to write and execute
application programs. An important aspect of the CMS is that it is the operator or
communicator of your z/VM environment. It executes commands given by users and
displays information from the z/VM environment to the user console.
The console can be considered two separate entities. When you run an
operating system in a virtual machine, you are the virtual machine operator. You operate the
virtual machine and the operating system in your virtual machine. Your virtual machine
operator’s console is the display device at which you log on to z/VM. (Your virtual machine
operator’s console can also be referred to as a virtual console, an operator’s console, or just
a console. All of these terms refer to the display device at which you log on to z/VM.) By
entering commands from your virtual machine operator’s console, you can communicate
with CP and with the operating system executing in your virtual machine. To communicate
with CP, enter CP commands. To communicate with the operating system running in your
virtual machine, enter the commands of that operating system (for z/VM, that would be CMS
commands).
As a side note, many installations have two consoles for the virtual machine
operator: a virtual machine console to communicate with CP, and a system console to
communicate with the operating system running in the virtual machine (CMS). Your virtual
machine operator’s console refers to the console you use to communicate with CP.
36
CMS Tasks
With CMS, you can:
Write, test, and debug application programs for use on CMS or
guest systems
Run application programs developed on CMS or guest systems
Create and edit data files
Process jobs in batch mode
Share data between CMS and guest systems
Communicate with other system users
These are the important operations and tasks that CMS is able to
execute. CMS writes, tests, and debugs application programs for use on CMS or a
guest system. CMS runs application programs developed on CMS or guest
systems, creates and edits data files, processes jobs in batch mode, shares data
between CMS and guest systems, and communicates with other systems users.
In batch mode, all data must be supplied beforehand and cannot be
interacted with while the program is executing. Running applications in batch mode
is very reliable and efficient. All data is saved in a file, so data cannot accidentally
be deleted or lost. Batch mode is efficient because it waits to accumulate a
sufficient amount of data to utilize the system processors, I/O devices, and other
networking devices. Therefore, batch mode is an important way of running and
completing CMS tasks.
37
z/VM Help Facility

CMS Help Facility provide assistance for:
• Tasks
• Commands and options
• Subcommands
• REXX statements
• Callable routines
• Pipeline stages
• Assembler language macros
• Messages
The z/MV Help Facility runs under CMS and provides online
assistance for various z/VM functions in the form of menus. The CMS Help Facility
provides information for tasks, commands and options, subcommands, REXX
Statements, callable routines, Pipeline stages, Assembler language macros, and
Messages. Other licensed programs may come with additional help topics. It is
also possible for you to write your own help files. An important thing to remember is
that you can access the z/VM Help Facility at anytime. All you need to do is type
“HELP operand”, where the operand is a command you are having trouble with or
the type of command you are looking for. To arrive at the main help menu, you
would just need to enter “HELP HELP”.
38
Control Program (CP)

It provides each user with an individual working virtual machine
environment
Every virtual machine is a functional equivalent of a real system,
sharing:
• Processor functions
• Storage
• Console
• I/O device resources
It provides connectivity support to exchange information and
access resources
The CP provides each user with an individual working environment

known as a virtual machine. Each virtual machine is the functional equivalent of a
real system, sharing the real processor function, storage, console, and I/O device
resources. As a virtual machine operator, you operate the virtual machine and
other operating systems in your virtual machine. Your virtual machine operator’s
console is the console you use to communicate with CP. By entering commands
from your virtual machine operator’s console, you can communicate with the CP
and with the operating system executing in your virtual machine. To communicate
with CP, enter CP commands. To communicate with the operating system running
in your virtual machine, enter the commands of that operating system.
When you first log on to z/VM, CP controls the working environment.
Many of the facilities of z/VM are immediately available to you. For example, you
can use CP commands to do various system management tasks. However, most
of the work done for z/VM requires the CMS component or a guest operating
system, such as z/OS, to help with data processing tasks and to manage workflow.
CP provides connectivity support that allows application programs to
exchange information with each other and to access resources residing in the same
VM system or on different VM systems.
39
Using CP Commands
z/VM uses the CP command language to configure, tune
and manipulate resources
• To control the resources of the real machine
• Processors
• I/O devices
• Networking devices
• To control your virtual machine’s configuration and
environment
z/VM uses the control program (CP) command language to

manipulate, use and configure its environment. You would use the control program
(CP) command language when you have a z/VM system and you want to control
the resources of the real machine located in your computer room. The CP
command language is also used when you are a virtual machine user and you want
to control your virtual machine’s configuration and environment. The CP
commands can be used to control the setup process of networking and tuning your
environment for z/VM processes and to install another operating system under
z/VM. Examples of these commands are located later in this module and in the
module “Advanced CP Commands and Structures”.
40
CP Control Tools: VM Dump Tool
The VM Dump Tool assists in analyzing dump data from a dump file created by the
DUMPLOAD utility. The VM Dump Tool provides a variety of subcommands and macros that
allow you to display, locate, and format dump data interactively. This tool can process CP stand-
alone dumps, CP ABEND dumps, and virtual machine dumps of a CP system. In z/VM, dumps
can be initiated by the hardware, software, or the user. Overall, the VM Dump Tool provides
detailed information after an error has occurred in a application or task.
A CP stand-alone dump occurs if the CP is unable to take an abend dump. You can
also initiate a stand-alone dump with the stand-alone dump utility. This stand-alone dump should
give you enough information for troubleshooting problems.
A CP ABEND dump (also called CP dump) must allocate enough spool or TEMP
space on the system to contain the whole system. The system operator can produce a system
abend dump by performing a Program Status Word (PSW) RESTART. The PSW contains the
address of the next instruction to be executed and, when an application or system software error
occurs, why it happened and other status information, which is all stored within the dump file.
The CP system abend dump should give you enough information to resolve most CP problems.
Use the Dump Viewing Facility to format a z/VM dump for the easiest problem resolution.
A virtual machine dump has no clear performance benefits because the amount of
paged out data on the system that was dumped is minimal and much more variable than the real
storage configuration. Virtual dumping time is primarily constrained by the amount of paged out
data and the page data set service times to read in the data, and not the size of the dump output
data set.
41
Privilege Class
Revisited
The above diagram displays the Privilege Class specifications

associated with the special commands describe within this next section.
Special commands are commands that control the system resources.
In order to balance control and workflow, each privilege class is assigned a type of
user and function to block inexperienced or guest users from altering the system. In
other words, it hinders a general user (G) from changing the system configurations,
which can hurt the systems overall performance or even crash the system.
Therefore, only a class A user (skilled and trained system operator) can change the
options to the system configuration. Hence, special commands are available to
different users according to there privilege class classification to ensure reliability
and integrity.
42
Logon em máquina CMS e estados de tela

Logon
• Quando um usuário se loga no VM é criada uma máquina CMS,
conforme as caracterísitcas armazenadas no profile para esse
usuário.
• Algumas máquinas de serviço o usuário se loga como “como” seu
userid, mas a máquina não é dele.
• Caso a máquina esteja sendo utilizada por outro usuário ( na
verdade ele mesmo ) ele pode se logar e a outra máquina sera
derrubada.
• No caso de colocar uma máquina em serviço o comando é
XAUTOLOG
Estados de tela representam como o VM irá se comportar
em caso do usuário entrar com comandos
Logon
L userid, onde userid é o nome da sua máquina virtual
Há algumas máquinas virtuais que podem ser compartilhadas entre um

grupo de usuários, como as máquinas de serviço. Estas máquinas são
logadas da seguinte forma:
L maint by userid , onde maint é o userid de uma máquina virtual de

serviço e userid é o nome da sua máquina virtual.
Para qualquer uma destas formas será solicitada a password na forma descrita a
seguir:
Enter your password, or To change your password, enter:

ccc/nnn/nnn
OBS: Agregando-se a palavra here ao userid, é possível "capturar" uma máquina

virtual caso ela esteja conectada em uma seção em outro terminal.
Para ativar uma máquina de serviço, à qual deverá executar sua função em modo
desconctado utiliza-se o comando
XAUTOLOG “nome da máquina”
43
Estados de tela
Estados de tela representam como o VM irá se
comportar em caso do usuário entrar com comandos
Estados de tela
CP READ - Indica que o Programa de Controle esta aguardando uma linha de informações.
Alternativas para retornar ao status normal: Digitar um comando CP; digitar o comando begin (b)
ou digitar (i cms) para reiniciar a sua máquina virtual.
MORE... - Indica que há mais informações para serem exibidas na tela. As informações
normalmente ficam retidas durante um minuto. Caso neste intervalo ela não seja limpa pelo usuário,
o sistema mudará automaticamente para a próxima tela. Caso se deseje retê-la, basta teclar enter
e a área de status passará para holding.
RUNNING - Status normal de uma tela de uma máquina virtual.
HOLDING - Idem ao MORE, com exceção de que só passará para a tela seguinte se o
usuário pressionar a tecla para limpá-la com a tecla clear (Pause/Break no PC).
VM READ - Indica que seu terminal está aguardando uma linha de informações. Para retornar ao
status running dê um enter.
44
Desativando uma máquina CMS

Para desativar a máquina no qual se está logado basta
utilizar o comando LOGOFF.
Para deslogar e deixar a máquina ativa o comando é
DISConnect
No caso de ser necessário desativar uma outra máquina o

comando é
FORCE ‘ID’ sendo ID o nome da máquina CMS
45
Sistema de arquivos na máqina CMS

Cada máquina CMS guarda o conjunto de arquivos,
criados na própria máquina, por programa ou edição
(XEDIT).
Outras máquinas poderão acessar esses arquivos desde
que o proprietário desta máquina o permita.
OBS: Para acessar arquivos que estão em minidiscos utiliza-se a exec FILELIST,
teclando FL.
Um arquivo CMS é identificado por três componentes: fn ft fm (filename, filetype,

filemode), onde:
filename (fn) - Pode ter ate 8 caracteres e é o nome do arquivo dado pelo usuário.
filetype (ft) - É uma identificação dada pelo usuário e que especifica uma
característica do arquivo (por exemplo: Se é texto então especificar txt como
filetype). Também pode ter até 8 caracteres.
filemode (fm) - Descreve o disco onde está o arquivo. O fm é composto de

uma letra e um número. O número indica o modo de acesso do disco e a letra
define o disco e a ordem de pesquisa dos arquivos nos discos.
46
GCS – Grupo de programas do protocolo SNA
CP - Control Program
GCS - Group Control System CMS - Conversational Monitor System
VTAM RSCS USER1 USER2 DB2
TCP/IP PVM
GCS (Group Control System)
Subsistema compartilhado que roda em máquinas virtuais que controlam

o protocolo SNA (System Network Architeture).
–RSCS (Remote Spooling Communication Subsystem) - Responsável por

transferências de dados entre sistemas.
–PVM (Pass-Through VM) - Permite que um usuário de um VM acesse outro VM

sem passar pela rede (VM <--> VM).
–VTAM (Virtual Transmition Access Method) - Responsável pelo acesso dos

usuários de VM que estão ligados à rede SNA. Permite a comunicação entre o VM
e diferentes sistemas operacionais. Controla CTCAs - (Channel To Channel
Adapter).
47
Função do RSCS
RSCS
PRINTER READER PUNCH PRINTER READER PUNCH
Sistema Sistema
operacional VM1 operacional VM2
CTC
A máquina RSCS, do grupo GCS, é responsável pelo envio de arquivos entre 2

máquinas CMS, independente das mesmas estarem no mesmo VM ou em
servidores diferentes.
Ao dar o comando SF (send file) a máquina origem pede serviços do RSCS, coloca
o arquivos na PUNCH para que o RSCS retire dele e transporte para a máquna
destino, colocando à disposição na READER do destinatário.
O arquivo ficará no spool de entrada (READER) até que seja recebida (RECEIVE)
para a lista de arquivos da máquina (FILELIST) ou descartada (DISCARD)
Par monitorar a máquina RSCS os operadores têm os sguintes comandos:
Consulta:
SM RSCS Q parâmetros
ƒ
Exemplos:
sm rscs q sy
sm rscs q pokvm011 q
sm rscs q s390vml1 a
Ação:
ƒ SM RSCS parâmetros
Exemplos:
sm rscs start pokvm011
sm rscs stop tc1vm
sm rscs rout pokvm01 203 to sbryvm07
sm rscs dr pvm9ln1
sm rscs pur pvm9ln1 5237
48
Função da máquina PVM
USERID USERID
PVM PVM
Máquina Virtual PVM Máquina virtual PVM
PKEDPS1 - BOSTON -
Sistema Sistema
operacional operacional
CTC
VM VM
O software PVM permite que através de um VM

cheguemos a outros sistemas VM´s. Utiliza como meio
físico para desempenhar esta função, os CTC´s (channel
to channel Adapter).
Para se utilizar o PVM devemos discar para ele (D PVM). Ele apresenta a lista de
máquinas com as quais esta máquina tem conexão por CTC.
Para monitorar a máquina PVM os operadores têm os seguntes comandos:
Consulta:
SM PVM Q parâmetros
ƒ
Exemplos:
sm pvm q sy
sm pvm q pkedvm9
Ação:
SM PVM parâmetros
Exemplos:
sm pvm start pkedvm9
sm pvm stop rhqvm02
sm pvm dr kcv3ad1
49
Função do VTAM
O VTAM mantém as conexões do VM com um conjunto de
outras máquinas VM, com a função de transporte de
dados, utilizando protocolo SNA.
As outras máquinas GCS utilizam os serviços da máquina
VTAM para cumprir sua função
Comandos de VTAM:
Consulta
SM VTAM D NET, parâmetro
Exemplos:
sm vtam d net,id=cdrms
sm vtam d net,id=stations
sm vtam d net,pending
sm vtam d net,id=r24pp0d,e
Ação
SM VTAM V NET, parâmetros
Exemplos:
sm vtam v net, act,id=r24pp0d
sm vtam v net, inact,id=r24pp0d,f
50
Comandos de consulta e alteração de estado

Comando de display - QUERY:
Este comando é utilizado para exibir informações sobre o sistema operacional e todos
os recursos disponíveis para ele.
ƒ Query parâmetro
Comando de alteração de status SET:

Este comando é utilizado para estabelecer, transformar ou resetar uma função
particular em uma máquina virtual.
ƒ SET parâmetros
Exemplos de comandos de consulta a parâmetros:

q cplevel
q names
q user regopr1
q dasd ALL
q tape
Q pf
Exemplos de comando para alteração de status

set warning off
set pf9 query users
set pf10 query names
51
Mainframe: z/OS Concepts
52
What is z/OS?
The most widely used mainframe operating system
OS/390, MVS, MVS/ESA, z/OS
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/OS1, 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.
53
Hardware resources managed by z/OS
z/OS
System Console
(hardware)
Mainframe computer
(CPU, processor
Master Console storage)
(z/OS)
Operator Console
(z/OS)
Tape drive
Tape
cartridges
DASD
controller
Disk storage
(DASD volumes)
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 that connect the
mainframe to the other tape drives, DASD devices, and consoles.
54
Virtual storage concepts
Virtual storage is an “illusion” created through z/OS management of real

storage and auxiliary storage
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 is

an address space
Each user or separately running program is represented by an address

space
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.
55
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, MQ, and IMS.
• TSO/E address spaces are created for every user who logs on to z/OS
• RACF protects all z/OS and Sub-systems resources
• Address spaces for every batch job that runs on z/OS.
The command START (S) starts a Started Tasks Address Spaces. Ex: S CICS
The command STOP (P) stops a Started Tasks Address Spaces. Ex: P RMF
56
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.
In an operating system, storage management involves file allocation, placement,

monitoring, migration, backup, recall, recovery, and deletion. These activities can be
done either manually or through the use of automated processes. When storage
management is automated, the system determines object placement, and automatically
manages object backup, movement, space, and security. A typical z/OS production
system includes both manual and automated processes for managing storage.
Depending on how a z/OS system and its storage devices are configured, a user or
program can directly control many aspects of storage use, and in the early days of the
operating system, users were required to do so. Increasingly, however, z/OS installations
rely on installation-specific settings for data and resource management, and add-on
storage management products to automate the use of storage. The primary means of
managing storage in z/OS is through the DFSMS component, which is discussed in Chapter 4,
“Working with data sets”.
57
Program products for z/OS
A z/OS system usually contains additional program

products (priced products) 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).
58
z/OS Commands
There are several commands on z/OS that can be used

to monitor and control the MVS Address Spaces and the Hardware.
DT
D A,L
D R,L
D U,DASD,ONLINE
D U,TAPE,OFFLINE
D M=CPU
D ASM
D GRC,C
Look at the last chapter “Mainframe System Commands”
59
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.
60
Mainframe: Batch processing and Job Entry Subsystem (JES)
Batch processing and JES
61
Objectives
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.
62
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.
Batch processing is for those frequently used programs that can be executed with
minimal
human interaction. They are typically executed at a scheduled time or on an as-
needed
basis.
Work running on z/OS is called a job, and job control language or JCL is used to
describe
certain attributes of the job to z/OS. A z/OS batch job consists of programs that run
in
environments described by JCL. After the JCL is submitted to the system, there is
normally no further human interaction with the job until it is complete.
63
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:
• Receive jobs into the operating system
• Schedule them for processing by z/OS
• Control their output processing.
JES is the component of the operating system that provides supplementary job
management, data management, and task management functions such as
scheduling,
control of job flow, and spooling.
z/OS has two versions of job entry systems: JES2 and JES3. Of these, JES2 is
most
common by far and is used throughout this text.
64
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.
Aprox. 90% z/OS environments use JES2.
65
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.
To run multiple jobs asynchronously, the system must perform a number of functions:
• Select jobs from the input queues (JES does this).
• Ensure that multiple jobs (including TSO users and other interactive applications) do
not conflict in data set usage.
• Ensure that single-user devices, such as tape drives, are allocated correctly.
• Find the executable programs requested for the job.
• Clean up after the job ends and then request the next job.
Most of this work is done by the initiator, based on JCL information for each job. The
most complex function is to ensure there are no conflicts due to data set utilization. For
example, if two jobs try to write in the same data set at the same time (or one reads while
the other writes), there is a conflict.1 This event would normally result in corrupted data.
The primary purpose of JCL is to tell an initiator what is needed for the job.
If job A and job B must both write to a particular data set, the system (through the initiator) does not
permit
both jobs to run at the same time. Instead, whichever job starts first causes an initiator
attempting to run the other job to wait until the first job completes.
66
How a symbolic file system is used

DDNAME DSNAME
program JCL for JOB

OPEN FILE=XYZ
READ FILE=XYZ
//XYZ DD DSNAME=MY.PAYROLL MY.PAYROLL
...
CLOSE FILE=XYZ
In this illustration we have a program, in some arbitrary language, that wants to

open and
read a data set. When the program is written, the name XYZ is arbitrarily selected
to
reference the data set. The program can be compiled and stored as an executable.
When
someone wants to run the executable program, a JCL statement must be supplied
that
relates the name XYZ to an actual data set name. This JCL statement is a DD
statement.
The symbolic name used in the program is a DDNAME and the real name of the
data set
is a DSNAME.
The program can be used to process different input data sets simply by changing
the
DSNAME in the JCL. This becomes significant for large commercial applications
that
might use dozens of data sets in a single execution of the program.
67
JES, job management, and JCL
Job control language or 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.
All jobs (STCs, JOBs and TSUs address spaces) are submitted to JES2 or JES3
using the JCL
68
Related actions with JCL

IT USER ACTIONS SYSTEM ACTIONS
Determine
JES interprets
the need JCL and
Create Submit
and
the JCL the Job passes it to
characteristics
z/OS initiator
of the Job
z/OS
System manages
Messages each step
of execution
User
JES collects
views
JES prints the output and
and
output information
interprets
about the Job
output
Imagine that you are a z/OS application programmer and you are developing a program
for a non-skilled users. Your program is supposed to read a couple of files, write another
couple, and then produce a printed report. This program will run as a batch job on z/OS.
What sorts of functions are needed in the operating system to fulfill the requirements of
your program? And, how will your program access those functions?
First, you need a sort of special language to inform the operating system about your
needs. On z/OS, this is Job Control Language (JCL). The use of JCL is covered in detail
in Chapter 6, “Using JCL” , but for now assume that JCL provides the means for you to
request resources and services from the operating system for a batch job.
Specifications and requests you might make for a batch job include the functions you
need to compile and execute the program, and allocate storage for the program to use as it
runs.
Think of JES as the manager of the jobs waiting in a queue. It manages the priority of the
set of jobs and their associated input data and output results. The initiator uses the
statements on the JCL cards to specify the resources required of each individual job once
it has been released (dispatched) by JES.
Your JCL as described is called a job—in this case formed by two sequential steps, the
compilation and execution. The steps in a job are always executed sequentially. The job
must be submitted to JES in order to be executed. In order to make your task easier, z/OS
provides a set of procedures in a data set called SYS1.PROCLIB. A procedure is a set of
JCL statements that are ready to be executed.
69
Spooling
JCL
//DD1 DD *
program ……...............
JES 1
read 2 data
……...............
/*
spool //DD2 DD SYSOUT=A
JES 4
SYSOUT
write 3
Printer
Spooling is the means by which the system manipulates its work, including:
• Using storage on direct access storage devices (DASD) as buffer storage to reduce
processing delays when transferring data between peripheral equipment and a
program to be run.
• Reading and writing input and output streams on an intermediate device for later
processing or output.
• Performing an operation such as printing while the computer is busy with other work.
There are two sorts of spooling: input and output. Both improve the performance of the
program reading the input and writing the output.
To implement input spooling in JCL, you declare // DD *, which defines one file whose
content records are in JCL between the // DD * statement and the /* statements. All the
logical records must have 80 characters. In this case this file is read and stored in a
specific JES2 spool area (a huge JES file on disk) as shown on this slide.
Later, when the program is executed and asks to read this data, JES2 picks up the records
in the spool and delivers them to the program (at disk speed).
To implement output spooling in JCL, you specify the keyword SYSOUT on the DD
statement. SYSOUT defines an empty file in the spool, allocated with logical records of
132 characters in a printed format (EBCDIC/ASCII/UNICODE). This file is allocated by
JES when interpreting a DD card with the SYSOUT keyword, and used later for the step
program. Generally, after the end of the job, this file is printed by a JES function.
70
Two-step job
First step Second step
Master Updates Master
Program Program
Tape Printer
Master
Suppose now that you want to make a backup of one master file and then update the
master file with records read-in from another file (the update file). If so, you need a job
with two steps. In Step 1, your job reads the master file, and writes it to tape. In Step 2,
another program (which can be written in COBOL) is executed to read a record from the
update file and searches for its match in the master file. The program updates the existing
record (if it finds a match) or adds a new record if needed.
Your JCL must have two steps, the first one indicating the resources for the backup
program, and the second for the update program.
Logically, the second step will not be executed if the first one fails for any reason. The
second step will have a // DD SYSOUT statement to indicate the need for output spooling.
The jobs are only allowed to start when there are enough resources available. In this way,
the system is made more efficient: JES manages jobs before and after running the
program; the base control program manages jobs during processing.
71
Job flow through the system

During execution, a job goes through the following
phases:
• Input
• Conversion
• Processing
• Output
• Print/punch (hard copy)
• Purge
During the life of a job, JES2 and the base control program of z/OS control different
phases of the overall processing. The job queues contain jobs that are waiting to
run,
currently running, waiting for their output to be produced, having their output
produced,
and waiting to be purged from the system.
72
Job flow through the system

JOB
CONVERSION EXECUTION OUTPUT HARD-COPY PURGE

QUEUE QUEUE QUEUE QUEUE QUEUE
INPUT CONVERSION PROCESSING OUTPUT HARD-COPY PURGE
SYSIN SYSOUT
SYSOUT
NON-PRINT/PUNCH
JCL
OUTPUT
JCL & SYSIN
SPOOL
DISK
73
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.
As previously mentioned, IBM provides two kinds of job entry subsystems: JES2
and
JES3. In many cases, JES2 and JES3 perform similar functions. They read jobs
into the
system, convert them to internal machine-readable form, select them for
processing,
process their output, and purge them from the system.
In an installation with a multi-processor configuration, there are noticeable

differences
between the two, mainly in how JES2 exercises independent control over its job
processing functions. That is, within the configuration, each JES2 processor
controls its
own job input, job scheduling, and job output processing.
74
JES2 and JES3 Commands
There are several commands on JES2 and JES3 that can be used
to monitor and control Jobs, Lines and other resources status
$DSPL
$DA
$DI
$DU,LNES
Look at the last chapter “Mainframe System Commands “ for more

JES2 and JES3 commands
As previously mentioned, IBM provides two kinds of job entry subsystems: JES2
and
JES3. In many cases, JES2 and JES3 perform similar functions. They read jobs
into the
system, convert them to internal machine-readable form, select them for
processing,
process their output, and purge them from the system.
In an installation with a multi-processor configuration, there are noticeable

differences
between the two, mainly in how JES2 exercises independent control over its job
processing functions. That is, within the configuration, each JES2 processor
controls its
own job input, job scheduling, and job output processing.
75
Mainframe: NETVIEW Concepts - Monitoring
Batch processing and JES
76
Ambiente Mainframe- Monitorar/Operar
Sistema Operacional: MVS / VM

Monitorar / Operar
Executar Comandos de Display:
Analisar Mensagens.
Executar Comandos de Ação:
Analisar Resultados.
77
Conceitos de Monitoração Netview
PROCESSADOR Console NETVIEW
LPAR
LPAR
CPU
2064
NETVIEW
LPAR Focal Point
LPAR
SE
LOG LOG LOG
DASD
78
INTRODUÇÃO :
O sistema SA / 390, monitoração e automação

de um ambiente MVS.
79
netview
NETVIEW
netview
netview
netview
netview
Netview
FOCAL
netview
netview
80
LOGON NETVIEW:
Paraacessar este ambiente precisamos de um usuário e

uma senha:
Usuário = id
Senha = password
81
82
83
84
Descrição
:
Account " Lpar "
Subsytem " Tasks "
Wtors " reply"
Batch " jobs "

Gateway " linha "
Nova Automação
85
FOCAL - Definição de PF:

PF1 => help
PF2 => Detalhe, possibilita analisar a mensagem em detalhes.
PF3 => End, finalisa seu trabalho no focal e faz com que você volte
para o NETVIEW.
PF6 => Roll, retorna ao NETVIEW.
PF7 => Up
PF8 => Down
PF10 =>
PF11 =>
Pf12 = > Procops, permite acessar a console do MVS selecionada.
86
FOCAL:
Este sistema é monitorado utilizando um padrão

de cores que são exibidas em seu painel de
controle. Quem faz essas atualizações
dinamicamente é a automação do NETVIEW
através de suas TASK`s.
– TASK`s
Essas task`s não tem um nome comum para todos
ambientes, logo antes de começar a executar a
monitoração é importante saber quais os nomes das task`s
relacionadas ao seu sistema.
87
FOCAL - Cores:
Vermelho:
Indica problema, temos que tomar uma ação imediata.
Amarelo:
Indica alerta, pois demonstra alguma anormalidade no sistema e
que pode se transformar em um problema.
Azul:
Com exceção da letra " B ", nos indica problema, falta de
comunicacao com o Netview, ( automação)
Pink:
Qdo. for spool - já esta critico
Qdo. for para uma task o operador precisa tomar uma
ação pois a automação se perdeu.
Verde:
O sistema esta ok.
88
FOCAL - Comandos:
TODOS OS COMANDOS PODEM SER EXECUTADOS DE DUAS
FORMAS:
XXXX COMANDO ou COMANDO,target=YYYYY
XXXX < system_name> ==> Nome específico para o sistema

OS/390.
YYYYY <domain_id> ==> Nome específico que identifica o

domínio do NETVIEW.
TARGET ==> É o parâmetro que permite ao operador especificar

e direcionar o comando para o sistema no qual será executada a
pesquisa.
89
FOCAL - Explain:
Este comando é utilizado para nos mostrar qual o significado de
cada cor e seu valor para o FOCAL:
< subsystem > EXPLAIN ou
EXPLAIN < status > | TARGET= < system_name > |< domain_id>
|<sysplex_name>
Exemplo:
– xxxx < system_name > EXPLAIN ou
– EXPLAIN,TARGET=yyyyy < domain_id >
90
FOCAL - DISPSTAT:
Este comando é utilizado para demonstrar qual o status
em que se encontra uma determinada TASK ou todas,
relacionadas ao sistema.
Exemplo:
XXXX DISPSTAT
OU
Dispstat,Target=yyyyy
91
FOCAL - INGLIST:
Este comando é utilizado para demonstrar qual o status em

que se encontra uma ou todas as TASKs , relacionadas a um
sistema SYSPLEX.
Exemplo:
XXXX INGLIST
OU
Inglist,Target=yyyyy
92
Para executar o comando via NETVIEW precisa

saber qual a LPAR ou TARGET a ser utilizado.
Se isso não for escrito o comando será direcionado
diretamente para o NETVIEW no qual o operador
realizou comando.
Todo comando de NETVIEW vem acompanhado da
particula MVS.
Exemplo:
Target MVS comando
Lpar MVS comando
MVS comando
93
TARGET
É o domain-id do sistema (netview), para localizarmos

podemos partir da lpar selecionando a com f2 ou f8 ou entrar
no netview de cada LPAR.
exemplo:
SA/390 BLXNV MessageView
LPAR
É o proprio nome do sistema que esta escrito na tela do

focal.
exemplo:
MEXD S W B G
94
95
Quando o Netview do focal sair do ar por algum

motivo devemos continuar nossa monitoração
se logando pelo Netview de cada LPAR.
Neste momento o comando será realizado

somente com a particula MVS e o comando.
exemplo
MVS D T
96
LOG - NETVIEW
BLOG:
– A LOG nos permite fazer pesquisa de todos os comandos

realizados.
Esta pesquisa pode ser referente ao dia corrente ou de dias
anteriores.
A consulta pode ser por operador e por sistema.
97
98
11
12
1 FOCAL
10 2
9 3
8 4
7
6
5
EASTERN
TIME =
NEW YORK
99
Mainframe: TSO (Time Sharing Option) and

ISPF (Interactive System Productivity)
100
How do we interact with z/OS?
TSO
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.
101
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).
Time Sharing Option/Extensions (TSO/E) allows users to create an interactive session

with the z/OS system. TSO1 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). This collection of menus and panels offers a wide range of
functions to assist users in working with data files on the system. ISPF users include
system programmers, application programmers, administrators, and others who access
z/OS. In general, TSO and ISPF make it easier for people with varying levels of
experience to interact with the z/OS system.
In a z/OS system, each user is granted a user ID and a password authorized for TSO
logon. Logging on to TSO requires a 3270 display device or, more commonly, a TN3270
emulator running on a PC.
During TSO logon, the system displays the TSO logon screen on the user’s 3270 display
device or TN3270 emulator. The logon screen serves the same purpose as a Windows
logon panel.
z/OS system programmers often modify the particular text layout and information of the
TSO logon panel to better suit the needs of the system’s users. Therefore, the screen
captures shown on these slides might differ from what you would see on a real-life
production system.
102
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 user’s 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 system’s
users.
As PASSWORDs não devem ser simples.

Devem seguir um padrão definido naquele ambiente.
Devem ser trocadas com determinada frequência.
O ID será bloqueado (revoked) caso a password seja teclada 3 vezes
erroneamente
103
TSO/E logon screen

------------------------------- TSO/E LOGON -----------------------------------
Enter LOGON parameters below: RACF LOGON parameters:
Userid ===> ZPROF
Password ===> New Password ===>
Procedure ===> IKJACCNT Group Ident ===>
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
104
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 (like a DOS prompt).
105
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
The READY prompt accepts simple line commands such as HELP, RENAME,
ALLOCATE, and CALL.
106
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.
When you invoke a CLIST, it issues the TSO/E commands in sequence. CLISTs are used
for performing routine tasks; they enable users to work more efficiently with TSO.
107
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.
TSO users create CLISTs with the CLIST command language. Another command
language used with TSO is called Restructured Extended Executor or REXX. Both
CLIST
and REXX offer shell script-type processing. These are interpretive languages, as
opposed to compiled languages (although REXX can be compiled as well). The
textbook
discusses CLIST and REXX in more detail in Chapter 8, “Using programming
languages
on z/OS” .
108
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.
109
Using ISPF allocate screen

Menu RefList Utilities Help
Allocate New Data Set
Command ===>
Data Set Name . . . : ZSCHOL.TEST.CNTL
Management class . . . (Blank for default management class)

Storage class . . . . (Blank for default storage class)
Volume serial . . . . EBBER1 (Blank for system default volume) **
Device type . . . . . (Generic unit or device address) **
Data class . . . . . . (Blank for default data class)
.Space units . . . . . TRACK (BLKS, TRKS, CYLS, KB, MB, BYTES
or RECORDS)
Average record unit (M, K, or U)
Primary quantity . . 2 (In above units)
Secondary quantity 1 (In above units)
Directory blocks . . 0 (Zero for sequential data set) *
Record format . . . . FB
Record length . . . . 80
Block size . . . . . 27920
Data set name type : (LIBRARY, HFS, PDS, or blank) *
(YY/MM/DD, YYYY/MM/DD
F1=Help F2=Split F3=Exit F7=Backward F8=Forward F9=Swap

F10=Actions F12=Cancel
This is a similar data set allocated with ISPF screens.

You can demo both of these to show the differences (interface) and similarities
(result).
110
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.
111
General structure of ISPF panels

Action Menu Utilities Compilers Options Status Help
Bar ---------------------------------------------------------------------------
ISPF Primary Option Menu
Panel 0 Settings Terminal and user parameters User ID . : AUES100

Options 1
2
View
Edit
Display source data or listings
Create or change source data
Time. . . :
Terminal. :
16:14
3278
3 Utilities Perform utility functions Screen. . : 1
Dynamic 4 Foreground Interactive language processing Language. : ENGLISH
Status 5 Batch Submit job for language processing Appl ID . : ISR
Area 6 Command Enter TSO or Workstation commands TSO logon : LOGON
7 Dialog Test Perform dialog testing TSO prefix: AUES100
8 LM Facility Library administrator functions System ID : SYS1
9 IBM Products IBM program development products MVS acct. : ACCNT#
10 SCLM SW Configuration Library Manager Release . : ISPF 5.2
11 Workplace ISPF Object/Action Workplace
S SDSF System Display and Search Facility
Enter X to Terminate using log/list defaults
Command Option ===>

Line
F1=Help F2=Split F3=Exit F7=Backward F8=Forward F9=Swap
Function F10=Actions F12=Cancel
Keys
112
ISPF Edit Panel - some line commands
Command Description
I Insert lines
D Delete lines
R Repeat lines
C Copy lines
M Move lines
A After line
B Before line
( Shift right columns
< Shift right data
) Shift left columns
> Shift left data
X Exclude lines
113
ISPF Edit Panel - Inserting lines

Screen 1
Screen 2
You can perform the following tasks:

• To view a data set’s contents, enter a v (view) as a line command in the column.
• To edit a data set’s contents, enter an e (edit) as a line command in the column.
• To edit the contents of a data set, move the cursor to the area of the record to be
changed and type over the existing text.
• To find and change text, you can enter commands on the editor command line.
• To insert, copy, delete, or move text, place these commands directly on the line
numbers where the action should occur.
•To commit your changes, use PF3 or save. To exit the data set without saving your
changes, enter Cancel on the edit command line.
114
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.
115
Mainframe: JCL (Job Control Language) and

SDSF (Spool Display and Search Facility)
116
Chapter 7 objectives
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
117
What is JCL?
Job control language (JCL) is used to tell the

system what program to execute, followed by a
description of program inputs and outputs.
There are three basic JCL statements:
• JOB statement
• EXEC statement
• DD statement
The details of JCL can be complicated but the general concepts are quite simple.
Also, a small subset of JCL
accounts for at least 90% of what is actually used. This chapter discusses selected
JCL
options.
While application programmers need some knowledge of JCL, the production

control
analyst responsible must be highly proficient with JCL, to create, monitor, correct
and
re-run the company’s daily batch workload.
118
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
There are three basic JCL statements:

JOB Provides a name to the system for this batch workload. It can optionally
include accounting information and a few job-wide parameters.
EXEC Provides the name of a program to execute. There can be multiple EXEC
statements in a job. Each EXEC statement within the same job is a job step.
DD The Data Definition provides inputs and outputs to the execution program
on the EXEC statement. This statement links a data set or other I/O device
or function to a DDNAME coded in the program. DD statements are
associated with a particular job step.
119
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 Chapter 5, “TSO/E, ISPF, and UNIX: Interactive facilities of z/OS” , we executed

the
same routine from the TSO READY prompt. Each JCL DD statement is equivalent
to the
TSO ALLOCATE command. Both are used to associate a z/OS data set with a
ddname,
which is recognized by the program as an input or output. The difference in method
of
execution is that TSO executes the sort in the foreground while JCL is used to
execute
the sort in the background, or batch.
120
In the preceding example…

MYJOB Job name
MYSORT Step name
SORTIN DD name for program input
SORTOUT DD name for program output
SYSOUT Where to send system output
messages (such as a data set)
SYSIN Specifies whether the input will
be data or control statements.
When submitted for execution:

MYJOB Is a job name the system associates with this workload.
MYSORT Is the stepname, which instructs the system to execute the SORT
program.
SORTIN On the DD statement, this is the ddname. The SORTIN ddname is
coded in the SORT program as a program input. The
data set name
(DSN) on this DD statement is ZPROF.AREA.CODES.
The data set can
be shared (DISP=SHR) with other system processes.
The data content
of ZPROF.AREA.CODES is SORT program input.
SORTOUT This ddname is the SORT program output.
SYSOUT SYSOUT=* specifies to send system output messages to the Job Entry
Subsystem (JES) print output area. It is possible to send
the output to a
data set.
SYSIN DD * is another input statement. It specifies that what follows is data or
control statements. In this case, it is the sort instruction
telling the
SORT program which fields of the SORTIN data records
are to be
sorted.
We use JCL statements in this text; some z/OS users use the older term JCL card, even
though the JCL resides in a disk library.
121
JCL: JOB statement

Create a member using ISPF edit
Create JCL statements
JOB statement
Accounting information
Execution classes
JOB JCL statement //MYJOB JOB 1 is a job card with name MYJOB. The 1 is a job card
accounting field that can be subject to system exits that might be used for charging
system users. Some common JOB card operands that could be included are:
REGION= Value requesting specific memory resources allocated to this job

NOTIFY= Message can be sent to a TSO user ID, following job completion
USER= Job will assume the authority of the user ID specified
TYPRUN= It is possible to submit the job on HOLD, to be released later
CLASS= Direct job JCL statement to a specific input queue, installation
specific
MSGCLASS= Direct job output to a specific output queue, installation specific
MSGLEVEL= Controls amount of system message to be received
Example:
//MYJOB JOB 1,NOTIFY=&SYSUID,REGION=6M
122
JCL: EXEC statement
EXEC statement
Region size
The EXEC JCL statement //MYSTEP EXEC has a stepname of MYSTEP. Following the
EXEC is either PGM=(executable program name) or a JCL PROC name. When a JCL
PROC is present, then the operands will be the variable substitutions required by the JCL
PROC. Common operands found on the EXEC PGM= statement are:
PARM= Parameters known by and passed to the program.

COND= Boolean logic for controlling execution of other EXEC steps in this
job....IF, THEN, ELSE JCL statements exist that are
superior to using
COND, however, lots of old JCL may exist in
production environments
using this statement.
TIME= Imposes a time limit.
Example:
//MYSTEP EXEC PGM=SORT
123
JCL: DD statement
DD statement
DD name (referenced in the program)
DSN= (the data set name as cataloged on disk)
The DD JCL statement //MYDATA DD has a ddname of MYDATA.
DD, the Data Definition, has significantly more operands than the JOB or EXEC
statements. The DD JCL statement can be involved with many aspects of defining or
describing attributes of the program inputs or outputs. Some common DD statement
operands are:
DSN= The name of the data set; this can include creation of temporary data
sets or a reference back to the data set name.
DISP= Data set disposition at step start (new, shr, old, mod), at step end (catlg,
keep, delete, pass) and if the step abnormally ends (catlg, keep,
delete,
pass).
SPACE= Amount of disk storage requested for a new data set.
SYSOUT= Defines a print location (and the output queue or data set).
VOL=SER= Volume name, disk name or tape name
UNIT= System disk, tape, special device type, or esoteric (local name).
DEST= Routes output to a remote destination.
DCB= Data set control block, numerous sub operands.
Most common suboperands:

LRECL= Logical record length. Number of bytes/characters in each
record.
RECFM= Record format, fixed, blocked, variable, etc.
BLOCKSIZE= Store records in a block of this size, typically a multiple of
LRECL. A value of 0 will let the system pick the best value.
DSORG= Data set organization—sequential, partitioned, etc.
LABEL= Tape label expected (No Label or Standard Label followed by data set
location). A tape can store multiple data sets; each data set on
the tape
is in a file position. The first data set on tape is file 1.
DUMMY Results in a null input or throwing away data written to
this ddname.
* Input data or control statements follow—a method of passing
data to a
program from the JCL stream.
*,DLM= Everything following is data input (even //) until the two alphanumeric
or special characters specified are encountered in column 1. 124
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.
125
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
All JCL parameters are important, but the DISP function is perhaps the most important
for DD statements. The complete parameter has these fields:
DISP= (status,normal end,abnormal end)

DISP= (status,normal end)
DISP= status
where status can be NEW, OLD, SHR, or MOD:

NEW Indicates that a new data set is to be created. This job has exclusive access to
the data set while it is running. The data set must not already exist.
OLD Indicates that the data set already exists and that this job is to have exclusive
access to it while it is running.
SHR Indicates that the data set already exists and that several concurrent jobs can
share access while they are running. All the concurrent jobs must specify
SHR.
MOD Indicates that the data set already exists and the current job must have
exclusive access while it is running. If the current job opens the data set for
output, the output will be appended to the current end of the data set.
The normal end parameter indicates what to do with the data set (the disposition) if the
current job step ends normally. Likewise, the abnormal end parameter indicates what to
do with the data set if the current job step abnormally ends.
The options are the same for both parameters:

DELETE Means to delete (and uncatalog) the data set at the end of the job step.
KEEP Means to keep (but not catalog) the data set at the end of the job step.
CATLG Means to keep and catalog the data set at the end of the job step.
UNCATLG Means to keep the data set but uncatalog it at the end of the job step.
PASS Means to allow a later job step to specify a final disposition.
The default disposition parameters (for normal and abnormal end) are to leave the data
set as it was before the job step started. (The catalog function was described previously.)
A main purpose of the DISP parameter is to advise the system about data set enqueuing
needed for this job to prevent conflicting use of the data set by other jobs.
126
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.
If the DISP parameter for a data set is NEW, then additional information is needed. This
includes:
• A data set name.
• The type of device for the data set.
• A volser if it is a disk or labeled tape.
If a disk is used, the amount of space to be allocated for the primary extent must be
specified.
If it is a partitioned data set, the size of the directory must be specified.
Optionally, DCB parameters can be specified. Alternately, the program that will write
the data set can provide these parameters.
The DISP and data set names have already been described. Briefly, the other parameters
are:
Volser The format for this in a DD statement is VOL=SER=xxxxxx, where
xxxxxx is the volser. The VOL parameter can specify other
details,
which is the reason for the format.
Device type There are a number of ways to do this, but UNIT=xxxx is the most
common. The xxxx can be an IBM device type (such as 3390),
or a
specific device address (such as 300), or an esoteric name
defined by
the installation (such as SYSDA). A common convention uses
SYSDA to represent any available disk volume.
Member name Remember that a library (or partitioned data set, PDS) member can
be treated as a data set by many applications and utilities. The
format
DSNAME=ZPROF.LIB.CNTL(TEST) is used to reference a
specific
member. If the application or utility program is expecting a
sequential data set, then either a sequential data set or a
member of a
library must be specified. A whole library name (without a
specific
member name) can be used only if the program or utility is
expecting a 127
library name.
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.
As a consequence of the limitations of the number of characters that could be

contained
in single 80-column punched cards used in earlier systems, z/OS introduced the
concepts
of continuation and concatenation. Therefore, z/OS retained these conventions in
order to
minimize the impact on previous applications and operations.
128
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
Continuation of JCL syntax involves a comma at the end of the last complete operand.
The next JCL line would include // followed by at least one space, then the additional
operands. JCL operand syntax on a continuation line must begin on or before column
sixteen.
//JOBCARD JOB 1,REGION=8M,NOTIFY=ZPROF
An important feature of DD statements is the fact that a single ddname can have multiple
DD statements. This is called concatenation.
The following JCL indicates that data sets are concatenated:

//DATAIN DD DISP=OLD,DSN=MY.INPUT1
// DD DISP=OLD,DSN=MY.INPUT2
// DD DISP=SHR,DSN=YOUR.DATA
Concatenation applies only to input data sets. The data sets are automatically processed
in sequence. In the example, when the application program reads to the end of
MY.INPUT1, the system will automatically open MY.INPUT2 and start reading it. The
application program is not aware that it is now reading a second data set. This continues
until the last data in the concatenation is read; at that time the application receives an
end-of -file indication.
129
JCL procedures - example

//MYJOB JOB 1
//MYPROC PROC
//SORTIN DD DISP=SHR,DSN=&SORTDSN
// PEND
Some programs and tasks require a larger amount of JCL than a user can easily enter.
JCL for these functions can be kept in procedure libraries. A procedure library member
contains part of the JCL for a given task -- usually the fixed, unchanging part of JCL.
The user of the procedure supplies the variable part of the JCL for a specific job.
Such a procedure is sometimes known as a cataloged procedure. A cataloged procedure
is not related to the system catalog.
Much of this JCL should be recognizable now. New JCL functions presented here
include:
• PROC and PEND statements are unique to procedures. They are used to identify the
beginning and end of the JCL procedure.
• The PROC is preceded by a label or name; the name defined in the example on the slide is
MYPROC.
• JCL variable substitution is the reason JCL PROCs are used. &SORTDSN is the only
variable in this example.
130
JCL procedures -- another example

//MYJOB JOB 1
//*---------------------------------*
//MYPROC PROC
// PEND
//*---------------------------------*
//STEP1 EXEC MYPROC,SORTDSN=IBMUSER.AREA.CODES
//SYSIN DD *
In this example, we include the inline procedure from the previous slide in our job
stream.
•When MYJOB is submitted, the JCL from the example on the previous slide is
effectively
substituted for EXEC MYPROC. The value for &SORTDSN must be provided.
• SORTDSN and its value were placed on a separate line, a continuation of the
EXEC
statement. Notice the comma after MYPROC.
• //SYSIN DD * followed by the SORT control statement will be appended to the
substituted JCL.
131
JCL procedures -- statement override

//MYJOB JOB 1
//*---------------------------------*
//MYPROC PROC
// 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 *
When an entire JCL PROC statement needs to be replaced, then a JCL PROC
override
statement can be used. An override statement has the following form:
//stepname.ddname DD ...
This slide shows an example of overriding the SORTOUT DD statement in

MYPROC.
Here, SORTOUT is directed to a newly created sequential data set.
132
Using SDSF
After submitting a job, it is common for z/OS users to 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 preceded by a “/”
• 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 is a software product whose primary purpose is to display printed output held
in the JES
spool area. Much of the printed output sent to JES by batch jobs (and other jobs) is
never
actually printed. Instead it is inspected using SDSF and deleted or used as needed.
133
SDSF panel hierarchy Primary

Option
Menu
Display Help
Input Output
SYSLOG Active Output Status Printer Initiator
Queue Queue
Panel Users Queue Panel Panel Panel
Panel Panel
Panel Panel
Job Output
Data Set Descriptor
Panel Panel
Output
Data Set
Panel
134
SDSF: Primary option menu
This is the SDSF primary options menu. Some of the options shown are:
DA The Display Active panel shows information about MVS

address spaces (jobs, started tasks,
and TSO users) that are running.
I The Input Queue panel displays information about jobs,
started
tasks, and TSO users on the JES2 input queue or
executing.
O The Output Queue panel displays information about
SYSOUT data
sets for jobs, started tasks, and TSO users on any
nonheld JES2 output queue.
H The Held Output panel shows information about
SYSOUT data sets for
jobs, started tasks, and TSO users on any held JES2
output queue.
ST The Status panel displays information about jobs,
started tasks,
and TSO users on the JES2 queues.
LOG The system Log panel displays the log and lets you
search it. 135
PS
SDSF: Options menu
Selecting options from the task bar allows you to tailor the SDSF primary options
panel.
136
Viewing the JES2 output files

Screen 1
Screen 2
The first screen shown on the slide displays a list of the jobs we submitted and
whose
output we directed to the HELD (Class T) queue, as identified in the MSGCLASS=T
parameter on the job card. In our case only one job has been submitted and
executed.
Therefore, we only have one job on the Held queue.
Issuing a ? command in the NP column displays the output files generated by job
7359.
The second screen displays three ddnames: the JES2 messages log
file, the JES2 JCL file, and the JES2 system messages file. This option is useful
when
you are seeing jobs with many files directed to SYSOUT and you want to display
one
associated with a specific step. You issue an S in the NP column to select a file you
want.
To see all files, instead of a ?, type S in the NP column;
137
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
COMMAND INPUT == PRE *

COMMAND INPUT == DA
138
SDSF: Input queue panel
COMMAND INPUT == PRE BAR*

COMMAND INPUT == I
139
SDSF: Output queue panel

COMMAND INPUT == O
140
SDSF: Held output queue panel
COMMAND INPUT == PRE MIR*

COMMAND INPUT == H
141
SDSF: Status panel

COMMAND INPUT == ST
142
Utilities
• z/OS includes a number of programs useful in
batch processing called utilities.
• Utilities provide many small, obvious, and useful
functions.
• Customer sites often write their own utility
programs, many of which are shared by the z/OS
user community.
• Some examples of utilities:
• IEBGENER Copies a sequential data set
• IEBCOPY Copies a partitioned data set
• IDCAMS Works with VSAM data sets
The IEFBR14 is a very used utility to allocate and delete datasets on first step of a
job
143
System Libraries
z/OS has many standard system libraries, including:
• SYS1.PROCLIB JCL procedures distributed

with z/OS
• SYS1.PARMLIB Control parameters for z/OS
and some program products.
• SYS1.LINKLIB Many of the basic execution
modules of the system.
• SYS1.LPALIB System execution modules
that are loaded into the link
pack area at z/OS initialization.
These libraries are standard PDS data sets and are found on the system disk
volumes.
144
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 locally-written
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.
145
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.
146
Mainframe: Working with data sets
147
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.
148
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.
In a z/OS system, data can be stored on a direct access storage device (DASD),
magnetic
tape volume, or optical media. The term DASD applies to disks or simulated
equivalents
of disks. All types of data sets can be stored on DASD, but only sequential data
sets can
be stored on magnetic tape. We discuss the types of data sets later in this module.
149
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, DFSMS is used to automate storage
management for data sets.
In a z/OS system, data management involves allocation, placement, monitoring,

migration, backup, recall, recovery, and deletion. These activities can be done either
manually or through the use of automated processes. When data management is
automated, the operating system determines object placement, and automatically
manages object backup, movement, space, and security. A typical z/OS production
system includes both manual and automated processes for managing data sets.
Data management includes these main tasks:

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

management functions of the system. DFSMS is a set of products, and one of these
products, DSFMSdfp, is required for running z/OS. DFSMS, together with hardware
products and installation-specific settings for data and resource management, provides
system-managed storage in a z/OS environment.
The heart of DFSMS is the Storage Management Subsystem (SMS). Using SMS, the
system programmer or storage administrator defines policies that automate the
management of storage and hardware devices. These policies describe data allocation
characteristics, performance and availability goals, backup and retention requirements,
and storage requirements for the system. SMS governs these policies for the system and
the Interactive Storage Management Facility (ISMF) provides the user interface for
defining and maintaining the policies.
The data sets allocated through SMS are called system-managed data sets or
SMS-managed data sets.
150
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.
151
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.
152
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 panel option 3.2.
• Access Method Services
• TSO ALLOCATE command
• job control language (JCL).
To use a data set, you first allocate it (establish a link to it), then access the data
using
macros for the access method that you have chosen.
The allocation of a data set means either or both of two things:

• To set aside (create) space for a new data set on a disk.
• To establish a logical link between a job step and any data set.
153
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.
You can specify the amount of space required in blocks, records, tracks, or cylinders.
When creating a DASD data set, you specify the amount of space needed explicitly (by
using the SPACE parameter), or implicitly (by using the information available in a data
class).
The system can use a data class if SMS is active even if the data set is not SMS managed.
For system-managed data sets, the system selects the volumes, saving you from having to
specify a volume when you allocate a data set.
If you specify your space request by average record length, space allocation is
independent of device type. Device independence is especially important to
system-managed storage.
A logical record (LRECL) is a unit of information about a unit of processing (for

example, a customer, an account, a payroll employee, and so on). It is the smallest
amount of data to be processed, and it is comprised of fields which contain information
recognized by the processing application.
Logical records, when located in DASD, tape, or optical devices, are grouped in physical
records named blocks (BLKSIZE). Each block of data on a DASD volume has a distinct
location and a unique address, thus making it possible to find any block without
extensive searching. Logical records can be stored and retrieved either directly or
sequentially.
The maximum length of a logical record (LRECL) is limited by the physical size of the
used media.
Space for a disk data set is assigned in extents. An extent is a contiguous number of disk
drive tracks (or cylinders). Data sets can increase in extents as they grow. Older types of
data sets can have up to 16 extents per volume. Newer types of data sets can have up to
128 or 255 extents.
In z/OS, a data set organization based on extents is designed to maximize disk

performance. Reading or writing contiguous tracks is faster than reading or writing tracks
scattered over the disk, as might be the case if tracks were allocated dynamically.
154
Data set record formats

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

Variable records.
RDW
block block
VB record record record record record
Variable blocked records. BLKSIZE >= 4 + n * lragest LRECL
BDW
U record record record record

Undefined records. No defined internal structure for access method.
Record and block descriptors words are each 4 bytes long

Traditional z/OS data sets are record oriented. In normal usage, there are no byte stream
files such as are found in PC and UNIX systems. (z/OS UNIX has byte stream files, and
byte stream functions exist in other specialized areas. These are not considered to be
traditional data sets.)
In z/OS, there are no new line (NL) or carriage return and line feed (CR+LF) characters
to denote the end of a record. Records are either fixed length or variable length in a given
data set. When editing a data set with ISPF, for example, each line is a record.
Traditional z/OS data sets have one of five record formats, as shown on the slide. We must
stress the difference between a block and a record. In this discussion,
a block is what is written on disk, while a record is a logical entity.
F - Fixed This means that one physical block on disk is one logical
record and all the blocks/records are the same size. This
format is seldom used.
FB - Fixed Blocked This means that several logical records are combined into one
physical block. This can provide efficient space utilization and
operation. This format is commonly used for fixed-length
records.
V - Variable This format has one logical record as one physical block. The
application is required to insert a four-byte Record Descriptor
Word (RDW) at the beginning of the record. The RDW
contains the length of the record plus the four bytes for the
RDW. This format is seldom used.
VB - Variable Blocked This format places several variable-length logical records

(each with an RDW) in one physical block. The software must
place an additional Block Descriptor Word (BDW) at the
beginning of the block, containing the total length of the
block.
U - Undefined This format consists of variable-length physical

records/blocks with no predefined structure. Although this
format may appear attractive for many unusual applications, it 155
is normally used only for executable modules.
Types of data sets

We discuss three types in this class:
• Sequential, partitioned, and VSAM
A 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.
The simplest data structure in a z/OS system is a sequential data set. It consists of one or
more records that are stored in physical order and processed in sequence. New records
are appended to the end of the data set.
An example of a sequential data sets might be an output data set for a line printer or a
deck of punch cards.
A z/OS user defines sequential data sets through job control language (JCL) with a data
set organization of PS (DSORG=PS), which stands for physical sequential. In other
words, the records in the data set are physically arranged one after another.
A partitioned data set adds a layer of organization to the simple structure of sequential
data sets. A PDS is a collection of sequential data sets, called members. Each member is
like a sequential data set and has a simple name, which can be up to eight characters long.
A PDS also contains a directory. The directory contains an entry for each member in the
PDS with a reference (or pointer) to the member. Member names are listed alphabetically
in the directory, but members themselves can appear in any order in the library. The
directory allows the system to retrieve a particular member in the data set.
A partitioned data set is commonly referred to as a library.
A PDSE is a partitioned data set extended. It consists of a directory and zero or more
members, just like a PDS. It can be created with JCL, TSO/E, and ISPF, just like a PDS,
and can be processed with the same access methods. PDSE data sets are stored only on
DASD, not tape.
156
PDS versus PDSE
PDS data sets:

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

• Similar in some ways to a PDS, but advantages include:
• Space reclaimed automatically when a member is deleted
• Flexible size
• Can be shared
• Faster directory searches
A PDS data set offers a simple and efficient way to organize related groups of sequential
files. A PDS has the following advantages for z/OS users:
• Grouping of related data sets under a single name makes z/OS data management
easier. Files stored as members of a PDS can be processed either individually or all
the members can be processed as a unit.
• Because the space allocated for z/OS data sets always starts at a track boundary on
disk, using a PDS is a way to store more than one small data set on a track. This saves
you disk space if you have many data sets that are much smaller than a track. A track
is 56,664 bytes for 3390 disk device.
•Members of a PDS can be used as sequential data sets, and they can be appended (or
concatenated) to sequential data sets.
• Multiple PDS data sets can be concatenated to form large libraries.
• PDS data sets are easy to create with JCL or ISPF; they are easy to manipulate with
ISPF utilities or TSO commands.
However, some aspects of the PDS

design affect both performance and the efficient use of disk storage, as follows:
Wasted space. When a member in a PDS is replaced, the new data area is written to a
new section within the storage allocated to the PDS. When a member is deleted, its
pointer is deleted too, so there is no mechanism to reuse its space.
Limited directory size. The size of a PDS directory is set at allocation time. As the
data set grows, it can acquire more space in units of the amount you specified as its
secondary space. These extra units are called secondary extents.
However, you can only store a fixed number of member entries in the PDS directory
because its size is fixed when the data set is allocated. If you need to store more
entries than there is space for, you have to allocate a new PDS with more directory
blocks and copy the members from the old data set into it.
Lengthy directory searches. Entries are searched sequentially in alphabetical order. If the directory is very
large and the members small, it might take longer to search the directory than to
retrieve the member when its location is found.
In many ways, a PDSE is similar to a PDS. Each member name can be eight bytes long.
For accessing a PDS directory or member, most PDSE interfaces are indistinguishable
from PDS interfaces. Both PDS and PDSE data sets are processed using the same access 157
methods (BSAM, QSAM, BPAM).
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)
The term Virtual Storage Access Method (VSAM) applies to both a data set type
and the
access method used to manage various user data types.
As an access method, VSAM provides much more complex functions than other
disk
access methods. VSAM keeps disk records in a unique format that is not
understandable
by other access methods.
VSAM is primarily for applications. It is not used for source programs, JCL, or
executable modules. VSAM files cannot be routinely displayed or edited with ISPF.
You can use VSAM to organize records into four types of data sets: key-sequenced,
entry-sequenced, linear, or relative record. The primary difference among these
types of
data sets is the way their records are stored and accessed.
158
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
• First byte: alphabetical (A-Z) or special (@ # $)
• The 7 remaining: alphabetical, special, numeric (0-9)
When you allocate a new data set (or when the operating system does), you must give the
data set a unique name.
A data set name can be one name segment, or a series of joined name segments. Each
name segment represents a level of qualification. For example, the data set name
VERA.LUZ.DATA is composed of three name segments. The first name on the left is
called the high-level qualifier (HLQ), the last name on the right is the lowest-level
qualifier (LLQ).
Segments or qualifiers are limited to eight characters, the first of which must be
alphabetic (A to Z) or special (# @ $). The remaining seven characters are either
alphabetic, numeric (0 - 9), special, a hyphen (-). Name segments are separated by a
period (.).
159
Catalogs and VTOCs

z/OS uses a catalog and a volume table of contents (VTOC)
on each DASD to manage the storage and placement of
data sets.
VTOC:
• Lists the data sets on a volume
• Lists the free space on the volume.
z/OS uses a catalog and a volume table of contents (VTOC) on each DASD to
manage
the storage and placement of data sets.
z/OS requires a particular format for disks, which is shown on the next slide.
160
VTOC
LABEL
(volser)
VTOC
MY.DATA YOUR.DATA free space
tracks tracks tracks
Extents
Record 1 on the first track of the first cylinder provides the label for the disk. It contains
the 6-character volume serial number (volser) and a pointer to the Volume Table Of
Contents (VTOC), which can be located anywhere on the disk.
The VTOC lists the data sets that reside on its volume, along with information about the
location and size of each data set, and other data set attributes. A standard z/OS utility
program, ICKDSF, is used to create the label and VTOC.
When a disk volume is initialized with ICKDSF, the owner can specify the location and
size of the VTOC. The size can be quite variable, ranging from a few tracks to perhaps
100 tracks, depending on the expected use of the volume. More data sets on the disk
volume require more space in the VTOC.
The VTOC also has entries for all the free space on the volume. Allocating space for a
data set (described later) causes system routines to examine the free space records,
update them, and create a new VTOC entry. Data sets are always an integral number of
tracks (or cylinders) and start at the beginning of a track (or cylinder).
161
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.
A catalog describes data set attributes and indicates the volumes on which a data set is
located. Data sets can be cataloged, uncataloged, or recataloged. All system-managed
DASD data sets are cataloged automatically in a catalog. Cataloging of data sets on
magnetic tape is not required but usually it simplifies users jobs. All data sets can be
cataloged in a catalog.
In z/OS, the master catalog and user catalogs store the locations of data sets by name.
This means that data set names must be unique. Both disk and tape data sets can be
cataloged.
To find a data set that you have requested, z/OS must know three pieces of information:
• Data set name
• Volume name
• Unit (the volume device type, such as a 3390 disk or 3590 tape)
You can specify all three values on ISPF panels or in JCL. However, the unit device type
and the volume are often not relevant to an end user or application program.
162
Catalog Structure SYSTEM.MASTER.CATALOG
Master Catalog
Data Set-SYS1.A1
or
HLQs (alias)
USERCAT.IBM IBMUSER...USER USERCAT.COMPANY
User Catalog User Catalog
Data Set with Data Set with

HLQ=IBMUSER HLQ=USER
Catalog Structure
volume (wrk002)
unit (3390) volume (wrk001)
unit (3390)
volume (012345)
IBMUSER.A2 IBMUSER.A1 unit (tape)
IBMUSER.A3 USER.A1 USER.TAPE.A1
SYS1.A1
A z/OS system always has at least one master catalog. If a z/OS system has a single
catalog, this catalog would be the master catalog and the location entries for all data sets
would be stored in it. A single catalog, however, would be neither efficient nor flexible,
so a typically z/OS system uses a master catalog and numerous user catalogs connected
to it as shown on the slide.
A user catalog stores the name and location of a data set (dsn/volume/unit). The master
catalog usually stores only a data set HLQ with the name of the user catalog, which
contains the location of all data sets prefixed by this HLQ. The HLQ is called an alias.
On the slide, the data set name of the master catalog is SYSTEM.MASTER.CATALOG. This
master catalog stores the full data set name and location of all data sets with a SYS1
prefix such as SYS1.A1. Two HLQ (alias) entries were defined to the master catalog,
IBMUSER and USER. The statement that defined that IBMUSER included the data set
name of the user catalog containing all the fully qualified IBMUSER data sets with their
respective location. The same is true for USER HLQ (alias).
When SYS1.A1 is requested, the master catalog returns the location information,
volume(WRK001) and unit(3390), to the requestor. When IBMUSER.A1 is requested,
the master catalog redirects the request to USERCAT.IBM, then USERCAT.IBM returns
the location information to the requestor.
163
Dasd Capacity
DASD CAPACITY TABLE
Physical Characteristics 3380-J 3380-E 3380-K 3390-1 3390-2 3390-3 3390-9
Data Cyl/Device 885 1770 2655 1113 2226 3339 10017
Track/Cyl 15 15 15 15 15 15 15
Bytes/Trk 47476 47476 47476 56664 56664 56664 56664
Bytes/Cylinder 712140 712140 712140 849960 849960 849960 849960
MB/Device 630 1260 1890 946 1892 2838 8514
164
Mainframe: TWS (Tivoli Workload Schedule) Concepts
165
Objetivos:
–Apresentar o objetivo dele no processamento batch
–Apresentar a sua estrutura
–Apresentar as suas divisões
166
O que é o TWS (antigo OPC):
É uma ferramenta IBM, um aplicativo que serve para planejar e

controlar operações batch´s, tanto em sistemas mainframe
quanto para equipamentos de baixa plataforma.
167
Como é a sua estrutura de monitoração e como se

monitora:
A estrutura do TWS para monitoração é toda montada pelo

coordenador do TWS que faz todas as definições de work station,
calendários, períodos, definições de aplicações, etc... e tudo isto é
definido em um database.
Na nossa monitoração diária só temos acesso a este database com a

opção de browse, pois nos permite apenas pesquisar, não nos sendo
permitido fazer qualquer alteração.
168
Divisões básicas do TWS para monitoração:
ƒDATABASE:
Conforme falamos anteriormente, tudo que queremos monitorar via TWS, temos que
definir no database.
Definimos todas as workstations que este OPC vai ter, vai utilizar.
O que é uma workstation?
É cada passo que uma aplicação tem que caminhar dentro do sistema até a sua
conclusão (término de processamento OK. É cada step dentro de uma aplicação.
Exemplo: Assim como um step dentro do JCL de um job, é um passo para que após cada
step o job complete OK, a workstation tem o mesmo significado dentro de uma
aplicação.
169
Temos três tipos de work station:
C=Computer, G=General e P=Printer
As work stations do tipo C são as únicas que enviam jobs do TWS para executar
na CPU. As do tipo P são as criadas para enviar listagens para as printer´s e as
demais são criadas para outras atividades, tipo G.
As work stations tipo G, são as work stations de preparação de dados, work

stations com inteferência manual e work stations do tipo que fecham uma etapa,
conhecidas como DUMMY.
Chegamos então à conclusão que temos três tipos de work stations, que podem
ter cinco modelos que são de CPU (tipo C), as de impressão (tipo P) e as work
stations de preparação de dados, de interferência manual e do tipo dummy´s (tipo
G).
Só que podemos criar tantas work stations do tipo C ou do tipo G ou do tipo P

quanto precisarmos.
170
OBS: Quando digo podemos criar tantas work stations quanto precisarmos,
estou me referindo ao coordenador de TWS e não a nós monitores de sistemas.
Da mesma forma para tudo que formos criar no database do TWS.
Definimos também todos os calendários que precisaremos dentro do nosso

TWS. Os calendários servem para definirmos os work days de segunda-feira até
sexta-feira e como free days os sábados e domingos e os feriados nacionais.
Definimos também os períodos de uma aplicação, e os períodos são criados

para definir a periodicidade de uma determinada aplicação ou de várias
aplicações, pois mais de uma aplicação pode usar o mesmo período.
Descrição de uma aplicação: neste ponto do TWS, ao definirmos uma nova

aplicação, é o momento onde definimos de que forma, como, quando e onde
esta nova aplicação vai executar. Neste momento definimos também todos os
jobs que vão compor esta aplicação, suas operações, seu calendário, seu
período, suas work stations, etc...
171
ƒLTP - Long Term Plan:
O LTP é o meu plano para um determinado período de tempo, maior que o plano
diário. É uma forma que o TWS nos permite visualizar o que vai acontecer nos
próximos, por exemplo, 30 dias. Com isto é possível programar o sistema para
futuras mudanças em um determinado dia e hora. É também o local onde, ao
rodar diariamente a minha aplicação geradora do plano diário, o sistema vai
buscar todas as aplicações que serão executadas neste próximo plano diário
que está sendo gerado.
ƒMCP - Modify Current Plan:
É o meu plano de máquina, que foi gerado por um determinado período, como
por exemplo por um período de 24 horas. Ou seja, estou informando ao
sistema quais as aplicações que serão executadas dentro deste período
gerado para as próximas 24 horas.
Esta seleção de aplicações que serão executadas neste próximos período de 24
horas é selecionada conforme as suas definições que foram feitas no database
dentro das descrições das aplicações.
172
O MCP nos permite também, conforme o próprio nome indica, modificar o meu
plano corrente mesmo depois que el foi gerado, como por exemplo incluir uma
nova aplicação, modificar uma aplicação que já foi incluída na geração do plano
corrente, deletar uma aplicação inteira ou somente uma operação desta
aplicação, modificar predecessores ou sucessores, time, e também monitorar os
jobs que estão em erro.
É a base da nossa monitoração, pois é o MCP que nos permite "conversar" com o
OPC. É monitorado através de telas, que nos permite interagir com todas as
aplicações que estão executando ou aguardando algum pré-requisito para a sua
execução.
ƒQCP - Query Current Plan:
É a opção do TWS, quase idêntica ao MCP, porém só permite verificar as

aplicações no plano corrente, não nos permitindo fazer nenhum tipo de
modificação ou alteração. Também nos permite verificar quais são as aplicações
que por algum motivo também estão atrasadas em relação ao seu horário de
processamento e a validade do plano corrente que está em curso, ou seja,
quando este plano foi gerado e qual o seu término.
173

IBM Global Services - Training Center - Hortolândia: Mainframe: Concepts

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IBM Global Services - Training Center - Hortolândia: Mainframe: Concepts

Uploaded by

Copyright:

Available Formats

IBM Global Services – Training Center - Hortolândia

© Copyright IBM Corp., 2005. All rights reserved.

001 .......... Mainframe: Concepts

© Copyright IBM Corp., 2005. All rights reserved.

A mainframe is a computing system that businesses

© Copyright IBM Corp., 2005. All rights reserved.

Today, computer manufacturers don’t always use the

The presence of a mainframe often implies a centralized form of computing, rather

Who uses mainframes?

© Copyright IBM Corp., 2005. All rights reserved.

Typical mainframe workloads

© Copyright IBM Corp., 2005. All rights reserved.

A batch job is submitted on the computer,

While batch processing is possible on distributed systems, it is not as commonplace as on

Mainframes serve a vast number of online transaction processing (OLTP) systems.

Typical batch use

© Copyright IBM Corp., 2005. All rights reserved.

Consider the following elements at work in the scheduled batch process:

Typical online use

Business analysts Inventory control

© Copyright IBM Corp., 2005. All rights reserved.

Common online transactions using a mainframe:

1. A customer uses an ATM, which presents a user-friendly interface for various

Roles in the mainframe world

Application Production Control Analyst

System Programmer System Administrator

© Copyright IBM Corp., 2005. All rights reserved.

System administrators perform more of the day-to-day tasks

Customer Engineers perform the mainframe installation and maintenance

Mainframe operating systems

© Copyright IBM Corp., 2005. All rights reserved.

The z/Transaction Processing Facility (z/TPF) operating system is a special purpose

Plays a central role in the daily operations of the world’s

© Copyright IBM Corp., 2005. All rights reserved.

Mainframe: Hardware systems and logical partitions

© Copyright IBM Corp., 2005. All rights reserved.

© Copyright IBM Corp., 2005. All rights reserved.

© Copyright IBM Corp., 2005. All rights reserved.

Processadores dos anos 90’s.

Modelo #proc Mips

© Copyright IBM Corp., 2005. All rights reserved.

Processadores dos anos 2000

Modelo #proc Mips

DASD: 2105 ESS – Enterprise Storage Server (SHARK)

© Copyright IBM Corp., 2005. All rights reserved.

• Tecnologia multi-plataforma (Mainframe, UNIX, As/400, Windows)

TAPES: 3490, 3590 and VTS (Virtual Tape Server)

© Copyright IBM Corp., 2005. All rights reserved.

3490 e 3480: montagem manual

© Copyright IBM Corp., 2005. All rights reserved.

Impressão a laser super rápida

© Copyright IBM Corp., 2005. All rights reserved.

Os equipamentos são distribuídos nos Data Centers e colocados sôbre pisos

Mainframe Basic Installation

Mainframe Dasd Tape VTS

© Copyright IBM Corp., 2005. All rights reserved.

© Copyright IBM Corp., 2005. All rights reserved.

LPAR – Logical Partition

HMC – Hardware Management Console

© Copyright IBM Corp., 2005. All rights reserved.

O HMC é instalado no SE (Support Element) pelo CE (Customer Engineer).

HMC – Hardware Management Console

© Copyright IBM Corp., 2005. All rights reserved.