z/OS Planning for Installation

z/OS Planning for Installation
z/OS
IBM
Planning for Installation
Version 2 Release 3
GA32-0890-30
Note
Before using this information and the product it supports, read the information in “Notices” on page 141.
This edition applies to Version 2 Release 3 of z/OS (5650-ZOS) and to all subsequent releases and modifications
until otherwise indicated in new editions.
Last updated: July 17, 2017
© Copyright IBM Corporation 2002, 2017.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Tables . . . . . . . . . . . . . . . v
About this document
. . . . . . . . vii
Who should read this document .
How to use this document . . .
z/OS information . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. vii
. vii
. vii
How to send your comments to IBM . . ix
If you have a technical problem .
.
.
.
.
.
.
. ix
Summary of changes . . . . . . . . . xi
Changes
Changes
Changes
Changes
in
in
in
in
z/OS
z/OS
z/OS
z/OS
V2R3 . . . . . . . . . . xi
V2R2 . . . . . . . . . . xii
V2R1 updates for September 2014 xiii
V2R1 . . . . . . . . . . xiv
Chapter 1. Learning about z/OS
. . . . 1
Introduction to z/OS elements and features . . . . 1
List of base elements and optional features . . . 2
Where are they now? . . . . . . . . . . 16
Two-year release cycle . . . . . . . . . . . 17
Methods of installing z/OS . . . . . . . . . 20
ServerPac (entitled with z/OS) . . . . . . . 20
Product ServerPac (entitled with z/OS) . . . . 21
CBPDO (entitled with z/OS) . . . . . . . 22
SystemPac (additional charge with z/OS) . . . 22
Other fee-based methods (additional charge with
z/OS) . . . . . . . . . . . . . . . 23
Web deliverable method . . . . . . . . . 23
Languages in which z/OS is available . . . . . 23
Coexistence and fallback . . . . . . . . . . 26
Understanding coexistence . . . . . . . . 26
Understanding fallback . . . . . . . . . 28
Which releases are supported for coexistence,
fallback, and migration? . . . . . . . . . 28
Platform (integration) testing by IBM . . . . . . 30
Service . . . . . . . . . . . . . . . . 31
Service policy. . . . . . . . . . . . . 31
ServerPac and Product ServerPac service level . . 31
CBPDO service level . . . . . . . . . . 32
SystemPac service level . . . . . . . . . 32
z/OS web deliverables service level . . . . . 32
PSP information . . . . . . . . . . . . 32
Consolidated service testing by IBM . . . . . 33
Maintenance after installation . . . . . . . 34
Service distribution . . . . . . . . . . . 35
Education and training . . . . . . . . . . 36
Publications . . . . . . . . . . . . . . 36
Chapter 2. Choosing the software
installation and delivery methods . . . 39
Choosing the delivery medium: tape, DVD, or
Internet. . . . . . . . . . . . . . . . 40
Choosing the Internet download method: direct
or intermediate . . . . . . . . . . . . 41
Chapter 3. Preparing the driving
system. . . . . . . . . . . . . . . 45
What is the Customized Offerings Driver? . . .
Identifying driving system software requirements
for installing z/OS using ServerPac or
dump-by-data-set SystemPac . . . . . . .
Preparing for installation . . . . . . . .
Identifying driving system software requirements
for installing z/OS using full volume dump
SystemPac . . . . . . . . . . . . . .
Identifying driving system software requirements
for installing z/OS using CBPDO . . . . . .
Driving system Wave 0 requirements . . . .
Driving system Wave 1 requirements . . . .
Driving system Wave 2 requirements . . . .
Identifying driving system software requirements
for installing subsystems . . . . . . . . .
Identifying driving system hardware requirements
. 45
. 46
. 50
. 52
.
.
.
.
54
56
56
57
. 57
58
Chapter 4. Preparing the target system
Choosing software products to install and
identifying requisites . . . . . . . . . . .
Choosing the z/OS base and optional features. .
Identifying functional requisites for z/OS
elements and features . . . . . . . . . .
Choosing IBM products that you want to run
with z/OS . . . . . . . . . . . . . .
Choosing ISV products that you want to run
with z/OS . . . . . . . . . . . . . .
Planning for the system identifier for z/OS. . .
Ordering z/OS and related IBM products . . . .
The Internet delivery process . . . . . . .
Identifying hardware requirements for the target
system . . . . . . . . . . . . . . . .
Identifying server requirements. . . . . . .
Identifying DASD space requirements . . . .
Identifying I/O device requirements . . . . .
Identifying service needed for the target system . .
If you are installing a z/OS ServerPac or Product
ServerPac order . . . . . . . . . . . .
If you are installing a z/OS CBPDO order... . .
If you are installing a z/OS SystemPac order . .
If you are installing an IBM Z server . . . . .
Using JES and SDSF with z/OS V2R3 . . . . .
ServerPac and SystemPac delivery of JES2, JES3,
and SDSF . . . . . . . . . . . . . .
Using the z/OS Font Collection with V2R1 and later
59
59
59
60
60
60
60
61
62
63
63
66
66
68
68
68
69
69
69
69
69
Choosing an installation package for installing z/OS 39
Installing z/OS without using an installation
package . . . . . . . . . . . . . . . 40
© Copyright IBM Corp. 2002, 2017
iii
Chapter 5. Preparing for customization
and test . . . . . . . . . . . . . . 71
Customizing for CEA . . . . . . . . . .
Using dynamic enablement . . . . . . . .
Deciding whether to dynamically enable . .
Dynamic enablement Step 1: Notify IBM . .
Dynamic enablement Step 2: Update parmlib .
Dynamic enablement Step 3: Establish the active
parmlib member. . . . . . . . . . .
Disabling what was enabled . . . . . . .
Scheduling test activities . . . . . . . . .
.
.
.
.
.
71
71
72
73
73
. 77
. 77
. 78
Chapter 6. Preparing for future
installations . . . . . . . . . . . . 79
System and installation requirements . . . . . . 79
Separating data from software . . . . . . . . 80
Placing data sets on specific volumes . . . . . . 83
Product sets . . . . . . . . . . . . . 83
Recommended data set placement . . . . . . 85
Implementing the recommended data set
placements . . . . . . . . . . . . . 95
Choosing a naming convention for data sets . . . 97
Using symbolic substitution . . . . . . . . 98
Using indirect catalog entries . . . . . . . . 98
Using parmlib concatenation (logical parmlib) . . . 98
DASD space utilization and performance . . . . 99
Undefined record format data sets . . . . . . 99
Using recommended block sizes for z/OS data
sets. . . . . . . . . . . . . . . . 100
Appendix A. Installation checklist
. . 101
Step 1. Plan the details . . . . . . . . .
Step 2. Order hardware and software . . . .
Step 3. If upgrading, prepare the current
environment (old target system) for the new
release. . . . . . . . . . . . . . .
Step 4. Build the driving system . . . . . .
Step 5. Build and verify the target system . . .
Step 6. Customize and test the target system . .
Step 7. Put the tested system into production (cut
over to production) . . . . . . . . . .
iv
z/OS Planning for Installation
. 101
. 103
.
.
.
.
103
103
103
106
Step 8. If upgrading, perform postmigration
customization . . . . . . . . . . .
.
. 106
Appendix B. Software requirements
for running z/OS V2R3 . . . . . . . 107
Appendix C. Additional hardware
requirements for running z/OS V2R3 . 117
Hardware requirements for z/OS Communications
Server . . . . . . . . . . . . . . . . 125
IP hardware requirements . . . . . . . . 125
SNA hardware requirements . . . . . . . 127
Appendix D. Making a copy of your
system software (cloning) . . . . . . 129
Choosing names . . . . . . . .
Initializing the new volumes . . . .
Setting up SMS . . . . . . . . .
Defining new catalogs and CSI data sets
Copying the software data sets . . .
Copying the SMP/E zones . . . . .
Making the copy usable . . . . . .
Testing . . . . . . . . . . .
Migrating to another system . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
130
131
131
131
132
133
134
134
135
Appendix E. Accessibility . . . . . . 137
Accessibility features . . . . . . .
Consult assistive technologies . . . .
Keyboard navigation of the user interface
Dotted decimal syntax diagrams . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
137
137
137
137
Notices . . . . . . . . . . . . . . 141
Terms and conditions for product documentation
IBM Online Privacy Statement. . . . . . .
Policy for unsupported hardware. . . . . .
Minimum supported hardware . . . . . .
Trademarks . . . . . . . . . . . . .
.
.
.
.
142
143
144
144
144
Index . . . . . . . . . . . . . . . 145
. 106
Tables
1.
2.
3.
4.
5.
|
|
6.
7.
Base elements and optional features in z/OS
V2R3 . . . . . . . . . . . . . . . 2
Summary of element, feature, and component
name changes, additions, deletions, and moves
in z/OS V1R5 and later . . . . . . . . 16
z/OS deliverables from September 2002
through September 2017 . . . . . . . . 17
Languages supported (in addition to U.S.
English) and the elements and features
available in each language . . . . . . . 24
Coexistence, fallback, and migration support
for recent, current, and upcoming releases . . 29
RSU content and RSU SOURCEID for each
month of 2017. . . . . . . . . . . . 34
Considerations for download methods (direct
versus intermediate) . . . . . . . . . 41
© Copyright IBM Corp. 2002, 2017
8.
9.
10.
11.
|
|
|
12.
13.
14.
Maximum amount of processor storage
supported by z/OS . . . . . . . . . . 64
IBM I/O devices and subsystems supported
by Version 2 . . . . . . . . . . . . 67
Existing font products and replacements in the
z/OS Font Collection base element. . . . . 70
FEATURENAME values for z/OS priced
features, and TCP/IP . . . . . . . . . 74
IBM middleware and application products
that require a specific version to run on z/OS
V2R3 . . . . . . . . . . . . . . 108
Functions of z/OS V2R3 that require specific
z/OS optional features or IBM products . . 108
Additional hardware requirements for z/OS
V2R3 elements and features . . . . . . . 117
v
vi
z/OS Planning for Installation
About this document
|
This document helps you to prepare to install z/OS® V2R3 (5650-ZOS) by giving you information that
you need to write an installation plan. To install z/OS means to perform the tasks necessary to make the
system operational. This process begins with the decision to either install for the first time or upgrade,
and ends when the system is ready for production. An installation plan is a record of the actions that you
need to take to install z/OS.
Who should read this document
|
|
This document is intended for experienced z/OS personnel who are planning to install z/OS Version 2
Release 3. The user of this document is assumed to be experienced in installing and managing the z/OS
operating system, subsystems, network products, non-IBM products, and other software that runs with
z/OS.
How to use this document
Use this document as a reference as you create your installation plan. Although this document is not a
step-by-step guide to planning an installation, its organization is generally chronological. For example,
learning is presented first, driving system requirements are presented before target system requirements,
and so forth.
If you would like a more detailed list of activities than what is presented in the body of this document,
see Appendix A, “Installation checklist,” on page 101.
z/OS information
This information explains how z/OS references information in other documents and on the web.
When possible, this information uses cross document links that go directly to the topic in reference using
shortened versions of the document title. For complete titles and order numbers of the documents for all
products that are part of z/OS, see z/OS Information Roadmap.
To find the complete z/OS library, go to IBM Knowledge Center (www.ibm.com/support/
knowledgecenter/SSLTBW/welcome).
© Copyright IBM Corp. 2002, 2017
vii
viii
z/OS Planning for Installation
How to send your comments to IBM
We appreciate your input on this documentation. Please provide us with any feedback that you have,
including comments on the clarity, accuracy, or completeness of the information.
Use one of the following methods to send your comments:
Important: If your comment regards a technical problem, see instead “If you have a technical problem.”
v Send an email to [email protected]
v Send an email from the Contact z/OS web page (www.ibm.com/systems/z/os/zos/webqs.html).
Include the following information:
v Your name and address
v Your email address
v Your phone or fax number
v The publication title and order number:
z/OS Planning for Installation
GA32-0890-30
v The topic and page number or URL of the specific information to which your comment relates
v The text of your comment.
When you send comments to IBM®, you grant IBM a nonexclusive right to use or distribute the
comments in any way appropriate without incurring any obligation to you.
IBM or any other organizations use the personal information that you supply to contact you only about
the issues that you submit.
If you have a technical problem
Do not use the feedback methods that are listed for sending comments. Instead, take one or more of the
following actions:
v Visit the IBM Support Portal (support.ibm.com).
v Contact your IBM service representative.
v Call IBM technical support.
© Copyright IBM Corp. 2002, 2017
ix
x
z/OS Planning for Installation
Summary of changes
This information includes terminology, maintenance, and editorial changes. Technical changes or
additions to the text and illustrations for the current edition are indicated by a vertical line to the left of
the change.
Changes in z/OS V2R3
The summary of changes that are made to z/OS Version 2 Release 3 (V2R3) Planning for Installation, as
updated September 2017, in support of z/OS Version 2 Release 3 (V2R3).
This document contains information that is previously presented in GA32-0890-06, which supports z/OS
Version 2 Release 2 (V2R2).
New server
z/OS V2R3 can run on the IBM z14™ (z14) server.
New information
z/OS V2R3 has an overall dependency on IBM 64-bit SDK for z/OS, Java™ Technology Edition, V8
(5655-DGH) and IBM 31-bit SDK for z/OS, Java Technology Edition, V8 (5655-DGG). Generally, this
dependency exists for new or enhanced functions in z/OS. Older functions that are unchanged from
previous releases, and have lower Java requirements, are expected to work with earlier supported
releases of Java. For the specific Java dependencies for each element, see Table 13 on page 108.
IBM z/OS Liberty Embedded is a new base element in z/OS V2R3.
IBM Print Transform from AFP products support dynamic enablement. See “IBM Print Transform from
AFP products” on page 76.
Changed information
The minimum driving system level for installing z/OS V2R3 is z/OS V2R1. Previously, for installing
z/OS V2R2, the driving system minimum level was z/OS V1R13.
As of z/OS V2R3, the Customized Offerings Driver is delivered on DVD only (three DVDs per order); it
is no longer delivered on IBM 3590 and 3592 tape media.
The separately licensed products, which were previously available only from the z/OS Standalone
Products ordering path, are now available for ordering from the ServerPac ordering path. These products
are now delivered as part of the z/OS ServerPac or Product ServerPac package.
Changed base elements
The following base elements are changed in z/OS V2R3:
v BCP
v CIM
v Communications Server
v Cryptographic Services
v DFSMSdfp
v Distributed File Service
v HCD
© Copyright IBM Corp. 2002, 2017
xi
v
v
v
v
v
v
v
v
v
v
v
v
IBM Knowledge Center for z/OS
IBM Tivoli® Directory Server (TDS)
Integrated Security Services
ISPF
JES2
Language Environment®
Network File System (NFS)
Runtime Library Extensions
TSO/E
z/OS Font Collection
z/OS OpenSSH
z/OS UNIX
Changed optional features
The following optional features are changed in z/OS V2R3:
v Communications Server Security Level 3
v DFSMSdss
v DFSMShsm
v DFSMSrmm
v DFSMStvs
v DFSORT
v HCM
v Infoprint Server
v JES3
v RMF™
v SDSF
v Security Server
v XL C/C++
v z/OS Security Level 3
Deleted information
Network Control Program, or NCP, is no longer supported. References to NCP are removed from this
publication.
Changes in z/OS V2R2
The summary of changes that are made to z/OS Version 2 Release 2 (V2R2) Planning for Installation, as
updated September 2015, in support of z/OS Version 2 Release 2 (V2R2).
This document contains information that is previously presented in GA32-0890-02, which supports z/OS
Version 2 Release 1 (V2R1).
New server: z/OS V2R2 can run on the IBM z13™ server.
New base elements: The following base elements are new in z/OS V2R2:
v IBM HTTP Server powered by Apache
v IBM Knowledge Center for z/OS
v IBM z/OS Management Facility (z/OSMF)
v z/OS OpenSSH
Changed base elements: The following base elements are changed in z/OS V2R2:
v BCP
v CIM
v Communications Server
xii
z/OS Planning for Installation
v
v
v
v
v
v
v
v
v
v
v
v
v
Cryptographic Services
DFSMSdfp
Distributed File Service
HCD
IBM Tivoli Directory Server (TDS)
Integrated Security Services
ISPF
JES2
Language Environment
Network File System (NFS)
Runtime Library Extensions
TSO/E
z/OS UNIX
Changed optional features: The following optional features are changed in z/OS V2R2:
v Communications Server Security Level 3
v DFSMSdss
v DFSMShsm
v DFSMSrmm
v DFSMStvs
v DFSORT
v HCM
v Infoprint Server
v JES3
v RMF
v SDSF
v Security Server
v XL C/C++
v z/OS Security Level 3
Deleted base element: IBM HTTP Server (powered by Domino®) is removed in z/OS V2R2; it is replaced
by IBM HTTP Server powered by Apache, which is new in z/OS V2R2.
Deleted optional features: The optional feature BookManager/Build is deleted in z/OS V2R2. This
feature includes the following FMIDs: HBKP300, JBKP310 (English), JBKP311 (French), JBKP312 (German),
JBKP313 (Spanish), JBKP314 (Brazilian Portuguese), JBKP315 (Canadian French).
Changes to driving system requirements:
v The minimum driving system level for installing z/OS V2R2 is z/OS V1R13. (For installing z/OS
V2R1, it was z/OS V1R12.)
v ServerPac and SystemPac now support extended format and extended addressability for zFS data sets.
v The Customized Offerings Driver (5751-COD) is shipped as zFS file systems instead of HFS file
systems.
Changes in z/OS V2R1 updates for September 2014
z/OS V2R1 as updated for September 2014.
HTTP Secure (HTTP using Secure Sockets Layer or HTTPS) for software product and service orders:
The capability to download Internet orders using HTTPS for the Product Customized Offerings (CBPDO,
ServerPac, and SystemPac), for Shopz service orders, and for SMP/E RECEIVE ORDER is provided. The
Shopz download pages provide the option to download directly to your z/OS host system using HTTPS.
The CustomPac installation dialog will allow you to specify which download method to use, prompt for
the appropriate information, and create the RECEIVE job accordingly. Secure delivery through HTTPS
was made available October 19, 2014.
Summary of changes
xiii
Changes to driving system requirements: To download your order using HTTP Secure (HTTP using
Secure Sockets Layer or HTTPS) directly to your z/OS host system, you will need:
v SMP/E V3.6 with PTFs UO01693 (Base) and UO01695 (Japanese) or higher
v CustomPac Installation Dialog level 26.20.00 or higher
v A keyring with the CA (Certificate Authority) certificate used by the IBM download server enabled, or
use the Java keystore file
v Appropriate HTTPS proxy or SOCKS proxy options, if required for your environment
Changes in z/OS V2R1
New base elements: The following base element is new in z/OS V2R1:
v z/OS Font Collection
Changed base elements: The following base elements were changed in z/OS V2R1:
v BCP
v CIM
v Communications Server
v Cryptographic Services
v DFSMSdfp
v Distributed File Service
v HCD
v IBM Tivoli Directory Server
v Integrated Security Services
v ISPF
v JES2
v Language Environment
v Library Server
v Network File System (NFS)
v Runtime Library Extensions
v TSO/E
v z/OS UNIX
Changed optional features: The following optional features were changed in z/OS V2R1:
v Communications Server Security Level 3
v DFSMSdss
v DFSMShsm
v DFSMStvs
v DFSMSrmm
v DFSORT
v HCM
v Infoprint Server
v JES3
v RMF
v SDSF
v Security Server
v XL C/C++
v z/OS Security Level 3
Deleted base element: No base element was deleted in z/OS V2R1.
Deleted FMIDs: The following FMID has been deleted in z/OS V2R1:
v
z/OS UNIX Integrated Call Level Interface (ICLI): HSAP360
New server:
xiv
z/OS Planning for Installation
v z/OS V2R1 can run on the IBM zEnterprise® EC12 (zEC12) and BC12 (zBC12) servers.
Changes to driving system requirements:
v The minimum driving system level for installing z/OS V2R1 is z/OS V1R12. (For installing z/OS
V1R13, it was z/OS V1R11.)
ServerPac and SystemPac changes:
v The Modify System Layout dialog allows you to define user data sets as HFS or zFS.
v IBM shipped data sets can be merged into user defined data sets using Merge function in Modify
System Layout.
v Existing data sets can be defined as user data sets in Modify System Layout dialog. For more details,
refer to the Dynamic HELP Facility of Define a USER Data Set panel.
v You can now use a Product ServerPac option to order only MVS™ and CICS® or only MVS or IMS™
without including a base product in the order. See “Product ServerPac (entitled with z/OS)” on page
21.
Product documentation changes: The product ID for z/OS changed to 5650-ZOS to reflect the latest
version z/OS. When an IBM product identifier changes, all documentation for the version receives new
order numbers. For a complete list of publications, and current order numbers, see z/OS Information
Roadmap.
Summary of changes
xv
xvi
z/OS Planning for Installation
Chapter 1. Learning about z/OS
z/OS (program number 5650-ZOS) is an operating system that is designed to meet the on-demand
challenges of the e-business world. z/OS delivers the highest qualities of service for enterprise
transactions and data, and extends these qualities to new applications by using the latest software
technologies.
Some highlights of z/OS are:
v The 64-bit z/Architecture® implemented by z/OS eliminates bottlenecks that are associated with the
lack of addressable memory. 64-bit real (central) storage support eliminates expanded storage, helps
eliminate paging, and can help you to consolidate your current systems into fewer logical partitions
(LPARs) or to a single native image.
v The Intelligent Resource Director (IRD) expands the capabilities of the workload manager (WLM) by
enabling resources to be dynamically managed across LPARs based on workload priorities.
v A Workload License Charges pricing model offers you flexibility in how your software product licenses
are managed and charged.
v HiperSockets™ provides high-speed, low-latency TCP/IP data communication across LPARs within the
same IBM Z® server. HiperSockets acts like a TCP/IP network within the server, eliminating the need
to use I/O subsystem operations and the need to traverse an external network to communicate
between LPARs in the same server.
v z/OS Font Collection is a new base element for z/OS and provides all fonts that are currently
marketed and serviced for the z/OS environment into one package as part of z/OS.
For more z/OS overview information, see:
v z/OS Introduction and Release Guide
v The z/OS home page (www.ibm.com/systems/z/os/zos)
Introduction to z/OS elements and features
z/OS consists of base elements and optional features:
v The base elements (or simply elements) deliver essential operating system functions. The base elements
are listed in Table 1 on page 2. When you order z/OS, you receive all of the base elements.
v The optional features (or simply features) are orderable with z/OS and provide additional operating
system functions. The optional features are listed in Table 1 on page 2.
Optional features are unpriced or priced:
– Unpriced features are shipped to you only if you order them. If you plan to use any unpriced
features, you should order them when you order your base elements. You must not wait until the
next release becomes available. Once a release's base elements are no longer orderable, neither are its
unpriced features.
To make ordering easier, the number of unpriced features has been reduced from time to time,
mainly through consolidation. The number of unpriced features is currently two: Communications
Server Security Level 3 and z/OS Security Level 3.
– Priced features are always shipped to you. When IBM packages your order, we enable the priced
features that you ordered. These features are ready to use after you install z/OS (and customize it as
needed). We disable the priced features that you did not order. Although they are installed on your
system, you cannot use them. Later on, if you decide to use them, you notify IBM and you enable
them dynamically (which is known as dynamic enablement). You dynamically enable by updating
parmlib member IFAPRDxx and you notify IBM by contacting your IBM representative.
© Copyright IBM Corp. 2002, 2017
1
Elements and features may be exclusive or nonexclusive:
v An element or feature is called exclusive to z/OS if it exists only within z/OS (not also as a separately
orderable product) and if future functional enhancements will occur only within z/OS.
v An element or feature is called nonexclusive if it exists both (1) within z/OS and (2) as a separate
product.
List of base elements and optional features
| Table 1 lists the base elements and optional features in z/OS V2R3. The following table headings are
used:
Name The name of the element or feature.
Last time changed (and equivalent product if nonexclusive)
The most recent release in which the element or feature changed. (“Change” means that one or
more of the element or feature FMID [function modification identifiers] was changed, or that the
element or feature was added to the system. A new function added through a program
temporary fix (PTF) is not considered a change. Also, for nonexclusive elements and features, the
equivalent level of the separate product is listed in parentheses.
The last release in which an element or feature was changed is considered its function level. Do
not confuse the function level with the product level. All elements and features are at the V2R3
product level, but they are at various function levels. For example, the product level of z/OS
BookManager® READ is z/OS V2R3 but its function level is OS/390® V1R1 because OS/390 V1R1
was the last release in which it changed.
|
|
Type and description
“Type” means the following:
v Whether it is a base element or optional feature
v Whether the base element or optional feature is exclusive (existing only within z/OS) or
nonexclusive (also available as a separate product)
v If an optional feature, whether it is priced or unpriced
v If an optional feature, whether it supports dynamic enablement. All of the priced features
support dynamic enablement.
Description
A brief description of the element or feature.
Table 1. Base elements and optional features in z/OS V2R3
Name
Last time
changed (and
equivalent
product if
nonexclusive)
Alternate Library z/OS V1R9
for REXX
Type
Description
Base element,
nonexclusive.
Alternate Library for REXX enables users to run compiled
REXX programs. This base element is nonexclusive to z/OS
because the following programs provide equivalent
functions:
v The Alternate Library portion of the priced product IBM
Library for REXX on zSeries V1R4 (5695-014). The
Alternate Library consists of FMIDs HWJ9143 (ENU) and
JWJ9144 (JPN). These are the same FMIDs that are in the
z/OS base element.
v The no-fee web download Alternate Library for REXX on
z/OS.
2
z/OS Planning for Installation
Table 1. Base elements and optional features in z/OS V2R3 (continued)
Name
|
|
|
|
|
|
|
|
|
|
Last time
changed (and
equivalent
product if
nonexclusive)
Type
Description
Base Control
Program (BCP)
z/OS V2R3
Base element,
exclusive.
The base control program (BCP) provides essential
operating system services. The BCP includes the I/O
configuration program (IOCP), workload management
(WLM), system management facilities (SMF), z/OS UNIX
System Services (z/OS UNIX) kernel, the program
management binder (FMID HPM77B0), IBM Health
Checker for z/OS, support for the Unicode Standard (FMID
HUN77B0), z/OS XML System Services (z/OS XML),
Capacity Provisioning (FMID HPV77B0), and System REXX
for z/OS Base.
BookManager
READ
OS/390 V1R1
Base element,
exclusive.
BookManager READ is used to display, search, and manage
online documents and bookshelves.
Bulk Data
Transfer (BDT)
OS/390 V1R2
Base element,
exclusive.
Bulk Data Transfer (BDT) provides the base services that
the optional BDT features (BDT File-to-File and BDT SNA
NJE) need to transfer data from one computer system to
another.
BookManager
READ V1R3,
5695-046)
You cannot activate any BDT functions until one or both of
the optional BDT features is enabled.
|
Bulk Data
Transfer (BDT)
File-to-File
OS/390 V1R2
Optional feature,
exclusive, priced,
can be
dynamically
enabled.
Bulk Data Transfer (BDT) File-to-File allows users at one
z/OS system in a SNA network to copy data sets to or
from another z/OS system in the network. This feature is
related to the element BDT.
Bulk Data
Transfer (BDT)
SNA NJE
OS/390 V1R2
Optional feature,
exclusive, priced,
can be
dynamically
enabled.
Bulk Data Transfer (BDT) SNA NJE allows JES3 users to
transmit jobs, output, commands, and messages from one
computer system to another within a SNA network. This
feature is related to the element BDT and the feature JES3.
Common
Information
Model (CIM)
z/OS V2R3
Base element,
exclusive.
Common Information Model (CIM) is a standard data
model for describing and accessing systems management
data in heterogeneous environments. It allows system
administrators to write applications that measure system
resources in a network with different operating systems
and hardware. To enable z/OS for cross platform
management, a subset of resources and metrics of a z/OS
system are mapped into the CIM standard data model.
Transport layer security (TLS) encryption is performed for
CIM by base element Communications Server. CIM does
not implement any of its own encryption algorithms.
Chapter 1. Learning about z/OS
3
Table 1. Base elements and optional features in z/OS V2R3 (continued)
Name
|
Last time
changed (and
equivalent
product if
nonexclusive)
Communications z/OS V2R3
Server
Type
Description
Base element,
Communications Server supports secure TCP/IP, SNA, and
exclusive, can be UNIX networking throughout an enterprise. It gives you
dynamically
the ability to connect subsystems and applications to each
enabled.
other, and to connect network devices (such as terminals
and printers) to the system.
Communications Server consists of two components: IP
Services and SNA Services. A related optional feature is
Communications Server Security Level 3.
For encryption, IP Services uses the SNMPv3 DES 56-bit
and IPSec DES 56-bit algorithms. IP Services also uses the
System SSL component of Cryptographic Services for
encryption services. SNA Services use the limited DES
algorithm for encryption.
|
Communications z/OS V2R3
Server Security
Level 3
Optional feature,
exclusive,
unpriced, cannot
be dynamically
enabled.
This feature works with the Communications Server base
element to provide stronger encryption (greater than 64
bits) than is available without this feature. This feature uses
the TDES and AES algorithms for encryption. The actual
level of encryption that takes place with this feature
installed can be configured to be less than the maximum
level enabled by this feature.
This feature is worldwide exportable subject to US export
regulations.
|
|
This feature uses System SSL, ICSF, and CPACF.
Cryptographic
Services
z/OS V2R3
Base element,
exclusive.
|
|
|
|
|
|
|
Cryptography is the transformation of data to conceal its
meaning. In z/OS, the base element Cryptographic Services
provides the following base cryptographic functions: data
secrecy, data integrity, personal identification, digital
signatures, and the management of cryptographic keys.
Keys up to 56 bits are supported by this base element. Keys
longer than 56 bits are supported by the optional feature
z/OS Security Level 3.
Cryptographic Services consists of the following
components:
v Integrated Cryptographic Service Facility (ICSF)
v Open Cryptographic Services Facility (OCSF) Base (last
changed in z/OS V1R9)
v Public Key Infrastructure (PKI) Services
v System Secure Sockets Layer (SSL).
|
DFSMSdfp
z/OS V2R3
Base element,
exclusive.
|
DFSMSdss
z/OS V2R3
Optional feature, DFSMSdss copies and moves data for backup and recovery,
exclusive, priced, and to reduce free-space fragmentation.
can be
dynamically
enabled.
4
z/OS Planning for Installation
DFSMSdfp provides storage, data, program, and device
management functions. Related optional features are
DFSMSrmm, DFSMSdss, DFSMShsm, and DFSMStvs.
Table 1. Base elements and optional features in z/OS V2R3 (continued)
|
Name
Last time
changed (and
equivalent
product if
nonexclusive)
DFSMShsm
z/OS V2R3
Type
Description
Optional feature,
exclusive, priced,
can be
dynamically
enabled.
DFSMShsm provides automated DASD storage
management, including space management for low and
inactive data, and availability management for accidental
data loss caused by local and site disasters. DFSMShsm
also lets you make effective use of tape media.
DFSMShsm requires DFSMSdss. For this reason,
DFSMShsm is not available by itself. If you want to use
DFSMShsm, you must order the DFSMShsm/DFSMSdss
combination. DFSMSdss is also available by itself for those
who do not want DFSMShsm.
|
DFSMSrmm
z/OS V2R3
Optional feature,
exclusive, priced,
can be
dynamically
enabled.
|
DFSMStvs
z/OS V2R3
Optional feature, DFSMS Transactional VSAM Services (DFSMStvs) enables
exclusive, priced, batch jobs and CICS online transactions to update shared
can be
VSAM data sets concurrently.
dynamically
enabled.
|
DFSORT
z/OS V2R3
Optional feature,
exclusive, priced,
can be
dynamically
enabled.
DFSMSrmm helps you manage your removable media as
one enterprise-wide library across systems that can share
DASD. DFSMSrmm also has a client/server function
(through TCP/IP) that enables a single enterprise-wide
library without the need for shared DASD.
DFSORT provides fast and easy sorting, merging, copying,
reporting, and analysis of your business information, and
versatile data handling at the record, field, and bit level.
DFSORT also includes the high-performance ICEGENER
facility, the versatile ICETOOL utility, symbols, and
multiple output capabilities with the powerful OUTFIL
feature.
Chapter 1. Learning about z/OS
5
Table 1. Base elements and optional features in z/OS V2R3 (continued)
Name
|
Distributed File
Service
Last time
changed (and
equivalent
product if
nonexclusive)
z/OS V2R3
Type
Description
Base element,
exclusive.
Distributed File Service provides:
v The z/OS File System (zFS). The zFS is a UNIX file
system that can be used in addition to the hierarchical
file system (HFS). zFS file systems contain files and
directories that can be accessed with z/OS UNIX
application programming interfaces (APIs). zFS file
systems can be mounted into the z/OS UNIX hierarchy
along with other local or remote file system types, such
as HFS, TFS, AUTOMNT, and NFS. The zFS does not
replace the HFS; it is complementary to the HFS. You can
use any combination of HFS and zFS file systems. The
zFS can be used for the root file system. Also, the zFS
can run sysplex-aware for read/write mounted file
systems.
For more information about the zFS, including how to
migrate data from the HFS to the zFS, see z/OS
Distributed File Service zFS Administration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v Server message block (SMB) file/print serving support.
The SMB support is based on the X/Open PC
Interworking: SMB, Version 2. Included in the support is
access to zFS, HFS, sequential, PDS, PDSE, and VSAM
data sets from Microsoft Windows 8, Microsoft Windows
7, Microsoft Windows Server 2012, Microsoft Windows
Server 2008, Windows Terminal Server on Microsoft
Windows Server 2008, SUSE Linux with Samba, and
Redhat Linux with Samba. Windows workstation users
can also exploit z/OS printer capabilities by using the
SMB file/print server interface to the z/OS Infoprint
Server feature.
For the software necessary to use the DFS or SMB
file/print serving support and other Distributed File
Service functions, see Appendix B, “Software
requirements for running z/OS V2R3,” on page 107.
The DFS and SMB support use the DES 56-bit algorithm for
encryption.
Environmental
Record Editing
and Printing
Program (EREP)
OS/390 V1R1
ESCON Director
Support
First Failure
Support
Technology™/
MVS
(FFST™/MVS)
6
Base element,
nonexclusive.
Environmental Record Editing and Printing Program
(EREP) edits and prints reports for the records that are
placed in the error recording data set (ERDS), which can be
used by IBM Support to diagnose problems.
OS/390 V1R1
Base element,
exclusive.
When your installation uses ESCON directors, the ESCON
Director Device Support feature enables reporting of
ESCON director device errors to z/OS.
OS/390 V1R2
Base element,
exclusive.
First Failure Support Technology/MVS (FFST/MVS)
provides immediate notification and first failure data
capture for software events.
(EREP MVS
V3R5, 5658-260)
z/OS Planning for Installation
Table 1. Base elements and optional features in z/OS V2R3 (continued)
Name
Last time
changed (and
equivalent
product if
nonexclusive)
GDDM
OS/390 V1R2
(GDDM/MVS
V3R2, 5695-167)
GDDM-PGF
OS/390 V1R2
(GDDM/PGF
V2R1.3,
5668-812)
GDDM-REXX
OS/390 V1R2
(GDDM-REXX/
MVS V3R2,
5664-336)
Type
Description
Base element,
nonexclusive.
GDDM provides presentation services and device-driving
capability. It includes PCLK and REXX code. Related
optional features are GDDM-Presentation Graphics Feature
and GDDM-REXX. Other GDDM associated products (IVU,
GKS, IMD) are not in z/OS, but are separately orderable
with z/OS.
Optional feature, GDDM-Presentation Graphics Feature (PGF) is a set of
nonexclusive,
programs for creating presentation material in various
priced, can be
styles. This feature is related to the base element GDDM.
dynamically
enabled.
Optional feature,
nonexclusive,
priced, can be
dynamically
enabled.
GDDM-REXX is a productivity tool that enables
programmers to prototype GDDM applications and to
create small routines and utility programs quickly and
easily. This feature is related to the base element GDDM.
Hardware Configuration Definition (HCD) defines both the
operating system configuration and the processor hardware
configuration for a system. A related optional feature is
HCM.
|
Hardware
z/OS V2R3
Configuration
Definition (HCD)
Base element,
exclusive.
|
Hardware
Configuration
Manager (HCM)
z/OS V2R3
Optional feature, Hardware Configuration Manager (HCM) is a PWS-based
exclusive, priced, client/server interface to z/OS Hardware Configuration
can be
Definition (HCD).
dynamically
enabled.
High Level
Assembler
(HLASM)
z/OS V1R10
Base element,
nonexclusive.
High Level
Assembler
Toolkit
z/OS V1R10
IBM HTTP
Server powered
by Apache
z/OS V2R2
(HLASM and
z/VM® and
z/VSE® V1R6,
5696-234)
(Toolkit feature
of HLASM and
z/VM and
z/VSE V1R6,
5696-234)
High Level Assembler (HLASM) integrates almost all
functions of past assemblers and provides extensions and
improvements. A related optional feature is High Level
Assembler Toolkit.
Optional feature, High Level Assembler Toolkit provides tools to improve
nonexclusive,
application development, debugging, and recovery. It is
priced, can be
related to the base element High Level Assembler.
dynamically
enabled.
Base element,
exclusive.
IBM HTTP Server powered by Apache is the new web
server for z/OS. It provides scalable, high-performance web
serving for critical e-business applications. It is the strategic
HTTP Server that z/OS V2R2 supports and includes
security authentication and authorization capabilities
similar to those provided in the Domino HTTP Server.
The level that is incorporated in z/OS is based on Apache
HTTP Server 2.4. In element publications, you might see
the name IBM HTTP Server - Powered by Apache V9,
which is how this level is referenced.
Chapter 1. Learning about z/OS
7
Table 1. Base elements and optional features in z/OS V2R3 (continued)
Name
|
|
|
|
|
|
IBM Knowledge
Center for z/OS
Last time
changed (and
equivalent
product if
nonexclusive)
z/OS V2R3
Type
Description
Base element,
exclusive.
IBM Knowledge Center is the IBM strategic framework for
providing Internet-based product documentation. IBM
Knowledge Center provides enhanced search technology
similar to that used for Information Centers. It also helps
you create your own local repositories and tailor the
content that is presented from them.
|
|
|
|
Softcopy Librarian makes it easier to manage and update
content for IBM Knowledge Center for z/OS. You can
download it from IBM Softcopy Librarian
(www.ibm.com/support/docview.wss?uid=swg27018846).
|
|
|
|
z/OS V2R3 includes a new release of IBM Knowledge
Center, which includes a Knowledge Center-based
replacement for the legacy LookAT facility that was used
for message look-ups.
|
IBM Tivoli
Directory Server
for z/OS (IBM
TDS for z/OS)
z/OS V2R3
Base element,
exclusive.
IBM Tivoli Directory Server for z/OS (IBM TDS for z/OS)
provides secure access for applications and systems on the
network to directory information held on z/OS using the
Lightweight Directory Access Protocol (LDAP). This
component consists of the LDAP server, LDAP client, and
utilities.
For encryption, IBM TDS for z/OS uses the DES (56 bit)
and MD5 encryption algorithms.
|
|
|
IBM z/OS
Liberty
Embedded
z/OS V2R3
Base element,
exclusive.
IBM z/OS Liberty Embedded provides a copy of the IBM
Liberty server stack for sharing between IBM z/OS
elements.
|
IBM z/OS
Management
Facility
z/OS V2R3
Base element,
exclusive.
IBM z/OS Management Facility (z/OSMF) provides a
web-based interface that helps you manage various aspects
of your z/OS systems through a browser at any time, from
any location. By streamlining some traditional tasks and
automating others, z/OSMF can help to simplify some
areas of z/OS system management.
ICKDSF (Device
Support Facility)
z/OS V1R4 z990
Compatibility
Support feature
Base element,
nonexclusive.
ICKDSF helps you perform functions that are required for
the installation and use of IBM DASD. You can also use it
to perform service functions, error detection, and media
maintenance.
(ICKDSF, z/OS.e,
and OS/390 R17,
5655-257)
8
z/OS Planning for Installation
ICKDSF was last changed in the z/OS V1R4 z990
Compatibility Support feature. This level was carried
forward to the z/OS V1R4 z990 Exploitation Support
feature and then to z/OS V1R5 and later, and is
functionally equivalent to the R17 level of the ICKDSF
product.
Table 1. Base elements and optional features in z/OS V2R3 (continued)
|
Name
Last time
changed (and
equivalent
product if
nonexclusive)
Infoprint Server
z/OS V2R3
Type
Description
Optional feature,
exclusive, priced,
can be
dynamically
enabled.
Infoprint Server helps you print files on z/OS printers from
any workstation that has TCP/IP access.
This feature consists of the following components or
functions:
v IP PrintWay™ basic mode (HMOS705, last changed in
z/OS V1R2)
v IP PrintWay extended mode
v NetSpool
v Print Interface
v Printer Inventory Manager
v Transform Interface
v z/OS Infoprint Central
IBM recommends that you use the Infoprint Server feature
IP PrintWay component, rather than the Communications
Server base element Network Print Facility (NPF) to reroute
print data to an IP network. IP PrintWay provides
improved function, capacity, performance, and usability
over NPF.
|
Integrated
z/OS V2R3
Security Services
Base element,
exclusive.
Integrated Security Services provides base security
functions for z/OS. Its components are:
v Enterprise Identity Mapping (EIM), which allows you to
map a user's identity on one system to the user's identity
on another system.
v Network Authentication Service for z/OS, which
provides Kerberos security services, including a native
Kerberos application programming interface functions
and Generic Security Service Application Programming
Interface (GSS-API) functions.
v Open Cryptographic Enhanced Plug-ins (OCEP).
As of z/OS V1R13, Distributed Computing Environment
(DCE) and Distributed Computing Environment Security
Server (DCE Security Server) are removed from the system.
IBM recommends the IBM WebSphere® Application Server,
the IBM Network Authentication Service, or the IBM Tivoli
Directory Server as replacement strategies for each of the
DCE technologies. See the Redbooks® DCE Replacement
Strategies at IBM Redbooks (www.ibm.com/redbooks).
Chapter 1. Learning about z/OS
9
Table 1. Base elements and optional features in z/OS V2R3 (continued)
|
Name
Last time
changed (and
equivalent
product if
nonexclusive)
ISPF
z/OS V2R3
Type
Description
Base element,
exclusive.
ISPF provides facilities for all aspects of host-based
software development. ISPF has four major components:
v Dialog Manager (DM). The Dialog Manager provides
services to dialogs and end users. These services include
display, variable services, input and output, user and
application profiles, table management, system interface
services, and dialog testing and debugging aids.
v Program Development Facility (PDF). PDF provides
services to assist dialog or application developers. These
include edit and browse functions, a wide range of
foreground and batch compilers, data set and catalog
utilities, TSO command interfaces, and data set search
and compare functions.
v Software Configuration and Library Manager (SCLM).
SCLM is a tool that controls, maintains, and tracks all of
the software components of the application throughout
the development cycle.
v Client/Server component. The Client/Server component
provides users who have a workstation that is running
Windows or UNIX with a graphical user interface to
ISPF application panels.
|
JES2
z/OS V2R3
Base element,
exclusive.
JES2 accepts the submission of work for the BCP. JES2
exercises independent control over its job processing
functions, whereas JES3 exercises centralized control.
z/OS V1R13 is the last release to support a staged
migration for JES2 and JES3. Starting in z/OS V2R1, your
installation must migrate to all elements of z/OS at the
same time, including JES2, JES3, or both.
|
|
JES3
z/OS V2R3
Language
Environment
z/OS V2R3
Optional feature,
exclusive, priced,
can be
dynamically
enabled.
JES3 accepts the submission of work for the BCP. JES3
exercises centralized control over its job processing
functions, whereas JES2 exercises independent control.
Base element,
exclusive.
Language Environment provides the runtime environment
for programs that are generated with C, C++, COBOL,
Fortran, and PL/I.
z/OS V1R13 is the last release to support a staged
migration for JES2 and JES3. Starting in z/OS V2R1, your
installation must migrate to all elements of z/OS at the
same time, including JES2, JES3, or both.
Inclusion of Language Environment as a base element in
z/OS does not replace the need for separate compilers.
Language Environment uses the limited DES algorithm for
encryption.
Library Server
10
z/OS V2R1
z/OS Planning for Installation
Base element,
exclusive.
Library Server converts BookManager and Information
Center documents to HTML for display through a web
browser, and provides unified organization and searching
of BookManager, PDF, and Information Center documents.
Table 1. Base elements and optional features in z/OS V2R3 (continued)
Name
|
Last time
changed (and
equivalent
product if
nonexclusive)
Type
Description
Metal C Runtime z/OS V1R13
Library
Base element,
exclusive.
The Metal C Runtime Library is a set of LPA-resident C
functions that can be called from a C program that is
created by using the z/OS XL C compiler METAL option.
MICR/OCR
OS/390 V1R1
Base element,
exclusive.
MICR/OCR provides the device support code for various
magnetic and optical devices.
Network File
System (NFS)
z/OS V2R3
Base element,
exclusive.
Network File System (NFS) is a distributed file system
protocol that allows a user on a client computer to access
files on a server over a network, much like local storage is
accessed. Both the client and server use z/OS UNIX System
Services sockets.
NFS uses the Network Authentication Service component
of Integrated Security Services for encryption.
Open Systems
z/OS V1R4 z990
Adapter Support Compatibility
Facility
Support feature
(OSA/SF)
Base element,
exclusive.
|
Resource
Measurement
Facility™ (RMF)
z/OS V2R3
Optional feature, Resource Measurement Facility (RMF) gathers data about
exclusive, priced, z/OS resource usage and performance, and provides
can be
reports on any system in a sysplex.
dynamically
enabled.
|
Runtime Library
Extensions
z/OS V2R3
Base element,
exclusive.
Runtime Library Extensions extends the runtime support
that is provided by the Language Environment base
element. It consists of:
v Common Debug Architecture (CDA) libraries
v Utilities
v UNIX System Laboratories (USL) I/O Stream Library
and USL Complex Mathematics Library
v Mathematical Acceleration Subsystem (MASS) libraries
v Automatically Tuned Linear Algebra Software (ATLAS)
libraries.
System Display
and Search
Facility (SDSF)
z/OS V2R3
Optional feature,
exclusive, priced,
can be
dynamically
enabled.
System Display and Search Facility (SDSF) provides you
with information to monitor, manage, and control your
z/OS system.
Optional feature,
exclusive, priced,
can be
dynamically
enabled.
Security Server helps you control access to protected
resources. Security Server contains one component, RACF®.
|
|
|
|
|
Security Server
z/OS V2R3
Open Systems Adapter/Support Facility (OSA/SF)
provides a user-friendly interface for monitoring and
controlling the zSeries Open Systems Adapter feature,
which provides network connectivity directly to local area
networks (LANs) and wide area networks (WANs) that
support IP and SNA protocols. OSA/SF supports Gigabit,
Token Ring, Fast Ethernet, 1000Base-T Ethernet, 10-Gigabit
Ethernet, and ATM features depending on the server on
which z/OS runs. For more information, see z Systems
OSA-Express Customer's Guide and Reference, SA22-7935.
z/OS V1R13 is the last release to support a staged
migration for SDSF. Starting in z/OS V2R1, your
installation must migrate to all elements of z/OS at the
same time, including SDSF.
Security Server uses the limited DES, CDMF, RC 40-bit,
RSA, and DSA algorithms for encryption.
Chapter 1. Learning about z/OS
11
Table 1. Base elements and optional features in z/OS V2R3 (continued)
Name
Last time
changed (and
equivalent
product if
nonexclusive)
SMP/E
z/OS V1R13
(SMP/E V3R6,
5655-G44)
Type
Description
Base element,
nonexclusive.
SMP/E is a tool for installing and maintaining software,
and for managing the inventory of installed software.
SMP/E provides a consistent and reliable method for
installing and upgrading the software in a z/OS system.
The SMP/E product allows installations that are currently
licensed for an earlier level of z/OS to order and install the
latest level of SMP/E without having to upgrade the
operating system. This capability allows products that run
on z/OS to exploit the packaging and installation
enhancements of SMP/E without requiring a later level of
the operating system. This capability also enables z/OS
installations to exploit new electronic delivery and
installation technologies in SMP/E sooner. The SMP/E
product is available at no additional charge to z/OS
installations.
The Planning and Migration Assistant (PMA), a component
of SMP/E, can help you maintain, plan for, and order new
releases of z/OS and other products. It provides reports
that use IBM-supplied data, your SMP/E consolidated
software inventory (CSI) data set, and a CustomPac
inventory file. The PMA can be found on the SMP/E home
page (www.ibm.com/systems/z/os/zos/features/smpe).
Terminal Input
Output
Controller
(TIOC)
OS/390 V1R1
Base element,
exclusive.
Terminal Input Output Controller (TIOC) is the interface
between TSO and VTAM®. It allows TSO to communicate
with the terminal hardware.
|
Time Sharing
Option/
Extensions
(TSO/E)
z/OS V2R3
Base element,
exclusive.
Time Sharing Option/Extensions (TSO/E) provides an
interactive terminal interface. As in prior releases of
TSO/E, this element includes CLISTs and REXX, but does
not include a REXX compiler.
|
XL C/C++
z/OS V2R3
Optional feature,
exclusive, priced,
can be
dynamically
enabled.
XL C/C++ consists of:
v XL C/C++ compiler
v XL C/C++ application development utilities
v Mathematical Acceleration Subsystem (MASS) libraries.
|
12
z/OS Planning for Installation
Table 1. Base elements and optional features in z/OS V2R3 (continued)
Name
|
|
|
z/OS Font
Collection
Last time
changed (and
equivalent
product if
nonexclusive)
z/OS V2R3
Type
Description
Base element,
exclusive.
z/OS Font Collection (FMID HFNT120 and HFNT12J)
provides selected fonts that are currently marketed and
serviced for the z/OS environment into one package.
Double-byte fonts for Chinese, Japanese, and Korean (CJK)
are included. Fonts that are included in z/OS Font
Collection are not available for ordering with z/OS V2R1
and later because they are provided with z/OS. The fonts
in the z/OS Font Collection are:
v AFP Font Collection for S/390® (5648-B33), includes
Japanese, Korean, Traditional Chinese, and Simplified
Chinese
|
|
|
|
|
|
|
|
v APL2® Fonts, V1.1 (5771-ADB)
v Data1 Fonts, V1.1 (5771-ADA)
v Sonoran Sans Serif Font, V1.1 (5771-ABB)
v Sonoran Sans Serif Condensed Font, V1.1 (5771-AFL)
v Sonoran Sans Serif Expanded Font, V1.1 (5771-AFN)
v Sonoran Sans Serif Headliner Font, V1.1 (5771-ADX)
v Sonoran Serif Font, V1.1 (5771-ABA)
v Sonoran Serif Headliner Font, V1.1 (5771-ADW)
v IBM Infoprint Fonts for z/OS (5648-E76), includes
Japanese, Korean, Traditional Chinese, and Simplified
Chinese
v PSF Compatibility Font feature (5655-M32), includes just
the PSF feature for the compatibility fonts, not the
executable code or the entire product
v World type fonts that were not previously available in
the z/OS environment. These fonts were part of the
InfoPrint Font Collection V3.1 available on other
operating systems. A subset of TrueType fonts from the
Worldtype libary is provided in Infoprint Transforms to
AFP for z/OS V2.3 (5655-N60).
v Selected object fonts (not source), Pi and Special
(5771-ABC), Math and Science (5771-ADT)
From a z/OS standpoint, this element owns the parts that
use SMP/E SUP/DELETE logic; therefore, you no longer
need to order the previous stand-alone products, as of
z/OS V2R1.
Chapter 1. Learning about z/OS
13
Table 1. Base elements and optional features in z/OS V2R3 (continued)
|
Name
Last time
changed (and
equivalent
product if
nonexclusive)
z/OS OpenSSH
z/OS V2R3
Type
Description
Base element,
exclusive.
z/OS OpenSSH is a port of Open Source Software release
OpenSSH 6.4p1 and provides secure encryption for both
remote login and file transfer.
z/OS OpenSSH includes the following utilities:
v ssh, a z/OS client program for logging in to a z/OS
shell. It can also be used to log in to UNIX shells on
other platforms. It is an alternative to rlogin.
v scp for copying files between networks. It is an
alternative to rcp.
v sftp for file transfers over an encrypted ssh transport. It
is an interactive file transfer program similar to ftp.
v sshd, a daemon program for ssh that listens for
connections from clients. The z/OS OpenSSH
implementation of sshd supports both SSH protocol
versions 1 and 2 simultaneously. The default sshd
configuration runs protocol version 2 only.
Other basic utilities such as ssh-add, ssh-agent,
ssh-keysign, ssh-keyscan, ssh-keygen, and sftp-server are
also included.
14
z/OS Planning for Installation
Table 1. Base elements and optional features in z/OS V2R3 (continued)
Name
|
z/OS Security
Level 3
Last time
changed (and
equivalent
product if
nonexclusive)
z/OS V2R3
Type
Description
Optional feature, z/OS Security Level 3 provides strong encryption for z/OS.
exclusive,
unpriced, cannot The components in this feature are:
be dynamically
v IBM TDS Security Level 3, which works with the IBM
enabled.
TDS base element to provide stronger encryption (greater
than 64 bits) than is available without the z/OS Security
Level 3 feature. This component uses the RC4, TDES,
and Advanced Encryption Standard (AES) algorithms for
encryption.
v Network Authentication Service Level 3, which works
with the Network Authentication Service component of
the Integrated Security Services base element to provide
stronger encryption (greater than 64 bits) than is
available without the z/OS Security Level 3 feature. This
component uses the TDES and AES algorithms for
encryption.
v OCSF Security Level 3, which was last changed in z/OS
V1R9. This component works with the OCSF component
of the Cryptographic Services base element to provide
stronger encryption (greater than 64 bits) than is
available without the z/OS Security Level 3 feature. This
component uses the TDES, DES, and RC2/RC4/RC5
algorithms for encryption.
v System Secure Sockets Layer (SSL) Security Level 3,
which works with the System SSL component of the
Cryptographic Services base element to provide stronger
encryption (greater than 64 bits) than is available without
the z/OS Security Level 3 feature. This component uses
the RC2/RC4, TDES, and AES algorithms for encryption.
This feature is worldwide exportable subject to U.S. export
regulations.
|
z/OS UNIX
System Services
z/OS V2R3
Base element,
exclusive.
z/OS UNIX System Services (z/OS UNIX) provides the
standard command interface familiar to interactive UNIX
users. This base element is made up of Application
Services, which includes the Shell and Utilities, Debugger,
and Parallel Environment.
Integrated Call Level Interface (ICLI), which was last
changed in z/OS V1R6, was removed from the z/OS V2R1
system.
Connection Manager and Process Manager, which both last
changed in OS/390 V2R7, were removed from the z/OS
V1R13 system.
zEnterprise data z/OS V2R1
Compression
(zEDC) for z/OS
Optional feature, zEDC for z/OS provides exploitation of the zEC12 and
exclusive, priced, zBC12 zEDC Express® adapter for hardware data
can be
compression.
dynamically
enabled.
Chapter 1. Learning about z/OS
15
Table 1. Base elements and optional features in z/OS V2R3 (continued)
Name
Last time
changed (and
equivalent
product if
nonexclusive)
Type
3270 PC File
OS/390 V1R2
Base element,
Transfer Program
nonexclusive.
(3270 PC File
Transfer Program
V1R1.1, 5665-311)
Description
3270 PC File Transfer Program transfers files from the host
to the workstation for offline data manipulation, updating,
or correction or for the transfer and storage of local data in
the host system.
Where are they now?
|
|
|
|
“Why can't I find that old base element in my new release?” you might ask. Or “ I never heard of that
feature; is it new?” Well, for reasons such as ordering simplification and technology improvements,
elements and features come and go, components within them move around, and names change. See
Table 2 for what has happened in z/OS V1R10 and later.
Table 2. Summary of element, feature, and component name changes, additions, deletions, and moves in z/OS V1R5
and later
|
|
|
Name
Change
When
changed
BookManager Build
This priced feature was removed from the system.
V2R2
Distributed Computing
Environment (DCE)
and Distributed
Computing
Environment Security
Server (DCE Security
Server).
This base element was removed from the system. IBM recommends the IBM
WebSphere Application Server, the IBM Network Authentication Service or
the IBM Tivoli Directory Server, or both, as replacement strategies for each of
the DCE technologies. See DCE Replacement Strategies at IBM Redbooks
(www.ibm.com/redbooks).
V1R13
Distributed Computing This base element was removed from the system. It facilitated the interaction
Environment (DCE)
between DCE clients and CICS or IMS regions. With the continued evolution
Application Support
of technology and accompanying changes in the marketplace, there is no
need for this support. If similar function is required, IBM recommends that
you use IBM WebSphere.
V1R13
DFSORT English and
Japanese panels
The panels were removed from DFSORT. For many years, these panels were
not enhanced, and they no longer matched the new functions added to
DFSORT.
V1R10
IBM HTTP Server
(powered by Domino)
This base element was removed from the system.
V2R2
IBM HTTP Server
powered by Apache
This base element was added in z/OS V2R2. It was based on Apache HTTP
Server 2.4.
V2R2
IBM Knowledge Center This base element was added in z/OS V2R2.
for z/OS
V2R2
IBM z/OS Liberty
Embedded
This base element is new in z/OS V2R3.
z/OS V2R3
IBM z/OS
Management Facility
(z/OSMF)
This product became a base element in z/OS V2R2.
V2R2
msys for Setup
This base element was removed from the system.
V1R12
SDSF
The SDSF Japanese FMID is discontinued, as of z/OS V2R3.
V2R3
16
z/OS Planning for Installation
Table 2. Summary of element, feature, and component name changes, additions, deletions, and moves in z/OS V1R5
and later (continued)
When
changed
Name
Change
Security Server
This optional feature had seven components but now has only one, RACF.
The PKI Services component moved to the Cryptographic Services base
element and the following components moved to new base element
Integrated Security Services:
V1R11
v DCE Security Server, which was later removed from Integrated Security
Services in z/OS V1R13.
v IBM Firewall Technology, which was later removed from Integrated
Security Services in V1R8.
v LDAP Server, which was added to IBM TDS in V1R8, and was later
removed from Integrated Security Services in z/OS V1R11.
v Network Authentication Service (NAS).
v Open Cryptographic Enhanced Plug-ins (OCEP).
z/OS Font Collection
In z/OS V2R1, z/OS Font Collection (FMID HFNT110 and HFNT11J) became
an exclusive base element. It provides all fonts that are currently marketed
and serviced for the z/OS environment into one package as part of z/OS.
Chinese, Japanese, and Korean (CJK) double-byte fonts are included in FMID
HFNT11J.
V2R1
z/OS OpenSSH
This base element was added in z/OS V2R2. It provides secure encryption for V2R2
both remote login and file transfer.
z/OS UNIX
The z/OS UNIX Connection Manager and Process Manager components were V1R13 and
removed from the system in z/OS V1R13. The z/OS UNIX Integrated Call
V2R1
Level Interface (ICLI) was removed from the system in z/OS V2R1.
Two-year release cycle
IBM intends to make new releases of z/OS Version 2 available approximately every two years. IBM
continues to align the coexistence, migration, and fallback policy with the service policy. See “Which
releases are supported for coexistence, fallback, and migration?” on page 28.
New z/OS functions continue to be delivered between releases through the normal maintenance stream
or as web deliverables. In addition, significant new functions can be delivered between releases as
features of the product. For a summary of web deliverables and between-release features, see Table 3. In
the table, full releases (as opposed to enhancements) are highlighted.
Table 3. z/OS deliverables from September 2002 through September 2017
Deliverable
General availability
Delivery method
z/OS V1R4 and z/OS.e V1R4
27 September 2002
New release of products
z/OS V1R4 z990 Compatibility
Support. This deliverable is replaced
by z/OS V1R4 z990 Exploitation
Support.
June 2003
Unpriced feature of z/OS V1R4
z990 Compatibility for Selected
Releases (z/OS V1R3, z/OS.e V1R3,
z/OS V1R2, and OS/390 V2R10)
June 2003
Web
Chapter 1. Learning about z/OS
17
Table 3. z/OS deliverables from September 2002 through September 2017 (continued)
Deliverable
General availability
Delivery method
z990 Cryptographic CP Assist
June 2003
Support (z/OS V1R3 and z/OS.e
V1R3). This deliverable is replaced by
z990 Cryptographic Support, which
in turn is replaced by z990 and z890
Enhancements to Cryptographic
Support.
Web
z/OS.e V1R4 z990 Coexistence. This
deliverable is replaced by z/OS.e
V1R4 z990 Coexistence Update.
June 2003
Unpriced feature of z/OS.e V1R4
z/OS V1R4 DFSMStvs and z/OS.e
V1R4 DFSMStvs
June 2003
Priced features of z/OS V1R4 and
z/OS.e V1R4
z990 Cryptographic Support (for
z/OS V1R4, z/OS.e V1R4, z/OS
V1R3, z/OS.e V1R3, z/OS V1R2, and
OS/390 V2R10). This deliverable
replaces z990 Cryptographic CP
Assist Support, and is replaced by
z990 and z890 Enhancements to
Cryptographic Support.
September 2003 for z/OS V1R4,
z/OS.e V1R4, and z/OS V1R2;
October 2003 for z/OS V1R3 and
z/OS.e V1R3; November 2003 for
OS/390 V2R10
Web
z/OS V1R4 z990 Exploitation
Support. This deliverable replaces
z/OS V1R4 z990 Compatibility
Support.
October 2003
Unpriced feature of z/OS V1R4
z/OS.e V1R4 z990 Coexistence
Update. This deliverable replaces
z/OS.e V1R4 z990 Coexistence.
October 2003
Unpriced feature of z/OS.e V1R4
z/OS V1R4 Consoles Enhancements
and z/OS.e V1R4 Consoles
Enhancements
March 2004
Unpriced features of z/OS V1R4 and
z/OS.e V1R4
z/OS V1R5 and z/OS.e V1R5 and
March 2004
New release of products
z990 and z890 Enhancements to
May 2004 except September 2004 for
Cryptographic Support (for z/OS
z/OS V1R6 and z/OS.e V1R6
V1R6, z/OS.e V1R6, z/OS V1R5,
z/OS.e V1R5, z/OS V1R4, z/OS.e
V1R4, z/OS V1R3, z/OS.e V1R3,
z/OS V1R2, and OS/390 V2R10).
This deliverable replaces both z990
Cryptographic CP Assist Support and
z990 Cryptographic Support.
Web
z/OS V1R6 and z/OS.e V1R6
September 2004
New release of products
z/OS and z/OS.e Text Search. This
deliverable supports z/OS V1R6 and
z/OS.e V1R6, and later.
September 2004
Web
LDAP Enhancements for z/OS
V1R4/R5 and z/OS.e V1R4/R5
November 2004
Web
ICSF 64-bit Virtual Support for z/OS
V1R6 and z/OS.e V1R6
December 2004
Web
Cryptographic Support for z/OS
V1R6/R7 and z/OS.e V1R6/R7
(contains ICSF FMID HCR7730)
September 2005
Web
18
z/OS Planning for Installation
Table 3. z/OS deliverables from September 2002 through September 2017 (continued)
Deliverable
General availability
Delivery method
IBM Health Checker for V1R4/R5/R6 September 2005
of z/OS and z/OS.e
Web
z/OS V1R7 and z/OS.e V1R7
September 2005
New release of products
Enhancements to Cryptographic
Support for z/OS and z/OS.e
V1R6/R7 (contains ICSF FMID
HCR7731)
May 2006
Web
IBM zIIP Support for z/OS and
z/OS.e V1R6/R7
June 2006
Web
z/OS V1R8 and z/OS.e V1R8
September 2006
New release of products (final release
of z/OS.e)
System REXX Support for z/OS V1R8 September 2007
and z/OS.e V1R8
Web
z/OS V1R9
September 2007
New release of product
Cryptographic Support for z/OS
V1R7-R9 and z/OS.e V1R7-R8
(contains ICSF FMID HCR7750)
November 2007
Web
z/OS V1R10
September 2008
New release of product
Cryptographic Support for z/OS
November 2008
V1R8-R10 and z/OS.e V1R8 (contains
ICSF FMID HCR7751)
Web
z/OS V1R11
September 2009
New release of product
Cryptographic Support for z/OS
V1R9-R11 (contains ICSF FMID
HCR7770)
November 2009
Web
z/OS V1R12
September 2010
New release of product
Cryptographic Support for z/OS
V1R10-R12 (contains ICSF FMID
HCR7780)
September 2010
Web
z/OS V1R13
September 2011
New release of product
Cryptographic Support for z/OS
V1R11-R13 (contains ICSF FMID
HCR7790)
September 2011
Web
Cryptographic Support for z/OS
V1R12-R13 (contains ICSF FMID
HCR77A0)
September 2012
Web
z/OS V1R13 RSM Enablement
Offering
December 14, 2012
Web
Cryptographic Support for z/OS
V1R13 - z/OS V2R1 (contains ICSF
FMID HCR77A1)
September 2013
Web
z/OS V2R1
September 2013
New release of product
RSM Enablement Offering for z/OS
V1R13
January 2015
Web
Enhanced Cryptographic Support for
z/OS V1R13 - z/OS V2R1 (contains
ICSF FMID HCR77B0)
February 2015
Web
Chapter 1. Learning about z/OS
19
Table 3. z/OS deliverables from September 2002 through September 2017 (continued)
|
Deliverable
General availability
Delivery method
XL C/C++ V2R1M1 web deliverable
with z13 support for z/OS 2.1
(contains FMIDs HLB7791, JLB7792,
HTV7791, JTV7792)
February 2015
Web
z/OS V2R2
September 2015
New release of product
Cryptographic Support for z/OS
V1R13 - z/OS V2R2 (contains ICSF
FMID HCR77B1)
April 2016
Web
Cryptographic Support for z/OS
V2R1 - z/OS V2R2 (contains ICSF
FMID HCR77C0)
October 2016
Web
z/OS V2R3
September 2017
New release of product
The statements regarding the release strategy represent current intentions of IBM. Any reliance on these
statements is at the relying party's sole risk and will not create any liability or obligation for IBM. All
statements regarding IBM plans, directions, and intent are subject to change or withdrawal without
notice.
Methods of installing z/OS
Several IBM packages are available for installing z/OS. Some are entitled with the product (as part of
your z/OS license, at no additional charge), while others are available for an additional fee. This section
describes each package.
Rule: Because the base elements and optional features are integrated into a single package with
compatible service levels, you must install, with few exceptions, the entire z/OS product. See “Choosing
the z/OS base and optional features” on page 59 for details about this policy.
Tip: You might find that sharing system libraries or cloning an already-installed z/OS system is faster
and easier than installing z/OS with an IBM installation package. For further information, see “Installing
z/OS without using an installation package” on page 40.
ServerPac (entitled with z/OS)
|
|
|
|
|
ServerPac is an entitled software delivery package that consists of products and service that are SMP/E
installable and products that are non-SMP/E installable. For non-SMP/E installable products, IBM has
performed the installation if the product runs on z/OS; otherwise, the product is delivered in the
ServerPac package with installation instructions. To install the package on your system and complete the
installation of the software it includes, use the CustomPac Installation Dialog.
Two types of ServerPac installation are available to you, when you order z/OS. One option is to order
both z/OS and the products that run on it by way of ServerPac. Another option is to order a Product
ServerPac that includes only the software products you want without the z/OS base. See “Product
ServerPac (entitled with z/OS)” on page 21.
The CustomPac Installation Dialog generates tailored installation jobs and saves detailed definitions of
volume, catalog, and data set configurations, which can be tailored, saved, and merged to install
subsequent ServerPacs. The CustomPac Installation Dialog is the same dialog that is used for all the
CustomPac offerings, including SystemPac (dump-by-data-set format), ProductPac®, and RefreshPac. For
more information about CustomPac fee offerings, see IBM CustomPac Services (www.ibm.com/services/
custompac).
20
z/OS Planning for Installation
Consider the following ServerPac installation options that are available to you (You choose the type when
you install, not when you order.)
v A full system replacement installs a complete z/OS system. It installs all the data sets you need to IPL, to
log on to the target system, and to run a z/OS image in order to complete other installation and
customization tasks. The installed data sets fall into two major categories:
1. System software and related data sets (such as distribution and target libraries, SMP/E CSI data
sets, and sample libraries)
2. Operational data sets (such as page data sets, system control files, and a master catalog).
Because IBM creates a working set of operational data sets for you, a full system replacement helps
assure a successful first IPL.
Depending on your environment, you might need to merge your existing operational data sets with the
data sets created by ServerPac. You can do this before or after first IPL.
v A software upgrade installs only system software and related data sets (such as distribution and target
libraries, SMP/E CSI data sets, and sample libraries). It does not create the set of new operational data
sets required to IPL (such as page data sets, system control files, and a master catalog). With a software
upgrade, all operational data sets are assumed to exist and to be usable by the new level of software
installed. When new operational data sets are required, you must allocate and initialize them before
you IPL. For example, you might need to add parameters that are required by the new software level
or change data sets so they work with both the old and new levels.
A software upgrade uses your existing catalog structure. This includes your existing master catalog
(with direct or indirect cataloging references) and user catalogs. In addition, software upgrade allows
you to create new user catalogs as part of the installation process.
|
|
A software upgrade is possible for z/OS but not for a Product ServerPac order or for subsystems
(DB2®, IMS, CICS, and WebSphere Application Server).
Of the entitled installation packages available for installing z/OS, most customers choose ServerPac
rather than CBPDO.
Product ServerPac (entitled with z/OS)
|
|
|
|
For ordering products other than z/OS itself, IBM offers an option called Product ServerPac. With a
Product ServerPac, you can order z/OS, DB2, IMS, and CICS products without having to include the
DB2, IMS, or CICS base product in the order. As of z/OS V2R3, you can also order non-SMP/E
installable products in a Product ServerPac.
|
|
|
A Product ServerPac has the same characteristics as a regular ServerPac. For SMP/E installable products,
IBM installs the product or product set when it creates your order and delivers the target and distribution
libraries with:
|
v Service integrated (applied and accepted) to the latest RSU level
|
|
v Critical (HIPER/PE) service applied. This service includes PTFs that resolve HIPER (high impact
pervasive) APARs or PEs (PTFs in error). These fixes are also known as HIPER/PRP.
|
|
v The SMP/E environment with a single GLOBAL zone and the minimum number of TARGET and DLIB
zones required
By default, for the z/OS SREL, IBM delivers WebSphere products in their own zone pair, IBM Installation
Manager installed products in their own zone pair, and the rest of the products in a separate zone pair.
The intent is for you to manage the products you ordered as a product set in the delivered SMP/E
environment. As of V2R1, you can choose which global zone you want to use for installation, the existing
driving systems, or the global zone that is shipped with the order.
As with the ServerPac orders for subsystems, Product ServerPac orders are not shipped with a separate
master catalog and use the existing master catalog during installation.
Chapter 1. Learning about z/OS
21
Using a Product ServerPac rather than CBPDO to build these product sets avoids having to install each
product individually and then install service by using SMP/E.
|
|
|
|
|
For non-SMP/E installable products, IBM installs the product if it runs on z/OS, or delivers the product
that is associated with z/OS but runs on another platform with instructions on how to install it. Some
non-SMP/E installable products might contain only documentation that is delivered in the ServerPac
package. Service is not integrated for non-SMP/E installable products. For instructions for obtaining
service for the product, see Appendix A in ServerPac: Installing Your Order .
Using Shopz, you can order eligible products in a Product ServerPac in the same manner as for regular
ServerPac. Shopz has a triangle icon to indicate which products in the ServerPac catalog are eligible for a
Product ServerPac. Because this is a ServerPac, Shopz product requisite checking enforces requirements
for installation, but similar to CBPDO, Shopz also displays requisites that can be bypassed if you already
have them installed on your system.
CBPDO (entitled with z/OS)
CBPDO (Custom-Built Product Delivery Option) is an entitled software delivery package that consists of
uninstalled products and unintegrated service. There is no dialog program to help you install it, as there
is with ServerPac. You must use SMP/E to install the individual z/OS elements and features, and their
service, before you can IPL. For installation instructions, see z/OS Program Directory in the z/OS Internet
library (www.ibm.com/systems/z/os/zos/library/bkserv).
| z/OS and all SMP/E installable products that run on z/OS are available in CBPDO. Non-SMP/E
| installable products are not provided in CBPDO.
When enhancements are provided as features of a release, subsequent to the general availability of the
release, the enhancements are available by themselves in CBPDO. There is no need to reorder and
reinstall all of z/OS. In addition, the enhancements are available for Internet delivery in CBPDO when
ordered by using Shopz. This support provides a quick and easy way for you to order and receive these
post-release features.
For products other than z/OS itself, CBPDO is useful to upgrade an existing product, or add a product to
an existing SMP/E environment. By contrast, the Product ServerPac is useful when you are creating a
new SMP/E environment.
SystemPac (additional charge with z/OS)
SystemPac is a software package, available for an additional fee and offered worldwide, that helps you
install z/OS and the subsystems DB2, IMS, CICS, and WebSphere Application Server. SystemPac is
tailored to your specifications; it is manufactured according to parameters and input/output definition
file (IODF) definitions that you supply during order entry. The goal is to have the system tailored to your
specifications and have products enabled according to your specified configuration. Parameters are
collected by telephone. Using a printed questionnaire as a guide, you tell an IBM representative your
responses. Upon completion, a printout showing all the parameters and definitions you specified is sent
to you for reference.
SystemPac comes in two formats:
v The full volume dump format requires you to install using volume restore. The tapes you receive are in
physical volume format (DFSMSdss dumped).
v The dump-by-data-set format requires you to install using the CustomPac Installation Dialog. The tapes
you receive are in IEBCOPY dump-by-data-set format (not a physical volume dump).
In both formats, selected products, elements, features, and functions (such as z/OS UNIX,
Communications Server, IBM HTTP Server, and WLM goal mode) are enabled with IBM defaults to allow
you to exploit e-commerce upon IPL once your enterprise connectivity is established.
22
z/OS Planning for Installation
SystemPac is designed for those who have limited skill or time to install or upgrade z/OS but who want
to install or upgrade to exploit z/OS functions in e-commerce or other areas.
You can find information about SystemPac at IBM CustomPac Services (www.ibm.com/services/
custompac).
Other fee-based methods (additional charge with z/OS)
Other fee-based methods (besides SystemPac) for installing z/OS are:
v The Entry Server Offering (available in some countries) is a packaged solution that includes hardware,
software, installation services, maintenance and financing to help customers get to current technology.
v z/OS Select in the United Kingdom, Software Management in Germany, and Express Plus Offering in
France. Most of these offerings are based on SystemPac. These offerings vary in scale; they can go as
far as to include a total system cutover.
v Other fee-based services include customized solutions, hardware services, and software services. For
information about the other fee-based services, contact an IBM representative or visit IBM Global
Technology Services (www.ibm.com/services).
Web deliverable method
Sometimes enhancements are provided as web deliverables. For example, the enhancement Cryptographic
Support for z/OS V2R1 - z/OS V2R2 is available as a web deliverable.
z/OS web deliverables are available from z/OS downloads (www.ibm.com/systems/z/os/zos/
downloads). They are packaged as two files that you can download:
v A readme file, which contains a sample job to decompress the second file, transform it into a format
that SMP/E can process, and invoke SMP/E to RECEIVE the file. This file must be downloaded as
text.
v A pax.z file, which contains an archive (compressed copy) of the FMIDs to be installed. This file needs
to be downloaded to a workstation and then uploaded to a host as a binary file.
For web downloads, you must perform the following tasks:
1. Allocate an HFS or zFS directory as R/W on the z/OS driving system where the package is to be
staged.
2. Download both parts of the package from z/OS downloads (www.ibm.com/systems/z/os/zos/
downloads).
3. Run the sample job that is provided in the README.TXT file. The job invokes the GIMUNZIP service
routine to extract the original data from the packages.
4. Obtain and install service for the target system. Service is not included in web deliverables. You can
obtain service for web deliverables through your regular preventive service deliverables that you use
for z/OS.
5. Install the downloaded FMIDs by using SMP/E APPLY.
Languages in which z/OS is available
z/OS is provided in U.S. English. In addition, 16 other languages are supported. The main items that are
provided in these other languages are messages, panels, and documentation. Not all elements and
features are available in each of the 16 languages. Table 4 on page 24 shows the 16 languages and lists
which elements and features are available in each.
When you order z/OS, you receive it in U.S. English and in the following additional languages:
v Thirteen additional languages for base element Library Server (listed in Table 4 on page 24)
v One additional language (Japanese) for the program management binder in base element BCP
Chapter 1. Learning about z/OS
23
If you want an additional language, you have to specify the language feature number in your order.
If you order the z/OS base in a non-English language, you get all priced features (which support
dynamic enablement) in English and any priced features that are available in that non-English language.
If you order a priced feature in a non-English language, you get it in that language and in English.
The enablement setting is based on whether an element or feature was ordered in any language.
Table 4. Languages supported (in addition to U.S. English) and the elements and features available in each language
Language
Base elements
Brazilian Portuguese
v BookManager READ
v GDDM
v Library Server
Canadian French
Priced optional features
Notes®
Translations are provided
with the z/OS base license
and therefore do not have to
be ordered separately: the
program management binder
in base element BCP, and
base element Library Server.
v BookManager READ
v GDDM
Danish
v BookManager READ
v GDDM
v Library Server
French
v BookManager READ
v GDDM
v Library Server
German
v BookManager READ
v GDDM
v ISPF
v Library Server
v TSO/E
Italian
v BookManager READ
v GDDM
v Library Server
24
z/OS Planning for Installation
Translations for the following
are provided with the z/OS
base license and therefore do
not have to be ordered
separately: the program
management binder in base
element BCP, and base
element Library Server.
Translations for the following
are provided with the z/OS
base license and therefore do
not have to be ordered
separately: the program
management binder in base
element BCP, and base
element Library Server.
Translations for the following
are provided with the z/OS
base license and therefore do
not have to be ordered
separately: the program
management binder in base
element BCP, and base
element Library Server.
Translations for the following
are provided with the z/OS
base license and therefore do
not have to be ordered
separately: the program
management binder in base
element BCP, and base
element Library Server.
Table 4. Languages supported (in addition to U.S. English) and the elements and features available in each
language (continued)
Language
Base elements
Priced optional features
Japanese
v Alternate Library for REXX v DFSMSrmm
v BCP
v Infoprint Server
v DFSMSdfp
v RMF
v Distributed File Service
v Security Server
v GDDM
v XL C/C++
v HCD
v IBM TDS
v Integrated Security
Services
v ICKDSF
v ISPF
v JES2
v Language Environment
v Library Server (DBCS)
Notes®
For BCP and Library Server
(DBCS)
v Translations for the
following are provided
with the z/OS base license
and therefore do not have
to be ordered separately:
the program management
binder in base element
BCP, and base element
Library Server.
v If you order the Japanese
Base or Japanese Alternate
Base feature, you will
receive the Unicode
Japanese FMID without
separately ordering it.
v Runtime Library
Extensions
v SMP/E
v SSL component of
Cryptographic Services
v TSO/E
v z/OS UNIX
Korean
v GDDM
v Library Server (DBCS)
Netherlands Dutch
v BookManager READ
v Library Server
Norwegian
v GDDM
v Library Server
Translations for the following
are provided with the z/OS
base license and therefore do
not have to be ordered
separately: the program
management binder in base
element BCP, and base
element Library Server.
Translations for the following
are provided with the z/OS
base license and therefore do
not have to be ordered
separately: the program
management binder in base
element BCP, and base
element Library Server.
Translations for the following
are provided with the z/OS
base license and therefore do
not have to be ordered
separately: the program
management binder in base
element BCP, and base
element Library Server.
Chapter 1. Learning about z/OS
25
Table 4. Languages supported (in addition to U.S. English) and the elements and features available in each
language (continued)
Language
Base elements
Simplified Chinese
v GDDM
v Library Server (DBCS)
v z/OS UNIX kernel in the
BCP
v TSO/E
v z/OS UNIX
Spanish
v BookManager READ
v GDDM
v Library Server
Swedish
v GDDM
v Library Server
Swiss German
v ISPF
Traditional Chinese
v GDDM
v Library Server (DBCS)
Uppercase English
Priced optional features
Notes®
Translations for the following
are provided with the z/OS
base license and therefore do
not have to be ordered
separately: the program
management binder in base
element BCP, and base
element Library Server.
Translations for the following
are provided with the z/OS
base license and therefore do
not have to be ordered
separately: the program
management binder in base
element BCP, and base
element Library Server.
Translations for the following
are provided with the z/OS
base license and therefore do
not have to be ordered
separately: the program
management binder in base
element BCP, and base
element Library Server.
Translations for the following
are provided with the z/OS
base license and therefore do
not have to be ordered
separately: the program
management binder in base
element BCP, and base
element Library Server.
v ISPF
Coexistence and fallback
Coexistence and fallback play an important part in planning for migration to the latest release. This
section explains what coexistence and fallback are, describes the IBM policy regarding the releases that
are supported for coexistence and fallback (as well as migration), and states which specific releases are
supported.
While coexistence and fallback might at first seem unrelated, they are very much related in that both deal
with an earlier level of a system being able to tolerate changes made by a later level.
Understanding coexistence
Coexistence1 occurs when two or more systems at different software levels share resources. The resources
could be shared at the same time by different systems in a multisystem configuration, or they could be
1. In some documentation, you might find the terms “compatibility” or “toleration” used instead of “coexistence”.
26
z/OS Planning for Installation
shared over a period of time by the same system in a single-system configuration. Examples of
coexistence are two different JES releases sharing a spool, two different service levels of DFSMSdfp
sharing catalogs, multiple levels of SMP/E processing SYSMODs packaged to exploit the latest
enhancements, or an older level of the system using the updated system control files of a newer level
(even if new function has been exploited in the newer level).
The sharing of resources is inherent in multisystem configurations that involve Parallel Sysplex®
implementations. But other types of configurations can have resource sharing too. Examples of
configurations where resource sharing can occur are:
v A single processor that is time-sliced to run different levels of the system, such as during different
times of the day
v A single processor running multiple images by means of logical partitions (LPARs)
v Multiple images running on several different processors
v Parallel Sysplex or non-Parallel Sysplex configurations
Note: The term coexistence does not refer to z/OS residing on a single system along with z/VSE,
VSE/ESA, or z/VM in an LPAR or as a VM guest.
|
|
|
|
|
z/OS V2R3 systems can coexist with specific prior releases of z/OS systems. (The releases are listed in
“Which releases are supported for coexistence, fallback, and migration?” on page 28.) This is important
because it gives you flexibility to migrate systems in a multisystem configuration to z/OS V2R3 using
rolling IPLs rather than requiring a systems-wide IPL. (See “Rolling z/OS across a multisystem
configuration.”) The way in which you make it possible for earlier-level systems to coexist with z/OS
V2R3 is to install coexistence service (PTFs) on the earlier-level systems.
You should complete the migration of all earlier-level coexisting systems to z/OS V2R3 as soon as you
can. Keep in mind that the objective of coexistence PTFs is to allow existing functions to continue to be
used on the earlier-level systems when run in a mixed environment that contains later-level systems.
Coexistence PTFs are not aimed at allowing new functions provided in later releases to work on
earlier-level systems.
Rolling z/OS across a multisystem configuration
A rolling IPL is the IPL of one system at a time in a multisystem configuration. You might stage the IPLs
over a few hours or a few weeks. The use of rolling IPLs allows you to migrate each z/OS system to a
later release, one at a time, while allowing for continuous application availability.
For example, data sharing applications offer continuous availability in a Parallel Sysplex configuration by
treating each z/OS system as a resource for processing the workload. The use of rolling IPLs allows z/OS
systems running these applications to be IPLed one at a time, to migrate to a new release of z/OS, while
the applications continue to be processed by the other z/OS systems that support the workload. By using
LPAR technology, you can use rolling IPLs to upgrade your systems without losing either availability or
capacity.
You can use rolling IPLs when both of the following are true:
v The release to which you are migrating is supported for coexistence, fallback, and migration with the
releases running on the other systems. See “Which releases are supported for coexistence, fallback, and
migration?” on page 28 for the releases that are supported.
v The appropriate coexistence PTFs have been installed on the other systems in the multisystem
configuration.
Even when you are using applications that do not support data sharing, rolling IPLs often make it easier
to schedule z/OS software upgrades. It can be very difficult to schedule a time when all applications
running on all the systems in a multisystem configuration can be taken down to allow for a
complex-wide or Parallel Sysplex-wide IPL.
Chapter 1. Learning about z/OS
27
The use of rolling IPLs not only enables continuous availability from an end-user application point of
view, but it also eliminates the work associated with migrating all z/OS systems in a multisystem
configuration at the same time.
Understanding fallback
Fallback (or backout) is a return to the prior level of a system. Fallback can be appropriate if you migrate
| to z/OS V2R3 and during testing, encounter severe problems that can be resolved by backing out the
new release. By applying fallback PTFs to the “old” system before you migrate, the old system can
tolerate changes that were made by the new system during testing.
Fallback is relevant in all types of configurations, that is, single-system or multisystem, with or without
resource sharing.
As an example of fallback, consider a single system that shares data or data structures, such as user
catalogs, as you shift the system image from production (on the “old” release) to test (on the new release)
and back again (to the old release). The later-level test release might make changes that are incompatible
with the earlier-level production release. Fallback PTFs on the earlier-level release can allow it to tolerate
changes that are made by the later-level release.
In general, always plan to have a backout path when you install new software. Identify and install any
service that is required to support backout.
Fallback is at a system level, rather than an element or feature level. As of z/OS V2R1, there is no
support for the fallback staging of mixed levels of JES2, JES3, and SDSF. As a result, you cannot back out
an element or feature that includes JES2, JES3, and SDSF. Rather, you must back out the entire product.
Fallback and coexistence are alike in that the PTFs that ensure coexistence are the same ones that ensure
fallback.
| Note: Keep in mind that new functions can require that all systems be at the z/OS V2R3 level before the
new functions can be used. Therefore, be careful not to use new functions until you are fairly confident
| that you do not need to back out your z/OS V2R3 systems because fallback maintenance is not available
in these cases. To determine the requirements for using a particular new function, refer to the appropriate
element or feature information.
If your fallback plans include making a clone, see Appendix D, “Making a copy of your system software
(cloning),” on page 129.
Which releases are supported for coexistence, fallback, and
migration?
| z/OS V2R3 is supported for coexistence, fallback, and migration with the following z/OS releases: V2R3,
V2R2, and V2R1.
This means that:
| v Coexistence of a V2R3 system with a V2R2 and V2R1 system is supported.
| v Fallback from a V2R3 system to a V2R2 or V2R1 system is supported.
| v Migration to a V2R3 system from a V2R2 or V2R1 system is supported.
The coexistence, fallback, and migration policy is aligned with the IBM service policy, which is five years,
as described in “Service policy” on page 31. Because V2R1 was the start of the two-year release cycle, as
a general rule, three releases are supported for coexistence, fallback, and migration over a period of five
| years. You can think of this as an “n-2” rule, where n is the latest release. Thus, V2R3 minus 2 = V2R1
28
z/OS Planning for Installation
|
meaning that z/OS V2R1 is the earliest (oldest) release supported for coexistence, fallback, and migration
with z/OS V2R3. The intention of the current policy is to simplify and provide greater predictability to
aid in release migrations.
Exceptions are:
v In some cases, more than three releases may be coexistence, fallback, and migration supported, at the
sole discretion of IBM.
v Any z/OS release having three or fewer months of service remaining at general availability of a new
release will not be coexistence, fallback, or migration supported with the new release.
The z/OS coexistence, fallback, and migration policy applies to the elements and features of z/OS, not to
customer-developed applications, vendor-developed applications, or IBM products that run on z/OS.
IBM performs platform (integration) testing and will provide service as necessary to support the z/OS
coexistence, fallback, and migration policy.
See Table 5 for a summary of coexistence, fallback, and migration support for recent, current, and
upcoming releases.
These statements represent the current intentions of IBM. IBM reserves the right to change or alter the
coexistence, fallback, and migration policy in the future or to exclude certain releases beyond those
stated. IBM development plans are subject to change or withdrawal without further notice. Any reliance
on this statement of direction is at the relying party's sole risk and does not create any liability or
obligation for IBM.
Table 5. Coexistence, fallback, and migration support for recent, current, and upcoming releases
z/OS release
(see note 1)
Releases that are coexistence,
fallback, and migration
supported with the release in
column one (see note 1)
R6
R6, R5, R4, R3
General availability of z/OS V1R6 was September 2004. z/OS
V1R2 was the oldest service-supported release at that time and
therefore the oldest release that would be coexistence, fallback,
and migration supported. However, its end-of-service date
(October 2004) was within three months of z/OS V1R6 general
availability (September 2004), so z/OS V1R3 became the oldest
release supported for coexistence, fallback, and migration with
z/OS V1R6.
R7
R7, R6, R5, R4
General availability of z/OS V1R7 was September 2005. z/OS
V1R4 was the oldest release that was service supported at that
time and therefore the oldest release supported for coexistence,
fallback, and migration with z/OS V1R7.
R8
R8, R7, R6, R5
General availability of z/OS V1R8 was September 2006. z/OS
V1R4 was the oldest release that was service supported at that
time because its end-of-service date was extended by 18 months
to 31 March 2007. However, z/OS V1R4 was not coexistence,
fallback, and migration supported with z/OS V1R8. Therefore,
z/OS V1R5 became the oldest release supported for coexistence,
fallback, and migration with z/OS V1R8.
R9
R9, R8, R7
General availability of z/OS V1R9 was September 2007. z/OS
V1R7 was the oldest release that was service supported at that
time and therefore the oldest release supported for coexistence,
fallback, and migration with z/OS V1R9.
Explanation (see note 2)
Chapter 1. Learning about z/OS
29
Table 5. Coexistence, fallback, and migration support for recent, current, and upcoming releases (continued)
|
|
|
|
z/OS release
(see note 1)
Releases that are coexistence,
fallback, and migration
supported with the release in
column one (see note 1)
R10
R10, R9, R8
General availability of z/OS V1R10 was September 2008. z/OS
V1R8 was the oldest release that was service supported at that
time and therefore the oldest release supported for coexistence,
fallback, and migration with z/OS V1R10.
R11
R11, R10, R9
General availability of z/OS V1R11 was September 2009. z/OS
V1R9 was the oldest release that was service supported at that
time and therefore the oldest release supported for coexistence,
fallback, and migration with z/OS V1R11.
R12
R12, R11, R10
General availability of z/OS V1R12 was September 2010. z/OS
V1R10 was the oldest release that was service supported at that
time and therefore the oldest release supported for coexistence,
fallback, and migration with z/OS V1R12.
R13
R13, R12, R11
General availability of z/OS V1R13 was September 2011. z/OS
V1R11 was the oldest release service supported at that time and
therefore the oldest release supported for coexistence, fallback,
and migration with z/OS V1R13.
V2R1
V2R1, V1R13, V1R12
General availability of V2R1 was September 2013. V1R12 was
the oldest release service supported at that time, and therefore
the oldest release supported for coexistence, fallback, and
migration with V2R1.
V2R2
V2R2, V2R1, V1R13
General availability of V2R2 was September 2015. V1R13 was
the oldest release service supported at that time, and therefore
the oldest release supported for coexistence, fallback, and
migration with V2R2.
V2R3
V2R3, V2R2, V2R1
General availability of V2R3 is planned for September 2017.
V2R1 is planned to be the oldest release service supported at
that time, and therefore the oldest release supported for
coexistence, fallback, and migration with V2R3.
Explanation (see note 2)
Note:
| 1. For readability, the version numbers have been omitted from the releases shown. Also, release
|
numbering of future releases (later than V2R3) is for illustrative purposes and is not a guarantee of
|
actual release numbers.
2. Future general availability (GA) dates are projections based on a two-year release cycle (described in
“Two-year release cycle” on page 17). Future end of service (EOS) dates are projections based on the
5-year service policy (described in “Service policy” on page 31).
Platform (integration) testing by IBM
For each release of z/OS, a team of IBM testers and system programmers performs a IBM Z® platform
test (formerly known as integration test). Test systems simulate customer production Parallel Sysplex
environments running z/OS and many related software products such as DB2, IMS, CICS, WebSphere
MQ (formerly known as MQSeries®), and WebSphere Application Server. The team migrates to each new
release of z/OS, puts the system into production, and then verifies that all products applicable to each
operating system work together. The team not only tests software, but also verifies that the software runs
in a hardware environment that has both generally available (GA) and pre-GA levels of IBM Z®
hardware.
30
z/OS Planning for Installation
The zPET team maintains two parallel sysplex environments. They have a 4-way test and quality
assurance sysplex, and a 9-way production sysplex. Like most customers, the latest z/OS gets migrated
by LPAR first to the 4-way system and later to the 9-way environment. Migration and coexistence are
tested between the pre-GA (n+1) z/OS and the latest z/OS GA code (n). After fully migrated to the
pre-GA z/OS, a fallback test scenario is performed. If successful, the fallback LPAR is once again
migrated to pre-GA z/OS and tests of new functions commence.
The team documents their experiences with installing, migrating, and testing z/OS and IBM Z® hardware
and System Storage®, in LCST/e z Systems Platform Evaluation Test Community blog
(www.ibm.com/developerworks/community/groups/community/zpet), which is available from IBM z
Systems Platform Test (www.ibm.com/systems/services/platformtest/servers/systemz.html). This
website also includes test results and advice for customers, and illustrations of the team's hardware,
software, networking, and application enablement configurations.
The team follows a process that includes simulating the workload stress levels, transaction rates, and lock
contention rates that customers might experience. They stress many of the same areas of the system that
customers stress. In their report, they include detailed descriptions of their hardware, software,
networking, and application enablement configurations, as well as the key operational, performance, and
availability characteristics of their Parallel Sysplex environment. They provide recommended recovery
procedures and various hints and tips that are distilled from their own experiences. They explain the
mistakes they make so that you can avoid those mistakes.
Service
This topic describes the IBM service policy for z/OS, the level of service that is provided with your order,
what PSP information is, the preventive maintenance that you should perform after installing z/OS, and
how preventive and corrective service are distributed.
Service policy
|
|
|
|
|
|
IBM's service policy is to provide maintenance (service) for each release of z/OS V2 for five years
following the general availability (GA) date. However, service on the last release of a version might be
extended beyond the intended five-year period. Before withdrawing service for any version or release of
z/OS, IBM intends to provide at least 12 months notice. For end-of-service (EOS) dates, including those
for z/OS V2R1 and z/OS V2R2, see IBM Lifecycle Support for z/OS (www.ibm.com/software/support/
systemsz/lifecycle).
Program temporary fix (PTF) distributions, including Recommended Service Upgrades (RSUs), are
available monthly while a release is current. Service testing for a release is performed for five quarters
after the general availability date for that release.
ServerPac and Product ServerPac service level
|
|
For ServerPac and Product ServerPac orders, service is integrated with the product code for SMP/E
installable products according to the following timeline:
v ServerPac and Product ServerPac are refreshed every month to pick up the most current RSU.
v All products incorporate high impact or pervasive (HIPER) and PTF-in-error (PE) fixes that are
available up to the day your order is built. Because these PTFs are still fairly new at the time your
order is built, they are not SMP/E ACCEPTed. Therefore, they were APPLYed only, which allows you
to back them off your system by using the SMP/E RESTORE command, if necessary. Your order also
includes (in its SMP/E global zone) the most recent unintegrated service that was available at the time
the order was created. In addition, the PTFs that were SMP/E APPLYed but not ACCEPTed are also in
the SMP/E global zone.
|
|
v All z/OS elements and features incorporate more service that was checked through platform
(integration) testing (SOURCEID ZOSV2R3).
|
v Your ServerPac order also includes unintegrated service that was available when your order was built.
Chapter 1. Learning about z/OS
31
The publication ServerPac: Installing Your Order, which comes with your order, specifies the integrated
service level applicable to your order.
| Service is not provided for non-SMP/E installable products. The publication ServerPac: Installing Your
| Order describes how to obtain service for these products in Appendix A.
Note: As of z/OS V1R13, ServerPac: Installing Your Order is no longer provided in hardcopy format; the
information is available in PDF format on a DVD that also includes the program directories.
CBPDO service level
For CBPDO orders, service is not integrated. You must receive and apply the service during the
installation process.
Service for all products, base elements, and optional features that you ordered is provided with default
CBPDO orders. To get service for other products, you can use SMP/E Internet Service Retrieval, Shopz,
or a fee service offering.
The CBPDO Memo to Users Extension that comes with CBPDO orders describes the SOURCEIDs for
| service. For example, platform-tested (integration-tested) PTFs have a SOURCEID of ZOSV2R3 for z/OS
| V2R3. For a description of the SMP/E SOURCEIDs that can be used to install z/OS, see SMP/E for z/OS
User's Guide.
SystemPac service level
For SystemPac orders, service is integrated with product code according to the following timeline:
v SystemPac is refreshed every month to pick up the most current RSU.
v All products incorporate high impact or pervasive (HIPER) and PTF-in-error (PE) fixes that are
available up to the day your order is built. Because these PTFs are still fairly new at the time your
order is built, they are not SMP/E ACCEPTed. They have been APPLYed only, allowing you to back
them off of your system using the SMP/E RESTORE command, if necessary. Your order also includes
(in its SMP/E global zone) the latest unintegrated service that was available at the time the order was
created. In addition, the PTFs that were SMP/E APPLYed but not ACCEPTed are also in the SMP/E
global zone.
v All z/OS elements and features will incorporate additional service that has been through platform
(integration) testing (SOURCEID ZOSV2Rn, where n is the release number).
v The publication SystemPac Installation Guide, which comes with your order, specifies the integrated
service level applicable to your order.
Note: As of z/OS V1R13, SystemPac Installation Guide is no longer shipped in hardcopy format; the
information is available in PDF format on a DVD that also includes the program directories.
z/OS web deliverables service level
z/OS delivers some functions from z/OS downloads (www.ibm.com/systems/z/os/zos/downloads).
z/OS web deliverables can be identified by the references to supported z/OS releases in their titles or in
their functional descriptions. These web packages contain only the base function; service is not included
in the web downloads. Service is included in your regular preventive service deliverable for z/OS
automatically.
PSP information
z/OS and most products that run on it provide files that contain information that becomes available after
the product information is published. Kept on the IBM RETAIN system and also available using
IBMLink, these files are called preventive service planning (PSP) “buckets”, or just “PSPs”. These terms
32
z/OS Planning for Installation
were chosen when PSP buckets contained only APAR- and PTF-related information, but over time
customers requested a more general repository of important installation-related information, and the role
of the PSP bucket has grown.
PSP buckets are kept on the IBM RETAIN system and are available to customers at Preventive Service
Planning buckets (www.ibm.com/support/customercare/psearch/search?domain=psp).
PSP buckets are identified by an upgrade identifier, and specific parts of them are called subsets. Each
upgrade contains information about a product. Subsets contain information about specific parts of a
product. For example, the z/OS PSP bucket has subsets for the BCP, JES2, ServerPac, and others.
|
|
|
|
|
|
For software upgrades for ServerPac and CBPDO installations, see z/OS Program Directory in the z/OS
Internet library (www.ibm.com/systems/z/os/zos/library/bkserv). For ServerPac, the upgrade is
ZOSV2R3 and the subset is SERVERPAC. For software upgrades for SystemPac installations, the upgrade
is CUSTOMPAC and the subsets are SYSPAC/FVD (for full volume dump format) and SYSPAC/DBD
(for dump-by-data-set format). For hardware upgrades, see “PSP hardware upgrade identifiers” on page
65.
At the beginning of each PSP bucket is a change index. For each subset, the change index identifies the
date of the latest entries in each section. You can quickly determine whether there are new entries you
need to read by checking the change index.
Each subset is broken into five sections, numbered 1 - 5:
Section 1
Installation Information. This section contains any changes to installation procedures or
information about additional requisite PTFs.
Section 2
Documentation Changes. This section contains any major changes to product information.
Section 3
General Information. This section contains important information that does not fit in another
section.
Section 4
Service Recommendations. The original purpose of the PSP bucket was to provide this
information, which includes a list of HIPER APARs and their fixes, as well as other important
service-related information.
Section 5
Cross-Product Dependencies. This section contains information about the levels or service levels
of other products you might need to run with the software you intend to install, or service that
you might need to install to run other products.
Consolidated service testing by IBM
IBM launched the consolidated service test (CST) effort in November 2000 and redefined the
Recommended Service Upgrade (RSU) for the OS/390 and z/OS platforms in November 2001. The
objective was to provide a consolidated, tested, and recommended set of service for z/OS and key
subsystems on a quarterly basis with published results. This means that you can obtain and install service
for z/OS and key subsystems from one recommended service package, so that you have a tested level of
service for all these products.
Note: CST testing does not replace PTF testing performed by each product. CST testing is in addition to
individual PTF testing.
The CST team tests in a customer-like production Parallel Sysplex environment in an IBM test lab. It runs
batch and data-sharing applications that exploit and stress the latest functions with up to two levels of
Chapter 1. Learning about z/OS
33
subsystems on three levels of z/OS systems. The CST team is continuously improving the test
environment. For more information about the environment, see the quarterly Consolidated Service Test
Report at Consolidated Service Test and the RSU (www.ibm.com/systems/z/os/zos/support/servicetest).
During testing, the team observes how each product runs and how all the products interact in this
environment. The team reports problems it finds to the IBM Support Center.
The testing cycle is quarterly. The team begins each quarter by installing all service from the prior quarter
and defining test scenarios to exploit new product functions while existing workloads are being run.
During the second month of the quarter the team starts running new test scenarios, identifies problems,
and applies fixes. In the final month of the quarter the team performs recovery tests and runs workloads
in a high stress environment. At the end of the quarter the team publishes results in the Consolidated
Service Test Report.
At the end of each month, between quarterly recommendations, the CST team provides a delta
recommendation for customers whose preventive strategy requires more frequent maintenance updates.
The monthly recommendation supports the most recently published CST quarterly recommendation. It
includes HIPER and PE fixes that have been installed at the beginning of the month and tested for the
duration of the month.
As quarterly and monthly recommendations become available, the team updates the CST Web site.
Maintenance after installation
After you have installed z/OS, you should install preventive maintenance using Recommended Service
Upgrades (RSUs). An RSU is an SMP/E SOURCEID (RSUyymm) used to identify the following:
v All PTFs that completed CST testing during the prior quarter.
v Certain types of PTFs that completed CST testing during the prior month. The types are high impact or
pervasive (HIPER) PTFs, PTF-in-error (PE) PTFs, and other recommended PTFs (recommended because
of new function, serviceability, installability, security, or integrity).
Note: While all CST-tested PTFs become RSU PTFs, not all RSU PTFs are tested in CST. Only the
following products or product families are included in CST testing: z/OS, IMS, DB2, CICS, and
MQSeries.
RSUs are available monthly. They are assigned an RSU SOURCEID that reflects when the PTFs in them
completed the test cycle and became recommended, not when the PTFs closed. (The PUTyymm SOURCEID
continues to be used to identify when a PTF closes.) Both the monthly and quarterly RSUs use the same
RSUyymm SOURCEID notation. You can identify quarterly RSUs by their month values, which are
RSUyy03, RSUyy06, RSUyy09, and RSUyy12. For a better understanding of RSU content and availability,
see Table 6.
Tip: Install an RSU every three months if possible, with the RSU level being the most current month.
Also, regularly (weekly, if possible) review current HIPER and PE PTFs, and roll these fixes into
production at least monthly. If you are unable to install RSU maintenance every three months, be sure to
review the HIPER and PE fixes on a regular basis.
|
Table 6. RSU content and RSU SOURCEID for each month of 2017
|
Month
RSU content
|
|
|
January 2017
All PTFs that exit CST through the end of September 2016 and are
RSU1612
not already in an RSU, plus HIPER and PE-correcting PTFs that exit
CST in November 2016.
|
February 2017
HIPER and PE-correcting PTFs that exit CST in December 2016.
RSU1701
|
March 2017
HIPER and PE-correcting PTFs that exit CST in January 2017.
RSU1702
34
z/OS Planning for Installation
SOURCEID
|
Table 6. RSU content and RSU SOURCEID for each month of 2017 (continued)
|
Month
RSU content
|
|
|
April 2017
All PTFs that exit CST through the end of December 2016 and are
RSU1703
not already in an RSU, plus HIPER and PE-correcting PTFs that exit
CST in February 2017.
|
May 2017
HIPER and PE-correcting PTFs that exit CST in March 2017.
RSU1704
|
June 2017
HIPER and PE-correcting PTFs that exit CST in April 2017.
RSU1705
|
|
|
July 2017
All PTFs that exit CST through the end of March 2017 and are not
already in an RSU, plus HIPER and PE-correcting PTFs that exit
CST in May 2017.
RSU1706
|
August 2017
HIPER and PE-correcting PTFs that exit CST in June 2017.
RSU1707
|
September 2017
HIPER and PE-correcting PTFs that exit CST in July 2017.
RSU1708
|
|
|
October 2017
All PTFs that exit CST through the end of June 2017 and are not
already in an RSU, plus HIPER and PE-correcting PTFs that exit
CST in August 2017.
RSU1709
|
November 2017
HIPER and PE-correcting PTFs that exit CST in September 2017.
RSU1710
|
|
December 2017
HIPER and PE-correcting PTFs that exit CST in October 2017.
RSU1711
SOURCEID
One way to review HIPER and PE PTFs is to use Enhanced HOLDDATA. Enhanced HOLDDATA is
HOLDDATA with additional information to identify the reason for the hold and a fixing PTF. Enhanced
HOLDDATA provides a hold against function SYSMODs (FMIDs) for HIPER and PE PTFs.
(Non-Enhanced HOLDDATA provides a hold only against PE PTFs.)
To display the Enhanced HOLDDATA, use the SMP/E REPORT ERRSYSMODS command. The SMP/E
report, when used with Enhanced HOLDDATA, identifies missing critical service that applies to your
specific system. This allows you to identify any missing HIPER and PE fixes for any target zone.
Additionally, the report identifies whether a corrective PTF is available, whether the corrective PTF is
already in RECEIVE status, and the reason indicator for a HIPER.
Enhanced HOLDDATA is available through z/OS service orders, CBPDO orders, and from the Internet.
For more information, see Enhanced HOLDDATA for z/OS (service.software.ibm.com/holdata/
390holddata.html).
To install service on elements and features, you must minimally meet the driving system requirements for
CBPDO Wave 1. For CBPDO Wave 1 driving system requirements, see “Driving system Wave 1
requirements” on page 56.
Service distribution
|
|
|
Both preventive and corrective service are delivered by using processes, such as Shopz, SMP/E Internet
Service Retrieval, and ServiceLink. Some z/OS products, such as non-SMP/E installable products, might
have service delivered through Fix.Central.
The IBM Support Portal (support.ibm.com) contains information about problem submission, problem
review, open and closed APARs, and documentation.
Shopz
Shopz is an Internet application you can use to order z/OS software products and service. Using Shopz,
you can order corrective and preventive service over the Internet, with delivery over the Internet or on
DVD or tape. Service with Shopz reduces your research time and effort by using your uploaded software
inventory bitmap to ensure that all applicable service, including reach-ahead service, for the installed
FMIDs in the target zones is selected. Shopz and Roles and Authorization Management (RAM) users can
now be authorized to create service orders, submit them for fulfillment, view and download orders they
Chapter 1. Learning about z/OS
35
create. Service order authorization can also be separated from product ordering authorization. For more
information, see IBM Software Shopz (www.ibm.com/software/shopzseries/ShopzSeries_public.wss).
Note: IBM's strategy is to provide entitled service ordering and service delivery capabilities for the z/OS
platform products electronically using the Internet. Shopz is the primary ordering and delivery method
for software service on these platforms.
SMP/E Internet Service Retrieval
Obtaining software service over the Internet was improved in z/OS V1R7 (and in the SMP/E V3R4
product) with the introduction of SMP/E Internet Service Retrieval. Without this function, ordering and
obtaining service over the Internet through Shopz involves a number of steps including running an
SMP/E job to create an inventory file, initiating a service order transaction on Shopz, uploading the
inventory file, waiting for notification that the service package is available, accessing the package on
Shopz, and running an SMP/E job to download and process the service package. SMP/E Internet Service
Retrieval consolidates these steps into one. You use a new form of the RECEIVE command to run an
SMP/E job to place a service order, wait for the IBM server to fulfill the order, download the service
package (which contains PTFs and HOLDDATA), and process its contents, all in one step.
With SMP/E Internet Service Retrieval, you can request service on demand and even automate the
service delivery process. For example, you could schedule an SMP/E job to run once a week, or even
every night, to order and download the latest HOLDDATA and critical PTF service and have these
service updates available exactly when you want.
SystemPac SFS
For SystemPac users, SystemPac follow-on service (SFS) comes free as an option as part of the SystemPac
fee offering. You can order a maximum of three SFSs with maximum intervals of 90 days apart. SFSs
contain PTFs fixing PEs and HIPERs. They are built according to the copy of the SMP/E consolidated
software inventory (CSI) of your system. Thus, these critical services are tailored to fit your environment.
RefreshPac (fee offering)
RefreshPac is a software preventive service offering that is available worldwide for a fee. RefreshPac can
update one or all target and DLIB zone pairs residing in a target and DLIB consolidated software
inventory (CSI). These zone pairs must belong to the same system release identifier (SREL). RefreshPac is
customized by providing input from the customer in the form of a copy of the CSI information that the
target and DLIB zone pairs to be serviced resided in. Upon delivery of the RefreshPac, you are entitled to
selective follow-on service (SFS). SFSs contain PTFs that fix PE and HIPER fixes that are discovered after
the package was shipped to you. By applying SFSs repeatedly, HIPER and PE fixes are flushed out of
your system, thus providing a highly available system for your applications.
Education and training
The IBM Education home page (www.ibm.com/services/learning) contains a course catalog, training
paths, a list of classes, and several links, including a link to the IBM Education Assistant. The IBM
Education Assistant is a collection of multimedia educational modules that are designed to help you gain
a better understanding of IBM products and use them more effectively to meet your business
requirements. Among many topics, you can find a ServerPac introduction module and a z/OS migration
module.
Publications
The following documents can help you plan and perform a system upgrade:
v z/OS Introduction and Release Guide
v z/OS Migration
v z/OS Summary of Message and Interface Changes
36
z/OS Planning for Installation
v ServerPac: Installing Your Order (for ServerPac orders) and in z/OS Program Directory in the z/OS
Internet library (www.ibm.com/systems/z/os/zos/library/bkserv) (for CBPDO orders).
See z/OS Information Roadmap for a list of titles and order numbers of all the z/OS product documents,
descriptions of the documents, information about the media in which they're available, and how to get
copies.
The documents previously named, as well as the rest of the z/OS product documents, are online at the
z/OS Internet Library site. The documents are provided in Portable Document Format (PDF) form and
served by Library Server. You can download them and then print (or browse) them on almost any
workstation platform by using the Adobe Acrobat Reader, which is available free from the web. Or, with
the Infoprint Server feature of z/OS and the Infoprint Transforms to AFP V2 for z/OS (5655-N60)
product, you can transform PDF files on z/OS to AFP format and print them on high-speed AFP printers.
Tip: The latest version of any document can be found at the z/OS Internet library (www.ibm.com/
systems/z/os/zos/library/bkserv), which is updated more frequently than the CDs and DVDs.
Other sources of information include:
v IBM Redbooks, which are developed and published by the IBM International Technical Support
Organization (ITSO). These documents, which are named for the color of their covers, are “how to”
documents written by experienced IBM professionals from all over the world. You can find IBM
Redbooks at IBM Redbooks (www.ibm.com/redbooks).
v “Flashes”, which are articles that are written by IBM Systems Center personnel. Flashes alert customers
and IBM personnel to significant new technical developments and guidance for the installation, use,
and maintenance of IBM products. You can find flashes at IBM Technical Support Flashes site
(www.ibm.com/support/techdocs/atsmastr.nsf/Web/Flashes).
Chapter 1. Learning about z/OS
37
38
z/OS Planning for Installation
Chapter 2. Choosing the software installation and delivery
methods
You were introduced to the various packages available for installing z/OS in “Methods of installing
z/OS” on page 20. You learned that ServerPac and CBPDO are entitled (provided as part of your z/OS
license). Other packages, such as SystemPac, are available for an additional fee. Now it is time to choose
one of the installation packages. This topic helps you make your decision.
This topic also helps you choose how you want your order delivered: on tape, DVD, or electronically
using the Internet.
Choosing an installation package for installing z/OS
|
If you are a new customer (never had z/OS), use one of the following installation packages to install
z/OS V2R3:
v Of the entitled packages (ServerPac and CBPDO): Use ServerPac using the full system replacement
installation path. You will also need the Customized Offerings Driver (5751-COD) as a driving system.
(The Customized Offerings Driver is also entitled.)
v Of the packages available for an additional fee: Use SystemPac in full volume dump format or one of
the other fee offerings.
|
If you are migrating to z/OS V2R3 from z/OS V1R13 or earlier, you are migrating from a release that is
no longer supported for migration. Contact your IBM representative to find out what alternatives are
available.
|
|
If you are migrating to z/OS V2R3 from z/OS V2R1 or V2R2, use any of the following installation
packages to install z/OS V2R3:
v Of the entitled packages (ServerPac and CBPDO):
|
– Use ServerPac if most of the elements and features already installed on your system are not
equivalent to the z/OS V2R3 level. Of your two choices within ServerPac, software upgrade is
preferable to full system replacement in the following cases:
- You are creating a new system image that will share operational data sets (like the master catalog
and parmlib) with existing systems.
- Your new environment will be similar to your old one.
- Your data set layouts will be the same or similar. IBM recommendations are described in “Placing
data sets on specific volumes” on page 83.
|
|
|
- You prefer to migrate your operational data sets before (not after) IPLing the new system for the
first time.
– Use CBPDO only if most of the elements and features already installed on your system are
equivalent to the z/OS V2R3 level, your enterprise has good to excellent product installation skills,
and you are within six months of service currency. Otherwise, using ServerPac will probably take
significantly less time and effort.
– As of z/OS V2R3, non-SMP/E installable products will be supported only in ServerPac or Product
ServerPac. They are not supported in CBPDO.
Note: Most customers choose ServerPac rather than CBPDO.
v Of the packages available for an additional fee, such as SystemPac full volume dump, SystemPac
dump-by-data-set, and the more-tailored services:
© Copyright IBM Corp. 2002, 2017
39
– Use SystemPac full volume dump if you can. The restore of the system is performed by way of
volume restore. You get an IPLable system within a day. There is no need to use installation dialogs
for restoring and customizing. All customizing is performed up front during local order entry, which
an IBM technical representative will guide you through.
– Use SystemPac dump-by-data-set if you want to do a software upgrade instead of a full system
replacement. The software upgrade installation path is preferable to a full system replacement for
the same reasons as described in a ServerPac installation.
– Choose other fee offerings (for example, Select in the United Kingdom, Software Management in
Germany, Express Plus Offering in France) if you want to have more than a system replacement
done. Some of the additional activities you might want done for you are system automation;
production cutover; database and related applications migration; backup and recovery; data
management; disaster recovery; parmlib, proclib, and VTAMLST conversion; and on-site support.
Note: To find out the driving system software and hardware requirements necessary to install a
ServerPac, CBPDO, or SystemPac order, see Chapter 3, “Preparing the driving system,” on page 45.
Installing z/OS without using an installation package
You might find that sharing system libraries or cloning an already-installed z/OS system is faster and
easier than installing z/OS with an IBM installation package such as ServerPac. You do not have to wait
for the order to be processed and the package delivered, and you do not have to use the CustomPac
Installation Dialog twice. Sharing the system libraries (logical SYSRES volume) may also save DASD and
support costs because you only need to install service (or additional products) once.
However, before sharing or cloning z/OS, you must have a license for each z/OS operating system that
you run. If you do not have the appropriate license or licenses, you must contact IBM. Any sharing or
cloning of z/OS without the appropriate licenses is not an authorized use of such programs.
Choosing the delivery medium: tape, DVD, or Internet
You can have products delivered to you on tape, DVD, or electronically by using the Internet:
v Tape is the original delivery medium and can be used for all products, that is, z/OS and products that
run on z/OS. Your order is placed and processed through Shopz, or any of the other ordering
methods, as either an IBM 3590 or IBM 3592 tape media order. The tapes include a bar code on the
side label to facilitate use in automated tape libraries. The program directories, SystemPac Installation
Guide, ServerPac: Installing Your Order, and CBPDO Memo to Users Extension are delivered on a separate
DVD media (in PDF format) along with the tape media.
|
|
|
|
IBM intends to discontinue delivery of z/OS platform products and service on magnetic tape in the
future. IBM recommends downloading products and service. However, if you requirer physical media,
products and service are also available on DVD. For reference, see the IBM statement of direction in
Preview: IBM z/OS Version 2 Release 3 - Engine for digital transformation, which is dated February 2017.
v DVD, like tape and the Internet, can be used for all products; that is, z/OS and products that run on
z/OS. Choosing DVD delivery reduces the size of shipments to you and eliminates the need to
introduce foreign tapes into your site. Your order is placed and processed through Shopz as a DVD (4.7
GB single-sided, single-layered) media order. To upload your DVD order, you need a DVD reader and
a workstation that is network-attached to your z/OS host system.
v Internet delivery, like tape and DVD, can be used for all products, that is, z/OS and products that run
on z/OS. You must place the order by using Shopz. You can install the order by using ServerPac,
CBPDO, or SystemPac. Shopz generates a customized download page for each order; the page includes
order content and instructions. Support to install Internet orders is added to the CustomPac Installation
Dialog and CBPDO installation process.
40
z/OS Planning for Installation
|
|
|
A typical z/OS-only ServerPac or SystemPac order is approximately 12 GB (compressed) in size. A typical
SystemPac order with multiple SRELs is approximately 15 GB (compressed) in size. A typical subsystem
ServerPac or SystemPac order is approximately 1 GB (compressed) in size.
|
|
|
If you choose Internet delivery, you can estimate how long a download takes for a specific order by using
the download speed table at the Download Support website (www6.software.ibm.com/regsvs/nethelp/
download.html).
Choosing the Internet download method: direct or intermediate
If you choose Internet delivery, you also have to choose whether to download your order directly to
z/OS (recommended) or download it to an intermediate node (a workstation) and then forward it to
your z/OS system. Table 7 and the security sections that follow help you understand the characteristics of
each download method and which method is most appropriate for your environment.
Table 7. Considerations for download methods (direct versus intermediate)
If downloading directly to z/OS
Considerations
If downloading to a workstation as
an intermediate node
Minimum recommended bandwidth 100 KBPS between your host and the
(higher bandwidth reduces download IBM server.
times)
100 KBPS between your intermediate
workstation and the IBM server.
Direct access to the Internet and
driving system
The workstation that will be used to
download the package must have
access to the Internet.
Your z/OS system must have access
to the Internet and your firewall and
security policies support connectivity
to the Internet.
The workstation must also have the
ability to make Internet packages
available to the z/OS host system.
ServerPac and SystemPac orders: the
workstation can be configured as an
FTP server or the package can reside
on a network drive that is accessible
by the host.
Software requirements
Hardware requirements
For ServerPac and SystemPac
dump-by-data-set, see item
“Identifying driving system software
requirements for installing z/OS
using ServerPac or dump-by-data-set
SystemPac” on page 46.
For ServerPac and SystemPac
dump-by-data-set, see items
“Identifying driving system software
requirements for installing z/OS
using ServerPac or dump-by-data-set
SystemPac” on page 46.
For CBPDO, see “Identifying driving
system software requirements for
installing z/OS using CBPDO” on
page 54.
For CBPDO, see “Identifying driving
system software requirements for
installing z/OS using CBPDO” on
page 54.
For SystemPac full volume dump, see
“Identifying driving system software
requirements for installing z/OS
using full volume dump SystemPac”
on page 52.
For SystemPac full volume dump, see
“Identifying driving system software
requirements for installing z/OS
using full volume dump SystemPac”
on page 52.
See “Identifying driving system
hardware requirements” on page 58.
See “Identifying driving system
hardware requirements” on page 58.
Chapter 2. Choosing the software installation and delivery methods
41
Table 7. Considerations for download methods (direct versus intermediate) (continued)
If downloading directly to z/OS
If downloading to a workstation as
an intermediate node
For ServerPac and SystemPac
dump-by-data set, you can resubmit
the RECEIVE job, and the SMP/E
GIMGTPKG service routine manages
the resumption of the download from
the file that was interrupted.
The download is resumed with the
file that was interrupted.
Considerations
Restart capability if transfer is
interrupted
Also supports ability to suspend and
resume download.
For CBPDO, you can resubmit the
RFNJOBS or RFNJOBH job, and the
RECEIVE FROMNETWORK service
manages the resumption of the
download from the file that was
interrupted.
For SystemPac full volume dump,
you can resubmit the GETORDRS or
GETORDRH job, and the SMP/E
GIMGTPKG service routine manages
the resumption of the download from
the file that was interrupted.
Background capability
For ServerPac and SystemPac
The download applet runs as a
dump-by-data set, you can generate
separate task but cannot be
the RECEIVE job in the CustomPac
scheduled for specific initiation times.
Installation Dialog, which retrieves
the package as a background request.
For CBPDO, you can obtain the
RFNJOBS or RFNJOBH job from the
Shopz download page for your order.
When the job is run on your host
system, it retrieves the CBPDO
package as a background request.
For SystemPac full-volume-dump,
you can obtain the GETORDRS or
GETORDRH job from the Shopz
download page for your order. When
the job is run on your host system, it
retrieves the SystemPac package as a
background request.
Authentication to access order
IBM-supplied user ID and password IBM-supplied user ID and password
for Shopz. Also, access to download
for Shopz.
the order is controlled by user ID and
password.
Internet package integrity
SHA-1 hashing algorithm and
verification.
42
z/OS Planning for Installation
RSA encryption to create a digital
signature. A unique client and server
public/private key pair is created.
Table 7. Considerations for download methods (direct versus intermediate) (continued)
If downloading directly to z/OS
If downloading to a workstation as
an intermediate node
Access to order information is
controlled by the Shopz user ID and
password. Also, you can use the
RACF SERVAUTH class to control
access to the IP stack and FTP client
authentication.
Access to order information is
controlled by the Shopz user ID and
password.
Considerations
Controlling who can download the
package
If the z/OS Security Server (RACF
Base) product is present in the order
then a RACF database containing the
minimal RACF definitions required
to IPL the target system is also
available with the order.
Security of your Internet order
Internet delivery uses a combination of industry standard authentication and data integrity approaches to
provide security for information about your order and to ensure the integrity of the contents of your
order. Your Shopz user ID and password protects sensitive data associated with your order from access
by others. This sensitive data includes the status of your order and information required to access your
order on the IBM server.
Hashing algorithms are used for both download methods (directly to z/OS and to a workstation as an
intermediate node). For downloads directly to z/OS, SMP/E ensures the data integrity of your package
through its assignment of a hash value during packaging of your order and verification of that hash
value upon download. SMP/E uses the ICSF One-Way Hash Generate callable service, or the Java
application class if ICSF is not configured, to perform the verification.
When you use Secure FTP (FTPS) or HTTP Secure (HTTPS) to download your order directly to your
z/OS host system, the package is encrypted during transmission. When you use Download Director to
download your order to a workstation as an intermediate node, the package is encrypted during
transmission.
Network security
Before downloading your order, you must understand your network security environment. For example,
v Does a z/OS image have access to the Internet?
v Are there security concerns for downloading to a workstation or transferring files to the host?
If you are planning to download directly to z/OS, you must be familiar with the security and networking
information required to navigate your enterprise's firewall or proxy server from z/OS:
v For ServerPac and SystemPac dump-by-data-set, this information is used by the CustomPac Installation
Dialog.
v For CBPDO, this information must be supplied within the RFNJOBS or RFNJOBH job that is supplied
on the Shopz download page.
v For SystemPac full-volume-dump, this information must be supplied within the GETORDRS or
GETORDRH job that is supplied on the Shopz download page.
Server information defines the IBM server where your order resides. The server information specifies:
v The IP address or host name of the IBM server.
v User ID and password information to access the IBM server.
Chapter 2. Choosing the software installation and delivery methods
43
If you are downloading your order to a workstation and you plan to use SMP/E RECEIVE
FROMNETWORK to transfer the order to z/OS, you must update the server information to reflect the
workstation's FTP server information.
Some firewall programs require an explicit IP address. The address depends on your domain. To
determine the IP address, you can use the FTP ping command to the server identified on the
customized download pages for ServerPac orders. For example, issue ping deliverycbbld.dhe.ibm.com. This returns the IP address.
v Package information: package attribute file, hash value, and the package ID (which is used as the
package directory in the SMPNTS).
Client information describes:
v The IP address or host name of the firewall or proxy server
v IP port
v User ID and password
v Account information
v Firewall-specific or proxy server commands
Both ServerPac and SystemPac (by way of the SMP/E GIMGTPKG service routine) use the One-Way
Hash Generate callable service to verify the SHA-1 hash value associated with your package. To ensure
the One-Way Hash Generate callable service is available, one of the following actions must be taken,
depending on how you intend to receive your order:
v To receive your order using FTPS, you must have ICSF configured and active, or the SMP/E Java
application class available
v To receive your order using HTTPS, you must have the SMP/E Java application class available
44
z/OS Planning for Installation
Chapter 3. Preparing the driving system
The driving system is the system image (hardware and software) that you use to install the target system.
The target system is the system software libraries and other data sets that you are installing. You log on to
the driving system and run jobs there to create or update the target system. Once the target system is
built, it can be IPLed on the same hardware (same LPAR or same processor) or different hardware than
that used for the driving system.
This topic identifies the software and hardware you will need for your driving system. See Chapter 4,
“Preparing the target system,” on page 59 for the software and hardware you will need for your target
system.
Note: If your driving system will share resources with your target system after the target system has
been IPLed, be sure to install applicable coexistence service (see “Coexistence and fallback” on page 26)
on the driving system before you IPL the target system. If you do not install the coexistence service, you
will probably experience problems due to incompatible data structures (such as incompatible data sets,
VTOCs, catalog records, global resource serialization tokens, or APPC bind mappings).
What is the Customized Offerings Driver?
The Customized Offerings Driver (5751-COD) is an entitled driving system you can use if:
v You do not have an existing system to use as a driving system, or
v Your existing system does not meet driving system requirements and you do not want to upgrade it to
meet those requirements.
The Customized Offerings Driver is a subset of a z/OS V2R1 system. It is in DFSMSdss dump/restore
format and supports DASD volumes formatted as 3390-9 or larger. The driver requires a locally attached
non-SNA terminal and a system console from the IBM (or equivalent) family of supported terminal types:
317x, 327x, 319x, or 348x.
|
|
|
As of z/OS V2R3, the Customized Offerings Driver is delivered on DVD only (three DVDs per order); it
is no longer delivered on IBM 3590 and 3592 tape media. The DVD restore process takes approximately
two hours per DVD. An IBM (or equivalent) supported tape drive can be used to restore the driver.
As of z/OS V2R2, the Customized Offerings Driver Installation Guide is shipped in PDF format on a
separate DVD. This publication is no longer shipped in hardcopy format.
The Customized Offerings Driver is intended to run in single-system image and monoplex modes only.
Its use in multisystem configurations is not supported. The Customized Offerings Driver is intended to
be used only to install new levels of z/OS using ServerPac or CBPDO, and to install service on the new
software until a copy (clone) of the new system can be made. The use of the Customized Offerings Driver
for other purposes is not supported. For example, IBM does not support the use of the Customized
Offerings Driver to run any production workload.
The Customized Offerings Driver includes a zFS file system and the necessary function to use
Communications Server (IP Services), Security Server, and the system-managed storage (SMS) facility of
DFSMSdfp, but these items are not customized. However, existing environments can be connected to, and
used from, the Customized Offerings Driver system.
Depending on the level of your existing system, the Customized Offerings Driver might be at higher
product and service levels. Therefore, as is true of the level of software you plan to install, fallback
service might be necessary to let you IPL and use your existing level of software after the Customized
Offerings Driver has been IPLed and used in any environment. You must either (1) use the Customized
© Copyright IBM Corp. 2002, 2017
45
Offerings Driver in a completely isolated environment or (2) install the needed fallback service on your
existing system before the Customized Offerings Driver is IPLed. A completely isolated environment
shares no DASD with any other system and will not be used to IPL any earlier level of software.
Installing the service on your existing system, as described in “Coexistence and fallback” on page 26, will
also satisfy the requirements for falling back from the Customized Offerings Driver. This will allow you
to IPL and use your current level of software after using either the Customized Offerings Driver or the
new system. IBM has installed the service on the Customized Offerings Driver to allow it to be IPLed
and used, if necessary, after the new system has been IPLed and used.
Identifying driving system software requirements for installing z/OS
using ServerPac or dump-by-data-set SystemPac
The driving system requirements for installing z/OS with a ServerPac or dump-by-data-set SystemPac are
described, as follows:
1. Operating system. Use either of the following:
v z/OS V2R1 or later.
|
v The Customized Offerings Driver. This entitled driving system is provided for those who do not
have an existing system to use as a driving system or whose existing system does not meet the
requirements of a driving system and who choose to not upgrade their driving system. For more
information, see “What is the Customized Offerings Driver?” on page 45.
2. TSO/E session. A TSO/E session on the IPLed system must be established using a locally-attached
or network-attached terminal.
3. Authorization. Use the RACFDRV installation job as a sample of the security system definitions
required, so that you can perform the installation tasks.
4. Security. To install the z/OS UNIX files, the following is required:
v The user ID you use must be a superuser (UID=0) or have read access to the BPX.SUPERUSER
resource in the RACF FACILITY class.
v The user ID you use must have read access to FACILITY class resources BPX.FILEATTR.APF,
BPX.FILEATTR.PROGCTL, and BPX.FILEATTR.SHARELIB (or BPX.FILEATTR.* if you choose to
use a generic name for these resources). The commands to define these FACILITY class resources
are in SYS1.SAMPLIB member BPXISEC1.
v Group IDs uucpg and TTY, and user ID uucp, must be defined in your security database. These
IDs must contain OMVS segments with a GID value for each group and a UID value for the user
ID. For ease of use and manageability, define the names in uppercase.
Rules:
– The group ID and user ID values assigned to these IDs cannot be used by any other IDs. They
must be unique.
– You must duplicate the required user ID and group names in each security database, including
the same user ID and group ID values in the OMVS segment. This makes it easier to transport
the z/OS UNIX file systems (HFS or zFS) from test systems to production systems. For
example, the group name TTY on System 1 must have the same group ID value on System 2
and System 3. If it is not possible to synchronize your databases you will need to continue
running the FOMISCHO job against each system after z/OS UNIX is installed.
If names such as uucp, uucpg, and TTY are not allowed on your system, or if they conflict with
existing names, you can create and activate a user ID alias table.
For information about defining these group and user IDs to RACF and about creating a user ID
alias table (USERIDALIASTABLE), see z/OS UNIX System Services Planning. Another source of
information is SYS1.SAMPLIB member BPXISEC1.
Note: You can use the RACFDRV installation job as a sample of the security system definitions
required to perform the installation tasks.
46
z/OS Planning for Installation
v To install into the zFS, your user ID requires read access to the SUPERUSER.FILESYS.PFSCTL
resource in the RACF UNIXPRIV class.
5. OMVS address space is active. For ServerPac only (not SystemPac), an activated OMVS address
space with z/OS UNIX kernel services operating in full function mode is required.
6. SMS is active. The Storage Management Subsystem (SMS) must be active to allocate z/OS UNIX file
systems (HFS or zFS) and PDSE data sets, whether they are SMS-managed or non-SMS-managed.
Also, the use of z/OS UNIX file systems (HFS or zFS) is supported only when SMS is active in at
least a null configuration, even when the file systems are not SMS-managed.
Note that ServerPac supports extended format and extended addressability for zFS data sets. For any
zFS data sets that exceed the 4 GB size limit, you must define an SMS Data Class with extended
format and extended addressability. Doing so will require that you specify an SMS Data Class name
(defined with extended format and extended addressability) in the CustomPac Installation dialog.
For information about providing the Data Class information, see ServerPac: Using the Installation
Dialog.
To allocate data sets, do either of the following:
v To allocate non-SMS-managed z/OS UNIX file systems (HFS or zFS) and PDSE data sets, you
must activate SMS on the driving system in at least a null configuration. You must also activate
SMS on the target system.
v To allocate SMS-managed z/OS UNIX file systems (HFS or zFS) and PDSE data sets, you must
activate SMS on the driving system in at least a minimal configuration. Then you must define a
storage group, create SMS-managed volumes, and write, translate, and activate a storage class
ACS routine that allows the allocation of z/OS UNIX file systems (HFS or zFS) and PDSE data
sets with the names in the ALLOCDS job. You must also activate SMS on the target system.
7. Language Environment requirements. The CustomPac Installation Dialog uses the Language
Environment run time library, SCEERUN. If SCEERUN is not in the link list on the driving system,
you must edit the ServerPac installation jobs to add it to the JOBLIB or STEPLIB DD statements.
Do not specify the following Language Environment run time options as non-overrideable
(NONOVR) in the CEEDOPT group of the CEEPRMxx parmlib member:
v ALL31
v ANYHEAP
v BELOWHEAP
v DEPTHCONDLMT
v ERRCOUNT
v HEAP
v HEAPCHK
v HEAPPOOLS
v INTERRUPT
v LIBSTACK
v PLITASKCOUNT
v STACK
v STORAGE
v THREADHEAP
v THREADSTACK
8. CustomPac Installation Dialog. If you are installing a ServerPac or dump-by-data-set SystemPac for
the first time, you need to install the CustomPac Installation Dialog on your driving system. See
ServerPac: Using the Installation Dialog or SystemPac: CustomPac Installation Dialog Reference Manual for
instructions. For subsequent orders you do not need to reinstall the dialog. IBM ships dialog updates
with each order. If your current dialog level is not at level 27.20.00 or later, you must update the
dialog before receiving your order. For more information, see ServerPac: Using the Installation Dialog
or SystemPac: CustomPac Dialog Reference.
|
|
|
Check the PSP bucket for possible updates to the CustomPac Installation Dialog. For ServerPac, the
upgrade is ZOSV2R3 and the subset is SERVERPAC. For SystemPac dump-by-data-set orders, the
upgrade is CUSTOMPAC and the subset is SYSPAC/DBD.
Chapter 3. Preparing the driving system
47
9. Proper level for service. To install service on the target system that you are building, your driving
system must minimally meet the driving system requirements for CBPDO Wave 1 (see “Driving
system Wave 1 requirements” on page 56) and must have the current (latest) levels of the program
management binder, SMP/E, and HLASM.
The service jobs generated by the CustomPac Installation Dialog use the target system's (and
therefore current) level of the program management binder, SMP/E, and HLASM. If you choose to
use your own jobs, model them after the jobs provided by ServerPac or dump-by-data-set SystemPac
by adding STEPLIB DD statements to access MIGLIB (for the program management binder and
SMP/E) and SASMMOD1 (for HLASM). Be sure that the SASMMOD1 and SYS1.MIGLIB data sets
are APF authorized.
Another way to install service is from a copy of your target system.
10. SMP/E ++JAR support. If your ServerPac order contains any product that uses the ++JAR support
introduced in SMP/E V3R2 (which is the SMP/E in z/OS V1R5), your driving system requires IBM
31-bit SDK for z/OS Java Technology Edition V6.0 (5655-R31), or IBM 64-bit SDK for z/OS Java
Technology Edition V6.0 (5655-R32), or higher. z/OS itself does not use the ++JAR support.
11. zFS configured properly. If you will use a zFS for installation, then you must be sure that the zFS has
been installed and configured, as described in z/OS Distributed File Service zFS Administration
12. Internet delivery requirements. As of May 22, 2016, you can no longer download ServerPac or
SystemPac dump-by-data-set orders to your z/OS host system from IBM download servers using
Standard FTP. If you intend to receive your order through the Internet, note the following
considerations:
v The Standard FTP (FTP) option is available only for orders that are downloaded from an
intermediate server.
v If you intend to receive your order using Secure FTP (FTPS), you need the following:
– SMP/E V3R6 or higher
– z/OS System SSL Security Level 3 Feature
– ICSF configured and active or IBM 31-bit SDK for z/OS, Java Technology Edition V6.0
(5655-R31), or IBM 64-bit SDK for z/OS, Java Technology Edition V6.0 (5655-R32), or higher
installed, which enables SMP/E to calculate SHA-1 hash values to verify the integrity of data
being transmitted. If ICSF is not configured and active, SMP/E will use its Java application
class instead for calculating the SHA-1 hash values. IBM recommends the ICSF method because
it is likely to perform better than the SMP/E method. (To find out how to configure and
activate ICSF, see z/OS Cryptographic Services ICSF System Programmer's Guide).
– A download file system. Your order is provided in a compressed format and is saved in a
download file system. The size of this file system should be approximately twice the
compressed size of your order to accommodate the order and workspace to process it.
– Firewall configuration. If your enterprise requires specific commands to allow the download of
your order through a local firewall, you must identify these commands for later use in the
CustomPac Installation Dialog, which manages the download of your order.
– Ensure that the Root 2 - GeoTrust Global CA Certificate is connected to your security manager
keyring and trusted on your system, and that the user ID that executes SMP/E is authorized to
use the keyring.
– Ensure that your FTP.DATA data set statements used in the RECEIVE job are set appropriately
for your environment. For example, an FTPKEEPALIVE statement with a value of 0 (the
default) can cause an FTP control connection to time out in some environments. Also, the
security manager keyring file specified by the KEYRING statement in the FTP.DATA file might
require certificates to be added. For details about specifying FTP.DATA statements, see z/OS
Network File System Guide and Reference.
v If you intend to download your order using HTTP Secure (HTTPS), you need the following:
– SMP/E V3R6 with PTFs UO01693 (Base), UO01695 (Japanese), and UO01741 (Base) or higher
– SMP/E uses the services of IBM 31-bit SDK for z/OS Java Technology Edition V6.0 (5655-R31),
or IBM 64-bit SDK for z/OS Java Technology Edition V6.0 (5655-R32) or higher.
48
z/OS Planning for Installation
– A download file system. Your order is provided in a compressed format and is saved in a
download file system. The size of this file system should be approximately twice the
compressed size of your order to accommodate the order and workspace to process it.
– HTTP or SOCKS Proxy Server configuration. If your enterprise requires specific commands to
allow the download of your order through an HTTP or SOCKS Proxy Server, you must identify
these commands for later use in the CustomPac Installation Dialog, which manages the
download of your order.
– Ensure that the Root 2 - GeoTrust Global CA Certificate is connected to your security manager
keyring or stored in your default Java keystore file and trusted on your system, and that the
user ID that executes SMP/E is authorized to use the keyring or default Java keystore file.
v For more information about how to set up FTPS or HTTPS, see the topic on preparing for secure
Internet delivery in SMP/E for z/OS User's Guide.
v For instructions on how to set up and verify that your system can connect to the IBM download
servers, see Connectivity Test for SW Download Readiness (www.ibm.com/marketing/iwm/iwm/
web/preLogin.do?lang=en_US&source=cbct).
13. Additional Internet delivery requirements for intermediate download. If you plan to download your
ServerPac or SystemPac dump-by-data-set order to a workstation, and go from there to z/OS, follow
these requirements:
v Download Director. This is a Java applet used to transfer IBM software to your workstation. For
Download Director requirements, see Download Director - FAQ (www6.software.ibm.com/
dldirector/doc/DDfaq_en.html).
v The ServerPac or SystemPac dump-by-data-set order accessible to the host. To make the order
(files) accessible to z/OS, you can do either of the following:
– Configure the workstation as an FTP server. After you download the order to your workstation,
the dialogs used to install a ServerPac or SystemPac dump-by-data-set order can point to a
network location (in this case, your workstation) to access the order. Consult the documentation
for your workstation operating system to determine if this FTP capability is provided or if you
have to install additional software. Commercial, shareware, and freeware applications are
available to provide this support. However, IBM cannot directly recommend or endorse any
specific application. This option requires the use of ICSF or the SMP/E Java application class
for calculation of SHA-1 hash values.
Use FTP commands to upload your package. The ServerPac Internet Delivery Installation
Checklist (www.ibm.com/software/shopzseries/eServerPac_checklist.pdf) or the CustomPac
Internet Delivery Installation Checklist for Dump by Dataset (www.ibm.com/software/
shopzseries/eCustomPac_DDS_checklist.pdf) contains sample FTP commands that you can use
to transfer your package to the host. You can copy/paste and update as required to provide a
user ID and password, and to replace your_package_id with the actual workstation location
(directory) and packid with the host location (directory) for your environment. To make the
transfer easier, you can create a text file that contains these FTP commands. This file then
becomes input to the FTP program on your workstation.
– Use network drives that are mounted to z/OS. The mounting can be accomplished using the
NFS base element, server message block (SMB) support provided by the Distributed File Service
base element, or the Distributed FileManager component of the DFSMSdfp base element. The
package is received from the file system defined as your SMPNTS.
For information about NFS, see z/OS Network File System Guide and Reference. For information
about using the Distributed FileManager, see z/OS DFSMS DFM Guide and Reference.
v CD write capability. If you specified that 100% electronic delivery is required, there might be CD
images associated with your order. The images are delivered in ISO9660 format and are packaged
in zip files (with an extension of .zip). These files require your workstation to have CD write
capability and you might have to acquire software to support this capability.
14. DVD delivery requirements. If you intend to receive your ServerPac or SystemPac dump-by-data-set
order by way of DVD, you need the following:
Chapter 3. Preparing the driving system
49
a. SMP/E V3R6 or higher
b. Proper dialog level. The CustomPac Installation Dialog must be at a level of 26.00.00 or higher.
This dialog supports electronic delivery on the dialog panel CPPPPOLI.
For more information, see ServerPac: Using the Installation Dialog, or SystemPac: CustomPac
Installation Dialog Reference Manual.
15. Additional DVD delivery requirements. If you plan to copy the contents of the DVD(s) to a
workstation before making them available on a z/OS host system, then the following requirements
apply:
a. The ability to share or transfer data to the z/OS host system where the order will be installed.
b. Disk space for storing DVD files. The amount of disk space required varies by order. You need to
have sufficient space for the compressed package. The package will be uncompressed on your
host.
c. If you plan to use the 'S' option in ServerPac/SystemPac using the workstation as the server, do
the following:
v You must set up an FTP server on that workstation.
v ICSF must be configured and active or IBM 31-bit SDK for z/OS Java Technology Edition V6.0
(5655-R31), or IBM 64-bit SDK for z/OS Java Technology Edition V6.0 (5655-R32) or higher
must be installed so that SMP/E can calculate SHA-1 hash values in order to verify the
integrity of data being transmitted.
If ICSF is not configured and active, SMP/E will use its Java application class instead for
calculating the SHA-1 hash values. IBM recommends the ICSF method because it is likely to
perform better than the SMP/E method. To find out how to configure and activate ICSF, see
z/OS Cryptographic Services ICSF System Programmer's Guide. For the required SMP/E setup, see
SMP/E for z/OS User's Guide.
Preparing for installation
If you are going to install z/OS using ServerPac or dump-by-data-set SystemPac, take the following
steps:
1. Separate customization data and non-z/OS products from your system software as described in
“Separating data from software” on page 80. This will minimize your installation and migration
workload not only for this installation but for future ones.
2. Plan your data set layout ahead of time. Before running any of the jobs generated by the CustomPac
Installation Dialog, decide where (on which volumes) you want to place product libraries and other
data sets. You may choose to implement the IBM recommended layout as described in
“Recommended data set placement” on page 85, or you could lay out the same catalog and volume
structure of your current system. After completing the installation, you can save the configuration
(including layout) and use it in future installations.
The easiest way to implement the IBM recommended layout is to assign your order's data sets to
DASD volumes automatically, using the dialog's Create a Recommended System Layout function. This
function helps you configure a target system that complies with the recommended system layout. The
alternative is to assign data sets manually using either (1) the View and Change Data Sets by Selected
Attributes function or (2) the Summary Display commands on the Modify System Layout Options
panel.
As part of layout planning, decide whether you'll want to merge any data sets that have matching
attributes in order to create a single panel library, single message library, and so forth. This is most
easily done using the View and Change Data Sets by Selected Attributes option. See ServerPac: Using
the Installation Dialog or SystemPac: CustomPac Dialog Reference for information about merging data sets
in a ServerPac or dump-by-data-set SystemPac. Be aware that not all data sets that can be merged
should be merged.
3. If possible, have empty volumes available onto which you will install your order. Empty volumes
make it easier to start over if necessary. But if you choose to place data sets on volumes that are not
empty, follow these steps:
50
z/OS Planning for Installation
a. Back up the target volumes.
b. Check the names of data sets on the volumes. A data set name on a given volume must not be the
same as the name of a data set that you plan to install on that volume. You can use the View and
Change option of Modify System Layout of the CustomPac Installation Dialog to get a list of the
data sets in your order.
All data sets are initially allocated with one or more temporary high-level qualifiers, called
system-specific aliases (SSAs). Later during installation, the data sets are renamed to remove these
temporary qualifiers. If you plan to install your order using volumes that already have data sets
on them, you must ensure that the names of the data sets already on the volumes will not be
duplicated by the names of the data sets you will create, both with and without their temporary
qualifiers.
4. Make sure that any data sets you choose to SMS-manage will not have names, with or without an
SSA, that duplicate the names of existing data sets on your driving system. This is because
SMS-managed data sets cannot coexist with like-named data sets in the driving system's catalog
structure. Data sets with duplicate names will become inaccessible from your driving system during
installation, and installation jobs will fail.
5. If you have decided to do a software upgrade instead of a full system replacement, follow these steps:
a. Back up catalogs that will be updated by the installation process. You can use the Defining
Alias-to-Catalog Relationships panel in the CustomPac Installation Dialog to determine which
catalogs will be updated. Consider using a DASD backup utility such as DFSMSdss or the
IDCAMS EXPORT TEMPORARY command. (But do not use the IDCAMS REPRO command.
REPRO changes volume ownership for VSAM and SMS-managed data sets from the input catalog
to the output catalog.) For information about DFSMSdss, see z/OS DFSMSdss Storage Administration
and z/OS DFSMSdfp Storage Administration. For information about backing up catalogs using the
EXPORT command, see z/OS DFSMS Managing Catalogs and z/OS DFSMS Access Method Services
Commands.
b. Back up other operational data sets (like parmlib, proclib, and the primary RACF database) that
will be updated during the installation.
c. When using the CustomPac Installation Dialog's Modify System Layout function, make sure that
the data set layout you specify matches your current system's catalog and volume structure (with
the exception of new data sets that will be allocated as part of the installation and old data sets
that you do not need to keep). The best way to do this is to use the saved configuration from your
last order as the basis for the new configuration. The dialog does this by default, placing data sets
on the same volumes with the same names. This makes it easy to keep the new system in sync
with the old system's catalog and volume structure.
If you cannot avoid changing the layout, you have to determine whether changes must be made to
the existing system, and if so, how to make them. If the existing catalogs will never be used to IPL
a system other than the new target, or the changes will not affect other systems that use the same
catalog, you can change the existing configuration. However, if the existing catalogs will be used
to IPL other systems and there is a possibility that users of those systems will be adversely
impacted by the changes that the new catalog entries introduce, you must change your existing
environment before performing the installation, change your planned configuration to make it
compatible with your existing environment, or use new catalogs for the installation.
6. Set up parmlib and proclib concatenation as described in z/OS MVS Initialization and Tuning Reference.
This step will save migration time now and in future installations.
7. If you use indirect cataloging at your site and have chosen to do a full system replacement, you will
have some additional migration work to do after installing because the new catalogs created by the
installation process use volume/unit referencing, not indirect cataloging. You can do one of the
following:
v Add the new entries to your existing catalogs and connect the new user catalogs to your existing
catalogs.
v Update the new catalogs to use indirect and extended indirect catalog entries.
Chapter 3. Preparing the driving system
51
Identifying driving system software requirements for installing z/OS
using full volume dump SystemPac
For a SystemPac full volume dump order delivered on tape, there are three possible ways to restore your
order:
1. With stand-alone utilities.
If you do not have a z/OS driving system, your SystemPac order contains the stand-alone versions of
the following utility programs so that you can install your order:
v ICKDSF, to be used to initialize DASD, create VTOCs, and perform other utility functions during
system installation
v DFSMSdss, to restore the volume from tape to DASD
The utilities are provided based on selections you make during local order entry. See the SystemPac
Installation Guide supplied with your order for details about running these utilities.
2. With batch JCL.
This is the most common way to install a full volume dump order. If you have a z/OS driving
system, you can install your order through a batch job that initializes and restores the DASD volumes.
However, you need to have the following software:
v ICKDSF R17 or later.
v DFSMSdss or Innovation Data Processing FDR V5.3.44 or later.
The JCL to restore the DASD volumes is described in the SystemPac Installation Guide supplied with
your order.
A full volume dump order is a load-and-go implementation that allows you to IPL your system as it
is restored. You can customize after you start your target system. Jobs are “file-tailored” and stored in
a library, as described in the SystemPac Installation Guide.
3. With the CustomPac Installation Dialog.
If you previously installed a ServerPac or dump-by-data-set SystemPac order and you have the
CustomPac Installation Dialog installed, you can use the dialog to receive your order from the first
System and Distribution tape, and then use the dialog to install your order. If you use this method,
after your DASD volumes are restored and the catalog volume is available, you need to connect the
target system master catalog to your driving system. For details, see SystemPac Installation Guide,
which is sent with your order.
Internet delivery requirements. As of May 22, 2016, you can no longer download SystemPac full volume
dump orders to your z/OS host system from IBM download servers by using Standard FTP. If you intend
to receive your order by way of the Internet, observe the following considerations:
v The Standard FTP (FTP) option is available only for orders that are downloaded from an intermediate
server.
v If you intend to receive your order using Secure FTP (FTPS), you need the following:
– SMP/E V3R6 or higher
– z/OS System SSL Security Level 3 Feature
– ICSF configured and active, or IBM 31-bit SDK for z/OS Java Technology Edition V6.0 (5655-R31) or
IBM 64-bit SDK for z/OS Java Technology Edition V6.0 (5655-R32) or higher installed, which enables
SMP/E to calculate SHA-1 hash values to verify the integrity of data being transmitted. If ICSF is
not configured and active, SMP/E uses its Java application class instead for calculating the SHA-1
hash values. IBM recommends the ICSF method because it is likely to perform better than the
SMP/E method. (To find out how to configure and activate ICSF, see z/OS Cryptographic Services
ICSF System Programmer's Guide).
– A download file system. Your order is provided in a compressed format and is saved in a download
file system. The size of this file system should be approximately twice the compressed size of your
order to accommodate the order and workspace to process it.
52
z/OS Planning for Installation
– Firewall configuration. If your enterprise requires specific commands to allow the download of your
order through a local firewall, you must identify these commands for later use in the CustomPac
Installation Dialog, which manages the download of your order.
– Ensure that the Root 2 - GeoTrust Global CA Certificate is connected to your security manager
keyring and trusted on your system, and that the user ID that executes SMP/E is authorized to use
the keyring.
– Ensure that your FTP.DATA data set statements that are used in the GETORDRS job are set for your
environment. For example, an FTPKEEPALIVE statement with a value of 0 (the default) can cause
an FTP control connection to time out in some environments. Also, the security manager keyring file
specified by the KEYRING statement in the FTP.DATA file might require certificates to be added. For
more information about FTP.DATA statements, see z/OS Network File System Guide and Reference.
v If you intend to download your order by using HTTP Secure (HTTPS), you need the following:
– SMP/E V3R6 with PTFs UO01693 (Base), UO01695 (Japanese), and UO01741 (Base) or higher
– SMP/E uses the services of IBM 31-bit SDK for z/OS Java Technology Edition V6.0 (5655-R31) or
IBM 64-bit SDK for z/OS Java Technology Edition V6.0 (5655-R32) or higher.
– A download file system. Your order is provided in a compressed format and is saved in a download
file system. The size of this file system should be approximately twice the compressed size of your
order to accommodate the order and workspace to process it.
– HTTP or SOCKS Proxy Server configuration. If your enterprise requires specific commands to allow
the download of your order through an HTTP or SOCKS Proxy Server, you must identify these
commands for later use in the GETORDRH job.
– Ensure that the Root 2 - GeoTrust Global CA Certificate is connected to your security manager
keyring or stored in your default Java keystore file and trusted on your system, and that the user ID
that executes SMP/E is authorized to use the keyring or default Java keystore file.
v For more information about how to set up FTPS or HTTPS, see "Preparing for secure Internet delivery" in
SMP/E for z/OS User's Guide.
v For instructions on how to set up and verify that your system can connect to the IBM download
servers, see Connectivity Test for SW Download Readiness (www.ibm.com/marketing/iwm/iwm/
web/preLogin.do?lang=en_US&source=cbct).
If you intend to download your SystemPac full volume dump order to a workstation and from there to
z/OS:
|
|
|
v Download Director. This is a Java applet or Java Web Start application depending on your browser's
capability, which is used to transfer IBM software to your workstation. For Download Director
requirements, see Download Director - FAQ (www6.software.ibm.com/dldirector/doc/DDfaq_en.html).
v The SystemPac full volume dump order accessible to the host. To make the order (files) accessible to
z/OS, you can do any of the following:
– Configure the workstation as an FTP server. After you download the order to your workstation, the
GETORDRS job can point to a network location (in this case, your workstation) to access the order.
Consult the documentation for your workstation operating system to determine whether this FTP
capability is provided or if you have to install more software. Commercial, shareware, and freeware
applications are available to provide this support. However, IBM cannot directly recommend or
endorse any specific application. This option requires the use of ICSF.
– Use FTP commands to upload your package. The CustomPac Internet Delivery Installation Checklist
(www.ibm.com/software/shopzseries/eCustomPac_FVD_checklist.pdf) contains sample FTP
commands that you can use to transfer your package to the host. You can copy/paste and update as
required to provide a user ID and password, and to replace your_package_id with the actual
workstation location (directory) and packid with the host location (directory) for your environment.
To make the transfer easier, you can create a text file that contains these FTP commands. This file
then becomes input to the FTP program on your workstation.
– Use network drives that are mounted to z/OS. The mounting can be accomplished by using the
NFS base element, server message block (SMB) support provided by the Distributed File Service
Chapter 3. Preparing the driving system
53
base element, or the Distributed FileManager component of the DFSMSdfp base element. The
package is received from the file system that is defined as your SMPNTS.
For more information about NFS, see z/OS Network File System Guide and Reference. For information
about using the Distributed FileManager, see z/OS DFSMS DFM Guide and Reference.
v CD write capability. If you specified that 100% electronic delivery is required, there might be CD
images that are associated with your order. The images are delivered in ISO9660 format and are
packaged in a compressed file. This file requires your workstation to have CD write capability and you
might have to acquire software to support this capability.
v DVD delivery requirements. If you intend to receive your SystemPac full volume dump order on
DVD, you need SMP/E V3R6 or higher.
v Additional DVD delivery requirements. If you plan to copy the contents of the DVDs to a
workstation before you make them available on a z/OS host system, the following requirements apply:
– The ability to share or transfer data to the z/OS host system where the order is installed.
– Disk space for storing DVD files. The amount of disk space that is required varies by order. You
need to have sufficient space for the compressed package. The package is uncompressed on your
host.
– If you plan to use GETORDER GIMGTPKG steps to receive order content by using the workstation
as the server, you must set up an FTP server on that workstation.
Identifying driving system software requirements for installing z/OS
using CBPDO
When you use the CBPDO method of installing z/OS you install in three stages called waves. (Wave 1, in
order to be more manageable, is divided into several tasks called ripples.) This section describes the
driving system requirements for each wave.
Internet delivery requirements. As of May 22, 2016, you can no longer download your CBPDO order to
your z/OS host system from IBM download servers using Standard FTP. If you intend to receive your
order by way of the Internet, observe the following considerations:
v The Standard FTP (FTP) option is available only for orders that are downloaded from an intermediate
server.
v If you intend to receive your order using Secure FTP (FTPS), you need the following:
– SMP/E V3R6 or higher
– z/OS System SSL Security Level 3 Feature
–
ICSF configured and active or IBM 31-bit SDK for z/OS Java Technology Edition V6.0 (5655-R31),
or IBM 64-bit SDK for z/OS Java Technology Edition V6.0 (5655-R32) or higher installed, which
enables SMP/E to calculate SHA-1 hash values to verify the integrity of data being transmitted. If
ICSF is not configured and active, SMP/E will use its Java application class instead for calculating
the SHA-1 hash values. IBM recommends the ICSF method because it is likely to perform better
than the SMP/E method. (To find out how to configure and activate ICSF, see z/OS Cryptographic
Services ICSF System Programmer's Guide).
– A download file system. Your order is provided in a compressed format and is saved in a download
file system. The size of this file system should be approximately twice the compressed size of your
order to accommodate the order and workspace to process it.
– Firewall configuration. If your enterprise requires specific commands to allow the download of your
order through a local firewall, you must identify these commands for later use in the RFNJOBS job
which manages the download of your order.
– Ensure that the Root 2 - GeoTrust Global CA Certificate is connected to your security manager
keyring and trusted on your system, and that the user ID that executes SMP/E is authorized to use
the keyring.
54
z/OS Planning for Installation
– Ensure that your FTP.DATA data set statements used in the RFNJOBS job are set appropriately for
your environment. For example, an FTPKEEPALIVE statement with a value of 0 (the default) can
cause an FTP control connection to time out in some environments. Also, the security manager
keyring file specified by the KEYRING statement in the FTP.DATA file might require certificates to
be added. For details about specifying FTP.DATA statements, see z/OS Network File System Guide and
Reference.
v If you intend to download your order using HTTP Secure (HTTPS), you need the following:
– SMP/E V3R6 with PTFs UO01693 (Base), UO01695 (Japanese), and UO01741 (Base) or higher
– SMP/E uses the services of IBM 31-bit SDK for z/OS Java Technology Edition V6.0 (5655-R31), or
IBM 64-bit SDK for z/OS Java Technology Edition V6.0 (5655-R32) or higher.
– A download file system. Your order is provided in a compressed format and is saved in a download
file system. The size of this file system should be approximately twice the compressed size of your
order to accommodate the order and workspace to process it.
– HTTP or SOCKS Proxy Server configuration. If your enterprise requires specific commands to allow
the download of your order through an HTTP or SOCKS Proxy Server, you must identify these
commands for later use in the RFNJOBH job.
– Ensure that the Root 2 - GeoTrust Global CA Certificate is connected to your security manager
keyring or stored in your default Java keystore file and trusted on your system, and that the user ID
that executes SMP/E is authorized to use the keyring or default Java keystore file.
v For more information about how to set up FTPS or HTTPS, see the topic on preparing for secure
Internet delivery in SMP/E for z/OS User's Guide.
v For instructions on how to set up and verify that your system can connect to the IBM download
servers, see Connectivity Test for SW Download Readiness (www.ibm.com/marketing/iwm/iwm/
web/preLogin.do?lang=en_US&source=cbct).
Additional Internet delivery requirements for intermediate download: If you intend to download your
CBPDO order to a workstation and from there to z/OS, in addition to these requirements you need the
following:
v Download Director. This is a Java applet used to transfer IBM software to your workstation. For
Download Director requirements, see Download Director - FAQ (www6.software.ibm.com/dldirector/
doc/DDfaq_en.html).
v The CBPDO order accessible to the host. To make the CBPDO order (files) accessible to z/OS, you can
do any of the following:
– Configure the workstation as an FTP server. After you download the order to your workstation, the
RECEIVE FROMNETWORK job (RFNJOBS) can point to a network location (in this case, your
workstation) to access the order. Consult the documentation for your workstation operating system
to determine if this FTP capability is provided or if you have to install additional software.
Commercial, shareware, and freeware applications are available to provide this support. However,
IBM cannot directly recommend or endorse any specific application. This option requires the use of
ICSF or the SMP/E Java application class for calculation of SHA-1 hash values.
– Use FTP commands to upload your package. The CBPDO Internet Delivery Installation Checklist
(www.ibm.com/software/shopzseries/ePDO_checklist.pdf) contains sample FTP commands that you
can use to transfer your package to the host. You can copy/paste and update as required to provide
a user ID and password, and to replace your_package_id with the actual workstation location
(directory) and packid with the host location (directory) for your environment. To make the transfer
easier, you can create a text file that contains these FTP commands. This file then becomes input to
the FTP program on your workstation.
– Use network drives that are mounted to z/OS. The mounting can be accomplished using the
Network File System base element, server message block (SMB) support provided by the Distributed
File Service base element, or the Distributed FileManager component of the DFSMSdfp base element.
The package is received from the file system defined as your SMPNTS.
Chapter 3. Preparing the driving system
55
For information about Network File System, see z/OS Network File System Guide and Reference. For
information about using the Distributed FileManager, see z/OS DFSMS DFM Guide and Reference.
v CD write capability. If you specified that 100% electronic delivery is required, there might be CD
images associated with your order. The images are delivered in ISO9660 format and are packaged in
zip files (with an extension of .zip). These files require your workstation to have CD write capability
and you might have to acquire software to support this capability.
v DVD delivery driving system requirements. If you intend to receive your CBPDO order by way of
DVD, you need SMP/E V3R6 or higher.
v Additional DVD delivery requirements. If you plan to copy the contents of the DVD(s) to a
workstation before making them available on a z/OS host system, then the following requirements
apply:
1. The ability to share or transfer data to the z/OS host system where the order will be installed.
2. Disk space for storing DVD files. The amount of disk space required varies by order. You need to
have sufficient space for the compressed package. The package will be uncompressed on your host.
3. If you plan to use RFNJOBD GIMGTPKG steps to receive order content using the workstation as
the server, do the following:
– Set up an FTP server on that workstation.
– ICSF must be configured and active or IBM 31-bit SDK for z/OS Java Technology Edition V6.0
(5655-R31), or IBM 64-bit SDK for z/OS Java Technology Edition V6.0 (5655-R32) or higher must
be installed so that SMP/E can calculate SHA-1 hash values in order to verify the integrity of
data being transmitted.
If ICSF is not configured and active, SMP/E will use its Java application class instead for
calculating the SHA-1 hash values. IBM recommends the ICSF method because it is likely to
perform better than the SMP/E method. To find out how to configure and activate ICSF, see
z/OS Cryptographic Services ICSF System Programmer's Guide. For the required SMP/E setup, see
SMP/E for z/OS User's Guide.
Driving system Wave 0 requirements
In Wave 0, you install the program management binder (part of the BCP), the HLASM base element, and
the SMP/E base element. These items must be installed on (available from) the driving system for
subsequent wave installations.
You can use either of the following as the driving system for installing Wave 0:
| v z/OS V2R1 or later.
| v The Customized Offerings Driver (5751-COD).
Wave 0 requires that the target system file system be mounted on the driving system because the code for
the program management binder and SMP/E installs into that file system.
Driving system Wave 1 requirements
In Wave 1, you install the majority of the elements and features of z/OS.
Driving system requirements for installing Wave 1 are:
1. An operating system. Use either of the following:
v z/OS V2R1 or later, except that the program management binder, HLASM, and SMP/E must be at
the current (latest) levels.
|
To satisfy the program management binder, HLASM, and SMP/E requirements, you can use a
STEPLIB DD statement to access the z/OS V2R3 program management binder, HLASM, and
SMP/E in the Wave 0 target system's SYS1.MIGLIB and ASM.SASMMOD1 data sets. Ensure that
the target system's SYS1.MIGLIB and ASM.SASMMOD1 data sets are APF-authorized on the
driving system. Also, ensure that HLASM PTF UK57150 (APAR PM14258) is installed.
|
56
z/OS Planning for Installation
v The Customized Offerings Driver V3 (5751-COD).
2. Proper security. To install the UNIX files, you require the security definitions described in item 4 on
page 46.
3. Program management binder entry in SMP/E UTILITY. The SMP/E UTILITY must have an entry for
the program management binder. You can specify any of these program names in the UTILITY entry:
IEWBLINK, HEWL, IEWL, LINKEDIT, or HEWLH096. (The linkage editor, which uses the names
HEWLKED, HEWLF064, IEWLF440, IEWLF880, and IEWLF128, cannot be used.)
4.
IEBCOPY entry update in SMP/E UTILITY. In the IEBCOPY entry of the global zone options, you
must specify PARM(WORK=2M) before you receive the FMIDs for Wave 1 elements. This change was
introduced in z/OS V2R1 because of the relfiles size increase in support of the Unicode component
in the BCP element.
5. Language Environment requirements. You must add SCEERUN (the run time library provided by
Language Environment) to your program search order because many elements and features require it.
If you wish, add SCEERUN to your LNKLST concatenation. If you do not add SCEERUN to your
LNKLST, you access SCEERUN by using STEPLIB DD statements in the individual element and
feature procedures that require them. The BCP is one element that requires access to SCEERUN; its
program management binder is the source of this requirement since OS/390 V2R10. This means that
you must make SCEERUN available (by LNKLST concatenation or STEPLIB DD statement, for
instance) to any JCL and procedures (such as SMP/E procedures) that invoke the program
management binder. This ensures that processing, such as conversion of long names to short names, is
successful.
6. OMVS address space active. Before you install the elements and features in Wave 1, you must
activate the OMVS address space in full function mode on the driving system. To activate OMVS,
complete the required customization (for example, SMS and RACF setup) as described in z/OS UNIX
System Services Planning.
7. Java runtime requirement. To install Wave 1 elements, you require IBM 31-bit SDK for z/OS Java
Technology Edition V6.0 (5655-R31), or IBM 64-bit SDK for z/OS Java Technology Edition V6.0
(5655-R32) or higher on the driving system.
8. Mounting of the target system's file system. The target system's file system must be mounted.
Driving system Wave 2 requirements
|
In Wave 2, you install z/OS V2R3, JES2 or JES3, and z/OS V2R3 SDSF. Wave 2 is optional and can be
combined with Wave 1.
The driving system requirements for Wave 2 are the same as for Wave 1. See “Driving system Wave 1
requirements” on page 56.
Identifying driving system software requirements for installing
subsystems
|
|
|
|
The driving system software required to install subsystems (DB2, CICS, IMS, and WebSphere Application
Server) using ServerPac is the same as the software in “Identifying driving system software requirements
for installing z/OS using ServerPac or dump-by-data-set SystemPac” on page 46.
To use a z/OS release as the driving system for installing subsystems, you might need to apply PTFs to
the prior release of the subsystem. For SMP/E PTFs, see Install coexistence and fallback PTFs in z/OS
Migration. For subsystem PTFs, see the subsystem program directories. Additionally, review the
subsystem PSP buckets for any updates. For ServerPac, the upgrade is ZOSV2R3 and the subset is
SERVERPAC. For SystemPac dump-by-data-set orders, the upgrade is CUSTOMPAC and the subset is
SYSPAC/DBD.
Chapter 3. Preparing the driving system
57
Identifying driving system hardware requirements
In addition to the hardware needed to run a driving system and the DASD required to install the
software, you need:
v A TSO/E terminal, preferably a color terminal if you are doing a ServerPac installation because the
ServerPac Installation Dialog uses color to identify key information on panels.
v Sufficient real storage. For ServerPac and dump-by-data-set SystemPac installations, at least 94 MB of
real storage is required for test systems on which there is one interactive TSO/E user and only the
RESTFS job will run, or at least 42 MB of real storage for systems supporting other workloads (plus
whatever real storage is needed to support the system's normal workload).
v For orders delivered on tape, a tape device capable of reading one of the following:
– IBM 3592 tape cartridges.
– IBM 3590 tape cartridges.
– A DVD reader for a 4.7 GB (single-sided, single-layered) DVD.
v For orders delivered on DVD:
– A DVD reader for a 4.7 GB (single-sided, single-layered) DVD.
– A workstation that is network-attached to your z/OS host system.
– Enough workstation hard drive space to download the order if you use store-and-forward. (About 6
GB is required for a z/OS-only order. More products require more space.)
v For orders delivered electronically (using the Internet):
– Sufficient SMPNTS DASD space for your ServerPac or CBPDO package. You will need
approximately two times the size of your order. The customized download pages indicate your
order size and the installation instructions on the download page provide formulas to help you
calculate the amount of space required for your order. As a guideline, about 6 GB (compressed) is
required for a z/OS-only order. More products require more space. A typical subsystem order is
approximately 500 MB (compressed).
To provide sufficient work space, add at least 950 cylinders to the space required to download the
package and use a secondary space allocation amount for the file system
– Enough workstation hard drive space to download the order if you use store-and-forward. (About 6
GB is required for a z/OS-only order. More products require more space.)
– A firewall configuration that supports downloads of a long duration without closing the connection.
The control connection can also benefit from keepalive packets. For more information, see z/OS
Communications Server: IP Configuration Reference.
– For direct download, using the ICSF One-Way Hash Generate callable service to verify the SHA-1
hash value can have associated hardware requirements. Enabling this function varies, depending on
your server; you might need to order and enable additional features.
For list of features that must be ordered, see z/OS Cryptographic Services ICSF System Programmer's
Guide.
Optionally, the hash value can be calculated by SMP/E (instead of by ICSF). SMP/E V3R6 and later
supports the use of an SMP/E Java application class to perform the calculation. However, the
calculation is done more quickly if ICSF is used rather than SMP/E. But ICSF must be active. If
z/OS does not detect ICSF to be active, SMP/E is used to calculate the hash value.
58
z/OS Planning for Installation
Chapter 4. Preparing the target system
The driving system is the system image (hardware and software) that you use to install the target system.
The target system is the system software libraries and other data sets that you are installing. You log on to
the driving system and run jobs there to create or update the target system. Once the target system is
built, it can be IPLed on the same hardware (same LPAR or same processor) or different hardware than
that used for the driving system.
This topic helps you identify the software and hardware you will need for your target system. See
Chapter 3, “Preparing the driving system,” on page 45 for the software and hardware you will need for
your driving system.
Choosing software products to install and identifying requisites
This task consists of:
v Choosing the z/OS base and optional features
v Identifying functional requisites for z/OS elements and features
v Planning for the system identifier for z/OS
v Choosing IBM products that you want to run with z/OS
v Choosing ISV products that you want to run with z/OS
Choosing the z/OS base and optional features
Rule: Because the z/OS base elements and optional features are integrated into a single package with
compatible service levels, you must install, with few exceptions, the entire z/OS product.
The exceptions are:
v Elements and features that are already installed do not have to be reinstalled if both of the following
are true: (1) you use the CBPDO installation method to migrate to the current z/OS release and (2) an
element or feature has not changed (its FMID did not change), or an element or feature is nonexclusive
and you've already installed its functionally-equivalent separate product version. To find out which
elements and features have changed in the current release, see Table 1 on page 2.
v Unpriced features that you did not order do not have to be installed.
v JES2 does not have to be installed if you are a JES3 customer. Starting with V2R1, the staged migration
path with old level of JES2 is no longer supported.
v JES3 does not have to be installed if you are a JES2 customer. Starting with V2R1, the staged migration
path with old level of JES3 is no longer supported.
Failure to install the entire z/OS product, except for the described exceptions, could result in an
unserviceable system until you install the entire product.
You can use the Planning and Migration Assistant (part of SMP/E) to help you determine what software
is already on a system from which you are migrating.
Alternate base
Customers may have the ability to replace some of the z/OS base functions with a commercially available
product that provides similar functions. Contact an IBM representative for qualification and pricing
information. All z/OS integrated testing results and performance claims will be voided with such
replacement.
© Copyright IBM Corp. 2002, 2017
59
The mechanism IBM uses for this accommodation is an alternate base configuration. One alternate base is
defined and is supported by the price file and the configurator. This alternate base, which contains the
base elements with IP Services (the component of base element Communications Server that provides
TCP/IP networking) disabled, is available for customers who have a commercially available product that
provides similar functions.
The alternate base, in addition to not supporting IP Services, does not support the optional feature
Communications Server Security Level 3.
Identifying functional requisites for z/OS elements and features
The base elements in z/OS represent an IPLable target system and satisfy most of the dependencies of
the base elements and optional features. But some elements and features require other features or IBM
products that are not part of the z/OS base. Moreover, some elements and features have optional
dependencies on other features or on IBM products that help you take full advantage of z/OS
capabilities. For a list of required and optional dependencies, see Appendix B, “Software requirements for
running z/OS V2R3,” on page 107.
Choosing IBM products that you want to run with z/OS
For a list of products available for ordering with z/OS, you can do either of the following:
v Use the self-service Internet application Shopz at IBM Software Shopz (www.ibm.com/software/
shopzseries/ShopzSeries_public.wss).
v Access the software configurator used in your country, select the z/OS environment, and then select
ServerPac, CBPDO, or SystemPac.
| If you are migrating to z/OS V2R3 from a prior release:
v You can find out which products have new levels by using Shopz or by using the SMP/E base
element's Planning and Migration Assistant. Both tools use data found on your system as well as the
latest IBM software product catalog.
| v You can expect that products that run on your prior z/OS release will also run on z/OS V2R3, at the
same product release levels, unless information is provided to the contrary in IBM announcement
letters or in Appendix B, “Software requirements for running z/OS V2R3,” on page 107. To find out the
levels of products that you currently have on your system, you can use the SMP/E Planning and
Migration Assistant. Be sure that the products you are running will be service supported in the
timeframe you are considering using them. You can find service support dates in the software
descriptions (sales manual) at the IBM Offering Information website (www.ibm.com/common/ssi).
Choosing ISV products that you want to run with z/OS
For a list of independent software vendors (ISVs) that support z/OS, as well as announcements,
testimonials, and other information, see ISVs and IBM z Systems (www.ibm.com/systems/z/solutions/
isv).
For a directory of ISV products that support z/OS, see the Global Solutions Directory
(www.ibm.com/partnerworld/gsd).
Planning for the system identifier for z/OS
If you are using a sub-capacity pricing metric for z/OS and need to produce a sub-capacity report each
month, you can do so by using Sub-Capacity Reporting Tool (SCRT).
SCRT uses the z/OS system identifier (SID) to uniquely identify a specific instance of the operating
system. On z/OS systems, the SYSID value is assigned by the SID parameter in the SMFPRMxx member
of SYS1.PARMLIB. Do not confuse the SYSID parameter with the subsystem ID that is assigned to
60
z/OS Planning for Installation
subsystems such as JES2, JES3, and IMS. The subsystem names (IDs) are assigned in the IEFSSNxx
member of SYS1.PARMLIB. SCRT has no dependencies on the values that are assigned to z/OS
subsystems.
The SYSID requirements differ depending on whether you are using a classic SCRT release or a Java
based SCRT release, as follows:
v For a classic SCRT release (earlier than SCRT V24.10.0), each SYSID assigned to an operating system
instance must be unique for an LPAR on the processor during the entire reporting period. That is, each
system identifier is associated with a single LPAR name. There is no restriction on assigning multiple
(different) SYSIDs to operating system instances running at different times (for instance, different IPLs)
in the same LPAR if those SYSIDs are not also used in other LPARs.
v For a Java based SCRT release (SCRT V24.10.0 or later), duplicate SYSIDs are allowed on different
native LPARs on the same processor.
It is recommended that you review the SCRT requirements before you choose z/OS system identifiers.
For more information about the SCRT and its requirements, see the Sub-Capacity Reporting Tool home
page (www.ibm.com/systems/z/swprice/subcap/scrt) and z/OS Planning for Sub-Capacity Pricing.
Ordering z/OS and related IBM products
Depending on the installation method you've chosen, order z/OS or related IBM products as follows:
v ServerPac:
Use the self-service Internet application IBM Software Shopz (www.ibm.com/software/shopzseries/
ShopzSeries_public.wss) or contact an IBM representative.
|
|
The system release identifiers (SRELs) are MVS, CICS, and DB2. If an order is for multiple SRELs, it
must include the operating system (z/OS).
|
|
|
|
IBM recommends that you order all products, both SMP/E installable and non-SMP/E installable, that
you intend to install, migrate, and maintain on the same schedule as z/OS (the z/OS product set) in the
same ServerPac. (See “Product sets” on page 83 for a description of product sets.) If you need to order
from multiple SRELs, place multiple orders (and you will receive multiple ServerPac orders).
With Product ServerPac orders, orders for products in the MVS SREL do not need to include the
operating system. That is, you can order WebSphere Application Server for z/OS, Tivoli, or any other
Product ServerPac eligible product without having to order a base. Also, you can order Product
ServerPac eligible products in any SREL without having to order the base product for that SREL.
Product ServerPac eligible products are indicated in the Shopz product catalog by the triangle icon.
When ordering upgrades to software products for which you are currently licensed, you can generate
an SMP/E report of installed software to be upgraded, and upload the report to Shopz. Shopz selects
upgrades and performs technical requisite checking. Shopz then lets you submit the order and track it
through delivery.
Typically, when a z/OS release becomes orderable in ServerPac, the previous release remains orderable
for one more month. Refer to z/OS announcements for exact dates.
v CBPDO:
Use the self-service Internet application at IBM Software Shopz (www.ibm.com/software/shopzseries/
ShopzSeries_public.wss), use IBMLink, or contact an IBM representative..
|
|
|
An order can be for products in one or more of the following system release identifiers (SRELs): MVS,
DB2, and CICS. Because z/OS is a large product, you can minimize the size of your order by placing
separate orders for z/OS itself and for other products in the same SREL (MVS).
When ordering upgrades to software products for which you are currently licensed, you can generate
an SMP/E report of installed software to be upgraded, and upload the report to Shopz. Shopz selects
upgrades and performs technical requisite checking. Shopz then lets you submit the order and track it
through delivery.
Chapter 4. Preparing the target system
61
If the equivalent level of a nonexclusive optional priced feature is currently running on your system,
and a CBPDO installation is planned for the next release with the intent of not replacing that
equivalent level of the feature during the installation, then the z/OS level of that feature must be
ordered, even if it will not be installed, to ensure that the appropriate product policy statements are
shipped for that feature.
Any country that has Shopz product delivery can have those products delivered electronically.
v SystemPac:
Use the self-service Internet application IBM Software Shopz (www.ibm.com/software/shopzseries/
ShopzSeries_public.wss), use IBMLink, or contact an IBM representative..
Unlike a ServerPac order, a SystemPac order can be for multiple SRELs. IBM recommends that you
order in the same SystemPac all products that you intend to install, migrate, and maintain on the same
schedule as z/OS.
When you place your SystemPac order, be sure to select the selective follow-on services (SFSs) as well.
You can specify a maximum of three SFSs at intervals of 30, 60, or 90 days apart. SFSs contain PTFs
fixing PE and HIPER PTFs that are discovered after your system is built. SFSs are tailored to the
SMP/E CSI of your system. The goal of SFSs is to stabilize your system over time, thus improving its
availability. SFSs are delivered on the same media type as your original order.
Upon placing the order, an IBM representative will contact you to provide additional help to have your
order enriched. Enrichment is an important part of SystemPac. Through a local order entry tool, your
system's parameters (such as volume serials, DASD types, catalog names, SMP/E definitions, and SMS
definitions) are collected. This enables the SystemPac to be built exactly the way you specified,
eliminating the need for customizing upon system restore. This also enables IBM to enable subsystems
and products according to your specifications (for example, z/OS UNIX in full function mode
according to your SMS specifications).
You also need to send a copy of your IODF to the IBM manufacturing center. Your SystemPac will be
built according to your IODF input. You can send the IODF electronically or using physical media.
Note:
v As of z/OS V2R1 SystemPac has been withdrawn from many geographic locations. Consider an
alternate method for ordering.
v The Print Services Facility™ (PSF) product should be treated as part of the z/OS product set. (Product
sets are discussed in “Product sets” on page 83.) If you want to use PSF and you plan to install with
ServerPac or SystemPac, include PSF in your product order.
Most new products and releases become orderable in ServerPac and SystemPac within eight weeks after
their general availability. However, the product lists might not contain the most current releases of all
products that run on z/OS. If the release of the product you want is not currently available in ServerPac
or SystemPac, and you cannot delay your order, IBM recommends that you:
1. Order ServerPac or SystemPac, omitting products not at the appropriate level.
2. Order CBPDO or ProductPac with those products you omit from ServerPac or SystemPac.
3. Install the ServerPac or SystemPac order, and then install the products from the CBPDO or
ProductPac.
The Internet delivery process
You can choose to have a ServerPac, CBPDO, or SystemPac order delivered to you entirely by Internet:
v The following items are delivered only by Internet:
– An e-mail notification that the order is ready
– Order-specific Web pages accessible through Shopz
v If you choose Internet, the following items are in an Internet format and are available from your
customized download pages:
– A softcopy packing list that describes the components of your package.
62
z/OS Planning for Installation
– CD/DVD images containing code or other materials.
– Entitled and licensed publications.
You place and receive an order as follows:
1. Place your ServerPac or SystemPac order using Shopz, specifying a preferred media of Internet.
For ServerPac or SystemPac, providing an inventory to Shopz can help you complete your checklist.
The inventory is used to customize the checklist to reflect the products that you have installed. For
CBPDO, providing an inventory to Shopz assists with product status, upgrade paths, and requisite
checking. Use the GIMXSID service routine to create the inventory.
You can also specify your delivery media preference to indicate that you require 100% Internet
delivery. In this case, you might have additional materials with your order, such as various CD
images, that must be downloaded. Installation instructions for these materials are provided on the
Shopz download pages for your order.
2. Track the status of your order. This can be done using functions available in Shopz. You will also
receive an e-mail when your order is ready.
You have 30 days to download your order. The date that the order will be removed is specified in the
e-mail.
Access to the order-specific information requires that you use the same Shopz user ID that was used
to place the order.
3. Download the various components of your order using the customized download pages available for
your order. The content of the pages is specific to the content of your order, its associated
components.
Your customized download pages include:
v A packing list and installation documentation.
v Information related to downloading the order. For ServerPac and SystemPac dump-by-data-set, this
includes information that you will need to use in the CustomPac Installation Dialog.
v Download links for the publications associated with your order.
v Optionally, download links and information for additional materials that might be included with
your order. These are typically CD/DVD images that contain publication collections or client code.
Identifying hardware requirements for the target system
This task consists of:
v Identifying server requirements.
v Identifying DASD space requirements.
v Identifying I/O device requirements.
v Identifying additional hardware needed by z/OS elements and features. See Appendix C, “Additional
hardware requirements for running z/OS V2R3,” on page 117.
Identifying server requirements
|
|
|
|
|
|
z/OS V2R3 is supported on the following IBM Z® servers:
v IBM z14™ (z14)
v IBM z13™ (z13)
v IBM z13s™ (z13s)
v IBM zEnterprise EC12 (zEC12)
v IBM zEnterprise BC12 (zBC12)
|
|
|
|
z/OS V2R3 is not supported on the following servers:
v IBM zEnterprise 196 (z196)
v IBM zEnterprise 114 (z114)
v IBM System z10® Enterprise Class (z10™ EC)
Chapter 4. Preparing the target system
63
| v
v
v
v
v
v
v
IBM
IBM
IBM
IBM
IBM
IBM
IBM
System z10 Business Class (z10 BC)
System z9® Enterprise Class (z9 EC)
System z9 Business Class (z9 BC)
eServer™ zSeries 990 (z990)
eServer zSeries 890 (z890)
eServer zSeries 900 (z900)
eServer zSeries 800 (z800).
| For the z14 server, z/OS V2R3, z/OS V2R2, and z/OS V2R1 support up to 170 processors configurable as
general purpose processors (CPs), zIIPs, IFLs, ICFs, or optional SAPs. The sum of CPs and zIIPs
configured in a single z/OS LPAR cannot exceed:
v 170 on z/OS V2R1 or later in non-SMT mode
v 128 on z/OS V2R1 or later in SMT mode.
| For the z13 and z13s™ servers, z/OS V2R3, z/OS V2R2, and z/OS V2R1 (with PTFs) support the
following maximum number of processors per LPAR:
v Up to 141 processors per LPAR, if the partition is IPLed in non-simultaneous multi-threading
(non-SMT) mode.
v Up to 213 threads per LPAR, if the partition is IPLed in simultaneous multi-threading (SMT) mode.
For other IBM servers, z/OS supports:
v Up to 100 processors per LPAR on the zEC12.
Notes:
1. z/OS V2R3 must be IPLed in z/Architecture mode.
| 2. The total number of processors that are defined in a z/OS LPAR is the sum of general purpose
|
processors (CPs), zIIPs, IFLs, ICFs, or optional SAPs.
| 3. The z14™, z13, and z13s servers do not support the IBM zEnterprise Application Assist Processor
|
(zAAP).
| 4. Coupling Facility Levels (CFLEVELs) have hardware and software requirements. For more
|
information, see Coupling Facility Level (CFLEVEL) Considerations (www.ibm.com/systems/z/
|
advantages/pso/cftable.html).
Processor storage amount
z/OS supports an architectural limit of 4 terabytes (TB) of processor storage per logical partition (LPAR).
However, the actual amount of processor storage that is supported per server and LPAR varies,
depending on the IBM server.
Table 8 shows the maximum amount of processor storage that is supported by z/OS for each of the IBM
servers.
Table 8. Maximum amount of processor storage supported by z/OS
|
IBM server
Maximum amount of processor storage per
server
Maximum amount of processor storage per
LPAR
IBM z14™ (z14™)
32.0 TB with z/OS V2R3
4 TB with z/OS V2R3
z13
10.0 TB with z/OS V2R2
4 TB with z/OS V2R2
z13s
4.0 TB with z/OS V2R2
4 TB with z/OS V2R2
zEC12
3.0 TB
1 TB
zBC12
496 GB
n/a
TM
For the storage amounts, note that:
v 1 TB equals 1,099,511,627,776 bytes
64
z/OS Planning for Installation
v 1 GB equals 1,073,741,824 bytes.
To run z/OS as a guest under z/VM, the minimum release of z/VM required is V5.4.
|
Minimum processor storage amount for IPLing a z/OS system
|
|
|
For z/OS V2R3 with the IBM z14™ server, a minimum of 8GB of processor storage is required. When
running as a z/VM guest or on an IBM z Personal Development Tool (zPDT), z/OS V2R3 requires a
minimum of 2GB of processor storage.
|
|
|
|
If you attempt to IPL z/OS V2R3 on a z14 with less than the minimum of processor storage amount,
z/OS issues a warning message (a WTOR) during IPL. Continuing with less than the minimum amount
of processor storage could impact the availability of your system. If you attempt to IPL z/OS V2R3 on an
earlier IBM server, no warning message is issued.
|
|
To assist your installation with migrating from z/OS V2R1 or V2R2, IBM provides a new health check
that issues a warning for a system that is configured with less than 8GB of processor storage.
|
|
|
|
|
|
|
For earlier combinations of z/OS systems and IBM server models, smaller amounts of processor storage
might be required for IPL. The minimum amount of processor storage that is required to IPL a z/OS
system depends on various factors, including the following:
v Number of devices in the I/O configuration
v Number of address spaces to be created
v Types of applications to be supported
v Products and subsystems to be supported.
|
|
|
|
|
|
|
In internal tests that were conducted at IBM, it was found that 256 MB of processor storage was the
minimum amount required to IPL a z/OS V2R2 system. The test systems were IPLed to the point of
initializing the JES2 subsystem, and had I/O configurations that were defined with the following devices:
v 51168 direct access storage devices (DASD)
v 16 graphics devices
v 5127 channel-to-channel (CTC) connections
v 52 tape drives.
|
|
An actual production system will likely require more than 256 MB of processor storage for normal
operations.
|
|
|
|
|
|
|
For any release of z/OS, it is recommended that you monitor your processor storage usage, and
determine whether to add more for better execution of workloads. The minimum stated here is not a
likely environment for many installations, however, it has been observed that many systems perform
adequately with between 8GB to 16GB of processor storage, depending on the workload and system
definition. A good indication that you have chosen an acceptable processor storage amount for your
system is if no paging occurs, or if the amount of paging that occurs is within your service level
objectives.
PSP hardware upgrade identifiers
For the latest hardware dependencies for z/OS, see Preventive Service Planning buckets
(www.ibm.com/support/customercare/psearch/search?domain=psp).
The PSP hardware upgrade identifiers are:
v 3906DEVICE for the IBM z14 (z14) server
v 2964DEVICE for the z13 server
v 2965DEVICE for the z13sTM server
v 2827DEVICE for the zEC12 server
v 2828DEVICE for the zBC12 server
Chapter 4. Preparing the target system
65
Identifying DASD space requirements
The DASD required for z/OS includes:
v All elements
v All features that support dynamic enablement, regardless of your order
v All unpriced features that you ordered.
The storage requirements for z/OS can be found in the topic about total DASD storage requirements in
z/OS Program Directory in the z/OS Internet library (www.ibm.com/systems/z/os/zos/library/bkserv).
Products that run on z/OS require additional storage.
Identifying I/O device requirements
| z/OS supports these and later IBM storage control units:
| v 3990 Model 3 and 3990 Model 6
| v IBM RAMAC 9393 Virtual Array Storage
| v IBM TotalStorage Enterprise Storage Server® (machine type 2105)
| v IBM System Storage DS8000 series (machine types 2107, 2421, 2422, 2423, and 2424).
z/OS supports Fiber Connection (FICON®), Enterprise Systems Connection (ESCON), and Enterprise
Systems Architecture/390 (ESA/390) devices.
Table 9 on page 67 lists the most commonly used I/O devices that are supported by z/OS. If you have a
question about support for a device that is not listed, contact your IBM representative.
Note: Table 9 on page 67 does not comprise a list of devices that are service supported. Many of the
devices have been withdrawn from service support. Rather, the table comprises a list of devices that are
supported by the software (z/OS). Normally, when devices are withdrawn from service, they continue to
be supported by the software. DASD devices that are attached to some older controllers, such as a 3880,
3990-1, or 3990-2, can still be defined in Hardware Configuration Definition (HCD), but these devices
| cannot be varied online to a z/OS V2R3 system.
Use of the IBM TotalStorage Enterprise Storage Server (2105) with z/OS requires the 2105 microcode to
be at EC fix level F25584 or later. This EC level fixes a problem that is caused by software exploitation of
the SII/RND CCW commands.
For a table summary of device information, see z/OS MVS Device Validation Support. The table shows the
order that z/OS uses when it attempts to satisfy a request for a device.
66
z/OS Planning for Installation
Table 9. IBM I/O devices and subsystems supported by Version 2
Device type
Order of devices
DASD
v 2105 TotalStorage Enterprise Storage Server (ESS)
v 2107 System Storage DS8000®
v IBM System Storage DS8000 series (machine types 2421, 2422, 2423, and 2424).
v 3380 Direct Access Storage Device
v 3390 Direct Access Storage Device
v 3990-3 Storage Control
v 3990-6 Storage Control
v 9332 Direct Access Storage Device
v 9340 DASD Subsystem
– 9341 Storage Controller Module, 9343 Storage Controller, 9345 DASD Module
– 9345 DASD Module
v 9391 RAMAC Array DASD
v 9393 RAMAC Virtual Array Storage
v 9396 RAMAC Scalable Array 3 Storage
v 9397 RAMAC Electronic Array Storage
v RAMAC Array Device
Tape
v 2440 Magnetic Tape Subsystem
v 3420 Magnetic Tape Unit
v 3422 Magnetic Tape Subsystem
v 3423 Magnetic Tape Device
v 3424 Magnetic Tape Subsystem
v 3430 Magnetic Tape Subsystem
v 3480 Magnetic Tape Subsystem
v 3490 Magnetic Tape Subsystem
v 3494 TotalStorage Enterprise Automated Tape Library
v 3494 TotalStorage Enterprise Peer-To-Peer Virtual Tape Server
v 3494 TotalStorage Enterprise Virtual Tape Server
v 3495 TotalStorage Enterprise Automated Tape Library
v 3584 System Storage Automated Tape Library (TS3500)
v 3590 TotalStorage Enterprise Tape System
v 3592 System Storage Tape System (TS11xx)
v 3957 System Storage Virtualization Engine (TS7700)
Card reader and
punch
v 2501 Card Reader
v 2540 Card Read Punch
v 3505 Card Reader
v 3525 Card Punch
Chapter 4. Preparing the target system
67
Table 9. IBM I/O devices and subsystems supported by Version 2 (continued)
Device type
Order of devices
Magnetic/optical
v 2440 Magnetic Tape Subsystem
v 3420 Magnetic Tape Unit
v 3422 Magnetic Tape Subsystem
v 3423 Magnetic Tape Device
v 3424 Magnetic Tape Subsystem
v 3430 Magnetic Tape Subsystem
v 3490 Magnetic Tape Subsystem
v MVS/ESA Direct Optical Attachment
v S/370 and S/390® Optical Media Attach/2
Display
v 3178 Display Station
v 3179 Display Station
v 3180 Display Station
v 3191 Display Station
v 3192 Color Display Station
v 3194 Display Station
v 3205 Color Display Station
v 3206 Display Station
v 3251 Display Station
v 3270 Information Display System
v 3290 Information Panel
v 3472 InfoWindow Workstation
Communication
See “Hardware requirements for z/OS Communications Server” on page 125.
Identifying service needed for the target system
Before you IPL the target system for the first time, you should determine whether your target system
software is at the appropriate service level, and apply fixes if it is not. This section explains the additional
service that you might need to apply.
See “Service” on page 31 for background information on the service that is shipped with ServerPac,
CBPDO, and SystemPac orders. See “Maintenance after installation” on page 34 for guidance on applying
maintenance to your z/OS system after you have finished installing it.
If you are installing a z/OS ServerPac or Product ServerPac order
If you install your ServerPac or Product ServerPac order shortly after it arrives, you should not need to
install additional RSU service. It should already be included in your order.
But if more than a few weeks have passed since your order arrived:
v Consult ServerPac: Installing Your Order, in the topic about service included in your order, to find the
service level of the system as shipped.
v Order a service package using the service delivery vehicle you prefer, such as Shopz, SMP/E Internet
Service Retrieval, or RefreshPac. Use a starting service level one month later than the level identified in
ServerPac: Installing Your Order.
If you are installing a z/OS CBPDO order...
If you ordered z/OS as a CBPDO package:
68
z/OS Planning for Installation
|
v Install all PTFs with a SOURCEID of ZOSV2R3. In addition, install all PTFs with a SOURCEID of HIPER
or PRP provided they are not in a PTF-in-error (PE) chain.
v Consult Memo to Users Extension to find the service level of the system as shipped.
v If more than a few weeks have passed since your order arrived, there should be a service package
available; order and apply it in accordance with the guidelines in “Maintenance after installation” on
page 34. Use the service delivery vehicle that you prefer, such as Shopz or SMP/E Internet Service
Retrieval.
If you are installing a z/OS SystemPac order
IBM strongly recommends that you select, during order entry, the optional follow-on services (SFSs) that
come with the SystemPac. SFSs contain critical service information: PTFs that resolve PEs and HIPERs
that are discovered after your system is built. The SFSs you get are tailored to the image of the SMP/E
CSI of the system that IBM shipped to you earlier. By installing repeating SFSs (at most 90 days apart,
maximum of three), you stabilize the system you installed, thus enabling you to have a system with
higher availability for your applications.
SFSs can be installed by way of the CustomPac Installation Dialog or batch JCL.
If you are installing an IBM Z® server
If you are installing an IBM Z® server, check the appropriate PSP bucket before you install.
The relevant upgrades are:
v 3906DEVICE for the IBM z14™ server
v 2964DEVICE for the z13™ server
v 2965DEVICE for the z13s™ server
v 2827DEVICE for the zEC12 server
v 2828DEVICE for the zBC12 server
Using JES and SDSF with z/OS V2R3
As of z/OS V2R1, the staged migration path with old levels of JES2, JES3, and SDSF is no longer
supported.
ServerPac and SystemPac delivery of JES2, JES3, and SDSF
|
Only the latest levels of JES2, JES3, and SDSF are delivered in ServerPac and SystemPac. Starting with
z/OS V2R1, you cannot use earlier levels of JES2, JES3, or SDSF. You cannot reassemble your existing
levels of JES2, JES3, or SDSF if they are not at the z/OS V2R3 level.
Using the z/OS Font Collection with V2R1 and later
Starting with z/OS V2R1, you can use the z/OS Font Collection base element of z/OS. The z/OS Font
Collection is an exclusive base element that includes the Chinese, Japanese, and Korean (CJK) double-byte
fonts.
Table 10 on page 70 summarizes the existing font programs and indicates whether the z/OS Font
Collection base element can replace them along with the replacement name in the collection:
Chapter 4. Preparing the target system
69
Table 10. Existing font products and replacements in the z/OS Font Collection base element. Existing font products
and replacements
Included in z/OS Font
Collection with V2R1 and
later
Program
number
Product name
V.R.M.
ServerPac
PDO
5655-M32
PSF Compatibility Fonts
4.5.0
Orderable
Orderable
HFNT110
HFNT120 (V2R3 and later)
5648-B33
Advanced Function
Printing (AFP) Font
Collection
2.1.1
Orderable
Orderable
HFNT110
HFNT120 (V2R3 and later)
5648-B33
AFP Font Collection
(Japanese fonts)
2.1.1
Orderable
Orderable
HFNT11J
HFNT12J (V2R3 and later)
5648-B33
AFP Font Collection
(Korean Fonts)
2.1.1
Orderable
Orderable
HFNT11J
HFNT12J (V2R3 and later)
5648-B33
AFP Font Collection
(Traditional Chinese
fonts)
2.1.1
Orderable
Orderable
HFNT11J
HFNT12J (V2R3 and later)
5648-B33
AFP Font Collection
2.1.1
(Simplified Chinese fonts)
Orderable
Orderable
HFNT11J
HFNT12J (V2R3 and later)
5648-E76
General Font Library
1.1.0
Orderable
Orderable
HFNT110
HFNT120 (V2R3 and later)
5648-E76
General Font Library
(Traditional Chinese
fonts)
1.1.0
Orderable
Orderable
HFNT11J
HFNT12J (V2R3 and later)
5648-E76
General Font Library
1.1.0
(Simplified Chinese fonts)
Orderable
Orderable
HFNT11J
HFNT12J (V2R3 and later)
5648-E76
General Font Library
(Korean fonts)
1.1.0
Orderable
Orderable
HFNT11J
HFNT12J (V2R3 and later)
5648-E76
General Font Library
(Japanese fonts)
1.1.0
Orderable
Orderable
HFNT11J
HFNT12J (V2R3 and later)
5771-ABC
Pi and Specials Fonts
Object
1.1.1
Orderable
Orderable
HFNT110
HFNT120 (V2R3 and later)
5771-ADT
Math and Science Fonts
Object
1.1.0
Orderable
Orderable
HFNT110
HFNT120 (V2R3 and later)
|
5771-ADB
APL2 Fonts
1.1.0
Orderable
Orderable
HFNT120 (V2R3 and later)
|
5771-ADA
Data1 Fonts
1.1.0
Orderable
Orderable
HFNT120 (V2R3 and later)
|
5771-ABB
Sonoran Sans Serif Font
1.1.0
Orderable
Orderable
HFNT120 (V2R3 and later)
|
|
5771-AFL
Sonoran Sans Serif
Condensed Font
1.1.0
Orderable
Orderable
HFNT120 (V2R3 and later)
|
|
5771-AFN
Sonoran Sans Serif
Expanded Font
1.1.0
Orderable
Orderable
HFNT120 (V2R3 and later)
|
|
5771-ADX
Sonoran Sans Serif
Headliner Font
1.1.0
Orderable
Orderable
HFNT120 (V2R3 and later)
|
5771-ABA
Sonoran Serif Font
1.1.0
Orderable
Orderable
HFNT120 (V2R3 and later)
|
|
5771-ADW
Sonoran Serif Headliner
Font
1.1.0
Orderable
Orderable
HFNT120 (V2R3 and later)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
70
z/OS Planning for Installation
Chapter 5. Preparing for customization and test
You complete your installation by customizing and testing the new system. Most of the information for
performing these tasks is in the various element and feature publications. However, a few items are in
this topic: customizing for CEA, using dynamic enablement, and scheduling test activities.
Customizing for CEA
Common event adapter (CEA) is a component of the BCP that provides the ability to deliver z/OS events
to C-language clients, such as the z/OS CIM server. A CEA address space is started automatically during
initialization of every z/OS system. Additionally, CEA provides instrumentation for various services such
as z/OSMF Incident Log and BCPii to run in full function mode or to provide other instrumentation
services.
CEA has two modes of operation:
v Full function mode. In this mode, both internal z/OS components and clients such as CIM providers can
use CEA indication functions.
v Minimum mode. In this mode, only internal z/OS components can use CEA indication functions.
Security setup is required for CEA to run in full function mode; a sample job is provided in
SYS1.SAMPLIB(CEASEC) to perform security resource definitions owned by CEA.
Using dynamic enablement
As explained in Chapter 1, “Learning about z/OS,” on page 1, the priced features support dynamic
enablement. This means that the priced features that you order are shipped enabled and are ready to use
after you install and customize them. The priced features that you do not order are shipped disabled;
even though you install them, you cannot use them. Later on, if you decide to use them, you enable them
dynamically.
While priced features are the main focus of dynamic enablement, several related items can also be
dynamically enabled should you decide to use them with z/OS:
v The individual product versions of z/OS nonexclusive features.
v The product Document Composition Facility (DCF) (5748-XX9).
v IP Services, one of the components of base element Communications Server, which is shipped enabled
when you order the standard z/OS base but disabled when you order the alternate base configuration.
Note that “TCP/IP” is the name used for dynamic enablement of this component.
Note: Infoprint Server Transform products V1 (5697-F51) was removed from the list when service
support ended. The follow-on Infoprint transform products have not been added to the list because they
are not dynamically enabled.
In brief, the steps required to dynamically enable are:
1. Notify IBM that you are starting to use the feature, product, or TCP/IP on a specific processor (as
identified by a specific processor serial number).
2. Update parmlib. IBM supplies a SYS1.PARMLIB member, IFAPRD00, that is tailored to your order.
IFAPRD00 contains entries that enable the priced features, products, or TCP/IP that you ordered for a
specific processor. To make the parmlib update, copy the contents of IFAPRD00 to an IFAPRDxx
member that will be active on the processor for which your z/OS order was placed, and modify
IFAPRDxx appropriately.
© Copyright IBM Corp. 2002, 2017
71
3. Establish the active parmlib member through the PROD parameter in IEASYSxx or the SET PROD
operator command.
The rest of this section helps you decide whether you need to use dynamic enablement, describes in
detail the three steps to do it, and explains how to disable should you want to. Topics are:
v “Deciding whether to dynamically enable”
v “Dynamic enablement Step 1: Notify IBM” on page 73
v “Dynamic enablement Step 2: Update parmlib” on page 73
v “Dynamic enablement Step 3: Establish the active parmlib member” on page 77
v “Disabling what was enabled” on page 77.
Deciding whether to dynamically enable
By describing the situations that require dynamic enablement, this section helps you decide whether you
need to dynamically enable.
A priced feature was not in your original order for a specific processor (as identified by a specific
processor serial number) but you now want to use it on that processor. If this is the case, then follow
the steps starting with “Dynamic enablement Step 1: Notify IBM” on page 73.
The priced features are:
v BDT File-to-File
v BDT SNA NJE
v DFSMSdss
v DFSMShsm (and DFSMSdss)
v DFSMSrmm
v DFSMStvs
v DFSORT
v GDDM-PGF
v GDDM-REXX
v HCM
v HLASM Toolkit
v Infoprint Server
v JES3
v RMF
v SDSF
v Security Server
v XL C/C++
v zEDC
You are licensed for a product that is also a nonexclusive priced feature and the license is on a
processor other than the one to which your z/OS order applies. To allow your installation flexibility as
you migrate to z/OS, you can run the separate product versions of the z/OS nonexclusive priced features
(or, in one case, a component of a nonexclusive priced feature). Running the separate product version of
such a z/OS feature means you do not have to order and install the z/OS feature.
The products that are also z/OS nonexclusive priced features are:
v GDDM-PGF. The corresponding z/OS feature is GDDM-PGF.
v HLASM Toolkit feature of HLASM. The corresponding z/OS feature is HLASM Toolkit.
If your order included separate product versions of these features, the separate versions are enabled in
the IBM-supplied IFAPRD00 member. If you are licensed for such products on a processor other than the
one to which your z/OS order applies, you must specifically enable them because the IBM-supplied
IFAPRD00 does not. Follow the steps starting with “Dynamic enablement Step 1: Notify IBM” on page
73.
72
z/OS Planning for Installation
You are licensed for DCF on a processor other than the one to which your z/OS order applies, or not
licensed at all. The product DCF (5748-XX9) can be dynamically enabled. To use DCF, you must do one
of the following:
v If you are already licensed for DCF on a specific processor, you must explicitly enable it in the
IFAPRDxx member that is active on that processor in order to continue to use it with z/OS. Follow the
steps starting with “Dynamic enablement Step 1: Notify IBM.”
v If you are not licensed for DCF on a specific processor and would like to use it, you must purchase a
license for that processor, receive and install DCF, and then follow the steps starting with “Dynamic
enablement Step 1: Notify IBM” to enable it in the IFAPRDxx member that is active on that processor.
(It is a violation of your license agreement with IBM to enable DCF on a processor if you are not
licensed for it on that processor.)
You are licensed for the alternate base but now want to use the standard base. IP Services, the
component of element Communications Server that supports TCP/IP networking, supports dynamic
enablement because of the z/OS alternate base configuration. (Refer to “Alternate base” on page 59.) IP
Services is shipped enabled if you order the standard z/OS base but disabled if you order the alternate
base. Thus, if you are licensed for the alternate base but now want to be licensed to use the standard
base, you must enable IP Services (using the name TCP/IP). Follow the steps starting with “Dynamic
enablement Step 1: Notify IBM.”
Dynamic enablement Step 1: Notify IBM
Ask your asset manager to contact your IBM representative to alert IBM that you are starting to use the
feature, individual product, or TCP/IP on a specific processor (as identified by a specific processor serial
number). Because the z/OS license is processor-based, you need to contact IBM only once when multiple
z/OS systems execute in LPAR mode on that processor.
Use of (and enablement of) the feature, individual product, or TCP/IP is subject to the z/OS license
terms and conditions and must be done with the knowledge of your asset manager according to the
terms and conditions for z/OS. For additional license terms and conditions, see the Usage Restriction
section of z/OS Licensed Program Specifications.
Dynamic enablement Step 2: Update parmlib
The IBM-supplied SYS1.PARMLIB member that defines the product enablement policy for a system is
IFAPRD00. This member contains a PRODUCT statement for each item (feature, product, or TCP/IP) that
can be dynamically enabled, set to an enablement state determined by your order. Copy IFAPRD00 to an
IFAPRDxx of your choosing and edit IFAPRDxx, if necessary, so that it contains the correct form of
PRODUCT statements to enable each feature, product, or TCP/IP that should be enabled, as described in
the topics starting with “z/OS priced features and TCP/IP.”
If you use the order that IBM ships to you to clone systems for use on other processors, you must ensure
that the IFAPRDxx member used on each processor enables only the z/OS priced features and products
that are licensed to that processor. A single shared copy of IFAPRDxx might or might not be suitable for
use by all of the processors.
Note the following:
v DFSMSdss, DFSMSrmm, DFSMShsm, and DFSMStvs do not use the IGDDFPKG parmlib member for
enablement.
v GDDM-REXX does not use the ERXTENAB JCL member of the GDDM SADMSAM data set.
z/OS priced features and TCP/IP
For each priced feature that you want to enable, or to enable TCP/IP, ensure that there is a PRODUCT
statement (or, for TCP/IP, multiple PRODUCT statements) having one of the following forms:
Chapter 5. Preparing for customization and test
73
PRODUCT
OWNER(’IBM CORP’)
NAME(’z/OS’)
ID(5650-ZOS)
FEATURENAME(name)
STATE(ENABLED)
NAME specifies the operating system.
The variable name on the FEATURENAME parameter identifies the feature, or TCP/IP base, that you
want to enable. Refer to Table 11 for possible values.
ID specifies the program number for z/OS.
The VERSION RELEASE MOD parameter should be omitted or specified with asterisks, as follows:
VERSION(*) RELEASE(*) MOD(*)
Table 11. FEATURENAME values for z/OS priced features, and TCP/IP
Name
FEATURENAME value
BDT File-to-File
BDTFTF
BDT SNA-NJE
BDTNJE
DFSMSdss
DFSMSDSS
DFSMShsm
DFSMSHSM
DFSMSrmm
DFSMSRMM
DFSMStvs
DFSMSTVS
DFSORT
DFSORT
GDDM-PGF
GDDM-PGF
GDDM-REXX
GDDM-REXX
HCM
HCM
HLASM
HLASM
HLASM
HLASM
Toolkit
Toolkit
Toolkit
Toolkit
Interactive Debug Facility
Disassembler
Enhanced Super-C
Cross-Reference Facility
TOOLKIT
TOOLKIT
TOOLKIT
TOOLKIT
DEBUGGER
DISASSEM
SUPERC
XREF
Infoprint Server
INFOPRINT SERVER
JES3
JES3
RMF
RMF
SDSF
SDSF
74
z/OS Planning for Installation
Notes
To specify a
FEATURENAME value that
contains a blank, either
replace the blank with an
underscore (as in
SECURITY_SERVER) or
enclose the name in single
quotation marks (as in
‘SECURITY SERVER’).
To specify a
FEATURENAME value that
contains a blank, either
replace the blank with an
underscore (as in
SECURITY_SERVER) or
enclose the name in single
quotation marks (as in
‘SECURITY SERVER’).
Table 11. FEATURENAME values for z/OS priced features, and TCP/IP (continued)
Name
FEATURENAME value
Notes
Security Server
SECURITY SERVER
To specify a
FEATURENAME value that
contains a blank, either
replace the blank with an
underscore (as in
SECURITY_SERVER) or
enclose the name in single
quotation marks (as in
‘SECURITY SERVER’).
TCP/IP (includes the components TCP/IP Base, TCP/IP TCP/IP BASE
CICS, and TCP/IP IMS)
TCP/IP CICS
TCP/IP IMS
v To specify a
FEATURENAME value
that contains a blank,
either replace the blank
with an underscore (as in
SECURITY_SERVER) or
enclose the name in
single quotation marks
(as in ‘SECURITY
SERVER’).
v You must specify
multiple PRODUCT
statements.
v If your installation
ordered the standard
z/OS base, TCP/IP is
shipped enabled.
Otherwise, it is shipped
disabled.
XL C/C++
C/C++
zEDC capability using zEDC Express
ZEDC
To specify a
FEATURENAME value that
contains a +, enclose the
name in single quotation
marks (as in ‘C/C++’).
DCF product
To enable the Document Composition Facility (DCF) product to run with z/OS, the following entry must
be in the IFAPRDxx parmlib member:
PRODUCT OWNER(’IBM CORP’)
NAME(DCF)
ID(5748-XX9)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DCF)
STATE(ENABLED)
GDDM-PGF product
To enable the GDDM-PGF product to run with z/OS, the following entry must be in the IFAPRDxx
parmlib member:
PRODUCT OWNER(’IBM CORP’)
NAME(GDDM-PGF)
ID(5668-812)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(GDDM-PGF)
STATE(ENABLED)
Chapter 5. Preparing for customization and test
75
HLASM Toolkit feature
To enable the High Level Assembler (HLASM) Toolkit feature of the HLASM product to run with z/OS,
the following entries must be in the IFAPRDxx parmlib member:
PRODUCT OWNER(’IBM CORP’)
NAME(’HI LVL ASSEMBLER’)
FEATURENAME(’TOOLKIT DEBUGGER’)
VERSION(*) RELEASE(*) MOD(*)
ID(5696-234)
STATE(ENABLED)
PRODUCT OWNER(’IBM CORP’)
NAME(’HI LVL ASSEMBLER’)
FEATURENAME(’TOOLKIT DISASSEM’)
VERSION(*) RELEASE(*) MOD(*)
ID(5696-234)
STATE(ENABLED)
PRODUCT OWNER(’IBM CORP’)
NAME(’HI LVL ASSEMBLER’)
FEATURENAME(’TOOLKIT SUPERC’)
VERSION(*) RELEASE(*) MOD(*)
ID(5696-234)
STATE(ENABLED)
PRODUCT OWNER(’IBM CORP’)
NAME(’HI LVL ASSEMBLER’)
FEATURENAME(’TOOLKIT XREF’)
VERSION(*) RELEASE(*) MOD(*)
ID(5696-234)
STATE(ENABLED)
|
|
|
|
|
|
|
|
|
|
|
IBM Print Transform from AFP products
To enable IBM Print Transform from AFP to PDF to run with z/OS, the following entries must be in the
IFAPRDxx parmlib member:
PRODUCT OWNER(’IBM CORP’)
NAME(’PRINT TRANSFORMS’)
FEATURENAME(’AFPxPDF’)
VERSION(*)
RELEASE(*)
MOD(*)
ID(5655-TF1)
STATE(ENABLED)
| To enable IBM Print Transform from AFP to PCL to run with z/OS, the following entries must be in the
| IFAPRDxx parmlib member:
| PRODUCT OWNER(’IBM CORP’)
|
NAME(’PRINT TRANSFORMS’)
|
FEATURENAME(’AFPxPCL’)
|
VERSION(*)
|
RELEASE(*)
|
MOD(*)
|
ID(5655-TF2)
|
STATE(ENABLED)
| To enable IBM Print Transform from AFP to PostScript to run with z/OS, the following entries must be in
| the IFAPRDxx parmlib member:
| PRODUCT OWNER(’IBM CORP’)
|
NAME(’PRINT TRANSFORMS’)
|
FEATURENAME(’AFPxPS’)
|
VERSION(*)
|
RELEASE(*)
|
MOD(*)
|
ID(5655-TF3)
|
STATE(ENABLED)
76
z/OS Planning for Installation
|
Print Services Facility (PSF) product
To enable the Print Services Facility (PSF) product to run with z/OS, the following entry must be in the
IFAPRDxx parmlib member:
PRODUCT OWNER(’IBM CORP’)
NAME(’PSF for z/OS’)
ID(5655-M32)
VERSION(*)
RELEASE(*)
MOD(*)
FEATURENAME(’PSF for z/OS’)
STATE(ENABLED)
To enable the PSF priced optional features to run with z/OS, the following entries must be in the
IFAPRDxx parmlib member:
PRODUCT OWNER(’IBM CORP’)
NAME (’PSF for z/OS’)
ID(5655-M32)
VERSION(*)
RELEASE(*)
MOD(*)
FEATURENAME(’Download Plus’)
STATE(ENABLED)
PRODUCT OWNER(’IBM CORP’)
NAME(’PSF for z/OS’)
ID(5655-M32)
VERSION(*)
RELEASE(*)
MOD(*)
FEATURENAME(’Download’)
STATE(ENABLED)
|
|
|
|
|
|
|
|
PRODUCT OWNER(’IBM CORP’)
NAME(’PSF for z/OS’)
ID(5655-M32)
VERSION(*)
RELEASE(*)
MOD(*)
FEATURENAME(’ACIF’)
STATE(ENABLED)
Dynamic enablement Step 3: Establish the active parmlib member
To dynamically activate the updated enablement policy without an IPL, place the updated PRODUCT
statements in the appropriate IFAPRDxx member of the active SYS1.PARMLIB data set. You can then
issue the SET PROD operator command to specify the IFAPRDxx member that defines the enablement
policy. See z/OS MVS System Commands for more information.
The enablement policy change takes place immediately but does not affect any instances of features,
products, or TCP/IP that are already executing. Also, activating a new enablement policy does not start
any of the enabled features, products, or TCP/IP. They will only run when explicitly started by some
other action, such as a START command.
Be sure to change the PROD system parameter in IEASYSxx to point to the appropriate IFAPRDxx
member; no IFAPRDxx member is activated by default. This change ensures that the next IPL activates
the correct policy. For more information about using IFAPRDxx, see z/OS MVS Initialization and Tuning
Reference.
Disabling what was enabled
If after you use an enabled feature, product, or TCP/IP, you want to discontinue its use, you must disable
it. Use the IFAPRDxx member to define the policy change and enter the SET PROD command to activate
the changed policy.
Chapter 5. Preparing for customization and test
77
Because disabling the feature, product, or TCP/IP in the enablement policy does not stop it from running,
you might have to explicitly stop it. For example, you might have to take the following actions:
v Enter a command that is provided by the feature, product, or TCP/IP.
v Enter the MVS MODIFY or MVS STOP command.
Or, you might decide that the least disruptive way to stop a long-running feature, product, or TCP/IP is
to IPL the system without it.
After you disable a feature, product, or TCP/IP, ask your asset manager to contact your IBM
representative to alert IBM that you are discontinuing its use on a specific processor. See the Usage
Restriction section of z/OS Licensed Program Specifications for more license terms and conditions.
Scheduling test activities
IPL the new release in a production environment after you have tested the new release with a simulated
production workload that includes all applications and all non-IBM products, and that ensures that
service level agreements can be met.
IPL in a shared resource environment after you have installed any coexistence PTFs.
If your production workload will require greater than 2 GB of real storage, be sure to use greater than 2
GB on your test image. In fact, the more storage you use above the 2 GB line on your test image, the
greater the chance that pages will be backed up there, and the greater the odds of exposing problems
during test rather than during production.
Perform function and stress test. Testing by IBM does not replace the need for this testing in your own
environment. Testing might include:
v Initializing the system
v Initializing JES2 or JES3
v Logging on to TSO/E
v Running the IVPs
v Submitting a job
v Checking the job's output
v Starting customization of z/OS
v If CICS or IMS is installed, initializing a region and signing on to a terminal
v Bringing your ISV products into the test environment
v Running critical production jobs
v Supporting a representative interactive workload
v Communicating with all networks
v Testing critical functions in applications
v Checking some of the paths not often taken
v Checking for completeness of accounting records
v Testing all non-IBM product functions
v Bringing your applications into the test environment
v Ensuring that performance goals stated in service level agreements can be met.
Do not complicate your testing by exploiting the new function that z/OS provides. Save that task until
after you are successfully running in production.
You should have a fallback (backout) plan in case problems occur during testing and you have to fall
back to your previous level.
78
z/OS Planning for Installation
Chapter 6. Preparing for future installations
When you build a z/OS system, you must balance the needs of your installation to build a system that
meets its needs well. While this will sometimes mean compromise, it more often means finding ways to
build a flexible system that is easy to install, easy to migrate, easy to extend, and easy to change. z/OS
provides tremendous flexibility in installation and customization. When applied using a well-planned
structure, this flexibility can minimize the time it takes to install and migrate new systems or new
software levels throughout an installation.
Adopting a well-planned structure for your installation provides the foundation for controlling workload
during future installations and migrations. Depending on how your system is structured today, doing this
can be very easy, requiring little investment, or quite difficult, requiring many system programming
hours. However, the long-term benefits of a well-planned structure are quite clear.
This topic helps you prepare for future installations. Many of the techniques discussed in this topic, if
you are not using them today, could take considerable time to implement. It can be difficult or even
impossible to attempt to do all these things during a single build and migration cycle, for any number of
reasons.
A phased approach will often prove most feasible and can begin to control the installation and migration
workload in the least time. This provides you benefits, starting with the next installation and migration
cycle, while controlling the work involved in implementation. As you implement each technique, more
time to implement the remainder should be available during future system builds and migrations.
Note: Some of the SystemPac-related techniques discussed in this topic are applicable only to SystemPac
dump-by-data-set format. SystemPac full volume dump format employs a very different philosophy,
requiring far fewer actions on your part.
System and installation requirements
Creating an installation plan helps you make sure the software you install is able to meet your
installation's requirements for software function. However, software function alone will not meet all the
needs of your business, and there are other things you should consider when planning to build a system,
such as:
v Achieving efficient virtual storage mapping
v Achieving best application performance
v Building a minimum number of system software configurations
v Reducing installation and migration time
v Reducing the opportunities for error during migration
v Making it easy to manage the system after it is in production
v Minimizing migration actions for the people who use the system.
How you choose to meet all of these requirements can have a significant effect on how much work is
required to perform the tasks associated with each stage. Keep these requirements in mind while reading
this topic.
© Copyright IBM Corp. 2002, 2017
79
Separating data from software
When you separate your data from your system software, you eliminate many tasks that must be
performed each time you upgrade or replace your system software. An effective way to separate data
from software is to use different DASD volumes for each.
You can minimize your installation and migration workload if you try to satisfy these objectives:
v All system software volumes for the same product set at the same product and service levels must be
identical.
v All differentiation between systems must happen during or after IPL.
v Only system software (and SMP/E data pertaining to it) should reside on system software volumes.
If you have not previously used a system replacement method to install software, you might find that it
makes the installation considerably easier. Most of the work involves separating the following data from
z/OS software:
v Customization data, including most system control files
v Non-IBM software
v IBM products that run on z/OS
v User exits
v User data.
Your goal is to make it easier to replace the volumes that contain z/OS software, which are supplied by
ServerPac or SystemPac (dump-by-data-set format). This allows you to more easily keep the other
software and data you need to use with z/OS across migrations.
What to do with the non-ServerPac or non-SystemPac code
1. Ask if the code is still required. If not, do not carry it forward; if so, go to the next step.
2. Determine the usefulness and effectiveness of this code:
v Does it need to be updated for the new function in z/OS? If it does, you might need to upgrade a
product or change the code.
3. If this code can be separated from the code delivered with ServerPac or SystemPac, place it in another
product set. The product set must be placed on another volume so that future ServerPac or SystemPac
installations will not overlay it. This requires moving it into separate libraries and SMP/E zones.
4. If the code cannot be separated from the code delivered with ServerPac or SystemPac, then it must be
reinstalled in the same zones and libraries delivered with ServerPac or SystemPac. One way to do this
is with the SMP/E BUILDMCS command.
5. Enable the useful and effective code to work with z/OS. This might mean using concatenation,
reinstalling the code, or possibly reassembling it.
As you face the task of where to place the various types of code in your installation and enabling the
code to work with z/OS, keep in mind the following advice:
v Use SMP/E to install all modules you use with the operating system; place comments in each module
that identify its function.
v Where possible, use IBM-supplied exit points to control the system rather than changing the source or
object code.
v Where possible, use the dynamic exits service. This service allows you to refresh exits without losing
availability. For information about the dynamic exits service, see z/OS MVS Installation Exits.
v Where possible, place your exit code in libraries placed on different volumes from IBM code. This
allows compatible exits to stay in place when you start to use a new level of the operating system, and
reduces migration time.
80
z/OS Planning for Installation
The following list includes the different kinds of code found in an installation, and describes actions that
ensure that the code you want to use with z/OS survives the installation process and is enabled to run
with z/OS. The list includes the ways you insert customer-written code into an operating system
environment or change the operating system code:
v IBM products that run on z/OS: This category includes the following:
– Products that are no longer marketed. Such products are not available through ServerPac. To avoid
having to reinstall these products every time you reinstall a z/OS ServerPac order, place these
products, if possible, in separate product sets with separate libraries or SMP/E zones.
Note: SMP/E provides the BUILDMCS command to copy a product from one zone to another. Use
BUILDMCS to either (1) move the product to new (target and DLIB) zones, if the product is not
available in ServerPac and if it can be installed in a separate zone, or (2) create an installable copy of
the product with its service already integrated so that it can be reinstalled in the new zones shipped
with ServerPac, which can be faster than reinstalling the product and its service from scratch. This
use of BUILDMCS applies to vendor products and to IBM products that are still in service but have
been withdrawn from marketing. For the information you need to use the BUILDMCS command
and restrictions on its use, see SMP/E for z/OS Commands.
Products that are no longer marketed but are still service supported are available for selection in the
SystemPac shopping list. Where appropriate, when you order a SystemPac, have these products
separated into their own SMP/E zone or volume using the local order entry tool.
– Available MVS SREL products, such as PSF or NetView®. You can order these products in the same
ServerPac or SystemPac as z/OS.
– Non-MVS SREL products, such as the subsystems (DB2, CICS, IMS, and WebSphere Application
Server). Check to make sure that these products do not need to be upgraded to run with z/OS by
doing the following:
- Do cross-zone requisite checking.
For ServerPac, run the SMPREP job or the REPORT CROSSZONE command.
For CBPDO, do cross-zone requisite checking during APPLY processing, as described in z/OS
Program Directory in the z/OS Internet library (www.ibm.com/systems/z/os/zos/library/
bkserv). If you did not perform cross-zone requisite checking, run the REPORT CROSSZONE
command.
For information about the REPORT CROSSZONE command, see SMP/E for z/OS Commands. For
information about the SMPREP job, see ServerPac: Installing Your Order.
- Check the cross-product dependencies section of the applicable PSP buckets.
If you need to upgrade a non-MVS SREL product, order it in a separate ServerPac or use SystemPac.
SystemPac provides the option of integrated subsystems. The package you order can include z/OS
and no more than one of the subsystems (DB2, CICS, IMS, or WebSphere Application Server). The
deliverable is shipped to you integrated and requires just one installation, by way of either the
CustomPac Installation Dialog or a full volume restore.
Should you choose to order subsystems with z/OS in one single SystemPac order, separate your
subsystems from the z/OS SREL products to gain maximum flexibility in the future. The local order
entry tool enables you to do so.
v User modifications: This category includes:
– User exits
– Updates to source code
– Zaps
– Changes to ISPF elements, such as panels, CLISTs, and EXECs.
Isolate this code from the IBM code when possible by:
– Placing it in a separate library that can be concatenated ahead of the IBM libraries
– Using the dynamic exits service and placing the code in separate libraries.
Chapter 6. Preparing for future installations
81
One simple way to tell whether user modifications must be reworked for the new level of software is
to try to reapply them and see how many of them SMP/E will install. Those that SMP/E will not
install will need to be changed for the new level of software. This method works if you have followed
the IBM advice about using SMP/E to install the code.
If your user modifications have been installed using SMP/E, you can get the list of user modifications
you now have installed by running a LIST SYSMODS USERMODS command against each of your
existing target zones. You will need to evaluate each user modification to determine whether it is still
needed and whether it needs to be reworked to be reinstalled.
To save time, you can run SMP/E REPORT SYSMODS commands, specifying each existing target zone
on the INZONE keyword and each corresponding new target zone on the COMPAREDTO keyword.
(The ServerPac SMPREP job includes a REPORT SYSMODS.) SMP/E will create SYSMODS
Comparison Reports that identify user modifications that are installed in the old zones and are
applicable to FMIDs in the new zone. It will also create a job in the SMPPUNCH data set to reinstall
them (and any applicable PTF and APAR SYSMODs) in the new ServerPac or SystemPac system's
target zone.
Some of your user modifications might be listed by the LIST commands but not included in the
SYSMODS Comparison Reports. These user modifications apply to FMIDs that are not installed on
your new system. Some FMIDs might have been replaced by others, in which case you will have to
rework applicable user modifications before reinstalling them. The others might have no replacements
and their user modifications are almost certainly no longer needed.
For FMIDs that have changed, evaluate the usermods and rework them, if necessary.
Keep the source for all user modifications in a single data set, and document each modification. Such
documentation often includes:
– The name of the part (for example the module) affected by the usermod
– The business justification for the usermod
– When the usermod can be eliminated
– The purpose of the usermod
– Instructions for reworking or reinstalling the usermod
– The product and current FMID to which the usermod is applied.
Some actions not only make a ServerPac or SystemPac (dump by data set format) installation easier, but
can also organize code and data so that other tasks are easier. Here are some recommended actions:
v SYSRES: Some SYSRES volumes are not large enough to hold all the z/OS target libraries. If you have
such a volume you can move some of the data sets off SYSRES. For help in determining which ones to
move, see “Recommended data set placement” on page 85.
v Parmlib and proclib:
– Do not make changes to the parmlib and proclib data sets that you use for production until you
have seen what IBM sends in the copies that IBM ships with z/OS. Compare the IBM copy to your
production copy or use the IBM library in your production concatenation and decide which of IBM's
parmlib and proclib specifications apply to your environment and manually make the changes.
Copy any new parmlib and proclib members into your production copy. Then, tailor your
production copy, as needs require.
– In a multisystem environment, try to have SYSRES, master catalog, and system-type libraries (such
as IODF, SYS1.DAE, and RACF data) common to as many systems as is practical. Use symbolic
substitution to reduce the number of parmlib and proclib members that are unique to specific
systems.
Using symbols in parmlib members makes it easier to share a parmlib member across multiple
systems. z/OS provides a tool that helps you to verify that your system symbolics work successfully
in your own configuration before you put the parmlib member into production. This tool, called the
parmlib symbolic preprocessor, runs as an ISPF dialog to interactively display the results of symbol
82
z/OS Planning for Installation
substitution before you IPL the system and use the symbols. You can find the tool in members
SPPINST and SPPPACK in SYS1.SAMPLIB. Information about setting up and using the tool appears
in the prolog of the SPPINST member.
Use parmlib concatenation to separate your tailored parmlib members from the IBM-supplied parmlib
members. See information about parmlib concatenation in the description of the LOADxx parmlib
member in z/OS MVS Initialization and Tuning Reference.
Placing data sets on specific volumes
With the ability to define very large volume sizes on certain hardware, it is possible that all your target
and DLIB libraries could fit on a single volume. If possible, use a large enough volume for your target
libraries so that you will not need multiple SYSRES logical extension volumes. However, some SYSRES
volume types, such as the 3390-3, are not big enough to hold all the target libraries for a z/OS system,
with the result that you have to move some data sets to SYSRES logical extension volumes (overflow
volumes). This section describes considerations for placing data sets on specific volumes. These
considerations try to minimize your migration actions, taking into account:
v Your ability to use a system (or subsystem) replacement
v Data set and system availability
v System performance
v System cloning and servicing techniques
v Sysplex/multisystem operations
v Your ability to exploit new technologies
v Sharing of data sets
v Backup and recovery
v Disaster recovery.
Using the guidelines in this section, you will have to determine which data set placements work best in
your environment, probably making trade-offs in order to achieve your business goals.
Product sets
Introducing product sets
A product set is a set of products that you should install, maintain, and migrate as a group. Everyone has
at least one product set that includes z/OS. The judicious grouping of your other system software
products into product sets can help you avoid reinstalling software you have already installed, give you
greater flexibility during migrations, control the amount of DASD used for system software, and make it
easier to have different groups maintain different sets of products.
Well-chosen product sets let you treat most system software in a logical, modular way. When different
images have different sets of requirements, you can use product sets as modular building blocks to make
the entire needed set of software available on each image. Specific recommendations for placement of
each product set's data sets are discussed in “Recommended data set placement” on page 85.
Characteristics of a product set
A product set is a group of products that is logically separate from any other group of products. Each
product set is an entity that can be installed, maintained, and migrated by itself. Each product set has its
own data sets, typically on separate DASD volumes, and its own SMP/E target and DLIB zones. Which
products you should place in each product set depends on how you plan to install, maintain, and use
software from different vendors.
When planning the number and content of product sets to be used in your installation, consider:
v Software installation requirements.
Chapter 6. Preparing for future installations
83
Some products must be installed in data sets and SMP/E zones shared with other products in order to
work. Such products cannot be considered as candidates for placement in different product sets.
However, the remaining products are potential candidates.
v Migration cycles.
Do you install and migrate all your software products at the same time (for example, once a year)? Or
do you install and migrate groups of products separately? Software often installed or migrated
separately includes subsystems, software from vendors, and application software.
Any software installed or migrated on a cycle different from other software is itself a candidate
product set.
v Organizational requirements.
Does a single person or group of people do all software installations and migrations? Or do different
people maintain different products? Note that some installations that once had separate organizations
install and maintain different product sets now have one group install all of them and others make the
software operational (including customization). This lets them include more products in each product
set and reduce the number of product sets.
Examples of software often maintained by different groups include application development software
(such as compilers and debuggers), database products (such as IMS Database Manager and DB2), and
transaction processing products (such as CICS and IMS Transaction Manager).
Software products maintained by different groups are sometimes candidates for inclusion in separate
product sets.
v Sharing boundaries.
Software can often be shared among multiple system images. There are many considerations for
sharing system software, and more information about this can be found in Parallel Sysplex - Managing
Software for Availability, SG24-5451. The boundaries on which you choose to share different products can
vary, depending on which products are being used.
When some products are shared among some sets of images and other products are shared among
different sets of images, they are candidates for inclusion in different product sets.
Note: You should generally not separate products to control access to them on different images for
licensing reasons, unless the terms and conditions of your licensing agreements require you to do so.
Most often, access to particular programs is better controlled using your security product.
v Product availability.
Some of the products you use might no longer be available from a particular software vendor. They
might originally have been placed in product sets with other products. Depending on how the product
is installed, it might become a candidate for inclusion in a product set separate from the vendor's other
products. Moving these products to separate product sets can sometimes let you avoid reinstalling
them each time you rebuild the product sets in which they were originally placed.
Which product sets are appropriate?
One or more product sets, as described in this topic, will be appropriate for your installation. Any of
these product sets can be merged with any other, as required by your business needs. (The result of
merging two product sets is considered to be a single product set.) Any product set described in this
topic can also be split into two or more product sets, if this is what is needed to meet your installation's
requirements. Product sets can be built at the same time or different times, and migrated together or
separately to different images as your business requires.
Each installation's requirements usually lead to a unique number of product sets and to unique content in
each set. Remember that your objective in choosing the number and composition of product sets is to
control workload while providing the amount of flexibility you need to manage your software easily. If
you have either too many or too few product sets, you will do more work during some phase of
installation or migration, and your system software will be harder to manage.
84
z/OS Planning for Installation
Product set for z/OS and closely-related products: The z/OS product set consists of all z/OS elements
and features and other products that either must be installed with z/OS, or that you choose to install
with z/OS. Some products must be installed with z/OS because they share load modules with z/OS load
modules. Others can be installed separately but are difficult to maintain separately because of frequent
service dependencies or local installation policies. Products in these two categories should always be part
of the z/OS product set.
Note: Remember to add products to the z/OS product set that install into data sets that cannot be
concatenated, such as SYS1.NUCLEUS.
Other products within the MVS SREL need not be installed with z/OS and are not difficult to maintain
separately. However, unless your installation has a reason to place them in a separate product set, you
should consider including them in the z/OS product set.
Subsystem product sets: Subsystem software includes database software, transaction processing
software, and some network software. This software is often installed using different installation
methods, is usually migrated on different cycles, is usually shared on different boundaries, and is often
maintained by different groups. These products are usually good candidates for different product sets.
Licensed product sets: If your migration cycles, organizational requirements, and sharing of boundaries
make it appropriate, you should consider creating a separate product set for some products. Generally,
such products should be reasonably stable and easy to install, maintain, and migrate separately. Examples
of such products include compilers, automation products, and products that can no longer be ordered.
Vendor product sets: You should consider creating one or more product sets for each vendor's products.
Recommended data set placement
Data set placement recommendations are not mandatory. The use of any or all of this layout is strictly
optional. The recommended layout provides a good foundation for many recent functional and system
management enhancements (such as sharing a master catalog, indirect volume serial support, z/OS
UNIX, and Parallel Sysplex). It can be used to suggest how you might place data sets or as a set of
objectives to which you can evolve.
To help you decide whether to follow the recommendations, ask yourself the following questions.
Positive answers indicate that at least some of the recommended actions would be beneficial to you.
v Will you require additional SYSRES logical extension volumes? Some SYSRES volume types, such as
the 3390-3, are not big enough to hold all the z/OS target libraries. Therefore, you might have to move
some data sets to SYSRES logical extension volumes.
Note: Several data sets shipped with z/OS are PDSEs. These data sets are CBC.SCCNCMP,
CBC.SCLBDLL2, CEE.SCEEBIND, CEE.SCEERUN2, SYS1.NFSLIBE, SYS1.SHASLNKE,
SYS1.SIEALNKE, SYS1.SIEAMIGE, and TCPIP.SEZALOAD. One or more are most likely in your link
list or will be added to your link list as part of installation. If one or more are in your link list and on
your SYSRES volume, you should not share the SYSRES volume beyond the scope of a sysplex because
PDSE sharing between sysplexes is not supported. If a PDSE is shared between sysplexes, data could
become corrupted.
v Do you plan to use indirect volume serial support? If so, the recommended layout fits nicely with this
support. See “Using indirect catalog entries” on page 98 for more information.
v Do you plan to use ServerPac or SystemPac (dump-by-data-set format) for future installations?
ServerPac replaces at least your target and distribution libraries, so using the layout recommended in
this section makes it easier to lay down the ServerPac or SystemPac (dump-by-data-set format)
libraries.
v Do you plan to share master catalogs? The recommended layout provides a good foundation if you do.
Chapter 6. Preparing for future installations
85
v Do you plan to move your volumes across systems? If so, the recommended placement of user catalogs
creates more-portable volumes and reduces migration workload. Also, the master catalog alias
resolution support in DFSMSdfp allows system symbols to be used for the user catalog name. See z/OS
DFSMS Managing Catalogs for details.
Based on these factors, you should determine which data sets to place on each volume based on data set
type, not based on element, feature, or product. There are five types of data sets in the recommended
data set layout. Each type is placed on a separate (logical) volume. The types of data sets and their
volumes are:
v SMP/E global-shared data sets, on a volume shared by all systems in the complex that need access to
SMP/E global information. See “SMP/E global data sets” on page 87 for details.
v Target libraries (TLIBs) for product sets, on the following volumes:
– TLIB volume 1 (TVOL1)
– TLIB volume 2 (TVOL2) through TLIB volume n (TVOLn)
– HFS or zFS target volume
– Licensed product set volume (for those licensed programs not installed with the z/OS product set)
– Vendor product set target volume
– Subsystem product set target volume
See “Target libraries (TLIBs)” on page 87 for details.
v Distribution libraries (DLIBs) for product sets, on the following volumes:
– DLIB volumes for target volumes (which include TVOL1, TVOL2-n, HFS, and zFS)
– DLIB volume for the licensed product sets
– DLIB volume for the vendor product sets
– DLIB volumes for the subsystem product sets
See “Distribution libraries (DLIBs)” on page 91 for details.
v Image-related data sets, on the following volumes:
– Page data sets volume 1
– Page data sets volume 2 through n
– HFS or zFS customization volume
See “Image-related data sets” on page 92 for details.
v Cluster-related data sets, on the following volumes:
– Master catalog volume (you can also choose to make this an image-related volume)
– JES checkpoint volume
– JES spool volume
– Sysplex volume 1
– Sysplex volume 2
– Softcopy volumes
See “Cluster-related data sets” on page 93 for details.
Many volumes on your system will contain data sets that are not supplied by ServerPac or SystemPac
(dump-by-data-set format). Keeping such volumes separate from those that ServerPac or SystemPac
(dump-by-data-set format) will replace, or that you will replace when migrating the new system to other
system images, makes it easier to prevent overlaying data sets that you want to keep. Volumes that
contain non-ServerPac or non-SystemPac data sets might include, but are not limited to, the identified
volumes in the data set descriptions, as well as volumes for assorted data sets (dumps that were
dynamically taken, logger log streams, and so forth). Note that you can install your ServerPac or
SystemPac (dump-by-data-set) order on volumes with existing data sets. See “Preparing for installation”
on page 50 for the steps to follow when your target volumes contain data that you want to preserve.
86
z/OS Planning for Installation
The rest of this topic contains details about the five types of described data sets and volumes. As you
read, keep the following in mind:
v Volumes can be combined in order to conserve DASD. Combine volumes based on like characteristics.
For example, consolidating two SMS-managed volumes with the same SMS constructs (Storage Class,
Management Class and in the same Storage Group) is more appropriate than consolidating a
non-SMS-managed volume and an SMS-managed volume.
v Although ServerPac and SystemPac (dump-by-data-set format) considerations are mentioned
specifically, this recommended system layout is equally applicable to CBPDO users and will save time
when the new system is migrated to other images.
SMP/E global data sets
These data sets contain SMP/E global system information. For the sake of organization, and ease of
backup and recovery, it is a good idea to keep them together on a volume shared by all systems that use
SMP/E in your complex. If you maintain multiple global zones for subsystems or vendors, the global
zone described here should contain ZONEINDEX references to all other zones. This will assist you in
cross-zone conditional requisite checking without requiring any changes to your installation's
maintenance procedures.
The recommended types of data sets for this volume are:
v SMP/E global CSI
v SMPPTS (this data set alone might fill a volume)
v SMP/E global logs (SMPLOG/A)
Target libraries (TLIBs)
These data sets are SMP/E target libraries for products sets mentioned in “Which product sets are
appropriate?” on page 84.
If you want to take advantage of indirect volume serial support, do not SMS-manage the target data sets
that reside on volumes TVOL1 through TVOLn.
TVOL1 through TVOLn may be shared with other systems (for IPCS or WLM migrations, for example). If
TVOL1 does not contain enough space to hold all the data sets listed for your system, then the criterion
for a split (between TVOL1A and TVOL1B, for instance) would be that the IPCS and change migration
libraries should be kept together on the first volume (TVOL1A).
If you support more than one language and are short of space on TVOL1, you might choose to put your
primary language on TVOL1A and your secondary languages on TVOL1B. An additional criterion for a
TVOL1A and TVOL1B split is to keep together those data sets that are less critical to the system and that
do not affect existing catalog structures (for instance, data sets that are new to z/OS and are not critical
to system usage).
When you install using ServerPac or dump-by-data set SystemPac, you should take advantage of the
Recommended System Layout enhancement. This function takes into consideration the volume space
available and the data set sizes in your order, and places the data sets accordingly. If you are a CBPDO
customer, you might have to calculate available space for the data set types on target volumes to ensure
that it is sufficient. Depending on the volume type, you might have to add another target volume.
TVOL1 through TVOLn contain the z/OS product set target libraries, except for HFS and zFS files.
TLIB volume 1 (TVOL1): TVOL1 is the first target library volume and the system residence (IPL)
volume. It contains many of the z/OS target libraries. Be sure to leave enough free space to allow for
future growth. TVOL1 allows you to IPL if one or more TVOL2 through TVOLn volumes are temporarily
not available.
Chapter 6. Preparing for future installations
87
TVOL1 contains some or all of the non-z/OS-UNIX target libraries for the z/OS product set. (See
“Product set for z/OS and closely-related products” on page 85 for more information on the z/OS
product sets.) This does not include the licensed product set, which you install separate from z/OS (on
licensed program volumes), or the subsystem product set (on the subsystem target volumes).
The recommended types of TVOL1 data sets are as follows. Note that the type of a data set is known
within the Recommended System Layout function in ServerPac and dump-by-data set SystemPac. The
data set type can also be found within the product's program directory.
v Load libraries.
v Change migration libraries. These libraries are used, or might be used, during migration from one
level of software to another.
v Help libraries.
v Panel libraries.
v Message libraries.
v Skeleton libraries.
v Table libraries.
v Fixed-block CLIST and EXEC libraries (if possible). If you do not use fixed-block CLIST and EXEC
data sets, then TVOL1 should contain your variable-block CLISTs and EXECs and TVOL2 would
contain your fixed-block CLISTs and EXECs. (In other words, put the kind of CLISTs and EXECs you
use on TVOL1.)
v Data libraries. Some data libraries should go on TVOL2.
v SMP/E managed PARMLIB. This data set is the one pointed to by the PARMLIB DDDEF, which will
be used to store parmlib members supplied by products you install. If you copy the SMP/E-managed
PARMLIB data set into your own system control data set, then the SMP/E-managed parmlib should be
placed on TVOL2-n. The placement of this PARMLIB data set makes it easier to use concatenated
PARMLIB support to reduce migration workload.
v SMP/E managed PROCLIB. This data set is the one pointed to by the PROCLIB DDDEF, which will be
used to store JCL procedures supplied by products you install. If you copy the SMP/E-managed
PROCLIB data set into your own procedure library, then the SMP/E-managed PROCLIB data set
should be placed on TVOL2-n. The placement of this PROCLIB data set makes it easier to use
concatenated PROCLIB support to reduce migration workload.
Reasons to put these data sets on TVOL1 are:
v These data sets are critical to basic system function and are required for recovery. Should some TVOLn
volumes be lost or become inaccessible, the system is less likely to fail if the most critical data sets are
all on a single volume. Also, in the event that all TVOLn volumes are lost or become inaccessible, the
ability to IPL, log on, and use basic system functions after recovering TVOL1 can speed the recovery of
other volumes and greatly simplify the process of restoring full function. (For example, restoring
additional volumes from backup tapes can be done in parallel, using cataloged tape data set names.)
v Although it is technically possible to SMS-manage these data sets, it is still recommended to not have
these volumes under SMS management. SMS volumes and data sets and volumes might not be
accessible during recovery situations (for example, ISPF edit). By extension, any data set required for
IPL is not recommended for SMS management.
v These data sets will be overlaid by a system replacement. By keeping them together, you can more
easily separate what will and will not be overlaid.
v The SMP/E DDDEFed PARMLIB and PROCLIB are on TVOL1 so that TVOL1 can be IPLed in a
minimum setup (without TVOL2 through TVOLn) and still have the SMP/E-installed defaults
available. The members stored by SMP/E in the PARMLIB pointed to by the PARMLIB DDDEF, and
those stored in the PROCLIB pointed to by the PROCLIB DDDEF, are not sufficient to IPL by
themselves; a minimum set of system control parameters and JCL procedures are required to IPL and
use the system. You can either concatenate your own PARMLIB and PROCLIB data sets to these data
sets (which is preferred) or add your own members to these data sets.
88
z/OS Planning for Installation
TLIB volume 2 (TVOL2) through TLIB volume n (TVOLn): TVOL2 through TVOLn are volumes used
for data sets that do not fit on TVOL1. They are for the z/OS product set; see “Product set for z/OS and
closely-related products” on page 85 for more information about the z/OS product set. Products you
want to install separately should be placed instead on licensed program volumes or subsystem volumes.
The recommended types of TVOL2 through TVOLn data sets are described as follows. Note that the type
of a data set is known within the Recommended System Layout function in ServerPac and dump-by-data
set SystemPac. The data set type can also be found within the product's program directory.
v Fixed-block CLIST and EXEC libraries (only if variable-block CLIST and EXEC libraries were used on
TVOL1).
v Sample and JCL libraries.
v Source libraries.
v Macro libraries.
v Workstation libraries (which are combined in the data libraries).
v Softcopy libraries into which SMP/E installs.
v Font and printing libraries.
v Text libraries.
v Flat files that SMP/E cannot manage (interface repositories and so forth, excluding documents).
v MMS-compiled and MMS-source data sets. MMS-source data sets are those data sets that are used as
input into the MMS compiler.
v SMP/E target CSI.
v SMP/E target data sets: SMPLTS, SMPMTS, SMPSTS, SMPSCDS.
v User catalog for the SMP/E target CSI and MMS-compiled data sets.
If you find that just one volume (TVOL2) is not enough, and you require other volumes (TVOL3 for
instance), you could place groups of data sets (rather than individual data sets) on one volume or the
other. Some examples of groupings are:
v Operational data sets, such as flat files, font and printing libraries, MMS-compiled libraries, and user
catalogs.
v VSAM data sets, such as the target CSI, MMS-compiled clusters, and user catalog.
v SMP/E work data sets, such as SMPLTS, SMPSCDS, SMPMTS, and SMPSTS.
Remember that these data sets are replaced by a subsequent ServerPac or SystemPac (dump-by-data-set
format) installation and associated customization.
HFS or zFS target volume: This is a user-maintained volume and may be SMS-managed. This volume is
not overlaid when unloading the ServerPac or SystemPac (dump-by-data-set format) HFS or zFS data
sets. However, the data in the z/OS UNIX file system will be overwritten by the installation of service or
the installation of z/OS with CBPDO. Therefore, you must ensure that you have a copy of your z/OS
UNIX file system before you install into it. See z/OS UNIX System Services Planning for more information
about installing service into the z/OS UNIX file system.
The recommended types of data sets (file systems) for the HFS or zFS target volume are:
v HFS or zFS data sets for z/OS elements or features that install into a z/OS UNIX file system
v HFS or zFS data sets for products that run on z/OS, except data sets containing customization data
(which would be on the HFS or zFS customization volume)
v User-defined HFS or zFS data sets (the CustomPac Installation Dialog allows user-defined data sets to
be defined as HFS or zFS)
v User catalog for HFS or zFS data sets on this volume if the volume is SMS-managed
Chapter 6. Preparing for future installations
89
You can combine the HFS or zFS target volume and your TVOL2-n volumes if you wish. You might want
to combine them if the products they share are migrated on the same boundary and there is enough
space on the TVOL2-n volumes for the HFS or zFS data sets.
Licensed product target volume: The libraries on this volume consist of the licensed product set that
you might not have in a system-replacement order and you want to keep separate. The data sets on this
volume are not overlaid by a system replacement and the content is decided on by the user. There can be
any number of this type of volume on a system.
The recommended types of data sets for this volume are:
v Licensed program target libraries
v SMP/E target CSI
v SMP/E target data sets: SMPLTS, SMPMTS, SMPSTS, SMPSCDS
v User catalog. The SMP/E target CSI should be defined using this catalog. Except for any data sets you
choose to catalog in the master catalog, all the licensed program target libraries should also be
cataloged in this user catalog, and ALIAS entries should be defined in the master catalog to relate their
high-level qualifiers to this user catalog.
Reasons to put these data sets on this volume are:
v To keep data sets that cannot be system-replaced (no longer marketed by IBM, older product levels,
and so forth) on volumes other than TVOL1-TVOLn, so they are not overlaid by a system replacement.
v To keep together licensed programs that have dependencies on each other.
v To facilitate data set sharing between systems and maintain data sets in one place.
Vendor product target volume: The libraries on this volume consist of the vendor product set that you
might not have in a system-replacement order and you want to keep separate. There can be any number
of this type of volume on a system.
The recommended types of data sets for this volume are:
v Vendor target libraries (that can be separated)
v SMP/E target CSI
v SMP/E target data sets: SMPLTS, SMPMTS, SMPSTS, SMPSCDS
v User catalog for the SMP/E target CSI. Unless a data set must be in the master catalog, all the vendor
product target libraries should be cataloged in the user catalog.
The reason to put these data sets on this volume is to keep the data sets off volumes that are overlaid by
a system replacement.
You will need to contact your vendors to determine whether their products need to be updated for each
z/OS release and whether the updates can be made ahead of time. To access the vendor's information
through the Web, see ISVs and IBM z Systems (www.ibm.com/systems/z/solutions/isv).
Subsystem target volume: The libraries on this volume consist of the subsystem product sets (CICS,
DB2, IMS or WebSphere Application Server). There can be any number of this type of volume on a
system.
The recommended types of data sets for this volume are:
v Subsystem target libraries.
v Alternate subsystem SMP/E global CSI, if applicable.
v SMP/E target CSI
v SMP/E target data sets: SMPLTS, SMPMTS, SMPSTS, SMPSCDS
90
z/OS Planning for Installation
v User catalog for the SMP/E global and target CSIs. Unless a data set must be in the master catalog, all
the subsystem target libraries should be cataloged in the user catalog.
Reasons to put these data sets on this volume are:
v To keep these data sets off volumes that are overlaid by a system replacement.
v To keep the subsystem together on the same volume.
v To facilitate data set sharing between systems and maintain data sets in one place.
A subsystem product set might need to be serviced before it can be used with a new z/OS system.
However, service updates usually can be made before the z/OS migration.
Distribution libraries (DLIBs)
You should place data sets on the DLIB volumes wherever they fit. There need not be a correlation
between TVOL1 and the DLIB volume for TVOL1, or between TVOL2 and the DLIB volume for TVOL2,
and so forth. It is possible, but not necessary, to SMS-manage the data sets.
Keep in mind how other systems will use the distribution libraries when you are deciding where to place
them. There might be cases where you do not want or need a set of distribution libraries available on
certain packs. These cases include:
v Distributing software to sites that do not use SMP/E or need the distribution libraries
v Having multiple target zones connected to a DLIB zone.
When allocating the distribution libraries you might have to use more than one DLIB volume. For an
estimate of how much space the distribution libraries in z/OS will use, see the topic about total DASD
storage requirements in z/OS Program Directory in the z/OS Internet library (www.ibm.com/systems/z/
os/zos/library/bkserv).
If space allows, any of the following DLIB volumes can be combined with their corresponding target
volumes: DLIB volume for licensed products, DLIB volume for vendor products, and DLIB volume for
subsystems.
If you choose to catalog your distribution library data sets, you should catalog them in the user catalog
used for the DLIB zone CSI. This makes it easier to move the DLIB volumes into other environments, to
switch between different levels of DLIB volumes, and to have more than one level available at a time. It
also reduces the amount of update activity required for the master catalog.
DLIB volumes for TVOL1, TVOL2 through TVOLn, HFS, and zFS: These distribution libraries are the
ones that are replaced by ServerPac or SystemPac (dump-by-data-set format) for your z/OS product set:
v DLIBs for TVOL1, TVOL2 through TVOLn, and TVOLH
The DLIB CSI should be placed on one of the DLIB volumes, along with a user catalog for the DLIB CSI.
DLIB volume for licensed products: These are the distribution libraries that correspond to the target
libraries for TVOLP (the licensed product set):
v DLIBs for TVOLP
v SMP/E DLIB CSI
v User catalog for the SMP/E DLIB CSI
DLIB volume for vendor products: These are the distribution libraries that correspond to the target
libraries for TVOLV (the vendor product set):
v DLIBs for TVOLV
v SMP/E DLIB CSI
v User catalog for the SMP/E DLIB CSI
Chapter 6. Preparing for future installations
91
DLIB volumes for subsystems: These distribution libraries are the ones that will be replaced by
ServerPac or SystemPac (dump-by-data-set format) for a subsystem product set:
v DLIBs for TVOLS
v SMP/E DLIB CSI
v User catalog for the SMP/E DLIB CSI
Image-related data sets
These data sets contain unshareable system image information. Although the recommendation is that they
be put on separate volumes, as described in this topic, if DASD is scarce you can combine them at the
expense of performance or availability, or both.
Image-related data sets should use system symbolics in their names for easier maintainability. For more
information on system symbolics, see z/OS MVS Initialization and Tuning Reference.
Page data set volume 1: The recommended types of data sets for this volume are:
v PLPA (1-cylinder allocation)
v Common
Unless your system is central-storage constrained, and has significant PLPA paging activity, there is little
or no performance impact to combining the PLPA and COMMON page data sets. The PLPA data set
should be allocated first, as a 1-cylinder data set. The COMMON data set should be allocated second,
immediately following the PLPA data set on the volume. The COMMON data set's size should be large to
contain both PLPA and COMMON pages.
This causes the vast majority of PLPA pages to be written to the COMMON page data set during IPL.
This allows the operating system to use chained CCWs within a single data set and improves
performance when both data sets are on the same volume.
Note: A warning message (ILR005E) is issued during IPL when PLPA pages overflow into the COMMON
page data set during CLPA processing. This message is intended to alert you to the possibility that PLPA
pages might have to be retrieved from data sets on different volumes (which would negatively affect
performance if there was significant PLPA paging). When PLPA and COMMON page data sets are on the
same volume, this message can be ignored.
Page data set volumes 2-n: The recommended types of data sets for these volumes are:
v Local
v SMF
v RMF reporting
v STGINDEX data sets (if used)
v Image-related LOGREC data set (if used)
Considerations when setting up a page data set volume are:
v Where possible, each local page data set should be placed on a dedicated volume connected to a
control unit that is not used for other paging volumes, and on channel paths that are not used for
other paging volumes. Although paging rates to DASD might be low, given sufficient central and
expanded storage, increasing workloads might eventually cause significant paging. If this happens,
locating local page data sets as suggested provides the best performance. Additionally, a large number
of page data sets yields better performance than a small number if there is significant paging to DASD.
IBM does not recommend placing other data sets on the volumes used for page data sets. However, if
you must place other data on local page data set volumes, choose data with the lowest frequency of
reference possible to minimize contention with paging.
v As one might expect, the I/O activity to SMF data sets is proportional to the amount of SMF data you
record from your specified SMF parmlib member.
92
z/OS Planning for Installation
v I/O to STGINDEX data sets is only done when a job stream does batch checkpoints to save status (to
allow the job stream to be restarted) or obtains restart status; therefore, this data set has relatively low
I/O. If your installation always IPLs using CVIO or CLPA (which implies CVIO), there is no reason to
have a STGINDEX data set. In this case, specify VIODSN=IGNORE in IEASYSxx. For more
information, see z/OS MVS Initialization and Tuning Reference.
v For information on choosing the LOGREC recording medium, see z/OS MVS Diagnosis: Tools and Service
Aids. I/O activity is typically low for the image-related LOGREC data set.
v Dynamic dumps are recommended, so SVC dump data sets are not listed.
HFS or zFS customization volume: This is an installation-maintained volume. The data sets on this
volume will not be overlaid by system replacement. This volume is separate from the HFS or zFS target
volume because it may contain unshareable HFS or zFS files that will generally need to be mounted
MODE(RDWR).
The recommended types of data sets for this volume are:
v HFS or zFS data sets that must be in write mode (for instance, /etc, /u, /var) and contain customized
information.
v A user catalog to own the HFS or zFS data sets (optional). This makes the volume portable using
dump and restore, catalog services (IMPORT CONNECT), and SMS definition changes.
Reasons to put these data sets on this volume are:
v To keep customer HFS or zFS customization file systems separate so that they can be mounted under
the file system provided in a system replace.
v To improve system performance. The number of HFS or zFS data sets that must be in write mode
should be minimized to just what is required.
v To keep installation-maintained HFS or zFS data sets (which may be SMS-managed) together on the
same volume for easier management.
Cluster-related data sets
These are shareable data sets used in a multisystem environment. Cluster-related data sets should use
system symbolics in their names for easier maintainability. For more information on system symbolics,
see z/OS MVS Initialization and Tuning Reference.
While all cluster-related data sets can be combined on the same volume, it is usually preferable to
separate certain data sets from others for performance or availability reasons. For example, the following
data sets should usually not be placed on the same volume:
v Primary and secondary RACF databases
v JES spool and checkpoint data sets
v Primary and backup SMS data sets
v Primary and secondary couple data sets
Note: You should also consider placing the primary RACF database in the coupling facility.
Master catalog volume: The recommended types of data sets for this cluster-related volume are:
v Master catalog
v BRODCAST
v Customer parmlib concatenation (not the SMP/E DDDEFed PARMLIB)
v Customer proclib concatenation (not the SMP/E DDDEFed PROCLIB)
v UADS (if used)
v VTAMLST
v SMS ACDS, CDS, model DSCB, HSM, RMM, and so forth
Chapter 6. Preparing for future installations
93
v APPC VSAM data sets (side information, TP profile)
v System control files (TCP/IP configurations and so forth)
v Primary RACF database
v IODF
v SYS0.IPLPARM
v UCATs
v SYS1.DDIR sysplex dump directory data set
v DAE data set
Considerations when setting up the master catalog volume are:
v BRODCAST (when individual user BRODCAST data sets are in use), LOGREC, parmlib, proclib,
UADS, IODF, and DAE are low-activity data sets.
v Customer parmlib and customer proclib should be concatenated with other parmlibs and proclibs. For
information on using system symbolics in concatenated parmlibs, see z/OS MVS Initialization and
Tuning Reference.
JES2 checkpoint volume: For maximum performance and reduced contention, place the primary JES2
checkpoint data set on its own dedicated volume. The JES2 checkpoint primary data set may be on a
coupling facility.
JES2 spool volume: Except in the case of a single-system MAS complex, you should dedicate JES2 spool
volumes to spool data sets, with no other data sets on the volumes. A system can have many spool
volumes.
The JES2 checkpoint duplex data set may be on a coupling facility.
Sysplex-related volume 1: This is a user-maintained volume and does not contain data sets overlaid by
a system replacement.
The recommended types of data sets for this volume are:
v Sysplex primary
v CFRM alternate
v ARM primary
v WLM primary
v LOGR primary
v SFM primary
v Sysplex root
Considerations when setting up sysplex-related volume 1 are:
v Couple data sets should not be placed on volumes that have high I/O activity, are subject to
RESERVEs, have page data sets, contain SYS1.DUMPnn data sets, or are eligible for allocation of data
sets dynamically allocated for SVC dumps.
v The CFRM primary and SYSPLEX primary should be on different volumes attached to different control
units. All other primary couple data sets can reside on the same volume, and all other alternate couple
data sets can reside on a different volume.
You can find more guidelines for placement of couple data sets in z/OS MVS Setting Up a Sysplex.
Sysplex-related volume 2: This is a user-maintained volume and does not contain data sets overlaid by
a system replacement.
The recommended types of data sets for this volume are:
94
z/OS Planning for Installation
v Sysplex alternate
v CFRM primary
v ARM alternate
v WLM alternate
v LOGR alternate
v SFM alternate
v Sysplex root backup
v Secondary RACF database
Couple data sets should not be placed on volumes that have high I/O activity, are subject to RESERVEs,
have page data sets, contain SYS1.DUMPnn data sets, or are eligible for allocation of data sets
dynamically allocated for SVC dumps.
You can find more guidelines for placement of couple data sets in z/OS MVS Setting Up a Sysplex.
Softcopy volume: This volume holds softcopy documents and related data sets.
There can be any number of this type of volume on a system. This is a user-maintained volume and does
not contain data sets overlaid by a system replacement.
The recommended types of data sets for this volume are:
v Documents (books)
v Bookshelves
v Bookindexes
The data sets on the softcopy volume are recommended to be SMS-managed. This allows the hierarchical
storage manager (HSM) to migrate any unused or infrequently-used data sets or documents.
Implementing the recommended data set placements
As you plan how you will implement the recommended data set placements, be sure to include the
following activities:
v Decide whether to merge data sets.
v Determine which data sets to move and where to move them.
v Choose a volume serial naming convention if you plan to use indirect volume serial support.
v Decide whether to use your existing master catalog.
v Move data sets to appropriate volumes.
v Update SMP/E DDDEFs.
v Update catalog entries to point to appropriate volumes.
v Update IEASYMxx in your parmlib, using volume naming conventions.
v If using ServerPac or SystemPac (dump-by-data-set format), save your configuration for the next
release.
v Update any environmentals that are applicable.
Decide whether to merge data sets
During a ServerPac or SystemPac (dump-by-data-set format) installation you can merge data sets while
you modify the shipped order's configuration. This makes it possible to consolidate data sets that are
used in the same ways. For example, you might merge ISPF panel libraries to create a smaller number of
panel libraries. The merged data set configuration remains available for your use during subsequent
installations.The CustomPac Installation Dialog allows IBM candidate data sets to be merged into the
user-defined target data set.
Chapter 6. Preparing for future installations
95
The CustomPac Installation Dialog shows the data sets that are eligible for merging with a data set that
you select. Not all data sets can be merged, however. The LPA and link list attributes must be compatible.
In addition, the Dialog allows you to merge data sets only when they share all of the following attributes
with the target data set:
v
v
v
v
Same record format (RECFM)
Same logical record size (LRECL)
Same data set type (DLIB or target library)
A data set organization of PO (DSORG=PO).
The candidate list is merely a reflection of the merge rules; you should not simply merge all eligible data
sets. Instead, base your merge decisions on logical groupings and similarity of content (for example, all
panel libraries).
If a CBPDO installation is chosen, you can follow the same merge rules used in the CustomPac
Installation Dialog when installing a ServerPac or SystemPac. You must not merge any data sets that
contain like-named members or aliases. For example, SFOMOBJ and SCLBCPP are the two libraries that
cannot be merged together.
Determine which data sets to move and where to move them
You can move data sets manually or you can use the CustomPac Installation Dialog's Create a
Recommended System Layout function to assign them automatically.
Understand the effects of this move on your environment. Do you have any applications that refer to the
data sets specifying a UNIT and VOLUME? If references to the moved data sets use the catalog, and the
catalog has been updated, then moving the data sets should have minimal impact. However, if the
catalog is shared with other systems, then the impact would be greater.
You should also review your backup and recovery procedures for the data sets you plan to move.
Choose a volume serial naming convention if you plan to use indirect volume
serial support
If you follow a naming convention for your SYSRES logical extension volumes, you can use a single
SYMDEF statement in your IEASYMxx parmlib member. For more information about indirect cataloging,
see “Using indirect catalog entries” on page 98.
Decide whether to use your existing master catalog
Is your current master catalog shared between several images? If so, will all images in your system use
the same layout?
In order to share the master catalog, all images should use the same layout. If all systems will not use the
same layout, then the master catalog should not be shared. In this situation, a separate master catalog for
the system that has been converted to the layout must be used because the same data set cannot be
cataloged on two different volumes.
Keep in mind that a catalog that contains extended indirect catalog entries cannot be used by a system
where the support is not available. If you plan on sharing your master catalog with an earlier system that
does not provide this function, you must decide if you will:
v Upgrade the earlier system to the minimum required for extended indirect cataloging
v Not use extended indirect cataloging until each image has the minimum required
v Use a separate master catalog on the later system, and discontinue sharing master catalogs.
Move data sets to appropriate volumes
If you are implementing the recommended data set placements during your ServerPac or SystemPac
(dump-by-data-set format) installation, once you have configured your system data sets you do not have
96
z/OS Planning for Installation
to move any data sets on the global, target, distribution, image, and some cluster volumes. The data sets
will already be restored from the ServerPac or SystemPac (dump-by-data-set format) in the configuration
you have chosen.
If you are implementing the recommended data set placements outside of a ServerPac or SystemPac
(dump-by-data-set format) installation, move the data sets you researched onto the appropriate volumes.
You might need some spare DASD space into order to move the data sets to a temporary location in
order to do a swap. How much space you will need depends on how many data sets you are moving.
Update SMP/E DDDEFs
If you are implementing the recommended data set placements during your ServerPac or SystemPac
(dump-by-data-set format) installation, once you have configured your system data sets you do not
update your SMP/E DDDEFs to reflect the configuration. The DDDEFs will correctly identify the data
sets for the configuration you have chosen.
If you are implementing the recommended data set placements outside of a ServerPac or SystemPac
(dump-by-data-set format) installation, update your DDDEFs to identify the appropriate volumes. You
can use the SMP/E ZONEEDIT command. If your data sets are cataloged, you will not have to update
the UNIT and VOLUME. You should verify that the data sets you moved are correct in their
DDDEFs.The CustomPac Installation Dialog allows DDDEF to be defined for user-defined data sets. The
installation job will define the DDDEF for user-defined data sets as mentioned in the configuration.
Update catalog entries to point to appropriate volumes
If you are implementing the recommended data set placements during your ServerPac or SystemPac
(dump-by-data-set format) installation, once you have configured your system data sets, the catalog your
ServerPac or SystemPac provides will correctly reflect your configuration.
If you are implementing the recommended data set placements outside of a ServerPac or SystemPac
(dump-by-data-set format) installation, update your catalog to identify the appropriate volumes.
Import user catalogs created to manage HFS, zFS, and VSAM (including CSI) data sets, and define the
necessary aliases.
If you are using extended indirect cataloging, your catalog should reflect the SYSRES logical extension
volumes by using your system symbols. It is recommended that &SYSR2 be used as the first SYSRES
logical extension symbol when using extended indirect cataloging.
Update IEASYMxx in your parmlib
Update your parmlib member to reflect the system symbols that you used in your catalog for extended
indirect cataloging. Your IEASYMxx member must match your catalog entries in order for your data sets
to be found.
If using ServerPac or SystemPac (dump-by-data-set format), save your
configuration for the next release
Because ServerPac or SystemPac (dump-by-data-set format) can save your configuration and reuse it for
your next ServerPac or SystemPac, it is recommended that you use this function. Once your configuration
is defined, you will not have to reconfigure the same data sets again.
Update any environmentals that are applicable
If you have any customization, applications, or parameters in your environment that have to be updated
to reflect your new layout, these need to be updated.
Choosing a naming convention for data sets
Choosing the correct naming conventions for system software data sets can save you considerable time
during installation and migration.
Chapter 6. Preparing for future installations
97
Some data sets are associated with only one system in a multisystem environment. Choose names for
these data sets that reflect the name of the specific system. Names of system operational data sets, such
as page and swap data sets, should include the system name. You can accomplish this using the
IBM-supplied system symbol &SYSNAME.
Remember that once you go into production with a set of naming conventions, you cannot easily change
them.
Using symbolic substitution
Using symbolic substitution involves carefully establishing naming conventions for such things as:
v Parmlib and proclib members
v Data sets
v System images
v HCD definitions
v Network definitions
v Subsystems.
Using indirect catalog entries
Indirect cataloging, also known as indirect volume serial support, allows the system to dynamically resolve
volume and device type information for non-VSAM, non-SMS-managed data sets that reside on the
system residence (IPL) volume when accessed through the catalog. This allows you to change the volume
serial number or device type of the system residence volume without also having to recatalog the
non-VSAM data sets on that volume.
Extended indirect volume serial support allows catalog entries to be resolved using system symbols defined
in an IEASYMxx member of parmlib, so that indirect references can be made to one or more logical
extensions to the system residence volume. Like indirect catalog support, this support lets you change the
volume serial numbers or device types of system software target volumes without having to recatalog
their non-VSAM data sets. Therefore, you can have multiple levels of z/OS data sets residing on multiple
sets of volumes with different names and device types, and use them with the same master catalog.
Furthermore, extended indirect volume serial support includes a system-defined static symbol, &SYSR1.
The value of &SYSR1 is automatically set to the volume serial of the IPL volume. If you name your
system residence volumes and their extensions according to a pattern, you can use substrings of the
&SYSR1 symbol to assign substitution text to symbols for the other volumes.
Using indirect catalog entries, together with the extended support, allows you to share master catalogs
among multiple images that use different volumes with different names for the system residence volumes
and their extensions. You can also do this using a single SYMDEF for all images in a shared parmlib data
set. Thus, once set up, no future updates should be needed to continue using this support.
For details about IEASYMxx parmlib members and how to define system symbols to use with indirect
volume serial support, see z/OS MVS Initialization and Tuning Reference. For details about how to use
indirect volume serial support itself, see z/OS DFSMS Access Method Services Commands.
Using parmlib concatenation (logical parmlib)
You can concatenate up to 16 data sets to SYS1.PARMLIB, in effect creating a “logical parmlib”. You
define the concatenation in the LOADxx member of SYS1.PARMLIB or SYSn.IPLPARM. Programs can use
the IEFPRMLB macro to obtain the parmlib concatenation data set list, allocate and open the parmlib data
sets, read a specified parmlib member, and close and unallocate the parmlib data sets. In addition, the
operator, if desired, can use a SETLOAD command to switch from one logical parmlib to another without
an IPL.
98
z/OS Planning for Installation
The overriding benefit of using parmlib concatenation is that it gives you greater flexibility in managing
parmlib. Specifically, it lets you:
v Separate IBM-supplied members from locally-customized ones
v Separate members based on job responsibility and security requirements
v Separate members for change-management purposes.
If you install using ServerPac or SystemPac, the IBM-supplied defaults cause the following concatenated
parmlib data sets to be searched in the order shown when you IPL the target system:
1. SYS1.PARMLIB (either the SYS1.PARMLIB supplied by IBM and edited by you or your original
SYS1.PARMLIB updated appropriately)
2. CPAC.PARMLIB (supplied by IBM and customized for your ServerPac or SystemPac order)
3. SYS1.IBM.PARMLIB (supplied by IBM).
For more information about specifying parmlib concatenation, see z/OS MVS Initialization and Tuning
Reference.
DASD space utilization and performance
The space required by system software data sets, except for PDSE data sets, is affected by the block sizes
you choose for those data sets. Generally, data sets with larger block sizes use less space to store the same
data than those with smaller block sizes. Data sets that store more data in less space usually offer better
DASD performance than those that use more space to store the same data.
There are some exceptions to the general rule that larger block sizes result in better space utilization. For
example, fixed block (FB) record format data sets should not be allocated with block sizes larger than half
the track length of the DASD they are allocated on. Doing so will cause considerable DASD space to be
wasted, because current DASD track lengths are less than twice the maximum block size of 32,760 bytes.
However, some data sets are best allocated using specific block sizes. When this is true of system
software data sets, IBM recommends specific block sizes for them.
Note: Block sizes listed in the data set space tables in program directories are not generally
recommended unless they are explicitly identified as recommended. You should treat the
recommendations in this topic as though they apply to all the system software data sets you allocate
unless the product specifically says to do otherwise.
Generally, system-determined block sizes (SDB) makes the best choice for block size for fixed block (FB),
variable block (VB), and variable-block spanned (VBS) record format data sets. You should use SDB for
all system software data sets with these record formats except those for which IBM specifically
recommends other block sizes. One way to do this is specifying BLKSIZE=0 in the DCB parameter of a
DD statement when allocating new data sets using JCL. For details about how to specify
system-determined block sizes, see z/OS MVS JCL Reference.
Note that system determination of block sizes affects the block size and number of blocks used. It does
not affect the amount of space allocated in a data set. The amount of space is defined by IBM (in sample
jobs and program directories).
Undefined record format data sets
Data sets with undefined (U) record formats do not follow the same rules as those with other record
formats. In particular, most load libraries in partitioned data sets (not PDSEs) will require less space
(often as much as 20% less) and offer better performance at increasing block sizes up to the block size
limit of 32,760 bytes. This is because the program management binder, linkage editor, and IEBCOPY
COPYMOD command use the data set block size only to set the maximum block length they will use.
They will write a block whenever the space available on a track is greater than the minimum block size
(over which you have no control) and less than or equal to the maximum block size.
Chapter 6. Preparing for future installations
99
Allocate all load libraries using a block size of 32,760 bytes unless you plan to move your system
software data sets from the device types on which they were originally allocated to device types with
shorter track lengths, or plan to move them between device types having different track lengths without
using IEBCOPY COPYMOD. A block size of 32,760 bytes will optimize space utilization and performance
for all system software load libraries.
Using recommended block sizes for z/OS data sets
For most efficient use of DASD, you should allocate z/OS data sets using the following block sizes:
v Use the system-determined block size for most non-RECFM U data sets (for example, code BLKSIZE=0
in JCL).
v For RECFM U data sets, use BLKSIZE=32760. (Note that 32760 is optimum because all supported
DASD types have track lengths greater than 32,760 bytes.)
v If you use a UADS data set for TSO/E, you should generally use the same block size you currently use
to allocate a new one. Do not allocate the UADS data set with a system-determined block size. This will result
in very poor DASD space utilization. Instead, model your new UADS from your existing UADS or start
with a small block size and increase the block size if a significant number of user ID entries are split
into multiple members. For details about allocating a UADS data set and optimizing its block size, see
z/OS TSO/E Customization.
v The AFP font libraries should not be allocated with system-determined block sizes. The correct block
size for the font libraries is 12288. The font data sets will take up more space if system-determined
block sizes are used and will result in very poor DASD space utilization.
For details about the conditions under which the system can determine the optimum block size for a data
set, look for information about system-determined block sizes in z/OS DFSMS Using Data Sets.
100
z/OS Planning for Installation
Appendix A. Installation checklist
This topic lists the tasks for installing z/OS. You can use this checklist of tasks as an aid when creating
your installation plan.
To install in the broad sense means to perform the tasks necessary to make a system operational. The
starting point is the decision to install, either for the first time or a subsequent time (the latter being an
upgrade). The ending point is a system in production.
An upgrade involves migration, during which you install your new system with the objective of making it
functionally compatible with the previous system, followed by exploitation, which involves taking
advantage of the enhancements in the new release.
This checklist can be used by either the first-time installer (whose enterprise never had z/OS before) or
the installer who is upgrading to a new release.
Step 1. Plan the details
1. If installing for the first time (not upgrading), understand installation basics.
Reference information: Chapter 1, “Learning about z/OS,” on page 1.
2. If upgrading, understand changes in the new release that affect installing.
Reference information: “Summary of changes” on page xi.
3. Choose the software installation method. Choices are:
v ServerPac (entitled)
v CBPDO (entitled)
v SystemPac (additional charge)
v Others at additional charge
v None if sharing or cloning
Reference information:
v ServerPac, CBPDO, and SystemPac: “Choosing an installation package for installing z/OS” on
page 39
v Other fee-based methods: IBM Global Technology Services (www.ibm.com/services)
v Sharing or cloning: “Installing z/OS without using an installation package” on page 40
4. Choose the software delivery method. Choices are:
v Tape
v DVD
v Internet
Reference information: “Choosing the delivery medium: tape, DVD, or Internet” on page 40.
5. Identify driving system hardware and software requirements.
Reference information: Chapter 3, “Preparing the driving system,” on page 45.
6. Choose the target system hardware to install or upgrade.
Reference information: “Identifying hardware requirements for the target system” on page 63 and
Appendix C, “Additional hardware requirements for running z/OS V2R3,” on page 117.
7. Choose the target system software to install.
Possible types of software are z/OS optional features, IBM middleware, IBM applications, and ISV
products.
Reference information: “Choosing software products to install and identifying requisites” on page 59
and Appendix B, “Software requirements for running z/OS V2R3,” on page 107.
© Copyright IBM Corp. 2002, 2017
101
8. Choose the target system JES level.
z/OS V1R13 is the last release to support a staged migration for JES2 and JES3. Starting in z/OS
V2R1, customers need to migrate to all elements of z/OS at the same time, including JES2, JES3, or
both.
Reference information: “Using JES and SDSF with z/OS V2R3” on page 69.
9. If upgrading, identify migration actions for z/OS.
Migration actions, or tasks, fall into three categories based on when they should be performed:
v Before installing (performed on the old system)
v Before the first IPL (performed on the new system before the first IPL)
v After the first IPL (performed on the new system after the first IPL)
Two migration actions in the “before installing” category are worthy of note here:
v Identifying coexistence and fallback service.
Coexistence service (installed on old systems that share resources) allows the new system to coexist
(share resources) with old systems. (Examples of shared resources are JES spools, RACF databases,
user catalogs, and ISPF profiles.)
Fallback service (installed on the system from which you are migrating) allows you to back out of
the installation, if necessary.
v Reviewing hardware and software PSP buckets for changes to planning information.
Reference information:
v All of z/OS Migration. Note that within the publication, the three possible timings are labeled
“before installing z/OS V2R3”, “before the first IPL of z/OS V2R3”, and “after the first IPL of
z/OS V2R3”.
|
|
|
v Install coexistence and fallback PTFs in z/OS Migration
v Review PSP buckets in z/OS Migration
10. If upgrading, identify migration actions for IBM middleware, IBM applications, and ISV products.
Reference information: IBM product publications and ISV publications.
11. If installing for the first time, identify customization needed on the new system.
This customization will allow you to exploit (make productive use of) the z/OS functions necessary
to accomplish your enterprise's goals.
Reference information:
v z/OS publications that have customization information, such as z/OS MVS Initialization and Tuning
Reference and z/OS Infoprint Server Customization. For the complete z/OS library, go to IBM
Knowledge Center (www.ibm.com/support/knowledgecenter/SSLTBW/welcome).
v Product-specific publications that have customization information, such as CICS Customization
Guide, which is available online at CICS Transaction Server for z/OS (www.ibm.com/support/
knowledgecenter/SSGMGV/welcome.html).
v Chapter 5, “Preparing for customization and test,” on page 71.
12. If upgrading, identify postmigration customization needed on the new system.
Examples of postmigration customization tasks are adding devices, upgrading the network, and
taking advantage of (exploiting) release enhancements.
Reference information:
v z/OS publications that have customization information, such as z/OS MVS Initialization and Tuning
Reference and z/OS Infoprint Server Customization. For the complete z/OS library, go to IBM
Knowledge Center (www.ibm.com/support/knowledgecenter/SSLTBW/welcome).
v Product-specific publications that have customization information, such as CICS Customization
Guide, which is available online at CICS Transaction Server for z/OS (www.ibm.com/support/
knowledgecenter/SSGMGV/welcome.html).
v Chapter 5, “Preparing for customization and test,” on page 71.
102
z/OS Planning for Installation
13. Identify test activities. Be sure they are consistent with local test policies.
Reference information: “Scheduling test activities” on page 78.
14. Establish a fallback strategy.
Reference information: “Coexistence and fallback” on page 26.
15. Prepare for future installations.
Specific tasks are separating data from software, placing data sets on specific volumes, choosing a
naming convention for data sets, using indirect catalog entries, using parmlib concatenation, and
making optimum use of DASD space.
Reference information: Chapter 6, “Preparing for future installations,” on page 79.
Step 2. Order hardware and software
1. Order driving system hardware and software that you chose in Step 1.
2. Order target system hardware and software that you chose in Step 1. For software, place your order
with Shopz, the self-service Internet application, if possible. Go to IBM Software Shopz
(www.ibm.com/software/shopzseries/ShopzSeries_public.wss).
Reference information: “Ordering z/OS and related IBM products” on page 61 and IBM Software
Shopz (www.ibm.com/software/shopzseries/ShopzSeries_public.wss).
3. If upgrading, order coexistence and fallback PTFs that you identified in Step 1.
4. Receive software shipments and verify contents.
Step 3. If upgrading, prepare the current environment (old target
system) for the new release
1. Perform as many z/OS migration actions as possible on the existing (old) system. These are the
preinstallation migration actions that you identified in Step 1, which have a timing of “before
installing z/OS V2R3” in z/OS Migration. These migration actions include installing the coexistence
and fallback PTFs that you identified in Step 1 and ordered in Step 2.
Reference information: z/OS Internet library (www.ibm.com/systems/z/os/zos/library/bkserv)
2. Perform as many migration actions as possible for IBM middleware, IBM applications, and ISV
products that run on the existing (old) system. These migration actions were identified in Step 1.
Reference information: IBM product publications and ISV publications.
3. Build, test, and put the old target system back into production. Follow local procedures.
Step 4. Build the driving system
The driving system is the system image (hardware and software) that you use to install the target system.
The system from which you are migrating can be used as the driving system, or you may use a different
system provided that it meets the minimal hardware and software requirements for a driving system.
1. Install or update driving system hardware that you identified in Step 1 and ordered in Step 2.
Reference information: related product documentation.
2. Install or update driving system software that you identified in Step 1 and ordered in Step 2.
Step 5. Build and verify the target system
The target system is the system software libraries and other data sets that you are installing. You log on to
the driving system and run jobs there to create or update the target system. Once the target system is
built, it can be IPLed on the same hardware (same LPAR or same processor) or different hardware than
that used for the driving system.
ServerPac or SystemPac dump-by-data-set installation:
Appendix A. Installation checklist
103
1. Install or upgrade target system hardware that you chose in Step 1 and ordered in Step 2.
Reference information: Related product documentation.
2. Review PSP buckets for the latest installation information.
Reference information: “PSP information” on page 32.
3. Prepare target system volumes for installation.
Reference information: “Preparing for installation” on page 50.
4. Receive the ServerPac or SystemPac order to DASD.
Reference information: ServerPac: Using the Installation Dialog or SystemPac: CustomPac Dialog
Reference.
5. Select the type of installation you prefer: full system replacement or software upgrade. Each requires
a different amount of work and a different order of tasks.
Reference information: ServerPac: Using the Installation Dialog or SystemPac: CustomPac Dialog
Reference.
6. Create and tailor the work configuration.
Reference information: ServerPac: Using the Installation Dialog or SystemPac: CustomPac Dialog
Reference.
7. Run installation jobs. The jobs install distribution and target libraries for your target system.
Reference information: ServerPac: Installing Your Order or SystemPac Installation Guide.
8. Review system HOLDs and latest Enhanced HOLDDATA in the CPAC.DOCLIB data set in the
ServerPac or SystemPac order and at Enhanced HOLDDATA for z/OS (service.software.ibm.com/
holdata/390holddata.html).
Reference information: “Maintenance after installation” on page 34.
9. Run element-specific post-installation jobs on the driving system.
Reference information: ServerPac: Installing Your Order or SystemPac Installation Guide.
| 10. If upgrading, perform pre-first-IPL migration tasks for z/OS. These migration actions were identified
|
in Step 1 and have a timing of “before the first IPL of z/OS V2R3” in z/OS Migration.
Reference information: z/OS Internet library (www.ibm.com/systems/z/os/zos/library/bkserv)
|
11. If upgrading, perform pre-first-IPL migration tasks for IBM middleware, IBM applications, and ISV
products. These migration actions were identified in Step 1.
Reference information: IBM product publications and ISV publications.
12. IPL the target system and log on.
Reference information: ServerPac: Installing Your Order or SystemPac Installation Guide.
13. Run element-specific post-installation jobs on the target system.
Reference information: ServerPac: Installing Your Order or SystemPac Installation Guide.
14. Run installation verification programs (IVPs).
Reference information: ServerPac: Installing Your Order or SystemPac Installation Guide.
15. Download client code to workstations, if applicable.
Reference information: element-specific documentation.
16. Apply service to target system software, if necessary.
Reference information: “If you are installing a z/OS ServerPac or Product ServerPac order” on page
68 or “If you are installing a z/OS SystemPac order” on page 69.
17. Save the customized configuration.
Reference information: ServerPac: Using the Installation Dialog or SystemPac: CustomPac Dialog
Reference.
18. Back up the system.
Reference information: Appendix D, “Making a copy of your system software (cloning),” on page
129.
104
z/OS Planning for Installation
CBPDO installation:
1. Install or upgrade target system hardware.
Reference information: Related product documentation.
2. Review PSP buckets for the latest installation information.
Reference information: “PSP information” on page 32.
3. Clone the system.
Reference information: Appendix D, “Making a copy of your system software (cloning),” on page
129.
4. Update SMP/E zone entries. For information, see z/OS Program Directory in the z/OS Internet library
(www.ibm.com/systems/z/os/zos/library/bkserv).
5. Create “FMIDSETs” that you will install in stages called “waves”. For information, see z/OS Program
Directory in the z/OS Internet library (www.ibm.com/systems/z/os/zos/library/bkserv).
6. Install Wave 0. For information, see z/OS Program Directory in the z/OS Internet library
(www.ibm.com/systems/z/os/zos/library/bkserv).
|
|
|
|
|
|
|
|
|
|
|
7. Install Wave 1 and, if upgrading, perform pre-first-IPL migration tasks for z/OS, IBM middleware,
IBM applications, and ISV products. (The pre-first-IPL migration tasks for z/OS were identified in
Step 1 and have a timing of “before the first IPL of z/OS V2R3” in z/OS Migration.)
Reference information: z/OS Internet library (www.ibm.com/systems/z/os/zos/library/bkserv),
IBM product publications, and ISV publications.
8. Install Wave 2 and, if upgrading, perform pre-first-IPL migration tasks for z/OS, IBM middleware,
IBM applications, and ISV products. (The pre-first-IPL migration tasks for z/OS were identified in
Step 1 and have a timing of “before the first IPL of z/OS V2R3” in z/OS Migration.)
Reference information: z/OS Program Directory in the z/OS Internet library (www.ibm.com/systems/
z/os/zos/library/bkserv), and the IBM Knowledge Center (www.ibm.com/support/
knowledgecenter), IBM product publications, and ISV publications.
9. Download client code to workstations, if applicable.
Reference information: element-specific documentation.
10. Apply service to target system software, if necessary.
Reference information: “If you are installing a z/OS CBPDO order...” on page 68.
11. Back up the system.
Reference information: Appendix D, “Making a copy of your system software (cloning),” on page
129.
SystemPac full volume dump installation:
1. Install or upgrade target system hardware.
Reference information: related product documentation.
2. Review PSP buckets for the latest installation information.
Reference information: “PSP information” on page 32.
3. Prepare target system volumes for restore.
4. Initialize volumes.
Reference information: SystemPac Installation Guide.
5. Unload the tapes to the initialized volumes.
Reference information: SystemPac Installation Guide.
|
|
6. If upgrading, perform pre-first-IPL migration tasks for z/OS. These migration actions were identified
in Step 1 and have a timing of “before the first IPL of z/OS V2R3” in z/OS Migration.
|
Reference information: z/OS Internet library (www.ibm.com/systems/z/os/zos/library/bkserv)
7. If upgrading, perform pre-first-IPL migration tasks for IBM middleware, IBM applications, and ISV
products. These migration actions were identified in Step 1.
Appendix A. Installation checklist
105
Reference information: IBM product publications and ISV publications.
8. IPL the target system and log on.
Reference information: SystemPac Installation Guide.
9. Run post-installation jobs after IPL.
Reference information: SystemPac Installation Guide.
10. Verify installation.
Reference information: SystemPac Installation Guide.
Step 6. Customize and test the target system
| 1. If upgrading, perform the post-first-IPL migration tasks for z/OS. These migration actions were
|
identified in Step 1 and have a timing of “after the first IPL of z/OS V2R3” in z/OS Migration.
|
Reference information: z/OS Internet library (www.ibm.com/systems/z/os/zos/library/bkserv)
2. If upgrading, perform the post-first-IPL migration tasks for IBM middleware, IBM applications, and
ISV products. These migration actions were identified in Step 1.
Reference information: IBM product publications and ISV publications.
3. If installing for the first time, perform the customization tasks that you identified in Step 1.
Reference information: z/OS Internet library (www.ibm.com/systems/z/os/zos/library/bkserv), IBM
product publications, and ISV publications.
4. IPL the customized system. Follow local procedures.
5. Test the customized system. Use the test cases that you identified in Step 1.
Step 7. Put the tested system into production (cut over to production)
1. Deploy the tested system. Follow local procedures.
2. Clone the tested system across a multisystem configuration.
Reference information: Appendix D, “Making a copy of your system software (cloning),” on page 129.
Step 8. If upgrading, perform postmigration customization
(If installing for the first time, customization is done in Step 6.)
1. Perform the customization tasks that you identified in Step 1.
Reference information: z/OS Internet library (www.ibm.com/systems/z/os/zos/library/bkserv), IBM
product publications, and ISV publications.
106
z/OS Planning for Installation
Appendix B. Software requirements for running z/OS V2R3
|
Careful planning is needed to ensure that you run the appropriate software with z/OS V2R3 on your
target system. This topic lists software requirements to consider.
|
If you are upgrading from z/OS V2R1 or z/OS V2R2, you can use the product levels on z/OS V2R3 that
you used on your prior z/OS release, as long as the product levels are still service-supported, with the
following exceptions:
v If you are using any of the products in Table 12 on page 108, you must use the product levels shown.
v If you are using any of the functions in Table 13 on page 108, and those functions have dependencies
on IBM middleware or application products, you must use the product levels shown (or later).
Notes:
1. This topic does not describe program requirements that are related to systems in a sysplex using the
coupling facility. For that information, see Parallel Sysplex (www.ibm.com/systems/z/advantages/
pso).
2. Requirements that are listed in this topic reflect the minimum levels.
3. Some IBM products and z/OS elements and features have comparable non-IBM equivalents. This
topic reflects only IBM software.
|
|
|
|
|
4. z/OS does not support service for client operating systems whose service is withdrawn by the
operating system manufacturer.
5. z/OS V2R3 has an overall dependency on IBM 64-bit SDK for z/OS, Java Technology Edition, V8
(5655-DGH) and IBM 31-bit SDK for z/OS, Java Technology Edition, V8 (5655-DGG). Generally, this
dependency exists for new or enhanced functions in z/OS. Older functions that are unchanged from
previous releases, and have lower Java requirements, are expected to work with earlier supported
releases of Java. For the specific Java dependencies for each element, see Table 13 on page 108.
Determine which PTFs are needed for z/OS V2R3
You must determine which PTFs are required for minimum support on z/OS V2R3, and which PTFs are
required to use specific functions in z/OS V2R3.
To do so, follow these steps:
1. Identify the PTFs for both minimum support and functional support with a FIXCAT called
IBM.TargetSystem-RequiredService.z/OS.V2R3, in enhanced HOLDDATA. The HOLDDATA type
FIXCAT (fix category) is used to associate an APAR to a particular category of fix for target system
PTFs identified as levels.
2. To identify the PTFs on your current system that would be needed for your upgrade to z/OS V2R3,
run the SMP/E command REPORT MISSINGFIX.
You might, for example, use a command such as the following to identify PTFs for the CICS CSI:
SET BDY(GLOBAL).
REPORT MISSINGFIX ZONES(CICS51T)
FIXCAT(IBM.TargetSystem-RequiredService.z/OS.V2R3).
3. To determine what PTFs are needed and not yet installed, run the command REPORT MISSINGFIX
against the global zones that you use to support your middleware and application products.
Determine the minimum product or functional release levels for z/OS V2R3
|
IBM middleware and application products require a specific release to run on z/OS V2R3. You cannot use
the FIXCAT support to determine these release levels. Instead, you can refer to the tables in this section.
© Copyright IBM Corp. 2002, 2017
107
| Table 12 lists the IBM middleware and application products that require a specific version of the product
| to run on z/OS V2R3.
|
Table 12. IBM middleware and application products that require a specific version to run on z/OS V2R3
|
|
If you use this IBM product...
You need this product level (in most cases achieved
with PTFs)
|
|
|
IBM Application Performance Analyzer for z/OS
IBM Application Performance Analyzer for z/OS
requires the 14.1 level at a minimum. Earlier levels of
this product are not supported for use with z/OS V2R3.
|
||
|
|
|
|
|
|
|
|
|
|
IBM Security zSecure™ products:
IBM Security zSecure products require the 2.3.0 level at a
minimum. Earlier levels of this product are not
supported for use with z/OS V2R3.
v zSecure Admin (5655-N16)
v zSecure Visual (5655-N20)
v zSecure Audit (5655-N17). A subset of the zSecure
Audit functions is contained in Adapters for QRadar®
SIEM (5655-AD8).
v zSecure Alert (5655-N21)
v zSecure Command Verifier (5655-N19)
v zSecure CICS Toolkit (5655-N18), which is installed on
CICS.
| Table 13 lists the functions of z/OS V2R3 that require specific optional features, IBM middleware
| products, or IBM application products.
Table 13. Functions of z/OS V2R3 that require specific z/OS optional features or IBM products
|
z/OS element or feature
Required z/OS optional features or IBM products (by function)
Alternate Library for REXX
None.
BCP
For requirements related to software support for the IBM z14 (z14),IBM z13, z13sTM,
zEC12, and zBC12 servers, see z/OS Migration.
DB2 Data Server Driver for JDBC and SQLJ supports Java Batch Container function
with PTF UK69734 and UK69742 (FMID JDB9912)
Dynamic APF requirements:
v The z/OS Security Server feature is required if you want to use the RACF data
security monitor program (DSMON) to produce reports for APF-authorized
programs.
FICON requirements:
v To simplify configuration definition tasks when you are migrating to FICON, use
the z/OS HCM feature.
v To report on the measurement data that is generated for FICON CHPIDs, use the
z/OS RMF feature.
v To use the architecture enhancements, use the following:
– z/OS JES3 feature
– PSF for z/OS V4 (5655-M32)
– Tivoli System Automation for z/OS V3 (5698-SA3) or later
– IMS V12 (5635-A03) or later.
108
z/OS Planning for Installation
Table 13. Functions of z/OS V2R3 that require specific z/OS optional features or IBM products (continued)
z/OS element or feature
Required z/OS optional features or IBM products (by function)
BCP (continued)
IEAVFTED REXX exec requirements:
v The IBM supplied IEAVFTED REXX exec is used to produce a Timed Event Data
Report in either a TSO or IPCS environment. The exec is a compiled REXX
program that requires the full REXX compiler runtime libraries (at least [5695-014]
REXX LIBR BASE V1.4 (FMID HWJ9140) installed. IEAVFTED does not work with
the z/OS base element, REXX Alternate Runtime Library z/OS Base (FMID
HWJ9143).
Java requirements:
|
|
|
|
|
|
|
|
v Capacity Provisioning requires IBM 31-Bit SDK for z/OS, Java 2 Technology
Edition V8 (5655-DGG) or later. CP does not support the 64-bit version of this
SDK.
|
|
|
IBM zEnterprise Application Assist Processor (zAAP) is a specialized processing unit
that provides an economical Java execution environment. Use of zAAP requires a
supported level of IBM SDK Java Technology Edition, either 31-bit or 64-bit.
v Predictive Failure Analysis (PFA) requires IBM 31-Bit SDK for z/OS, Java 2
Technology Edition V8 (5655-DGG) or later. PFA does not support the 64-bit
version of this SDK.
v
Sub-Capacity Reporting Tool (SCRT) requires IBM 31-bit or 64-bit SDK for z/OS,
Java 2 Technology Edition, V7.0 or later.
Job support for started tasks requirements:
v z/OS Security Server feature is required if you plan to use dynamic security
control for started tasks. You can do this by using the STARTED class to assign
RACF identities to started procedures and jobs dynamically with the RDEFINE
and RALTER commands.
Messages that are displayed in non-English languages:
v The z/OS Security Server feature is required if you use this function because
RACF is used to obtain language information for users.
Operations log (OPERLOG) requirements:
v The z/OS Security Server feature is required if you want to protect the OPERLOG
log stream.
v The z/OS SDSF feature is required if you want to use the log browser facility for
the OPERLOG log stream.
Appendix B. Software requirements for running z/OS V2R3
109
Table 13. Functions of z/OS V2R3 that require specific z/OS optional features or IBM products (continued)
z/OS element or feature
Required z/OS optional features or IBM products (by function)
BCP (continued)
System-managed duplexing rebuild requires any APARs included in the
CFDUPLEXING PSP bucket. This function can be exploited by the following
products and components:
v System logger, the JES2 checkpoint, WLM for multisystem enclaves and IRD,
VTAM GR and multinode persistent sessions (MNPS), and BatchPipes® for OS/390
V2 (5655-D45) enable system-managed duplexing rebuild through APAR PQ49953.
v IRLM V2R1 and higher enables system-managed duplexing rebuild for the IRLM
lock structure for IMS and DB2 data sharing.
v DB2 supports system-managed duplexing rebuild for its system communication
area. DB2 supports user-managed duplexing rebuild for its group buffer pools, as
of DB2 V5.
v MQSeries enables system-managed duplexing rebuild for shared queues in
WebSphere MQ for z/OS.
v CICS shared temporary storage queues, coupling facility data tables, and named
counters are protected by system-managed duplexing rebuild in CICS Transaction
Server (TS) for z/OS V3.1 (5655-M15) and later.
v IMS supports system-managed duplexing rebuild function for IMS shared message
queue structures and IMS fast path expedited message handler (EMH) structures.
IMS also supports z/OS system-managed duplexing rebuild function for IMS fast
path virtual storage option (VSO) structures. This support also enables the
system-managed rebuild and automatic altering of the VSO structure size.
TSO consoles used as extended MCS consoles:
v The z/OS Security Server feature is required if you want to use this function
because RACF is used to obtain console security attributes.
z/OS UNIX kernel requirements:
v The z/OS Security Server feature is required if any address space must call a z/OS
UNIX kernel service.
BDT
One or both of the BDT features (BDT File-to-File or BDT SNA NJE).
BDT File-to-File
None.
BDT SNA NJE
Any supported JES3 level.
BookManager READ
To use the print function to print BookManager documents on AFP printers, you
need to set your BookManager READ print options to GML Starter Set and install the
following products:
v DCF V1R4 (5748-XX9)
v PSF for z/OS V4 (5655-M32)
CIM
None.
110
z/OS Planning for Installation
Table 13. Functions of z/OS V2R3 that require specific z/OS optional features or IBM products (continued)
z/OS element or feature
Required z/OS optional features or IBM products (by function)
Communications Server
IP Services has the following software requirements:
|
|
v For SNMP NetView client support: Tivoli NetView for z/OS V5R4 (5697-ENV) or
later , as long as it is service supported.
v For file access protection for FTP: z/OS Security Server feature
|
v For FTP DB2 query: A supported DB2 level is required.
v For user-written programs in Pascal that interface to a TCP, UDP, or IP boundary:
IBM VS Pascal Compiler and Library (5668-767)
v For IMS sockets on z/OS: IMS V12 (5635-A03) or later
v For user-written programs in C that interface to an X Window System client,
Remote Procedure Call, TCP or UDP protocol boundary, DPI, IP, or z/OS UNIX
feature (Rcommands, RPC, or X Window System), you require the z/OS XL
C/C++ feature.
v For TCP/IP functions written in C (C sample programs, Network Database System
client and server, Network Computing System, Remote Procedure Call, non-z/OS
UNIX X Window System) or z/OS UNIX features (ONC/RPC, X Window System),
you require the z/OS XL C/C++ feature.
SNA Services has the following software requirements:
v For High Performance Routing (HPR) Border Node and HPR network
management:
|
– Tivoli NetView for z/OS z/OS V5R4 (5697-ENV) or later.
v If running z/OS as a guest under z/VM, the PTF for VM APAR VM64789 is
required.
Communications Server
Security Level 3
None.
Cryptographic Services
None.
DFSMSdfp
Distributed FileManager (DFM/MVS) DataAgent and the DFM target server: To
check the authorization of remote systems to connect to z/OS and to access specific
data sets, the z/OS Security Server feature (RACF component) is required.
VSAM record level sharing (RLS): To use this function, you need the z/OS Security
Server feature (RACF component); CICS TS for z/OS V3.1 (5655-M15) or later; and
appropriate levels of COBOL, PL/I, FORTRAN, and Language Environment runtime
libraries for batch applications that use VSAM RLS data access.
For full support in exploiting PDSE member generations with ISPF, IBM Data Set
Commander V8.1 (5635-ISP) is beneficial. This product can display a member list
with all member generations, from which users can browse, edit, copy, delete, and
restore PDSE member generations both online and in batch.
DFSMSdss
IMS backup-while-open support: To use this function, the Database Manager feature
of IMS V12 (5635-A03) or later is required.
DFSMShsm
Control data set (CDS) record level sharing (RLS) serialization: To use this function,
global resource serialization or an equivalent function is required.
DFSMSrmm
None.
DFSMStvs
To apply forward recovery logs to a restored copy of a data set, you need CICS
VSAM Recovery for z/OS V4 (5655-P30).
To back up data sets while they are open, you need the z/OS features DFSMShsm
and DFSMSdss.
DFSORT
DFSORT Performance Booster for The SAS System requires enabling support from
SAS Institute Inc.
Appendix B. Software requirements for running z/OS V2R3
111
Table 13. Functions of z/OS V2R3 that require specific z/OS optional features or IBM products (continued)
z/OS element or feature
Required z/OS optional features or IBM products (by function)
Distributed File Service
The IP Services component of the z/OS Communications Server base element must
be operational.
SMB print serving support requires the z/OS Infoprint Server feature to be
operational.
SMB password encryption requires the OCSF component of the z/OS Cryptographic
Services base element to be operational to use hardware encryption capabilities.
|
|
|
Supported SMB clients include Microsoft Windows 8, Microsoft Windows 7,
Microsoft Windows Server 2012, Microsoft Windows Server 2008, SUSE Linux with
Samba, and Redhat Linux with Samba.
EREP
None.
ESCON Director Support
None.
FFST
None.
GDDM
None.
GDDM-PGF
None.
GDDM-REXX
None.
HCD
To migrate from the active switch configuration or to activate a switch configuration,
Tivoli System Automation for z/OS (5698-SA3) is required.
To perform the verification/priming function of the active I/O configuration, Tivoli
System Automation for z/OS (5698-SA3) is required.
Use of the CHPID Mapping Tool is recommended for mapping logical CHPIDs to
physical channels (PCHIDs) and creating input to HCD/IOCP. The tool is a
workstation-based Java application available from the Resource Link home page
(www.ibm.com/servers/resourcelink). It updates the IOCP input file with the PCHID
values and can generate reports to help with cabling.
Note: Beginning with z/OS V2R1 (HCD version 2), you can verify the active or
target configuration by using z/OS discovery and I/O Autoconfiguration (zDAC), if
Tivoli System Automation (TSA) I/O operations is not installed or not running. This
action is possible for a server after the z196 and z114 generations supporting zDAC
and for a system in the local sysplex, which is capable for dynamic activates. The
verification is limited to FICON attached storage devices.
|
|
|
|
|
|
HCM
Operating system (workstation):
v Windows 7
Host communication:
v TCP/IP: TCP/IP networking protocol must be installed (delivered with Windows
7).
v HCM installation: A method to download the code from the host to the
workstation is required (for example, FTP or PCOMM).
HLASM
None.
HLASM Toolkit
None.
IBM HTTP Server
A web browser must be installed on a networked workstation.
Communications Server IP connectivity must be established.
|
IBM Knowledge Center for
z/OS
112
v The Knowledge Center element requires that the following Java level is installed:
z/OS Planning for Installation
– IBM 64-bit SDK for z/OS, Java Technology Edition, V8 (5655-DGH)
Table 13. Functions of z/OS V2R3 that require specific z/OS optional features or IBM products (continued)
|
|
z/OS element or feature
Required z/OS optional features or IBM products (by function)
IBM TDS
If IBM TDS uses DB2 to store data for a general LDAP directory server, a supported
DB2 level is required.
DB2 is not required in the following situations:
v If IBM TDS is used only to provide LDAP access to user, group, connect, and
resource profiles stored in RACF.
v If IBM TDS is used only to provide LDAP access to configuration data stored in an
IODF by way of HCD
v If IBM TDS uses a file system to store data for a general LDAP directory server.
If IBM TDS uses a file-based backend (LDBM, file-based GDBM, or CDBM), a z/OS
UNIX file system is required for storing this data. IBM TDS for z/OS requires a z/OS
UNIX System file system for storing the schema backend.
To write application programs that use the Kerberos or GSS-API programming
interface, you require the z/OS XL C/C++ feature.
To use the ldapdiff utility, you require IBM 31-bit SDK for z/OS, Java 2 Technology
Edition, V7.1 (5655-W43).
|
||
IBM z/OS Management
Facility (z/OSMF)
|
|
|
|
The z/OSMF element requires the following minimum level of Java:
v IBM 64-bit SDK for z/OS, Java Technology Edition, V8 SR4 FP2 (5655-DGH)
By default, the SDK resides in the directory /usr/lpp/java/J8.0_64 on your system.
If you installed it in another location, be sure to include the JAVA_HOME statement
in your IZUPRMxx parmlib member, as described in IBM z/OS Management Facility
Configuration Guide.
ICKDSF
None.
Infoprint Server
The z/OS Security Server feature is required.
To print output from Infoprint Server with AFP printers, you require PSF for z/OS
V4 (5655-M32).
If you want to use the IPP server function of Infoprint Server, you require one of
these:
v IBM 31-bit SDK for z/OS, Java Technology Edition, V7.1 (5655-W43)
|
v IBM 31-bit SDK for z/OS, Java Technology Edition, V8 (5655-DGG)
The IPP Server can use only the 31-bit SDK. However, you can install the 64-bit SDK
on your z/OS system. See the Java versions that follow.
To use the print management functions that are provided by Infoprint Central, you
require:
v A running IBM HTTP Server base element of z/OS
v XML Toolkit for z/OS V1R10 (5655-J51).
|
|
|
|
v One of these:
– IBM 31-bit SDK for z/OS, Java Technology Edition, V7.1 (5655-W43) or V8
(5655-DGG)
– IBM 64-bit SDK for z/OS, Java Technology Edition, V7.1 (5655-W44) or V8
(5655-DGH)
Appendix B. Software requirements for running z/OS V2R3
113
Table 13. Functions of z/OS V2R3 that require specific z/OS optional features or IBM products (continued)
|
|
z/OS element or feature
Required z/OS optional features or IBM products (by function)
Infoprint Server (continued)
Accessing Infoprint Central requires one of the following web browsers on
workstations with these tested operating systems:
|
|
|
Windows 7 Professional, Windows 8.1, and Windows Server 2012
v Microsoft Internet Explorer 10.0 or 11.0
v Mozilla Firefox 42 Extended Support Release (ESR) or later
|
|
|
|
|
|
|
Windows 10
v Microsoft Edge 25 or later
v Microsoft Internet Explorer 10.0 or 11.0
v Mozilla Firefox 42 Extended Support Release (ESR) or later
Note: Other browsers might work with Infoprint Central V2R3, but have not been
tested. Using untested browsers might result in some Infoprint Central functions that
are unavailable.
Infoprint Server can use the following transform products to convert data streams
from one format to another:
v Infoprint Transforms to AFP V2 for z/OS (5655-N60)
v Infoprint XT for z/OS (5655-O15)
v InfoPrint Transform Manager for Linux
The following transform products are no longer supported as of z/OS V2R1:
v Infoprint Transform for AFP to HP PCL V2 for z/OS (5655-P19)
v Infoprint Transform for AFP to Adobe PDF V2 for z/OS (5655-P20)
v Infoprint Transform for AFP to Adobe PostScript V2 for z/OS (5655-P21)
|
|
Version 1 Release 2 of the following transform products are now available and can
also be used to convert data streams from one format to another on z/OS V2R1 and
later releases:
v IBM Print Transform from AFP to PCL for Infoprint Server for z/OS (5655-TF2)
v IBM Print Transform from AFP to PDF for Infoprint Server for z/OS (5655-TF1)
v IBM Print Transform from AFP to PostScript for Infoprint Server for z/OS
(5655-TF3)
The transforms can convert (1) PCL, PostScript, PDF, SAP R/3, and Xerox print data
to AFP format for printing by PSF for z/OS V4 (5655-M32) on AFP printers, and (2)
AFP, line data, and XML data streams to PCL, PostScript, or PDF format for printing,
e-mailing, or presenting on the web.
|
|
The Infoprint Coaxial Printer Support for z/OS (5655-N62) for printing to
SNA-controlled printers is no longer supported as of z/OS V2R3.
|
|
|
The workstation operating system that is required to use the Infoprint Port Monitor
is Windows 7, Windows 8.1, Windows 10, Windows Server 2012, or Windows Server
2016.
Integrated Security Services
None.
ISPF
To use ISPF Software Configuration and Library Manager (SCLM), the z/OS Security
Server feature is recommended, but not required, to ensure data integrity.
For TCP/IP communication, ISPF Client/Server requires the IP Services component
of Communications Server on the host and one of the following operating systems on
the workstation, by using the TCP/IP included in the workstation operating system:
v Windows 7 or Windows 8
v IBM AIX® V6.1 with X11R6 Motif V1R2
Use of VSAM support (Edit/View/Browse) requires the File Manager for z/OS
product.
114
z/OS Planning for Installation
Table 13. Functions of z/OS V2R3 that require specific z/OS optional features or IBM products (continued)
z/OS element or feature
Required z/OS optional features or IBM products (by function)
JES2
To monitor and control jobs, output, devices, and system resources from TSO/E, you
need the z/OS SDSF feature.
To use Advanced Function Presentation, you need PSF for z/OS V4 (5655-M32).
Use of JES2 internal readers by CICS Transaction Server (CICS/TS) V3R1 (5655-M15)
requires PTF UK25148 (for APAR PK42184).
Use of Tivoli Workload Scheduler for z/OS (5698-A17) requires the JES2 PTF for
APAR PK85334.
Use of JES2 internal readers by CICS Transaction Server (CICS/TS) V3R2 (5655-M15)
requires PTF UK27691 (for APAR PK48550).
JES3
To monitor JES3 activity, z/OS RMF is required.
To use Advanced Function Presentation, you need PSF for z/OS V4 (5655-M32).
Language Environment
None.
Library Server
The IBM HTTP Server base element must be operational.
Use of extended shelf support requires XML Toolkit for z/OS V1R10 (5655-J51).
Indexing or reindexing of any type of shelf requires XML Toolkit for z/OS V1R10
(5655-J51).
|
|
Use of InfoCenter support requires XML Toolkit for z/OS V1R10 (5655-J51), plus IBM
31-bit SDK for z/OS, Java Technology Edition, V7.1 (5655-W43) or V8 (5655-DGG).
|
|
|
Use of the Java applet-based administrative interface requires XML Toolkit for z/OS
V1R10 (5655-J51), plus IBM 31-bit SDK for z/OS, Java Technology Edition, V7.1
(5655-W43) or V8 (5655-DGG).
To use the Java applet-based administrative interface, the client workstation must be
running a level of Java that equals or exceeds the level of Java running on the z/OS
server. Use of the original HTML-based administrative interface does not require Java
to be running on the client workstation, nor does it require Java to be running on the
z/OS server except when documentation stored as InfoCenters is being administered.
|
|
|
Metal C Runtime Library
None.
MICR/OCR
None.
NFS
NFS Client and NFS Server both require:
v z/OS Communications Server - IP Services
v z/OS Security Server feature
OSA/SF
To meet the SAF of the host operating system on which OSA/SF is running, the
z/OS Security Server feature is required.
To handle alerts that OSA reports when the SNA mode is active on an OSA and issue
OSA/SF for MVS commands from NetView, Tivoli NetView for z/OS V5R4
(5697-ENV) or later is required.
The z/OS RMF feature is required to obtain resource utilization data about OSA
channels.
To access OSA/SF at a workstation, use a workstation that supports Java 1.6 runtime
libraries. Interoperability testing with Windows 7 and Linux has been done. The
OSA/SF GUI for Windows is shipped in a single JAR file.
Appendix B. Software requirements for running z/OS V2R3
115
Table 13. Functions of z/OS V2R3 that require specific z/OS optional features or IBM products (continued)
z/OS element or feature
Required z/OS optional features or IBM products (by function)
RMF
The RMF Spreadsheet Reporter requires:
v Operating system: Windows 7.
v Spreadsheet program: To use the spreadsheet macros that are shipped with the
Spreadsheet Reporter, you can use one of the following Microsoft Excel products:
Excel 2007, Excel 2010, or Excel 2013.
RMF Performance Monitoring (RMF PM) requires:
v Operating system: Windows 7.
The RMF Client/Server requires:
v Host software: a z/OS Communications Server network connection from the
workstation to the host.
v Workstation software: An operating system that supports the z/OS ISPF
Client/Server.
Runtime Library Extensions
None.
SDSF
To use the SAF security feature of SDSF, the z/OS Security Server feature is required.
The z/OS RMF feature is required for users to do the following:
v Use the RMF support that is provided by the DA panel
v View sysplex-wide data on the DA panel
v View both the MVS and LPAR view of CPU use on the DA panel
v Use the Y action character to issue an MVS STOP command on the DA panel
v View IBM zIIP information on the DA panel
|
|
For sysplex-wide data in a JES2 environment, a service-supported level of WebSphere
MQ for z/OS is required on the panels CK, ENC, PS, and RM for JES2 systems.
Security Server
|
To run the RACF remove ID utility (IRRRID00) or the RACF report writer, the z/OS
DFSORT feature is required.
If you use DB2 to manage multilevel data, a supported DB2 level is required.
SMP/E
The SMP/E RECEIVE ORDER command requires the IBM 31-bit SDK for z/OS Java
Technology Edition V6.0 (5655-R31), or IBM 64-bit SDK for z/OS Java Technology
Edition V6.0 (5655-R32) or higher.
The RECEIVE FROMNETWORK command and the GIMZIP and GIMGTPKG service
routines require either the ICSF component of base element Cryptographic Services
to be operational, or the previously mentioned levels of Java.
|
|
TIOC
None.
TSO/E
For language support service or for TSO/E to save the user's console command
profile, the z/OS Security Server feature is required.
XL C/C++
None.
z/OS Security Level 3
To write application programs that use the DCE programming interface, you require
the z/OS XL C/C++ feature.
z/OS Font Collection
None.
z/OS OpenSSH
None.
z/OS UNIX
To write application programs that use the C or C++ language application
programming interface, you require the z/OS XL C/C++ feature.
3270 PC File Transfer
Program
Compatible 3270 terminal emulation software, such as IBM Personal
Communications/3270 and IBM Communications Manager/2, is required.
116
z/OS Planning for Installation
Appendix C. Additional hardware requirements for running
z/OS V2R3
Hardware requirements for a target system are discussed in “Identifying hardware requirements for the
target system” on page 63. Beyond these basic requirements, certain elements and features have
additional hardware requirements, as described in this topic.
Note: For more information about the requirements for a Parallel Sysplex, see the following references:
v z/OS MVS Setting Up a Sysplex
v Parallel Sysplex (www.ibm.com/systems/z/advantages/pso).
Table 14. Additional hardware requirements for z/OS V2R3 elements and features
z/OS element or feature
Additional hardware requirements for z/OS V2R3 elements and features
Alternate Library for REXX None.
BCP
Automatic tape switching requirements for 3480, 3490, 3590, or 3592 tape drives: A
single I/O device should have a single device number (defined through HCD) across
the entire sysplex, and that number should not be reused for any other device. For ease
of management, you should use the same device number on all systems to represent an
automatically switchable device. If an automatically switchable device is a 3480 without
the Read Configuration Data Capable function, you must use the same device number
on all systems. If you have not already applied C05566E, device numbers must be the
same.
Note: 3592 tape devices are defined through HCD as device type 3590-1, the same as
3590 devices.
Automatic IPL (autoIPL) requirement:
|
v The no-charge SCSI IPL hardware feature (#9904) is integrated on the IBM Z®
servers. That is, no features are required on the IBM z14™ (z14), z13, z13s™, zEC12, or
zBC12 servers.
v z/OS must be IPLed in order to detect the support.
Enablement of autoIPL in multisystem-capable sysplexes with SFM active: The use of
autoIPL in multisystem-capable sysplex configurations, where a sysplex failure
management (SFM) policy is active, is supported. With this support, requested autoIPL
actions are performed in accordance with the DIAGxx parmlib member, even when an
SFM policy is active in the sysplex.
Flash Express, which supports storage-class memory (SCM) on Flash Express cards as
optional auxiliary storage, is available on the z13 or z13s server, and on the zEC12 or
zBC12 server with FC #0402.
Global resource serialization: If any systems are in a global resource serialization ring
complex but not in the sysplex, global resource serialization requires basic mode CTCs
to communicate with those systems.
© Copyright IBM Corp. 2002, 2017
117
Table 14. Additional hardware requirements for z/OS V2R3 elements and features (continued)
z/OS element or feature
Additional hardware requirements for z/OS V2R3 elements and features
BCP (continued)
XCF (cross-system coupling facility) requirements in a sysplex configuration with one
central processor complex (CPC):
v Sysplex timing capability is not required. However, to provide timing for all
members of the sysplex, one of the following must be true:
– The sysplex is a single-system sysplex on one processor.
– The sysplex runs in multiple logical partitions on a single CPC.
– The sysplex runs as a set of VM guests on the same VM image.
v Unless your system is running in XCF-local mode, a sysplex couple data set is
required.
v If you have more than one system image in the sysplex, XCF signaling connectivity
is required between each system in the sysplex.
In a sysplex configuration with two or more central processor complexes (CPCs), XCF
requires all of the following:
|
|
|
v Sysplex timing capability that extends to all of the processors that contain any of the
z/OS or coupling facility images in the sysplex. The sysplex timing capability is
provided by the Server Time Protocol (STP) feature.
v Shared DASD for the sysplex couple data set. Certain functions require additional
couple data sets. For more information, see z/OS MVS Setting Up a Sysplex.
v XCF signaling connectivity between each system in the sysplex and every other
system in the sysplex.
This signaling connectivity can be established by using one of several methods. The
signaling mechanisms that are supported are:
– FICON or ESCON channels that are used as extended mode CTCs
– Coupling facility channels that are connected to a coupling facility with the use of
XCF signaling structures.
The use of Parallel Sysplex functions, such as data sharing, requires a Coupling Facility.
|
The IBM z Integrated Information Processor (zIIP) is a specialty engine for running
database workloads. Use of zIIP requires an IBM z14 (z14), z13, z13s, zEC12, or zBC12.
|
|
All supported z/OS releases support running zAAP-eligible work on a zIIP specialty
engine.
SMF record signing requires the CPACF feature.
|
BDT
None.
BDT File-to-File
None.
BDT SNA NJE
None.
BookManager READ
None.
CIM
None.
Communications Server
See “Hardware requirements for z/OS Communications Server” on page 125.
Communications Server
Security Level 3
If hardware cryptography is available, it is used by Communications Server Security
Level 3.
Notes:
|
|
|
|
|
v Use of hardware cryptography by Communications Server Security Level 3 requires
the Cryptographic Coprocessor hardware feature on the server
v Use of AES-CBC algorithms for IPSec requires the CPACF feature
v Use of algorithms other than DES, TDES, AES-CBC, MD5, and SHA1 requires ICSF
v Use of FIPS 140 mode requires ICSF.
118
z/OS Planning for Installation
Table 14. Additional hardware requirements for z/OS V2R3 elements and features (continued)
|
z/OS element or feature
Additional hardware requirements for z/OS V2R3 elements and features
Cryptographic Services
Cryptographic Services is supported on the following IBM Z servers: IBM z14 (z14),
z13, z13s, zEC12, zBC12, z196, z114, z10 EC, or z10 BC.
Specific functions in Cryptographic Services require additional hardware features, as
follows:
|
|
|
|
|
|
|
|
v For ICSF to provide cryptographic services, the Crypto Express feature is required.
The Crypto Express feature can be configured as a CCA coprocessor, accelerator, or a
PKCS #11 coprocessor. The PKCS #11 coprocessor is available on the zEC12, zEB12,
and later servers.
v For CCA secure key processing, the Crypto Express feature must be configured as a
CCA coprocessor. This is the default configuration.
v To enable clear key DES, TDES, and AES instructions, the CP Assist for
Cryptographic Functions (CPACF) feature is required.
DFSMSdfp
Catalog sharing enhancements (ECS) for Parallel Sysplex environments: To use this
function, a coupling facility is required.
Defining and accessing extended format sequential data sets: Extended format data sets
must reside on DASD attached through cached storage controls.
Extended address volumes (EAVs): To use this function, an IBM System Storage DS8000
with Licensed Machine Code (LMC) level 5.4.0xx.xx (bundle version 64.0.xx.xx) or later
is required.
Extended remote copy (XRC): When migrating data with XRC, the primary storage
device must be attached to an XRC-capable storage subsystem, such as an Enterprise
Storage Server with applicable feature licenses enabled.
Peer-to-peer remote copy (PPRC): When migrating data with PPRC, the primary and
secondary storage devices must be attached to a PPRC-capable storage subsystem, such
as an Enterprise Storage Server with applicable feature licenses enabled.
OAM File System support: To use a file system sublevel configured with an NFS file
system mounted in the z/OS UNIX hierarchy, an NFS server compatible with the z/OS
NFS client is required.
OAM Parallel Sysplex support: To use this OAM object support capability, coupling
facility hardware or a supported simulated environment is required.
OAM System Managed Tape Support: To use this support in an automated tape library
environment, an IBM automated tape library or an IBM Virtual Tape Library is
required. To use this support in a manual tape library environment, stand-alone tape
drives are required.
Storage management subsystem system groups: Some SMS complex configurations
might require DASD with enhanced connectivity. Because all systems in an SMS
complex share the configuration data sets, the ACDS and the COMMDS must reside on
DASD devices that are accessible to the system activating the configuration.
VSAM record level sharing (RLS): A coupling facility (at least one) must be connected
to all systems capable of VSAM RLS. For multiple coupling facilities, select one facility
with global connectivity to contain the master lock structure. The coupling facility must
be at control level 2. It must be large enough to contain either a lock or a cache
structure, or both, and have enough surplus space to allow the structures to be
modified. The cache structures must be defined to SMS to enable it for VSAM RLS.
WORM Tape Support: Requires the IBM 3592 Enterprise Tape System and WORM tape
media, or the logical WORM support in the IBM TS7700 Virtualization Engine.
Appendix C. Additional hardware requirements for running z/OS V2R3
119
Table 14. Additional hardware requirements for z/OS V2R3 elements and features (continued)
z/OS element or feature
Additional hardware requirements for z/OS V2R3 elements and features
DFSMSdss
Concurrent copy: To use this function, data must reside on DASD volumes that are
attached through a concurrent copy-capable storage subsystem.
Defining and accessing extended format sequential data sets through BSAM and
QSAM: Extended format data sets must reside on DASD attached through cached
storage controls and an ESCON or FICON channel adapter.
Fast replication: To use this function, you need DASD attached to a FlashCopy® capable
storage subsystem, such as DS8000.
DFSMShsm
Fast replication: To use this function, you need DASD attached to a FlashCopy capable
storage subsystem, such as DS8000.
DFSMSrmm
None.
DFSMStvs
None.
DFSORT
The use of High Performance FICON requires a zHPF-capable processor, zHPF-capable
FICON features, and zHPF-capable devices.
Distributed File Service
None.
EREP
None.
ESCON Director Support
None.
FFST
None.
GDDM
GDDM supports devices that use the 3270 Extended Data Stream, the architected
extensions to SNA character string (SCS), or IPDS. GDDM supports any other terminal
or terminal-attached printer and provides graphics and image functions if it is
upwardly compatible with the supported device.
GDDM host graphics are supported for viewing, printing, and plotting on IBM
Personal Communications/3270 V6 or later, or GDDM/MVS V3 download for
GDDM-OS/2 Link. For Microsoft Windows, use IBM Personal Communications/3270
V5 or later, which provides a native graphics emulator.
GDDM host graphics are supported on DOS for viewing and printing/plotting to
GDDM-PCLK supported devices through IBM Personal Communications/3270 V6 or
later, or a download of GDDM-PCLK from GDDM/MVS V3.
GDDM host graphics are supported for viewing on AIX terminals through the X3270
emulator or the TCP/IP GDDMXD facility.
GDDM-PGF
None.
GDDM-REXX
None.
HCD
None.
HCM
Hardware that can be used to establish a TCP/IP connection from the workstation to
the z/OS host is required.
Workstation requirements:
v Disk space: about 200 MB
v Color display with 1024 x 768 resolution
v Network adapter
Processing large configurations might require more disk space and might benefit from
more memory.
120
z/OS Planning for Installation
Table 14. Additional hardware requirements for z/OS V2R3 elements and features (continued)
z/OS element or feature
Additional hardware requirements for z/OS V2R3 elements and features
HLASM
To display or enter double-byte data, any of the following are required:
v DBCS 3270 emulation on RS/6000® or PS/55
v DBCS nonprogrammable terminal
To print double-byte data, any of the following are required:
v AFP printers
v 3270 remote printing on RS/6000 or PS/55
HLASM Toolkit
None.
IBM HTTP Server
A networked workstation with a web browser is required.
If hardware encryption is desired, cryptographic hardware is required.
IBM Knowledge Center for None.
z/OS
|
|
|
|
|
IBM TDS
None.
IBM z/OS Management
Facility (z/OSMF)
None.
ICKDSF
The commands ICKDSF INIT and REFORMAT support the VERIFYOFFLINE
functionality. This hardware support was provided in the following levels:
v DS8870 R7.1 GA, Bundle 87.10.87.0, LIC 7.7.10.287
v DS8700 R6.3 SP6, Bundle 76.31.79.0, LIC 6.6.31.670
v DS8800 R6.3 SP6, Bundle 86.31.95.0, LIC 7.6.31.1150.
|
|
DS8870 R7.1 GA, Bundle 87.10.87.0, LIC 7.7.10.287DS8700 R6.3 SP6, Bundle 76.31.79.0,
LIC 6.6.31.670DS8800 R6.3 SP6, Bundle 86.31.95.0, LIC 7.6.31.1150
Infoprint Server
|
|
|
|
Printer and connectivity requirements depend on the function to be performed:
v To print output with IP PrintWay, a printer that is connected by way of the z/OS
Communications Server base element (IP Services) is required. An IP connection
requires a printer that supports the LPR protocol, the IPP protocol, or TCP/IP direct
sockets.
v To print AFP data streams, an IPDS (Intelligent Printer Data Stream) printer that is
supported by PSF is required, with the appropriate hardware attachment (channel,
SNA, or TCP/IP) for the printer.
v Line data can be printed on any printer that is supported by JES2 or JES3.
v To receive LPR print requests from a remote host, a TCP/IP connection is required
from the remote host to the z/OS host.
|
|
|
|
A workstation capable of running Windows 7, Windows 8.1, Windows 10, Windows
Server 2012, or Windows Server 2016 is required to use the Infoprint Port Monitor. The
Infoprint Port Monitor also requires a TCP/IP connection from the workstation to the
z/OS host.
Integrated Security
Services
None.
ISPF
The ISPF base implementation requires a full-screen display terminal that supports
3270 data stream and provides a minimum interactive screen of 24 lines by 80
characters and a maximum interactive screen of 62 lines by 160 characters.
On the host, the ISPF Client/Server (ISPF C/S) implementation requires the following:
v A TCP/IP or APPC network connection from the workstation to the z/OS host
For the workstation, the ISPF C/S implementation requires either of the following:
v Any personal computer capable of running Windows 7 or Windows 8
v Any RS/6000 machine capable of running AIX Version 6.1 with a display device or
X-station capable of running Motif V1R2
Appendix C. Additional hardware requirements for running z/OS V2R3
121
Table 14. Additional hardware requirements for z/OS V2R3 elements and features (continued)
z/OS element or feature
Additional hardware requirements for z/OS V2R3 elements and features
JES2
A JES2 MAS with multiple z/OS images that use multiple central processors requires
the Server Time Protocol (STP) feature or a Sysplex Timer to synchronize time across
the processors.
JES3
A JES3 complex with multiple z/OS images that use multiple central processors
requires the Server Time Protocol (STP) feature or a Sysplex Timer to synchronize time
across the processors.
Language Environment
None.
Library Server
None.
Metal C Runtime Library
None.
MICR/OCR
None.
NFS
None.
OpenSSH for z/OS
None.
OSA/SF
OSA/SF requires an OSA. For more information, see z Systems OSA-Express Customer's
Guide and Reference.
Consider the following for levels of OSA/SF:
v OSA-1 is not supported on any IBM Z® server.
v OSA-2 is not supported on the zEC12 or zBC12 servers.
v OSA-Express features are not supported on the zEC12 or zBC12 servers.
OSA-Express2 features:
v The 1000Base-T Ethernet feature is only supported on the zEC12 server.
v The Gigabit Ethernet SX, Gigabit Ethernet LX, and 10 Gigabit Ethernet LR features
are only supported on the zEC12 server.
OSA-Express3 features:
v The Gigabit Ethernet SX, Gigiabit Ethernet LX, and 10 Gigabit Ethernet LR features
are only supported on the zEC12 and zBC12 servers.
OSA-Express4S features:
v The Gigabit Ethernet SX, Gigabit Ethernet LX, and 10 Gigabit Ethernet LR features
are supported only on the z13, z13s, and zEC12 servers.
|
v The 1000Base-T Ethernet feature is supported only on the IBM z14 (z14), z13, and
z13s servers.
OSA-Express5S features:
v The Gigabit Ethernet SX, Gigabit Ethernet LX, and 10 Gigabit Ethernet LR features
are supported only on the z13, z13s, and zEC12 servers.
|
v The 1000Base-T Ethernet feature is supported only on the IBM z14 (z14), z13, z13s,
zEC12, or zBC12 servers.
122
z/OS Planning for Installation
Table 14. Additional hardware requirements for z/OS V2R3 elements and features (continued)
z/OS element or feature
Additional hardware requirements for z/OS V2R3 elements and features
OSA/SF (continued)
Only 1000Base-T OSA features can be run in TCP/IP Passthru and SNA modes.
For z13, z13s, zEC12, or zBC12, servers, an OSA-Express2 1000Base-T Ethernet feature
is available as a replacement for the Fast Ethernet feature.
For z13, z13s, zEC12, or zBC12 servers, an OSA-Express3 1000Base-T Ethernet feature is
available as a replacement for the Fast Ethernet feature.
If the Windows (GUI) interface to OSA/SF is to be used, OSA/SF requires:
v A workstation with a Pentium 200 MHz (or equivalent) processor, 128 MB RAM, and
an SVGA display with a resolution of 1024x768x16 colors is recommended. You
might be satisfied with OSA/SF GUI performance on the minimum processor that is
required by your Windows operating system, but the GUI might not display
correctly at a lesser resolution.
v TCP/IP connectivity to the host system where OSA/SF is running.
RMF
The RMF workstation functions require a networked workstation with a web browser.
Runtime Library
Extensions
None.
SDSF
None.
Security Server
None.
SMP/E
None.
TIOC
None.
Appendix C. Additional hardware requirements for running z/OS V2R3
123
Table 14. Additional hardware requirements for z/OS V2R3 elements and features (continued)
z/OS element or feature
Additional hardware requirements for z/OS V2R3 elements and features
TSO/E
These requirements apply to interactive use of TSO/E, not to batch use. A terminal that
is supported by base element Communications Server is required. The full-screen
LOGON, TRANSMIT and RECEIVE commands, the Session Manager, and the
Information Center Facility, which need a minimum screen size of 24 by 80, require one
of the following terminals:
v IBM 3270 Information Display System Terminals
– 3275 Models 2 and 12
– 3276 Models 2, 3, 4, 12, 13, and 14
– 3277 Model 2
– 3278 Models 2, 3, 4, and 5 (monochrome)
– 3279 Models 2A, 2B, 2X, 3A, 3B, 3X, S2A, S2B, and S3G (base color mode)
v IBM 3472 Family
v IBM 3178 Display Terminal Models C1, C2, C3®, and C4
v IBM 3179 Display Terminal Model 1 and Model G (alphanumeric mode)
v IBM 3180 Display Terminal Models 100 and 110
v IBM 3191 Display Terminal Models A30, A40, B30, B40, D, E, and L
v IBM 3192 Color Display Terminal Models A, B, C, D, F, G, L, and W
v IBM 3194 Display Terminal
v IBM 3290 Information Panel
v IBM PS/2 family (configured for 3270 support)
v IBM Personal Computer (configured for 3278/79 support)
v IBM PS/55 family (configured for 3270 support)
v IBM 5550 family (configured for 3270 support)
v Any other terminal that functions in compatibility mode with the terminals in the
list.
The VM/PC servers (spool, disk, and file) available with the MVSSERV command
processor require the IBM Personal Computer Models XT/370 or AT/370 with an IBM
3278/79 Device Emulation Adapter.
|
|
|
|
|
|
|
z/OS V2R3 is the last release of z/OS to support the Server-Requester Programming
Interface (SRPI). This API was introduced in TSO/E in the 1980s to provide a
programming interface that enhances the environment of IBM workstations
communicating with IBM mainframes running z/OS. If your applications use SRPI,
IBM recommends that you migrate to TCP/IP for z/OS to for similar function. For
reference, see IBM United States Software Announcement 217-085, "IBM z™/OS Version
2 Release 3—Engine for digital transformation" dated February 21, 2017.
XL C/C++
Running code that is compiled with specific ARCH and TUNE levels requires
processors that support the instructions that the compiler uses when they are specified.
For more information, see z/OS XL C/C++ User's Guide.
z/OS Font Collection
None.
124
z/OS Planning for Installation
Table 14. Additional hardware requirements for z/OS V2R3 elements and features (continued)
z/OS element or feature
Additional hardware requirements for z/OS V2R3 elements and features
z/OS UNIX
The extended user interface support allows existing hardware (such as terminals and
workstations) and existing telecommunications software (such as VTAM and TCP/IP)
that run on z/OS to be used.
For 3270 support, most 3270 type terminals or 3270 emulators in a z/OS network from
which a user can interactively log on to TSO/E are supported by z/OS UNIX services
and include:
v Real and emulated 3270s in a VTAM SNA network, which satisfy the following
requirements:
– The minimum screen size is 24x80.
– The terminal must be known to TSO/E and VTAM as a full-screen device. z/OS
UNIX services use full-screen mode.
– The terminal must support uppercase and lowercase characters.
– A minimum of 12 PF keys are required.
v UNIX workstations and other workstations in a TCP/IP network that supports the
TELNET 3270 (TN3270) client function.
v The OMVS command supports customized PF keys to scroll backward/forward,
display HELP, hide input that is typed into the command line, refresh the screen,
retrieve previous commands, and enter TSO/E commands.
For ASCII control sequence support from 3270 displays, the OMVS command, with the
pseudoterminal functions, maps and transforms a 3270 TSO/E terminal interface and
user externals to the POSIX 1003.1 defined terminal interface that is expected by POSIX
compliant user processes, including the POSIX 1003.2 Shell. This mapping consists of:
v Use of 3270 key sequences to emulate ASCII terminal control is supported.
A set of system-defined 3270 default key sequences that map to ASCII escape control
values is supplied. The user can tailor the system defaults.
v Execution in canonical (line-oriented) mode only.
v Conversion tables that map the 3270 data stream to a pseudoterminal device driver
for both control and data are provided. Users can customize these tables.
For ASCII terminal interface, UNIX workstations and other workstations in a TCP/IP
network that support the telnet or rlogin virtual terminal protocols can login directly to
the z/OS shell through Communications Server. The supported ASCII terminal
interface conforms to X/OPEN Issue 4, Version 2.
3270 PC File Transfer
Program
An IBM or compatible PC with appropriate communications device, such as a LAN
adapter or modem, is required.
Hardware requirements for z/OS Communications Server
Hardware requirements for z/OS Communications Server are described in the following sections:
v “IP hardware requirements”
v “SNA hardware requirements” on page 127.
IP hardware requirements
Communications Server provides direct LAN communication and provides for point-to-point
communication over S/390 channels (ESCON or Block Multiplex) to several IBM and equivalent other
vendor devices.
v Direct LAN communication is provided by IBM Open Systems Adapter - Express.
v Point-to-point communication over IBM Z® channels is supported by the following devices:
– IBM RS/6000
Appendix C. Additional hardware requirements for running z/OS V2R3
125
– IBM Channel-to-Channel Adapter.
| An IBM z14 (z14), z13, z13s, zEC12, or zBC12 server is required to use the following functions:
v Support for z/OS Communications Server for intra ensemble networks
v OSA-Express4S QDIO IPv6 checksum and segmentation offload.
| An IBM z14 (z14), z13, z13s, zEC12, or zBC12 server is required to use the following functions:
v OSA-Express optimized latency mode
v OSA-Express inbound workload queueing
v Support for z/OS Communications Server for intra ensemble networks.
| An IBM z14 (z14), z13, z13s, zEC12, or zBC12 server is required to use the following functions:
v OSA-Express network traffic analyzer
v OSA-Express virtual MAC
v QDIO diagnostic synchronization
v QDIO support for OSA interface isolation.
| An IBM z14 (z14), z13, z13s, zEC12, or zBC12 server is required to use the following functions:
v ICSF encryption/decryption instructions, called crypto assist, which provide synchronous clear key
support for DES, TDES, and SHA-1 algorithms for IPSEC.
v The checksum offload of IPv4 packets enhancement. An OSA-Express with a supporting level of
microcode is also required.
v IPv4 Broadcast support for HiperSockets.
v Segmentation Offload (Large Send). An OSA-Express with a supporting level of microcode is also
required.
Network attachments
To attach TCP/IP to the network, you require one of the following network processors and associated
components or their equivalents:
IBM RISC System/6000 Channel Attachment:
v To attach to the RISC System/6000 using MPCPTP, the following items are required:
– AIX 4.3 (or later)
– PCI ESCON Control Unit Connectivity Version 2.1
IBM Open Systems Adapter (OSA) Feature:
| v OSA-Express2 supporting Gigabit Ethernet, 10 Gigabit Ethernet, and 1000Base-T Ethernet connections
|
on the zEC12 and zBC12 servers.
| v OSA-Express3 supporting Gigabit Ethernet and 10 Gigabit Ethernet, and 1000Base-T connections, on
|
the zEC12 and zBC12 servers.
|
v OSA-Express4S supporting Gigabit Ethernet and 10 Gigabit Ethernet, and 1000Base-T connections, on
the z13, z13s, zEC12, and zBC12 servers. Supporting 1000BaseT connections on the IBM z14™ (z14).
v OSA-Express5S supporting Gigabit Ethernet and 10 Gigabit Ethernet, and 1000Base-T connections, on
the z13, z13s, zEC12, and zBC12 servers.
| v OSA-Express6S supporting 10 Gigabit Ethernet on the z14 server.
OSA Direct SNMP subagent support requires a server with the OSA-Express feature running in QDIO
mode (OSD) or non-QDIO mode (OSE). It is available on all servers supported by z/OS. For information
about the level of each server that is required for this support, see z Systems OSA-Express Customer's Guide
and Reference.
126
z/OS Planning for Installation
|
|
IBM RoCE Express feature:
v RoCE Express supporting 10GbE Ethernet (used with SMC-R) on zEC12, zBC12, z13, and z13s servers.
|
v RoCE Express2 supporting 10GbE Ethernet (with SMC-R) on an IBM z14 (z14) server.
|
|
Internal Shared Memory (ISM):
v ISM is a virtual PCI feature (used with SMC-D) on a z13 (GA2) or z13s or IBM z14 (z14) server.
Miscellaneous IP hardware requirements
IPv6 support requires the following:
|
|
v OSA-Express2, OSA-Express3, OSA-Express4S, OSA-Express5S, or OSA-Express6S feature defined for
QDIO mode (OSD)
v Multipath channel point-to-point (MPCPTP) Data Link Control (DLC), which might carry IPv6 traffic
over ESCON/FICON, XCF links, and IUTSAMEH.
|
Use of HiperSockets IPv6 support requires at a minimum an IBM z13, z13s, or zEnterprise server.
|
Use of HiperSockets multiple write facility requires at a minimum a z13 or z13s server.
SNA hardware requirements
For communication with remote resources, one or more of the following products, or their equivalent, is
required:
v Channel-to-channel adapter
v FICON channel-to-channel adapter
v IBM Cross-System Coupling Facility (XCF)
v IBM Enterprise System Connection (ESCON) channel
v IBM Open Systems Adapter-Express.
SNA triple DES (TDES) session level encryption requires a Cryptographic Coprocessor on the server.
Appendix C. Additional hardware requirements for running z/OS V2R3
127
128
z/OS Planning for Installation
Appendix D. Making a copy of your system software (cloning)
This topic describes how to make a copy of the system software in the z/OS product set, also known as a
“clone”), on different DASD volumes with different volume serials.
After you finish installing z/OS, you need to make a copy of it (“clone” it). Some reasons:
v Backup: A backup copy is a copy of the z/OS product set (z/OS and other products you are installed
on the same set of volumes using the same SMP/E zones) that meet the following criteria:
– Resides on different volumes with different volume labels
– Includes copies of the associated SMP/E zones with different names that point to the data sets on
the new volumes
– Includes copies of the associated catalogs with different names
– After making the copy, and doing the necessary setup, you can IPL it in place of the original copy.
v Move: To move the software to another system.
v Copy: To create another SMP/E serviceable copy for installing service or other products.
To make a copy, you must do a number of tasks depending on how your system has been configured. In
addition, many of the tasks can be done using different techniques, and differing local standards and
practices add more variations to the process. Some of the factors that can affect the way that you copy
your system are:
v Catalog sharing boundaries (such as whether shared master catalogs are in use)
v Use of direct, indirect, or extended indirect catalog referencing
v Local versus central maintenance
v System software volume sharing boundaries and their relationship to catalog and sysplex boundaries
v Naming conventions
v Whether new data sets affect the existing environment
v Testing and migration procedures
v Whether the copy is used in an existing environment or a new one.
The information in this topic is based on the system layout that is described in “Recommended data set
placement” on page 85. However, you might find this information useful even if your system is
configured differently. The techniques that are shown here are designed to minimize the amount of work
that is required to migrate software into existing environments that use the recommended system layout.
They make a complete copy of the software that can be serviced using SMP/E.
The following SYS1.SAMPLIB jobs are referred to in this topic:
v IEACLNIN, which initializes volumes
v IEACLNSM, which converts an HFS or zFS volume to SMS management
v IEACLNCS, which defines catalogs and creates CSI data sets
v IEACLNCV, which copies volumes
v IEACLNMT, which creates a mount point directory and mounts the HFS or zFS at it
v IEACLNCZ, which copies zones
If you are migrating your software to another system and you use the same volume, catalog, and data set
names, you need only one of the procedures in this topic. Use the full-volume physical dumps and
restores to make the copy, and then follow the steps in “Migrating to another system” on page 135.
© Copyright IBM Corp. 2002, 2017
129
Note: Before cloning z/OS, you must have a license for each z/OS operating system that you run. For
details, see “Installing z/OS without using an installation package” on page 40.
Choosing names
The first step in preparing to make a copy of your system is choosing new names. You must choose new
names for:
v The new DASD volumes that will be the target of the copy:
– The IPL volume (TVOL1)
– The second and any other target library volumes (TVOL2-n)
– The HFS or zFS volume
– The DLIB volumes, if you are also copying the distribution libraries
Choose names that allow you to define system symbols for each target volume based on the name of
the IPL volume. For example, the name for TVOL1 might be OS260 and the name for TVOL2 might be
OS260X, using the scheme OSrrr for TVOL1 and OSrrrX for TVOL2, where rrr is a level identifier and
the system symbols are &SYSR2.=’&SYSR1(1:5).X’.
v User catalogs to manage the VSAM files, HFS files, zFS files, and DLIB data sets. These catalogs are:
– One for the second target library volume (TVOL2), to own the target zone CSI data set and any
MMS-compiled VSAM files
– One for the HFS or zFS volume, to own the HFS or zFS data sets
– One for the first DLIB volume, to catalog the distribution libraries.
Choose names using a convention that avoids having two catalogs with the same name in the same
catalog environment at the same time. IBM recommends that you choose a naming convention based
on the volume serial of a TVOLn volume. You should pick one or more installation-wide high-level
qualifiers and reserve them for catalog naming. This prevents catalog names from conflicting with any
existing alias entry names. One example of such a convention is USERCAT.volser. In this example, the
high-level qualifier USERCAT is reserved for naming catalogs.
v The SMP/E CSI data sets and SMP/E zones:
– Target zone CSI data set
– DLIB zone CSI data set
– Target zone
– DLIB zone
You should choose the CSI data set names using different high-level qualifiers because they will be
cataloged in different catalogs. You must pick currently-unused high-level qualifiers to be able to
define them as aliases in the newly defined user catalog. IBM recommends that you choose a high-level
qualifier for CSI data set names based on the volume serial of a TVOLn volume. For example, you
might use OS26TZ.CSI as the name of a target zone CSI data set.
v MMS data sets.
If you use MMS data sets, you should choose their names using different high-level qualifiers because
they will be cataloged in different catalogs. You must pick currently-unused high-level qualifiers to be
able to define them as aliases and access the MMS data sets. The high-level qualifier you choose can be
defined as a system symbol to avoid other parmlib changes.
IBM recommends that you choose a high-level qualifier for MMS data sets that is derived from the
volume serial of a TVOLn volume. If you do, you will be able to define a single symbol for all MMS
data sets in the z/OS product set that will not need to be updated in the future. For example, if:
– the MMS data sets are placed on TVOL2
– and the name of TVOL2 is derived from the name of TVOL1 (by defining a system symbol for
TVOL2 based on a substring of the system-supplied symbol for the IPL volume label)
– and you choose a high-level qualifier based on the name of TVOL2 for the MMS data sets
130
z/OS Planning for Installation
then you can define a system symbol based on the name of TVOL2 in an IEASYMxx member of
parmlib. This symbol would be resolved to the high-level qualifier you used, and could be used as part
of the data set name in an MMSLSTxx member of parmlib to allocate the MMS data sets associated
with the IPL volume.
v HFS or zFS data sets.
HFS and zFS data sets can be optionally SMS-managed. They must be cataloged and their names must
be unique within the file system structure in order to be mounted. In the IBM cloning samples, the
HFS and zFS data sets are SMS-managed.
v Distribution libraries.
You can choose to use volume serials on the DLIB zone DDDEFs, or to name the data sets differently
and locate them through the user catalog on the first DLIB volume. If you choose to locate them by
name using the catalog, you must rename them using a new high-level qualifier.
Initializing the new volumes
To initialize the new volumes, use ICKDSF. See the IEACLNIN job in SYS1.SAMPLIB.
The size and location of the VTOCs specified will be changed on some of the new volumes by
full-volume copy operations when sizes and locations of the VTOCs on the volumes they are copied from
are different. The VTOC size and location remains as specified for new volumes that are not copied using
full-volume physical copy.
Setting up SMS
Because SMS must be active and the HFS or zFS data sets must be cataloged in order to mount the HFS
or zFS, some SMS setup is needed to prepare for copying the HFS or zFS volumes. The IEACLNSM job
in SYS1.SAMPLIB does a DFSMSdss CONVERTV to convert the volume to an SMS-managed volume.
The first step creates a VTOC index, which is required for all SMS-managed volumes. The second step
converts the volume to an SMS-managed volume. Access to the STGADMIN.ADR.CONVERTV FACILITY
class profile or to a higher-level profile (such as STGADMIN.*) is required to run CONVERTV.
Defining new catalogs and CSI data sets
The next step in making the copy is allocating new user catalogs to manage the VSAM files, HFS or zFS
files, and distribution libraries. The IEACLNCS job in SYS1.SAMPLIB defines three user catalogs:
v A user catalog on TVOL2 to own the SMP/E target zone CSI data set and MMS data sets
v A user catalog on the HFS or zFS volume to own the HFS or zFS
v A user catalog on the first DLIB volume to manage the DLIB zone CSI data set and distribution
libraries.
The user catalogs are defined using IDCAMS commands. These catalogs will not contain a large number
of entries, so it is not necessary to allocate very much space for them.
Alias entries are defined to relate the new high-level qualifiers you chose for the VSAM files, HFS or zFS
files, and distribution libraries to the new catalogs. This will establish the new catalogs as the owning
catalogs for the VSAM and HFS or zFS files, making the volumes with their catalogs and data sets
portable to other systems.
Next, new CSI data sets are defined, using the source data sets as models for allocating the new ones.
Because SMP/E CSI data sets must be initialized with the GIMZPOOL record before SMP/E can process
them, both must be primed using the REPRO command:
Appendix D. Making a copy of your system software (cloning)
131
Copying the software data sets
The previous steps created the environment needed to copy the data on the z/OS volumes. All the data
except that in the SMP/E CSIs is copied using DFSMSdss. The job in SYS1.SAMPLIB for copying
volumes is IEACLNCV.
The PARALLEL parameter is used to let DFSMSdss multitask the copy and dump operations so they can
be done more quickly. The SERIAL parameter is used to make sure that the HFS or zFS volume dump
completes before the HFS or zFS volume restore.
Access to the STGADMIN.ADR.STGADMIN.COPY FACILITY class profile, or to a higher-level profile
(such as STGADMIN.*), is required to use the ADMINISTRATOR keyword. If you do not use the
ADMINISTRATOR keyword, UPDATE or higher access to all the data sets on the volume is required.
The data on each volume is copied differently, depending on the volume being copied and its content:
v Because TVOL1 has no VSAM or SMS-managed data sets, it can be copied using full-volume physical
copy.
Note: Physical copy preserves the IPL text on TVOL1, so no steps are needed to replace it. If you are
copying the system software between volumes on different device types, you will need to use
copy-by-data-set rather than full-volume copy. Copy-by-data-set does not preserve the IPL text, so you
have to replace the IPL text whenever you copy TVOL1 to a different device type.
v TVOL2 contains a user catalog and VSAM data sets (the target zone CSI data set and any
MMS-compiled data sets). It is copied by data set, excluding the user catalog, VTOC Index, SMP/E
target zone CSI data set, and VSAM Volume Data Set (VVDS). The VSAM data sets are renamed using
the new high-level qualifiers you chose.
The SMP/E CSI data sets are copied later using SMP/E commands.
Note: The RECATALOG parameter catalogs all the data sets during the copy of TVOL2 in the user
catalog on TVOL2. However, only the SMP/E CSI, SMP/E non-VSAM, and MMS-compiled data sets
will actually be accessed using this catalog, because extended indirect cataloging is used to find them
in the normal catalog search order.
v The HFS or zFS data sets are logically copied in the IEACLNCV sample job, and given a new name.
Starting with z/OS V1R12, zFS data sets can be indirectly cataloged and do not necessarily require a
new name. To use this support, you must do a physical copy of the zFS data set (not a logical copy).
Here is an example of doing a physical copy of a zFS data set, which you intend to have cataloged
indirectly:
//STEPS01 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
COPY DATASET(INC(ZFS.ROOT)) PHYSINDYNAM ( (OLDZFS) ) OUTDYNAM ( (NEWZFS) ) ALLDATA(*)
/*
Doing a physical copy of the zFS data set will result in a new data set with the same name as the
source data set, but currently uncataloged. In order to subsequently catalog the zFS data set into the
target system's catalog, you can use sample JCL like the following where &zfsvl is a system symbolic
that has been defined in IEASYMxx parmlib member with the actual volume serial:
//CATZFS EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE CLUSTER (NAME(ZFS.ROOT) -
132
z/OS Planning for Installation
LINEAR VOLUMES(&zfsvl) RECATALOG)
/*
For more information on indirectly cataloged zFS data sets, see z/OS DFSMS Managing Catalogs. Keep
in mind that all HFS or zFS data sets associated with a particular system should be cloned. This
includes the root as well as the /etc and /var file systems. When your cloned system is IPLed, you
will also need unique /dev and /tmp file systems.
v The first DLIB volume is copied by data set, similar to the way TVOL2 is copied, because it contains
the DLIB zone CSI data set and user catalog. Its data sets are renamed during the copy using the new
high-level qualifier you chose. If you prefer not to rename the data sets, remove the RENAMEU
parameter.
v The second DLIB volume is copied by data set. Its data sets are renamed during the copy using the
new high-level qualifier you chose. If you prefer not to rename the data sets, remove the RENAMEU
parameter.
Note: The RECATALOG parameter catalogs all the data sets during the copies of the DLIB volumes in
the user catalog on DLIB1. However, only the SMP/E CSI and SMP/E non-VSAM data sets will
actually be accessed using this catalog.
If you are making a clone for the purpose of creating an SMP/E-serviceable copy, make the HFS or zFS
files accessible by mounting the file systems at the mount point you chose. To do this, you must first
create the directory by issuing the MKDIR command. For example, you could issue mkdir /service to
create a directory named service. Then, you could issue MOUNT commands from a TSO user ID to
mount the file systems. The user ID must have superuser authority (either UID(0) or READ access to an
applicable RACF UNIXPRIV class profile) to issue the MOUNT command. For more information about
the MKDIR and MOUNT commands, see z/OS UNIX System Services Command Reference. For a sample job,
see IEACLNMT in SYS1.SAMPLIB.
Copying the SMP/E zones
The SMP/E zones are copied using ZONECOPY rather than IDCAMS REPRO so that both the zones and
the CSI data sets can be renamed. This makes it possible to use both the old and new target and DLIB
zones with a single global zone. The IEACLNCZ job in SYS1.SAMPLIB shows how to do a ZONECOPY.
Before the zones are copied, the global zone's ZONEINDEX entry must be updated with the new CSI
data set and zone names.
Next, the zones are copied using ZONECOPY commands. Because the SMP/E boundary is already set to
do the ZONECOPY, the ZONEEDIT commands to change the DDDEFs to reflect new volume serials (and
data set names, for the DLIB zone) can be issued at the same time.
If you have copied an existing cataloged data set that does not have the VOLUME defined to the new
target system using the same name, you must use an ADD DDDEF for the new target data set. If this is
not done, the new code will be installed into the existing cataloged data set and not the new target data
set.
REP TARGETZONE(newtgt) RELATED(newdlb) is an optional command, to be added only if the DLIBs
and DLIB zone will be copied at the same time as the target libraries and zone.
As a rule, you should not install service or products on the same copy of the system software that the
system is using. This includes those parts of the system software that reside in an HFS or zFS. The way
to update a copy of an HFS or zFS is to mount it on another mount point. The system will continue to
use its own level of the HFS or zFS, and the copy will be accessible using the other mount point.
Appendix D. Making a copy of your system software (cloning)
133
Before making any updates to the copy with SMP/E, you should change the HFS or zFS path DDDEFs to
point to another directory, usually called a service directory, and mount the copy's HFS or zFS on that
directory's mount point. This assures that SMP/E will update the correct HFS or zFS when products and
service are installed.
To change the DDDEFs, use the SMP/E ZONEEDIT command. For example, the following commands
will add /service to the beginning of all HFS or zFS paths:
SET BDY(NEWTGT) .
ZONEEDIT DDDEF .
CHANGE PATH(*,’/service’*) .
ENDZONEEDIT .
Note that the HFS or zFS remains usable for backup no matter where the DDDEFs point. If you IPL
using a BPXPRMxx member that mounts the copy's HFSs or zFSs at their normal mount points (not the
service mount points), the system will function normally. The DDDEFs only affect where SMP/E searches
for or stores parts that reside in an HFS or zFS.
For more information about servicing elements in the HFS or zFS, see the topic about installing service
into the hierarchical file system in z/OS UNIX System Services Planning.
Making the copy usable
After you have completed the preceding steps, you have a backup copy of the z/OS product set. If you
have used the recommended system layout (described in “Recommended data set placement” on page
85), used indirect and extended indirect cataloging (described in “Using indirect catalog entries” on page
98), used a consistent TVOLn naming convention that lets you use system symbols to derive the names of
TVOL2-n, and avoided the use of explicit volume serials in the link, LPA, and APF lists, there should be
very few other actions you need to take to use the copy as a backup suitable for IPL. Because the SMP/E
zones were copied with the software, you can also query the level of any SMP/E-maintained part of this
copy of the system at any time.
The one thing you will have to do is create another BPXPRMxx member of parmlib to point to the new
HFS or zFS data sets.
If you have not followed these recommendation, you will have additional work to do. For example:
v If you did not use indirect cataloging, you need to create a copy of the master catalog to IPL with the
new backup volumes. For information about creating a copy of your master catalog, see z/OS DFSMS
Managing Catalogs.
v If you coded volume serials for z/OS product set volumes in the link, LPA, or APF lists, you need to
create new parmlib members.
v If your clone is for a new image, you need to copy image-related data sets. See “Image-related data
sets” on page 92 for information.
v If your clone is for a sysplex, you need to copy sysplex-related data sets. See “Cluster-related data sets”
on page 93 for information.
Testing
Never assume that the backup copy will work until it has been tested. Schedule a test time on the system
to be backed up to make sure that the copying process was successful and that backup procedures work.
If this is not possible, a slightly more risky alternative is using a test system with copies of the
production system's operational data sets.
134
z/OS Planning for Installation
Migrating to another system
Note!
This section only lists actions you need to take to move a copy of software from one system to another. It
does not list the actions needed to install and migrate new levels of software. For that information, see
other documentation such as z/OS Migration.
If you want to move the copy to another system that also uses the recommended system layout, there are
only a few things to do:
v If you chose to SMS-manage your HFS or zFS data sets, define the HFS or zFS volume to SMS on the
other system if the volume is not in the same SMS-plex. You can define the HFS or zFS volume using
ISMF, the same way it was defined in “Setting up SMS” on page 131.
v Import the user catalogs and define the data set aliases if the target system for migration is not sharing
its master catalog with the system from which you made the copy.
v Create a new BPXPRMxx member on the other system. It should specify the ZFS or HFS file system
type, as appropriate.
Copy the active BPXPRMxx member to a new member. Update the ROOT FILESYSTEM and MOUNT
FILESYSTEM statements as needed.
v Install any system-specific usermods. Also, install any system-specific exits that cannot be installed
separately from the system software.
v Specify the master catalog name in LOADxx rather than in SYSCATxx members of the NUCLEUS data
set. This is IBM's recommendation. However, if you choose to specify it using SYSCATxx, you must
add or update this member to reflect the name of the intended image's master catalog.
To import the user catalogs and define the aliases, use IDCAMS:
IMPORT CONNECT OBJECTS((usercat.newfs VOLUMES(newfs) DEVT(3390)))
IMPORT CONNECT OBJECTS((usercat.newtv2 VOLUMES(newtv2) DEVT(3390)))
IMPORT CONNECT OBJECTS((usercat.newdl1 VOLUMES(newdl1) DEVT(3390)))
DEFINE ALIAS (NAME(fsnew) RELATE (usercat.newfs))
DEFINE ALIAS (NAME(newtarg) RELATE (usercat.newtv2))
DEFINE ALIAS (NAME(newmms) RELATE (usercat.newtv2))
DEFINE ALIAS (NAME(newdlib) RELATE (usercat.newdl1))
Appendix D. Making a copy of your system software (cloning)
135
136
z/OS Planning for Installation
Appendix E. Accessibility
Accessible publications for this product are offered through IBM Knowledge Center (www.ibm.com/
support/knowledgecenter/SSLTBW/welcome).
If you experience difficulty with the accessibility of any z/OS information, send a detailed message to the
Contact z/OS web page (www.ibm.com/systems/z/os/zos/webqs.html) or use the following mailing
address.
IBM Corporation
Attention: MHVRCFS Reader Comments
Department H6MA, Building 707
2455 South Road
Poughkeepsie, NY 12601-5400
United States
Accessibility features
Accessibility features help users who have physical disabilities such as restricted mobility or limited
vision use software products successfully. The accessibility features in z/OS can help users do the
following tasks:
v Run assistive technology such as screen readers and screen magnifier software.
v Operate specific or equivalent features by using the keyboard.
v Customize display attributes such as color, contrast, and font size.
Consult assistive technologies
Assistive technology products such as screen readers function with the user interfaces found in z/OS.
Consult the product information for the specific assistive technology product that is used to access z/OS
interfaces.
Keyboard navigation of the user interface
You can access z/OS user interfaces with TSO/E or ISPF. The following information describes how to use
TSO/E and ISPF, including the use of keyboard shortcuts and function keys (PF keys). Each guide
includes the default settings for the PF keys.
v z/OS TSO/E Primer
v z/OS TSO/E User's Guide
v z/OS ISPF User's Guide Vol I
Dotted decimal syntax diagrams
Syntax diagrams are provided in dotted decimal format for users who access IBM Knowledge Center
with a screen reader. In dotted decimal format, each syntax element is written on a separate line. If two
or more syntax elements are always present together (or always absent together), they can appear on the
same line because they are considered a single compound syntax element.
Each line starts with a dotted decimal number; for example, 3 or 3.1 or 3.1.1. To hear these numbers
correctly, make sure that the screen reader is set to read out punctuation. All the syntax elements that
© Copyright IBM Corp. 2002, 2017
137
have the same dotted decimal number (for example, all the syntax elements that have the number 3.1)
are mutually exclusive alternatives. If you hear the lines 3.1 USERID and 3.1 SYSTEMID, your syntax can
include either USERID or SYSTEMID, but not both.
The dotted decimal numbering level denotes the level of nesting. For example, if a syntax element with
dotted decimal number 3 is followed by a series of syntax elements with dotted decimal number 3.1, all
the syntax elements numbered 3.1 are subordinate to the syntax element numbered 3.
Certain words and symbols are used next to the dotted decimal numbers to add information about the
syntax elements. Occasionally, these words and symbols might occur at the beginning of the element
itself. For ease of identification, if the word or symbol is a part of the syntax element, it is preceded by
the backslash (\) character. The * symbol is placed next to a dotted decimal number to indicate that the
syntax element repeats. For example, syntax element *FILE with dotted decimal number 3 is given the
format 3 \* FILE. Format 3* FILE indicates that syntax element FILE repeats. Format 3* \* FILE
indicates that syntax element * FILE repeats.
Characters such as commas, which are used to separate a string of syntax elements, are shown in the
syntax just before the items they separate. These characters can appear on the same line as each item, or
on a separate line with the same dotted decimal number as the relevant items. The line can also show
another symbol to provide information about the syntax elements. For example, the lines 5.1*, 5.1
LASTRUN, and 5.1 DELETE mean that if you use more than one of the LASTRUN and DELETE syntax elements,
the elements must be separated by a comma. If no separator is given, assume that you use a blank to
separate each syntax element.
If a syntax element is preceded by the % symbol, it indicates a reference that is defined elsewhere. The
string that follows the % symbol is the name of a syntax fragment rather than a literal. For example, the
line 2.1 %OP1 means that you must refer to separate syntax fragment OP1.
The following symbols are used next to the dotted decimal numbers.
? indicates an optional syntax element
The question mark (?) symbol indicates an optional syntax element. A dotted decimal number
followed by the question mark symbol (?) indicates that all the syntax elements with a corresponding
dotted decimal number, and any subordinate syntax elements, are optional. If there is only one syntax
element with a dotted decimal number, the ? symbol is displayed on the same line as the syntax
element, (for example 5? NOTIFY). If there is more than one syntax element with a dotted decimal
number, the ? symbol is displayed on a line by itself, followed by the syntax elements that are
optional. For example, if you hear the lines 5 ?, 5 NOTIFY, and 5 UPDATE, you know that the syntax
elements NOTIFY and UPDATE are optional. That is, you can choose one or none of them. The ? symbol
is equivalent to a bypass line in a railroad diagram.
! indicates a default syntax element
The exclamation mark (!) symbol indicates a default syntax element. A dotted decimal number
followed by the ! symbol and a syntax element indicate that the syntax element is the default option
for all syntax elements that share the same dotted decimal number. Only one of the syntax elements
that share the dotted decimal number can specify the ! symbol. For example, if you hear the lines 2?
FILE, 2.1! (KEEP), and 2.1 (DELETE), you know that (KEEP) is the default option for the FILE
keyword. In the example, if you include the FILE keyword, but do not specify an option, the default
option KEEP is applied. A default option also applies to the next higher dotted decimal number. In
this example, if the FILE keyword is omitted, the default FILE(KEEP) is used. However, if you hear
the lines 2? FILE, 2.1, 2.1.1! (KEEP), and 2.1.1 (DELETE), the default option KEEP applies only to
the next higher dotted decimal number, 2.1 (which does not have an associated keyword), and does
not apply to 2? FILE. Nothing is used if the keyword FILE is omitted.
* indicates an optional syntax element that is repeatable
The asterisk or glyph (*) symbol indicates a syntax element that can be repeated zero or more times.
A dotted decimal number followed by the * symbol indicates that this syntax element can be used
138
z/OS Planning for Installation
zero or more times; that is, it is optional and can be repeated. For example, if you hear the line 5.1*
data area, you know that you can include one data area, more than one data area, or no data area. If
you hear the lines 3* , 3 HOST, 3 STATE, you know that you can include HOST, STATE, both together,
or nothing.
Notes:
1. If a dotted decimal number has an asterisk (*) next to it and there is only one item with that
dotted decimal number, you can repeat that same item more than once.
2. If a dotted decimal number has an asterisk next to it and several items have that dotted decimal
number, you can use more than one item from the list, but you cannot use the items more than
once each. In the previous example, you can write HOST STATE, but you cannot write HOST HOST.
3. The * symbol is equivalent to a loopback line in a railroad syntax diagram.
+ indicates a syntax element that must be included
The plus (+) symbol indicates a syntax element that must be included at least once. A dotted decimal
number followed by the + symbol indicates that the syntax element must be included one or more
times. That is, it must be included at least once and can be repeated. For example, if you hear the line
6.1+ data area, you must include at least one data area. If you hear the lines 2+, 2 HOST, and 2
STATE, you know that you must include HOST, STATE, or both. Similar to the * symbol, the + symbol
can repeat a particular item if it is the only item with that dotted decimal number. The + symbol, like
the * symbol, is equivalent to a loopback line in a railroad syntax diagram.
Appendix E. Accessibility
139
140
z/OS Planning for Installation
Notices
This information was developed for products and services that are offered in the USA or elsewhere.
IBM may not offer the products, services, or features discussed in this document in other countries.
Consult your local IBM representative for information on the products and services currently available in
your area. Any reference to an IBM product, program, or service is not intended to state or imply that
only that IBM product, program, or service may be used. Any functionally equivalent product, program,
or service that does not infringe any IBM intellectual property right may be used instead. However, it is
the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or
service.
IBM may have patents or pending patent applications covering subject matter described in this
document. The furnishing of this document does not grant you any license to these patents. You can send
license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
United States of America
For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual
Property Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japan
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some
states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this
statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically
made to the information herein; these changes will be incorporated in new editions of the publication.
IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
This information could include missing, incorrect, or broken hyperlinks. Hyperlinks are maintained in
only the HTML plug-in output for the Knowledge Centers. Use of hyperlinks in other output formats of
this information is at your own risk.
Any references in this information to non-IBM websites are provided for convenience only and do not in
any manner serve as an endorsement of those websites. The materials at those websites are not part of
the materials for this IBM product and use of those websites is at your own risk.
© Copyright IBM Corp. 2002, 2017
141
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the
exchange of information between independently created programs and other programs (including this
one) and (ii) the mutual use of the information which has been exchanged, should contact:
IBM Corporation
Site Counsel
2455 South Road
Poughkeepsie, NY 12601-5400
USA
Such information may be available, subject to appropriate terms and conditions, including in some cases,
payment of a fee.
The licensed program described in this document and all licensed material available for it are provided
by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or
any equivalent agreement between us.
Any performance data contained herein was determined in a controlled environment. Therefore, the
results obtained in other operating environments may vary significantly. Some measurements may have
been made on development-level systems and there is no guarantee that these measurements will be the
same on generally available systems. Furthermore, some measurements may have been estimated through
extrapolation. Actual results may vary. Users of this document should verify the applicable data for their
specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their
published announcements or other publicly available sources. IBM has not tested those products and
cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of
those products.
All statements regarding IBM's future direction or intent are subject to change or withdrawal without
notice, and represent goals and objectives only.
This information contains examples of data and reports used in daily business operations. To illustrate
them as completely as possible, the examples include the names of individuals, companies, brands, and
products. All of these names are fictitious and any similarity to the names and addresses used by an
actual business enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs
in any form without payment to IBM, for the purposes of developing, using, marketing or distributing
application programs conforming to the application programming interface for the operating platform for
which the sample programs are written. These examples have not been thoroughly tested under all
conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these
programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.
Terms and conditions for product documentation
Permissions for the use of these publications are granted subject to the following terms and conditions.
142
z/OS Planning for Installation
Applicability
These terms and conditions are in addition to any terms of use for the IBM website.
Personal use
You may reproduce these publications for your personal, noncommercial use provided that all
proprietary notices are preserved. You may not distribute, display or make derivative work of these
publications, or any portion thereof, without the express consent of IBM.
Commercial use
You may reproduce, distribute and display these publications solely within your enterprise provided that
all proprietary notices are preserved. You may not make derivative works of these publications, or
reproduce, distribute or display these publications or any portion thereof outside your enterprise, without
the express consent of IBM.
Rights
Except as expressly granted in this permission, no other permissions, licenses or rights are granted, either
express or implied, to the publications or any information, data, software or other intellectual property
contained therein.
IBM reserves the right to withdraw the permissions granted herein whenever, in its discretion, the use of
the publications is detrimental to its interest or, as determined by IBM, the above instructions are not
being properly followed.
You may not download, export or re-export this information except in full compliance with all applicable
laws and regulations, including all United States export laws and regulations.
IBM MAKES NO GUARANTEE ABOUT THE CONTENT OF THESE PUBLICATIONS. THE
PUBLICATIONS ARE PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF
MERCHANTABILITY, NON-INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE.
IBM Online Privacy Statement
IBM Software products, including software as a service solutions, (“Software Offerings”) may use cookies
or other technologies to collect product usage information, to help improve the end user experience, to
tailor interactions with the end user, or for other purposes. In many cases no personally identifiable
information is collected by the Software Offerings. Some of our Software Offerings can help enable you to
collect personally identifiable information. If this Software Offering uses cookies to collect personally
identifiable information, specific information about this offering’s use of cookies is set forth below.
Depending upon the configurations deployed, this Software Offering may use session cookies that collect
each user’s name, email address, phone number, or other personally identifiable information for purposes
of enhanced user usability and single sign-on configuration. These cookies can be disabled, but disabling
them will also eliminate the functionality they enable.
If the configurations deployed for this Software Offering provide you as customer the ability to collect
personally identifiable information from end users via cookies and other technologies, you should seek
your own legal advice about any laws applicable to such data collection, including any requirements for
notice and consent.
For more information about the use of various technologies, including cookies, for these purposes, see
IBM’s Privacy Policy at ibm.com/privacy and IBM’s Online Privacy Statement at ibm.com/privacy/
Notices
143
details in the section entitled “Cookies, Web Beacons and Other Technologies,” and the “IBM Software
Products and Software-as-a-Service Privacy Statement” at ibm.com/software/info/product-privacy.
Policy for unsupported hardware
Various z/OS elements, such as DFSMS, JES2, JES3, and MVS, contain code that supports specific
hardware servers or devices. In some cases, this device-related element support remains in the product
even after the hardware devices pass their announced End of Service date. z/OS may continue to service
element code; however, it will not provide service related to unsupported hardware devices. Software
problems related to these devices will not be accepted for service, and current service activity will cease if
a problem is determined to be associated with out-of-support devices. In such cases, fixes will not be
issued.
Minimum supported hardware
The minimum supported hardware for z/OS releases identified in z/OS announcements can
subsequently change when service for particular servers or devices is withdrawn. Likewise, the levels of
other software products supported on a particular release of z/OS are subject to the service support
lifecycle of those products. Therefore, z/OS and its product publications (for example, panels, samples,
messages, and product documentation) can include references to hardware and software that is no longer
supported.
v For information about software support lifecycle, see: IBM Lifecycle Support for z/OS
(www.ibm.com/software/support/systemsz/lifecycle)
v For information about currently-supported IBM hardware, contact your IBM representative.
Trademarks
IBM, the IBM logo, and ibm.com® are trademarks or registered trademarks of International Business
Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be
trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at
Copyright and Trademark information (www.ibm.com/legal/copytrade.shtml).
Adobe, Acrobat, and PostScript are either registered trademarks or trademarks of Adobe Systems
Incorporated in the United States, other countries, or both.
Intel is a trademark of Intel Corporation or its subsidiaries in the United States and other countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle, its
affiliates, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or
both.
Other company, product, or service names might be trademarks or service marks of others.
144
z/OS Planning for Installation
Index
Numerics
A
C
2105 System Storage DS8000 67
2107 System Storage DS8000 67
2440 Magnetic Tape Subsystem 67, 68
2501 Card Reader 67
2540 Card Read Punch 67
3178 Display Station 68
3179 Display Station 68
3180 Display Station 68
3191 Display Station 68
3192 Color Display Station 68
3194 Display Station 68
3205 Color Display Station 68
3206 Display Station 68
3251 Display Station 68
3270 Information Display System 68
3270 PC File Transfer Program
base element 2
hardware requirements 125
software requirements 116
3290 Information Panel 68
3380 Direct Access Storage 67
3420 Magnetic Tape Unit 67, 68
3422 Magnetic Tape Subsystem 67, 68
3423 Magnetic Tape Device 67, 68
3424 Magnetic Tape Subsystem 67, 68
3430 Magnetic Tape Subsystem 67, 68
3472 InfoWindow Workstation 68
3480 Magnetic Tape Subsystem 67
3490 Magnetic Tape Subsystem 67, 68
3494 TotalStorage Enterprise Automated
Tape Library 67
3494 TotalStorage Enterprise Peer-To-Peer
Virtual Tape Server 67
3494 TotalStorage Enterprise Virtual Tape
Server 67
3495 TotalStorage Enterprise Automated
Tape Library 67
3505 Card Reader 67
3525 Card Punch 67
3584 System Storage Automated Tape
Library (TS3500) 67
3590 TotalStorage Enterprise Tape
System 67
3592 System Storage Tape System
(TS11xx) 67
3890 Storage Control 67
3957 System Storage Virtualization
Engine (TS7700) 67
3990-3 Storage Control 67
3990-6 Storage Control 67
9332 Direct Access Storage Device 67
9340 DASD Subsystem 67
9341 Storage Controller Module 67
9343 Storage Controller 67
9391 RAMAC Array DASD 67
9393 RAMAC Virtual Array Storage 67
9396 RAMAC Scalable Array 3
Storage 67
9397 RAMAC Electronic Array
Storage 67
accessibility 137
contact IBM 137
features 137
alternate base 59
Alternate Library for REXX
base element 2
hardware requirements 117
software requirements 108
architecture
z/Architecture introduction 1
z/Architecture required 64
assistive technologies 137
automatic tape switching hardware
requirements 117
Capacity Provisioning 2
CBPDO
deciding if it is for you 39
driving system software
requirements 54
how you order 61
introduction to 22
CEA (common event adapter)
customization
SYS1.SAMPLIB(CEASEC) 71
CEASEC member of SYS1.SAMPLIB
CEA (common event adapter)
customization 71
change index
PSP bucket 32
changes, summary of
in z/OS V2R1 xiii, xiv
in z/OS V2R2 xii
in z/OS V2R3 xi
checklist, installation 101
CICS driving system software
requirements 57
CIM (Common Information Model)
base element 2
hardware requirements 118
software requirements 110
cloning your system 129
licensing considerations 40
cluster-related data sets, placement of 93
coexistence
description of 27
IBM policy 28
common event adapter customization
SYS1.SAMPLIB(CEASEC) 71
Common Information Model
base element 2
hardware requirements 118
software requirements 110
Communications Server
base element 2
hardware requirements 125
software requirements 111
Communications Server Security Level 3
hardware requirements 118
optional feature 2
software requirements 111
compatibility 27
consolidated service test (CST) 33
contact
z/OS 137
copy
software 129
copying your system 129
coupling facility structure duplexing,
system-managed
software requirements 110
cross-system coupling facility (XCF)
hardware requirements 118
Cryptographic Services
base element 2
© Copyright IBM Corp. 2002, 2017
B
backout 28
Base Control Program (BCP)
base element 2
base elements
introduction to 1
list of 2
renamed and moved 16
BCP
hardware requirements 117
software requirements 108
BDT
hardware requirements 118
software requirements 110
BDT File-to-File
hardware requirements 118
software requirements 110
BDT SNA NJE
hardware requirements 118
software requirements 110
block sizes
affect on DASD space 99
recommended 100
BookManager Build removed from
z/OS 16
BookManager READ
base element 2
hardware requirements 118
software requirements 110
books
IBM Redbooks 36
BUILDMCS command
description 80
use of 80
Bulk Data Transfer (BDT)
base element 2
Bulk Data Transfer (BDT) File-to-File
optional feature 2
Bulk Data Transfer (BDT) SNA NJE
optional feature 2
145
Cryptographic Services (continued)
hardware requirements 119
software requirements 111
CST (consolidated service test) 33
Customized Offerings Driver 45
customizing for CEA
SYS1.SAMPLIB(CEASEC) 71
CustomPac Installation Dialog
installing 47
introduction to 20
cycles of releases 17
D
DASD
placement 83
space utilization and performance 99
storage requirements 66
data set placement 83
DB2 driving system software
requirements 57
DCE Application Support removed from
z/OS 16
DCE removed from z/OS 16
DCF, enabling 75
device support, I/O 66
DFSMS/MVS Network File System
now named Network File System 2
DFSMSdfp
base element 2
hardware requirements 119
software requirements 111
DFSMSdss
hardware requirements 120
optional feature 2
software requirements 111
DFSMShsm
hardware requirements 120
optional feature 2
software requirements 111
DFSMSrmm
hardware requirements 120
optional feature 2
software requirements 111
DFSMStvs
hardware requirements 120
optional feature 2
software requirements 111
DFSORT
hardware requirements 120
optional feature 2
software requirements 111
DFSORT removed from z/OS 16
differences
in z/OS V2R1 xiv
in z/OS V2R2 xii
in z/OS V2R3 xi
disabling what was enabled 77
Distributed File Service
base element 2
hardware requirements 120
software requirements 112
distribution libraries, placement of 91
DLIBs (distribution libraries), placement
of 91
documentation
from IBM Systems Centers 36
146
z/OS Planning for Installation
download method, choosing a 41
driving system
software requirements for CBPDO 54
software requirements for
ServerPac 46
software requirements for SystemPac
dump-by-data-set 46
software requirements for SystemPac
full volume dump 52
dump-by-data-set SystemPac
introduction to 22
duplexing rebuild, system-managed
software requirements 110
DVD delivery
for products 40
hardware requirements for 58
software requirements for CBPDO
download 56
software requirements for ServerPac
and SystemPac download 49, 54
dynamic APF software requirements 108
dynamic enablement
procedures 71
relationship to language 23
dynamic exits service 80
E
education
for z/OS 36
IBM Learning Services website 36
electronic delivery
between-release enhancements 22
for products 40
for service 36, 60, 61, 62, 103
hardware requirements for 58
how it works 62
software requirements for direct
CBPDO download 54
software requirements for
intermediate CBPDO download 55
software requirements for
intermediate ServerPac
download 46
elements
introduction to 1
list of 2
renamed and moved 16
enablement of priced features 71
end of service 31
Enhanced HOLDDATA 35
Enterprise Identity Mapping (EIM)
part of Integrated Security Services 2
Entry Server Offering for installing 23
Environmental Record Editing and
Printing Program (EREP)
base element 2
EREP
hardware requirements 120
software requirements 112
ESCON devices supported by z/OS 66
ESCON Director Support
base element 2
hardware requirements 120
software requirements 112
exclusive element or feature, introduction
to 2
Express Plus Offering
for installing 23
extended indirect cataloging 98
extended indirect volume serial
support 98
F
fallback
description of 28
IBM policy 28
features
introduction to 1
list of 2
renamed and moved 16
fee installation methods
other than SystemPac 23
SystemPac 22
FFST
hardware requirements 120
software requirements 112
FICON devices supported by z/OS 66
First Failure Support Technology/MVS
(FFST/MVS)
base element 2
FIXCAT 32
flashes, IBM Systems Center 36
frequency of releases 17
full system replacement
introduction to 21
full volume dump SystemPac
introduction to 22
G
GDDM
base element 2
hardware requirements 120
software requirements 112
GDDM-PGF
enabling 75
hardware requirements 120
optional feature 2
software requirements 112
GDDM-REXX
hardware requirements 120
optional feature 2
software requirements 112
global data sets, placement of SMP/E
global resource serialization complex
hardware dependencies 117
Global Technology Services, IBM
web page 23
87
H
Hardware Configuration Definition
(HCD)
base element 2
Hardware Configuration Manager (HCM)
optional feature 2
hardware requirements
for each element and feature 117
minimum for driving system 58
target system 63
HCD
hardware requirements 120
HCM
hardware requirements 120
software requirements 112
Health Checker for z/OS, IBM
in BCP 2
HFS customization volume, data sets
on 93
HFS target volume, data sets on 89
High Level Assembler (HLASM)
base element 2
HLASM
hardware requirements 121
software requirements 112
HLASM Toolkit
enabling 76
hardware requirements 121
optional feature 2
software requirements 112
HOLDDATA 35
I
I/O device support 66
IBM Education Assistant 36
IBM Global Technology Services
web page 23
IBM Health Checker for z/OS
in BCP 2
IBM HTTP Server
hardware requirements 121
software requirements 112
IBM HTTP Server (powered by Domino)
removed from z/OS 16
IBM HTTP Server powered by Apache
base element 2
new base element 16
IBM Knowledge Center for z/OS
base element 2
hardware requirements 121
new base element 16
software requirements 112
IBM Learning Services 36
IBM Print Transform from AFP products)
enabling 76
IBM TDS
base element 2
hardware requirements 121
software requirements 113
IBM TDS Security Level 3
in z/OS Security Level 3 2
IBM Tivoli Directory Server for z/OS
(IBM TDS for z/OS)
base element 2
IBM z Integrated Information Processor
(zIIP)
hardware requirements 118
IBM z/OS Liberty Embedded
base element 2
IBM z/OS Management Facility
(z/OSMF)
base element 2
hardware requirements 121
new base element 16
software requirements 113
IBM zEnterprise Application Assist
Processor (zAAP)
software requirements 109
ICKDSF
base element 2
hardware requirements 121
software requirements 113
ICLI (Integrated Call Level Interface)
in z/OS UNIX 2
ICSF
part of Cryptographic Services 2
IFAPRDxx parmlib member
how to activate 77
how to update for dynamic
enablement 73
image-related data sets, placement of 92
IMS driving system software
requirements 57
indirect cataloging 98
indirect volume serial support 98
Infoprint Central, z/OS
part of Infoprint Server 2
Infoprint Server
hardware requirements 121
optional feature 2
software requirements 113
installation checklist 101
installing
definition of install vii
elements you must install 59
entitled methods
CBPDO 22
ServerPac 20
features you must install 59
fee methods 23
Entry Server Offering 23
Express Plus Offering 23
other 23
Software Management 23
SystemPac 22
z/OS Select 23
IBM recommendations 39
Integrated Call Level Interface (ICLI)
in z/OS UNIX 2
Integrated Security Services
base element 2
hardware requirements 121
software requirements 114
integration testing by IBM
blog 30
explanation of 30
website 30
Intelligent Resource Director (IRD) 1
Internet address
for downloading Enhanced
HOLDDATA 35
for IBM education information 36
for IBM Global Technology
Services 23
for IBM Redbooks 36
for IBM Systems Center flashes 36
for ISV products 60
for product publications 36
for SMP/E Planning and Migration
Assistant 2
for z/OS platform (integration)
test 30
Internet address (continued)
for zSeries service information 35
Internet delivery
between-release enhancements 22
for products 40
for service 36, 60, 61, 62, 103
hardware requirements for 58
how it works 62
software requirements for direct
CBPDO download 54
software requirements for
intermediate CBPDO download 55
software requirements for
intermediate SystemrPac
download 46
software requirements for SystemPac
full volume dump download 52
Internet Service Retrieval, SMP/E 36
IP PrintWay 2
IP Security - TDES
now in Communications Server
Security Level 3 2
IP Services
hardware requirements 125
part of Communications Server
element 2
software requirements 111
IPL
minimum storage required to 64
preparing for rolling 27
IRD (Intelligent Resource Director) 1
ISPF
base element 2
hardware requirements 121
software requirements - with ISPF
client/server 114
ISV products
choosing 60
list on World Wide Web 60
ITSO Redbooks 36
J
Java
software requirements 109
Java software requirements 109
JES2
base element 2
coexistence-fallback-migration
policy 28
hardware requirements 122
recommended data sets on checkpoint
volume 94
recommended data sets on spool
volume 94
ServerPac and SystemPac delivery
of 69
software requirements 115
using existing level with z/OS
V2R3 69
JES3
coexistence-fallback-migration
policy 28
hardware requirements 122
optional feature 2
ServerPac and SystemPac delivery
of 69
Index
147
JES3 (continued)
software requirements 115
using existing level with z/OS
V2R3 69
K
kernel, z/OS UNIX
in BCP 2
keyboard
navigation 137
PF keys 137
shortcut keys 137
L
Language Environment
base element 2
hardware requirements 122
software requirements 115
language relationship to dynamic
enablement 23
languages available for z/OS 23
Learning Services, IBM 36
Library Server
base element 2
hardware requirements 122
software requirements 115
licensed product DLIB volume, data sets
on 91
licensed product target volume, data sets
on 90
licensed products on z/OS 60
licensed programs on z/OS 60
licensing considerations when sharing or
cloning 40
logical parmlib 98
M
magnetic tape subsystems 67, 68
maintenance using RSUs, preventive 34
Managed System Infrastructure for Setup
withdrawn 16
marketed, products no longer
reinstalling 80
master catalog changes to use
ServerPac 80
master catalog volume, data sets on 93
Metal C Runtime Library
base element 2
hardware requirements 122
software requirements 115
MICR/OCR
base element 2
hardware requirements 122
software requirements 115
migration, IBM policy for 28
moved elements and features 16
msys for Setup withdrawn 16
multisystem configuration
resource sharing inherent in 27
MVS/ESA Direct Optical Attachmen 68
148
z/OS Planning for Installation
N
national language support
in z/OS 23
navigation
keyboard 137
NetSpool
part of Infoprint Server 2
network attachments hardware
requirements 126
Network Authentication Service
part of Integrated Security Services 2
Network Authentication Service Level 3
component in z/OS Security Level
3 2
Network File System
base element 2
hardware requirements 122
software requirements 115
Networking Systems Center flashes 36
NFS (Network File System)
base element 2
hardware requirements 122
software requirements 115
NLS (national language support)
in z/OS 23
NLV (national language version) support
in z/OS 23
non-IBM products, choosing 60
nonexclusive element or feature,
introduction to 2
O
OCEP (Open Cryptographic Enhanced
Plug-ins)
part of Integrated Security Services 2
OCSF
part of Cryptographic Services 2
Open Cryptographic Enhanced Plug-ins
(OCEP)
part of Integrated Security Services 2
Open Systems Adapter Support Facility
(OSA/SF)
base element 2
OpenSSH for z/OS
hardware requirements 122
optional features
introduction to 1
list of 2
renamed and moved 16
order checklist for SystemPac orders 62
order period 61
OSA/SF
hardware requirements 122
software requirements 115
P
page data set volume 1, data sets on 92
page data set volume 2, data sets on 92
Parallel Sysplex, rolling z/OS across 27
parmlib
changes to use ServerPac 80
parmlib concatenation 98
control parmlib data sets 80
parmlib symbolic preprocessor tool for
verifying symbols 80
PDSEs
no sharing between sysplexes 85
PFA
software requirements 109
PKI Services
part of Cryptographic Services 2
Planning and Migration Assistant,
SMP/E
description 2
used to plan order 60
platform testing by IBM
blog 30
explanation of 30
website 30
policy, IBM
coexistence 28
fallback 28
installing all elements and
features 59
migration 28
service 31
Predictive Failure Analysis (PFA)
software requirements 109
preventive maintenance using RSUs 34
preventive service planning 32
Preventive Service Planning (PSP)
hardware upgrade identifiers 65
priced features, introduction to 1
Print Interface
part of Infoprint Server 2
Print Services Facility (PSF)
enabling 77
Print Transform products)
enabling 76
Printer Inventory Manager
part of Infoprint Server 2
processor storage requirements
maximum supported 64
minimum to IPL 64
proclib
changes to use ServerPac 80
product set, definition of 83
products no longer marketed
reinstalling 80
PSP
buckets 32
software upgrade identifiers 32
PSP bucket
change index 32
Public Key Infrastructure (PKI) Services
part of Cryptographic Services 2
publications
IBM Redbooks 36
R
RACF
part of Security Server feature 2
RAMAC Array Device 67
real storage
maximum supported 64
minimum required to IPL 64
Recommended Service Upgrade (RSU)
description of 34
in platform (integration) testing 31
Recommended Service Upgrade (RSU)
(continued)
in ServerPac order 31
in SystemPac order 32
Redbooks, IBM 36
RefreshPac 36
release strategy 17
renamed elements and features 16
requirements
DASD 66
driving system
(SystemPac dump-by-data-set) 46
(SystemPac full volume dump) 52
CBPDO 54
hardware 58
ServerPac 46
hardware 117
minimum software product levels 60
software 107
storage to IPL 64
supported servers 63
Resource Measurement Facility (RMF)
optional feature 2
ripple, definition of 54
RMF
hardware requirements 123
software requirements 116
rolling IPL
preparing for 27
RSU
description of 34
in platform (integration) testing 31
in ServerPac order 31
in SystemPac order 32
Runtime Library Extensions
base element 2
hardware requirements 123
software requirements 116
S
S/370 and S/390 Optical Media
Attach/2 68
SDSF
hardware requirements 123
ServerPac and SystemPac delivery
of 69
software requirements 116
Security Server
hardware requirements 123
optional feature 2
software requirements 116
Select, z/OS
for installing 23
sending comments to IBM ix
server message block (SMB) 2
software requirements 112
ServerPac
deciding if it is for you 39
driving system software
requirements 46
full system replacement 21
how you order 61
introduction to 20
SMS active for allocation 46
software upgrade 21
target system preparation 50
servers supported by z/OS 63
service
distribution 35
driving system requirement
(ServerPac and SystemPac) 48
end of 31
Enhanced HOLDDATA website 35
for target system 68
level for CBPDO orders 32
level for ServerPac orders 31
level for SystemPac orders 32
planning 32
policy 31
preventive maintenance 34
RefreshPac 36
web deliverables 32
Web page for information 35
Service Retrieval, SMP/E Internet 36
shipping z/OS, frequency of 17
Shopz
for ordering service 35
shortcut keys 137
size
of blocks for best performance 99
of DASD required 66
SMB (server message block) 2
software requirements 112
SMP/E
base element 2
hardware requirements 123
software requirements 116
SMP/E for z/OS V3.6 32
SMP/E global data sets, placement of 87
SMP/E Internet Service Retrieval 36
SMP/E Planning and Migration Assistant
description 2
used to plan order 60
SMS active for allocation 46
SNA Services
hardware requirements 127
part of Communications Server
element 2
software requirements 111
softcopy documents on Internet
IBM Redbooks 36
product 36
softcopy volume, data sets on 95
Software Management
for installing 23
software requirements
driving system for CBPDO 54
driving system for ServerPac 46
driving system for SystemPac
dump-by-data-set 46
driving system for SystemPac full
volume dump 52
for each element and feature 107
software upgrade
introduction to 21
space requirements
DASD 66
DASD utilization and
performance 99
minimum storage required to IPL 64
SREL
in CBPDO order 61
in ServerPac order 61
SREL (continued)
in SystemPac order 62
SSL, System
part of Cryptographic Services 2
staging JES and SDSF migration 69
stand-alone products on z/OS 60
storage requirements
DASD 66
DASD space utilization and
performance 99
maximum real storage supported 64
minimum required to IPL 64
strategy, release 17
subsystem DLIB volume, data sets on 92
subsystem driving system software
requirements 57
subsystem target volume, data sets
on 90
summary of changes
in z/OS V2R1 xiii, xiv
in z/OS V2R2 xii
in z/OS V2R3 xi
SYS1.SAMPLIB(CEASEC)
CEA (common event adapter)
customization 71
sysplex-related volume 1
recommended data sets on 94
sysplex-related volume 2
recommended data sets on 94
sysplex, rolling z/OS across 27
SYSRES
changes to use ServerPac 80
handling overflow 85
indirect cataloging 98
indirect volume serial support 98
logical extension volumes 98
no sharing if sysplex and PDSEs 85
System Display and Search Facility
(SDSF)
optional feature 2
system identifier, planning 60
System REXX for z/OS Base 2
System Secure Sockets Layer (SSL)
part of Cryptographic Services 2
System SSL
part of Cryptographic Services 2
system symbolics
with indirect volume serial
support 98
system-managed duplexing rebuild
software requirements 110
SystemPac
deciding if it is for you 39
driving system software requirements
(dump-by-data-set) 46
driving system software requirements
(full volume dump) 52
for installing 22
how you order 61
SMS active for allocation 46
target system preparation 50
Systems Center, IBM
flashes 36
publications 36
Index
149
T
V
target libraries (TLIBs), placement of 87
TCP/IP
in Communications Server 2
TCP/IP for MVS IMS Sockets
software requirements 111
Terminal Input Output Controller (TIOC)
base element 2
testing a new release 78
Time Sharing Option/Extensions (TSO/E)
base element 2
TIOC
hardware requirements 123
software requirements 116
Tivoli Directory Server for z/OS
hardware requirements 121
Tivoli Directory Server for z/OS Security
Level 3, IBM
in z/OS Security Level 3 2
Tivoli Directory Server for z/OS, IBM
software requirements 113
TLIBs, placement of 87
toleration 27
trademarks 144
training
for z/OS 36
IBM Learning Services website 36
Transform Interface
part of Infoprint Server 2
TSO/E
hardware requirements 124
software requirements 116
TVOL1, data sets on 87
TVOL2, data sets on 89
TVOLn, data sets on 89
vendor product DLIB volume, data sets
on 91
vendor product target volume, data sets
on 90
vendor products, choosing 60
volume serial support, indirect 98
volumes, apportioning data sets to 85
VTAM
in Communications Server 2
U
Unicode Standard, support for 2
unpriced features, introduction to 1
upgrades
hardware identifiers 65
software identifiers 32
URL
for downloading Enhanced
HOLDDATA 35
for IBM education information 36
for IBM Global Technology
Services 23
for IBM Redbooks 36
for IBM Systems Center flashes 36
for ISV products 60
for product publications 36
for SMP/E Planning and Migration
Assistant 2
for z/OS platform (integration)
test 30
for zSeries service information 35
user exits
positioning to use ServerPac 81
user interface
ISPF 137
TSO/E 137
user modifications
positioning to use ServerPac 81
150
z/OS Planning for Installation
W
Washington Systems Center flashes 36
waves
definition of 54
Wave 0 requirements 56
Wave 1 requirements 56
Wave 2 requirements 57
web address
for downloading Enhanced
HOLDDATA 35
for IBM Global Technology
Services 23
for SMP/E Planning and Migration
Assistant 2
Web address
for IBM education information 36
for IBM Redbooks 36
for IBM Systems Center flashes 36
for ISV products 60
for product publications 36
for z/OS platform (integration)
test 30
for zSeries service information 35
web deliverables, service for 32
web delivery for enhancements 23
withdrawn products (from marketing)
reinstalling 80
World Wide Web address
for IBM Redbooks 36
for ISV products 60
for zSeries service information 35
X
XL C/C++
hardware requirements 124
optional feature 2
software requirements 116
XML System Services, z/OS 2
Z
z/Architecture
introduction 1
requirement for 64
z/OS Font Collection 1
base element 2
hardware requirements 124
new base element 17
software requirements 116
using 69
z/OS Infoprint Central
part of Infoprint Server 2
z/OS OpenSSH 17
base element 2
software requirements 116
z/OS Security Level 3
optional feature 2
software requirements 116
z/OS Select
for installing 23
z/OS UNIX
base element 2
hardware requirements 125
kernel 2
software requirements 116
z/OS UNIX Application Services
in z/OS UNIX 2
z/OS UNIX Integrated Call Level
Interface (ICLI)
removed from V2R1 17
z/OS UNIX System Services (z/OS
UNIX)
base element 2
hardware requirements 125
kernel 2
software requirements 116
z/OS XML System Services 2
z13 server 63
z13s server 63
zBC12 server 63
zEC12 server 63
zEnterprise data Compression (zEDC) for
z/OS
optional feature 2
zFS customization volume, data sets
on 93
IBM®
Product Number: 5650-ZOS
Printed in USA
GA32-0890-30
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement