Upgrade to IBM z/OS V2.4 planning

Upgrading to z/OS V2R4 Part 1 of 2: Planning
SHARE in Ft Worth, TX © 2020 IBM Corporation Page 1 of 55
Abstract:
This is the planning part of a two-part session for system programmers and their managers who are planning on upgrading to
z/OS V2.4. In part one, the focus is on preparing your current system for upgrading to either release. The system requirements
to run and how to prepare your system for the upgrade are discussed. Part two covers the only upgrade details for upgrading
to z/OS V2.4 from either V2.2 or V2.3. It is strongly recommended that you attend both sessions for an upgrade picture for
z/OS V2.4.
The general availability date for z/OS V2.4 happened September 30 2019.

Related Publications:
• z/OS V2.4 zipped PDFs with index https://t.co/eKOUGUydO8?amp=1
• z/OS V2.4 library for all books: https://www-
01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4Library?OpenDocument
o z/OS Planning for Installation
o z/OS Introduction and Release Guide
o z/OS Release Upgrade Reference Summary (new name for Summary of Message and Interface Changes!)
o z/OS MVS Initialization and Tuning Reference
o z/OS UNIX System Services Planning
• System z Platform Test Report for z/OS and Linux Virtual Servers (available from
http://www.ibm.com/servers/eserver/zseries/zos/integtst/)
• ServerPac: Installing Your Order (no order number; custom-built to your order)
• ServerPac: Using the Installation Dialog,
URL DESCRIPTION
http://www.ibm.com/systems/z/os/zos/ IBM z/OS home page
https://github.com/IBM/IBM-Z-zOS/tree/master/zOS-Workflow z/OSMF Workflows
http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin
/pbi.cgi
IBM Publications Center
https://www-
304.ibm.com/servers/resourcelink/hom03010.nsf?OpenDatabase
IBM ResourceLink
https://github.com/IBM/IBM-Z-zOS/tree/master/zOS-Education IBM Education Assistant for z/OS
http://www.ibm.com/servers/eserver/zseries/zos/servicetst/ Consolidated Service Test (CST) home page
http://www.ibm.com/servers/eserver/zseries/zos/installation/ z/OS Installation
http://www.ibm.com/software/support/lifecycle/index_a_z.html End of Service dates for IBM Software
http://www.ibm.com/servers/eserver/zseries/zos/integtst/ zSeries Platform Test web page

http://www.redbooks.ibm.com/ IBM Redbooks web page
http://www.ibm.com/support/techdocs/atsmastr.nsf/Web/Flashes IBM Systems Center Flashes
http://www.ibm.com/servers/eserver/zseries/zos/support/ z/OS Technical Support
http://www.ibmlink.ibm.com/ IBMLink web page
http://www.ibm.com/systems/z/advantages/pso/cftable.html Coupling Facility Level (CFLEVEL)
Considerations web page
http://service.boulder.ibm.com/390holddata.html Enhanced HOLDDATA web page
http://www14.software.ibm.com/webapp/set2/psp/srchBroker PSP buckets web page
http://www.ibm.com/software/shopzseries Shopz home page
http://www.ibm.com/systems/z/os/zos/features/software/isv230.html ISVs Supporting z/OS V2.3
http://www.ibm.com/systems/z/os/zos/features/software/isv220.ht
ml
ISVs Supporting z/OS V2.2
http://www.ibm.com/servers/eserver/zseries/swprice/ IBM System z Software Pricing
Software Pricing web page
http://www.ibm.com/systems/z/os/zos/support/zos_eos_dates.html z/OS marketing and service announce,
availability, and withdrawal dates
http://www.ibm.com/systems/z/os/zos/features/unix/bpxa1ty1.html Some ported programs for z/OS web page
https://www.ibm.com/systems/z/os/zos/installation/zosnfapars.html z/OS Platform New Function APARs
IBM Education:
IBM courses are available for z/OS. For schedules and enrollment on the world wide web, IBM Global Campus
URL: http://www.ibm.com/services/learning/ .
z/OS V2.4 Performance Information
At z/OS V2.4 GA (September 2019), the SOFTCAP tool can be downloaded from the web site:
http://w3.ibm.com/support/americas/wsc/cpsproducts.html . This tool provides more specific capacity planning information for
the upgrade to z/OS V2.4.

z/OS Elements and Features
z/OS consists of base elements and optional features:
 The base elements (or simply elements) deliver essential operating system functions. When you order z/OS,
you receive all of the base elements.
 The optional features (or simply features) are orderable with z/OS and provide additional operating system
functions. 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, IBM
recommends that you 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, usually neither are its
unpriced features.
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 them 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.
Elements and features may be exclusive or nonexclusive:
 An element or feature is called exclusive to z/OS if it exists only within z/OS (not also as a separately orderable,
or stand-alone, product) and if future functional enhancements will occur only within z/OS.
 An element or feature is called nonexclusive if it exists both (1) within z/OS and (2) as a stand-alone product.
Listed in the slide above are the changing elements within z/OS V2R4 since z/OS V2R2.

Withdrawn in z/OS V2R3 (last delivered in z/OS V2R2)
This section lists items that were withdrawn in z/OS V2R3. You should take this into account if you are upgrading
from z/OS V2.2 or V2.3, to z/OS V2.4. The removal of these functions may have upgrade actions which you can
perform now, in preparation for z/OS V2.4.
• z/OS V2.3 is the last release in which the consoles component supports shared mode. Migrate to distributed
mode, which was introduced in z/OS V1.10. A "best practices" health check was added in z/OS V1.13 to
help you identify systems on which shared mode is in use. Distributed mode is designed to improve
operations in sysplex environments by helping reduce the time required to IPL and for systems to join a
sysplex, improve availability, and allow more MCS, SMCS, and subsystem consoles to be configured.
• z/OS V2.3 is the last release to include the Trivial File Transfer Protocol Daemon (TFTPD) function in z/OS
Communications Server.
• z/OS V2.3 is the last release to include the TCP/IP legacy device drivers for FDDI and Token Ring (LCS
with LINKs FDDI and IBMTR), Token Ring (MPCIPA with LINK IPAQTR), and ENet and FDDI (MPCOSA
with LINKs OSAENET and OSAFDDI). If you are using any of these devices, migrate to newer devices such
as OSA Express QDIO and Hipersockets. Note that this withdrawal is only for TCP/IP device types, and not
for any of the SNA device drivers.
• z/OS V2.3 is the last release to include the Simple Mail Transport Protocol Network Job Entry (SMTPD
NJE) Mail Gateway and Sendmail mail transports. If you use the SMTPD NJE Gateway to send mail, use
the existing CSSMTP SMTP NJE Mail Gateway instead. IBM had announced plans to provide a
replacement program for the Sendmail client that would not require programming changes. Those plans
have changed, and IBM plans to provide a compatible subset of functions for Sendmail in the replacement
program and to announce those functions in the future. Programming changes or alternative solutions to
currently provided Sendmail functions might be required. No replacement function is planned in z/OS
Communications Server to support using SMTPD or Sendmail as a (SMTP) server for receiving mail for
delivery to local TSO/E or z/OS UNIX System Services user mailboxes, or for forwarding mail to other
destinations.

• z/OS V2.3 is the last release to provide support in the Common Information Model (CIM) component for the
Java Managed Provider Interface (JMPI).
• z/OS V2.3 is the last release to support the DFSMSrmm CIM Provider.
• Starting in z/OS V2.3, z/OS system logger will no longer support the log stream DRXRC duplex mode
option. z/OS V2.2 was announced as being the last release for system logger to support the DRXRC log
stream duplex staging data set option. See the statement of direction in US Software Announcement 215-
006, dated January 14, 2015. Also refer to the logger migration health check
ZOSMIGV2R2_NEXT_IXG_REMOVE_DRXRC), provided in the PTFs for APAR OA49507, to aid in
identifying whether any log stream is defined in the sysplex with the DUPLEXMODE(DRXRC) attribute.
• IBM previously announced in Software Announcement 215-267, dated July 28, 2015, that z/OS V2.2 would
be the last release to include a number of System Data Mover (SDM) TSO/E commands. Based on client
feedback, IBM now intends to continue to support these commands in the future, including the query and
XSET commands. However, IBM plans no future enhancements for them. IBM recommends you use the
equivalent REXX versions of these commands instead, which are intended to be updated as needed to
support any new functions in the future. For more information about using the REXX commands, see z/OS
DFSMS Advanced Copy Services.

BCP: Removal of support for user key common areas
Required if you are using any of the user key common areas described in this upgrade action.
IBM strongly recommends that you eliminate all use of user key common storage. Allowing programs to obtain user key (8-15) co
mmon storage creates a security risk because the storage can be modified or referenced, even if fetch protected, by any unautho
rized program from any address space. Therefore, without the restricted use common service area (RUCSA) optional priced feat
ure, the obtaining of user key (8-15) storage is not supported in z/OSV2R4.
RUCSA is more secure because it can be managed as a SAF resource. However, it does not prevent two or more different SAF-
authorized applications from altering or referencing another application's RUCSA storage. RUCSA became available as a part of
the BCP base element with APAR OA56180 on earlier z/OS releases, but it is only available as a priced feature in z/OS V2R4.
Related to this change:
• Support to change the key of common ESQA storage to a user key (via CHANGKEY) is removed regardless of RUCSA
exploitation. NUCLABEL DISABLE(IARXLUK2) is no longer a valid statement in the DIAGxx parmlib member. ( Note: T
his statement only exists in z/OS V2R3.)
• Support of user-key (8 - 15) SCOPE=COMMON data spaces is removed regardless of RUCSA exploitation.
• YES is no longer a valid setting for the following statemets in the DIAGxx parmlib member:
VSM ALLOWUSERKEYCSA Controls the allocation of user key CSA.
ALLOWUSERKEYCADS Controls the allocation of user key SCOPE=COMMON data spaces.
If set to YES on a z/OS V2R4 system, these statements are treated as syntax errors with messages, such as the followi
ng:
SET DIAG=J2
IEE252I MEMBER DIAGJ2 FOUND IN D10JHM1.PARMLIB
ASA002I SYNTAX ERROR IN PARMLIB MEMBER=DIAGJ2
LINE 17: 393 NO EXPECTED BEFORE <NON-KEYWORD>. DETECTING MODULE IS IGVDITMS.
INPUT LINE: VSM ALLOWUSERKEYCSA(YES)
ASA004I PARSING OF PARMLIB MEMBER=DIAGJ2 395 CONTINUED AT ),
LINE 17. DETECTING MODULE IS IGVDITMS.
INPUT LINE: VSM ALLOWUSERKEYCSA(YES)
ASA002I SYNTAX ERROR IN PARMLIB MEMBER=DIAGJ2
LINE 18: 396 NO EXPECTED BEFORE <NON-KEYWORD>. DETECTING MODULE IS IGVDITMS.
INPUT LINE: ALLOWUSERKEYCADS(YES)

ASA004I PARSING OF PARMLIB MEMBER=DIAGJ2 397 CONTINUED AT ),
LINE 18. DETECTING MODULE IS IGVDITMS.
INPUT LINE: ALLOWUSERKEYCADS(YES) IEE536I DIAG VALUE J2 NOW IN EFFECT
Upgrade action:
1. On the production system that you are upgrading to z/OS V2R4, determine whether you are using user key common
storage by checking the response to the following operator commands :
o D IPLINFO,RUCSA . If RUCSA was specified with nonzero values, you are already using RUCSA and must do
either of the following:
▪ Upgrade to the z/OS V2R4 priced optional feature. For instructions, see z/OS Planning for Installation.
No other steps are required. However, you might want to see whether you can reduce or possibly
eliminate user key common storage usage by following the additional steps below.
▪ Start with Step 2 below to remove all usage of user key common storage from your current system and
then remove the use of RUCSA before IPLing z/OS V2R4.
o D DIAG . If VSM ALLOWUSERKEYCSA and ALLOWUSERKEYCADS are set to NO and you are not using
RUCSA, no further action is required. You already prevent the use of user key common storage.
2. Query all software vendor products to determine whether any service is required to eliminate the use of user key
common storage.
o If you are running CICS Transaction Server for z/OS, ensure that you are running V5.2 or a later version.
o If you are running Tivoli OMEGAMON XE for DB2 PE/PM, apply APAR PI97225 ("Removed User Key CADS
Creation").
3. Check for usage of user key common areas, such as the following:
o Using the STORAGE, GETMAIN or CPOOL service to obtain common ECSA/CSA storage (subpool 227, 228,
231, 241) that specifies a key of 8-15.
o Using the DSPSERV service to allocate a SCOPE=COMMON data space in a key of 8-15.
o Using the CHANGKEY service to change the storage key of common storage to a key of 8-15.
To aid in finding all instances of user key common usage, apply the PTF for APAR OA53355 on your production
system. Doing so allows you to take one or more of the following actions:
o Enable the following example SLIP trap to produce GTF trace records to help in identifying software that uses
user key common storage:
SLIP SET,IF,A=TRACE,ID=UKEY,NUCEP=(IARXLUK4,0,1),TRDATA=(STD,REGS),END
In the GTF trace record, register 1 contains the address of the program that used user key common storage.
o Activate the ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM health check. This health check issues an
exception message when it detects usage of user key common storage.
o Ensure that SMF Type 30 recording is active. The Storage and Paging section contains flags that indicate
whether user key common storage is used. For information about the SMF30_UserKeyCsaUsage,
SMF30_UserKeyCadsUsage and SMF30_UserKeyChangKeyUsage flags, see z/OS MVS System
Management Facilities (SMF).
4. If the PTF for APAR OA53355 is not applied, you can take one or more of the following actions to help find
instances of user key common usage:
o Set the DIAGxx parmlib statement VSM ALLOWUSERKEYCSA to NO, which is the default. Then, IPL a test
system with the updated setting. Any software on your test system that attempts to obtain user key CSA/ECSA
storage by using the GETMAIN, STORAGE, or CPOOL service will fail. The service receives one of the
following abends: B04-5C, B0A-5C, or B78-5C.
o Specify ALLOWUSERKEYCADS(NO) in your DIAGxx parmlib. Then, IPL a test system with the updated
setting. Any software on your test system that attempts to obtain a user key (8-15) SCOPE=COMMON data
space fails with a 01D-xx0015xx abend.
o On z/OS V2R3 systems and later, specify NUCLABEL ENABLE(IARXLUK2) in your DIAGxx parmlib member.
Then, IPL a test system with the updated setting. Any software on your test system that attempts to use
CHANGKEY to change subpool 247 or 248 common storage to a user key (8-15) will fail with a 08F-1C abend.
o Enable the following example SLIP trap to produce GTF trace records to help in identifying software that
obtains user key CSA/ECSA storage:
SLIP SET,IF,A=TRACE,ID=UCSA,NUCEP=(IGVVSMG2,0,1),END
o Enable the following example SLIP trap to produce GTF trace records to help in identifying software that
allocates user key SCOPE=COMMON data spaces:
SLIP SET,IF,A=TRACE,ID=UCAD,NUCEP=(IAXDKUKY,0,1),END
o Check for usage of the CHANGKEY service to change the storage key of common storage to a key of 8-15.
5. Change the affected software to use a system key rather than a user key. Or, change the affected software to use
storage that is not common to all address spaces. Some alternatives for sharing storage (instead of having storage
common to all address spaces) include the following options:

o Use a SCOPE=ALL data space to share data space storage with specific units of work in specific address
spaces.
o Use IARVSERV SHARE to share below-the-bar storage with specific address spaces.
o Use IARV64 GETSHARED to share above-the-bar storage with specific address spaces.
o Use z/OS UNIX shared memory to share below-the-bar or above-the-bar storage with specific address spaces.
6. For those who cannot immediately eliminate all affected software programs or need more assistance in identifying
the programs that reference user key CSA storage, the more secure restricted use common service area (RUCSA),
an optional priced feature in z/OS V2R4 (and provided in the BCP base element by APAR OA56180 for earlier z/OS
releases) can be used. However, IBM still recommends the elimination of all user key common storage. For more
information about RUCSA and upgrading to it, see z/OS MVS Initialization and Tuning Guide.
Reference information
For more information, see the following references:
• For information about IBM Health Checker, see IBM Health Checker for z/OS User's Guide.
• For information about SMF records, see z/OS MVS System Management Facilities (SMF).
• For information about the z/OS V2R4 RUCSA optional priced feature, see:
o z/OS Introduction and Release Guide
o z/OS Planning for Installation

DFS/SMB: Use Network File System (NFS) instead of DFS/SMB
Required if you currently are using Server Message Block.
As of z/OS V2R4, the z/OS operating system no longer supports Distributed File System / Server Message Block
(DFS/SMB). Originally, the z/OS Distributed File Service base element consisted of two components: SMB and z/OS
File System (zFS). In z/OS V2R4, the name of the base element is changed to z/OS File System.
If you need to share files between z/OS and Microsoft Windows, IBM recommends that you use the Network File
System (NFS) protocol instead of DFS/SMB. NFS also allows for the sharing of z/OS data with UNIX and Linux
systems.
NFS is the strategic file sharing protocol for the z/OS platform. To help your installation upgrade to NFS, IBM plans to
deliver new NFS function on existing levels of the operating system, including installation, security, availability, and
operational enhancements. These planned enhancements are intended to help you more easily migrate to NFS before
you upgrade to the next release of z/OS.
To determine whether your system uses DFS/SMB, use health check
IBMUSS,ZOSMIGV2R3_NEXT_USS_SMB_DETECTED. This check, which is added by APAR OA56251, is
available for z/OS V2R3 and z/OS V2R2 systems.
Upgrade action: Do the following:
1. Determine whether your system uses DFS/SMB. To do so, use health check
IBMUSS,ZOSMIGV2R3_NEXT_USS_SMB_DETECTED.
2. If so, stop using DFS/SMB.
3. Verify that NFS is configured and running.
NFS provides two z/OSMF workflows to aid the system administrator, as follows:
• Workflow for Installing and Configuring the z/OS NFS Server
Guides the system administrator through the process of setting up the z/OS NFS Server. This workflow
provides information on the initial installation of the NFS server. You might find it to be helpful, if you have
not set-up NFS before.

• Workflow for Migration from z/OS DFS/SMB to z/OS NFS
Describes the steps that the system administrator must perform to have z/OS NFS provide function that is
similar to an existing z/OS DFS/SMB configuration.
For more information about these workflows, see APAR OA56186.
4. Use the equivalent functions in NFS.
Reference information: For more information about NFS, see z/OS Network File System Guide and Reference.

Withdrawn in z/OS V2R4 (last delivered in z/OS V2R3)
This section lists items that IBM has announced it has removed in z/OS V2R4. You are encouraged to consider
these removals when making your plans for system upgrades. These statements represent IBM's current intentions.
IBM development plans are subject to change or withdrawal without further notice.
• z/OS V2.3 is the last release of z/OS to support the Server-Requester Programming Interface (SRPI). SRPI
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. Customers with applications using
SRPI should start using TCP/ IP for z/OS to provide similar function. Documentation for SRPI is available in
TSO/E Guide to the Server-Requester Programming Interface, SA22-7785, and this publication as well as
documentation for SRPI-related functions, such as the MVSSERV command, will be removed.
• Infoprint Server intends to enable dynamic configuration as the default behavior. This change in default
behavior will be mandatory and not reversible. You can disregard this statement if you already enabled
dynamic configuration. See the Infoprint Server Customization publication (SA38-0691) for details on how to
enable and the advantages of enabling dynamic configuration. Some advantages of enabling dynamic
configuration include:
o Authorized administrators can use the Infoprint Server ISPF panels or the Printer Inventory
Definition Utility (PIDU) to view and change the dynamic attributes rather than editing the
/etc./Printsrv/aopd.conf file.
o If you change an attribute in the system configuration definition, with a few exceptions, you do not
need to stop and restart Infoprint Server for the change to take effect.
o You can configure Infoprint Server to start and stop individual daemons.
o You can benefit from new functions in Infoprint Server that require dynamic configuration. For
example, you can use the MVS system logger function.

• z/OS V2R3 is the last release to support z/OS Batch Runtime. This component provides a framework for
interoperability between PL/I, COBOL, and Java applications that run on z/OS. It is designed to provide a
managed environment that enables shared access to a DB2 connection by PL/I, COBOL, and Java
programs. It is recommended that you use IBM WebSphere® Application Server JSR 352 instead. Doing so
might require you to modify and test your programs in a JSR 352 compliant batch container.
• IBM plans to discontinue delivery of z/OS platform products and service on magnetic tape on July 1, 2018.
This fulfills the statement of direction in IBM United States Software Announcement 217-085, "Preview: IBM
z/OS Version 2 Release 3 - Engine for digital transformation," dated February 21, 2017. IBM recommends
downloading products and service over the Internet. However, if you have a requirement for physical
media, products and service remain available on DVD.
• z/OS V2.3 is planned to be the last release of the operating system to provide national language translation
in languages other than Japanese. As such, the handful of z/OS elements that provide message and panel
translation to Chinese (Simplified and Traditional), Danish, Dutch (Netherlands), French (including Canadian
French), German (including Swiss German), Italian, Korean, Norwegian, Portuguese (Brazilian), Spanish,
and Swedish today, will no longer provide translations into these languages in the release after z/OS V2.3.
• z/OS V2.3 is planned as the last release to include the z/OS BookManager READ and Library Server base
elements, the latter of which includes the BookRead API. Over time, IBM's platform for delivering product
documentation to customers has evolved to IBM Knowledge Center technology, and production of
documentation formats that are supported by BookManager Read and Library Server has greatly
diminished. IBM recommends now using IBM Knowledge Center for z/OS (KC4z), which was introduced as
a base element of z/OS in version 2.2, to maintain local repositories of product documentation and serve
content.
• OSA Support Facility (OSA/SF) is an element of z/OS that has been used to configure devices on Open
Systems Adapter (OSA) cards used for the SNA protocol and to support and manage all OSA features.
OSA/SF in z/OS has both a graphical user interface as well as a REXX API. On EC12/BC12 systems, IBM
introduced support to configure these devices on the latest generation OSA adapters (OSA Express5S) and
to support and manage these adapters exclusively using the Hardware Management Console (HMC), with
no capability to configure or manage devices on these adapters provided in the z/OS OSA/SF application.
The OSA/SF on the HMC functionality can be used to configure and manage OSA-Express4S and newer
generation adapters. No change to the OSA cards' strategic importance to z/OS is meant by this change.
z/OS continues to support the networking operational use of OSA adapters.
• z/OS V2.3 is the last release to include the SMP/E Planning and Migration Assistant (PMA). The set of
functions provided by PMA, which was introduced in 1998, has largely been supplanted by newer functions
provided by Shopz and by z/OSMF Software Management or duplicate other functions available in SMP/E.
For those functions, IBM recommends you use the replacements instead. However, no replacements are
planned for the Intermediate Product Migration Changes report or for the PMA ISPF tables. With this
removal and repackaging of SMP/E, it has become as exclusive base element to z/OS.

Planned for removal in the releases following z/OS V2R4
This section lists items that IBM has announced it intends to remove in the releases after z/OS V2R4 and beyond.
You are encouraged to consider these removals when making your plans for system upgrades. These statements
represent IBM's current intentions. IBM development plans are subject to change or withdrawal without further
notice.
• The release after /OS V2.3 is planned to be the last release of the operating system to support the HFS
(Hierarchical File System) data structure used by the z/OS UNIX environment. IBM has provided equivalent
if not superior functionality with the z/OS File System (zFS). Customers should migrate from HFS to zFS
using the utilities provided in the operating system to convert their entire file system hierarchy.
• z/OS V2.4 is planned to be the last release to support the ISPF Workstation Agent (WSA), also known as
the ISPF Client/Server Component. WSA is an application that runs on your local workstation and maintains
a connection between the workstation and the ISPF host. It is primarily used to transfer files between the
workstation and the host. IBM recommends using more current file transfer solutions such as those
provided by the Zowe Dataset Explorer, z/OS FTP, and similar file transfer mechanisms. These solutions
have more capabilities, including the ability to provide secure communications.
• z/OS V2.4 is planned to be the last release to support the VTAM Common Management Information
Protocol (CMIP). CMIP services is an API that enables a management application program to gather
various types of SNA topology data from a CMIP application called the topology agent that runs within
VTAM. IBM recommends using the SNA network monitoring network management interface (NMI) to
monitor SNA Enterprise Extender and High Performance Routing data.
• IBM announced that JES2 is the strategic Job Entry Subsystem (JES) for the z/OS Operating System and
that JES3 would continue to be supported and maintained. To date, IBM has made significant investment in
JES2 by delivering unique functions such as email support in JCL, spool migration and merge, and dynamic
checkpoint expansion and tuning to make management easier. In z/OS V2.4, IBM plans to deliver in JES2
Spool Encryption and a new user exit alternative based on defining policies that allow exit programs to be
implemented in a parameterized rule-based approach. To help JES3 to JES2 migration efforts, JES2 has
added functionality, including dependent job control, deadline scheduling, 8-character job classes, and
interpreting JES3 JECL control statements. For z/OS V2.4, additional function to aid in migrations is
planned, including Disk Reader capability and enhanced JES3 JECL support in JES2 (ROUTE XEQ).
Today, as a result of our strategic investment and ongoing commitment to JES2, as well as continuing to
enhance JES3 to JES2 migration aids, IBM is announcing that the release following z/OS V2.4 is planned to
be the last release of z/OS that will include JES3 as a feature. If you are one of the clients who remains on
JES3, IBM encourages you to start planning your migration. For questions, contact jes3q@us.ibm.com.
• z/OS V2.4 is planned to be the last release in which the z/OS TN3270E Telnet server, FTP server, and
Digital Certificate Access Server (DCAS) will support direct invocation of System SSL APIs for TLS/SSL
protection. In the future, the only TLS/SSL protection option for these servers will be Application
Transparent Transport Layer Security (AT-TLS). The direct System SSL support in each of these
components is functionally outdated and only supports TLS protocols up through TLSv1.1. IBM
recommends converting your TN3270E Telnet, FTP server, and DCAS configurations to use AT-TLS, which
supports the latest System SSL features, including the TLSv1.2 and TLSv1.3 protocols and related cipher
suites. Note that while native TLS/SSL support for z/OS FTP client is not being withdrawn at this time, no
future enhancements are planned for that support. IBM recommends using ATTLS to secure FTP client
traffic.
• z/OS V2.4 is planned to be the last release of z/OS to allow specifying service coefficients in the Workload
Manager (WLM) service definition on the Service Definition Details page. The IBM recommended values are
CPU=1, SRB=1, MSO=0, and IOC=0, which will be the default values in a later release. IBM recommends
that you adjust your service coefficients before upgrading to a later release.
• z/OS V2.4 is planned to be the last release to support EIM (Enterprise Identity Mapping) and OCSF (Open
Cryptographic Services Facility), and all of its plug-ins, such as OCEP (Open Cryptographic Enhanced Plug-
ins) and PKITP (PKI Services Trust Policy). These components have not been widely utilized nor enhanced
for several releases of z/OS. IBM recommends using other applications such as ICSF (Integrated
Cryptographic Services Facility) and System SSL for comparable functionality.
• z/OS V2.4 will be the last release that the Network Configuration Assistant (NCA) z/OS MF plug-in supports
the policy data import function, which allows you to import existing Policy Agent configuration files into the
Network Configuration Assistant. After z/OS V2.4, import of policy configuration files will no longer be
supported for AT-TLS, IPSec, PBR, and IDS technologies. Import of TCP/IP profiles into NCA is not
affected.

• z/OS V2.4 is planned to be the last release to support the z/OS MF classic-style user interface (the tree
mode interface) and in future releases will only support the desktop-style user interface. The z/OS MF
desktop-style user interface supports all the functions that the traditional tree mode interface does, and
provides a more modernized and personalized UI, by displaying the z/OS MF tasks in a desktop style with
task icons, taskbar, and other desktop elements that can be user tailored, which allows users to interact with
z/OS using a familiar interface that is similar to other operating environments. The desktop UI also has more
capabilities, such as the ability to search for data set names, quickly locate a task, group tasks in a folder,
and perform similar actions.
• z/OS V2.4 is planned to be the last release of z/OS to support DFSMSrmm Web Services. Today, RMM
provides support for remote JavaTM applications to connect to the RMM application programming interface
(API) running on a z/OS system over the internet via a package that is deployed on a web server such as
z/OS WebSphere(R) Application Server or Apache Tomcat. Use of the RMM API, which accesses the RMM
control data set to obtain information about RMM managed resources, would still be available to
applications using either high-level or assembler languages.
To determine if you are using RMM's Web Services support, verify if you have the following packages
deployed: /usr/lpp/dfsms/rmm/rmmapi.ear for IBM WebSphere and /usr/lpp/dfsms/rmm/rmmapitc.war for
Apache Tomcat. This can also be checked by listing the deployed web applications in the Tomcat Web
application Manager or on the WebSphere Integrated Solutions console.

z/OS Ordering and Deliverable Key Dates
Key dates for recent z/OS releases and functions:
• October 17, 2016: Availability date for the Cryptographic Support for the z/OS V2R1-V2R2 web
deliverable. (The FMID is HCR77C0.)
• September 14, 2017: Availability date for the Cryptographic Support for the z/OS V2R1-V2R3 web
deliverable. (The FMID is HCR77C1.)
• September 15, 2017: Ordering starts for z/OS V2.3
• September 29, 2017: z/OS V2.3 general availability.
• January 29, 2018: All ordering of z/OS V2.2 is completed.
• December 2018: Availability date for the Cryptographic Support for the z/OS V2R2-V2R3 web deliverable.
(The FMID is HCR77D0.)
• September 13, 2019: Ordering starts for z/OS V2.4
• September 2018: Availability date for the Cryptographic Support for the z/OS V2R2-V2R4 web deliverable.
(The FMID is HCR77D1.)
• September 27, 2017: z/OS V2.4 general availability.
• January 2020: Ordering complete for z/OS V2.3.
Web deliverables
Sometimes enhancements are provided as Web deliverables, and not integrated in your ServerPac or CBPDO
deliverable. For example, some of the ICSF enhancements are available this way. z/OS Web deliverables are
available from http://www.ibm.com/eserver/zseries/zos/downloads/. They are packaged as two files that you
download:
 A readme file, which contains a sample job to uncompress 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.

 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 perform the SMP/E installation work yourself.
Cryptographic Support for z/OS V2.1-V2.3 Web deliverable (ICSF FMID HCR77C1). This web deliverable
supports z/OS V2.1, V2.2, and V2.3. This Web deliverable contains support for Crypto Express6S coprocessors
available on z14 processors. These updates are intended to help clients meet standards and provide better
cryptographic security. ICSF enhancements for the Crypto Express6S updates are intended to include support for a
PCI HSM (“Payment Card Industry Hardware Security Module”) configured CCA coprocessor. This Web deliverable
also contains other enhancements.
Cryptographic Support for z/OS V2R2-V2R3 Web deliverable (ICSF FMID HCR77D0) was available December
2018. This web deliverable supports z/OS V2.2 and V2.3. This download provides ICSF enhancements for Crypto
Express5S (CCA Release 5.4 and later) and Crypto Express6S (CCA Release 6.1 and later). Additional
enhancements to ICSF available in this download provide support for:
• CCA redirection for Regional Crypto Enablement. Certain CCA callable services will have the ability to direct
the request to a regional crypto device. This enhancement introduces the concept of "RCS Redirection"
through a new XFACILIT resource, and adds the concept of an "RCS Token" to existing symmetric key
token types.
• ChaCha20 and Poly1305 algorithms. These new algorithms will be available via the PKCS#11 interfaces
and clear key only.
• Dynamic Service Update. Applying service to a running ICSF instance without causing an interruption to
their applications. When ICSF service is available on a system, ICSF will have a new operator command
that will allow running requests to finish, pause incoming requests, prepare to restart with the service
libraries, and then stop ICSF. Through system automation (preferred), ICSF will be restarted and the
paused requests will be resumed without a visible interruption.
• Early ICSF. ICSF will now be able to start much earlier in the IPL process, such that ICSF should be
available for work as early as full function start. ICSF is also adding new ways to provide installation options
via a more standard PARMLIB interface.
• KGUP and SAF profile prefixing. KGUP can be made to honor CSFKEYS resource profiles, configured to
require higher permission when performing destructive operations on an existing key (such as UPDATE or
DELETE), permit a user or group to a CSFKEYS resource but only for specific callable services, and have
ICSF prepend a system name to a CSFKEYS resource prior to the SAF check.
• A new ISPF browser added for the PKDS.
• A new DISPLAY ICSF, MKVPs operator command.
• …and much more.
Cryptographic Support for z/OS V2R2-V2R4 Web deliverable (ICSF FMID HCR77D1) was available September
2019. This web deliverable supports z/OS V2.2, V2.3, and V2.4. ICSF provides the following new features:
• Support for the new Crypto Express7S adapter, configured as a CCA coprocessor, an EP11 coprocessor, or
an accelerator.
• The ability to use CP Assist for Cryptographic Functions (CPACF) for certain clear key ECC operations.
ICSF can now call CPACF instructions to perform ECC key generation, key derivation, and digital signature
generation and verification using a subset of the NIST curves. The CPACF on IBM z15 also supports the
ed448 and ec25519 curves.
• A new SMF record whenever a master key is changed. Certain compliance regulations mandate the
periodic rotation of encryption keys, including the master keys loaded into coprocessors. As part of the
master key change process, an SMF record will now be written every time the new master key is promoted
to the current master key as part of the change master key ceremony.
• A health check that verifies a system's ability to use the NIST recommended PSS signature algorithms. It is
not obvious that the ECC master key is required when generating and using RSA keys enabled for PSS
signatures, so a health check will help clients understand the need for this additional master key so they can
begin to exploit the recommended algorithms.
• New quantum safe algorithms for sign and verify operations. With this release of ICSF, it is now possible to
use quantum safe encryption algorithms for digital signature operations, which also includes the ability to
generate and store new keys. These algorithms will be clear key only and available via the PKCS #11
interfaces.
• Support for CCA Release 5.5 and CCA Release 6.3 including:

o New services in support of ANSI TR-34 Remote Key Loading.
o PCI HSM Compliance for AES and RSA keys.
o Additional AES based financial services.
o Note: These functions were made available on ICSF FMD HCR77D0 with PTFs for APAR
OA57089.

z/OS ICSF Release Levels
The support for cryptography (z/OS base element ICSF) has been delivered via Web deliverables and release
incorporations over the years.
z/OS Releases and Crypto Web Deliverables
Deliverable General availability Delivery method
z/OS V2R1, FMID HCR77A0
Incorporated
September 30, 2013 New release of products
Cryptographic Support for z/OS V1R13-
V2R1 (FMID HCR77A1)
September 20, 2013 Web deliverable
Enhanced Cryptographic Support for z/OS
V1.13–V2.1 (FMID HCR77B0)
February 2015 Web deliverable
V2R2 (FMID HCR77B1)
November 2015 Web deliverable
V2R2 (FMID HCR77C0)
October 2016 Web deliverable
V2R3 (FMID HCR77C1)
September 2017 Web deliverable
z/OS V2R2, FMID HCR77B0
Incorporated
V2R2 (FMID HCR77B1)
November 2015 Web deliverable
V2R2 (FMID HCR77C0)
October 2016 Web deliverable
V2R3 (FMID HCR77C1)
V2R3 (FMID HCR77D0)
December 2018 Web deliverable

V2R4 (FMID HCR77D1)
z/OS V2R3, FMID HCR77C0
Incorporated
V2R3 (FMID HCR77C1)
V2R3 (FMID HCR77D0)
December 2018 Web deliverable
V2R4 (FMID HCR77D1)
z/OS V2R4, FMID HCR77D0
Incorporated
Planned for September 2019 New release of products
V2R4 (FMID HCR77D1)
Refer to this technote: http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103782 for a complete
history of ICSF deliverables, and functions contained in those deliverables.

XML Toolkit for z/OS Version 1 Release 10 (5655-J51, 5655-I30)
The XML Parser, C++ Edition has been updated with the following support:
 Ability to optionally utilize z/OS XML System Services (z/OS XML) as an underlying parsing technology when
performing DOM (Document Object Model) and SAX2 (Simple API for XML) based parsing operations. Support
is provided for both non-validating parsing as well as validating parsing utilizing schema based on the W3C
Schema recommendation. This enhancement is provided by way of a set of new z/OS-specific parser C++
classes that are similiar in name to and closely mimic the existing DOM and SAX2 interfaces. Utilizing z/OS
XML provides redirection to zAAP specialty processors of the portion of the XML parsing operation performed
by z/OS XML and may result in significant improved raw performance as well.
 A new feature that supports importing multiple schemas with the same namespace.
 Improved source offset support, enhancing the ability to obtain information that correlates parsed output with the
associated data in the input document being parsed. This new support is included in the new z/OS-specific
IBM 31-bit SDK for z/OS V8 (5655-DFH, 5655-I48) available March 6, 2015
The 31-bit SDK for z/OS Version8 has been enhanced to:
• Deliver a comprehensive Java SDK at the SE level 8 for the IBM(R) z/OS platform
• Include the enhancements to z/OS Java unique security and JZOS functionality
• Exploit new capabilities available with z/OS V2.1 and V2.2, as announced in Software Announcement 215-
006, dated January 14, 2015,and IBM z SystemsTM z13TM, as announced in Hardware Announcement
115-001, dated January 14, 2015.
• Provide improved performance using the Data Access Accelerator API for processing native data records
and types directly from Java code
• Provide enhanced monitoring and diagnostics
• Contain the JZOS and z/OS unique security enhancements of previous z/OS Java SDK products.
IBM 64-bit SDK for z/OS V8 (5655-DGG, 5655-I48) available March 3, 2015
The 64-bit SDK for z/OS Version 8 has been enhanced to (similar to the 31-bit SDK V8):
• Deliver a comprehensive Java SDK at the SE 8 level for the IBM(R) z/OS platform
• Include the enhancements to z/OS Java unique security and JZOS functionality

• Exploit new capabilities available with z/OS V21. and V2.2, as announced in Software Announcement 215-
006, dated January 14, 2015,and IBM z Systems z13, as announced in Hardware Announcement 115-001,
dated January 14, 2015.
• Provide improved performance using the Data Access Accelerator API for processing native data records
and types directly from Java code
• Provide enhanced monitoring and diagnostics
• Contain the JZOS and z/OS unique security enhancements of previous z/OS Java SDK products.
IBM SDK for Node.js - z/OS V8.0.0 (5655-DKN, 5655-SDS) available June 14, 2019
Node.js is one of the fastest growing language runtimes in the market with a large open source community.
Available and supported on z/OS, IBM SDK for Node.js - z/OS provides extra security and performance by
leveraging the capabilities of IBM Z.
SDK for Node.js - z/OS, V8.0 is the follow-on product to SDK for Node.js - z/OS, V6.0. SDK for Node.js - z/OS, V8.0
is upgraded to the open source Node.js V8.0 level and includes performance improvements and additional features.
SDK for Node.js - z/OS can take advantage of the colocation of your data and existing applications on IBM Z to
significantly increase throughput and reduce response time. You can control which data will be exposed externally,
while keeping all confidential data secure inside the Z platform.
The IBM Z stack is designed with large I/O capacity to support high volumes of transactions. Node.js applications on
z/OS exploit the underlying asynchronous I/O support in z/OS and Z hardware, to scale to thousands of connections
with minimal overhead. New in SDK for Node.js - z/OS, V8, application developers can leverage the C++ compiler
with EBCDIC and ASCII execution character sets shipped with Node.js V8 to build optimized native npm add-ons.
End of Service Dates for Older IBM XML and Java SDK levels:
• XML V1R9 was out of service on September 30, 2013.
• IBM 64-bit SDK for z/OS, Java 2 Technology Edition, V1 Release 4 (5655-I56): was out of service as of
September 30, 2008.
• IBM 31-bit SDK for z/OS, Java 2 Technology Edition, V1 Release 4 (5655-M30): was out of service as of
September 30, 2011. z/OS R11 was the last release for which IBM SDK V1R4 support was available.
• IBM 64-bit SDK for z/OS, Java 2 Technology Edition, V5 Release 0 (5655-N99): was out of service as of
September 30, 2013.
• IBM 31-bit SDK for z/OS, Java 2 Technology Edition, V5 Release 0 (5655-N98): was out of service as of
September 30, 2013.
• IBM 64-bit SDK for z/OS V6 Release 0 (5655-R32): was out of service as of September 30, 2018.
• IBM 31-bit SDK for z/OS V6 Release 0 (5655-R31): was out of service as of September 30, 2018.
• IBM 64-bit SDK for z/OS V7 Release 0 (5655-W44): has announced to be end of service as of September
30, 2019.
• IBM 31-bit SDK for z/OS V7 Release 0 (5655-W43): has announced to be end of service as of September
30, 2019.
• IBM 64-bit SDK for z/OS V7 Release 1 (5655-W44): has announced to be end of service as of April 30,
2022.
• IBM 31-bit SDK for z/OS V7 Release 1 (5655-W43): has announced to be end of service as of April 30,
2022.

Service Policy
With the two-year z/OS release frequency, the z/OS support policy is five years of z/OS support, with three years of
optional extended service (5+3).
Prior to withdrawing service for any version or release of z/OS or z/OSMF, IBM intends to provide at least 12
months notice. The service policy for z/OS also applies to any enhancements (including but not limited to web
deliverables), such as the RSM Enablement Offering for z/OS R13 which was provided for z/OS R13.
See the table below for expiration dates for service support.
Version and release General availability (GA) End of service (EOS)
OS/390 V2R8 24 September 1999 Occurred 30 September 2002
OS/390 V2R9 31 March 2000 Occurred 31 March 2003
OS/390 V2R10 29 September 2000 Occurred 30 September 2004
z/OS V1R1 30 March 2001 Occurred 31 March 2004
z/OS V1R2 26 October 2001 Occurred 31 October 2004
z/OS V1R3 29 March 2002 Occurred 31 March 2005
z/OS V1R4 27 September 2002 Occurred on 31 March 2007
z/OS V1R5 26 March 2004 Occurred on 31 March 2007
z/OS V1R6 24 September 2004 Occurred on 30 September 2007
z/OS V1R7 30 September 2005 Occurred on 30 September 2008 *
*The “z/OS V1.7 Lifecycle Extended Service” offering
expired on 30 September 2010. If you require support
for defects for z/OS V1R7 beyond September 2010,
contact an IBM representative for a special bid.
z/OS V1R8 29 September 2006 Occurred 30 September 2009 *

*The “z/OS V1.10 Lifecycle Extended Service”
offering expired on 30 September 2013. If you require
support for defects for z/OS V1R10 beyond September
2013, contact an IBM representative for a special bid.
*See “z/OS V1.11 Lifecycle Extended Service” below
for a fee-based accommodation, through 30
September 2014.
*See “IBM Software Support Services for z/OS
V1.11” below for a fee-based accommodation,
through 30 September 2016.
z/OS V1R12 24 September 2010 Occurred 30 September 2014
*See “IBM Software Support Services for z/OS
V1.12” below for a fee-based accommodation,
through 30 September 2017
z/OS V2R2 30 September 2015 Announced for September 2020
z/OS V2R3 29 September 2017 Planned for September 2022
z/OS V2R4 Planned for September
2019
Planned for September 2024
IBM Software Support Services for z/OS V1.13 – starting October 1, 2016
If you wish to purchase extended service on z/OS V1R13, contact your IBM representative.
IBM Software Support Services for z/OS V2.1 – starting September 29, 2018
If you wish to purchase extended service on z/OS V2R1, contact your IBM representative.

z/OS Coexistence
Coexistence 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 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:
• A single processor that is time-sliced to run different levels of the system, such as during different times of
the day
• A single processor running multiple images by means of logical partitions (LPARs)
• Multiple images running on several different processors
• Parallel Sysplex or non-Parallel Sysplex configurations
Note: The term coexistence does not refer to z/OS residing on a single system along with VSE/ESA, VM/ESA, or
z/VM in an LPAR or as a VM guest.
z/OS systems can coexist with specific prior releases. This is important because it gives you flexibility to migrate
systems in a multisystem configuration using rolling IPLs rather than requiring a systems-wide IPL. The way in
which you make it possible for earlier-level systems to coexist with z/OS is to install coexistence service (PTFs) on
the earlier-level systems.

You should complete the upgrade of all earlier-level coexisting systems 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:
• The release to which you're migrating falls is supported for coexistence, fallback, and upgrade with the
releases running on the other systems.
• The appropriate coexistence PTFs have been installed on the other systems in the multisystem
configuration.
Even when you're 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. 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 (backout) is a return to the prior level of a system. Fallback can be appropriate if you migrate to z/OS V2R2
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 made by the
later-level release.
As a general reminder, always plan to have a backout path when installing new software by identifying and installing
any service required to support backout.
Fallback is at a system level, rather than an element or feature level.
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 z/OS V2R4 level before the new functions
can be used. Therefore, be careful not to exploit new functions until you are fairly confident that you will not need to
back out your z/OS V2R4 systems, as fallback maintenance is not available in these cases. You should consult the
appropriate element or feature documentation to determine the requirements for using a particular new function.
Which releases are supported for coexistence, fallback, and upgrade?
• IBM plans to continue to support an n-2 (three consecutive release) coexistence, fallback, and upgrade
policy.
• Do note that with the two-year release cycle that z/OS support is intended for five years with three optional
extended service years (5+3). You should plan on completing your upgrade plans during the period of time
while your older z/OS release is still in service.

• Starting with z/OS R6, IBM has aligned the coexistence, fallback, and upgrade policy with the
service policy. IBM intends to continue with the practice of providing coexistence, fallback, and policy
support for those releases which are still in support. As a general rule, this means that three z/OS and
Thus, z/OS V2R3 is coexistence, fallback, and upgrade supported with the following two z/OS releases:
V2R1 and V2R2. This means that:
• Coexistence of a V2R3 system with a V2R1 or V2R2 system is supported.
• Fallback from V2R3 to V2R1 or V2R2 is supported.
• Upgrade to V2R3 from V2R1 or V2R2 is supported
z/OS V2R4 is coexistence, fallback, and upgrade supported with the following two z/OS releases: V2R2 and
V2R3. This means that:
• Coexistence of a V2R4 system with a V2R2 or V2R3 system is supported.
• Fallback from V2R4 to V2R2 or V2R3 is supported.
• Upgrade to V2R4 from V2R2 or V2R3 is supported
The z/OS coexistence, fallback, and upgrade 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 integration
testing and will provide service as necessary to support the z/OS coexistence, fallback, and upgrade policy.
See the table below for a summary of current and planned coexistence, fallback, and upgrade support.
These statements represent IBM's current intentions. IBM reserves the right to change or alter the coexistence,
fallback, and upgrade 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.
Releases that are coexistence, fallback, and upgrade supported as of z/OS R10
z/OS
release
Releases that
are coexistence,
fallback, and
upgrade
supported with
the release in
column Explanation
R10 R10, R9, R8 General availability of R10 was September 26, 2008. R8 is the oldest release that is service
supported at that time and therefore the oldest release that is coexistence, fallback, and
upgrade supported with R10.
R13 R13, R12, R11 General availability for R13 was September 30, 2011. R11 is the oldest release that is service
V2R1 V2R1, R13, R12 General availability for V2R1 was September 30, 2013. R12 is the oldest release that is
service supported at that time and therefore the oldest release that is coexistence, fallback,
and upgrade supported with V2R1.
V2R2 V2R2, V2R1, R13 General availability for V2R2 was September 30, 2015. R13 is the oldest release that is
V2R3 V2R3, V2R2,
V2R1
General availability for V2R3 was September 29, 2017. V2R1 is the oldest release that is

V2R4 V2R4, V2R3,
V2R2
General availability for V2R4 is planned for September 2019. V2R2 is the oldest release that
is service supported at that time and therefore the oldest release that is coexistence, fallback,

z/OS Documentation: Where to Start
To gain an overview of z/OS and plan for the installation, review:
 z/OS V2R4 Upgrade Workflow
 z/OS V2R4 Planning for Installation
 zSeries Platform Test Report for z/OS and Linux Virtual Servers (formerly, the z/OS Parallel Sysplex Test
Report)
 z/OS V2 R4 Introduction and Release Guide - great for finding new functions in a release to exploit!
To install z/OS, review Preventive Service Planning (PSP) Buckets for:
 ServerPac (if using ServerPac to install)
 z/OS and individual elements (including ZOSGEN, which helps you with general z/OS level information)
 Hardware, if you will using specific HW functions or upgrading your server
In addition, to install z/OS using ServerPac, review:
 ServerPac: Using the Installation Dialog (SC28-1244)
 The custom-built installation guide, ServerPac: Installing Your Order
To install z/OS using CBPDO, review the z/OS Program Directory.
PSP Buckets
z/OS, and most products that run on it, provide files containing information that became available after the product
documents were printed. Kept on IBM's RETAIN system and also available using IBMLink, these files are called
preventive service planning (PSP) "buckets", or just "PSPs". 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, refer to z/OS Program Directory. 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).
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. Use the PSP Web site
(http://www14.software.ibm.com/webapp/set2/psearch/search?domain=psp) for the contents of the buckets.
The upgrade for the z/OS V2.4 PSP bucket is ZOSV2R4. Recognizing that there are many PSP buckets to review,
z/OS uses descriptive element names, instead of FMIDs for the subsets. This reduces the number of PSP buckets
that must be reviewed, since most elements are composed of multiple FMIDs. There are subsets in the ZOSV2R4
upgrade for general topics (ZOSGEN), and for the ServerPac deliverable (SERVERPAC) that should be reviewed
also. DFSMS is consolidated into one subset. All PSP upgrades and subset IDs are listed in the z/OS Program
Directory. However, the non-exclusive elements' stand-alone product upgrade and subsets are used.
Hardware PSP upgrade identifiers
Hardware PSP bucket upgrade IDs are in the form xxxxDEVICE and contain the latest software dependencies for
the hardware, and recommended PTFs and APARs required for specific processor models. The PSP hardware
upgrade identifiers are:
• 8561DEVICE for the z15 server.
o The FIXCAT names are IBM.Device.Server.z15-8561.RequiredService, IBM.Device.Server.z15-
8561.Exploitation, and IBM..Device.Server.z15-8561.RecommendedService.
• 3907DEVICE for the z14 ZR1 server.
o The FIXCAT names are IBM.Device.Server.z14ZR1-3907.RequiredService, IBM.Device.Server.
z14ZR1-3907.Exploitation, and IBM.Device.Server. z14ZR1-3907.RecommendedService.
o The FIXCAT names are IBM.Device.Server.z14-3906.RequiredService, IBM.Device.Server. z14-
3906.Exploitation, and IBM.Device.Server. z14-3906.RecommendedService.
• 2965DEVICE for the z13s server.
o The FIXCAT names are IBM.Device.Server.z13S-2965.RequiredService, IBM.Device.Server.z13s-
2965.Exploitation, and IBM.Device.Server.z13s-2966.RecommendedService.

o The FIXCAT names are IBM.Device.Server.z13-2964.RequiredService, IBM.Device.Server.z13-
2964.Exploitation, and IBM.Device.Server.z13-2964.RecommendedService.
• 2828DEVICE for the zBC12 server.
o The FIXCAT name is IBM.Device.Server.zBC12-2828.
• 2827DEVICE for the zEC12 server.
o The FIXCAT name is IBM.Device.Server.zEC12-2827.
Specific functions for each server also have corresponding FIXCATs.
Verifying the PTFs in the PSP buckets are installed
• To simplify finding the appropriate PSP bucket and identifying which PTFs listed in the PSP bucket need to
be installed on your system, use the SMP/E REPORT MISSINGFIX command in conjunction with the
FIXCAT type of HOLDDATA. For complete information about the REPORT MISSINGFIX command, see
SMP/E Commands. For a description of what FIXCATs are available, go to
http://www.ibm.com/systems/z/os/zos/smpe/ and click on “Guide to fix category values and descriptions”.
DASD Storage Requirements
Keep in mind the DASD required for your z/OS system includes all z/OS elements (per the z/OS Policy). That is, it
includes ALL elements, ALL features that support dynamic enablement, regardless of your order, and ALL unpriced
features that you ordered. This storage is in addition to the storage required by other products you might have
installed. All sizes include 15% freespace to accommodate the installation of maintenance.
The estimated total storage required for z/OS V2.4 data sets is provided below. If you add other products to your
z/OS V2.4 ServerPac, you will need additional space for those other products.
For z/OS V2R4 (as of September 2017):
 The total storage required for all the target data sets is approximately 10,944 cylinders on a 3390 device. This
total size exceeds the space on a 3390-9.
 The total storage required for all the distribution data sets is approximately 19,255 cylinders on a 3390 device.
 The total executable root file system storage is approximately at 4,990 cylinders on a 3390 device when it is an
HFS and 4,980 when it is a zFS. Use IBM Health Checker for z/OS check ZOSMIGREC_ROOT_FS_SIZE to
determine whether a volume has enough space for the z/OS version root file system, available back to z/OS R9
in APARs OA28684 and OA28631.
 z/OS V2.1 introduced the z/OS Font Collection base element. This element installs into a separate file system
(the “font file system”). You may choose to merge the font file system and root file system if you desire.
ServerPac will provide you this file system. The total font file system storage is estimated at 5,500 cylinders on
a 3390 device when it is an HFS or a zFS.
 z/OS V2.3 introduces the IBM z/OS Liberty Embedded base element. This element installs into a separate file
system (the “Liberty file system”). IBM recommends that you keep the Liberty file system separate from other
file systems in case of space fluctuations. ServerPac will provide you this file system. The total Liberty file
system storage is estimated at 2,400 cylinders on a 3390 device when it is an HFS or a zFS.
 z/OS V2.4 introduces the IBM Container Extensions (zCx) base element. This element installs into a separate
file system (the “zCX file system”). IBM recommends that you keep the zCX file system separate from other file
systems in case of space fluctuations. ServerPac will provide you this file system. The total xCX file system
storage is estimated at 5,250 cylinders on a 3390 device when it is an HFS or a zFS.
 For configuration and execution, additional file system space is needed:
 You will need 50 cylinders for the /etc file system (either HFS or zFS).
 For the CIM element, the space required for the /var VARWBEM file system is 94 cylinders primary, 10
cylinders secondary (either HFS or zFS).
m
i
g

 For Predictive Failure analysis, a separate file system, either HFS or zFS, is created and mounted at
mountpoint the /var/pfa. The total space required for zFS or HFS is 300 cylinders primary; 50 cylinders
secondary.
 For z/OSMF additional file system space is needed for the repositories. Refer to your ServerPac installation
or sample jobs provided.
z/OS Driving System Requirements
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.
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 on the driving system before you IPL the target system. If you don't install
the coexistence service, you will probably experience problems due to incompatible data structures (such as
incompatible data sets, VTOCs, catalog records, GRS tokens, or APPC bind mappings).
Customized Offerings Driver (5751-COD)
The Customized Offerings Driver V3.1 (5751-COD) is an entitled driving system you can use if:
• you don't have an existing system to use as a driving system, or
• your existing system does not meet driving system requirements and you don't want to upgrade it to meet
those requirements.
This driver is currently a subset of a z/OS V2R2 system (with the level of SMP/E at V3R6), and is available on a
DVD or electronically.
The Customized Offerings Driver requires three DASD volumes configured as 3390-9, or larger; a non-Systems
Network Architecture (SNA) terminal used for a z/OS MVS™ system console; and a locally attached SNA terminal
for a Time Sharing Option Extended (TSO/E) session. Also, if you select tape media, a tape drive that can read
3590 or 3592 tape is required. The Customized Offerings Driver can also be ordered on DVDs, which removes the
requirement for a tape drive.
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.
As of z/OS V2R2, the Customized Offerings Driver Installation Guide is no longer shipped in hardcopy format.
Instead, this publication is shipped in PDF format on a separate DVD.
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.
Identifying Driving System Software Requirements for ServerPac for z/OS V2R4
Driving system requirements for installing z/OS V2R3 by way of ServerPac or dump-by-data-set SystemPac are:
 An operating system: Use either of the following:
 A supported z/OS release (V2R2 or later), or
 The Customized Offerings Driver V3 (5751-COD).
 A terminal: A locally-attached or network-attached terminal that can be used to establish a TSO/E session on the
IPLed system is required.
 Proper authority: Use the RACFDRV installation job as a sample of the security system definitions required so
that you can perform the installation tasks.
 Proper security:

In order for you to install into the zFS, the user ID you use must have read access to the
SUPERUSER.FILESYS.PFSCTL resource in the RACF FACILITY class.
In order for you to install the z/OS UNIX files, the following is required:
 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.
 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.
 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.)
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 HFS data sets 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. Other sources of information are 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.)
 Language Environment run-time options: As of z/OS R7, ServerPac requires that the following Language
environment run-time options are not specified as nonoverrideable (NONOVR) in the CEEDOPT CSECT:
ALL31, ANYHEAP, BELOWHEAP, DEPTHCONDLIMIT, ERRCOUNT, HEAP, HEAPCHK, HEAPPOOLS,
INTERRUPT, LIBSTACK, PLITASKCOUNT, STACK, STORAGE, THREADHEAP, and THREADSTACK .
 Language Environment: 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.
 OMVS address space active: For ServerPac only (not SystemPac), an activated OMVS address space with
z/OS UNIX kernel services operating in full function mode is required.
 SMS active: The Storage Management Subsystem (SMS) must be active to allocate HFS and PDSE data sets,
whether they are SMS-managed or non-SMS-managed. Also, the use of HFS data sets is supported only when
SMS is active in at least a null configuration, even when the data sets are not SMS-managed. Do either of the
following:
To allocate non-SMS-managed HFS 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.
To allocate SMS-managed HFS 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 PDSE and HFS data
sets with the names in the ALLOCDS job. You must also activate SMS on the target system.
• 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.
 SMP/E ++JARUPD Support: If your ServerPac order contains any product that uses the ++JARUPD support
introduced in SMP/E V3R2, then your driving system will require IBM SDK for z/OS, Java 2 Technology Edition.
 zFS configuration requirements (optional): If you will specify that you will use a zFS for ServerPac installation,
then you must be sure that the zFS has been installed and configured, as described in z/OS Distributed File
Service zSeries File System Administration.

If you intend to receive your order using Secure FTP (FTPS):
 SMP/E V3R6 or higher
 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.
If you intend to download your order using HTTP Secure (HTTPS):
 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.
 Proper level of CustomPac Installation Dialog to support HTTPS downloads. The CustomPac Installation
Dialog must be at a level of 26.20.00 or higher. For further details see "Updating Your Dialogs" and
"required migration step" in ServerPac: Using the Installation Dialog.
 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.
 For instructions on how to set up and verify that your system can connect to the IBM download servers, see
the Connectivity Test for SW Download Readiness web site.
 For more information about how to set up FTPS or HTTPS, see SMP/E for z/OS User's Guide.
If you intend to receive your order by way of DVD, you need the following:
 Order available on z/OS host system. To make the order available on your z/OS host system, upload the
order to the z/OS host from the DVD(s). Refer to readme.pdf on the first DVD to find the various methods for
making your order available on your z/OS host system.
 Space requirements on z/OS. Ensure you have the required space on your z/OS host system. To get the
actual size of the order, refer to dialog.txt on the first DVD.
 Space requirements on a workstation. If you chose to copy your order from the DVD(s) to a workstation
before uploading the contents to your z/OS host system, ensure you have the required space available on
your workstation.
 Proper level for service: In order for you to install service on the target system that you're building, your driving
system must minimally meet the driving system requirements for CBPDO Wave 1 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 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 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.

Target System Hardware Requirements
The minimal hardware requirements for z/OS, as well as additional hardware needed by specific z/OS elements and
features, are documented in z/OS Planning for Installation.
Identifying Processor Requirements
z/OS V2.4 supports these System z server models:
• IBM z15
• IBM z14 and z14 ZR1
• IBM z13 and z13s
• IBM zEnterprise zBC12 and zEC12
The following IBM System z servers, and earlier servers, are not supported with z/OS V2.3 and later releases:
• IBM zEnterprise 196 (z196) and IBM zEnterprise 114 (z114)
• IBM System z10 EC and System z10 BC
Important: If you IPL z/OS on a server that it does not support, you might receive wait state 07B-1E (decimal 30).
The number of IEA434I messages is limited to 32 during IPL/NIP to avoid exhausting initial ESQA. An IEA444I
message will be reported one time during IPL/NIP to indicate that additional IEA434I messages have been
suppressed: IEA444I NUMBER OF IEA434I MESSAGES EXCEEDS NIP MAXIMUM .
Identifying Minimum Storage Requirements as of z/OS V2.3
As of IBM z/OS V2.3 with IBM z14 (or z14 ZR1) will require a minimum of 8 GB of memory. When running as a
z/VM guest or on a IBM System z Personal Development Tool, a minimum of 2 GB will be required. If the minimum
is not met, a warning WTOR will be issued at IPL. Continuing with less than the minimum memory could impact
availability. A migration health check has been introduced back to z/OS V2.1 with PTFs to warn you when an LPAR
on a z14 or ZR1 system has been configured with less than 8 GB.
Identifying Coupling Facility Requirements

There are hardware and software requirements related to coupling facility levels (CFLEVELs). See
http://www.ibm.com/systems/z/advantages/pso/cftable.html
When you change coupling facility control code (CFCC) levels, your coupling facility structure sizes might change. If,
as part of your upgrade to a z14 server, you change CFCC levels, you might have larger structure sizes than you
did previously. If your CFCC levels are identical, structure sizes are not expected to change when you migrate from
a previous server to a newer generation server.
In addition, similar to CF Level 17 and later, ensure that the CF LPAR has at least 512MB of storage.
CFCC Level 22, introduced on the z14, supports the Coupling Facility use of Large Memory to improve availability
for larger CF cache structures and data sharing performance with larger DB2 Group Buffer Pools (GBP) with no
DB2 supporting code required. This support removes inhibitors to using large CF cache structures, enabling use of
Large Memory to appropriately scale to larger DB2 Local Buffer Pools (LBP) and Group Buffer Pools (GBP) in data
sharing environments. If you are moving your coupling facilities and the coupling facility structures will be on higher
CFCC levels than they were previously, run the Coupling Facility Structure Sizer (CFSIZER) tool to find out if you
have to increase coupling facility structure sizes. Prepare to make the necessary changes to the CFCC level as
indicated by the tool.
You can download the CFSIZER tool at Coupling Facility sizer (http://www.ibm.com/systems/support/z/cfsizer/).
Note: After you make a coupling facility available on the new hardware, you can run the Sizer utility, an authorized
z/OS program, to evaluate structure size changes. The Sizer utility is distinct from CFSizer, and should be run after
the new hardware (CFLEVEL) is installed, but before any CF LPAR on the new hardware is populated with
structures. You can download the Sizer utility at http://www.ibm.com/systems/support/z/cfsizer/altsize.html.
 IBM z15 servers initially ship with CFCC level 24.
 IBM z14 ZR1 servers initially ship with CFCC level 23.
 IBM z13s servers initially ship with CFCC level 21.
 IBM zEnterprise zEC12 servers initially shipped with CFCC level 18. After Sept 2013, the zEC12 and zBC12
ship at CFCC level 19.
Identifying z/VM Requirements
If you will be running IBM z/OS V2.4 as a guest under IBM z/VM, the z/VM release must be z/VM 6.4, or later.

Choosing ISV products that you want to run with z/OS V2.4
For a list of independent software vendors (ISVs) that support z/OS V2.4, the file can be downloaded from this
website. https://www.ibm.com/downloads/cas/W7KV1LV2
For a list of independent software vendors (ISVs) that support z/OS V2.3 and V2.3, the file can be downloaded from
this website.
http://ftpmirror.your.org/pub/misc/ftp.software.ibm.com/common/ssi/ecm/97/en/97015397usen/systems-
hardware-other-papers-and-reports-97015397usen-20180420.pdf
For a directory of IBM and IBM Business partners that provide z/OS applications, tools, and services, see the Global
Solutions Directory: http://www.ibm.com/software/solutions/isv

Choosing IBM Products That You Want to Run with z/OS
You must determine the minimum product release levels and release levels for functional requirements. IBM
middleware and application products require a specific level (version, release, or PTF) so that the products will run
on z/OS V2R4. You cannot use the FIXCAT support to determine these release levels. Instead, you can refer to
z/OS V2.4 Planning for Installation, Appendix B, for the functions of z/OS that require specific z/OS optional
features, IBM middleware products, or IBM application products.
If you are upgrading from z/OS V2R2 or z/OS V2R3, you may generally use the product levels on z/OS V2R4
that you used on your prior z/OS release, as long as the product levels are still service-supported.
Note, however, that if you are using any of the functions in z/OS V2.4 Planning for Installation, Appendix B, and
those functions have dependencies on IBM middleware or application products, you must use the product levels
shown (or later).
Many of these products can be ordered as part of your z/OS ServerPac order. Note that there may be differences
between what is minimally service supported, what is minimally supported with z/OS V2R4, and what is currently
orderable.
If you're upgrading to z/OS V2R4, you can find out which products have new levels by using Shopz and loading your
current inventory to see what higher levels of products are orderable.

Tip! Finding End of Service Dates for IBM Products
A handy website for finding end of service dates for IBM products is http://www.ibm.com/software/support/lifecycle/ .
An especially useful way of identifying if any of the products you are approaching or have met end of service is to
use z/OSMF Software Management, and look at the End of Service report!

Programmatic Help with Target System PTF Verification for z/OS V2.4
The IBM PTFs needed to support z/OS V2.4 are identified with a FIXCAT called IBM.TargetSystem-
RequiredService.z/OS.V2R4, in Enhanced HOLDDATA. You must use the SMP/E REPORT MISSINGFIX
command to help identify those PTFs on your current system which would be needed for your upgrade to z/OS
V2R4.
It is a good idea to periodically re-run the REPORT MISSINGFIX command to determine if any new PTFs have
been identified that you are missing.

Using FIXCAT for coexistence PTFs for z/OS V2R4
For coexistence verification for z/OS V2R4, the fix category of interest is IBM.Coexistence.z/OS.V2R4. You can
use the FIXCAT of ++HOLD statement to identify APARs, their fix categories, and the PTF that resolves the APAR.
Another fix category that is helpful when doing the coexistence verification is IBM.Function.HealthChecker, for
verifying that you’ve got the latest migration IBM Health Checks for z/OS installed on your coexisting system.
When FIXCAT HOLDDATA statements are received into a global zone, SMP/E assigns the fix category values as
sourceids to the PTFs that resolve the APARs. These sourceids then simplify selecting and installing required fixes.
During APPLY and ACCEPT command processing you can specify the assigned sourceids on the SOURCEID and
EXSRCID operands to select the SYSMODs associated with a particular fix category.
In addition, for the APPLY and ACCEPT commands you can specify which Fix Categories are of interest using the
new FIXCAT operand. This tells SMP/E to process only FIXCAT HOLDDATA for the categories you specify, and all
others are ignored.
Finally, SMP/E uses the FIXCAT HOLDDATA to identify what required fixes are missing. The REPORT
MISSINGFIX command analyzes the FIXCAT HOLDDATA and determine which fixes (APARs) identified by the
HOLDDATA are not yet installed. Only the fixes associated with the fix categories of interest to you, specified by
you, are analyzed and identified. For example, you can identify only the missing fixes associated with a particular
hardware device or coexistence for a specific new software release.
Note that you can use wildcards in the FIXCAT name in the REPORT MISSINGFIX command. For example, if you
wanted to verify coexistence for z/OS V2R3 as well as z/OS V2R4 on your z/OS V2R2 system, your command
could be:
REPORT MISSINGFIX ZONES(ZOS22T) FIXCAT(IBM.Coexistence.z/OS.V2R*,
IBM.Function.HealthChecker).
Do notice though, that z/OS V2.3 coexistence fixes have also been “backmarked” for z/OS V2.4 coexistence, so it is
not necessary to specify interim z/OS releases for coexistence verification in the REPORT MISSINGFIX command.

Prepare for your upgrade to z/OS V2.4!
In this presentation you’ve seen many things can you can do right now, on your current z/OS release to help make
your z/OS V2R4 upgrade smooth. Listed above are a recap of the things that were shown in this presentation, but
make sure you review the upgrade actions (and look at the z/OS Upgrade Workflow) so that you know a more
complete upgrade picture.

Using IBM Health Checker for z/OS for upgrade purposes
Starting in z/OS V1R10, the Health Checker infrastructure is exploited for upgrade purposes. Health Checks that
are helpful for determining upgrade action applicability are provided. These checks ("Migration Health Checks")
should be used prior to your upgrade to the new z/OS release to assist with your upgrade planning, and re-run after
your upgrade to verify that the upgrade action was successfully performed. As with any Health Check, no updates
are performed to the system. Migration Health Checks only report on the applicability of a specific upgrade action
on a system; and only report on the currently active system.
Details on how to run the Migration Health Checks are provided in beginning of the z/OS Upgrade Workflow.
System REXX health check considerations
All exploiters of the System REXX support in z/OS require that the System REXX customization be performed.
Using the IBM Health Checker for z/OS health checks is one example of possible System REXX exploitation. In
particular, any compiled REXX execs must have the proper runtime support available from the Alternate Library for
REXX (available in z/OS since V1R9) or from the IBM Library for REXX on zSeries (5695-014). Several IBM Health
Checker for z/OS migration health checks have been written in compiled System REXX. These health checks rely
upon the System REXX customization and runtime activities being completed. If System REXX (and the security
environment that System REXX requires) have not been properly customized, then System REXX health checks will
not execute successfully.
o For System REXX customization activities, refer to "System REXX" in z/OS MVS Programming: Authorized
Assembler Services Guide.
o For compiled REXX exec runtime availability, see "Alternate Library for REXX Customization
Considerations" in z/OS Program Directory, or refer to product documentation accompanying IBM Library
for REXX on zSeries.
Migration Health Checks and Best Practice Health Checks
Migration Health Checks are not different from other Health Checks, but they do have some characteristics which
allow them to be uniquely identified.

For z/OS, the convention is ZOSMIGVvvRrr_component_program_name The names of migration checks begin
with the characters ZOSMIG. Following this prefix is a value to help you plan the timing of the upgrade action, as
follows:
• ZOSMIGVvRr_Next : Upgrade action is recommended, but will become a required upgrade action in the
release after VvRr .
• ZOSMIGVvRr_Next2 : Upgrade action is recommended, but will become a required upgrade action two
releases after VvRr.
• ZOSMIGVvRr : Upgrade action is required in the release indicated by VvRr.
• ZOSMIGVvRrPREV: Upgrade action is required in the release indicated by VvRr and in prior releases, with
the appropriate service.
• ZOSMIGREC : Upgrade action is recommended for the foreseeable future. The upgrade action might never
be required.
• ZOSMIGREQ : Upgrade action that is recommended now, but will be required in a future release.
For the ICSF element, the convention is ICSFMIGnnnn_component_program_name ).
Migration checks have a status of INACTIVE by default. Because you may not want to know about upgrade actions
during non-upgrade periods, Migration Health Checks will not automatically be active.
There are Best Practice Health Checks that can help with upgrade actions, and yet they do not have the Migration
Health Check naming convention. That is because the component owners felt that the practice is recommended for
reasons above and beyond upgrade purposes. All Health Checks (whether they are Migration Health Checks or
Best Practice Health Checks) will be cross-referenced in the z/OS Upgrade Workflow when they can assist with a
specific upgrade action. Be aware, your upgrade assistance is not just limited to the checks that follow the
Migration Health Check naming convention!
For description of the health checks above, which release they run on, and their severity refer to the Health Checker
User’s Guide.

Very Important Links:
z/OS V2.4 Upgrade workflow: https://github.com/IBM/IBM-Z-zOS/tree/master/zOS-
Workflow/zOS%20V2.4%20Upgrade%20Workflow
Exported V2.3 to V2.4 Workflow:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0zm100/Export_zOS_V2R3_t
o_V2R4_Upgrade_Workflow.html
Exported V2.2 to V2.4 Workflow:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0zm100/Export_zOS_V2R2_t
o_V2R4_Upgrade_Workflow.html
Content Solution webpage for learning in an easy way about ServerPac packaged as a z/OSMF Portable Software
Instance:
https://www.ibm.com/support/z-content-solutions/serverpac-install-zosmf/
Continuing the advancement in z/OS upgrade assistance!
We have converted the z/OS Migration book into two z/OS Management Facility (z/OSMF) z/OS Upgrade
Workflows. (One for the V2R2 to V2.4 path, one for the V2.3 to V2.4. path.) Using the z/OSMF workflow, you can
go through a z/OS V2.4 upgrade as an interactive, step-by-step process. Depending on your z/OS V2.4 upgrade
path, you select the files you will need. If you do not download all necessary files, your workflow cannot be created.
In z/OS V2.4 (continuing what was introduced in V2.2) the z/OS Upgrade Workflow has the capability to invoke IBM
Health Checker for z/OS health checks directly from the step, and also provides the optional capability to give
feedback on your upgrade experience.
The z/OS V2.4 Upgrade Workflow is the ability to discover used z/OS priced features(continuing what was
introduced in V2.3), and some other features, on your system. This is very helpful, because if you are not using a

certain feature, then why have to manually skip those steps yourself? The z/OSMF Workflow can identify many
features that you might not be using, and automatically skip them in the Workflow for you, giving you less steps to
perform.
This tool is not supported by the IBM Service organization but rather by the tool owner on a best-can-do basis.
Please report any problems, suggestions, or comments to zosmig@us.ibm.com. This userid is actively monitored
and assistance is offered, typically within a couple of hours.
If you would like to see a short demo on using the z/OS V2.1 migration workflow, visit IBM® z/OSMF V2.1 Migration
Workflow Demo on YouTube.
Upgrade Workflow Tips
1. Use discovery to help eliminate unnecessary upgrade actions!
a. To be consistent with the former book, the workflows include some upgrade actions shown
as "None" for components that do not have any upgrade action. "None." still counts as a
workflow sub-task to complete, even though there is no upgrade action to perform. To
complete the sub-task, mark the upgrade action sub-tasks with an "Override-complete" to
have them designated as complete. Choose to “skip none” during the first discovery step.
b. To allow you to skip prior hardware levels you have already upgraded through, choose to
“skip prior hardware level” during the first discovery step.
2. The URL links to the documentation in the workflow cannot go to an anchor in the web page. The
URLs will just bring you to the web page, not content that may be further down in the page. You
may have to scroll down on the web page to find the information that you need.
3. Some upgrade actions have associated health checks. For those steps, the health check will be
invoked to determine if the upgrade action is applicable to your system. Read the instructions
carefully on the Perform tab before running the health check, as important information is provided
for each check.
4. For each upgrade action and for the entire upgrade, you can optionally provide your feedback to
IBM. Just follow the instructions you see in z/OSMF. You do not need to provide feedback to
complete each step of the workflow.
z/OS Upgrade Workflow
Starting in z/OS V2.4, IBM no longer provide the z/OS Migration publication, GA32-0889, in its current format. Since
z/OS V2.2, the preferred method for learning about upgrade actions has been the z/OS Upgrade Workflow.
Discovering, performing, and verifying many upgrade actions through the z/OS MF Workflow function instead of a
more traditional book format allows for a tailored and specific upgrade path associated with a particular system.
Starting with the z/OS V2.4 release and later, IBM provides upgrade tasks in a z/OS MF Workflow, as well as a
single exported file. By providing the z/OS V2.4 upgrade materials in both formats, users still can enjoy the
advantages of a z/OSMF Workflow as well as being able to search, browse, and print in a more traditional format.
With the removal of the traditional z/OS publication, GA32-0889, it is strongly recommended that you plan for your
next upgrade by having z/OS MF ready to use in at least one location in your enterprise. Notice that the exported
format of the z/OS upgrade materials that can be easily read or printed for those without any z/OS MF capabilities
will not be tailored for any environment.
z/OSMF ServerPac
IBM's first delivery of a ServerPac in z/OSMF Software Management portable software instance format was with the
CICS Transaction Server and associated CICS products, on December 9, 2019. Initially,IBM intends to allow you to
choose to order ServerPac for CICS and associated products in either the new z/OSMF Portable Software Instance
(PSI) format or the existing CustomPac Dialog-based format. The z/OSMF Portable Software Instance format is
designed to be installed using z/OSMF Software Management.
The requirements for using the CustomPac Dialog-based format remain unchanged, and this is the first of many
offerings that are planned to be delivered in the PSI format. For both formats, IBM plans to continue to offer delivery
via internet download or on DVD.
This initial offering of an IBM ServerPac in a z/OSMF portable software instance represents the next step in IBM's
collaboration with other leading z/OS platform software vendors to deliver a consistent package format intended to
be used with z/OSMF software management as a common installer.

Upgrade to IBM z/OS V2.4 planning

More Related Content

What's hot (20)

Similar to Upgrade to IBM z/OS V2.4 planning (20)

More from Marna Walle (16)

Recently uploaded (20)

Upgrade to IBM z/OS V2.4 planning