GC28 0667 1_OS_VS2_Planning_Guide_for_Release_2_Nov73 1 OS VS2 Planning Guide For Release 2 Nov73

User Manual: GC28-0667-1_OS_VS2_Planning_Guide_for_Release_2_Nov73

Open the PDF directly: View PDF PDF.
Page Count: 174

DownloadGC28-0667-1_OS_VS2_Planning_Guide_for_Release_2_Nov73 GC28-0667-1 OS VS2 Planning Guide For Release 2 Nov73
Open PDF In BrowserView PDF
GC28-0667-'
File No. S370-34

Systems

OS/VS2 Planning Guide for
Release 2
Program Number 5742-020

VS2 Release 2

Second Edition (November, 1973)
This is a major revision of, and obsoletes, GC28-0667-0. See the Summary of
Amendments following the Contents. Changes or additions to the text and illustrations
are indicated by a vertical line to the left of the change.
This edition applies to Release 2 of OS/VS2 and to all subsequent releases until
otherwise indicated in new editions or Technical Newsletters. Changes are continually
made to the information herein; before using this publication in connection with the
operation of IBM systems, consult the latest IBM System/360 and System/370 Bibliography,
GA22-6822, for editions that are applicable and current.
Requests for copies of IBM publications should be made to your IBM representative or
to the IBM branch office serving your locality.
A form for readers' comments is provided at the back of this publication. If the form
has been removed, comments may be addressed to IBM Corporation, Publications
Development, Department D58, Building 706-2, PO Box 390, Poughkeepsie, N.Y. 12602.
Comments become the property of IBM.
©

Copyright International Business Machines Corporation 1973

Preface
This publication contains planning information for OS/VS2 Release 2. It is
intended for installation managers and system programmers responsible for
assessing the effort required to install an OS/VS2 Release 2 system. Readers
should have a background in programming and maintaining computer operating
systems such as OS/MVT or OS/VS2 Release l.
This publication is for planning purposes only. The functions and capabilities
described reflect the information that is currently available. This information is
subject to change before the availability of OS/VS2 Release 2.
Throughout this publication the term MVS is used interchangeably with VS2
Release 2. MVS refers to the mUltiple virtual storage concept of this release.
This manual contains the following independent chapters:
• Introduction -- The Introduction highlights the major points that should be
considered in planning for the installation and implementation of VS2 Release
2.
• Defining the System -- This chapter provides preliminary planning information
for defining the type of system that an installation needs. For example, the
chapter describes the VS2 Release 2:
--procedures and macro instructions for system generation.
--procedures and parameters for system initialization.
--system libraries and data sets.
For each topic, a summary of the major changes from both MVT and VS2
Release 1 is provided.
• Directing the Use of System Resources
new VS2 Release 2 facilities that allow
distribution of system resources among
information that helps assess the effort
facilities.

-- This chapter describes some of the
an installation to control the
system users. It provides planning
involved in implementing these

• System Integrity -- This chapter discusses integrity in a multi-user computer
system. It includes recommendations for maintaining, in any control program
extensions or modifications, the same level of system integrity as that of the
VS2 Release 2 system.
• Conversion Considerations -- This chapter presents preliminary descriptions of
some of the most significant differences between VS2 Release 2 and MVT or
VS2 Release 1. It provides the information to assess the extent of the
modifications required for existing data sets, cataloged procedures, programs,
data reduction routines, and operational procedures, to install VS2 Release 2.
• Appendix A: Virtual Storage Map -- This appendix shows the layout of virtual
storage in VS2 Release 2.
• Glossary -- The glossary describes VS2 terms.

Preface

3

The following items are described in this publication strictly for advance
planning purposes and will not be available with the initial release of VS2
Release 2:
• lES] job entry subsystem.
• Virtual telecommunications access method (VT AM).
Additional information about these items will be available later. Availability
dates for the support of the items may be obtained from th{! local IBM branch
offices .
Prerequisite Publication
IBM System/370 Introduction to VS2 Release 2, GC28-0661

This publication describes VS2 Release 2 features and facilities, design
coneepts, and basic hardware requirements.
Related Publications
Introduction to Virtual Storage in System/370, GR20-4260

This publication provides an overview of the advantages and concepts of
virtual storage systems.
IBM Data Processing Glossary, GC20-1699

This publication defines terms and concepts used in IBM publications.
OS/VS Virtual Storage Access Method (V SAM) Planning Guide:, GC26-3799

This publication contains a detailed description of the virtual storage access
method (VSAM).
IBM System/370 OS/VSl Planning and Use Guide, GC24-S090

This publication describes OS/VSl. It can assist installation personnel in
selecting and evaluating VS 1 and can assist system programmers in
implementing, modifying, and extending the capabilities of the VS 1 control
program.
IBM System/370 OS/VS2 Planning and Use Guide, GC28-0600

This publication describes OS/VS2 Release 1. It introduces VS2 concepts and
provides planning information for users planning to have VS2 Release 1
installed.
Introduction to VTAM, GC27-6987

This publication describes the functions and capabilities that an installation
needs to know to plan for installing the virtual telecommunications access
method (VTAM).

4

OS/VS2 Planning Guide for Release 2

Contents

Summary of Amendments

. 9

Introduction . . . . . .
VS2 Release 2 Highlights
Multiprocessing
Job Entry Subsystems.
Data Set Handling . .
System Resources Management
System Activity Measurement Facility
Allocation . . . . . . . . . .
Multiple Virtual Address Spaces
MVS Planning Considerations
Functions Not Supported
Unsupported Type I Programs

11
12
12
12
12
13
13
13
13
14
15
17

Defining the System . . . . . .
System Generation Procedures .
The VS2 Release 2 Starter System
Minimum Configuration . . .
Physical Addresses for Devices
Stage I Macro Instructions
Job Entry Subsystem Generation
JES2 Generation
JES3 Generation
RMTGEN
System Generation Changes
Initializing the New System Data Sets
Adding Installation-Written Members to System Libraries
Unsupported VS2 Release 1 Stage I Macro Instructions
System Initialization. . . . . . . . . . . .
MVS System Parameters . . . . . . . . . . . .
Changes to System Parameters for MVS . . . .
Changes to VS2 Release 1 System Parameters
Unsupported VS2 Release 1 System Parameters
Unsupported MVT System Parameters
System Parameter Specification. . . . .
System Parameter Library (SYS1.PARMLlB)
Changes to SYS I.PARMLIB Lists .
IBM-Created Lists. . . .
Installation-Created Lists. . .
System Libraries and Data Sets. . .
Required Libraries and Data Sets
Optional Libraries and Data Sets
Changes to VS2 Release 1 System Libraries and Data Sets
Changes to MVT System Libraries and Data Sets . . . .
Adding Paging Space to the System . . . . . . . . . .
Creating Temporary Data Sets in External Page Storage Using Virtual I/O

19
20
21
21
21
22
23
24
25
25
26
28
28
29
30
30
36
36
37
38
39
39
40
41
45
47
47
48
49
50
50
51

Directing the Use of System Resources
System Resources Management. . .
Workload Management Routines
Resource-Use Routines . . . . .
Control Function. . . . . . . .
Workload Management Concepts
Transaction. . . . .
Performance Variable
Service. . . . .
Service Rate
System Workload . .
Installation Performance Specification.
Performance Groups. . . . . . . . .
Performance Objectives . . . . . . .
Associating a Transaction With a Performance Objective
The Relationship Between Workload Levels and Service Rates
System Resources Manager Parameters
IPS Parameters (IEAIPSxx) . . . . . . . . . . . . . . . .

53
54
54
54
56
56
57
57
57
57
58
58
58
59
61
61
65
65

Contents

5

Tuning Parameters (IEAOPTxx)
System Activity Measurement Facility (MF /1)
MF /1 Operation . . . . . . . . .
MF/l Reports and Tracing Records
CPU Activity Report
Paging Activity Report. . . . .
Workload Activity Reports . . .
Performance Group Period Report
Performance Group Report
System Summary Report
Channel Activity Report . .
I/O Device Activity Reports
SMF Recording .
Tuning with MF/l .
Tuning Example

67

System Integrity . . . .
Installation Responsibility
Areas of Concern . . . .
User-Supplied Addresses for User Storage Areas
User-Supplied Addresses for Protected Control Blocks
Resource Serialization . . . . . .
Resource Identification . . . . . . . . . .
SVC Routines Calling SVC Routines . . . .
Control Program and User Data Accessibility
Control Program Extensions. . . .
Installation Procedural Responsibilities

79
80
81
81
81
82
83
84
84
85
86

Convers:ion Considerations . . . . . .
Job Entry Subsystem Considerations
The JES2 Job Entry Subsystem
JES2 Job Flow . . . . . .
MVS Operational Changes .
JES2/HASP Compatability .
The JES3 Job Entry Subsystem
JES3 Scheduling Features
Job Definition
JES3 Job Flow . . . . .
Device Scheduling. . . .
Job Selection and Scheduling
JES Operational Environment
The Role of the JES3 Operator
The Operator's Console . .
Initialization, Control Statements, and Commands
JES3/ ASP Compatability . . . . . . . . . . .
SMF Considerations. . . . . . . . . . . . . . . . .
Differences From VS2 Release t System Management Facilities.
Differences From MVT System Management Facilities .
SMF Record Differences for VS2 Release 2
New System Resources Manager Data .
SMF Recording Replaced by MF /1
New Storage Data. . . . . . . . .
Job Entry Subsystem Statistics . . .
MUltiprocessing Data . . . . . . .
Virtual Storage Access Method Data
Time Sharing Record Elimination. .
Changes to SMF Exits for VS2 Release 2
Job Control Language . . . . . . . .
Changes to VS2 Release 1 JCL
Performance Group Specification
Assigning Job Selection Priority
Specifying Data Sets in Paging Space (Virtual I/O Data Sets)
Requesting Data Set Freeing at Data Set Close Time . . . .
Specifying the Number of Resources That May Be Held for Reuse
Requesting Multiple Copies of an Output Data Set . .
Directing the Destination of an Output Data Set . . .
Support for Tape and Direct Access Devices . . . . .
Format Record Identification for the 3886 OCR Device
Output Limit Specification . . . . . . .
lncreased Data Set Definition Capability
lncreased Volume Sharing Capability . .
lnterpretation of the REGION Parameter

6

OS/VS2 Planning Guide for Release 2

68
68
70
70
70
71
71
71
72
72
72
72
73
73

89
90
90
91
93
95
96
98
98
99
lOO
101
102
103
lO3
104
lO4
lO6
lO6
lO6
lO6
109
109
109
110
110
110
llO
llO
t 12
114
114
114
114
115
115
115
115
116
116
116
116
116
116

Job Step Dispatching Priority Default Value . . . .
Cbanges to MVT JCL . . . . . . . . . . . . . . .
Requesting Storage for Program Execution. . . . .
Specifying the BT AM Online Terminal Test Option
JES2 JCL Considerations . . . .
JES2 JCL for non-HASP Users . .
JES2 Control Cards . . . . .
Assigning Job Selection Priority
JES2 JCL for HASP Users . .
/*JOBPARM Control Card
/*OUTPUT Control Card .
JES3 JCL Considerations . . . .
Communication Between Address Spaces
Allocation Considerations . .
Allocation Serialization
Mount Characteristics .
User-Assigned Names .
Device Precedence List
MVS Allocation Philosophy
Reducing Allocation Contention Among Job Steps
Operator Command Language . . .
Changes to Operator Commands
Multiprocessing Support . .
Diagnostic Support
VTAM Support . . . . . .
Time Sharing (TSO) Support
System Resources Management Support
Miscellaneous Support . . . . . . .
Job Entry Subsystem Support. . . .
Time Sharing Considerations. . . . . . .
System Resources Management Support
VSAM Support . . . . . .
Allocation Support . . . . .
Job Entry Subsystem Support
Edit Support. . . . . . . .
Accounting Support
Time Sharing Integration Support
Catalog Support . . . . . .
The VSAM Catalog . . . . . .
VSAM Order of Search
Creating or Updating the VSAM Catalog
Updating an OS Catalog From a VSAM Catalog
Catalog Utility and Macro Changes
OS CVOL Support . . . . . . . . . . .
Defining an OS CVOL for MVS
Accessing CVOL Catalogs . . . . . .
Compatability for OS CVOL Requests.
Data Set Conversion . . . . . . . .
Reformatting the UADS . . . . . . . .
Formatting the Broadcast Data Set
Programming Considerations With Virtual=Real Addresses
Program Conversion
TCAM Conversion. . . . . . . . . .
Multiprocessing Considerations . . . . . .
Hardware Configuration Considerations
Operator Control of Configuration .
Recovery Considerations . . . . .
Alternate Path Retry . . . . .
Dynamic Device Reconfiguration
Alternate CPU Recovery . .
Manual Switching . . . . .
Programmer Considerations . .
Loosely-Coupled Configurations

117
117
117
117
117
117
117
118
118
118
118
119
120
121
121
121
121
122
122
123
124
124
127
127
127
128
128
128
128
134
134
134
134
138
138
138
138
139
140
141
142
143
143
144
144
145
145
146
146
146
146
148
148
149
149
149
150
150
150
151
151
151
152

Appendix A: Virtual Storage Map .

153

Glossary

155

Index

161

Contents

7

Figures

8

Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure

1.
1.
2.
3.
4.
S,.
6.
7.
8.
9.
HI.
11.
12.
13.

Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure

14.
15.
16.
17.
18.
19.
20.
2L
22.
22.
23.
24.
25.
26.
27.
28.
29.
29.
29.
30.
3l.
32.
3,.
33.
3,.
34.
35.
36.
37.

OS/VS2 Planning Guide for Release 2

Unsupported MVT Functions (Part 1 of 2)
15
Unsupported MVT Functions (Part 2 of 2)
16
Unsupported VS2 Release 1 Functions . .
16
Required Device Physical Addresses for the Starter System
22
Generating a VS2 Release 2 System . . . . . . . . . .
24
Changes in Stage I Macro Instructions . . . . . . . . . . . . . . . . . . 27
System Libraries to Which Installation-Written Members May Be Added
29
System Initialization Parameter Summary
31
Changes to SYS1.PARMLIB Lists . . . . . . . . . . .
40
Performance Objective Definition . . . . . . . . . . .
60
Associating a Transaction With a Performance Objective
61
Performance Objectives. . . . . . . . . . . . . . . .
62
63
System Workload Levels . . . . . . . . . . . . . . .
Service Rates for Different Performance Objectives at Various System Workload
Levels . . . . . . . . . . . . .
64
Tuning Example . . . . . . . . . . . .
74
Changing a Performance Objective
75
Effects of a Performance Objective Change
76
JES2 Processing Stages . . . . . . . . .
91
JES2 Differences From MVT HASP and VS2 Release 1 HASP
95
Sample JES3/ ASP Multiprocessing Configuration . . . . .
97
JES3 Job Flow . . . . . . . . . . . . . . . . . . . . .
99
JES3 Differences From MVT ASP and VS2 Release 1 ASP
105
Changes to SMF Records for VS2 Release 2 (Part 1 of 2)
107
Changes to SMF Records for VS2 Release 2 (Part 2 of 2)
108
Changes to SMF Exits for VS2 Release 2 . .
1111
JCL Changes for VS2 Release 2 . . . . . .
1] 3
Features Supported With JES3 Control Cards
1119
Communication Between Address Spaces . .
121
Relationship Between User-Assigned and Generic Names
122
Serialization Characteristics of Suggested Allocation Methods
123
Changes to Operator Commands for VS2 Release 2 (Part 1 of 3)
125
Changes to Operator Commands for VS2 Release 2 (Part 2 of 3)
126
Changes to Operator Commands for VS2 Release 2 (Part 3 of 3)
127
JES2 Command Functions
129
JES3 Command Functions . . . . . . . . . . . . . . . . .
130
JES3 Control Command Functions. . . . . . . . . . . . . .
130
Changes to Time Sharing Commands for VS2 Release 2 (Part 1 of 3)
135
Changes to Time Sharing Commands for VS2 Release 2 (Part 2 of 3)
136
Changes to Time Sharing Commands for VS2 Release 2 (Part 3 of 3)
137
Simplified Catalog Structure - OS vs. VSAM
140
Functions of the Access Method Services .
142
Method of Processing OS CVOL Requests
144
Virtual Storage Map . . . . . . . . . .
153

Summary of Amendments
for GC28-0667-1
VS2 Release 2
Job Entry Subsystem

Catalog Support

The JES2 and JES3 job entry subsystems, generally
compatible with HASP II and ASP Version 3 respectively,
are described with particular reference to compatability to
other systems.

OS control volumes (CVOLs) are supported under VS2
Release 2.

Allocation

The system trace function is now available by command
(TRACE).

Diagnostic Support

Allocation has been redesigned in an attempt to reduce
contention for devices.

V =R Programming Considerations
System Resource Management

Those considerations necessary for running with virtual
addresses equal to real addresses are discussed.

The workload management concepts are defined.

Error Recovery Under Multiprocessing
Virtual I/O
I/O may be performed logically rather than physically, in a
manner transparent to the user.

Manual switching, alternate path retry, dynamic device
reconfiguration, and alternate CPU recovery can occur with
multiprocessing.

Communication Between Address Spaces
The interregion communication of previous systems can
occur with less movement of data.

Summary of Amendments

9

10 OS/VS2 Planning Guide for Release 2

Introduction
OS/VS2 Release 2 (MVS) is a virtual storage operating system with
multiprogramming, multiprocessing, time sharing (TSO), and job entry
subsystems. In addition to providing significant new features, it also enhances
existing OS/MVT and OS/VS2 facilities. OS/VS2 Release 2 is generally upward
compatible with OS/MFT, OS/MVT, OS/VSl and OS/VS2 Release 1.

Introduction

11

VS2 Release 2 Highlights
Some of the significant new features provided in MVS include multiprocessing,
job entry subsystems, new data set handling facilities, a centralized resource
management facility, a system activity measurement facility, a virtual I/O paging
mechanism for temporary data sets, and multiple virtual address spaces. These
are described in the following sections. For a more detailed description of these
features and of the MVS system, see the Introduction to VS2 Release 2.

Multiprocessing
The im~orporation of multiprocessing into the MVS control program provides for
growth to larger and more complex systems. CPU s can be combined in two types
of combinations: loosely coupled or tightly coupled. An installation can use
combinations of loosely coupled and tightly coupled multiprocessing to tailor
configurations to meet individual requirements.
In a tightly coupled multiprocessing system, two CPUs share real storage,
under a single control program, and communicate with each other by
means of an interrupt capability. The system control program treats the CPUs as
resources, assigning them to process tasks. Either JES2 or JES3 can be used to
provide support for tightly-coupled mUltiprocessing.
operatt:~

Loosely coupled multiprocessing systems connect VS2 Release 2 systems by
means of channel to channel adapters that pass information between the
processors. One processor controls job selection for all of the processors in the
system. The JES3 job entry subsystem, a successor of ASP, provides the control
for loosely coupled multiprocessing systems. One or more of the JES3 processors
can, itself, be a tightly coupled mUltiprocessor.

Job Entry Subsystems
JES2 and JES3 provide the job processing functions of:
• Reading local and remote jobs into the system.
• Scheduling jobs.
• Maintaining all data submitted with jobs.
• Supporting the system management facilities.
• Handling all output from batch jobs and time-sharing users.
In addition, JES3 provides:
• Workload sharing by processors within the JES3 complex.
• Network job processing for workload sharing between remote VS2 systems.
• Pre··execution fetch and setup of removable I/O volumes.
• Scheduling based on job-completion deadline.
• Scheduling based on completion deadline.
• Scheduling based on completion of one or more jobs within a related set of
jobs.
Either JES2 or JES3 may be specified during system generation to run as a
component of the system control program.

12

OS/VS2 Planning Guide for Releas{! 2

Data Set Handling
The virtual storage access method (VSAM) is designed to offer function and
flexibility to online and data base environments. In MVS, the key-sequenced
VSAM system catalog structure is designed to reduce access time to very large
catalogs. It permits the use of multiple private catalogs and the master catalog in
one step, job, or session.
Virtual I/O (VIO), is a new way of processing temporary data sets. It is
accomplished on a page basis in virtual storage.
The virtual telecommunications access method (VT AM) is a new
direct-control teleprocessing access method with facilities available to applications
programs, including those using TeAM.

System Resources Management
A new facility, called the system resources manager, is a centralized
decision-maker that monitors a wide range of data about the condition of the
system. It attempts to provide system resources to jobs in a manner specified by
the installation. This allows an installation to specify that certain jobs get better
response time than other jobs.

System Activity Measurement Facility
The system activity measurement facility (MF /1) is both a new and standard
feature in MVS. It collects information about system activities and produces trace
records and reports. MF /1 \s basically system oriented (as opposed to SMF
which is basically job oriented). It is designed to aid in analyzing both system
performance and system trends and in anticipating future system requirements.

Allocation
A new allocation design allows an installation to assign names to subsets of
devices and to define a precedence list for allocating device types. The intent of
the design is to reduce contention for devices (serialization) and allocation time
by tailoring the allocation process.

Multiple Virtual Address Spaces
In VS2, virtual storage is an address range of 16,777,216 bytes. Release 1 of
VS2 provided one virtual address range; jobs were assigned regions from this
address range, just as jobs were assigned regions in real storage in MVT. MVS
provides multiple virtual address spaces; each user (Le., batch job, time-sharing
job, and certain system components) receives its own copy of virtual storage,
minus the space used for certain system functions (e.g., the nucleus, the link pack
area, the system queue area).
The new virtual storage design provides the potential for greater
multiprogramming, including the concurrent execution of more large jobs and a
greater mix of time-sharing and batch jobs. Also, since each job is isolated in a
private address space, inter-region virtual storage fragmentation is eliminated and
protection features are extended.

Introduction

13

MVS Planning Considerations
To make use of some of the new or changed MVS facilities, it will be necessary
to modify some existing procedures, libraries, data sets, and programs. The
following list highlights examples of some of the more significant Release 2
changes that may require modifications to be made by an installation. Neither the
list nor the examples are meant to be exhaustive; rather they call attention to
areas of change that should be considered when planning to install the MVS
system.
The actual details of the changes are described in this publication in
suqceeding chapters.
• While the selection and specification of Stage I system generation options has
been simplified, it is now necessary to select and specify job entry subsystem
options.
• MVS system initialization is designed to enable minimum operator intervention
by extending the options that can be specified in SYS I.P ARMLIlB.
• The system catalog structure is now a VSAM data set that can handle both
VSAM and other data set types. Existing OS system catalogs (SYSCTLGs)
are either supported as CVOLS, or can be converted to the new VSAM
structure.
• The new multi-function access method services are used to convert an OS
system catalog to a VSAM master catalog. Access method services also replace
most of the catalog functions of system utilities such as IEHMOVE, IEHLIST,
IEHPROGM.
• Paging space is contained in VSAM data sets in MVS. At least two page data

sets with the required space must be defined during system generation.
• System resources management routines allow the specification of relative rates

for system resource scheduling for various categories of batch and time sharing
jobs. The installation identifies the categories by assigning each of them a
performance group number to be specified in JCL. The installation specifies
the distribution rates and other tuning options in SYS I.P ARMLIB members.
• The new system activity measurement facility (MF / I) collects and records
information about system activities in either the SMF data set or on formatted
and printed reports. Some SMF data, such as CPU or paging activity is now
recorded only by MF / I on new SMF records.
• System management facilities (SMF) records have been extended to record data

provided by new features such as the system resources manager, the virtual
storage access method, or job entry subsystems. Data reduction routines may
have to be revised to process new records and new or changed record fields.
• Job control language parameters have been added to specify items such as

performance groups. Job entry subsystem control cards may be used to specify
JES2 or JES3 job processing options.
• The operator commands have been extended to support multiprocessing and
changed for communication with the job entry subsystems.
• The installation can name subsets of a generic set of devices in such a manner
as to allow simultaneous allocation within the generic set.

14

OS/VS2 Planning Guide for Release 2

Functions Not Supported
Figure 1 shows significant MVT functions that are not supported in VS2 Release
2. Figure 2 shows unsupported VS2 Release 1 functions.
Unsupported MVT Function

Comparable VS2 Release 2 Function

Automatic SYSIN batching (ASB) reader

Job entry subsystem (JES2 or JES3)

BACKSPACE, NOTE, POINT, XDAP, and EXCP
addressed to SYSIN/SYSOUT DCBs

----

Conversational remote job entry (CRJE)

Time sharing (TSO)

Dedicated work files

Virtual I/O (VIO)

Direct system output (DSO)

----

Graphic job processor (GJP)

----

IEBUPDAT utility program
IEHIOSUP utility program
IEHMOVE, IEHLIST, IEHPROGM

IEBUPDTE utility program

---Access method services

(most catalog functions)
IMBMDMAP

AMBLIST

IMCJQDMP service aid

Job entry subsystem and scheduler work area (SWA) dump routines

IMCOSJQD service aid

----

Main storage hierarchy support

----

OS readers and writers

Job entry subsystem (JES2 or JES3) and the external writer

Queued telecommunications

Telecommunications access

access method (QT AM)

method (TCAM)

QT AM message processing programs

TCAM application programs

Remote job entry (RJE)

JES2 or JES3 remote job entry

Rollout/ rollin

Paging

Satellite graphic job processor (SGJP)

----

Scatter load

Paging

System environment recording

Recovery management

routines (SERO and SER 1)
OS system catalog (SYSCTLG)

support (RMS)
VSAM master catalog with CVOL support

Figure 1. Unsupported MVT Functions (Part 1 of 2)

Introduction

15

Unsupported MVT Function

Comparable VS2 Release 2 Function

SYSl.ACCT data set

System management facilities (SMF) data sets

SYSl.SYSJOBQE

Job entry subsystem input and output queues and the scheduler work
area (SWA)

Tape output for SMF

----

TESTRAN program

--- -

Time slicing

System resources manager

Transient areas

Pageable link pack area

TSO driver

System resources manager

TSO trace

Generalized trace fadlity (GTF)

--

Figure 1. Unsupported MVT Functions (Part 2 of 2)

-Unsupported VS2 Release 1 Function

Comparable VS2 Release 2 Function

BACKSPACE, NOTE, POINT, XDAP, and EXCP

----

addressed to SYSIN/SYSOUT DCBs
Directed swap for TSO

-

---

--

Access methods services

IEHMOVE, IEHLIST, IEHPROGM
(most catalog functions)

Job entry subsystem and SW A dump routines

IMCOSJQD service aid
Nucleus-only SYSGEN

---

-

OS readers and writers

Job entry subsystem and the external writer (JES2 or JES3)

OS system catalog (SYSCTLG)

VSAM master catalog With CVOL support

Priority I/O queueing and ordered seek queueing

----

QT AM message processing programs

TCAM application programs

SYS 1.SYSJOBQE

Job entry subsystem input and output queues and the scheduler work
area (SWA)

Time slicing

System resources manager

TSO driver

System resources manager

----

TSO link pack area

Generalized trace facility (GTF)

TSO trace
Figure 2. Unsupported VS2 Release 1 Functions

16

OS/VS2 Planning Guide for

Releas(~

2

--

Unsupported Type I Programs
The following Type I programs which were supported by MVT and VS2 Release
t are not supported by MVS (i.e., APARs written against these programs
running on MVS will not be accepted). Corresponding program products are
supported in their place. (Contact your local IBM branch office for information
about these program products).
Even though the followlng Type I language compilers are not supported under
MVS, generated object cbde for an installation's programs that use any of these
higher-level Type I languages, together with their corresponding library modules,
will operate on this release of OS/VS2 subject to the constraints outlined in the
"Program Conversion" section of this publication.
Program Name

Program Number

COBOL F
COBOL F Library
Full ANS Cobol V2
Full ANS Cobol V2 Library
FORTRAN G
FORTRAN H
FORTRAN G and H Library
PL/t F
PL/t F Library
PL/ t F Syntax Checker
SORT/MERGE

360S-CB-S24
360S-LM-S2S
360S-CB-S4S
360S-LM-S46
360S-FO-S20
360S-FO-SOO
360S-LM-SOt
360S-NL-Stt
360S-LM-St2
360S-PL-SS2
360S-SM-023

Introduction

17

18

OS/VS2 Planning Guide for Release 2

Defining the System
During system generation and system initialization, the installation can define or
change the operation of a standard or optional feature of the system control
program to meet specific needs. This chapter provides planning information for
defining the system. It is divided into the following sections:
• System Generation Procedures

r-

• System Initialization
• System Libraries and Data Sets

Defining the System

19

System Generation Proced.ures
System generation is the process of selecting data from IBM-distributed libraries
and tailoring it to create an operating system for an installation.
An I/O device-only system generation can also be performed. It is performed
when only 110 devices and channels are to be added, deleted, or modified. The
processor-only generation available with MVT and the nucleus-only generation
available with both MVT and VS2 Release 1 are not available with MVS.
The MVS system generation process is simplified over the MVT and VS2
Release 1 system generation processes in the following ways:
• Many previously optional facilities are now standard. Therefore, fewer macro
instructions and parameters need to be specified.
• Several user-specified macro instructions have been clarified by consolidating
parameters for related options under a single macro instruction.
• Additional system initialization lists are available to be pre:formatted and taken
from the SYSl.PARMLIB data set for use at IPL time.
For MVS, IBM will generate (from installation-provided system generation
statements) and install one system control program per uniprocessing or
multiprocessing configuration. The IBM installation process also includes
performing the installation verification procedure (IVP).
There are six major steps in generating a new operating system.
Planninn
The distribution libraries containing the MVS modules must be ordered from
IBM. The options must be selected that, with the standard features, will
constitute the desired system. The macro instructions needed to specify the
options and standard features of the new system must be selected and coded.
Volume and data set initialization
The direct access volumes that will contain the distribution libraries (and the
starter system) must be initialized. The volumes on which the new system will be
generated must also be initialized. The data sets on the system volumes must be
allocated (unless they will be specified by SYSGEN macros to be assembled in
Stage I for allocation in Stage II).
Stage I
The macro instructions are assembled and expanded into job control languagt!,
utility control statements, assembler language statements, and linkage editor
control statements.
Stage

n

(Jobstream Execution)

The modules from the distribution libraries are assembled~ link-edited, and
copied to the data sets that have been allocated on the new system volume(s).
Job entry subsystem generation
The job entry subsystem modules can be assembled (JES2 only) and
link-edited to reflect the options and limits specified for them. Job entry
subsystem generation may be performed concurrently with Stage II. Additionally,

20

OS/VS2 Planning Guide for Release 2

remote station programs may optionally be generated (RMTGEN). For JES2
(most) and for JES3 (all) these options can be specified during initialization.
Testing

After the new system is generated, the IBM Program Systems Representative
uses the installation verification procedure (IVP) to verify that the new system is
operational on the hardware configuration.

The VS2 Release 2 Starter System
The first time that MVS is generated, the IBM starter system is required to drive
the system generation processing. The starter system consists of an MVS
operating system that uses JES2 as the job entry subsystem. After the first
system generation, either the starter system or the new MVS control program can
be used to drive subsequent system generations.
Minimum Configuration

Use of the starter system requires the following minimum configuration:
• One IBM System/370 Model 145, 15511, 158, 16511, or 168. (The clock
comparator, the CPU timer feature (#2001) and the advanced control program
support feature (#1001) are required on the Model 145.)
• 768K bytes of real storage.
• One multiplexer channel.
• One selector or block multiplexer channel.
• Three IBM 3330 spindles, or four IBM 2314/2319 Direct Access Storage
Facility devices.
• One card reader.
• One hardcopy console or one hardcopy device with a display console.
• One 9-track magnetic tape.
• One 1403 or 3211 printer.
Physical Addresses for Devices

The starter system is configured to support the devices at the addresses specified
in Figure 3.

Defining the System

21

Function

Console

Reader

Punch

Tape

Printer

Direct
Access
Storage
Device

Device

Multiplexer
Channel

Channel 1

Channel 2

158 Console

014,016

3213

015,017

3210/3215

009,01F

3066

040,060
OCO,OOO
OEO,OFO

2540

OOC

20C

3505

012

20A

2540

000

200

3525

013

206

Channel 3

Channel 4

-209,21F
140

240

340

440

..

..

2400 (7-TR-OC)

180, 181

280,281

380,381

480,481

2400 (9-TR)
3400

182, 183
184

282,283
284

3B2,383

482,483

3211

002,004

1403

OOE,OOF

20E

2305-1

1FO

2FO

2305-2

100

200

2314/2319

130, 131
132, 133
134,135

230,231
232,233
234,235

330,331
332,333

3330

150, 151
152, 153

250,251
252,253

350,351
352,353

3330-1

158, 159
15A,156

258,259
25A,256

358,359
35A,356

3340

1CO, 1C1
1C2,1C3

2CO,2C1
2C2,2C3

3CO,3C1
3C2,3C3

Figure 3. Required Device Physical

Address~s

--

".

--

for the Starter System

Stage I Macro Instructions
The Stage I macro instructions are used to tailor the new system. They describe
the machine configuration, the control program, the data management routines,
and the user-written routines. They are also used to specify the program options
that are to be included in the system.
The macro instructions that can be specified in Stage I of MVS are:
AFFINITY
specifies program names (e.g., emulators) and the identification of the CPU on
which each program is required to execute.
CHANNEL
specifies the channel characteristics. A CHANNEL macro instruction is
required for each channel i~ the installation's computing system.

22

OS/VS2 Planning Guide for Release 2

CKPTREST
specifies standard system completion codes not eligible for automatic restart,
and user completion codes that are eligible for automatic restart. If the
CKPTREST macro instruction is not specified, the standard set of codes will
be used.
CONSOLE
specifies the console configuration for the system.
CTRLPROG
specifies control prograI)} options. If the CTRLPROG macro instruction is not
specified, the default values are assumed.
DATAMGT
specifies optional access methods (BT AM, ISAM, GAM, TCAM and VT AM)
to be included in the system.
DATASET
specifies system data sets and the volumes on which they reside. It is required
for each defined data set that is not located on the system residence volume.
It is also used to specify user-written macros, routines, and procedures to be
added to system libraries.
EDIT
specifies the physical characteristics and processing attributes of the data sets
to be processed by the time sharing EDIT command.
GENERATE
specifies the data sets, volumes, and I/O devices required for the SYSGEN
process, the SYSGEN output options, and the type of generation being
performed.
IODEVICE
specifies characteristics of an I/O device and its operating system
requirements. An IODEVICE macro instruction is required for each uniquely
addressable I/O device.
SCHEDULR
specifies job and master scheduler options.
SVCTABLE
specifies the number, type, APF authorization, and entry status of the
user-written SVC routines to be added to the new system.
TSO
specifies the inclusion of IBM -supplied time sharing command processors.
UNITNAME
specifies a name for a group of I/O devices and optionally makes the name
available for VIO use. A UNITNAME macro instruction is required for each
named group of I/O devices in the system, except for unique device types.

Job Entry Subsystem Generation
Job entry subsystems (JES2 or JES3) are added to the system through the
process of job entry subsystem generation, which may be executed concurrently
with Stage II. Figure 4 summarizes the steps that are involved in performing a
job entry subsystem generation and relates them to the steps that are required to
perform a system generation (SYSGEN).

Defining the System

23

Step

SYSGEN

JES2
Generaticm

JES3
Generation

Planning (selecting options)

x

x

Volume and data set initialization

x

x

x

Stage I

x

Stage \I (jobstream execution)

x

x

x

x

x

x

x

Stage \I and JES2 generation
may be executed concurrently.
RMTGEN (optional)
Testing

x

Figure 4., Generating a VS2 Release 2 System

JES2 Generation
The distribution libraries needed to perform a JES2 generation are distributed by
IBM along with the MVS distribution libraries. They contain:
• The JES2 source code.
• The utilities used by the JES2 jobstream.
During JES2 generation, the JES2 control program is assembled to reflect the
options and limits that the installation has chosen. The installation takes the
following steps to perform a JES2 generation.
Planning
The JES2 and optional RMTGEN parameters must be chosen and coded.
VoIUlD4~ and data set initialization
The space required for JES2 data sets must be allocated on the new system
volum{!s.
Jobstrcam Execution
The jobstream on the distribution library must be executed to apply options,
assemble, link-edit, and copy the JES2 modules from the distribution library to
the data sets that have been allocated on the new system volumes. The jobstream
also invokes RMTGEN if any remote terminals were specified by the JES2
generation parameters.
JES2 Generation Options: The following characteristics of the JES2 control
.
program may be specified:
• The maximum number of jobs, started tasks, and time sharing users in the
JES2 subsystem at anyone time.
• The number of card readers, printers, and card punches to be used by the job
control manager.
• The: maxim-qm number of initiators that may be started at anyone time.
• The default limits for a job's printed or punched output and the actions to be
taken when the specified limits are exceeded.

24

OS/VS2 Planning Guide for Release 2

• The type of processing for SYSOUT data sets.
• The number of direct access storage volumes that may be mounted
concurrently as spooling devices.
• Many parameters (or their equivalents) formerly specified only during
HASPGEN, can now be specified during JES2 initialization.
JES3 Generation

The initial release of JES3 is distributed as a separately order able independent
component. It contains:
• A source library containing all JES3 programs and macros.
• An object deck library containing assembled JES3 modules suitable for link
editing.
• A sample program library containing test decks and such procedures as the
method for adding the JES3 ICR to the existing MVS system.
• A sample JES3 initialization deck.
Because JES3 options and limits are selected at initialization time, it is not
necessary to specify them at system generation. RMTGEN parameters must be
coded.
RMTGEN
In addition to generating a job entry subsystem, one or more remote station
programs may also be generated. The process of generating job entry subsystem
multileaving remote terminal programs is called RMTGEN. The parameters used
during RMTGEN specify hardware configuration and software options. Remote
terminal programs that can be generated by RMTGEN include:
• System/360 and System/370 binary synchronous communication (BSC)
remote terminal program.
• System/360 model 20 remote terminal program.
• 1130 remote terminal program.
• 1130 remote terminal program load program.
• System/3 remote terminal program.
Note: Remote terminals can be supported only by 2701 and 2703 emulators on
the 3704 and 3705.
RMTGEN Options: The following remote terminal program characteristics may
be specified:
• The type and degree of text compression.
• The amount of main storage available to the program.
• The number of buffers to be used by the program.
• The inclusion or exclusion of unit record devices.
• The unit address of the BSC adapter and devices.
• The speed of the communication line used.

Defining the System

25

• The number of buffer areas to be used for restoring compressed lines to their
original form.
• The type of assembly listing to be produced during RMTGEN.

System Generation Changes
Some of the major changes to the system generation processes for MVT and VS2
Release 1 include:
• Changes to the process of initializing new system data sets.
• The reduction of the number of macro instructions that need to be specified
during Stage I (see Figure 5). This reduction is due both to the fact that
previously optional facilities are now standard and to the consolidation of
related options under single macro instructions in MVS. For example, it is no
longer necessary to specify two different SYSGEN macro instructions
(RESMODS and LINKLIB) to add installation-written routines to the nucleus
and the link library. The parameters on these macro instructions have been
consolidated under the DATASET macro instruction which is now used to
specify the addition of installation-written routines to any system library. (See
the topic "Adding Installation-Written Members to System Libraries.")
• The addition of a job entry subsystem generation.
• The addition of parameters for specifying authorized appendages.

26

OS/VS2 Planning Guide for Release 2

MVT

--

--

AFFINITY

* **
***

***
***

ASSEMBLR
CENPROCS
CHANNEL

CENPROCS
CHANNEL

***

***

--

CHANNEL

***

***

CKPTREST
DATASET

CKPTREST
DATASET

COBLIB
COBOL
CTRLPROG

***
***

***
***

CTRLPROG

CTRLPROG

DATAMGT
DCMLlB
EDIT

DATAMGT
DATASET
EDIT

DATAMGT
DATASET
EDIT

EDITOR
EMULATOR
FORTLIB

EDITOR

FORTRAN
GENERATE
GENTSO
GJOBCTL
GRAPHICS
HELP

-***

--***

***

***

GENERATE

GENERATE

---

GRAPHICS
DATASET

---

DATAMGT
DATASET

IMAGELIB
IOCONTRL
IODEVICE

--

--

L1NKLIB
LOADER
MACLIB

L1NKLIB
LOADER
MACLIB

DATASET
DATASET

OUTPUT
PARMLIB
PL1

TSO
PARMLIB

TSO
DATASET

***

***

PL1 LIB
PROCLIB
PTOP

***

***

DATASET

DATASET

RESMODS
RPG
SCHEDULR

***

VS2 Release 2

ALGLlB
ALGOL

CHECKER
CKPTREST
CMDLlB

--

VS2 Release 1

DATASET
IODEVICE

DATASET
IODEVICE

--

***

***

RESMODS

DATASET

***

** *

SCHEDULR

SCHEDULR

SECMODS
SECONSLE
SORTLIB

CENPROCS
SECONSLE

CONSOLE

***

***

SORTMERG
SUPRVSOR
SVCLlB

***

***

DATASET

DATASET

SVCTABLE
SYSUTILS
TELCMLlB

SVCTABLE

SVCTABLE

--

---

** *

***

DATASET

DATASET

TSOPTION
UCS
UNITNAME

TSO
UCS
UNITNAME

TSO

--

PAGE

DATASET

--

UNITNAME

no longer specified during system generation
the function specified by this macro instruction may be added to the system
after system generation

Figure 5. Changes in Stage I Macro Instructions
Defining the System

27

Initializing the New System Data

St~ts

New system data sets must be initialized before Stage II is executed. Initialization
includes:
• allocating space for system data sets on the new system volumes.
• building the volume index of the system catalog.
• cataloging the data sets in the new system catalog.
In MVS, the new system data sets can be initialized either during system
generation by using the DATASET macro instruction or at any other time before
Stage II by using the access method services.
The Stage I DATASET macro instruction did not exist in MFT or MVT. Its
use for initializing new system data sets during SYSGEN remains unchanged
from VSl Release 1 and VS2 Release 1. A DATASET macro instruction is
specifi{~d with the SPACE parameter in the Stage I input deck for every system
data set that is to be allocated. The new system data sets are then allocated and
cataloged during Stage II execution.
In MVS, the IEHPROGM utility program can be used to catalog only
non-VSAM data sets without CVOL pointers. In order to preallocate all new
system data sets (VSAM and non-VSAM data sets) the access method services
should be used. In this case a DATASET macro instruction should be specified
without the SPACE parameter for any system data set used during system
generation that is not on the system residence volume. This enables the catalog
entry to be created during Stage II.
Adding Installation-Written Members to System Libraries
The DATASET macro instruction is used during SYSGEN to include
installation-written members in system libraries. The parameters:
PDS=SYS1.name
MEMBERS=(name, name ... )

are functionally equivalent to their counterparts on the RESMODS and LINKLIB
SYSGEN macro instructions in MVT and VS2 Release 1. A new feature is
provided for adding installation-written routines to the nucleus, however. If only
the PDS parameter is specified, the members in the data set specified by PDS
will be copied into the nucleus as individual members. If both the PDS and
MEMBERS parameters are specified, the members in the data set specified by
PDS will be copied into the nucleus and link-edited together with the nucleus
member IEANUCOl. Figure 6 indicates the system libraries to which
installation-written members may be added and the form in which they must be
added.

28

OS/VS2 Planning Guide f or

Relea~.e

2

System Library

Form

SYSl.CMDLIB
SYS l.IMAGELIB
SYS 1.LINKLIB

load module
load module
load module

SYS I.LPALIB
SYS 1.MACLIB
SYSl.NUCLEUS

load module
system macro
load module

SYS I.PARMLIB
SYS 1. PROCLIB
SYS 1. TELCMLIB

system parameter
system procedure
load module

SYS 1. VT AMLIB
SYS 1. VT AMLST

load module
, system parameter

Figure 6. System Libraries to which InstaUation-Written Members May Be Added

Unsupported VS2 Release 1 Stage I Macro Instructions
The following VS2 Release 1 macro instructions are not supported in MVS.
CENPROCS
Model dependent information is no longer needed during system generation
processing.
EDITOR
All functions provided by this macro instruction are available in
SYS 1.PROCLIB cataloged procedures.
GRAPHICS
The DAT AMGT macro instruction now performs the function.
LINKLIB
The DATASET macro instruction now performs the function.
LOADER
Options specified by this macro instruction are now available in
SYS 1.PROCLIB cataloged procedures.
MACLIB
The DATASET macro instruction now performs the function.
PAGE
The DATASET macro instruction now performs the function.
PARMLIB
The DATASET macro instruction now performs the function.
RESMODS
The DATASET macro instruction now performs the function.
SECONSLE
The CONSOLE macro instruction now performs the function.
UCS
The options specified by this macro instruction are standard in the MVS
system.

Defining the System

29

System Initialization
Before any job can be processed, the control program and its associated control
blocks and work areas must be loaded into storage and prepared for operation.
Loading these control program modules is the function of the initial program
loader (IPL).
After the IPL program completes its loading functions, control passes to the
nucleus initialization program (NIP), which performs more functions necessary
for the operation of the control program. (For example, NIP defines storage
areas and initializes certain tables, work areas, and control blocks.) NIP also
loads and initializes routines (such as fixed LPA routines) selected by the user.
The nucleus initialization program also initializes real storage. It gives the
installation control over virtual storage definition by processing
installation-supplied system parameters that specify virtual storage options.
Master scheduler initialization completes the initialization process by
establishing system tasks such as the console communications task, the log task,
job entry subsystems, system management facilities, the recovery/termination
management task and the missing interruption checker task.
In MVS, changes have been made to the system initialization process to
provide the installation with greater flexibility in specifying system options as well
as the opportunity to simplify the IPL process. These changes include:
• The reduction of informational IPL messages.
• The elimination of the time-of-day (TOD) clock messages and associate,d
replies, unless the installation requests that they be issued or unless there is :an
error in TOD clock processing.
• The implementation of mUltiple SYS I.P ARMLIB members for SMF, volume
attributes, commands, and the link library.
• The creation of a SYS l.P ARMLIB member that contains installation-specified
operator commands that are issued by the system control program at the
completion of system initialization processing. The operator need respond only
in case of error conditions.

MVS System Parameters
The installation uses system parameters to control the system initialization
process. System parameters may be specified through the master console or in
the IEASYSxx lists in the system parameter library, SYS I.PARMLIB. Each
parameter in a SYSl.PARMLIB list is specified in the same format as that
required by the "SPECIFY SYSTEM PARAMETERS" message. Figure 7
provides a summary of these parameters. More detailed descriptions of the
parameters follow.

30

OS/VS2 Planning Guide for Release 2

Parameter

SYS1.PARMLIB
List
Read

Value Specified

APF

Authorized library name

@

APG

Automatic priority group for system resources manager

•

BLDL

Pageable directory for SYS1.LlNKLIB

BLDLF

Nonpageable directory for SYS1.LlNKLIB

CLPA

New link pack area to be created

IEABLDxx

•
•

IEABLDxx
IEALODOO
IEAPAKOO

CMD

Command to be issued internally

@

CSA

Size of the common service area

@

CVIO

Delete all VIO data sets from paging space

@

DUMP

Data sets for SYS1.DUMP

FIX

Reenterable routines for nonpageable LPA

HARDCPY

Hard copy log

IPS

I nstallation performance specification

@

IEAIPSxx

LNK

Names of data sets concatenated to SYS1.LlNKLIB

@

LNKLSTxx

LOGCLS

Output class for log data set

@

LOGLMT

WTL limit for log data set

@

MAXUSER

Maximum number of virtual address spaces

@

MLPA

Modifications to pageable LPA

NUCMAP

New nucleus map for DSS

OPI

SYS1.PARMLIB operator intervention restrictions

•

OPT

System resources manager tuning parameters

@

PAGE

Page data set names

•
•

REAL

V = R address area size

SMF

SM F parameters

SQA

Size of the system queue area

SYSP

•

•

COMMNDxx

IEAFIXxx

IEALPAxx

@

IEAOPTxx

@

SMFPRMxx

System parameter list to be merged with I EASYSOO

•

IEASYSxx

VAL

Volume characteristics

@

VATLSTxx

VRREGN

Default region size for a V= R request

@

WTOBFRS

Number of buffers for WTO routine use

@

WTORPLY

Number of operator reply elements for WTOR routine use

@

• -@

IEAAPFxx

Not Included in MVT Systems

-- Not Included in VS2 Release 1 Systems and MVT Systems

Figure 7. MVS System lnitiaUzation Parameter Summary

Defining the System

31

APF
specifies the value that is appended to IEAAPF to form the name of the
SYS l.P ARMLIB list that contains data set names with their corresponding
volume identifications of authorized program libraries.
The SYS l.LINKLIB and SYS l.SVCLIB libraries are automatically included as
authorized libraries.

APG
specifies an automatic priority group for use by the system resource
management routines. If the APG parameter is not specified, a default value
of 7 will be used.
BLDL
speeifies a value that is appended to IEABLD to form the name of a
SYS l.P ARMLIB list that contains the names of modules for which entries are
to be built in the pageable BLDL table.
The directory created in response to the BLDL parameter will reside in
page able storage.
If the BLDL and BLDLF parameters are both specified, the BLDL parameter

will be ignored. A warning message will be issued to identify this condition.
The IEABLDOO list is the default list.

BLDLF
specifies a value that is appended to IEABLD to form the name of a
SYS l.P ARMLIB list that contains the names of modules for which entries are
to be built in the resident BLDL table.
Thl~

directory created in response to the BLDLF parameter will reside in fixed
storage.

specified~ the BLDLF
parameter will be accepted. A warning message will be issued to identify this
condition.

If the BLDLF and BLDL parameters are both

The IEABLDOO list is the default list.

CLPA
specifies that a new pageable link pack area is to be created.
If a previously created link pack area exists, it is deleted and the space it

oceupied is made available for system paging use.
If CLP A is specified, CVIO is automatically specified.

CMD
specifies a value that is appended to COMMND to form the name of the
SYS l.PARMLIB list that contains the commands that the installation selects
to be issued internally as soon as the system initialization process is complete.
If not specified in a system parameter list of by the operator, the

COMMNDOO list is used.
CSA
specifies the common service area.
The value specifies the size, in lK byte

m~ltiples,

of the common service area.

If CSA is not specified, the default value of lOOK bytes is used.

32

OS/VS2 Planning Guide for Release 2

CVIO
for system restart, specifies that all virtual I/O (VIO) data sets are to be
deleted from the paging space.
CVIO is automatic if CLP A is specified.
DUMP
specifies tape volumes and/or the direct access storage devices to be used for
the SYS 1.DUMP data sets.
FIX
specifies a value that is appended to IEAFIX to form the name of the
SYS 1.P ARMLIB list that contains the names of reenter able routines from the
SYS1.LINKLIB, SYS1.LPALIB, and SYS1.SVCLIB data sets to be made
resident as a fixed extension to the link pack area (fixed link pack area).
If not specified, a fixed link pack area is not created.

HARDCPY
specifies that the hard copy log is desired, whether or not the system log is to
be used as the hardcopy log, and whether or not messages are to be recorded
on the hardcopy log.
If the console configuration contains an active graphic console or more than

one active console, a hardcopy log is required. In this case, if routing codes
1,2,3,4,7,8,or 10 are desired, they need not be specified since all of these
codes are automatically assigned by the system control program.
IPS
specifies a value that is appended to IEAIPS to form the name of the
SYS 1.P ARMLIB member that contains the installation performance
specification (IPS).
The IEAIPSOO is the default list.
LNK
specifies a value that is appended to LNKLST to form the name of the
SYS 1.PARMLIB list that contains the names of the data sets to be
concatenated to SYS 1.LINKLIB.
Any number of SYS 1.P ARMLIB lists may be specified in this manner until
the number of data sets contained reaches 15. (The maximum number of data
set names other than SYS 1.LINKLIB is 15. This allows 16 data sets including
SYS1.LINKLIB to be concatenated.) SYS1.LINKLIB is opened first. Then
each data set that is specified is opened and concatenated in the order in
which it appears (Le., left to right).
The LNKLSTOO list is the default list.
LOGCLS
specifies the JES2 output class for the log data sets.
If the LOGCLS parameter is not specified, a default class of A is used.

LOGLMT
specifies the number of write-to-Iog (WTL) instructions that may be issued
before the log data set is scheduled for output processing.
If the LOGLMT parameter is not specified, a default value of 500 WTL

instructions is used.

Defining the System

33

MAXUSER
spedfies the maximum number of independent virtual address spaces available
for use by the operating system.
If the MAXUSER parameter is not specified, a default value of 256 is used.

The maximum number that may be specified is 1,536 minus the number of
active VIO data sets.
MLPA
speeifies a value that is appended to IE ALP A to form the name of the
SYS 1.P ARMLIB list that contains the reenterable routines from
SYSl.LINKLIB, SYSl.LPALIB, and SYSl.SVCLIB data sets to be made
resident as a pageable extension to the link pack area (modified link pack
area).
If the MLP A parameter is not specified, a modified link pack area is not

created.
NUCMAP
specifies the creation of a new map of the nucleus in the SYS 1.DSSVM data
set and the deletion of the existing nucleus map.
The parameter must be specified if the nucleus for which a map exists is
modified and an IPL is performed using the modified nucleus. The NUCMAP
parameter need not be specified again until another modification is made to
the nucleus.
A new nucleus map will be created without the specification of the NUCMAP
parameter, if the name of the nucleus load module changes between IPL
procedures or if a nucleus map does not exist for the first IPL after system
generation.
OPI
specifies operator intervention restrictions of the system parameters in the
SYS 1.P ARMLIB lists.
The OPI parameter can only be included in SYS 1.P ARMLIB lists. It may be
specified for individual system parameters or for the entire set of system
parameters.
OPT
sp(;:cifies a value that is appended to IEAOPT to form the name of the
SYSl.PARMLIB list that contains tuning parameters for the system resources
management routines.
If not specified in a system parameter list or by the operator, default values

provided by the system resources management routines are used.
PAGE
specifies one or more page data set names to be used for a particular system
IPL, in addition to the page data set names in the PAGE parameter
specification of P ARM LIB members IEASYSOO or IEASYSxx. The first data
set name is used to contain as much of the PLP A as space permits.
The values specified include identification of the VSAM data sets for which
space was previously allocated and formatted (and, optionally, the unit on
which the volume containing the specified data sets should reside).

34

OS/VS2 Planning Guide for Release 2

REAL
specifies nonpageable storage (virtual equals real address area).
The value specified is the number of IK byte blocks to be reserved for
nonpageable (V =R) storage.
If the value specified is 0, there will be no V =R storage in the system.
If the REAL parameter is not specified, a default of 76K will be used.

SMF
specifies a value that is appended to SMFPRM to form the name of the
SYS I.P ARMLIB list that contains system management facility (SMF) values.
If not specified in a system parameter list or by the operator, the SMFPRMOO
list is used.

SQA
specifies the system queue area.
The value specified is the number of 64K byte segments to be added to the
minimum size of the system queue area.
If not specified in a system parameter list or by the operator, a default value
of one (64K byte segment) is added to the minimum size of the system queue
area.
If the specified amount of virtual storage is not available, a warning message
will be issued. The SQA parameter may be respecified at that time.

The size of the system queue area cannot be changed during a restart that
reuses the previously initialized link pack area. If the SQA parameter is
specified on the restart and the size is different, the system uses the previous
size and issues a warning message.
SYSP
specifies' the SYS l.P ARMLIB list of system parameters that is to be merged
with the default list of system parameters, IEASYSOO.
The value specified is appended to IEASYS to form the name of a
SYS I.P ARMLIB list that contains the system parameters to be used for the
current IPL. Any number of IEASYSxx lists may be specified.
If not modified by this parameter, only the IEASYSOO list is used. The
IEASYSOO list contains the values selected during system generation for
various system parameters unless the contents of the list have been modified
by the system programmer at the installation.

When multiple IEASYSxx lists are specified by the SYSP parameter, they are
treated in ascending priority sequence (Le.,parameters defined in a member
specified near the beginning of the list will be replaced by the same
parameters defined in a member specified near the end of the list). In the
process of merging parameters with the IEASYSOO list, IEASYSOO is always
read, and always assumes the lowest priority.

Defining the System

35

For I!xample, if the operator responds:
R 00, 'SYSP=( 01 ,02 ) ,

and these two IEASYSxx lists contain the following system parameters:
IEASYSOl:

MLPA=( 00,01 ) , BLDL=OO

IEASYS02:

MLPA=02, SQA=1 0

then the effective system parameters will be:
MLPA=02, BLDL=OO, and SQA=1 0

VAL
specifies a value that is appended to V ATLST to form the name of the
SYS l.P ARMLIB list that contains mount and allocation characteristics for any
or aU of the direct access volumes used by the installation.
If not specified in a system parameter list or by the operator, the V ATLSTOO

list is used.
VRREGN
specifies nonpageable storage (virtual equals real address area) for a specific
job.
The value specified becomes the default value for the real main storage size
(in lK multipltes) to be allocated to a job requiring V =R address space.
If the VRREGN parameter is not specified, a default value of 64K is used.

The VRREGN system parameter should not be confused with the REAL
system parameter. REAL specifies the total amount of nonpageable (V =R)
storage available to the system. VRREGN specifies the subset of the total
spaee that is available for an individual job.
WTOBFRS
speeifies WTO buffers.
The: value specifies the number of buffers to be used by the write-to-operator
(WTO) routines.
If the WTOBFRS parameter is not specified, a default value of 20 is used.

WTORPLY
specifies WTOR elements.
The value specifies the number of operator reply elements to be used by the
write-to-operator-with-reply (WTOR) routines.
If the WTORPLY parameter is not specified, a default value of 5 is used.

Changes to System Parameters for MVS
Figure 7 shows new system parameters for MVS. Some VS2 Release 1 and some
MVT system parameters are not supported. Of these, some have been replaced
by new parameters and others have been eliminated, either because their
functions are not supported in MVS or because their functions are now
performed by the system control program.
Chan~:es to VS2 Release 1 System Parameters: The following VS2 Release 1
system parameters have changed for MVS.

36

OS/VS2 Planning Guide for Relea!ie 2

APG
The only value that can be specified for the APG parameter in MVS is the
priority of the automatic priority group.
DUMP
Ten SYS I.DUMP data sets can be specified in MVS.
PAGE
Values specified by the PAGE parameter have changed for MVS because
paging space is made up of preformatted VSAM data sets, two of which must
be defined and formatted during system generation, (See the topic "Adding
Paging Space to the System" in this chapter.) The PAGE parameter also no
longer specifies a particular volume to contain the link pack area.
REAL
In MVS, the value specified by the REAL parameter represents the total
amount of V=R storage in lK byte multiples, as opposed to the number of
4K byte blocks added to a 64K byte minimum value in VS2 Release 1.
Unsupported VS2 Release 1 System Parameters: The following VS2 Release 1
system parameters are not supported in MVS but are provided for by comparable
functions.
LSQACEL
This parameter is not needed in MVS because quickcells for the local system
queue area are controlled by virtual storage management routines.
PAL
The values specified by this parameter are supplied by the address space
supervision routines in MVS.
SQACEL
This parameter is not needed because quickcells for the system queue area are
controlled by virtual storage management routines.
TMSL
This parameter is not needed because the system resources management
routines determine the acceptable time slices.
The following VS2 Release 1 system parameters are not supported in MVS
and have no comparable MVS functions.
AUXLIST
This parameter is not needed because in MVS it is not meaningful to
distinguish between the auxiliary storage available for background and
time-sharing jobs.
CPQE
The number of channel programs to be used by the address space supervision
routines is no longer an installation option.
MPA
It is not necessary to specify the size of the master scheduler region because
in MVS, the master scheduler task has its own independent virtual address
space.
TSOAUX
It is not necessary to specify back-up auxiliary storage space for time sharing
jobs in MVS, because each time sharing user is assigned to an individual
virtual address space.

Defming the System

37

Unsupported MVT System Parameters: The following MVT system parameters
are not supported in MVS, but are provided for by comparable MVS functions.
MIN
This parameter is not needed in VS2 because the initiator modules are
contained in the pageable link pack area.
MOD
The CPU model identification is determined in VS2 by the STIDP instruction.
RAM
Routines from SYSl.SVCLIB and SYSl.LINKLIB can be: added to the VS2
link pack area by means of the SYS l.LP ALIB data set 01' the MLP A or FIX
system parameters.
RERP
In VS2, error recovery procedure (ERP) routines are always resident in the
link pack area.
RSVC
In VS2, SVC routines are always resident in the link pack area.
SQS
This parameter is replaced by the SQA system parameter .
TMSL
This parameter is not needed because the system resource management
routines determine the acceptable time slices.
The following MVT system parameters are not supported in VS2 Release 2
and have no comparable MVS functions.
ALTSYS
This parameter is not needed because the system residence devices are t.reated
by dynamic device reconfiguration (DDR) as any other swappable device.
HRAM
Mvr hierarchy support is not needed in VS2.
HSVC
MVT hierarchy support is not needed in VS2.
MPS
It is not necessary to specify the size of the master scheduler region because

in MVS, the master shceduler task has its own independent virtual address
space.
QBF
This parameter is not needed in MVS because the job queue is replaced by the
scheduler work area (SW A) and job entry subsystem data sets.
System Parameter Specification
An installation can tailor a system through the specification of system
parameters, either during system generation (SYSGEN) processing or in the
IEASYSOO or IEASYSxx lists of SYS l.P ARMLIB. The system operator specifies

38

OS!VS2 Planning Guide for Releast! 2

system parameters through the master console in response to the "SPECIFY
SYSTEM PARAMETERS II message. Proper use of IEASYSOO or IEASYSxx can
result in a significant saving of time.
The IEASYSOO (system parameter) list is always created during the SYSGEN
process, and the system parameters HARDCPY, PAGE and either BLDL or
BLDLF are included in it. The installation may also specify that the system
parameters CSA, REAL, SQA, VRREGN, APF=OO, and FIX=Ol should be
included in the IEASYSOO list during SYSGEN processing.
The remainder of the system parameters are specified in two ways:
• By using a system utility program to ad,d them to the IEASYSOO or any
IEASYSxx list.
• By entering them through the operator's console.
The IEASYSOO list is read for every IPL. The installation is not only able to
add parameters to this list, but may change parameter values that were included
in it during SYSGEN processing. Operator interaction will be minimized during
system initialization processing if the installation ensures that the IEASYSOO list
contains all of the system parameters required to establish the desired operating
environment. The system operator will then be able to respond to the I I SPECIFY
SYSTEM PARAMETERS" message with end-of-block (EOB), and will not be
required to respond further unless error conditions are detected and prompting
occurs.
The IEASYSOO member should generally contain installation default values, or
parameters for which values can be defined that do not change from IPL to IPL.
The IEASYSxx members, on the other hand, should be used to contain
parameters that are subject to change from IPL to IPL, depending on the user
applications. (See the SYSP parameter description for additional information.)

System Parameter Library (SYSl.PARMLIB)
The SYSl.PARMLIB data set contains both IBM-created and installation-created
lists of parameter values. The formats for the lists have been revised from MVT
to allow better space utilization within parameter records, and to afford more
flexibility in their definition. All MVT and VS2 Release 1 parameter lists that are
still valid lists in MVS need not have their formats changed.

Defining the System

39

Changes to SYS I.PARMLIB Lists

Figure B shows the new or changed MVS SYS l.P ARMLIB lists.
List

Change from MVT

Change from VS2 Release 1

COMMNDxx
IEAABDOO
IEAAPFxx

New
New
New

New
New
New

IEAAPPOO
IEABLDxx
IEADMPOO

New
New
New

New
None
New

IEAFlXxx
IEAIGEOO
IEAIGGOO
IEAIPSxx
IEALODOO

New
No longer supported
No longer supported
New
New

None
No longer supported
No longer supported
New
None

IEALPAxx
IEAOPTxx
IEAPAKOO
IEARSVOO

New
New
New
No longer supported

None
New
None
No longer supported

IEASYSxx
IKJPRMOO
IQAORDER
IRBMFlxx

New
Now only TIOe parameters
Not applicable
New

None
Now only TIOe parameters
No longer supported
New

LNKLSTxx
PARMTZ
SMFPRMxx

No longer a single member
New
No longer a single
member named SMFDEFLT
No longer a single
member named PRESRES

No longer a single member
None
No longer a single
member named SMFDEFLT
No longer a single
member named PRESRES

VATLSTxx

Figure 8. MVS Changes to SYS1.PARMLIB Lists

40

OS/VS2 Planning Guide for ReleaSE! 2

IBM-Created Lists

The IBM-created lists that are named in column 1 are standard in
SYS l.PARMLIB for MVS.
Standard List

Alternate List

Address of areas to be dumped by SYSABEND

IEAABDOO
IEABLDOO

IEABLDxx

Names of SYSt.LINKLIB load modules whose
directory entries are to made in the BLDL table
Addresses of areas to be dumped by SYSUDUMP

IEADMPOO
IEAIPSOO

Contents

IEAIPSxx

Installation performance specification

IEALODOO

Names of SYS1.LPALIB modules whose directory
control block information is to be maintained in
nonpageable storage

IEAPAKOO

Groups of names of SYS1.LPALIB modules that
are to be packed together in the link pack area

IEASYSOO

IEASYSxx

Lists of system parameters

LNKLSTOO

LNKLSTxx

Names of additional data sets that may be
concatenated with SYS t .LINKLIB data sets

SMFPRMOO

SMFPRMxx

SMF parameters

The following lists are optionally created during the system generation process
if specified by the installation.
Standard List

Alternate List

Contents

IEAAPFOO

IEAAPFxx

Names of authorized libraries

IEAAPPOO
IEAFIXOI

Names of installation-written EXCP appendages
IEAFIXxx

Names of SYS1.SVCLIB, SYS1.LPALIB, and
SYSl.LINKLIB modules that are to be made
resident as a nonpageable extension to the link
pack area

Of the IBM-created lists, multiple lists can be created and maintained for
those that have alternate names. These lists may therefore be respecified by the
installation to continue the system tailoring begun with system generation
processing. The desired list may then be selected from the multiple lists by
system parameters specified from the operator's console or in the IEASYSOO or
IEASYSxx lists.
Authorized Appendage List (IEAAPPOO)

This list contains the names of installation-written I/O appendage routines and a
description of the function of each routine. Any 110 appendage that is to be
used by an unauthorized routine must be named in the IEAAPPOO member of
SYS l.P ARMLIB. (Authorized routines are able to use any installation-written
I/O appendage.) This system integrity requirement prevents unauthorized
routines from incorrectly using I/O appendages. To restrict an I/O appendage to
use by authorized programs, omit it from this list.
It is not necessary to include the names of control program (e.g., system
access methods) appendages in an authorized appendage list.

Defining the System

41

If the installation chooses to specify the creation of IEAA1PPOO during system
generation, appendage names may be entered, even if the appendages have not
yet been written. This capability allows the installation to "pIime" the list with
the names of appendages that will be added to the system later.

See the chapter "System Integrity" for a description of authorized and
unauthorized routines.
Authoril:ed Program Library List (IEAAPFxx)

This list contains the data set names and corresponding volume indentifications
for libraries that may contain programs requiring APF authorization.
The ability for installation-specified libraries to contain APF-authorized
programs extends the VS2 Release 1 APF support that allowed authorized
programs to reside only in SYSl.LINKLIB, SYSl.SVCLIB, and SYSl.LPALIB.
The specification of additional libraries for authorized programs in the
IEAAPFOO or IEAAPFxx list in MVS eliminates the need to concatenate
libraries containing programs requiring APF-authorization.
It is not necessary to include SYSl.LINKLIB or SYSl.SVCLIB in an
authorized program library list.

Dump Default Lists (IEAABDOO and IEADMPOO)

The dump default lists, IEAABDOO and IEADMPOO, contain the IBM-supplied
defaults for the storage areas to be dumped to the data sets defined by
SYSABEND and SYSUDUMP DD statements, respectively. The installation may
change the defaults in these lists to satisfy individual requirements. Some of the
defaults that may be specified include the system queue area, the local system
queue area, the scheduler work area for the task, the task's control blocks, the
GTF or supervisor trace table, the PSW at entry to ABEND, general register
contents at entry to ABEND, the contents of the task's link pack area, the
contents of the task's job pack area.
Fixed LPA List (IEAFIXxx)

The fixed LP A list indicates those modules from SYS 1.SVCLIB, SYS 1.LP ALIB,
and/ or SYS 1.LINKLIB that should be included in the nonpageable extension to
the link pack area. The list should contain modules that significantly increase
system performance when they are fixed rather than paged.
The fixed LP A list is created during system generation processing, if so
specified by the installation.
Installation Performance Specification (IEAIPSxx)

The installation performance specification (IPS) consists of control information
used by the workload management routines that are part of the system resources
management routines. It includes performance group definitions, performance
objectives, and service definition coefficients that are used to establish service
rates.
For a more detailed description of the contents of the IPS, see the chapter:
"Directing the Use of System Resources".

42

OS/VS2 Planning Guide for Release 2

Link Library List (LNKLSTxx)
The link library list enables concatenating up to 15 data sets, on multiple
volumes, with SYS 1.LINKLIB. It is generated during the system generation
process but may be modified via the IEBUPDTE utility program. Each data set
that is concatenated with SYSl.LINKLIB may have up to 16 extents. (Note:
After additions or changes are made that extend data sets concatenated with
SYSl.LINKLIB, the system should be re-IPLed to update the description of
SYSl.LINKLIB to the system.)
In MVS, multiple link library lists may be maintained in SYS 1.PARMLIB. The
list to be used is selected at IPL time by the LNK system parameter.
LPA Directory Load List (IEALODOO)
The link pack area (LP A) directory load list indicates those modules residing on
SYS 1.LPALIB or in the pageable LP A that are to have the contents supervision
directory control block information initialized by NIP in nonpageable storage.
When this list is used, contents supervision routines do not have to search to find
the module in the LPA directory. The number of page faults that may occur is
therefore reduced. Candidates for this list are modules that are frequently used.
LPA Packing List (IEAPAKOO)
The link pack area (LP A) packing list contains the names of modules residing on
the SYS 1.LPALIB data set that may be grouped together by packing the LP A.
Grouping these modules may sharply reduce page faults as well as eliminate
wasted space within the LP A.
Modules that frequently pass control to one another should be grouped
together to reduce page faults.
The total size of all modules in a group should not exceed 4K (page size).
The proper loading of modules into the LP A is done at NIP time, based upon
the data in IEAPAKOO. Modules that are not listed in IEAPAKOO are then
loaded into the LP A in the order that they appear in the SYS 1.LP ALIB
directory.
There are no alternate lists for IEAPAKOO. If IEAPAKOO is not found as a
member of SYS 1.PARMLIB, the modules will be loaded in the order that they
appear in the SYS 1.LPALIB directory.
Resident BLDL List (IEABLDxx)
The resident BLDL list specifies the names of modules from SYS 1.LINKLIB, or
any data set concatenated to SYS1.LINKLIB, that are to have directory entries
built by NIP. This eliminates the directory search required when a load module is
requested from SYS 1.LINKLIB.
The directory will reside either in the fixed or pageable area of the system,
depending upon whether the BLDLF or BLDL reply is specified by the operator
in response to the "SPECIFY SYSTEM PARAMETERS" message. The BLDL
and BLDLF parameters are mutually exclusive.
The member name for the standard list is IEABLDOO. The load module names
must be listed in the same order as they appear in the directory; that is, they
must appear in ascending collating sequence. (Note: Directory entries in the
resident BLDL table are not updated as a result of updating the load module in

Defining the System

43

the library. The old version of the load module is used untH an IPL process
updates the resident BLDL table.)
The IEABLDOO list indicated by BLDL=OO or BLDLF ==00 is created during
system generation processing. The list will be null if no entries are specified for it
at SYSGEN.
If specified during system generation and not modified through operator
communication or a list of system parameters (IEASYSxx) the default
IEABLDOO is used.

SMF Parameter List (SMFPRMxx)
The SMF parameter list contains the parameters that control SMF operations.
Multiple SMF parameter lists may be maintained in SYS l.P'ARMLIB. The list to
be used is selected at IPL time by the SMF system parameter.
The single SYS l.P ARMLIB member (SMFDEFLT) supplied by IBM in MVT
and VS2 Release 1 is not valid. In MVS, the IBM-supplied SYSl.PARMLIB
member that contains the default SMF parameters is called SMFPRMOO. The
format of the SMFPRMOO and SMFPRMxx lists is different from the MVT and
VS2 Release 1 SMFDEFLT list.
The ALT and PRM keywords are not supported because the SMF data sets,
SYSl.MANX and SYSl.MANY must be cataloged in MVS.
The MDL keyword has also been deleted.
The .SID keyword has been expanded to allow the specification of a
System/370 model number.
System Parameter List (lEASYSxx)
The system parameter list may include all system parameters that are valid input
to the "SPECIFY SYSTEM PARAMETERS" message. The standard list,
IEASYSOO, is created during Stage II of the system generation process. This
param,eter list enables an installation to specify all parameters needed during a
particular IPL process without requiring that they be specified from an operator's
console.
Operator intervention for an individual parameter list may be restricted by use
of the 'OPI= YES/NO' parameter.

44

OS/VS2 Planning Guide for Release 2

InstaUation-Created Lists
The installation is also able to create certain lists, that are not supplied by IBM,
to further tailor the system to installation needs. Most of these may also be
maintained as mUltiple lists. The following lists may be created by the installation
in MVS:
Default List

Alternate List

Contents

COMMNDOO

COMMNDxx

Commands to be issued by the system control
program at the completion of system initialization
processing.

IEALPAOO

IEALPAxx

Names of SYS1.SVCLIB, SYS1.LPALIB, and
SYS1.LINKLIB modules that are to be made
resident as a page able extension to the link pack
area.

IEAOPTOO

IEAOPTxx

System resource management tuning parameters.

IKJPRMOO

TIOC buffer parameters

IRBMFlOO

MF /1 parameters

PARMTZ

Local time constant

VATLSTOO

VATLSTxx

Volume attributes

Command List (COMMNDOO)
This list contains commands (e.g., START) that are to be issued by the system
control program at the completion of system initialization processing. It may also
be used to specify whether or not the time-of-day (TOD) clock initialization
messages and associated responses should be issued.
The COMMNDxx list is specified by the CMD system parameter.

Local Time Constant (PARMTZ)
This SYS l.P ARMLIB member may be used to contain the value (in hours,
minutes, and seconds) that the local time differs from Greenwich Mean Time
(GMT), and the direction (east or west) from the GMT.
This constant is used to set the time-of -day clock and overrides the local time
value that is specified at system generation for inclusion in the CVT.

Modified Link Pack Area List (IEALPAxx)
This list may be used to indicate reenterable routines from the SYS l.LINKLIB,
SYS1.LPALIB, and SYS1.SVCLIB data sets that are to be contained in the
pageable extension to the link pack area. The routines in this area (called the
modified link pack area) are resident only for the current IPL. If a routine is
searched for, the modified link pack area is searched first, followed by the
pageable link pack area. If a system restart is initiated and a previously created
link pack area is used, the routines in the modified link pack area must be
respecified if desired.
The IEALP Axx list is specified by the MLP A system parameter.

Defining the System

45

System Resources Management Tuning Parameter List (IEAOPTxx)
This parameter list contains the values that are used by the system resources
management algorithms to influence decisions about swapping jobs in or out of
real storage. The values are described in the chapter: "Directing the Use of
System Resources".
MF/l Parameter List (IRBMFlxx)
This list contains the parameters that control MF /1 operation. The options that
may be specified are described in the topic: "MP/1 Operation" in the chapter:
"Direeting the Use of System Resources".
Volume Attribute List (VATLSTxx)
The volume attribute list may be used to define the mount characteristics
(permanently resident, reserved) and allocation characteristics (storage, public,
private) for any, or all, direct access volumes used by an installation.
This list was a single SYS 1.PARMLIB member called PRESRES in MVT and
VS2 Release 1. Multiple members of the volume attribute list may be maintained
in MVS.
The V ATLSTxx list is specified by the VAL system parameter.

46

OS/VS2 Planning Guide for

Relea~le

2

System Libraries and Data Sets
Some system data sets are basic to MVS and are required for every operating
system. Other system data sets are optional and are required only when selected
options are included in the system.

Required Libraries and Data Sets
The following libraries and data sets are required for every MVS operating
system and must be on the system residence volume.
• SYS I.LOG REC (error recording. data· set) -- The machine error recording data
set is used by recovery management routines to record statistical data about
machine errors and software errors.
• SYS1.NUCLEUS (nucleus library) -- The nucleus library contains the resident
portion (nucleus) of the control program and may contain modules selected
and link -edited during system generation.
• SYS1.SVCLIB (SVC library) -- The SVC library contains some OLTEP
modules and some appendage modules.
The following libraries and data sets are required for every MVS operating
system and must be on direct access volumes. It is not necessary that they be on
the system residence volume.
• Job Entry Subsystem Data Set(s) -- These data sets contain spooled and
checkpointed record used by either JES2 or JES3. Either may be a
multivolume data set.
• Master Catalog -- The master catalog is a key-sequenced VSAM data set that
contains pointers to cataloged data sets and user catalogs. The name can be
specified at system generation time on the PDS = parameter of the Stage I
DATASET macro instruction. This catalog replaces the MVT and VS2 Release
1 system catalog (SYSCTLG).
• Page Data Sets -- The page data sets are known collectively as paging space.
Paging space contains the "pagedout" portions of address spaces and the
common system area, as well as the data written to virtual 110 data sets.
• SYS I.DSSVM -- This data set contains the command language modules used
by the dynamic support system (DSS).
• SYS1.LINKLIB (link library) -- The link library contains programs and
routines that are not in the link pack area and are referred to by ATTACH,
LINK, LOAD, or XCTL macro instructions.
• SYS1.LPALIB (link pack area library) -- The link pack area library contains
all modules that are loaded into the pageable link pack area. In MVS, the
pageable link pack area is a read-only area. Therefore, modules contained in it
must be refreshable. Modules that are modified during execution
(non-refreshable) should be included in the modified link pack area. Because
all of the modules in this library are brought into the LP A at IPL time, this
library may be placed on a demountable volume that may be removed after
IPL.
• SYS1.MACLIB (macro library) -- This library contains macro definitions for
the system macro instructions used by the assembler-language processor.

Defining the System

47

• SYS I.PARMLIB (parameter library) -- The parameter library contains defau.lt
parameters for the initialization of system functions.
• SYS I.PROCLIB (procedure library) -- The procedure library contains
cataloged procedures used for job definition.
• SYS I.SAMPLIB -- This library contains independent utility programs, the IPL
text, and the SMF exit routines.
• SYS I.STGINDEX -- This VSAM data set is used as an internal catalog for
the pageable link pack area and virtual 110 data sets that must be saved
across job steps and IPLs.
• SYSl.BRODCAST (broadcast data set) -- the broadcast data set contains two
types of time-sharing messages: notices and mail. This data set must be
cataloged but requires space allocation only if time sharing messages are to be
written.
• SYSl.CMDLIB (command library) -- This library contains time-sharing
command processor programs, service routines, and utility programs. This
library must be cataloged. It requires space allocation unless the TSO stage 1
system generation macro instruction is coded such that the time sharing
command system is not included.
• SYSl.MANX/SYSl.MANY (SMF data sets) -- The system management
facility (SMF) data sets contain the information collected by the SMF
routines. They may also contain measurement information collected by the
syst.em activity measurement facility (MF 11). The SMF data sets must be
cataloged but require space allocation only if SMF or MF I 1 recording is
planned.
• SYSl.UADS (user attribute data set) -- This data set contains a list of
terminal users who are authorized to use time-sharing and information about
the users. This data set must be cataloged but requires space allocation only if
the installation plans to initiate terminal sessions.

Optional Libraries and Data Sets
The following data set is optional and, if selected, must be on the system
residence volume.
• PASSWORD -- This data set contains records that associate the names of
protected non-VSAM data sets with the passwords assigned to the data sets.
The following libraries and data sets are optional and, if selected, must be on
direct access volumes unless otherwise stated.
• SYS I.DCMLIB -- This library contains program function key (PFK)
definitions for display consoles and is required if a display console with the
optional PFK feature is included in the system.
• SYSl.DUMP (dump data set) -- This data set contains core image dumps
recorded in the event of abnormal termination of a critical task. The dump
data set may reside on tape.
• SYS I.HELP -- This data set is required if the time-sharing HELP command is
used. Each member of this data set contains information regarding the syntax,
subcommands, and functions for each time-sharing command.

48

OS/VS2 Planning Guide for Release 2

• SYS1.1MAGELIB -- This data set contains the 1403 and 3211 universal
character set (UCS) and forms control buffers (FCB) image modules. It is
required if a 1403 printer with the UCS feature, 3211 printer, 3890 document
processor device, or 3886 optical character recognition device is included in
the system.
• SYS 1.P AGEDUMP -- This data set contains the stand-alone dump program, if
this program is on a direct access device. If the stand-alone dump program is
on tape, this data set will not exist.
• SYS 1. TELCMLIB (telecommunications
library) -- This library contains the
/
telecommunications subroutines in load module format and is required if any
of the TP access methods other than the virtual telecommunications access
method (VT AM) are selected.
• SYS 1. VT AMLST -- This data set contains lists of internal parameters in card
image format used during VTAM initialization.
• SYS 1. VT AMLIB -- This library contains the VT AM executable code in load
module form.
• SYSl.VTAMOBJ -- This data set contains the 3705 network control program
(NCP) that is loaded by VT AM during VT AM initialization.

Changes to VS2 Release 1 System Libraries and Data Sets
System data sets and libraries in MVS are the same as their counterparts is VS2
Release 1 with the following exceptions:
• The page data set, SYS 1.P AGE, has been replaced by two or more uniquely
named VSAM data sets. This paging space must be defined before the first
IPL. (See the topic "Adding Paging Space to the System.")
• The system catalog, SYSCTLG, has been replaced by a key-sequenced VSAM
data set. Conversion aids are discussed in the topic "Catalog Conversion" in
the chapter "Conversion Considerations".
• The data sets that support job entry subsystems are new.
• The format of the SYS 1.BRODCAST data set has been modified to include a
change level indicator in the header record and a new field for each user
identification in the mail directory records. This field contains the address of
the last message in the chain of messages assocated with each user
identification. An MVS format for the broadcast data set is obtained by using
a new subcommand (SYNC) of the time-sharing ACCOUNT command. (See
the topic "Formatting the Broadcast Data Set" in the "Conversion
Considerations" chapter.)
• The load module size of modules in the SYS 1.DSSVM data set has been
increased from 1K bytes to 2K bytes.
• The SYS1.SYSJOBQE data set does not exist. It has been replaced by a
scheduler work area (SWA) in virtual storage for initiator records and by a
job entry subsystem data set for input, queued jobs, and output.
• The content of the SYSl.LOGREC data set has been expanded to include
records for software error recording, missing interrupts, and dynamic device
reconfiguration(DDR) routines.

Defining the System

49

• The SMF data sets, SYS I.MANX and SYS I.MANY, may now be used for
system activity measurement facility (MF /1) recording. They must be
cataloged in MVS.
• The log data sets are no longer named SYSl.SYSVLOGX and
SYS 1.SYSVLOGY by IBM. They are dynamically allocated by the job entry
subsystem.
• The SYS I.P ARMLIB library contains new members to control the
initialization of the system. See the topic "SYSl.PARMLIB" in the section
"Defining the System" for descriptions of these members.
• The SYSl.STGINDEX data set is new.
• The format of the SYSl.UADS data set has been modified to contain
information for new keywords on ACCOUNT subcommands. An existing user
attributes data set (UADS) is converted to the new MVS format by using an
Account Facility utility program (UADSREFM). (See the topic "Reformatting
the UADS" in the "Conversion Considerations" chapter.)
• The SYS 1. VTAMLIB, SYS 1. VT AMLST and SYS 1. VT AMOBJ data sets are
new.

Changes to MVT System Libr.aries and Data Sets
System data sets and libraries in MVS are also the same as their counterparts in
MVT, with the exceptions previously noted and the following:
• The SYS I.ACCT data set no longer exists. The SMF data sets SYS I.MANX
and SYSI.MANY should be used in its place.
• The SYSl.DSSVM data set is new.
• The SYSl.LPALIB data set is new. It contains all of the SVCs and most of
the modules that, in MVT were contained in the SYS I.LINKLIB and
SYS1.SVCLIB libraries. All of the modules contained in this new data set
appear in the fixed or pageable link pack area in VS2.
• The page data sets are new.
• The SMF data sets, SYSl.MANX and SYSl.MANY, may now be used for
VSAM recording.

Adding Paging Space to the System
Before the first system IPL, the installation must define and preformat paging
space. In MVS, paging space contains system pages, the page able link pack area,
and virtual I/O data sets. Paging space consists of two or moOre VSAM data sets.
The usc of the define statement with this type of VSAM data set causes a paging
data set to be formatted with track overflow for maximum performance of paging
I/O.
At least two such data sets are required for paging space because two copies
(primary and secondary) of certain pages are maintained on external storage.
These data sets must contain enough space for a minimum number of secondary
pages, corresponding primary pages, and additional pages that have no associated
secondary copies.
The auxiliary storage management initialization routines enforce these
minimum values by internally separating paging data sets for exclusive storage of

50

OS/VS2 Planning Guide for Release 2

secondary page copies, from paging data sets used exclusively for primary copies.
These routines attempt to select for secondary page copies, enough (entire) data
sets on the slowest paging device type to satisfy the minimum number of pages.
They classify paging devices by average access time. For best separation, the
installation should direct candidate page data sets for secondary page storage
onto the slowest device available for paging; preferably directing the other paging
data sets to separate devices.
The installation can include more paging space than the minimum by
specifying additional page data sets during system generation. If it is necessary to
add paging space to the syst6"m after system generation, the installation must first
use access method services to define and format the data sets, then cause their
names to be entered in a PARMLIB member PAGE list, and finally re-IPL the
system. The operator can also specify additional names via the PAGE system
parameter.
No more than 25 page data sets can be specified during system generation.
The number of page data sets must never exceed 63.
Page data sets can be added to the system in even or odd numbers; there is
no need to pair them.

Creating Temporary Data Sets in Extemal Page Storage Using Virtual I/O
Conventional access methods (BSAM, QSAM, BDAM, and BPAM) and XDAP
and EXCP macro instructions, can create and access temporary data sets in
external page storage or system paging space by utilizing the virtual input/output
(VIa) facility.
Specific unitnames can be defined during system generation (UNITNAME
macro) as eligible for VIa processing. The VIa unitname defined is coded in a
problem program JCL statement which defines a system-named temporary data
set without specifying the volume serial number. VIa then interprets and
simulates the execution of the channel programs associated with an EXCP issued
by an access method or a problem program.
The channel programs are not scheduled and translated in the conventional
manner by the I/O supervisor. VIa simulates I/O activity using a buffer that is
the size of a track for the first device in the list defined by the UNITNAME
macro instruction. To the access method or problem program, a VIa device is a
real direct access storage device; actually the virtual device is simulated on the
volumes assigned to external page storage.
VIa processing relies heavily on the services of the paging supervisor. The
paging supervisor causes the real I/O that is requested by VIa, and maintains for
virtual, auxiliary, and real storage, the page tables that make data accessible in a
virtual storage environment. The paging supervisor maintains the contents of the
VIa buffer based on requests issued by VIa.
VIa offers the following enhancements to conventional processing of
temporary data sets:
• Channel program translation and page fixing by the I/O supervisor for each
EXCP request, are eliminated.
• The paging supervisor dynamically allocates page-size physical blocks
(auxiliary storage page slots) to a VIa data set as it is being created. DADSM
overhead for the allocation of space on a real device is thereby eliminated.

Defining the System

51

• Many I/O operations may be satisfied by moving data between a VIO buffer
and an access method or user buffer, thus eliminating the channel and device
activity associated with normal channel program request processing. The data
set is automatically blocked in page size (4K) records, irre:spective of access
method or user-buffer size.
• There is generally more efficient utilization and easier management of direct
access space, since temporary data sets use auxiliary space within the paging
data sets.
• When a data set page is to be read, the paging supervisor determines if it is
still in real storage and available for reclamation (the reclaim function). If it
can be reclaimed, the read is accomplished without physical I/O.

52

OS/VS2 Planning Guide for Release 2

Directing the Use of System Resources
This chapter describes some of the MVS facilities that allow installations to direct
the use of system resources.
System resources management routines allow an installation to specify, in
measure able terms, the relative rate at which system resources should be
provided to various categories of background and terminal jobs.
The system activity meas\i:;~ment facility (MF /1) provides reports on selected
areas of system activity. The installation uses the information in these reports to
determine how to specify performance objectives for the system resources
management routines.

Directing The Use of System Resources

53

System Resources Management
System resources management routines are new in MVS. They provide:
• The capability for an installation to specify, in measure able terms, the rate at
which system resources should be provided to various use:rs of the system.
• A means by which the system control program is able to monitor the use of
system resources and attempt to maintain their most efficient use at all system
workload levels.
These routines monitor the use of system resources to determine when
background and time sharing jobs should be swapped in or out to meet the
installation-specified objectives.
The resources management routines are divided into three primary categories:
• Workload management routines.
• Resource-use routines.
• A control function.

Workload Management Routines
The function of the workload management routines is to cOllltrol the relative rate
at whiGh processing resources are provided to individual jobs or time sharing
users so as to conform to installation performance specifications. Their design
enables installations to specify different processing rates for a job or time sharing
command depending on the system workload level and on th.e age of, or amount
of processing done by, a job or command. Workload management routines
accomplish this processing rate control by monitoring the processing resources
used by each address space and scheduling swaps (to or from main storage) to
achieve an intended processing rate. A more detailed discussion of the installation
interface with the workload management routines is found under "Workload
Management Concept."

Resource-Use Routines
The resource-use routines consist of a set of algorithms that make scheduling
recommendations intended to optimize the utilization of the system CPU, I/O,
main storage, and paging resources. These algorithms include:

I/O Load Balancing
This algorithm attempts to maintain a dispatchable job mix that has a balanced
use of logical channels. The algorithm monitors the fraction of I/O requests
delayed on each logical channel and ascertains whether this measure of load
falls within an acceptable range. When an imbalance -- either an overload or
underload situation -- occurs the algorithm seeks out an address space known
to be a heavy user of the imbalanced resource, and may then recommend a
swap. To reduce the overhead of monitoring the I/O profile of each individual
address space, the I/O request counts gathered already on behalf of SMF are
analyzed for this purpose.
CPU Load Adjustment
This algorithm continuously monitors CPU utilization and when this value
either goes above or below an acceptable target range, the CPU Load
Ad justment algorithm will attempt to remedy the situation by recommelllding
the swapping of one or more heavy CPU users into main storage in the case

54

OS/VS2 Planning Guide for

Releas(~

2

of CPU underload, or out of main storage in the case of overload. Because
MVS installations are advised to initiate more jobs than will normally fit in
main storage, ingredients for a well balanced job mix normally exist on the
queue of swapped-out but ready to execute address spaces.
A special case occurs when the CPU is 100% utilized. When this occurs the
algorithm looks for address spaces near the bottom of the dispatching queue
that are not being regularly dispatched. This situation is considered a serious
CPU overload because it means that address spaces are tying up real storage,
but are either not executing at all or are executing too slowly to warrant the
expenditure of rear storage. The solution is to recommend the replacement of
heavy CPU users in main storage with 110 users who make better use of the
system resources.
Main Storage Occupancy
This algorithm attempts to ensure that the sum of the working sets of all
swapped-in address spaces (those address space pages that are regularly
referenced) nearly fills, but does not exceed, the capacity of main storage. The
sum is· judged too large if the size of the available frame count drops below a
low threshold. When this occurs, an address space is promptly swapped-out to
free frames and thereby increase the available frame count. To prevent this
corrective action from happening too often, the main storage occupancy
algorithm evaluates the consequences of all anticipated swaps in an attempt to
keep the available frame count near a target which is above the low threshold.
If the low threshold is crossed too frequently, this target is dynamically
adjusted away from the low threshold. If it is not crossed at all, the algorithm
is too conservative and the target is dynamically adjusted closer to the low
threshold.
Page Replacement
Page stealing makes frames occupied by unreferenced pages, available for
reuse by active pages. The page replacement algorithm takes advantage of data
maintained on an address space basis, to determine candidates for page
stealing.
This represents a marked departure from Release 1 which employs a
system-wide page stealing algorithm. Perhaps more important however, is the
fact that in Release 2 page stealing is not used to p~rform the system-wide
control function of ensuring the availability of sufficient deallocated real pages.
The problem of thrashing -- excessive demand paging -- is largely eliminated
in Release 2 because page stealing is not used to remedy real frame shortages.
Instead, when such a shortage occurs, the SRM main storage occupancy
algorithm uses swapping to reduce the number of address spaces executing in
main storage.
To ensure an acceptable percentage of "good steals," the page replacement
algorithm monitors the page referencing activity of individual address spaces,
and selects a page to be stolen if and only if it has gone un referenced for a
predefined amount of that address space's CPU execution time. This criterion
prevents the stealing of active working set pages that go unreferenced for
periods of elapsed time simply because that address space temporarily did not
get dispatched.
For pages in the Common Area this approach is not used, since these pages
are not associated with any particular address space. Unreferenced elapsed
time is used as the prime criterion for stealing these pages.

Directing The Use of System Resources

55

Device Allocation
This algorithm determines the unit to be used for data sets for which an
allocation choice must be made from a list of more than one device candidate.
The goal is to allocate from lightly-utilized channels, and to collect allocations
for the same address space on the same logical channel without collecting
them on the same device, so that swapping that address space will have a
predictable effect on the system I/O load.
Automatic Priority Group (APG)
This algorithm reorders dispatchable address spaces within the automatic
priority group based on the degree to which they are I/O bound; within the
APG, I/O-bound jobs are given higher dispatching priorities than CPU-bound
jobs.
To fully realize the benefits of this algorithm, the installation should place all
possible users within the APG. In MVS, this is facilitated because the APG
priority is used as the default step displl.tching priority. (See the topic
"Changes to VS2 Release 1 JCL" in the chapter "Conversion
Considerations. ")
ENQ/DEQ Algorithm
This algorithm determines when a batch or terminal job is in control of a
system resource and is delaying other jobs that are enqueued on the same
resource. When such a determination is made, the job that is enqueued upon
the system resource is made non-swapp able for an installation-specified time
interval. The interval is specified by the ERV parameter in the IEAOPTxx
member of SYS 1.P ARMLIB.

Control Function
The control function gathers the results (recommendation values for potential
swap decisions) produced by the workload management routines and the
resource-use algorithms. It uses a control algorithm to combine and evaluate the
individual recommendation values to produce a composite recommendation value
for each potential swap decision. The control function then uses these values to
determine the amount of swapping that should be performed in an attempt to
satisfy the installation-specified performance objectives andl efficiently use system
resources.
The control algorithm uses optional installation-specified parameters called
resource factor coefficients to weight the recommendation values produced by
the I/O and CPU load balancing algorithms. The use of these coefficients (which
are contained in the IEAOPTxx member of SYS 1.P ARMLIB) provides one
method of system tuning. For example, if the installation increases the CPU
coefficient, the recommendation value produced by the CPU load balancing
algorithm will be more heavily weighted when it is evaluated by the control
algorithm in conjunction with other recommendation values.

Workload Management Concepts
One of the SRM design objectives is to assure maximum control over user
performance by an installation, without requiring the installation to supply its
own scheduling algorithm. The solution adopted is to permit an installation to
specify in measure able terms, the response and turnaround objectives wanted,
and allow the workload management routines to determine how to achieve these
objectives. The following concepts support such an approach by providing

56

OS/VS2 Planning Guide for Release 2

measure able terms for the response objectives of individual batch and time
sharing users.
Transaction
The basic entity to which reponse and turnaround objectives are associated is
called a transaction. Since both batch and time sharing are supported by the
workload management routines, a concept of transaction is needed which
supports both environments. A job is the batch entity about which turnaround is
usually measured. It is therefore selected as the definition of a batch transaction.
Provision also exists to treat individual job-steps as separate transactions.
The time sharing entity about which response is measured, normally begins
when the user strikes end-of -block and ends when he receives his terminal
output. This sequence may be encompassed in a time sharing command or
subcommand -- in either case it qualifies as a separate transaction.
Performance Variable
Having defined what a transaction is, the need now exists for a variable capable
of expressing response and turnaround objectives for transactions. Response time
itself is not satisfactory because it is too dependent on the individual processing
requirements of each transaction. What is needed is a variable that measures the
rate at which processing takes place, rather than the amount of processing
required. An objective expressed in terms of processing rate can reasonably be
used to assure a time sharing user a consistent quality of responsiveness,
regardless of the variety of commands he chooses to enter.
Service
The measure of processing chosen is a composite variable called service -- a
combination of an individual address space's CPU, I/O, and main storage usage.
The formula for service also includes three installation-supplied coefficients.
SERVICE = A* ( SMF Task CPU Time * K) +
B* ( SMF I/O Request Count) +
C* (Working Set Size * SMF Task CPU Time * K)

where: A, B, and C are installation-supplied constants, and K is a
model-dependent MIPS adjusting factor.
Service Rate
Service rate, defined as the service accumulated by a transaction divided by the
elapsed time, is the variable used by the installation to express response and
turnaround objectives. It is used by the workload management routines to
monitor the progress of each executing transaction.
The SMF job termination record, the time sharing TIME command, and the
MF /1 workload activity report, return to the installation the data necessary to
correlate service rate with response and turnaround times.
Thus, for example, a user regularly submitting the same batch job should know
that if it requires approximately 72K service units, and through arrangement with
the installation manager the job is assured 25 sui sec, then it will complete in 4R
minutes, while if the arrangement is for 50 su/sec it will complete in 24 minutes.

Directing The Use of System Resources

57

There is a practical limit to the service rate a job can absorb. The workload
management routines can do no better than provide the job with the highest
service rate it can absorb, even if a higher rate is requested.
System Workload

One important new facility in MVS, is the ability to temporarily swap most batch
and time sharing address spaces out of main storage. This facility makes it
feasible -- and usually desireable -to start more batch initiators than the real
storage capacity can efficiently support. The SRM keeps track of all active
address spaces, both batch and time sharing, and schedules swaps in and out so
that a number of conditions are satisfied. For the purposes of this discussion, it is
sufficient to mention two of these conditions:
• The demand for real storage should not cause excessive paging .
• The service rate afforded each address space should correspond closely to the
installation performance objectives.
The combined demand of all address spaces for system resources constitutes
the system workload. The more active address spaces that exist -- whether batch
or time sharing -- the heavier will be the system workload. MVS is designed to
efficiently handle a very wide range of system workloads. An installation should
anticipate, however, that under heavy system workload coltlditions, some address
spaces must be temporarily swapped out of main storage. This results in lower
serviee rates for the delayed address space. Later it will bt~ shown that an
installation can specify the service rate reductions that individual batch and time
sharing address spaces should experience under different system workload levels.
Installation Performance Specific;lltion
It is the job of the installation to translate the various performance requirements

of its users into one or more installation performance specifications. This control
data, which is included in the SYS l.P ARMLIB data set, permits the workload
manager to schedule the availability of processing resources among individual
users in accordance with the dictates of the installation.
An installation performance specification (IPS) is a mapping that associates a
particular transaction with an intended service rate. It is important to note that
the IPS mappings take into account other considerations, specifically the systt~m
workload, the amount of service already accumulated by a transaction, and the
age of the transaction.
Performance Groups

The purpose of performance groups is to group together user transactions that
the installation considers to have similar performance requirements. A
teleprocessing applications program that has multiple users and executes in a
single virtual address space is considered to be a single transaction, and its
terminal users are not distinguished from each other by the system resources
management routines.
The installation can define as many as 255 performance groups, each
identified by a distinct performance group number. Each performance group
definition includes as many as eight performance group ~riods. By dividing a
performance group into periods, an installation can associate different
performance objectives with different perioJs in the life of a transaction. The
duration of a period can be specified either as a number of real-time seconds or

58

OS/VS2 Planning Guide for Release 2

as a number of accumulated service units. For example, one performance group
might be defined for short compile-load-go jobs that should have a very rapid
turnaround time. The installation divides the performance group into two periods.
The first period is associated with a high service rate and lasts until N number of
service units are accumulated, where N has previously been determined to be a
sufficient number of service units to complete a short compile-load-go job. If a
job in the group is not complete after N service units are accumulated, it enters
the second period, for which a lower service rate has been specified, and remains
in this period for the duration of the job.
Performance Objectives
A performance objective specifies service rates; how many service units per
second an associated transaction should receive under different system workload
conditions.
The motive for specifying different performance objectives is to give certain
users better service at the expense of other users. However, the relative
importance of this motive is dependent on the size of the system workload (i.e.,
the degree to which the demand for system resources exceeds the supply).
The installation specifies the treatment of different subsets of jobs by fixing
arbitrary points, called workload levels, at which it defines target service rates for
each subset of jobs. Conceptually, increasing workload levels can be thought of
as increasing competition or demand for system resources. Thus, in order to
preserve a high service rate for high priority jobs as demand (workload level)
increases, an installation will reduce the target service rate for lower priority jobs.
Typically, an installation supplies an IPS such that if the system workload is
moderate, all jobs should receive satisfactory service rates. However, if the
system workload is heavy, the installation will want to provide an acceptable
service rate to high priority jobs, and lower the service rate for lower priority
jobs. Under very heavy workload conditions the installation might completely
sacrifice the service rate of lower priority jobs (i.e., assign a service rate of 0) in
order for the system to continue to provide acceptable service to the higher
priority jobs. By defining workload levels, the installation can express the varying
service relationships between groups of users at different system workload levels.
For example, an installation defines three performance objectives, numbered 2,
5, and 8. When the system workload is light, each performance objective should
specify a better than satisfactory service rate for the transactions associated with
it; the installation assigns the number 2 to this workload level and assigns
corresponding service rates to each performance objective, as illustrated in the
chart at the top of Figure 9. Under very heavy workload conditions, the
installation wants to completely sacrifice the service rates for objective 5 and to
lower the service rate for objective 8 but still provide acceptable service to jobs
associated with objective 2. This workload level is assigned the number 8; the
corresponding service rates associated with each objective are illustrated in Figure
9. The two intermediate workload levels shown in Figure 9 are established to
reflect the changing relationships between the performance objectives as the
workload level increases from 2 to 8.

Directing The Use of System Resources

S9

Performance Objectives
Performance

Service Rate

Service Rate

Service Rate

Service Rate

Objective

for Workload

for Workload

for Workload

for Workload

Number

Level 2

Level 4

Level 6

Level 8

2

44

40

36

32

5

60

10

0

0

100

20

s
100

Performance Objective 8

80

60

...

CI)

10

a:

CI)

.;CJ
Iii
C/)
When the system workload is at level 4,
transactions associated with performance
objective 8 receive service at a rate of 20

40

20

- - - - - . - - - - - - - . _...............__ _

o~-------_~I--------~----------I~--------~I.
2
4
6
8 -w
Workload Level

Figure 9. Performance Objective Definition

60

OS/VS2 Planning Guide for Release 2

The system resources manager tracks the service rates provided to all users. As
the system workload level increases or decreases, it adjusts the service rates in an
attempt to maintain the relationships between the performance objectives (and
therefore between the transactions associated with the objectives) that the
installation has defined.
Figure 9 also contains a graphic representation of one of the performance
objectives (performance objective 8). This graph illustrates the service rates that
the installation has defined for the system workload levels of 2, 4, 6, and 8. The
workload management routines attempt· to provide the service rate that applies to
the performance objective for the associated job at the current system workload
level. In Figure 9, when the current system workload is 4, the workload
management routines recominend swapping in order to maintain a service rate of
20 for the jobs that are associated with performance objective 8. Jobs associated
with other performance objectives will be targeted at service rates indicated in
their performance objectives for a workload level of 4.
Associating a Transaction with a Performance Objective
Every transaction that enters the system has a performance group number. In
Figure 10, transaction A is associated with performance group 9, transaction B is
associated with performance group 8. For its first performance group period,
transaction B will be associated with performance objective 5. This means that,
for this period, the workload management routines will attempt to maintain a
service rate for transaction B that equals the service rate specified in performance
objective 5 for the workload level that equals the actual workload level of the
system at a given time.
I nstallation Performance Specification (I PS)
~~~~~--~----~----~------~--Transaction A
Performance Group
Number = 9

Transaction B
Performance Group
Number = 8
Workload Level

2
100

4

6

20

18

8

Figure 10. Associating a Transaction With a Perfonnance Objective

The Relationship Between Workload Levels and Service Rates
To summarize the relationship between workload levels and service rates,
consider a hypothetical installation whose users fall into one of three distinct
subsets. Each subset can be considered to be a performance group. They are:

Directing The Use of System Resources

61

• Performance Group A -- A long running batch job that is run only once a day
is the: only job in this class and is extremely important.
• Performance Group B' -- Moderate length batch jobs, of intermediate
importance make up this class.
• Performance Group C -- Relatively short batch jobs, least in importance,
make: up this class.
Figure 11 illustrates the performance objectives that have been defined for
each of the three performance groups. (Three distinct performance groups, each
with only one defined period and one associated performanc,~ objective, are
assumed for simplicity of illustration.)

S

140

J!l
III
ex:

120

0-

100

0

~

•

80

CI)

u

.~
CI)

en

0

60

40

20

~------~--------~------~~----------W
2
4
6
8

o

Workload Level

Figure 11. Performance Objectives

Group A jobs are associated with performance objective 3, group B jobs with
performance objective 8, and group C jobs with performance objective 5. Jobs
associated with performance objective 3 demand a service rate of approximately
120 at workload levels 2 and 4. At workload level 6, performance objective 3
jobs d~:!mand a service rate of 100 "'hile performance objective 5 jobs have
stopped receiving service, and performance objective 8 jobs have reduced their
demands to 18 service units per unit time. At workload levt!l 8, even performance
objective 8 jobs nearly stop receiving service in deference to A jobs. As long as
the A job receives a service rate of approximately 100, the installation knows
that the job will complete processing in a satisfactory amount of time.

62

OS/VS2 Planning Guide for Release 2

The workload level at which the system operates is a function of the number
of jobs in each performance objective actually initiated at any time. Figure 12
illustrates system workload levels that result from three different possiblilties:
• One job from each performance objective.
• One job from performance objective 3, four from performance objective 8,
and two from performance objective 5.
• One job from performance objective 3, seven from performance objective 8,
and one from performance objective 5.

1-1-1

S

CI.I

....co

1-4-2

S

280

280

280

240

240

240

200

....CI.Ico
a: 160
CI.I
.;u
i 120
CI)

200

....IIIco

a: 160

a: 160
CI.I

'E
Jl

'ECI.I

5

CI)

80

Composite
Demanp

40
0

2

4

6

/

Performance
Objective 3 - 1 job
Performance
Objective 8 - 1 job
Performance
Objective 5 - 1 job

120
C

. ,
omposlte
Demand

80

8

0

2

4

6

Workload Level

System
Workload
Level
Between
2 and 4

Supply

i/

Composite ..... ~

80

Demand

;

40

40

Workload Level

i

200

u

120

1-7-1

S

Performance
Objective 3 - 1 job
Performance
Objective 8 - 4 jobs
Performance
Objective 5 - 2 jobs

System
Workload
Level
of 4

8

o

2

4

6

8

Workload Level

Performance
Objective 3 - 1 job
Performance
Objective 8 - 7 jobs
Performance
Objective 5 - 1 job

System
Workload
Level
Between
6and8

Figure 12. System Workload Levels

In these illustrations a simplified assumption is made that the system provides
a composite service rate of 220 service units per unit of time to all active jobs;
this is the "supply" line. The "demand" line represents the composite service
demands from all jobs at each workload level. It is derived by multiplying the
number of jobs in each performance group by the service rate specified for that
performance objective at the particular workload level. In other words, with a job
mix of 1-4-2, (the center graph on Figure 12), the composite service rate
demanded by all jobs at workload level 4 is 1x120+4x20+2x10=220. (At
workload level 4, a job associated with performance objective 3 demands a
service rate of 120, a performance objective 8 job demands 20 and a
performance objective 5 job demands 10.) The intersection of the supply and
demand lines produces the resulting system workload - that point of equilibrium
at which the system can meet the composite demands of all active users.
In Figure 13, the different system workload levels that result from the three
different job mixes are superimposed over the three performance objectives to
illustrate the service rates that apply as the system workload level increases.

Directing The Use of System Resources

63

1·1·1

S

1-4·2

,·7·1

140

...
CD
III

a:

120

0-

100

®

=

=

Ii

•

80

Q)

u

.~

~

®

60

40

20

..~------------~W
8

~------------~----~----~=-------------~

o

2

4

6

Workload Level

Figure 13. Service Rates for Different Perfonnance Objectives at Various System Workload Levels

As shown in Figure 13, the following conclusions about the installation's
performance objective specifications may be drawn from this hypothetical
analysis:
With 1 job initiated in each performance objective:
• The system will be operating at a workload level between 2 and 4.
• The performance objective 3 job will receive approximately 121 service
units per unit time.
• The performance objective 8 job will receive approximately 64 service units
per unit time.
• The performance objective 5 job will receive approximately 35 service units
per unit time.
With 1 performance objective 3 job, 4 performance objective 8 jobs, 2
performance objective 5 jobs:
• The system will be operating at a workload level of 4.
• The performance objective 3 job will receive approximately 120 service
units per unit time.
• The performance objective 8 jobs will each receive approximately 20
service units per unit time.
• The performance objective 5 jobs will each receive approximately 10
service units per unit time.
64

OS/VS2 Planning Guide for Release 2

With 1 performance objective 3 job, 7 performance objective 8 jobs, 1
performance objective 5 job:
• The system will be operating at a workload level between 6 and 8.
• The performance objective 3 job will receive approximately 100 service
units per unit time.
• The performance objective 17 jobs will each receive approximately 15
service units per unit time.
• The performance objective 5 job will not be receiving service.
In each of the preceding examples, the sum of the service rates provided to all
users will equal approximately 220 service units per unit time (the composite
system "supply").

System Resources Manager Parameters
The system resources manager parameters fall into two classes. Those that affect
the recommendation values produced by workload management routines are
contained in the SYS 1.PARMLIB member IEAIPSOO (or IEAIPSxx); those that
otherwise affect swapping decisions are contained in the SYS 1.PARM LIB
member IEAOPTOO (or IEAOPTxx).
These parameters provide the installation with a great degree of flexibility in
stating performance requirements.
IPS Parameters (lEAIPSxx)
An installation performance specification contains four categories of information:
• Service definition coefficients -- The workload management routines use these
values as multipliers, in calculating the service that a transaction has received.
(See the topic "Service" earlier in this chapter.)
• Up to 32 workload level numbers -- Workload level numbers are used to
specify the relative service rates that jobs of different priorities are to receive
at varying levels of system activity. Each number is related to a specific
service rate in each performance objective, and the numbers increase in
magnitude as contention for system resources increases.
• Up to 64 performance objectives -- Each performance objective is specified in
terms of the service rates to be provided at different workload levels. The
performance objective number that is specified for each performance group
period, identifies the performance objective to be used for that period.
• Up to 255 performance group definitions -- A performance group definition is
identified by a performance group number. It may be subdivided into as many
as eight different periods. Each period has the following parameters associated
with it:
- period duration
- units code
- performance objective number
- response/throughput bias
- interval service value

Directing The Use of System Resources

65

These categories of information are specified by the following parameters:
Performance Group Number
The performance group number is an integer between 1 and 255 that
associates a transaction with a performance group definition. All transactions
have performance group numbers. 1 is the default for batch jobs and 2 is the
default for terminal jobs.
Period Duration
The period duration is a positive integer that indicates the length of the
interval during which a specified performance objective is to be associated
with a transaction.
Units Code
The units code is specified by the letter "s" or the letter "R". "s" indicates
that the indicated period duration is to be measured in terms of accumulated
service; "R" indicates that it is to be measured in terms of real-time seconds.
Performance Objective Number
The performance objective number is an integer between 1 and 64, that
indicates the performance objective with which the transa(~tion is to be
associated for the duration of the indicated period.
Response/Throughput Bias
The response/throughput bias (RTB) is an integer that indicates, for each
performance group period, that deviations from the service. rate specified in
the performance objective can be tolerated in favor of higher system
throughput. "1" indicates that for jobs in this performance group period, the
resource-use algorithms will produce evaluations that will influence swap
decisions; "0" indicates that they will not.
Interval Service Value
The interval service value (lSV) specifies a minimum number of service units
that a transaction must receive during each interval of real storage occupancy,
before a swap evaluation is made by the workload management routines.
Workload Level
The workload level is an integer between 1 and 128. Up to 32 workload level
numbers can be specified (in increasing magnitude representing heavier
workload levels of the system). Workload levels are used to differentiate
between light and heavy demands for the use of system resources. The same
workload level numbers must be specified for each performance objective in
an IPS.
Performance Objective
Each performance objective is identified by an integer from 1 to 64 followed
by a definition of the service rates that are associated with the workload level
numbers specified by the workload level parameter. A service rate must be
specified for each workload level number defined in the IPS.
Service Definition Coefficients
The service definition coefficients (CPU, IOC, MSO) are used by the system
resources management routines to calculate the service units that are provided
to a particular job. Each coefficient is a multiplier on one of the three basic
processing units in these calculations. For example, if an installation specifies

66

OS/VS2 Planning Guide for Release 2

an IOC coefficient of 3.0, whenever a job issues an I/O request, the system
resources management routines multiply the I/O resource (one processing
resource) by the service definition coefficient (3.0), and that job is considered
to have used three service units.
Each of the service definition coefficients may be specified only once in an
IPS. If a service definition coefficient is not specified, an IBM-supplied default
value will be used.
Service Rates
Service rates are integers that define a target rate that system resources are to
be supplied to an associated transaction. When grouped in sets called
performance objectives, these define an intended service rate for any system
workload condition.
Tuning Parameters (IEAOPTxx)
The parameters in the SYS I.PARMLIB member IEAOPTxx include:
Resource Factor Coefficients
Resource factor coefficients are values in the range 0.0 to 9.9. They specify
values that are used as multipliers in the control algorithm to weight the
recommendation values produced by the I/O and CPU load balancing
algorithms. The two coefficients are 10C and CPU. Each coefficient has a
default value of 1.0. The coefficients are used to make the recommendation
values produced by the corresponding algorithms either more or less important
than the recommendation values supplied by the workload management
routines, for which an implied coefficient of 1.0 applies.
Resource Manager Constants
This category contains the enqueue residence value (ERV). The ERV is an
integer in the range 0-999999. It is used to calculate the amount of time that
an address space will not be swapped because the address space is enqueued
upon a system resource required by another address space. The time interval is
determined by multiplying the ERV by the (model dependent) time required
to execute 10,000 machine instructions. (This procedure is intended to keep
the execution interval relatively constant on all System/370 models.)

Directing The Use of System Resources

67

System Activity Measurement Facility (MF /1)
The system activity measurement facility (MF /1) is new in MVS. Installations
may use it to monitor selected areas of system activity and obtain feedback in
the form of trace records and/or formatted reports. Measurements may be
gathered independently on:
• CPU activity
• Channel activity and channel-CPU overlap activity
• I/O device activity and contention
- Unit record devices
- Graphics devices
- Direct access storage devices
- Communication equipment
- Magnetic tape devices
- Character reader equipment
• Paging activity
• Workloadactivity
MF /1 activity is divided into three categories:
• SAMG (system activity measurement gathering) obtains the measurements of
system activity requested by the installation.
• SARG (system activity report generation) produces formatted reports of
desired system measurements.
• MFC (measurement facility control) controls the collection, tracing and
reporting of system activity.
SAMG consists of distinct sets of measurement gathering (MG) routines
associated with each class of measurement data. Only those sets associated with
the measurement data requested by the system operator af(~ loaded and active
during MF /1 reporting intervals.
SARG generates formatted summary reports of information requested by the
system operator, collected by SAMG, and routed to it by MFC. Printing of these
reports may be done as they are generated, or may be defe:rred until MF /1
termination.
MFC is the system task that controls MF /1 operation. It causes the loading of
the MG routines that will be needed to obtain the desired information, passes
control to these routines at the desired intervals, routes collected information to
SARG as required, and terminates MF /1 execution at the ,end of its specified
duration.

MF/1 Operation
The operation of MF /1 is controlled by a set of parameters that may be
contained in:
• The P ARM field of the START command that is issued to start MF /1
processing.

68

OS/VS2 Planning Guide for Relea!le 2

• The P ARM field of the EXEC statement in the MF I I cataloged procedure.
• The MF I I partitioned data set member (typically a SYS l.P ARMLIB
member).
The IBM -supplied cataloged procedure for MF I 1 names the MF I 1 partitioned
data set member that contains card image MF I 1 control input. Member names
are of the form IRBMFlxx, where xx is a decimal digit field. In the absence of
any explicit specification, the SYS I.PARMLIB member IRBMF 100 is used.
The system operator issues the START command to begin MF I 1 monitoring.
The parameters controlling the operation of MF I 1 are gathered from the above
sources in the order stated. Explicit specification of an option in the P ARM field
of the START command will therefore override any alternative specifications of
that option in any other source. If a parameter is not specified in any of the
three sources the system default value is used.
The MF / I options are summarized below. The underlined values are the
system default values, as well as the values that appear in the SYSl.PARMLIB
member IRBMFIOO.
CPU/NOCPU
.PAGING/NOPAGING
CHAN/NOCHAN

WKLD(PERIOD I GROUP ISYSTEM) INOWKLD
DEVICE(device list)/NODEVICE
These parameters are used to specify which of the classes of MG routines
(CPU activity, paging activity, channel activity, workload activity, 110 device
activity) will be loaded and executing during the MF I 1 reporting period.
UNITR/NOUNITR
TAPE/NOTAPE
DASD/NODASD
COM'"M/NOCOMM
GRAPH/NOGRAPH
CHRDR/NOCHRDR

These parameters are the elements of the device list above. They specify the
device types (unit record, tape, direct access, communications, graphics,
character reader) about which information will be collected.
REPORT(REALTIME/DEFER)/NOREPORT
This parameter specifies whether or not formatted reports of the gathered data
will be generated, and when the reports will be generated (i.e., as the data is
gathered, or after MF I I processing terminates).
SYSOUT(class)
This parameter specifies the SYSOUT class to which formatted reports will be
directed. Class A is the default.
RECORD/NORECORD

This parameter specifies whether or not trace records will be written to the
SMF data set.
INTERVAL(value/valueM)
This parameter specifies the interval at which data will be gathered for report
formatting and/or trace record writing. The range is from 1 to sixty minutes.
The default is 1SM.

Directing The Use of System Resources

69

CYCLE(value)
This parameter specifies the frequency at which observations are made of
sampled data. The range is from 50 to 999 milliseconds. The default is 250
milliseconds.
STOP(value/valueM/valueH)/NOSTOP
This parameter specifies the desired time interval for MF /1 activity, in
minutes or hours (the default is minutes). The operator STOP command will
terminate execution at any time, regardless of the value for this parameter.
The default value is 15M.
MEMBER(nn)
The value specified by this parameter is added to IRBMFI to form the name
of the partitioned data set member that contains the MF /1 options. The
default is 00.
OPTIONS/NOOPTIONS
This parameter specifies whether or not a list of the keyword options to be
used will be printed at the operator's console. If the list is printed, the
operator will be able to respond with any desired changes to the option list.

MF/1 Reports and Tracing R'ecords
Measurement output is produced in two forms:
• Printed Reports -- The data is formatted and printed for each class of system
activity data collected.
•

Tra(~e

Records -- The data is written as a trace record to the SMF data set.
One or more trace records are produced for each class of system activity data
collected.

The printed reports and trace records contain the same type of information,
but in different forms. The installation can specify desired output as:
• Printed reports only.
• Trace records only.
• Both printed reports and trace records.
The following sections describe the contents of each type of printed report
and trace record.
CPU Activity Report
This report provides information about the use of the central processing unit(s).
The total CPU wait time that has taken place during an MF /1 reporting interval
is generated for each CPU. The CPU wait time is also expressed as a percentage
of the reporting interval time.
Paging Activity Report
This report provides detailed information about the demandls made on the systt~m
paging facilities during the reporting interval. It also distinguishes between the
use of real main storage and external page storage. The following categories of
information are included:

70

OS/VS2 Planning Guide for Release 2

• Page reclamations -- Page reclamation rates and percentages are produced, for
system pageable areas and the user's private address spaces, for both VIO and
non-VIO accesses.
• Page-ins -- Page-in rates and percentages are produced for all pages
transferred from external page storage to real storage. This information is
provided for system pageable areas and the user's private address spaces.
• Page-outs -- Page-out rates and percentages are produced for pages
transferred from real storage to external page storage. This information is
provided for system pageable areas and the user's private address spaces.
• External page storage counts -- Total page slots are produced, as well as the
number of unused slots, unavailable slots, and slots containing either data set
pages or virtual address space pages.
• Pageable real storage counts -- The total number of page able real storage
frames is produced, as well as breakdowns into counts and percentages of used
and unused page frames.
• Swap counts -- The total number of swaps are produced, as well as average
pages per swap-out, and average pages per swap-in.
Workload Activity Reports
These reports provide information about the system workload activity and its
relationship to the installation-specified performance objective for each
performance group period. This information can be used to evaluate and modify
the IPS. The three different workload activity reports that are available provide
three different levels of detail. The types of reports desired are specified by input
parameters indicated below from the most detailed report to the least detailed
report.
• Performance group period report -- (WKLD(PERIOD))
• Performance group report -- (WKLD( GROUP))
• System summary report -- (WKLD(SYSTEM))
Performance Group Period Report: This report provides, for each performance
group period within each performance group:
• The total number of service units used by all transactions in that performance
group period.
• The average service rate for all transactions within that performance group
period.
• The average workload level of all associated transactions.
• The average number of transactions that were concurrently active.
• The total number of transactions that terminated.
• The average elapsed time of a transaction that terminated.
Performance Group Report: This report provides, for each performance group,
for one MF /1 reporting interval:
• The total number of service units used by all transactions in that performance
group.
• The average number of associated transactions that were concurrently active.

Directing The Use of System Resources

71

• The total number of associated transactions that terminated during the
reporting interval.
System Summary Report: This report provides, for one MF /1 reporting interval:

• Tht: total number of service units used by all transactions.
• The mean workload level of the system.
• The average number of transactions that were concurrently active.
• The total number of transactions that terminated during the reporting interval.
Channel Activity Report

This report provides information about channel loading for all channels in the
system. For each active channel, a "channel activity" count provides the total
number of successful SIO instructions (excluding the sense SIO instructions)
issued to that channel during the reporting interval. A "percent channel active"
indication provides the percentage of the total reporting interval during which
each ehannel was busy. A "percent channel busy and CPU waiting" indication
provides the percentage of the reporting interval during which each channel was
busy while the associated CPU was in a wait state. An installation may use this
information, in conjunction with the information contained in the I/O device
activity reports, to determine possible bottlenecks associated with channels.
I/O Device Activity Reports

These reports provide information about I/O device loading for all devices in the
chosen device class(es). The classes desired are specified in the input parameter
string (UNITR, TAPE, DASD, COMM, GRAPH, CHRDR). For each device
report, a "device activity count" indicates the number of successful SIO
instructions (excluding the sense SIO instructions) issued to the device during the
reporting interval. A "percent busy" indication provides the percentage of the
reporting interval during which the device was busy. A "mean queue length"
value provides an average number of requests that were enqueued and waiting to
be serviced on the device during the reporting interval. An installation may use
this information, in conjunction with the information contained in the channel
activity reports, to determine possible bottlenecks in the I/O subsystem.
SMF Recording
If RECORD is specified among the MF /1 input parameters, a record will be

written to the SMF data set, at the end of each reporting interval, for each
report requested by the parameters. Each record contains information similar to
the contents of the corresponding formatted report. Totals., averages, and
percentages are not explicitly contained in the record, but may be calculated from
the explicit data. The SMF records, and their corresponding printed reports are:

72

OS/VS2 Planning Guide for Release 2

SMF70

-- CPU Activity Report

SMF71

-- Paging Activity Report

SMF72

-- Workload Activity Report

SMF73

-- Channel Activity Report

SMF74

-- I/O Device Activity Report

Tuning With MF /1
Tuning a system is the process of modifying its hardware or software
characteristics to bring performance closer to installation defined objectives. Once
an installation's performance objectives are clearly defined, MF /1 can be used to
help an installation both specify and meet them. For example, the channel
activity report and I/O device activity report can provide information about the
efficiency of the system-wide I/O load balance and how it affects system
throughput. Analysis of these reports could indicate possible system configuration
changes or data set residence modifications.
MF /1 can also be used to determine if the IPS reflects the installation's
turnaround/ response requirements and, if so, whether the IPS objectives are
being met. It can further be used to analyze the specified performance objectives
for possible modification.

Tuning Example
Figure 14 shows the division of the installation's jobs into three performance
groups. Assume that users associated with performance group 7 -- the time
sharing users -- are experiencing poor response time at their terminals. The
installation decides to activate MF /1 for a three hour period during a typical
day, to obtain six reports on the workload activity for analysis. To initiate this
reporting the operator enters:
START

MF1.MF1",(NOCPU,NOPAGING,NOCHAN,
NODEVICE,INTERVAL(30M),STOP(3H))

(Assume that there are no EXEC statement parameters in the MF /1 procedure,
and that the default SYSl.PARMLIB list IRBMFI00 is used.)
With the above command and the standard defaults, the following options will
control MF /1 execution in this case:
NOCPU
NOPAGING
NOCHAN
WKLD(PERIOD)
NODEVICE
REPORT (DEFER)
SYSOUT(A)
NOTRACE
INTERV AL(30M)
CYCLE(250)
STOP(3H)
OPI

Directing The Use of System Resources

73

IPS Values
FIRST PERIOD

SECOND PERIOD

CI>

CI>

'~

';:;

CI>

CI>

>

>

Performance
Group

Significance of
Performance Group
to Installation

Number

c:

co

.~
c:
::>

co

Terminal Jobs

Interaction

8

High Priority Batch

3000

9

Low Priority Batch

Entire
Job

100

0
';:;

~

co
a:

>

I-

CI>

c..

5Q

S

8
5

System
Workload Level

"
Q)

u

.~

Q)

CI)

40

20

W

2

4

Workload Level

Figure 14. Tuning Example

74

OS/VS2 Planning Guide for Release 2

6

E

co

....'"

C:l

:::>

:;

Rest of
Job

60

o

co

c:

~
CI>

c..

2

80

CI>
.....
co

c:

c:

E

:;

Performance
Objectives

t,)

t,)

CI

S

CI>

CI>

';:;

Performance
Objectives

0

0

0

7

t,)

'B

'B
c:

--

8

-

8

I-

co
a:

:::>

-

-

~

Assuming that the operator does not prematurely terminate MF /1 execution
with the STOP command, MF /1 will terminate at the end of three hours, and
the six reports that were collected at half-hours intervals will then be printed.
The installation can now begin its analysis.
Two figures of interest in this case are the average system workload level, and
the average active time for all performance group 7 transactions. Suppose that
these reports indicate that, during the time that MF /1 monitoring took place, the
system was operating approximately at workload level 4 and that the average
response time for time sharing users was 30 seconds (considered by the
installation to be poor response time).
An analysis of the performance objective specification shows that, at workload
level 4, performance objective 2 specifies that performance group 7 transactions
receive 40 service units per unit time. The installation might reasonably wish to
increase the service rate for its time sharing users in order to improve the
response time. This increase would raise the performance objective curve for
performance objective 2, as shown in Figure 15.

S

Performance
Objectives

System
Workload Level

100

®
80

j!!
cv

a:

CII
Col

..
en

60

'S:

........

CII

~==~

40

-.--

.... ....... - - ....

•

20

o

2

4

6

8

W

Workload Level

Figure IS. Changing a Perfonnance Objective

Directing The Use of System Resources

75

Figure 16 shows that raising the service rate for performance objective 2 raises
the system workload level, aU other factors being equal. Transactions associated
with performance objectives 5 and 8 would, therefore, be affected. Transactions
associated with performance objective 5 would be most severely affected because
their demand curve slopes most severely to the right of workload level 4.

Performance
Objectives

S

100

-

@

System
Workl~ad

I

Level

_-

80

-

...

-

CIl
III

a:

CIl

u

.~

60

-

-

CIl

en

-t----_
==
§
- - .....

~

40

t

§--t

20

L -______~____--~------~--------~W

o

2

4
Workload Level

Figure 16. Effects of a Perfonnance Objective Change

Before the installation modifies performance objective 2, it is able to perform
further analysis to determine the quantitative effects of such a change. Suppose
the MF /1 reports showed an average of 20 jobs associated with performance
objective 2, 8 jobs with performance objective 5, and 4 jobs with performance
objective 8. Then, some measure of the average system rate of service supplied
to all jobs can be obtained by multiplying the number of jobs at each
performance objective by the service rate for that performance objective at
workload level 4 (i.e., 20 x 40 + 8 x 20 + 4 x 10 = 800 + 160 + 40 = 1000
total service units per unit time).
In this case, increasing the performance objective 2 curve by 10 service units,
results in a total increase in demand of 200 service units (10 times the 20 jobs
associated with performance objective 2). Thus, the workload level of the system
shifts to the right (increases) to compensate for this increase in demand, while
maintaining the system supply of 1000 total service units approximately constant.
(See Figure 16.) If the installation considers the service rates provided for all
performance objectives at the projected new workload level to be acceptable, it
may modify the IPS to contain the new performance objective 2.
The installation may then use MF /1 monitoring to verify the accuracy of the
projections; repeating the entire procedure, if desired, until satisfactory results are
achievt~d.

76

OS/VS2 Planning Guide for Release 2

The preceding example is not meant to reflect actual figures or relationships,
but rather to indicate the possibilities for tuning that MF /1 can provide. The
illustrated method of improving response time is neither the only one, nor
necessarily the best -- other alternatives include varying the interval service value
parameter, dividing the time sharing performance group into more than one
period, and increasing the number of performance groups provided for time
sharing users. Any method chosen to improve this or other system performance
characteristics will suggest other uses and variations for MF /1.

Directing The Use of System Resources

77

78

OS/VS2 Planning Guide for Release 2

System Integrity

A highly desirable property of an operating system is its ability to insure that one
program cannot interfere with or modify another program's (system or user)
execution unless it is authorized to do so. For reliability and system availability,
this is extremely important; for data security, it is essential. MVS provides this
capability in the form of system integrity support.
System integrity is defined as the ability of the system to protect itself against
unauthorized user access to the extent that security controls cannot be
compromised. That is, there is no way for an unauthorized* problem program
using any system interface to:
• Bypass store or fetch protection, Le. read or write from or to another user's
areas.
• Bypass password checking, Le. access password protected data for which a
password has not been supplied.
• Obtain control in an authorized state.
In MVS all known integrity exposures have been removed. IBM will accept as
valid, any AP AR that describes an unauthorized program's use of any system
interface (defined or undefined) to bypass store or fetch protection, to bypass
password checking, or to obtain control in an authorized state.

*An authorized program in MVS is one that executes in a system key (keys 0-7), in supervisor
state, or is authorized via the Authorized Program Facility (APF).

System Integrity

79

Installation Responsibility
To ensure that system integrity is effective and to avoid compromising any of the
integrity controls provided in the system, the installation must assume the
responsibility for the following items:
The installation must be responsible for the physical environment of the
computing system. Operations personnel and system programmers have, in effect,
uncontrolled access to certain portions of the operating system. Problems of this
nature are discussed in The Considerations of Physical Security in a Computer
Environment, GS20-2700.
The installation must be responsible for the adoption of certain procedures
(e.g. the password protection of appropriate system data sets) that are a
necessary complement to the integrity support within the operating system itself.
The most significant of these procedures are described briefly in the topic
"Installation Procedural Responsibilities."
The installation must ensure that its own modifications and additions to the
control program do not introduce any integrity exposures. That is, all
installation-written authorized code (e.g. an installation SVC) must perform the
same or an equivalent type of validity checking and control that the MVS control
program employs to maintain system integrity.

80

OS/VS2 Planning Guide for Release 2

Areas of Concern
Several areas with the potential for integrity exposures have been identified.
These areas, and what has been done to eliminate them as potential sources of
integrity exposures, are described below. The description is a guideline to aid the
installation in preserving system integrity in any modification or addition to the
control program. It is also intended to aid in determining whether an impact on
existing installation cody might occur, where that code is dependent on the use of
non-standard interfaces to the control program. There should be no impact on
installation-written routines that use standard interfaces (problem
program/system interface described in an SRL), because no standard interface
has been removed from the system control program in connection with system
integrity support. MVS system integrity support is concerned only with restricting
the unauthorized problem program; there is no attempt or intention to prevent
the installation manager or any authorized system programmer from modifying
the system control program.

User-Supplied Addresses for User Storage Areas
A potential integrity exposure exists whenever a routine having a system
protection key (key 0-7), accepts a user-supplied address of an area to which a
store or fetch is to be done. If the system routine does not adequately validate
the user-supplied address to ensure that it is the address of an area accessible to
the user for storing and fetching data, an integrity violation can occur when the
system key program routine:
• Stores into (overlays) system code or data (e.g. in the nucleus or the system
queue area), or into another user's code or data .
• Moves data from a fetch-protected area that is not accessible to the user (e.g.
the fetch-protected portion of the common service areas), to an area that is
accessible to him.
The elimination of this problem requires that system key routines always verify
that the entire area to be stored into, or fetched from, is accessible (for storing
or fetching) to the user in question. The primary validation technique is the
generally established MVS convention that system key routines obtain the
protection key of the user before accessing the user-specified area of storage. For
example, MVS data management SVC routines (which generally run in key 5)
assume the user's key before modifying a data control block (DCB) or an I/O
block (lOB).

User-Supplied Addresses for Protected Control Blocks
A potential integrity exposure exists whenever the control program (system
key / privileged mode) accepts the address of a protected system control block
from the user. For most system control blocks this situation should not be
permitted to exist. However, in certain cases it is necessary to allow the user to
provide the address of a system control block that describes his allocation/access
to a particular resource (e.g. a data set), in order to identify that resource from a
group of similar resources, (e.g. a user may have many data sets allocated).
Inadequate validity checking in this situation can create an integrity exposure,
since an unauthorized problem program could provide its own (counterfeit)
control block in place of the system block and thereby gain the ability to:

System Integrity

81

• Access a resource in an uncontrolled manner (since the control block in this
case would normally define the restrictions, such as read-only for a data set,
on the user's allocation to the resource.
• Gain control in a privileged state (because such control blocks may contain
the addresses of routines that run in privileged mode or with a system (0-7)
key.
• Cause various other problems depending on exactly what data the system may
be keeping in the control block involved.
To avoid this type of exposure, the control program must verify, for every
address of this type that is accepted from a problem program, that the address is
that of:
1. A protected control block created by the control program.
2. The correct type of control program block (e.g. a TCB versus a DEB, or a
QSAM DEB versus an ISAM DEB).
3. A control block created for use in connection with the user (job step) that
supplied the address.
In MVS, verification is generally accomplished by establishing a chain or table
of the particular type of control block to be validated. This chain or table is
located via a protected and job step-related control block that is known to be
valid (i.e. whose address is not allowed to be supplied by the user, and is located
via a chain of protected control blocks that begins with a control block known to
be valid or fixed at a known location at IPL time, such as the CVT*). Thus a
control block can only be entered in the chain/table by an authorized program,
which satisfies (1) above; by definition the chain/table establishes the type of
control block, which satisfies (2) above; and also by definition each chain/table
is located only through a job step-related control block, satisfying point (3).

Resource Serialization
Resource serialization is another potential source of integrity problems. Here an
integrity exposure can result when serialization controls on sensitive control
program resources are nonexistent, or inadequate to the exltent that an
unauthorized problem program can directly, or indirectly through a part of the
control program (e.g. by issuing an SVC), change the content or status of a
system resource (e.g. control block, work area), while another portion of the
control program (e.g. another SVC) is using that resource or is in some way
dependent on its content or status remaining unchanged for a given period of
time.
Adequate control of serial resources becomes even more significant in a
multiprocessing environment since some uniprocessor serialization techniques
(e.g., disablement), are no longer effective because of the possibility of multiple
tasks, even mUltiple tasks in the same job step, using the same serial resource and
running concurrently on different CPUs.
To eliminate this as a potential exposure, a locking technique is used to
serialize access to the resources in question. However, a locking technique is not
*This does not imply that a system routine must go back to the CVT or similar control block
every time it wants to establish a valid chain. Typically, a control block address not too far
down on such a chain is available already validated in a register. For example, the first load
of an SVC may receive control with a valid TCB address in a lcgister.

82

OS/VS2 Planning Guide for

Releas!~

2

effective unless all routines that have the potential for changing the resource, or
that depend on its status remaining unchanged for a given period, make use of
the (same) locking mechanism. Effective use of a locking technique therefore
requires considerable investigation and effort, to determine and keep track of
system resources that must be serialized and routines that access such resources.
In MVS, a combination of ENQ/DEQ and a new hierarchical locking
structure with multiple typ-es of locks, is the primary method used to synchronize
the use of serial resources. The locking mechanism is restricted to key 0
programs, which prevents unauthorized problem programs from interfering with
the serialization of system resources. For the same reason, ENQ/DEQ is
restricted to authorized programs for all major names of the form SYSZxxxx, and
for the following explicit major names: SYSDSN, SYSIEECT, SYSIEFSD,
SYSIEAOl, SYSVTOC, SYSPSWRD, SYSCTLG, SYSIGGVl, SYSIGGV2, and
SYSVSAM.
Another integrity consideration, related to the above problem, but generally
applicable to all validity checking for integrity purposes, is the
time-of-check-to-time-of-use problem. This refers to the fact that from the time
of a validity check until the completion of the operation associated with that
validity check, the variables on which the outcome of the validity check is based
must not be allowed to change to the extent that the result of the validity check
would be changed. While this is a relatively obvious statement, the requirement it
imposes has considerably influenced the direction of the integrity support in
MVS.
In some cases, this requirement can be met "automatically" through use of
hardware serialization mechanisms, such as checking the validity of fetch/store
operations by assuming the user's protection key. In other cases, techniques such
as saving validated data in protected (storage keys 0-7) core and use of the
above-mentioned locking mechanisms are required.

Resource Identification
Resource identification is another area that can be subject to integrity exposures.
Exposures can result if the control program does not maintain and use sufficient
data to uniquely distinquish one resource from other similar resources. For
example, a program must be identified by both name and library to distinquish it
from other programs. The consequences of inadequate resource identification are
problems such as the ability of an unauthorized problem program to create
counterfeit control program code or data, or to cause varying types of integrity
problems by intermixing incompatible pieces of control program code and/or
data.
The general solution can only be stated as the reverse of the problem~ that is,
the control program must maintain and use sufficient (protected) data on any
control program resource, to distinguish between that resource and other control
program or user resources. The following are examples of the controls that MVS
employs to comply with the requirement:
• In general, authorized program requests to load other authorized programs are
satisfied only from authorized system libraries (see the topic "Control Program
Extensions").
• MVS takes explicit steps to ensure that routines loaded from authorized
system libraries are used only for their intended purpose. This includes
expanded validity checking to remove any potential for the unauthorized

System Integrity

83

program to specify explicitly which of the authorized library routines are to
gain control in any given situation.
• Sensitive system control blocks are validated as being the "correct" blocks to
be used in any given control program operation. (See the topic "User-Suppli(!d
Addresses of Protected Control Blocks").

SVC Routines Calling SVC Routines
A potential problem area exists whenever a problem program is allowed to use
one SVC routine (routine A) to invoke a second SVC routine (routine B) that
the problem program could have invoked directly. An integrity exposure occurs if
SVC routine B bypasses some or all validity checking based on the fact that it
was called by SVC routine A (an authorized program), and in addition,
user-sulPplied data passed to routine B by routine A either is not validity checked
by routine A, or is exposed to user modification after it was validated by routine
A. This problem will not exist if the user calls SVC routine lB directly, because
the validity checking will be performed on the basis of the caller being an
unauthorized program.
SVC routine A, which is aware that it has been called by an unauthorized
program, must ensure that the proper validity checking, etc., is .accomplished.
However, it is usually not practical for SVC routine A to do the validity checking
itself, because of the potential for user modification of the data prior to or during
its use by SVC routine B. The general solution should be for SVC routine A to
provide an interface to SVC routine B, informing routine B that the operation is
being requested with user-supplied data in behalf of an unauthorized problem
program (implying that normal validity checking should be performed).
In practice, in MVS, most SVC B type routines that could! be subject to this
problem, use the key of their caller as a basis for determining whether or not to
perform validity checking. Therefore most SVC A type MVS routines have
simply adopted the convention of assuming the key of their caller before calling
the SVC B routine.

Control Program and User Dtrta Accessibility
Important in maintaining system integrity, is the consideration of what system
data is sensitive and must be protected from the user, and what data can be
exposed to user manipulation. The imp~ications of the exposure of the wrong
type of data are obvious.
In general, it is necessary to protect the following types of data:
• Code, and the location of code, that is to receive control in an authorized
state.,
• Work areas for such code, including areas where it saves the contents of
registers.
• Control blocks that represent the allocation or use of system resources.

S4

OS/VS2 Planning Guide for Release

:e

MVS maintains items such as the above in system storage, or in a separate
region in the case of some APF-authorized (see the following section) programs.
It may also be necessary to protect, for a limited period, certain data that is
normally under the control of the user (e.g. to prevent its modification during a
critical operation). In this case MVS provides fetch protection for such data if:
• The data consists of proprietary information (e.g. passwords).
• The control program cannot determine the nature of the contents of the data
area.

Control Program Extensions
The final potential problem area involves the fact that there exists a somewhat
hazy distinction between the control program and certain types of problem
programs. In most installations, there are problem state/user key (keys 8-15)
programs that are actually extensions to the control program in that they are
allowed (by means of various special SVCs, etc.) to bypass normal system
controls over access to system resources. For example, a special utility program
that scans all the data on a pack might be able to avoid the normal system extent
checking on a direct access volume. The Authorized Program Facility (APF) was
introduced in VS2 Release 1 as a means of identifying these control program
extensions as "authorized" programs, and restricting the use of the various
"special" SVCs used by such programs to bypass normal system controls. This
use of APF is continued in MVS with the restriction of SVCs under APF
extended to include certain new SVCs introduced in MVS.
If an installation has its own control program extensions and special SVCs that
allow the bypass of normal system security or integrity checks (e.g., an SVC that
returned control in key 0), and if such SVCs are not currently restricted from use
by an unauthorized program, then the APF facility should be used to restrict
these SVCs and to authorize the control program extensions that use them. A
description of how to use the APF facility can be found in appropriate VS2
publications.

An important MVS addition is that APF has been extended to recognize and
accept authorized programs from "authorized" libraries other than
SYSl.SVCLIB, SYSl.LINKLIB, and SYSl.LPALIB. Any library may be
designated as an authorized library by inclusion of its name in the
SYS 1.PARMLIB member, IEAPFOO or IEAPFxx, prior to IPL. Such libraries are
the equivalent of the above system libraries in that nonspecific system requests
(library not specified) for routines that will execute with system key, privileged
mode, or APF authorization, can be satisfied by a module loaded from any
authorized library.
APF supports a facility (TESTAUTH) used to control the execution of certain
paths through SVCs, such as the path that opens (OPEN) the VTOC. This
facility may not be used to control the use of I/O appendages in MVS.
Appendages ~ controlled through SYS 1.PARMLIB as described above.
Note: The user of APF should also be aware that APF authorization is defined
such that any SVC that is restricted by the APF mechanism, can be executed by
any system key (0-7) or (in most cases) privileged mode routine. However, this
is not true in reverse. An APF authorized program will not automatically be
allowed system services that are restricted by system key or privileged mode
tests ..

System Integrity

85

Installation Procedural Responsibilities
As noted previously, the installation is responsible for the implementation of
procedures that are necessary in certain instances to complement the MVS
contro] program integrity/security support. These responsibilities are discussed
below. Note that in some instances, the concern is for basic system integrity,
while other items are concerned with a particular type of security.
1. The installation must password protect appropriate system libraries. System
integrity obviously cannot be maintained if system code and data is exposed to
arbitrary modification by any user on the system. For integrity purposes, it is
generally sufficient to protect appropriate libraries from write access; no
password is required for read access but a password is required for write
access. However, for security purposes, it is necessary to protect certain
system data sets (e.g. the PASSWORD data set itself) from read as well as
write accesses. To facilitate the protection of such data sets, during IPL and
system task initialization password requests are suppressed for data sets being
opened by the system.
Certain auxiliary storage manager (ASM) initialization procedures make
password protection of the SYSl.STGINDEX data set ineffective. However,
ASM provides protection via an ENQ on the data set name, effectively
preventing another user from allocating the data set.
2. Because the checkpoint data set produced by the Checkpoint/Restart facility
contains sensitive system data normally protected from the user, maintaining
system integrity requires that such data sets be protected from modification
(or from being counterfeited) prior to their use by Restart. MVS implements a
facility whereby the installation can adopt a set of special procedures/controls
over checkpoint data sets that will eliminate their potential for compromising
system integrity. The control mechanism involves a combination of:
• System/operator validation of checkpoint data sets.
• External labeling procedures for "checkpoint volumes."
• Offline control of "checkpoint volumes."
• Prohibiting I/O to checkpoint data sets, except through the checkpoint
SVC (APF-authorized programs excepted).
3. The installation should be aware of the following password protection
requirements, which may necessitate some changes in installation procedure.
• Because of the characteristics of magnetic tape devices, once a program has
access to one file on a tape, it can not be ensured that the program is not
able to access other files on that tape, even though it may not possess
passwords for those files. For this reason, MVS has implemented a changt~
in the handling of password-protected tape data sets to attempt to ensure
that if a user is allowed access to one data set on a tape volume, he can be
presumed also authorized to other data sets on the volume. To this end,
whenever a user attempts to create a tape data set whose file sequence
number is greater than 1, the protection attributes of the new file will be
compared against the protection attributes of the immediately preceding file
on the tape (no protection, protected for write, protected for read and
write, etc.). If the protection attributes do not match, the new data set will
not be created. In addition, if the previous data set is password protected,
its password must be supplied before the new data set will be created.

86

OS/VS2 Planning Guide for Release 2

Note that these changes do not eliminate problems caused by an installation
library containing already-existing tape files with mixed protection
attributes.
• The security-conscious installation should ensure that password-protected
data sets are created only on tapes which are unused or completely erased.
This is necessary because in certain cases residual information left on the
tape after the password data set was created, could result in a user being
able to open one of the previous data sets on the tape, thus gaining access
to the whole tape.
4. In the case of the 2840/2250, the installation may want to use dynamic
allocation and JCL validation exits to achieve additional control over device
allocation and user identification. Fetch/store protect is not available for the
2840 buffer, which can be shared by up to four 2250 graphic devices. The
above-mentioned exits can be used to establish a control mechanism that
restricts to users of the same security classification, 2250's that are connected
to the same 2840.
5. Although APF -authorized programs bypass the usual system control validity
checks, in any user interfaces they must provide validity check mechanisms the
same as or equivalent to the system validity checks. The effectiveness of APF
is dependent on this. However, it may be impractical to provide these checks
for some APF-authorized programs, and in these cases their use should be
restricted by placing them in APF-authorized password protected libraries. The
passwords for these libraries should then be provided only to individuals
authorized to use the programs. Installations might consider using this control
mechanism for the IEHINIT, OLTEP, and IEHDASDR routines.
6. If there are two modules with the same name on different authorized libraries
and an authorized program attempts to load one of these, it could get the
other (either accidentally or deliberately with JOBLIB, STEPLIB, or
concatenation). This type of exposure requires the additional restriction that
duplicate module names not be permitted across authorized libraries.
7. The optional update password for VSAM catalogs provides protection against
unauthorized delete or alter operations on non-VSAM data set entries~
operations on VSAM data set entries are protected under the password for the
data set. Catalogs (e.g., the master catalog) containing sensitive non-VSAM
data sets should be protected under the update password.
8. OS CVOLs should be password protected (one password for all CVOLs under
the name SYSCTLG) to avoid concurrent access between OS catalog routines
and an unauthorized user. However, this does not prevent unauthorized delete
or alter operations on the catalog. This protection is not offered for OS
CVOLs.
9. Installation-written programs (e.g., I/O appendages) that execute in supervisor
state or system key (0-7) in the user's address space, must be link edited
reentrant to ensure that they are loaded in a protected subpool.

System Integrity

87

88

OS/VS2 Planning Guide for Release 2

Conversion Considerations

This chapter describes significant differences and incompatibilities between
OS/MVS and:
• OS/MVT
• OS/VS2 Release l.
It is divided into the following sections:

• Job entry subsystem considerations.
• SMF considerations.
• Job control language.
• Communication between address spaces.
• Allocation considerations.
• Operator commands.
• Time sharing considerations.
• Catalog support.
• Data set conversion.
• V =R programming considerations.
• Program conversion.
• Multiprocessing considerations.

Conversion Considerations

89

Job Entry Subsystem Considerations
The job entry subsystems available with MVS are:
JES2 -- generally compatible with HASP II.
JES3 -- generally compatible with ASP Version 3.
With the first release of MVS, only JES2 will be available; therefore JES3
information reflects current design and is for advanced planning purposes only.
All jobs, started tasks, and LOGONs processed by the system must be entered
through a job entry subsystem, which must therefore be started before any
processing is done. The primary job entry subsystem is started automatically at
system initialization. Any other is started by the operator.

The JES2 Job Entry Subsystel"
JES2 functions as a job entry and system output processor. It also starts and
stops system initiators, selects jobs to be processed by initiators, and frees
resources when the jobs are complete. JES2 controls a job prior to execution and
following job termination.

90

OS/VS2 Planning Guide for Release 2

JES2 Job Flow
Figure 17 is an overview of the JES2 processing stages. Input, execution, output,
and purge services execute in the JES2 address space. Other functions depicted
execute in system or user address spaces.

Local
and

Execution Service
Input
Service

• •It!

Pre-E xecut ion
Control

Execution
Control

Converter

Output
Service

Print/
Punch
Service

Executing
Job or
System
Task

Purge
Service

Output
Processor

External
Writer

Remote or
Local

Figure 17. JES2 Processing Stages

Input Service: Jobs are read into the system from various types of card readers
and remote terminals, and through the internal reader interface. An internal
reader is an output (SYSOUT) data set allocated to JES2, which is recognized
and placed in the input stream. Jobs and system tasks submit jobstreams in this
manner.
Each job or user is given a unique job identifier; then the JCL and input data
are stored on direct access volumes for retrieval during Execution Service.
Compatability: Input service functions as a complete replacement for the OS
reader; however no catalog procedures are associated with this function.
Procedure libraries and interpretation parameters are associated with jobs by
JES2.
Prior to execution, jobs are maintained on JES2 execution queues rather than
on SYS 1.SYSJOBQE. Pre-execution manipulation must occur through the use of
JES2 commands rather than system commands.

Conversion Considerations

91

Jobs with JCL syntax errors fail during conversion. The job is sent directly to
output service, thus the JCL is not interpreted.
Support of the DLM parameter on DD
compatible with OS support.

* or DD DATA JCL statements is

JES2 ignores the" / /" (null) statement. The only effect of this statement is a
possible higher input record count than MVT.
Execution Service: Through this service, jobs are submitted to the system for
execution. Conversion takes place immediately after input service. The JCL is
converted into internal text, unless syntax errors are discovered. Job selection
takes place as soon as an initiator eligible to process the job is available. Jobs are
selected in priority sequence within their class.
The subsystem interfaces for the following functions are supported through
execution service:
• Subsystem job selection (including presenting jobs for warmstart).
• Allocation/ unallocation of JES2 data sets.
• Sysout output interfaces (TSO output TMP).
• Job status.
• Job cancel.
• End of storage.
• End of task.
• WTO /WTOR/DOM messages.
• Command processor.
• Verify remote user id.
• Job termination.
• Job re-enqueue.
• OPEN/CLOSE of JES2 data sets.
Compeltability: JES2 does not support the Execution Task Monitor of OS/MVT
HASP systems. The System Resources Manager of MVS accomplishes the same
functions, with no defined interface to JES2.

All sysin/ sysout data sets are maintained by JES2.
JES2 provides an access method for reading and writing the spool data sets in
response to user requests. This method of accessing spool data is different from
that provided by OS /MVT HASP.
JES2 is responsible for presenting jobs for warmstart or restart.
JES2 supports 36 job classes rather than 15. (A-Z, 0-9)
EXCP to a JES2 data set is not supported.
NOTE/POINT to DCBs processing JES2 data sets is nOit supported.
JE82 supports the IEFUSO SMF exit.

92

OS/VS2 Planning Guide for Release 2

Output Service: The print data sets and system messages created during
execution are printed; the punch data sets are punched.
JES2 operator commands are used to control JES2 printer/punch devices.
Operators at remote stations can control only those JES2 devices attached to
their particular station.
When each group of job-related data sets and each spinoff data set are
processed, output service writes one SMF type 6 record to the SMF data set.
Compatabi/ity: JES2 does not attach user-written sysout writers. The external
writer interface must be used for special sysout processing.

Purge Service: When all processing required for a job is completed, the direct
access space maintained by JES2 and all JES2 resources associated with the job
are made available. The SMF purge exit is scheduled and the SMF purge record
written.
JES2 Warmstart For a warmstart occurring under JES2, all spool volumes that
were up during the last execution must be available, although they need not be
mounted on the same drives.
Jobs with no job journal or with an irretrievable journal are not presented to
the system for warmstart processing.
New jobs may be presented to the system and will be processed in priority
order -- ahead of lower priority warmstart jobs.
MVS Operational Changes
JES2 performs the reader function of the MVT Reader/Interpreter, and
functions of the MVT Output Writer and Remote Job Entry. Unit record devices
used for reading jobs and printing or punching output, and teleprocessing lines
used for accessing remote stations are normally assigned to JES2. Thus a deVice,
even though idle, may need to be disassociated from JES2 before it can be used
by other system jobs or tasks.
Converter /Interpreter parameters formerly placed in the Reader Procedure
PARM field for each specific reader, are included in the JES2 job class related
parameters established during JES2 initialization. All catalogued procedure
libraries to be used by jobs, LOGON, or system tasks must be included in the
JES2 catalog JCL. JES2 class-related parameters and Job Control Cards
associate the procedures with jobs by job class.
A card reader can be dedicated to JES2 in such a manner that the operator
need only ready the device to cause JES2 to read a jobstream.
A catalogued procedure is provided to read a job stream from any
QSAM-supported device through the internal reader interface. This method is
used to read jobs from local devices other than card readers; it must also be used
if input stream positioning is desired.
Column binary cards must be read by an installation-written routine and
passed to JES2 through the internal reader interface.
The OS/360 standard separator page is not supported -- the special JES2
separator page is a combination of those provided by MVT HASP and OS/360.

Conversion Considerations

93

An external writer is provided to support user-written output writers and the
standard OS/360 separator page. This allows a user to write data to devices not
directly supported by JES2 or JES3 (e.g., tape and disk), and to use
installation-written job separator routines.
Remote stations may be attached with point-to-point based or dial lines.
Multi-point support is not provided.
The direct sysout writer is not supported. A sysout data set is available for
output service processing prior to the end of the job if the data set is unallocated
at CLOSE. This facility is called sysout spinoff.
JES2 output service attempts to minimize forms, UCS, and FCB loading while
processing output data sets. Operator interaction is minimized, and data may be
processed in an order different from MVT. A JES2 generation option allows an
installation to specify that output in the message class of a job be processed
continguously.
Sysout data sets and system messages are processed directly by JES2 and
written into the JES2 spool data set, rather than into separate direct access data
sets. These data sets may be retrieved at a time sharing terminal or by an
external writer. Data sets freed by a foreground user are immediately available
for output processing by JES2, or for inspection via the OUTPUT command.
A time sharing user can use JES2 control cards to specify job-related
parameters for his submitted job.
JES2 schedules the IEFUSO SMF exit and the SMF purge exit, and writes the
SMF output, purge, and subsystem activity records (types 6" 26, and 43-46
respectively) .

94

OS/VS2 Plannjng Guide for Release 2

JES2/HASP Compatibility
Figure 18 describes some areas of compatibility between HASP and JES2.
Some additional items and further clarification follow:
VS2 Release 1/HASP

MVT/HASP

JES2

Tape input (via HASP START
command)

Internal reader (via a cataloged
procedure)

Internal reader (via a cataloged
procedure)

Execution task monitor

Dynamic dispatcher

System resources management routines

Binary synchronous code adapter and
synchronous transmitter receiver
communications facilities

Binary synchronous code adapter
communications facilities only

Binary synchronous code adapter
communications facilities only

Pseudo devices for SYSI N/SYSOUT
via QSAM, BSAM, or EXCP

Pseudo devices for SYSIN/SYSOUT
via QSAM, BSAM, or EXCP

Subsystem interfaces for SYSIN/SYSOUT
via QSAM and BSAM only

Installation-written output writers only
via the system output writer

Installation-written output writers only
via the system output writer

Subsystem interface allows installationwritten routines to obtain SYSOUT data
sets from JES2

HASP console services Qt multiple
console support

Multiple console support with HASP
interfaces

Multiple console support with JES2
interfaces

Purge card

Purge record written to SMF data set

Purge record written to SMF data set

System output queued by four types

System output queued by forms,
printer set-up, and 36 output classes

System output queued by forms,
printer set-up, and 36 output classes

No equivalent function

Forms, printer set-up, and routing
information may be specified on a
HASP OUTPUT control card

Forms, printer set-up, and routing
information may be specified on a
JES2 OUTPUT control card

Restricted checkpoint/restart support
for jobs using SYSIN/SYSOUT

Restricted checkpoint/restart support
for jobs using SYSIN/SYSOUT

Full checkpoint/restart support

No SMF SYSIN record counts

No SMF SYSIN record counts

No SMF output limiting support

No SMF output limiting support

No SMF output record

SM F output record is written to the
SMF data set

Numeric forms designation

Alphanumeric forms designation

Alphanumeric forms designation

TSO SYSOUT data sets are written by
the system output writer

TSO SYSOUT data sets are written by
the system output writer

Time sharing SYSOUT data sets are
processed by JES2 and are retrievable
via the OUTPUT command

Background jobs scheduled from a
terminal must use system facilities
rather than HASP

TSO users may submit jobs to HASP
for scheduling, inquire of their status,
and cancel them

Time sharing users may submit jobs to
JES2 for scheduling, inquire of their
status, and cancel them

Full SMF support

Figure 18. JES2 Differences From MVT/HASP and VS2 Release l/HASP

• JES2 is distributed on the MVS Starter System rather than on a separately
ordered component tape. Also, JES2 is automatically started by the system at
IPL, rather than by the operator.
• During initialization, if errors are found in the arrangement of mounted spool
volumes the operator is informed and JES2 waits for the situation to be
corrected.
Conversion Considerations

95

• Pseudo-devices are no loner used for specification of input and output devices
and internal readers. System interfaces are provided with data sets identified
by JES2-generated internal names, and the Internal Readers identified by the
presence of the name· INTRDR as the user-written Writer name in the
SYSOUT parameter of the DD statement.
• Extended setup control affects the operation of output dlevices. Output service
dequeues data for output devices based on output classes associated with each
output device, rather than according to the characteristics of the device (e.g.
special forms printer). Any of the 36 valid output classes may be specified for
a given output device. Default classes specified during job entry subsystem
generation can be overridden by the operator. The order of appearance of
dat.a sets on an output device may be different from MVT HASP for a given
job based on special forms requirements. SYSOUT is sent directly to JES2;
otherwise output service processing is compatible between JES2 and VS2
Release 1 HASP.

The JES3 Job Entry Subsystem
JES3, which includes some scheduling functions not providled by JES2 plus
support for loosely-coupled systems, is designed for the uSler with a
medium-to-Iarge job-shop environment. As with JES2, JES3 replaces the OS
readers and writers, and SYS1.SYSJOBQE. Figure 19 shows a possible JES3
multiprocessing configuration, with MVS and other systems connected via
channel-to-channel connectors (CTCs). JES3 executes in all processors. The
controlling processor in a JES3 configuration is called a Global processor; under
ASP it was called the "Support" and "Local Main" processor. The other JES3
processors are called Local processors; under ASP they wt!re called "Main" or
"Real Main" processors. The Global processor controls job input, processes job
output, and gives commands to the Local processors through the CTCs. From
the global console, the multiple processors of a JES3 complex appear as a single
system.
The primary enhancement to the ASP concept of loosely-coupled systems is
the addition of dynamic system interchange (DSI). In case the Global processor
fails, DSI allows the functions of the Global processor to be switched
(operator-assisted) to any attached MVS Local processor. This processor then
becomes the Global processor for itself and any MVS or MVT processor which
is attached to it.

96

OS/VS2 Planning Guide for Release 2

Global Processor

Local Processor

MVS

MVS

Up to 3 MVS
Local Processors
can be connected
Local Processor
Shared JES3
Job Queue
CTC*

ASP Main Processor
VS2-1
or
MVT
CTC

Maintask

-B

SYS1.SYSJOBQE

Up to 29 MVT or
VS2 Release 1 Main
Processors can be
attached.

ASP Main Processor
VS2-1
or
MVT

r
r---.

~

CTC
Maintask
./

SYS1.SYSJOBQE
* A CTC connection between Local processors is recommended (not required)
to allow JES3 dynamic Global switching in the event of Global failure.

Figure 19. Sample JES3/ ASP Multiprocessing Configuration

Conversion Considerations

97

JES3 Scheduling Features

Some of the features which enhance loosely-coupled systems and assist
uniprocessing environments are:
• Pre execution setup is provided for direct access, graphic, unit record, and tape
devices which are not assigned to JES3 for job input and output functions.
JES3 determines the device and volume requirements for each job.
• Selection of a job for a processor is based on the ability of that processor to
provide sufficient devices. JES3 switches pooled devices among processors to
further control job/processor selection.
• A user exit is provided to determine which processor is eligible to execute a
given job. Information regarding current workload is available at this exit.
• The operator is instructed to premount the volume(s), after the eligible
processors are determined and the devices are reserved for the job.
• Optionally, preexecution setup need occur for only the largest number of
devices used in anyone step of the job. In previous releases (through ASP
3.0), the number of devices setup was the total number of devices used in all
steps. For example:
Device
2314
2400

# used in
step 1
2
3

#used in
step 2
4
0

#used in
step 3
1

5

ASP
total

JE
to

7
8

• Multiple jobs on different processors can share direct access volumes. Data
sets, with disposition specified as shared, can also be shared between
processors.
• JES3 volumes can be set up dynamically for dynamically allocated data sets.
These devices are returned to the system when the data sets are deallocated.
• Dependent job control (DJC) allows simple or complex job interdependencies
that are present in many commercial data processing installations, to be
scheduled through JES3. The success or failure of one job under DJC can
cause execution, holding, or cancelling of other dependent jobs.
• Devices can be pooled for jobs under DJC, or for job-(~lass groups. This
alJows devices to be reserved for jobs with data set dependencies.
• Deadline Scheduling increases the probability of a job completing by a
specified time. The selection priority of the job is dynamically adjusted.
• Network job processing (NJP) allows input and output from compatible JES3
installations. Jobs cannot be transmitted between JES3 and ASP.
Job Definition

A job in the JES3 system consists of one or more job segments. A job segme:nt
(e.g., PRINT or PUNCH) is defined as a logical portion of a job. It is not
directly analogous to a job step in MVT, rather it relates the stages of job
processing. Except for jobs specifying special JES3 processes (e.g., NJP), job
segments are defined by JES3 to control the job's input, control statement
conversion, device scheduling, execution, printing and punching, and job purge.
AU JES3 support functions are implemented by dynamic support programs
(DSPs). A support function is defined as any process performed by the Global

98

OS/VS2 Planning Guide for Release 2

processor as a part of a job in the system. Tasks such as card reading, printing,
card punching, and servicing the Local and Global processors are examples of
support functions. DSPs can be activated when explicitly requested by the
operator or by nonstandard jobs.
JES3 Job Flow

All jobs are initially read into the Global processor by JES3, and are assigned a
unique JES3 job number. Jobs can be submitted via a tape, disk, or card reader
attached to the Global processor. In addition, jobs can be submitted to the global
processor from remote terminals via remote job processing (RJP), TSO terminals,
the internal reader, and from other JES3 systems via network job processing
(NJP). The job flow (see figure 20) is as follows:

Input
Service

Converter
Service

.......J------.L.L.-L.1-_...l'-J

------

Output
Service

Main
Service

Executing Job
or
System Task

Output
Processor

Print!
Punch
Services

Purge
Service

External
Writer

Figure 20. JES3 Job Flow

1. The job is read into the system and is initially placed on a spooling disk pack.
An entry for the job is placed in the JES3 job queue. The support function
that performs this task is called Input Service.

Conversion Consl"eratlons

99

2. Immediately after input service, converter service is invoked. If a special
catalogued procedure library is specified, it is opened and passed to the
converter for JCL conversion. Converter service performs two functions:
• Interprets and converts JCL into system control blocks.
• Determines job setup requirements from generated system control blocks.
During the first phase, JCL conversion and interpretration, syntax and logical
errors are detected. This early J CL analysis allows cancellation of jobs with
system or JES3 JCL errors before the job enters the setup and execution queues.
During the second phase, the system control blocks are sc:anned and the setup
requirements for each job are determined. As in the first phase, jobs with errors
are scheduled for output service, bypassing execution.
3. Jobs with no JCL errors are passed to the device scheduling function for
preexecution setup. Based on device requirements established by converter
service, devices are selected. Any necessary volumes that require mounting are
requested from the tape and DASD library console operators (See the section
called Device Scheduling).
4. Based on device requirements, initialization specifications, job definition, and
user exit, the job will be scheduled for processing on either the Global, a
Local, or a Main processor. If the selected processor is Local, the Global
processor will pass the job to the Main for processing. JES3 then signals the
selected processor to begin executing the job. After processing is complete,
control is passed to the Global processor for printing and punching. (Refer
also to the section called Job Selection and Scheduling.)
5. Output data sets are queued for the external writer, the TSO OUTPUT
command, or JES3 printers or punches.
6. Output data sets are printed by the JES3 print service function. Print service
informs the operator of any special printer setup necessary. The printer(s) can
be dther local or remote as defined by the job.
7. Output data sets are punched by the JES3 punch service function. A local or
remote punch may be defined by the job.
8. A support function, purge, releases for use by other jobs, all DASD JES3
queue space associated with the completed job. At this time the SMF purge
record is written for the job.
In most cases, the standard job sequence described abovl~ will meet the needs
of the application programmer; however, through the inclusion of JES3 control
statements in the job's JCL, the job function sequence can be altered and special
JES3 processing such as NJP can take place. The inclusion of JES3 processing
control statements in the J CL causes the job to be classified as nonstandard.
Device Scheduling

Immediately after the interpretation of the JCL for a job, a table summary of all
data set, volume, and device requirements is created. If a JOBCAT or STEPCAT
DD statement specifies a special catalog, or if access to the system catalog
determines a special catalog is needed, the catalog is dynamically allocated during
the building of this table. The table is completed when all ]CL cross reference
processing is complete and all volume and unit requirements are determined. The
job is then enqueued for selection by the device scheduling function.

100

OS/VS2 Planning Guide for Release 2

The device scheduling function selects jobs for pre execution setup by priority,
subject to workload parameters as specified by the installation.
JES3 manages all references to tape devices and mountable direct access
volumes. Jobs referencing permanently resident volumes will be automatically
routed to the Local processor on which the volume resides. Reference to
nonspecific direct access volumes are not handled by JES3; they are passed to
the system for normal allocation processing.
Jobs that require special data set volumes to be mounted are not submitted for
execution until the appropriate units are available for mounting. Instructions are
then issued to the operator to mount and/ or ready the required volumes.
All volumes are assumed to reside in an installation tape and disk library.
Messages are sent to these libraries requesting that all volumes required for
preexecution setup by JES3 be forwarded to the tape and disk setup areas. This
action is performed for each job requiring setup prior to requesting that the
volumes be mounted.
Jobs which do not require setup devices, or for which setup has already been
effected, are executed while the setup process is being carried out for other jobs.
JES3 waits for all operators involved to complete their required tasks before
allowing the job to execute on a Local processor. If all devices allocated to a job
are shared by Local processors, that job will be eligible for execution on any
Local processor to which the devices are attached. When setup is complete, the
job is released to an execution queue for processing.
In addition, device scheduling provides:
• Setup and system messages for direct access devices and tapes will be routed
to the console located nearest each device.
• Multiple jobs on different processors can share direct access volumes and data
sets. The data sets can be shared providing the disposition is specified as
shared.
• Operator commands are available to determine the status of jobs, devices, and
volumes in setup control.
• JCL references to permanently resident direct access volumes require no
operator action.
• The number of devices setup can optionally be limited to the number needed
at anyone time during the job. During deallocation the device will be returned
to the device scheduling function for use by other jobs. Devices used for
passed data sets can optionally be made available for other allocations.
Job Selection and Scheduling
Each processor in the JES3 complex requests work from the Global processor.
Jobs are selected for each processing stage in priority order. Priority is initially
established via the priority parameter on the JOB statement or with a JES3
control statement. The selection priority of a job can be changed by the operator,
by priority aging, or by deadline scheduling.
The priority aging feature allows JES3 to increase the priority of a job after it
has been passed over by the JES3 an installation-specified number of times,
either because of an insufficient number of devices or a low priority level relative

Conversion Considerations

101

to that of other jobs in the system. Raising a job's priority will cause the job to
be given preferential treatment in the selection of devices.
The deadline scheduling feature allows the installation to specify a time of day
by which the job should be scheduled. If the job is not scheduled by this time,
JES3 will increase the priority of the job at installation-defined intervals until it
is scheduled.
Certain segments of a job can be designated by a JES3 control statement to
be exeeuted in a remote processor. A job can be specified as nonstandard,
executed in a remote processor, and its output returned to the submitting
processor for printing or punching. The job can be executed in the submitting
processor and printed in the remote processor. The user can control NJP
processing or allow the operator to control it by making the job eligible for
operator-controlled transmission to another processor.
Using dependent job control (DJC), an installation can cause JES3 to control
job selection based on dependencies among jobs. With JES3 control cards, the
user can specify that one set of jobs (predecessor jobs) be eompleted ahead of
other jobs (successor jobs). Jobs in a DJC network are held after JCL
interpretation until predecessor jobs have completed execution or indicated to
JES3 that critical processing is complete. This ensures that interjob catalog and
device dependencies are resolved before setting up sucessor jobs. A device pool
can be assigned to a set of jobs under DJC, assuring the availability of critical
devices when needed.
JES3 job scheduling provides flexibility in balancing the installation workload
among the JES3 processors. When a system initiator becomes available for job
processing, JES3 selects a job by priority from the available classes, and from
among jobs requiring no setup volume mounting, or whose setup volumes have
been mounted and verified.
The installation can also specify that JES3 is to attempt to balance the CPU
and I/O load by selecting a job whose CPU-to-I/O ratio complements those jobs
currently running in the system. A CPU-to-I/O ratio is specified for each job via
a JES3 control statement, or is a default by job class. The installation can also
specify the number of initiators that can be started on each processor, and the
maximum number of jobs from anyone class which can be simultaneously
scheduled.
JES3 Operational Environment
The operational environment of the loosely coupled JES3 system is considerably
different from that of other systems. All JES3 functions for all processors are
controlled from consoles attached to the Global processor. The installation can
allow system commands to be entered and system messages to be received at
these JES3 consoles, reducing or removing the need for an operator to be
stationed at system consoles on each separate processor. The implementation of
multiple JES3 operator consoles, the separation of JES3 global functions, and the
two-way operator communication with JES3 support functions, cause the loosely
coupled complex to appear as a single system rather than composed of several
separate and independently operated computer systems.
JE83 provides an installation with flexibility in the location of machine-room
equipment. By using additional operator consoles, JES3 installations can
physically separate the operational functions (card input/output, printing, and
tape setup), locating them in areas more convenient to the local work flow. The

102

OS/VS2 Planning Guide for Release 2

card reader/punches and the printers can be located in a job dispatching area
where programs are submitted for execution and output is returned. The
mountable input/output units can be placed in an area that is convenient to the
tape and disk library. In addition, an operator console can be placed at the tape
and disk librarian's desk to receive library volume requests. The central
processing units can then be placed in some other area that is free of the
congestion that often surrounds peripheral units.
The Role of the JES3 Operator
From the Global Processor, the global console operator manages the work flow
of the JES3 complex and can modify specific jobs by changing their priorities.
Other operators control the devices attached to the Global JES3 system (such as
printers, card readers and card punches), mount and demount the Global and
Local Processor mountable units, manage the disposition of required special
volumes, and monitor the flow of jobs through the system.
Each JES3 support function (processing stage) responds to a number of
operator commands that permit the operator to cancel job processing, to restart
processing, or to resume processing after an operator intervention request. Some
functions, such as Print Service (at the print stage), provide additional options.
For each printer, processing can be restarted either at the beginning of the data
set or job, or at a checkpoint made within several pages of the current position.
. the restart can be accomplished on the same printer or on a newly assigned
printer. In addition, a request can be made to reload the Universal Character Set
buffer of a local printer. Background programs can be invoked from an operator
console as well as from the input JCL and JES3 control cards.
The JES3 console inquiry function permits the global console operator to
determine the status of the JES3 work queue, the status of a given job in the
queue, the amount of space left in the JES3 queue, a summary of the workload
backlog, and the status of the workload for any JES3 processing stage. This
inquiry feature also permits the operator to determine whether the backlogs are
adequate or too high, and to obtain an estimate of when a given job will be
processed in the current queue. With this information, and with the ability to
change job priorities or to place a job in hold status and later release it for
processing, the operator can manage the system. He can also inquire into the
status of functional components of the JES3 system, such as the number of
buffers currently in use, or invoke a support function which will display the
entire system status on a printer attached to the JES3 Global system.
The Operator's Console: Operational control is maintained at every stage of
processing for the following functions:
• Deletion of a job. The operator can delete a job from the system by issuing
the MODIFY with CANCEL message from the console.
• Restart of job processing. The operator can restart applicable job segments on
the Global Processor by issuing the RESTART message at a console.
• Change of job priority. The operator can change the priority of a particular
job. This option is usually used to expedite job processing for a particular job.
• Holding and releasing of a job in queue. The operator can withhold a job from
processing. Further, a job previously in hold status can be released to be
scheduled for additional processing. Jobs may be held and released on the
basis of priority or, if received from remote workstations, on an individual

Conversion Considerations

103

terminal basis. Jobs in hold status from a particular terminal can be released
entirely, or the operator can specify the number of jobs to be released.
• Initiation of batch support functions: Using the CALL facility, the operator
can request the system to schedule support functions (card-to-tape,
tape··to-printer, etc.) to be executed concurrently with the standard
preprocessing and postprocessing facilities.
• Dynamic reconfiguration of Global processor input/output and terminal
devices. The operator can remove, make available, or reroute the output of
such devices as printers, card reader/punches, and Local processors.
• System status inquiry. The operator can query the system regarding the job
queue for functions such as estimated processor running time and estimated
number of lines of print. In addition, the operator can request the status of an
individual job, as well as a printout of the entire job queue status.
Messages can be sent between JES3 consoles.
Initialization, Control Statements, and Commands

During initialization, JES3 configuration and processing options are defined in
much the same manner as with ASP. This process is controlled by JES3
initialization control cards and allows the user flexibility in modifying JES3
operation.
Initialization consists of:
• Loading the resident portion of the JES3 system.
• Loading optional modules.
• Formatting the JES3 queue devices if necessary.
• Allocating disk space for JES3 data sets.
• Defining job scheduling algorithms.
.• Defining installation standards.
• Defining console message routing.
• Defining the number of processors and the operating characteristics of each.
• Establishing support processor device allocation tables.
• Starting of procedures on selected Main processors.
JES3 processes JCL statements in a manner similar to MVT ASP or VS2
Release 1 ASP. Minimal syntax change to existing J CL is required.
JES3 control cards communicate special instructions to the system for forms
contro] on the printer or card punch, the requirements for execution on a specific
processor, and special scheduling requirements for job processing.
JES3 / ASP Compatability

Unlike ASP which is an optional extension of OS/360, JES3 is a componenet of
MVS. 1ES3 functions totally replace SYS 1.SYSJOBQE and the OS readers and
writers. Figure 21 relates some of the JES3 compatability items to the systems
which support them.

104

OS/VS2 Planning Guide for Release 2

MVT/ASP 3.0

VS2 Release 1/ASP 3.1

VS2 Release 2/JES3

A single system job queue
for multiple OS/MVT CPUs.

A single system job queue
for intermixed MVT and
VS2 multiple CPUs.

A single system job queue
for intermixed MVT, VS2-1 ,
VS2-2 multiple CPUs.

All SYSI N/SYSOUT data
is sent across the CTC.

All SYSIN/SYSOUT data
is sent across the CTC.

JES3 systems share the
spool queue. The CTC is'
used for control information
only.
MVT and VS2-1 SYSIN/
SYSOUT data is sent across
the CTC.

I

I

SYSOUT blocking is
required in the Main
processor.

SYSOUT blocking is
required in the Main
processor.

SYSOUT blocking is
transparent to the VS2-2
user. It is required in MVT
and VS2-1 processors.

ASP 'hot-jobs' remain
active in the event of
Support Processor or ASP
failure.

ASP 'hot-jobs' remain
active in the event of
Support Processor or ASP
failure.

All jobs running in the
failing system are lost but
jobs in other systems are not.

The Reader/I nterpreter
function for all CPUs is
executed in the Support
Processor.

The Reader/Interpreter
function for all CPUs is
executed in the Support
Processor.

The Converter and
Interpreter functions are
executed in the Global
Processor for VS2-2, and the
R/I function executed in the
support processor for MVT
and VS2-1.

Main storage can be
partitioned (fenced) for
assignment to specific job
groups.

Main storage can be
partitioned for MVT
processors only. It is not
applicable to VS.

Main storage can be
partitioned for MVT
processors only. It is not
applicable to VS.

ASP Dynamic Dispatching.

Available for MVT
processors only. VS2
provides a dynamic
dispatch ing function.

Available for MVT
processors only. VS2
provides a dynamic
dispatching function.

ASP job ENQ occurs at
the volume level.

ASP job ENQ occurs at
the volume level.

JES3 job ENQ occurs at
the data set name level.

Pre and post-SYSGEN
modification is necessary.

Pre and post-SYSGEN
modification is necessary.

There is a J ES3 generation
process.

No support.

3270 Light Pen support.

3270 Light Pen and Function
Key support.

Operator control via ASP
Console Service. The CTC
is the System Master
Console.

Operator control via ASP
Console Service. The CTC
is the System Master
Console.

Operator control is via JES3
Console Service. Messages
and commands are optionally
routed to JES3 Console
Service via the CTC.

No Checkpoint/Restart
support.

No Checkpoint/Restart
support.

Full Checkpoint/Restart
support.

ASP accounti ng.

ASP accounting.

ASP accounting is
eliminated. Full SMF
support is available.

MCS route codes are
ignored by ASP.

MCS route codes are
ignored by ASP.

MCS route codes can be
mapped onto JES3 route
codes for VS2-2 processors
(only).

POLY ASP is supported.

POL YASP is supported.

POL Y ASP is not supported.

Figure 21. JES3 Differences From MVT ASP and VS2 Release 1 ASP

Conversion Considerations

105

SMF Considerations
System management facilities (SMF) collect and record system and job
information. The information can be used for job accounting and management
information reports.
Most of the changes to SMF records and exits for MVS have been made to
support new system control program design. Because these changes could affect
existing data reduction routines, all records and exits should be studied to
determine what effect the changes might have.
The following topics describe the changes that have been made to SMF for
MVS.

Differences from VS2 Release 1 System Management Facilities
The most significant differences from VS2 Release 1 are:
• SMF records contain additional accounting information to record new system
environmental characteristics.
• New SMF exits from the control program are provided.
• SMF supports an output limiting facility.
• The SMF data sets, SYS I.MANX and SYS.MANY, must be cataloged.
• The SMFDEFLT list in SYS l.P ARMLIB has been changed. Multiple SMF
SYS l.P ARM LIB members may be maintained. Their names are of the form
SMFI)RMxx. Some of the parameters in these members are also different. See
the topic "IBM-Created Lists" in the chapter "Defining the System" for a
more detailed description.
• The type 20 Job Initiation record is now considered a job record and no
longer controlled by the DSV option.
• The same SYS l.P ARM LIB member is applicable to background and
foreground use.

Differences from MVT System Management Facilities
In addition to the preceding, the most significant differences from MVT are:
• SMF is a standard facility of MVS.
• SMF does not support tape for recording SMF data.

SMF Record Differences for MVS
Figure 22 indicates how the SMF records have changed for ~[VS. The following
topics explain why some of the more significant changes were made.

106

OS/VS2 Planning Guide for Release 2

Record
Type

Differences Between VS2
Release 2 and MVT

Differences Between VS2
Release 2 and MFT

Virtual storage statistics added

Virtual storage statistics added

******

**** .. *

1

---

---

---

---

2

******

** .. * .. *

******

*** ... * ..

3

* ... ****

*****'*

******

******

SYSIN/SYSOUT EXCP counts
eliminated
Virtual storage statistics added
VIO statistics added
Paging statistics added
CPU time statistics separated
into two fields
System resource manager
statistics added
CPU time statistics separated
into two fields

Virtual storage statistics added
VIO statistics added
Paging statistics added
CPU time statistics separated
into two fields

SYSIN/SYSOUT EXCP counts
eliminated
Virtual storage statistics added
VIO statistics added
Paging statistics added
CPU ti me statistics separated
into two fields -

System resources manager
statistics added
CPU time statistics separated
into two fields

System resources manager
statistics added
CPU time statistics separated
into two fields

SYSIN/SYSOUT EXCP counts
eliminated
Virtual storage statistics added
VIO statistics added
Pagi ng statistics added
CPU time statistics separated
into two fields
System resources manager
statistics added
CPU time statistics separated
into two fields

6

Job entry subsystem change

Job entry subsystem change

Job entry subsystem change

Job entry subsystem change

7

******

******

**-5-***

******

8

******

******

******

******

5

9
10

******

******

******

******

11

******

******

12

---

---

---

MP statistics eliminated

******
******

******'

* ... * ... **

MP statistics eliminated

---

---

---

13
14

VIO statistics added

VIO statistics added

VIO statistics added

VIO statistics added

15

VIO statistics added

VIO statistics added

VIO statistics added

VIO statistics added

N/A

N/A

17

******

**** .. *

******

*** .. **

18

******

*****'*

******

* .. ****

19

******

******

*** ... **

* .. ****

20

******

******

******

21

******

* ... ****

*** .. **

******
*** ...... *

22

New record for MP statistics

New record for MP statistics

New record for MP statistics

New record for MP statistics

26

New record for job entry subsystem
statistics

New record for job entry subsystem
statistics

New record for job entry subsystem
statistics

New record for job entry subsystem
statistics

30
31

S

Differences Between VS2
Release 2 and VS1

0

4

-

Differences Between VS2
Release 2 and VS2 Release 1

32
33

--This record is now written when the
MODI FY TCAM command with the
TS option is issued.

N/A
New record for time sharing
statistics

--This record is now written when the
MODIFY TCAM command with the
TS option is issued

---

N/A

---

---

N/A

---

Figure 22. Changes to SMF Records for VS2 Release 2 (Part 1 of 2)

N/A
New record for time sharing
statistics

I
I

I

N/A
N/A

Record
Type
34

35

Differences Between. VS2
Release 2 and VS2 Release 1
Virtual storage statistics added
via statistics added
Paging statistics added
CPU time statistics separated
into two fields

New record for time sharing
statistics
CPU time statistics separated
into two fields

System resources manager statistics
added
CPU time statistics separated
into two fields

New record for time sharing
statistics
CPU time statistics separated
into two fields

38

N/A

40

******

41

---

N/A

42

---

N/A

43
44

Differences Between VS2
Release 2 and MVT

Differences Between VS2
Release 2 and VS 1

Virtual storage -statistics added
Paging statistics added
CPU time statistics separated
into two fields
System resources manager statistics
added
CPU ti me statistics separated
into two fields

---

New record for dynamic allocation
statistics

******

I

New record for time sharing
statistics
CPU time statistics separated
into two fields

I

I

---

statistics

N/A

New record for job entry subsystem
statistics

---

N/A
New record for dynamic a!!ocation

N/A

---

Job entry subsystem change

N/A

New record for time sharing
statistics
CPU time statistics separated
into two fields

via statistics added

N/A

New record for job entry subsystem
statistics

Differences Between VS2
Release 2 and MFT

New record for job entry subsystem
statistics

N/A

N/A

45

New record for job entry subsystem
statistics

New record for job entry subsystem
statistics

New record for job entry subsystem
statistics

I

New record for job entry subsystem
statistics

47

New record for job entry subsystem
statistics

Job entry subsystem change

New record for job entry subsystem
statistics

I

New record for job entry subsystem
statistics

48

New record for job entry subsystem
statistics

Job entry subsystem change

New record for job entry subsystem
statistics

49

New record for job entry subsystem
statistics

New record for job entry subsystem
statistics

New record for job entry subsystem
statistics

I

New record for job entry subsystem
statistics
New record for job entry subsystem
statistics

62

******

******

New record for VSAM statistics

New record for VSAM statistics

63

******

New record for VSAM statistics

******

New record for VSAM statistics

New record for VSAM statistics

67

******

******
******
******

New record for VSAM statistics

64

New record for VSAM statistics

New record for VSAM statistics

68

******

******

New record for VSAM statistics

New record for VSAM statistics

******

New record for VSAM statistics

New record for VSAM statistics

70

New record for MF 11

New record for MF/1

New record for MF 11

New record for MF 11

71

New record for MF/l

New record for MF 11

New record for MF/1

New record for MF 11

72

New record for MF 11

New record for MF /1

New record for MF /1

New record for MF /1

73

New record for MF/1

New record for MF/1

New record for MF/1

New record for MF 11

74

New record for MF 11

New record for MF/1

New record for MF/1

New record for MF /1

69

---

******

0
••
ecord nOl+ suppv. led
~r+

******

....,. sta"sdCS
+i +"
Sall.e

Figure 22. Changes to SMF Records for VS2 Release 2 (Part 2 of 2)

N.I A

,,,.
No. appl ....able
+

New System Resources Manager Data
SMF record types 4, 5, 34, and 35 (step termination, job termination,
time-sharing step termination and LOGOFF) provide new information obtained
from system resources management routines. Fields in record types 4 and 34 are
now used to record step termination data such as VIO page-ins, VIO page-outs,
total page-ins, and total page-outs. Fields in record types 5 and 35 are used to
record job termination data such as:
• Total number of service units used by a background job (type 5) or a terminal
job (type 35).
• The total amount of time that the background job was active (type 5).
• The total amount of time that all transactions were active (type 35).
• The total number of transactions.
This information can be used to approximate TSO terminal response time for a
session, and for adjusting IPS values in an attempt to obtain desired response
time. (See the chapter "Directing the Use of System Resources" for a description
of an installation performance specification (IPS) and service units.)

SMF Recording Replaced by MF / t
Two records, type 1 (wait time) and type 12 (end-of-day), are no longer
supported because the system activity measurement facility (MF /1) now records
the data in place of SMF. The information from record types 1 and 12 is now in
record types 70 (CPU activity) and 71 (paging activity), although record types
70 and 71 are formatted differently from record types 1 and 12. Furthermore,
MF /1 records are only written to the SMF data set when MF /1 is operationa1.
Therefore, an installation that wants to use the information that was in record
types 1 and 12 should rewrite data reduction routines to recognize the new
records and process the new format.
MF /1 processing must also be started so that the data will be gathered and
recorded.
Three other new records (types 72, 73, and 74) have been created to record
MF /1 data. See the topic "Tracing" in the chapter "Directingthe Use of System
Resources" for a more detailed description of their contents.

New Storage Data
Three fields in both record types 4 and 34 now provide new step level
accounting information such as:
• Either the size of the V=R address area specified on an ADDRSPC=REAL
request, or the total size of the user's private address space for an
ADDRSPC=VIRT request.
• The amount of the user's private address space (assigned from the high
address) used for the local system queue area (LSQA), the scheduler work
area (SWA), and subpools 229 and 230.
• The amount of the user's private address space (assigned from the low
address) used for the user's programs.

Conversion Considerations

109

Job Entry Subsystem Statistics
Some SMF records have been modified and others created to record statistics
provided by the job entry subsystem. They are:
• The type 6 (output) record contains new data such as data set control
indicators, JES-assigned job numbers, output route code, and data format
error indicators. This record will be produced by the job entry subsystem and
external writer which handles all system output processing.
• The type 26 (job summary) record is produced when a job is ready to be
purged from the system. It contains information about subsystem processing
such as the type of job and how it entered the system, p:riorities for job
selection and output processing, counts of lines or puched cards generated, and
times at which the various phases of processing the job began and ended.
• Record types 43, 45, 47, 48, and 49 record information about subsystem
activity. Included is data regarding the starting or stopping of a subsystem or a
subsystem event (e.g., SIGNON). Record type 49 records the attempt to sign
on or start a line with an invalid password.
Multiprocessing Data
The type 22 record is new in MVS. It indicates the status of resources unique to
a multiprocessing configuration. It serves the same function for CPUs, channels,
and storage as record types 8, 9, 10, and 11 do for I/O devices.
Virtual Storage Access Method Data
The virtual storage access method (VSAM) generates new records (types 64, 67,
and 68) that contain information similar to existing data management SMF
records. VSAM also records statistics when a VSAM data set is opened,
allocated, and freed (record types 62, 63, and 69).
Note: Record types 63 and 67 are generated for VSAM recovery processing.
Time Sharing Record Elimination
The following record types are not supported in MVS:
• 30 -- Start TS
• 32-- Driver
• 33 -- Driver Modify
• 41-- Modify TS
• 42 -- Stop TS
These records were associated with starting and stopping TSO and with the
TSO driver. These functions have been replaced by the MODIFY TCAM
command and the system resources manager in MVS.

Changes to SMF Exits for MVS
Figure 23 indicates the changes that have been made to SMF exits in other
systems for MVS.

110

OS/VS2 Planning Guide for Relea!ie 2

Exit

IEFUJV

Difference Between
VS2 Release 2 and
VS2 Release 1

Difference Between
VS2 Release 2 and
VS1

Difference Between
VS2 Rele.~se 2 and
MVT

Difference Between
VS2 Release 2 and
MFT

This exit is also taken
after the internal text
is created

This exit is also taken
after the internal text
is created

This exit is also taken
after the internal text
is created

This exit is also taken
after the internal text
is created

IEFUIV

N/A

---

N/A

N/A

IEFUJI

******

******

******

******

IEFUSI

******

******

******

******

******

******

******

IEFUSO

New exit for output
limiting facility

IEFACTRT

Counts are in terms of
logical records rather
than physical blocks

Counts are in terms of
logical records rather
than physical blocks

Counts are in terms of
logical records rather
than physical blocks

Counts are in terms of
logical records rather
than physical blocks

IEFUTL

This exit can now be
taken from the
foreground

This exit can now be
taken from the
foreground

This exit can now be
taken from the
foreground

This exit can now be
taken from the
!oreground

There is a new interface
to extend the time limit
in micro seconds

There is a new interface
to extend the time limit
in micro seconds

There is a new interface
to extend the time limit
in micro seconds

There is a new interface
to extend the time limit
in micro seconds

For wait limits there is
no longer an extension.
A new time limit is set
for the remainder of
the step.

For wait limits there is
no longer an extension.
A new time limit is set
for the remai nder of
the step.

For wait limits there is
no longer an extension.
A new time limit is set
for the reaminder of
the step.

For wait limits there is
no longer an extension.
A new time limit is set
for the remainder of the
step.

New exit for selecting
records to be written

New exit for selecting
records to be written

New exit for selecting
records to be written

Change in exit
parameters

New exit receives
control when job is
ready to be purged
from the system

New exit receives
control when job is
ready to be purged
from the system

IEFU83

IEFUJP

--******
N/A

******

New exit receives
control when job is
ready to be purged
from the system
Exit not supported
Unchanged
Not applicable

Figure 23. Changes to SMF Exits for VS2 Release 2

Conversion Considerations

ttt

Job Control Language
Job control language statements contain information that is needed to control the
processing of jobs.
This section describes JCL facilities, parameters, and subparameters that are
either new or have changed from both VS2 Release 1 to MVS and MVT to
MVS. Figure 24 summarizes the more significant JCL changes.

112

OS/VS2 Planning Guide for Release 2

Statement
JOB

Parameter
accounting
information field

Change

C!)

ADDRSPC

Assigns pageable or nonpageable storage space, and defaults for pageable storage.

CLASS

(A-Z,0-9). The job entry subsystem enqueues the job on the associated class queue.

PERFORM

Associates jobs with performance group definitions.

'PRTY

This parameter is ignored when the JES2 job entry subsystem is used. Priority values
can be specified on a subsystem control card.

REGION
ROLL

Limits the size of variable GETMAIN requests.

•

This parameter is ignored.

•

Assigns pageable or nonpageable storage space, and defaults for pageable storage.

TYPRUN

EXEC

ADDRSPC

If TYPRUN=SCAN, the JCL is converted but does not execute.

DPRTY

The default is the value of the APG priority.

DYNAMNBR

Limits the number of data sets that a job step may hold for reuse.

PERFORM

Associates job steps with performance group definitions.

REGION
ROLL

DO

In addition to standard'OS usage, this field can be used for JES2 parameters.

Limits the size of variable GETMAIN requests.

•

This parameter is ignored; the job is not failed.

AFF

This parameter is ignored; the job is not failed.

AMP

Completes information in an access method control block (ACB) for the virtual
storage access method (VSAM) data sets.

COPIES

Specifies multiple copies of an output data set.

DCB

DEN =4 subparameter indicates 6250 bits-per-inch for 9-track tape.
FR 10 subparameter specifies the SYS1.IMAG ELIB member to be used to interpret
documents read by a 3886 OCR device.
•

DEST

Allows you to route output to specified destinations.

DYNAM

Total is added to DYNAMNBR value, if any.

FREE

Indicates when a data set is to be deallocated.

JOBCAT

Defines a private user catalog.

OUTLIM

With SYSOUT=, this parameter will specify the maximum number of logical records
(for example, print lines) that may be written into this SYSOUT data set. An SMF
exit routine is entered when ~his number is exceeded.

RETAIN
SEP
SPACE
SPLIT
STEPCAT
SUBALLOC
SYSOUT=(c,p,f)

•

o

o

HIARCHY subparameter is ignored; the job is not failed.

C!)
(!)
(!)
(!)
(!)
(!)

®

This parameter is ignored; the job is not failed.
This parameter is ignored; the job is not failed.
Has a new default value for VIO data sets.
Converted to an equivalent SPACE parameter.
Defines a private VSAM user catalog.
Converted to an equivalent SPACE parameter.
c - (A-Z, 0-9) (* is valid in JES2 only.) This output class designation is used to queue
the associated output.-l)a-ta-isdequeued in much the same manner as the MVT output
writer. p - (p=INTRDR). This data set is sent directly to input service for processing
as an input job stream.
p - (p +- INTRDR). This data set is enqueued separately for the named writer.
f - Data is enqueued separately with this alphameric forms designation.

UNIT

The SEP subparameter is ignored, the job is not failed.

VOLUME

The RETAIN subparameter is ignored; the job is not failed.

New ,or changed from MVT
New or changed from VS2 Release 1
New or changed from MVT and VS2 Release 1

Figure 24. JCL Changes for VS2 Release 2

Conversion Considerations

t 13

Changes to VS2 Release 1 JCL
The following topics describe the differences from VS2 Release 1 JCL.
Perfonnance Group Specification
The PERFORM parameter is new for MVS. It is used to assoeiate a job or job
step with any of the several performance groups specified by installation-supplied
performance group definitions. Each performance group definition specifies a rate
for providing system resources to terminal jobs or batch jobs or job steps under
varying conditions (see the chapter: "System Resources Management") .
• When PERFORM=groupnr is coded on a JOB statement, that job receives
system resources at the rate defined by the performance group identified by
'groupnr' (a number between 1 and 255).
When PERFORM=groupnr is coded on an EXEC statement, the group
number value applies only to the job step specified on the EXEC statement.
• When PERFORM.procstep=groupnr is coded on an EXEC statement, the
group number value applies to the specified step within the procedure invoked
by the EXEC statement.
If the PERFORM parameter is coded on the JOB statement, its value
overrides any value for PERFORM parameters that may be specified on the
EXEC statements for that job. If a PERFORM parameter is specified for a
procedure, its value overrides any value for PERFORM parameters that may be
specified on EXEC statements within the procedure.
If the PERFORM parameter is not coded, the default is 1 for background jobs
and 2 for foreground users. Therefore if the previous job control language for a
job is not changed, the job will be associated with one of only two possible
performance group definitions.

Assigning Job Selection Priority
The PRTY parameter of the JOB statement is ignored in MVS with the JES2 job
entry subsystem. Instead, job selection priority must be specified on a JES2
control card.
The PRTY parameter is valid with JES3.
Specifying Data Sets in Paging Space (Virtual I/O Data Sets)
A new Stage I system generation parameter, VIO, may be specified on the
UNITNAME macro instruction to identify unit names that may be used to
specify data sets that are to receive virtual I/O (VIO) processing. Any single
volume temporary data set defined by a DD statement with a unit name for
which VIO= YES was coded at system generation time, is proeessed as a virtual
I/O data set.
The DD statement that defines the temporary data set must meet the
following requirements if the temporary data set is to be allocated to the system's
paging space:
• The DSNAME parameter must not be specified unless an & name value is
supplied for it. (Data sets with non-system generated names are not allocated
to paging space).
• The data set disposition must be new or passed.

114

OS/VS2 Planning Guide for Release

J~

• The UNIT parameter must specify a unit name that indicates system paging
space. (VIO= YES must have been specified for that unit name at system
generation time.)
• Indexed sequential data set organization must not be specified on the DSORG
subparameter of the DCB parameter.
• No volume serial number may be specified.
If the SPACE parameter is not coded for virtual I/O data sets, the default value

is 10 primary and 50 secondary

b~cks

with an average block length of 1000.

Requesting Data Set Freeing at Data Set Close Time
The FREE parameter of the DD statement is new in MVS. It is used to specify
that a data set is to be freed when that data set is closed.
If FREE=END is specified, the data set is freed at the end of the job step. If
FREE=CLOSE is specified, the data set is freed when the CLOSE macro
instruction is issued for it.
If the FREE parameter is not coded, the default value is END. Therefore, if
the current job control language for a job is not changed, all data sets will be
released at the end of the job step.
If FREE=CLOSE is specified for a SYSOUT data set, the data set will be
sent to the job entry subsystem when the CLOSE macro instruction is issued.
The data set is eligible for immediate printout (spinoff).

Note: FREE=CLOSE should not be specified for a data set that is opened and
closed more than once during a job step.
Specifying the Number of Resources That May Be Held for Reuse
The DYNAMNBR parameter of the EXEC statement is new in MVS. While it
extends (dynamic allocation) and replaces the function of the DD DYNAM
statement in MVT and VS2 Release 1, it does not specify a value that limits the
number of dynamic allocations allowed to a terminal job. Rather, it specifies a
value that is used to control the number of not-in-use data sets that may be
allocated to a job step. The DYNAMNBR parameter value is added to the
number of DD statements in the job step to determine the number of data sets
with the not-in-use attribute that a job step may hold.
The value of the DYNAMNBR parameter must be within the range of 0 to
1,635. If the DYNAMNBR parameter is not coded, the default value is O.
Requesting Multiple Copies of an Output Data Set
The COPIES parameter of the DD statement is new in MVS. It specifies the
number of copies of an output data set that are to be produced by the job entry
subsystem. The COPIES parameter may be coded only when the SYSOUT
parameter is included on the DD statement.
Directing the Destination of an Output Data Set
The DEST parameter of the DD statement is new in MVS. It specifies that an
output data set is to be routed to a remote station or local device by the job
entry subsystem. The DEST parameter may be coded only when the SYSOUT
parameter is included on the DD statement.

Conversion Considerations

115

Support for Tape and Direct Access Devices
If INTRDR is not coded for the SYSOUT parameter of the DD statement, the
data set is enqueued separately for the named writer. This writer is not invoked
by the job entry subsystem -- the operator must start an exte:rnal writer to attach
any user-written writer. The main purpose of the external writer is to support
output devices not supported by the job entry subsystem, specifically tape and
direct access devices. The external writer uses the QSAM access method and any
devices supported by QSAM.

To separate output destined for an external writer from output processed by
the job entry subsystem, it is advisable to place it in separate classes not assigned
to job entry subsystem devices.
Format Record Identification for

thE~

3886 OCR Device

A new subparameter (FRID) of the DCB parameter of the DD statement is used
to specify the type of document that is supplied as input to a 3886 optical
character recognition (OCR) device. The FRID subparameter indicates the
member of the SYS1.lMAGELIB data set that is to be used for interpreting the
document to be read by the 3886 OCR device.
Output Limit Specification
The OUTLIM parameter on the DD statement is used to specify the limit for the
number of logical records to be written to an output data set. It is coded the
same way as the MVT OUTLIM parameter.
Increased Data Set Definition Capability
In MVS, as many as 1,635 DD statements may be specified for each job step. In
both MVT and VS2 Release 1, the limit was 255 DD statements per step.
Increased Volume Sharing Capability
The following additional types of volumes may be shared between jobs and job
steps in MVS:
• Private direct access volumes mounted in response to nonspecific requests .
• Direct access volumes for which deferred mounting has be:en requested.
Interpretation of the REGION Parameter
In MVS, the address space available to an individual job (user private address
space) is restricted only by the size of the individual virtual address space (16
megabytes) minus the space required for system control program use. Therefore,
for jobs that specify ADDRSPC=VIRT (requesting V=V storage), the REGION
paramet.er is not used to specify the size of the address spac(~ available to the
individual job. It is, however, used to specify the maximum value for use by the
GETMAIN service routines in servicing variable-length GETMAIN requests.
When a variable-length GETMAIN is issued that would cause the address space
allocated to a user to exceed the value of the REGION parameter, the user is
limited to the REGION parameter value. For jobs that specify
ADDRSPC=REAL (requesting V=R storage), the value specified is used to limit
the size of the address space available to the individual job.

116

OS/VS2 Planning Guide for Release 2

Job Step Dispatching Priority Default Value
In MVS, the value of the APG priority will be used as the default dispatching
priority for a step when the DPRTY parameter is not specified on the EXEC
statement. In MVT and VS2 Release 1, the default dispatching priority for the
step was the job's dispatching priority.

Changes to MVT JCL
In addition to the differences described above, two JCL parameters are new to
current MVT users.
Requesting Storage for Program Execution
The ADDRSPC parameter is new in VS. It is used to assign page able or
nonpageable storage space to a job or a job step. It may be specified as either
ADDRSPC=VIRT or ADDRSPC=REAL:
• If ADDRSPC= VIRT is specified, the job is assigned to pageable (V = V)
storage.
• If ADDRSPC=REAL is specified, the job is assigned to nonpageable
(V =R) storage .
• If the ADDRSPC parameter is not coded, the default value is VIRT.
Therefore, if the current job control language for a job is not changed, the job
will be executed in page able storage. If the job must be executed in nonpageable
storage, ADDRSPC=REAL must be specified.
If the ADDRSPC parameter is coded on the JOB statement, its value
overrides any value in the ADDRSPC parameters that may be specified in the
EXEC statements for that job.

Specifying the BTAM Online Terminal Test Option
In MVS, a new value can be specified for the EROPT subparameter of the DCB
parameter of the DD statement. If EROPT=T is coded, it indicates a request for
the basic telecommunication access method (BTAM) online terminal test option.

JES2 JCL Considerations
The JES2 job entry subsystem processes JCL statements in a manner similar to
MVT /HASP and VS2 Release l/HASP. The JCL considerations for JES2
therefore fall into two categories, depending upon whether or not an installation
currently has a HASP system. In either case, however, no syntax changes to
existing J CL will be required.
JES2 JCL for Non-HASP Users
Two significant points for installations that are unfamiliar with HASP are:
• Extended JCL facilities are provided by JES2 control cards.
• The cataloged procedure to be used for job conversion can no longer be
associated with an input stream but rather with a job class.
JES2 Control Cards: The JES2 control cards are identified by a / * in columns 1
and 2 and a JES2 control verb beginning in column 3. They are used to:
• Supply information for the JES2 separator page and card.

Conversion Considerations

117

• Identify a job selection priority (for queuing the job).
• Supply information for calculating a job selection priority if such a priority is
not explicitly stated.
• Identify volumes required by the job, so that the job is held until the required
volumes become available.
• Route system output data sets to the local printer or punclh.
• Send a message to the central computer operator.
• Specify the DDNAME of the cataloged procedure library to be used for
conversion of the job's JCL.
• Specify extended output processing setup options to be associated with data
set groups.
Assigning Job Selection Priority: A JES2 control card (priority) is used to assign
a selection priority to a job. If this control card is not included, the job entry
subsystem assigns a priority determined either by the estimated execution time
and estimated number of lines of output (values contained on another JES2
control card) or by the JES2 generation default values.
If the PRTY parameter is coded on a JOB statement, it will be ignored.

JES2 JCL for HASP Users
The two most significant points are:
• In addition to the job copies and job routing facilities, it is now possible to
specify data set copies and data set routing.
• Two new control cards have been created.
/*JOBJ>ARM Control Card: The /*JOBPARM control card was new in HASP
for VS2 Release 1 and is coded similarly for JES2. It specifit~s job-related
parameters that are used by the JES2 job entry subsystem to:
• Establish the default job selection priority.
• Control the job's processing.
• Build the JES2 separator page and card.
These parameters extend the information that previously could be specified
only on a JOB statement accounting information parameter by adding
information such as the name of the cataloged procedure library to be used for
JCL conversion.
/*OUTPUT Control Card: The /*OUTPUT control card was new in HASP for
VS2 Release 1, and is coded similarly for JES2. It specifies c;haracteristics and/or
options for groups of output data sets.
It is used in conjunction with the form number subparameter in the SYSOUT
parameter of the DD statement.
Any system output set whose DD statement form subparameter matches the
FORMS code specified on as /*OUTPUT control card, will be processed
according to the specifications of the /*OUTPUT control card.

118

OS/VS2 Planning Guide for ReleasL~m initialization

parameter 33
maximum number specified 36
dump default lists
IEAABDxx 42
IEADMPxx 42
overriding defaults with the CHNGDUMP
command 128,.125
DUMP system initialization parameter 33,31
difference from VS2 Release 1 36
DYNAM job control language parameter 113,115
dynamic address translation (DAT)
definition
156
dynamic allocation validation exit 87
dynamic device reconfiguration (DDR)
150-151
dynamic support program (DSP) 98
dynamic support system (DSS)
definition
156
NUCMAP system initialization parameter 34
system data set SYS1.DSSVM 47,49,50
dynamic system interchange (DSI) 96
DYNAMNBR job control language parameter 115,113
EC (extended control) mode
definition
156
EDIT command
136
EDIT system generation macro instruction 23,27
EDITOR system generation macro instruction 29,27
emulator 151
specified by AFFINITY macro instruction 22
EMULATOR system generation macro instruction 27
enabled page fault
definition
156
END subcommand
136
ENQ macro instruction
ensuring serial access for mUltiprocessing 151
major name restrictions for authorized programs 83
ENQ/DEQ algorithm 56
enqueue residence value (ERV) 67,56
EOD operand
125
EROPT JCL subparameter of DCB parameter 117,113
error recording data set (SYS I.LOGREC) 47
change from MVT and VS2 Release 1 49
ERV (enqueue residence value) 67,56
EXCP addressed to SYSIN/SYSOUT DCB
15,16
EXEC command
136
EXEC statement 113
execution service 92
execution task monitor 92
EXPORT verb
142
extended control (EC) mode
156
external page storage
definition
156
MF/l counts 71,70
external page table (XPT)
definition
156
external writer 94,116
fetch protection 81,87
FIB (foreground initiated background) commands 138
file protection attributes 86
FIX system initialization parameter 33,31
fixed
definition
156
fixed BLDL table
153
definition
156
system initialization parameter specification 32
153
fixed link pack area (LPA)
definition
156
specifying routines with the FIX parameter 33
fixed LP A list (IEAFIXxx) 42
fixed page
147
definition
156
foreground initiated background (FIB) commands 138
FORTLIB system generation macro instruction 27
FORTRAN G
17
FORTRAN H
17
FORTRAN system generation macro instruction 27
fragmentation
definition
156

virtual storage 13
FREE command 136
job entry subsystem support
138
FREE job control language parameter 115,113
freeing data sets 115
FRID job control language subparameter of DCB
parameter 116,113
Full ANS COBOL V2
17
functions not supported
MVT
15
VS2 Release 1 16
GAM (graphics access method)
definition
156
system generation specification 23
GOG (generation data group)
142
127
generalized trace facility (GTF)
replacement for trace and TSO trace
16
TRACE system initialization parameter 37
GENERATE system generation macro instruction 23,27
142
generation data group (GDG)
GENTSO system generation macro instruction 27
GETMAIN, restriction for variable-length
116
GJOBCTL system generation macro instruction 27
GJP (graphic job processor)
15
global
definition
156
global lock
definition
156
global processor 96
global services
definition
156
GRAPH MF/l parameter 69
graphic job processor (GJP)
15
graphics access method (GAM)
definition
156
system generation specification 23
GRAPHICS system generation macro instruction 29,27
GTF (generalized trace facility)
127
replacement for trace and TSO trace
16
TRACE system initialization parameter 37
HALT command
125,127
hard copy log 33
HARDCPY system initialization parameter 33,27
hardware error recovery management system
definition
156
HASP
156
(see also JES2)
HELP system generation macro instruction 27
HIARCHY job control language subparameter of DCB
parameter 113
hierarchy support
unsupported MVT function
15,38
highlights of VS2 Release 2 12
HOLD command 125
HOLD operand 126
HRAMsystem initialization parameter 38
HSVC system initialization parameter 38
IBM-created SYS1.PARMLIB lists 41-44
IEAABDxx (dump default list)
description 42
overriding defaults with the CHNGDUMP
command 128,125
IEAAPFxx (authorized program library list) 42
IEAAPPOO (authorized appendage list) 41
IEABLDxx (resident BLDL list) 43
IEADMPxx (dump default list)
description 42
overriding defaults with the CHNGDUMP
command 128,125
IEAFIXxx (fixed LP A list) 42
IEAIPSxx (see installation performance specification)
IEALODOO (LP A directory load list) 43
IEALP Axx (modified link pack area list) 45
IEAOPTxx (system resources management tuning parameter
list) 67,45-46

Index

163

lEAP AKOO (LP A packing list) 43
IEASYSxx (system parameter list)
description 44
recommendations for values 39
IEBUPDAT utility program 15
IEBUPDTE utility program 15
IEFACTRT SMF exit 111
IEFUIV SMF exit 111
IEFUJI SMF exit 111
IEFUJP SMF exit 111
IEFUJV SMF exit 111
IEFUSI SMF exit 111
IEFUSO SMF exit 111
IEFUTL SMF exit 111
IEFU83 SMF exit 111
IEHIOSUP utility program 15
IEHLIST utility program 143,15,16
IEHMOVE utility program 143,15,16
IEHPROGM utility program 143,28,15,16
IEHUCAT utility program 143
IMAGELIB system generation macro instruction 27
IMBMDMAP program 15
IMCOSJQD service aid
16
IMPORT verb 142
IN operand 125
indexed sequential access method (ISAM) 23
INIT operand
DISPLAY command 125
TRACK command 127
initial program loader (IPL) 30
initialization, master scheduler 30
initialization, new system data sets 28
initialization, system 30-46
parameters 30-39
input service 91
installation-created SYS l.P ARM LIB lists 45-46
installation performance specification (IPS)
58
definition
156
IEAIPSxx list 65-67,42
parameters 65-67
tuning example 73-77
109
using SMF data to adjust
installation verification procedure (IVP) 20,21
integrity, system 79-87
areas of concern 81-85
definition 79
installation responsibility 80
procedural responsibilities 86-87
interaction 156
internal reader 91
definition 156
internal writer
definition
156
interprocessor communication (IPC)
definition 156
120
interregion communication
INTERV AL MF /1 parameter 69
interval service value (ISV) 66
definition 156
10C resource factor coefficient 67
10C service definition coefficient 67,57
IOCONTRL system generation macro instruction 27
IODEVICE system generation macro instruction 23,27
I/O appendage integrity 87
I/O device activity measurement 68
I/O device activity report 72
tuning example 73
I/O load balancing algorithm 54
weighted by resource factor coefficients 67,56
I/O measure 57
I/O, Virtual 51-52
IPC (interprocessor communication)
definition 156
IPL (initial program loader) 30
IPS (see installation performance specific:ation) 58
IPS operand 126
IPS system initialization parameter 33,31
IQAORDER list 40
IRBMFlxx (MF/1 parameter list) 43
ISAM (indexed sequential access method) 23
ISV (interval service value) 66

164

OS/VS2 Planning Guide for Release 2

IVP (installation verification procedure)

20,21

JCL (job cont~ollanguage)
112-118
(see also parameters, JCL)
changes to MVT 117,113
changes to VS2 Release 1 114-117
for JES2 117-118
summary of changes 113
JCL validation exit 87
JES2
definition 156
differences from MVT /HASP and VS2
Release I/HASP 93-95
generation 24-25
highlights 12
input service 91
JCL 117-118
job flow 91
operator commands 124-131
SMF record support
no
time sharing commands 138
JES2 control cards 117-118
JES2 generation 24-25
JES3 96-105
commands 132-133,130
comparison with ASP 104-105
definition 156
generation 25,24
highlights 12
JCL 118
job flow 99
mUltiprocessing 152
job class, JES2 25
job control language (JCL)
112-118
changes to MVT
117,113
changes to VS2 Release 1 114-116
for JES2 117-118
summary of changes 113
job entry subsystem (see JES2, JES3)
data set 47,49
generation 20-21,23-25
highlights
12
job initiation record
106
job journal 93
job purge SMF exit 111
job queue data set (SYSl.SYSJOBQE) 49
unsupported MVT function
16
unsupported VS2 Release 1 function
16
job segment 98
job selection priority
117
JOB statement 113
job step dispatching priority default value
117
job summary record (SMF)
110
JOBCAT catalog 141
JOB CLASS operand 125
jobname operand 125-126
JOBPARM control card
118
JOBS operand
DISPLAY command 125
TRACK command 127
journal, job 93
link library (SYS I.LINKLIB) 47
adding installation-written members 29
link library list (LNKLSTxx) 43
link pack area (LP A)
defined
157
fixed LPA
153
modified LPA 153
pageable LPA
153
link pack area library (SYSl.LPALIB) 47
adding installation-written members 29
LINKLIB system generation macro instruction
LISTCAT verb 142
LNK system initialization parameter 33,31
LNKLSTxx (link library list) 43
load balancing 54
LOADER system generation macro instruction
local lock
definition 157

29,27

29,27

local main processor 96
local processor 96
local service
definition 157
local system queue area (LSQA)
153
definition 157
local time constant (P ARMTZ) 45
locking technique 83,149
log data sets 50
specification of output class with LOGCLS 33
specification of WTL limit with LOGLMT 33
LOGCLS system initialization parameter 33,27
LOGLMT system initialization parameter 33,27
LOGOFF command 136
LOGON command 136
system resources manager support 134
152,12
loosely coupled mUltiprocessing (MP)
LP A Oink pack area)
definition
157
fixed LPA 153
modified LPA
153
pageable LPA 153
LPA directory load list (IEALODOO) 43
LPA packing list (IEAPAKOO) 43
LSQA (local system queue area)
147
definition 157
LSQA operand
MOUNT command
128,126
START command 128,126
LSQACEL system initialization parameter 37
M operand 125
MACLIB system generation macro instruction
macro instructions, system generation
AFFINITY 22,27
ALGLIB 27
ALGOL 27
ASSEMBLER 27
CENPROCS 29,27
CHANNEL 22,27
CHECKER 27
CKPTREST 23,27
COBLIB 27
COBOL 27
CONSOLE 23,27
CTRLPROG 23,27
DAT AMGT 23,27
DATASET 23,27
DCMLIB 27
EDIT 23,27
EDITOR 29,27
EMULATOR 27
FORTLIB 27
FORTRAN 27
GENERATE 23,27
GENTSO 27
GJOBCTL 27
GRAPHICS 29,27
HELP 27
IMAGELIB 27
IOCONTRL 27
IODEVICE 23,27
LINKLIB 29,27
LOADER 29,27
MACLIB 29,27
OUTPUT 27
PAGE 29,27
PARMLIB 29,27
PLI
27
PLlLIB 27
PTOP 27
RESMODS 29,27
RPG 27
SECONSLE 29,27
SCHEDULR 23,27
SORTLIB 27
SORTMERG 27
SUPRVSOR 27
SVCTABLE 23,27

29,27

SYSUTILS 27
TELCMLIB 27
TSO 23,27
TSOPTION 27
UCS 29,27
UNITNAME 23,27
macro library (SYS1.MACLIB) 47
adding installation-written members 29
main processor 96
main storage (see real storage)
main storage hierarchy support 15
main storage occupancy algorithm 55
manual switching 151
master address space 37,38
definition 157
master scheduler initialization 30
MATRIX operand of DISPLAY command 127,125
MAXUSER system initialization parameter 34,31
MCP (message control program)
definition
157
TCAM
148
measurement facilities
MF/l
68-77
SMF 106-111
measurement facility control (MFC) 68
MEMBER MF /1 parameter 70
MEMBERS system generation parameter 28
message control program (MCP)
definition
157
TCAM 148
MFC (measurement facility control) 68
MF/l (system activity measurement facility) 68-77
definition 157
highlights 13
operation 68-69
parameters 69-70
reports 70-72
SYSl.PARMLIB member 43
tracing 72
tuning example 73-77
MF/l parameter list (IRBMFlxx) 43
MF /1 reports 70-72
channel activity 72
CPU activity 70
I/O device activity 72
paging activity 70-71
workload activity 71-72
MIC (missing interruption checker)
157
definition
initialization 30
MIN system initialization parameter 37
minimum configuration
for multiprocessing 149
for starter system 21
missing interruption checker (MIC)
definition 157
initialization 30
MLPA system initialization parameter 34,31
MN operand 126
MOD system initialization parameter 38
modified link pack area 153
system initialization parameter specification 33
modified link pack area list (IEALP Axx) 45
MODIFY command 125
MODIFY subcommand 136
MONITOR command 128,126
MONITOR subcommand 136
MOUNT command 126,128
MP (see multiprocessing)
MPA system initialization parameter 37
MPS system initialization parameter 38
MSGRT command
126
multiple address spaces 13
definition
157
specifying maximum number with MAXUSER
parameter 34
multiple locks
149
multiple virtual address spaces 13
definition
157
specifying maximum number with MAXUSER
parameter 34

Index

165

multiprocessing (MP), tightly coupled
considerations for VS2 Release 2 149-151
definition
157
highlights
12
operator command support
127
SMF record support
110
system integrity considerations 82
multiprocessing (MP), loosely coupled
12
mUltiprogramming 13
multitasking
considerations for a multiprocessing
environment 82,151
N operand
125
NET operand
127
DISPLAY command
125
HALT command
127
MODIFY command
126
START command
126
VARY command
127
Network job processing (NJP) 98,102
NIP (nucleus initialization program) 30
NJP 98,102
NOCHAN MF /1 parameter 69
NOCHRDR MF/l parameter 69
NOCOMM MF/l parameter 69
NOCPU MF/l parameter 69
NODASD MF/l parameter 69
NODEVICE MF/l parameter 69
NOGRAPH MF /1 parameter 69
nonpageable dynamic area
146-147
nonstandard job 100
non-standard control program interface 81
not-in-use data sets
115
NOTE addressed to SYSIN/SYSOUT DCB
15,16
NOOPTIONS MF/l parameter 70
NOPAGING MF/l parameter 69
NORECORD MF/l parameter 69
NOREPORT MF/l parameter 69
NOT APE MF/l parameter 69
NOTRACE MF/l parameter 69
NOUNITR MF/l parameter 69
NOWKLD MF/l parameter 69
nucleus
153
nucleus initialization program (NIP) 30
nucleus library (SYS1.NUCLEUS) 47
adding installation-written members 29
nucleus-only generation 20,15
NUCMAP system initialization parameter 34,31

o PER operand

126
operator
commands 124-131
console, JES3
103
control of multiprocessing configurations 149-151
reducing interaction during system initialization 39
OPERATOR command 136
operator commands 124-131
job entry subsystem support 128-131
multiprocessing support 127
summary of changes 125-127
system resources management support 128
time sharing support 128
VT AM support
127
operator intervention restriction 34,31
OPI system initialization parameter 34,31
OPT system initialization parameter 34,31
OPTIONS MF/l parameter 70
ordered seek queueing
16
OUT operand
CANCEL command 125
RESET command
126
OUTCLASS operand
125
OUTUM job control language paramet(~r 116,113
OUTPUT command
137
job entry subsystem support
138
OUTPUT control card
118
output limit specification
116
output record (SMF)
110

166

OS/VS2 Planning Guide for Release 2

output service 93
OUTPUT system generation macro )mstruction

27

page
definition
157
page data sets 47
adding paging space to the system 50
change from VS2 Release 1 49
definition
157
14
highlights
naming (PAGE parameter) 34
page fault
definition
157
page fixing
definition
157
page frame
definition
157
MF/l counts 71
page frame table entries
153
page-in
counts in SMF records
106
157
definition
rates and percentages in MF /1 n:ports 71
page-out
counts in SMF records
106
definition
157
rates and percentages in MF /1 reports 71
page reclamation
definition 157
rates and percentages in MF / 1 n~ports 71
page replacement algorithm 55
page stealing 55
definition
157
PAGE system generation macro instruction 29,27
PAGE system initialization parameter 34,31
adding paging space to the system 50
difference from VS2 Release 1 36
page table (PGT)
definition
157
page translation exception
definition 157
page able BLDL table
153
system initialization parameter specification 32
page able link pack area
153
creation using the CLP A parameter 32
SYS1. LPAUB 47
transient area replacement
16
pageable real storage counts 71
paging
157
definition
replacement for rollout/rollin
15
replacement for scatter load
1:5
space 50
paging activity measurement 68,70-71
paging activity report 70-71
paging device
definition
157
PAGING MF/l parameter 69
paging rate
MF/l counts 71
definition 158
paging space (page data sets) 47,50
adding paging space to the system 50
change from VS2 release 1 49
definition
158
highlights
14
naming (PAGE parameter) 34
PAL system initialization parameter 37
parameters, JCL
ADDRSPC
116-117,113
AFF
113
COPIES
115,113
DCB
113
DEST
115,113
DPRTY
117,113
DYNAM
113,115
DYNAMNBR 115,113
FREE
115,113
HIARCHY
113
OUTUM
116,113

PERFORM
113,114
PRTY 117-118,114,113
REGION
116,113
RETAIN
113
ROLL 113
SEP 113
SPACE
113
SPLIT 113
SUBALLOC
113
SYSABEND 42
SYSUDUMP 42
UNIT 113
parameters, MF /1
69-70
example 73-75
parameters, system initialization
ALTSYS 38
APF 32,31
APG 32,31
AUXLIST 37
BLDL 32,31
BLDLF 32,31
CLPA 32,31
CMD 32,31
CPQE 37
CSA 32,31
CVIO 33,31
DUMP 33,31
FIX 33,31
HARDCPY 33,31
HRAM 38
HSVC 38
IPS 33,31
LNK 33,31
LOGCLS 33,31
LOGLMT 33,31
LSQACEL 37
MAXUSER 34,31
MIN 37
MLPA 34,31
MOD 38
MPA 37
MPS 38
NUCMAP 34,31
OPI 34,31
OPT 34,31
PAGE 34,31
PAL 37
QBF 38
RAM 38
REAL 34,31
RERP 38
RSVC 38
SMF 35,31
SQA 35,31
SQACEL 37
SQS 38
SYSP 35,31
TMSL 37,38
TRACE 37
TSOAUX 37
VAL 36,31
VRREGN 36,31
WTOBFRS 36,31
WTORPLY 36,31
PARMLIB system generation macro instruction 29,27
PARMTZ (local time constant) 45
password protection
integrity 87
PASSWORD data set 48
system data sets 86,80
system libraries 86
tape data sets 86-87
PATH operand 127
PAUSE operand 125
PDS system generation parameter 28
percent channel active value 72
percent channel busy and CPU waiting value 72
PERFORM job control language parameter 113,114
performance groups
158
performance group number 66
JCL specification 114 .

time sharing LOGON command
134
performance group periods
158
definition
158
tuning example 73-77
performance group period report 71
performance group report 71-72
performance objective number 67,59-65
performance objectives 59-65
definition
158
effect of changing 76
motive for specifying 59
tuning example 73-77
performance specifications 58
performance variable 57
period duration parameter 66
PGT (page table)
definition 158
physical addresses for devices 21
physical environment, computing system 80
PL 1 system generation macro instruction 27
PL/l F
compiler 17
library
17
syntax checker 17
PL 1LIB system generation macro instruction 27
POINT addressed to SYSIN/SYSOUT DCB
15,16
preexecution setup 98,100
pre-fixed storage area (PSA)
153
PRES RES list 46,40
PRINT verb
142
priority aging
101
priority I/O queueing
16
priority, job selection
117
priority, job step dispatching 117
private address space
definition
158
size recorded by SMF 109
PROC operand 126
procedure library (SYS1.PROCLIB) 48
adding installation-written members 29
processor-only generation 20
procname operand
125
PROFILE subcommand 136
ED IT command
138
program conversion
148
programming conventions 148
V=R
146-147
multiprocessing
151-152
protected system control block 81-82
PRTY job control language parameter 116,114,113
PRTYoperand
126
PSA (pre-fixed storage area)
153
pseudo device 96
PTOP system generation macro instruction 27
Q operand
HOLD command 125
RELEASE command
126
SET command 126
QBF system initialization parameter 38
queued telecommunications access method (QT AM)
QUIESCE command 127,126
QT AM (queued telecommunications access method)

15
15

R operand
125
RAM system initialization parameter 38
reader 91,156,15,16
internal
156
OS
15,16
real address
158
definition
range set for multiprocessing
149-151
real main processor 96
real storage
ADDRSPC=REAL
148
definition
158
multiprocessing considerations 149-151
MVT
13
paging activity report of use 70-71
shared
12
Index

167

real storage management (RSM)
definition 158
real storage occupancy
resource-use algorithm 54-55
service definition coefficient MSO 67
service received during interval of 67
REAL system initialization parameter '34,31
difference from VS2 Release 1 37
Reclaim (of data set) 52
reconfiguration 149-151
definition
158
JES3
104
RECORD MF /1 parameter 69
recovery
definition
158
mUltiprocessing
150
recovery management routines 153
recovery termination manager
definition 158
initia.lization 30
refreshable
definition 158
modules in the page able link pack an:a 47
REGION job control language parameter 116,113
REGSIZE operand 126
RELEASE command
126
relocate hardware (dynamic address translation)
definition 155
remote job entry (RJE)
15
remote terminal access method (RT AM)
definition
158
remote terminal programs 25
REPORT MF/l parameter 69
REPRO verb 142
RERP system initialization parameter 38
RESET command 126
resident BLDL list (IEABLDxx) 43,44
RESMODS system generation macro instruction 29,27
resource factor coefficients 67
use of 56
resource identification 83
resource manager constants 67
resource-use routines 54-55
response/throughput bias (RTB) 66
definition
158
RET AIN job control language parameter 113
RJE (remote job entry)
15
RMTGEN 25
definition 158
options 25
ROLL job control language parameter 113
rollout/rollin 15
RPG system generation macro instruction 27
RSM (real storage management)
definition 158
RSVC system initialization parameter 38
RTAM (remote terminal access method)
definition 158
RTB (response/throughput bias) 66
definition 158
RUN subcommand 136
SAMG (system activity measurement gathering) 68
SARG (system activity report generation) 68
satellite graphic job processor (SGJP)
15
SAVE operand 126
15
scatter load
scheduler work area (SW A)
153
definition 158
SYS1.SYSJOBQE replacement 16,49
SCHEDULR system generation macro instruction 23,27
secondary storage (auxiliary storage)
155
definition
paging activity report of use 70-71
SECONSLE system generation macro instruction 29,27
security, system 86-87
segment
definition
158
segment table (SGT)
definition 158
168

OS/VS2 Planning Guide for Release 2

SEND operator command 128,126
SEND subcommand
EDIT command 138,136
OPERATOR command 137
SEND time sharing command 137
SEP job control language parameter 113
separator page 93
serialization, allocation 121,13
serialization techniques 82-83
disablement 82
ENQ/DEQ 83,151
locking 83
WAIT/POST 151
service 57
service definition coefficients 67,65
use of 57-59
service rate 59-65
definition
158
effect of change for a performance objective 76
IPS specification 67
tuning example 73-77
workload activity reports 71-72
service units 57-65
definition 158
MF/l workload activity reports 71-72
SMF record counts 106
tuning example 73-77
SERO routine
15
SER 1 routine
15
SET command
used to identify the CPU with an acceptable clock
value 127
used to restore time zone constant to IPL value 127
used to specify an IPS
126
SET operand 125
setup
JES2 96
JES3 98,100
SGJP (satellite graphic job processor)
15
SGT (segment table)
definition 158
shared DASD, recovery of 150
SIO instruction counts 72
slot
definition 158
MF/l counts 71
SMF (system management facilities)
106-111
differences from MVT
106
differences from VS2 Release 1 106
exits 111
records
107-108
system initialization parameter specification 35
SMF data sets (SYS1.MANX/SYSl.MANY) 48
change from MVT 50
change from VS2 Release 1 49
SMF operand 126
SMF parameter list (SMFPRMxx) 44
SMF system initialization paramete:r 35,31
SMFDEFLT parameter list 44,40
SMFPRMxx (SMF parameter list) 44
software recording facility
definition
158
SORT/MERGE 17
SORTLIB system generation macro instruction 27
SORTMERG system generation macro instruction 27
SPACE job control language parameter 113
SPACE system generation macro parameter 28
spin lock
definition 159
spinoff 93,94
SPLIT job control language parameter 113
spool 99
SQSA (system queue area)
153
definition 159
system initialization parameter specification 35
SQA operand 125,147
SQS system initialization paramet~:r 35,31
SQACEL system initialization parameter 37
SQA system initialization parameter 38
SSM instruction 148

stage I 20
stage II 20
standard control program interface 81
START command
128,126
START operand
127
starter system 21
minimum configuration 21
physical addresses for devices 21-22
STEPCAT catalog 141
STIDP instruction 38
STOP command
128
STOP MF/l parameter 70
STOPMN subcommand
136
STOPTR command
128,127
STORAGE operand
127
storage map, virtual
153
store protection 87
SUBALLOC job control language parameter 113
SUBMIT command
137
job entry subsystem support 138
SUBMIT operand
126
support processor 96
suspend lock
definition
159
SUPRVSOR system generation macro instruction 27
SVC library (SYSl.SVCLIB) 47
adding installation-written members 29
SVC routines calling SVC routines 84
SVC routines, installation-written
integrity considerations 85
SYSGEN specification with SVCT ABLE macro 23
SVCTABLE system generation macro instruction 23,27
SW A (scheduler work area)
153
definition
159
replacement for SYSl.SYSJOBQE
16,49
swap counts 71
swapping
definition
159
ER V effect on 67
ISV effect on 66
use by the system resources manager 57
switching, manual
151
symmetric processors
definition
159
symmetric storage configuration
definition
159
symmetricalI/O
149
SYNC subcommand
146,135
SYSABEND job control language parameter 42
SYSCTLG data set 49
conversion to VSAM format
139-145
SYSDSN major name 83
SYSGEN (see system generation)
SYSIEAOI major name 83
SYSIEECT major name 83
SYSIEFSD major name 83
SYSOUT MF/l parameter 69
SYSP system initialization parameter 35,31
SYSPSWRD major name 83
system activity measurement facility (MF/l) 68-77
definition
159
13
highlights
operation 68-69
parameters 69-70
reports 70-72
SYSl.PARMLIB member 43
tracing 72
tuning example 73-77
system activity measurement gathering (SAMG) 68
system activity report generation (SARG) 68
system area
153
system catalog (SYSCTLG) 49
139-145
conversion to VSAM format
highlights 12
system data sets 46-50
changes to MVT 50
changes to VS2 Release 1 49-50
optional 48,49
password protection 86
required 47-48
system environment recording routines (SERO and
SERl)
15

system generation
changes 25-29
JES2 generation 24-25
job entry subsystem generation 20,24-25
macro instructions (see macro instructions, system
generation)
procedures 20-29
RMTGEN 25
starter system 21-22
unsupported VS2 Release 1 macro instructions 29
system initialization 30-46
parameters 30-39
(see also parameters, system initialization)
system parameter library (SYS 1.PARMLIB) 39-46
system integrity 79-87
areas of concern 81-85
definition 79
installation responsibility 80
procedural responsibilities 86-87
system key 81
definition
159
system parameter library (SYS1.PARMLIB) 39-46
IBM-created lists 41
installation-created lists 45
required system data set 47
summary of changes 40
106-111
system management facilities (SMF)
differences from MVT
106
differences from VS2 Release 1 106
111
exits
records 107-108
system initialization parameter specification 35
system parameter list (IEASYSxx) 44
system parameter specification 37
system protection key
81
definition
159
system queue area (SQA)
153
definition
159
system initialization parameter specification 35
system resources management 54-67,73-77
definition 159
highlights
13
JCL support
114
operator command support
128
parameters 65-67
SMF records
107-108
time sharing command support
134 .
tuning example 73-77
system resources management tuning parameter list
(IEAOPTxx) 67,45-46
system restart 33
system security 86-87
system summary report 74
system workload 58
SYSUDUMP job control language parameter 42
SYSUTILS system generation macro instruction 27
SYSVTOC major name 83
SYS l.ACCT data set 50
unsupported MVT function
16
SYS l.BRODCAST data set 48
formatting
146
mounted for system initialization
138
new format description 49
SYS1.CMDLIB data set 48
adding installation-written members 29
SYS1.DCMLIB data set 48
SYSl.DSSVM data set 47
change from MVT 50
change from VS2 Release 1 49
specifying creation of a new nucleus map with the
NUCMAP parameter 34
SYS 1. DUMP data set 48
device specification by a system initialization
parameter 33
maximum number specified 36
SYS 1. HELP data set 48
SYS1.IMAGELIB data set 48
adding installation-written members 29
116
use for 3886 OCR devices
SYS1.LINKLIB data set 47
adding installation-written members 29

Index

169

SYS I.LOGREC error recording data set 47
change from MVT and VS2 Release I 49
SYS1.LPALIB data set 47
adding installation-written members 29
SYS I.MACLIB data set 47
adding installation-written members 29
SYS1.MANX data set 48
change from MVT
50
change from VS2 Release 1 49
SYS I.MANY data set 48
change from MVT 50
change from VS2 Release 1 49
SYS1.NUCLEUS data set 47
adding installation-written members 29
SYS1.PAGE data set 49
SYS1.PAGEDUMP 49
SYS 1. P ARMLIB (system parameter library)' 39-46
IBM-created lists 41
installation-created lists 45
required system data set 47
summary of changes 40
SYS1.PARMLIB lists
changes to 40
IEAABDxx 42
IEAAPFxx 42
IEAAPPOO 41
IEABLDxx 43-44
IEADMPxx 42
IEAFIXxx 42
IEAIPSxx 42
IEALODOO 43
IEALPAxx 45
IEAOPTxx 45-46
IEAPAKOO 43
IEASYSxx 44
IQAORDER 40
IRBMFlxx 43
LNKLSTxx 43
PARMTZ 45
PRES RES 46,40
SMFDEFLT
44,40
SMFPRMxx 44
VATLSTxx 46
SYS1.PROCLIB data set 48
adding installation-written members 29
SYSl.SAMPLIB data set 48
SYSl . STGINDEX data set 48
SYS l.SVCLIB data set 47
adding installation-written members 29
SYS 1.SYSJOBQE data set 49
JES2 91
JES3
96
unsupported MVT function
16
unsupported VS2 Release 1 function
16
SYS I.SYSVLOGX (see log data sets)
SYS I.SYSVLOGY (see log data sets)
SYS 1. TELCMLIB data set 48-49
adding installation-written members 29
SYS1.UADS (user attribute data set)
48
formatting
146
mounted for system initialization
138
new format description
50
SYS 1. VT AMLIB data set 49
adding installation-written members 29
SYS 1. VT AMLST data set 49
adding installation-written members 29
SYS1.VTAMOBJ data set 49
T operand
125
tape data set password protection 86-87
TAPE MF /1 parameter 69
TCAM (telecommunications access method)
conversion considerations
148
system generation specification 23
TELCMLIB system generation macro instruction 27
telecommunications access method (TCAM)
conversion considerations
148
system generation specification 23
telecommunications library (SYS 1.TELCMLIB) 48-49
adding installation-written members 29
170

OS/VS2 Planning Guide for Releas·e 2

temporary data set
51
TEST AUTH facility
51
TESTRAN program
16
tightly coupled mUltiprocessing (MP')
considerations for VS2 Release 2
149-151
definition
157
highlights
12
operator command support
127
SM.F record support
110
TIME command
137
time dependency
148
83
time-of-check-to-time-of-use problem
time sharing
accounting support
138
allocation support
134
command changes
135-137
edit support
138
job entry subsystem support
138
SMF record elimination
1 10
system resources manager support
134
time sharing integration support
138
VSAM support
134
time slicing
16
TMSL system initialization parameter 37,38
TOO clock messages 30
TP operand
125
TRACE command
127
TRACE MF/l parameter 69
trace, TSO
16
tracing, MF /1
72
SMF records
106
TRACK command
128,127
transaction
159
transient areas
16
translation tables
159
TS operand
DISPLAY command
125
TRACK command
127
TSO (see time sharing)
TSO driver
16
TSO system generation macro instruction 23,27
TSO trace
16
TSOAUX system initialization parameter 37
TSOPTION system generation macro instruction
turnaround time 73
tuning parameter list (IEAOPTxx)
67,45-46
tuning with MF/1
73-77
type I programs
17
u operand
125
UADS (see SYS1.UADS)
UADSREFM utility program
146
UCS system generation macro instruction 29,27'
unallocating data sets (see freeing data sets)
uniprocessing
159
UNIT job control language parameter
1 13
UNITNAME system generation macro instruction
121-122,23,27
114,51
specifying VIO processing
UNITR MF /1 parameter 69
units code parameter 66
unsupported MVT functions
job control language summary
113
operator command summary
125-127
SMF record summary
107 -108
summary
15-16
system data sets
50
system initialization parameters 37-38
time sharing command summary
135-137
unsupported Type I programs
17
unsupported VS2 Release 1 functions
job control language summary
113
operator command summary
125-127
SMF record summary
107 -108
summary
16
system data sets 49-50
system generation macro instructions 29
system initialization parameters 37
time sh",ring command summary
135-137

27

user address space (see private address space)
user area 153
user-assigned names
121
user attribute data set (SYS1.UADS) 48
formatting
146
mounted for system initialization 138
new format description 50
user key 85
USER operand 125
user protection key 85
USERID operand 125
user-supplied addresses 81
USERS operand
126
utility programs
IEHIOSUP 15
IEHLlST 143,15,16
IEHMOVE 143,15,16
IEHPROGM
143,28,15,16
IEHUCAT 143

v= R

(virtual equals real) address area
ADDRSPC JCL parameter specification 116-117
candidate programs 148
definition
159
programming considerations 146-147
REAL system initialization specification 34
VRREGN system initialization specification 36
V=R programming considerations
146-147
VAL system initialization parameter 36,31
validity checking 80
fetch/store operations 83
SVC routines calling SVC routines 84
unauthorized program requests for authorized library
routines 84
user-supplied addresses 81
VARY command 149,127
VATLSTxx (volume attribute list) 46
VIO (virtual I/O)
catalog for data sets (STGINDEX) 48
data set allocation 122-123
definition
159
12
highlights
JCL requirements
114-115
MF /1 report data 71
SMF record support
106
SYSGEN specification with the UNITNAME
macro 23
system initialization parameter specification 33
virtual address
definition
159
virtual equals real address area (V =R)
ADDRSPC JCL parameter specification 117
candidate programs 146-148
definition
159
REAL system initialization specification 34
VRREGN system initialization specification 36
virtual I/O (VIO)
catalog for data sets (STGINDEX) 50
definition
159
12
highlights
JCL requirements
114-115
MF /1 report data 71
SMF record support
106
SYSGEN specification with the UNITNAME
macro 2.3
system initialization parameter specification 33
virtual memory (virtual storage)
definition
159
highlights
13
virtual storage
definition
159
13
highlights

virtual storage access method (VSAM)
catalog 139-145
definition 159
12
highlights
SMF record support
110
time sharing support 134
virtual storage management (VSM)
definition 159
virtual storage map 153
virtual telecommunications access method (VT AM)
command support 125-127
highlights
12
system data sets 49
volume attribute list (V ATLSTxx) 46
volume sharing 116
139
volume table of contents (VTOC)
VRREGN system initialization parameter 36,31
VSAM (virtual storage access method)
catalog (see VSAM catalog)
definition
159
highlights
12
SMF record support
110
time sharing support 134
VSAM catalog 139-145
creating 142-143
master catalog 47
search strategy
141
structure 139-140
updating
142-143
142-143
use of access method services
VSM (virtual storage management)
159
VTAM (virtual telecommunications access method)
command support 125-127
13
highlights
system data sets 49
VT AM data sets
SYS 1. VT AMLIB 49
SYS 1. VT AMLST 49
SYS1.VTAMOBJ 49
VTOC (volume table of contents)
139
WKLD MF /1 parameter 69
workload activity measurement 68
workload activity reports 71
performance group period report 71
performance group report 71-72
system summary report 72
workload level 59-66
function of initiated jobs 63
MF /1 data in reports 71-72
tuning example 73-77
used to express service relationships between groups of
users 59
workload management 54,56,58
definition
159
WRITELOG command
127
writer
internal 156
OS 15,16
WTOBFRS system initialization parameter 36,31
WTORPLY system initialization parameter 36,31
XDAP addressed to SYSIN/SYSOUT DCB
XPT (external page table)
definition
156
2-channel switches
3886 OCR device

15,16

149
116

Index

171

172

OS/VS2 Planning Guide for Release 2

OS/VS2 Planning Guide for Release 2
G C28-0667-1

Your views about this publication may help improve its usefulness; this form
will be sent to the author's department for appropriate action. Using this
form to request system assistance or additional publications will delay response,
however. For more direct handling of such requests, please contact your
IBM representative or the IBM Branch Office serving your locality.
Possible topics for comment are:
Clarity Accuracy Completeness Organization Index Figures Examples Legibility

What is your occupation? ----------------------------_____________ _
Number of latest Technical Newsletter (if any) concerning this publication: ____________ _
Please indicate in the space below if you wish a reply.

Thank you for your cooperation. No postage stamp necessary if mailed in the U.S.A. Elsewhere, an
IBM office or representative will be happy to forward your comments.

READER'S
COMMENT
FORM

GC28-0667-1

Your comments, please ...
This manual is part of a library that serves as a reference source for system analysts,
programmers, and operators of IBM systems. Your comments on the other side of this
form will be carefully reviewed by the persons responsible for writing and publishing
this material. All comments and suggestions become the property of IBM.

Fold

I

Fold

-

-

- -

-

-

-

-

-

-

- --~

First Class
Permit 81
Poughkeepsie
New York

I
I

I
I

o
(/)

<

(/)
I\.)

""0

Qj"
::J

~.

Business Beply Mail

::J

co

G)

No postage stamp necessary if mailed in the U.S.A.

0.:
CD

I

..,0'

I
I
I

Postage will be paid by:

I nternational Business Machines Corporation
Department D58, Building 706-2
PO Box 390
Poughkeepsie, New York 12602

I

I
I
I

----------------~
Fold

Fold

I

I
I
I

I
I

I
I

l!J]3llir
(!)

International Business Machines Corporation
Data Processing Division
1133 Westchester Avenue, White Plains, New York 10604
(U.S.A. only)
IBM World Trade Corporation
821 United Nations Plaza, New York, New York 10017
(International)

c

I

I
I

I
I

I
I
I



Source Exif Data:
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
XMP Toolkit                     : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37
Create Date                     : 2012:06:08 18:40:35-08:00
Modify Date                     : 2012:06:08 23:16:27-07:00
Metadata Date                   : 2012:06:08 23:16:27-07:00
Producer                        : Adobe Acrobat 9.51 Paper Capture Plug-in
Format                          : application/pdf
Document ID                     : uuid:6890bc4d-3432-4aae-9eea-cdb5932650bc
Instance ID                     : uuid:67282d0f-20a7-413c-b705-cfd896039632
Page Layout                     : SinglePage
Page Mode                       : UseOutlines
Page Count                      : 174
EXIF Metadata provided by EXIF.tools

Navigation menu