zOS V2R4 Upgrade Workflow from zOS V2R3
Description :zOS V2R4 Upgrade Workflow from zOS V2R3
  • Status: In Progress
  • Owner: IBMUSER
  • System: PLEX1.SYS1
  • Version: HSMA247;PH25395P;2020-07-30T23:13:19
  • Steps complete: 0 of 214
  • Export time: 2020-10-21 20:50:28

Filters :


Contents

< Note: Page numbers might not be accurate. >

Step 1 : Discover z/OS features in use


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

In this step, you execute a JCL job to generate an output property file that will reflect the current status of a priced feature on your system.

Instructions:

This step of the workflow will determine which z/OS priced features are currently enabled on the running system. Using this information (which you control with your IFAPRDxx parmlib member), associated steps with DISABLED features will be marked as Skipped. The objective of this step is to automatically reduce the number of non-applicable upgrade steps that you need to review.

Review the output of this step to see which priced features were determined to be disabled on this system, and to see which steps have had their state changed.

If you determine that you later want to perform those steps that were marked as Skipped, you can change the status and perform those steps, after they have been assigned.


Step 2 : Upgrading your z/OS system: An introduction


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This level of the z/OS Upgrade Workflow corresponds to z/OS V2R4.

Introducing the z/OS V2R4 Upgrade Workflow

Using a z/OSMF workflow, you can perform a z/OS V2R4 upgrade as an interactive, step-by-step process. The z/OS V2R4 Upgrade Workflow uses the latest functions in z/OSMF to provide a smooth upgrade experience.

The z/OS V2R4 Upgrade Workflow is available as two z/OS Management Facility (z/OSMF) workflows. Depending on whether you are migrating from z/OS V2R2 or z/OS V2R3, you select the files that apply to your migration path and download them to your system to create the workflow.

IBM no longer provides the z/OS Migration publication. Since z/OS V2R2, the preferred method for learning about migration actions has been the z/OS Workflow. Discovering, performing, and verifying many migration actions through the workflow instead of a traditional book allows for a tailored and specific migration path that is associated with a particular system.

Accompanying the change of format—a workflow instead of a book—is a change in terminology: upgrade instead of migrate. In our industry, the process of replacing software with a newer level is most often referred to as upgrading the software. In contrast, the phrase migrating the software can be taken to mean moving software from one server to another. When you perform the actions that are described in the workflow, you are upgrading z/OS to a newer level of function than the prior release. Thus, upgrade is the appropriate term for what these workflows do.

The z/OS Upgrade Workflow is provided in the following git repository for IBM/IBM-Z-zOS, which already hosts the z/OS workflows for previous releases:

https://github.com/IBM/IBM-Z-zOS

Usage tips

  • Enhanced discovery functions are available. Follow the instructions in the first step "Discover z/OS features in use" to allow z/OSMF to skip as many inapplicable steps as possible, thus reducing the number of steps for you to perform. The additional discovery includes the option to skip steps that are empty (which have actions that are shown as "None"). In addition, discovery is enhanced to skip over the hardware server levels that you have already upgraded to.

  • Some upgrade actions have associated health checks. For those steps, the health check is invoked to determine whether the upgrade action is applicable for your system. Read the instructions carefully on the Perform tab before running the health check for important information about each check.

  • For the individual upgrade actions and for the entire upgrade effort, you can optionally provide your feedback to IBM. Follow the instructions that are shown in the workflow. You do not need to provide feedback to complete each step of the workflow.

Summary of changes for z/OS V2R4 Upgrade Workflow, Version 2.3 (October 29 2020)

New information

The following upgrade actions are new:

  • Prepare for the removal of the internal battery feature
  • Prepare for the removal of support for TLS 1.0 and TLS 1.1 for SE, HMC, and OSC
  • BCP: The ASCB and WEB are backed in 64-bit real storage by default
  • DFSMS: Change DFSMSrmm Web Services to use the HTTPS protocol
  • ISPF: Accommodate the ISPF Gateway access change from HTTP to HTTPS
  • z/OSMF: Ensure that workflow users are authorized to read workflow files
  • z/OSMF: Use the Diagnostic Assistant to collect diagnostic data about z/OSMF
  • z/OSMF: Remove STGADMIN SAF authorization requirements for Software Management

Changed information

The following upgrade actions are changed:

  • Verify that virtual storage limits are set properly
  • BCP: Accommodate the new DSLIMITNUM default
  • CIM: Accommodate the default change from HTTP to HTTPS
  • DFSMSrmm: Remove the CIM provider registration and its associated files
  • IP Services: Plan to upgrade the FTP server to AT-TLS security
  • RMF: Configure AT-TLS to enable secure communication with the RMF distributed data server
  • Security Server: Check for duplicate class names

Summary of changes for z/OS V2R4 Upgrade Workflow, Version 2.2 (August 13 2020)

New information

The following upgrade actions are new:

  • IP Services: Plan to upgrade the DCAS server to AT-TLS security
  • IP Services: Plan to upgrade the FTP server to AT-TLS security
  • IP Services: Plan to upgrade the TN3270E server to AT-TLS security
  • OpenSSH: Accommodate a new level of OpenSSH
  • z/OSMF: Remove references to z/OSMF mobile notification service

Changed information

The following upgrade actions are changed:

  • BCP: XCF/XES FUNCTIONS XTCSIZE is enabled by default
  • ICSF: Plan for the removal of sequential data sets from the CSFPARM DD statement
  • PKI Services: Ensure that users have CA root certificate for PKI and web pages use HTTPS
  • SNA services: Migrate from VTAM Common Management Information Protocol

Summary of changes for z/OS V2R4 Upgrade Workflow, Version 2.1 (July 31 2020)

This workflow replaces the previous level, Version 2.0, from September 2019. This workflow includes new and changed upgrade actions (listed below), and changes for terminology, maintenance, and editorial corrections.

New information

The following upgrade actions are new:

  • BCP: Plan for removal of support for the IEWTPORTS transport utility
  • Security Server: Plan for removal of support for RACF database sharing with z/VM.

Changed information

Throughout this workflow, links were corrected or removed to ensure consistent linking.

Changes in previous versions of this workflow

New information

New general upgrade actions:

  • "Plan for removed z/OS national language translations"

New BCP actions:

  • BCP: Recompile programs with the new IRARMCTZ macro in APAR OA55218
  • BCP: Ensure that TVSAMCOM or TVSMSG are not used as job statement symbols
  • BCP: Running z/OS as a guest requires z/VM V6R4 or later
  • BCP: Stop referencing the ETR parameters in CLOCKxx
  • BCP: Regenerate the Unicode conversion image
  • BCP: Prepare for the removal of service coefficients from WLM service definitions
  • BCP: Evaluate the changed default for system logger's use of IBM zHyperwrite

New BookManager® READ action:

  • Remove any dependencies on BookManager READ from your system

New Common Information Model (CIM) actions:

  • CIM: Accommodate the default change from HTTP to HTTPS

New Communications Server actions:

  • SNA services: Migrate from VTAM Common Management Information Protocol
  • TCP/IP: Prepare for the removal of native TLS/SSL support
  • TCP/IP: Prepare for the removal of Sysplex Distributor support for IBM DataPower Gateway products
  • IP services: Ensure storage availability for IWQ IPSec traffic
  • IP Services: Decide whether to accept the new FIXED CSM default
  • Determine the storage impact if QDIOSTG=126 is in effect

New Cryptographic Services actions:

  • ICSF: Plan for the removal of sequential data sets from the CSFPARM DD statement
  • ICSF: Plan for the removal of support for EIM, OCSF, OCEP, and PKITP
  • PKI Services: Ensure that users have the CA root certificate for the PKI web interfaces

New DFSMS actions:

  • DFSMSdfp: Review XRC parmlib members for use of default values
  • DFSMSdfp: Check for an out-of-synch condition in the OAM configuration
  • DFSMShsm: Accommodate the default change for SETSYS MIGRATIONAUTOCLOUD
  • DFSMSdfp: Increase storage for SMS ACDS data sets
  • DFSMSdfp: Accommodate code 4 for empty objects in the IDCAMS LISTCAT command
  • DFSMSdss: SHARE keyword isignored for COPY and RESTORE of PDSE
  • DFSMSdfp: Expect dumping of the catalog address space for VVDS manager error 050-020

New Distributed File Service action:

  • DFS/SMB: Use Network File System (NFS) instead of DFS/SMB

New HCD actions:

  • HCD withdraws support for out-of-service processor types
  • HCD: Accommodate the removal of switch functions from Tivoli System Automation

New HCM action:

  • HCM: Accommodate the removal of I/O Operations from Tivoli System Automation

New High Level Assembler (HLASM) action:

  • HLASM: Verify that the changed default of ILMA is acceptable

New IBM z/OS Management Facility action:

  • z/OSMF: Move the user directory from /var to /global
  • z/OSMF: Prepare for the removal of the policy data import function of NCA
  • z/OSMF: Accommodate the use of IBM z/OS Liberty Embedded
  • z/OSMF: Establish security for cross-site z/OSMF REST requests

New Infoprint Server actions:

  • Infoprint Central requires SSL connections by default
  • Edit the aopd.conf file

New ISPF action:

  • ISPF: Plan for the removal of Workstation Agent

New JES2 actions:

  • JES2: Activate z22 mode
  • JES2: Accommodate the changed default for the EXECUTABLE keyword on $GETMAIN
  • JES2: Checkpoint versions are moving to 64-bit storage
  • JES2: Accommodate changes in NJE input phase processing for multi-object job streams
  • JES2: Review changes applicable to exit routines and user modifications

New JES3 action:

  • JES3: Plan for migration to JES2 in a future release

New Library Server action:

  • Stop using Library Server

New OSA Support Facility (OSA/SF) action:

  • Stop using Open Systems Adapter/Support Facility (OSA/SF)

New RMF action:

  • RMF: Configure AT-TLS to enable secure communication with the RMF distributed data server

New Security Server actions:

  • RACF: Ensure that the ECC master key is activated in the CCA coprocessor
  • RACF: Check for programs affected by the increase of the maximum length of JESJOBS class profiles

New SMP/E action:

  • SMP/E: Accommodate the removal of Planning and Migration Assistant

New TSO/E action:

  • TSO/E: Check for programs that expect RC 0 for invalid command invocations

New z/OS UNIX actions:

  • z/OS UNIX: Optionally delete the FORKCOPY(COW) option of BPXPRMxx
  • z/OS UNIX: Optionally delete the KERNELSTACKS option of BPXPRMxx

These actions are applicable for customers who are migrating from either z/OS V2R3 or z/OS V2R2, and are thus included in both "Upgrading from z/OS V2R3 and "Upgrading from z/OS V2R2."

Changed information

The following information is changed:

  • Upgrade actions from earlier releases that apply to z/OS V2R4 are carried over from the z/OS Migration document.

  • Changed general action:

    • Migrate /etc, /global, and /var system control files
  • Changed BCP action:

    • BCP: Removal of support for user key common areas
  • Changed Infoprint Server action:

    • Upgrade web browser support for Infoprint Central
    • Prepare for dynamic configuration
    • Remount the Printer Inventory and copy files that were customized
  • Changed Security Server action:

    • Check for previously defined classes HBRADMIN, HBRCONN, or HBRCMD
  • Changed z/OS UNIX action:

    • z/OS UNIX: Migrate from HFS file systems to zFS file systems

Deleted information

Upgrade actions that were introduced in z/OS V2R2 and do not apply to the z/OS V2R4 path have been removed.


Step 2.1 : Typical upgrade steps


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

It is possible to make upgrade changes at the same time you make the changes necessary to exploit new functions in the new release. However, the more prudent approach is to do your upgrade first and then exploit new functions. The typical steps to accomplish this are:

  1. Learn about z/OS V2R4. Good sources of information include:
  2. Perform as many of the upgrade actions as you can on your existing ( old) system so that you have fewer actions to perform after you install z/OS V2R4. In this information, the actions you can perform on your existing system are identified by headings that say Actions to perform before installing z/OS V2R4. Note that not all of the actions are required. Some depend on your environment, configuration, and workload, and are identified accordingly. These actions should be made to, or copied (cloned) to, all existing systems that will be migrated to z/OS z/OS V2R4.

    Use IBM Health Checker for z/OS to assist with some upgrade actions. For more information, see the workflow step "Using IBM Health Checker for z/OS for migration checking."

  3. Order and install coexistence and fallback service for any system that will share resources with a z/OS V2R4 system. See the workflow step "Install coexistence and fallback PTFs." This service needs to be installed on all systems that will coexist with z/OS V2R2 and all systems that will be migrated to z/OS V2R4 (and which you might fall back to).
  4. Prepare the driving system. For driving system requirements, see the topic about preparing the driving system in z/OS Planning for Installation.
  5. Order z/OS V2R4 from ShopZ, then install it. If you use a ServerPac, refer to ServerPac: Installing Your Order for installation instructions. If you use a CBPDO, see z/OS Program Directory.
  6. Prepare target system hardware and software. During this step, perform the upgrade actions identified by headings that say Actions to perform before the first IPL of z/OS V2R4. (Again, not all of the actions are required. Some depend on your environment, configuration, and workload, and are identified accordingly.)
  7. IPL the new z/OS V2R4 system with your updated customization and configuration files.
  8. Perform any upgrade actions identified by headings that say Actions to perform after the first IPL of z/OS V2R4. (Again, not all of the actions are required. Some depend on your environment, configuration, and workload, and are identified accordingly.)

    Use IBM Health Checker for z/OS to assist with some upgrade actions. For more information, see the workflow step called "Using IBM Health Checker for z/OS for migration checking."

  9. Deploy z/OS V2R4 to other systems within a sysplex, data center, and enterprise.

    The upgrade is now complete.

  10. When you are confident that a system, or in some cases all systems in a sysplex, are not going to fall back to z/OS V2R3 or z/OS V2R2, you can exploit the functions introduced in z/OS V2R4.
  11. Deploy this exploitation on other systems (again within a sysplex, data center, and eventually enterprise).

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 2.2 : Using IBM Health Checker for z/OS for migration checking


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

Before you upgrade to a new z/OS release, you can use IBM Health Checker for z/OS to assist with planning. Migration checks can help you determine the applicability of various upgrade actions to your current system. As with other checks provided by IBM Health Checker for z/OS, no updates are made to the system. Migration checks report only on the applicability of specific upgrade actions on a system, and only on the currently active system.

IBM Health Checker for z/OS is started automatically during system initialization.

Migration checks are similar to the other checks provided by IBM Health Checker for z/OS. The only differences are:

  • Migration checks are inactive by default.
  • 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.
    Note:

    In previous releases, the names of migration checks followed a different set of naming conventions: one for ICSF, which used the convention ICSFMIGnnnn_component_program_name, and one for the rest of z/OS, which used the convention ZOSMIGVvvRrr_component_program_name.

On your current z/OS release, follow these steps:

  1. Install the latest migration checks. Review all the latest health checks for both best practices and migration by using the SMP/E FIXCAT IBM.Function.HealthChecker.

    You might want to install the PTFs during a regular service window, so that an IPL is scheduled afterward. Checks are often added by a function when it is started or restarted, so you might find that installing the PTFs before a scheduled IPL works best for you. More migration checks can be added at different times, so having all the latest checks installed before making your migration plans is recommended.

  2. Activate the migration checks that are appropriate to your upgrade path. Because the naming convention for migration checks indicates which release introduced the corresponding upgrade actions, you can activate only the checks that are appropriate for your upgrade path. Using SDSF (or another method for viewing checks, such as filters), you can view ahead of time which migration checks you have available on your system. For example, if you are upgrading from z/OS V2R2 to z/OS V2R4, you must activate the migration checks for changes that occurred in both z/OS V2R3 and z/OS V2R4. If you are upgrading from z/OS V2R3 to z/OS V2R4, you need to activate only the migration checks for changes that occurred in z/OS V2R4. There are many ways to make a check active, and many ways to use wild cards to include specific checks.

    Here are some examples of using the MODIFY command to make checks active:

    • F HZSPROC,ACTIVATE,CHECK=(IBM*,*MIG*)
    • F HZSPROC,ACTIVATE,CHECK=(IBM*,ICSFMIG*)
    • F HZSPROC,ACTIVATE,CHECK=(IBM*,ZOSMIG*)
  3. Review the migration check output and rerun checks. Any exceptions should be addressed in your migration plan. If you can complete the upgrade action before you move to the new z/OS release, you can rerun the check to verify that it was completed correctly on your current system. In some cases, the check might be available for running on the new z/OS release for verification after that release is IPLed.
  4. Deactivate the migration checks if you want. If you no longer desire to have the migration checks active, you can deactivate them similar to the way you activated them. For example:
    • F HZSPROC,DEACTIVATE,CHECK=(IBM*,*MIG*)
    • F HZSPROC,DEACTIVATE,CHECK=(IBM*,ICSFMIG*)
    • F HZSPROC,DEACTIVATE,CHECK=(IBM*,ZOSMIG*)

Within this document, the upgrade actions that have checks are clearly identified within the upgrade actions.

Not all upgrade actions in this document are addressed by checks; many upgrade actions do not lend themselves to programmatic checking. Therefore, use this document to prepare your migration plan and do not rely on checks only.

System REXX considerations

Several IBM Health Checker for z/OS migration health checks are written in compiled System REXX. These health checks rely on System REXX customization and runtime activities being completed. If System REXX and the security environment that System REXX requires has not been properly customized, the System REXX health checks will not run successfully. Also, the compiled REXX execs must have the proper runtime support from the Alternate Library for REXX (available in z/OS since V1R9) or from IBM Library for REXX on zSeries (5695-014).

Note:

To allow System REXX to use JES services, the AXRnn address spaces are started under the primary subsystem. Therefore, you must end the AXRnn address spaces before you shut down JES2. You do not have to stop the AXR address space; this action only affects the secondary AXRnn address spaces.

More information is available in the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 2.3 : Elements and features that do not have upgrade actions


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

For an upgrade from z/OS V2R3 to z/OS V2R4, the following z/OS elements and features do not have upgrade actions to perform:

  • Alternate Library for REXX
  • BDT
  • BDT File-to-File
  • BDT SNA NJE
  • Communications Server Security Level 3
  • DFSORT
  • EREP
  • FFST
  • GDDM
  • GDDM-PGF
  • GDDM-REXX
  • IBM HTTP Server
  • IBM Knowledge Center for z/OS
  • IBM Tivoli Directory Server
  • ICKDSF (Device Support Facility)
  • Integrated Security Services
  • Metal C Runtime Library
  • MICR/OCR
  • NFS
  • Runtime Library Extensions
  • TIOC
  • z/OS Font Collection
  • z/OS Security Level 3
  • 3270 PC File Transfer Program

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3 : General upgrade actions for everyone migrating to z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This level of the z/OS Upgrade Workflow corresponds to z/OS V2R4.


Step 3.1 : Upgrade actions for everyone moving to z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes general upgrade actions that apply to everyone, regardless of which elements and features you use.


Step 3.1.1 : Upgrade actions for everyone before installing z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes general upgrade actions that you can perform on your current (old) system. You do not need the z/OS V2R4 level of code to make these changes, and the changes do not require the z/OS V2R4 level of code to run once they are made.


Step 3.1.1.1 : Review PSP buckets


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Check the preventive service planning (PSP) buckets for important software and hardware installation and maintenance information that occurs too late in the development cycle to be included in the product publications. Included are PTFs for both service and small programming enhancements (SPEs).

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  1. Identify which PSP buckets to review. For this task, you will need to know:
    • PSP bucket upgrade IDs (or upgrades). The most relevant upgrades are those related to z/OS V2R4 and its servers. The z/OS V2R4 upgrade is ZOSV2R4; the server upgrades are shown in Table 2.
    • FIXCAT values if you use the SMP/E REPORT MISSINGFIX command in conjunction with the FIXCAT type of HOLDDATA (as mentioned in the tip that follows). The FIXCAT values are shown in Table 2. Note:
      • The values shown are for the minimum support necessary for the servers. If you exploit additional functions on a server, the FIXCAT value will have additional qualifiers.
      • You must run z/OS V2R4 on a zEC12 or zBC12 or later. See the workflow step called "Ensure that you are using supported servers, storage controllers, and machine facilities."
  2. Obtain the PSP buckets at Preventive Service Planning buckets or from IBMLink.
  3. Review the PSP buckets and take whatever actions are prescribed.
Tip:

To simplify finding the appropriate PSP bucket and identifying which minimum PTFs listed in the PSP bucket need to be installed on your system, you can use SMP/E FIXCATs and the REPORT MISSINGFIX command. The FIXCAT values are shown in Table 2.

Table 2. Servers, upgrades, and FIXCAT values

Server

Upgrade

FIXCAT value

z14

3906DEVICE

IBM.Device.Server.z14-3906

z14 ZR1

3907DEVICE

IBM.Device.Server.z14ZR1-3907

z13®

2964DEVICE

IBM.Device.Server.z13-2964

z13s™

2965DEVICE

IBM.Device.Server.z13S-2965

zBC12

2828DEVICE

IBM.Device.Server.zBC12-2828

zEC12

2827DEVICE

IBM.Device.Server.zEC12-2827

Reference information

For more information, see the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.1.2 : Install coexistence and fallback PTFs


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

By installing coexistence and fallback PTFs on your pre-z/OS V2R4 systems, you allow the systems to coexist with z/OS V2R4 systems during your migration. Installing coexistence and fallback PTFs also allows for fallback to the previous systems, if necessary. Coexistence and fallback are important because they allow you to migrate systems in a multisystem configuration to z/OS V2R4 using rolling IPLs (one system at a time), allowing for continuous application availability.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

Install the appropriate PTFs.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Before you introduce z/OS V2R4 into your environment, install coexistence and fallback PTFs on all pre-z/OS V2R4 systems with which your z/OS V2R4 system will coexist.

Use the SMP/E REPORT MISSINGFIX command with the FIXCAT type of HOLDDATA as follows:

  1. Obtain and RECEIVE the latest HOLDDATA onto your pre-z/OS V2R4 systems. Use your normal service acquisition portals or download the HOLDDATA directly from Enhanced HOLDDATA for z/OS. Select the Full from the Download NOW column to receive the FIXCAT HOLDDATA; the other files do not contain FIXCATs.
  2. Run the SMP/E REPORT MISSINGFIX command on your pre-z/OS V2R4 systems and specify a Fix Category (FIXCAT) value of IBM.Coexistence.z/OS.V2R4. The report identifies the missing coexistence and fallback PTFs for that system. For more information about the REPORT MISSINGFIX command, see z/OS SMP/E Commands.
  3. Periodically, you might want to obtain the latest HOLDDATA and rerun the REPORT MISSINGFIX command to find out whether there are any new coexistence and fallback PTFs.

Reference information

For an explanation of the z/OS coexistence-migration-fallback policy, see the coexistence and fallback topic in z/OS Planning for Installation.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.1.3 : Use zSoftCap to identify the effect of capacity changes


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The zSoftware Migration Capacity Planning Aid (zSoftCap) is a PC-based tool that evaluates the effects of software release migrations.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended to help with assessing processor capacity and available resources when you are migrating to new software levels.

Target system hardware requirements:

This tool runs on your workstation. The requirements are:

  • A dual-core technology, or faster, processor.
  • An SVGA display 1024 x 768 or better.
  • Approximately 5 MB of hard disk space for the zSoftCap application and user's guide, plus 80 MB for the IBM Java 1.6 runtime environment.

Target system software requirements:

This tool runs on your workstation. Requirements are:

  • Windows 7 or later.
  • IBM Java™ 1.6, or later, runtime environment. This environment is available with the tool.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  1. Download zSoftCap from the IBM Techdocs website IBM Techdocs. Search for Techdoc PRS268.
  2. Run zSoftCap to determine your expected increase in CPU utilization, if any.
Reference information

For more information, see zSoftCap User's Guide.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.1.4 : Add or change volumes to keep your z/OS root file system in a single data set


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Because of release enhancements and service, the size of the z/OS root file system (or version root file system) continues to grow from release to release. The size of the z/OS root file system, whether HFS or zFS, is expected to closely approach, if not exceed, the limit of 3339 cylinders on a 3390-3 device.

It is advisable to have the z/OS root file system within a single data set for ease of management.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended for ease of management if your z/OS root file system resides on a 3390-3 volume (or another DASD volume that is close to the 3390-3 limit of 3339 cylinders).

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

Use IBM Health Checker for z/OS check CHECK(IBMUSS, ZOSMIGREC_ROOT_FS_SIZE) to determine whether a volume has enough space for the z/OS root file system.

Steps to take

To keep the z/OS root file system in a single data set, do one of the following:

  • Move your z/OS root file system to a larger DASD volume geometry
  • Use multiple volumes for the z/OS root file system data set.

If your z/OS root data set cannot fit on the volume or volumes you have defined for it, divide the z/OS root, with the smaller file systems being managed together.

Remember that all systems to which you deploy the z/OS root file system need sufficient DASD space to hold the z/OS root.

Tip:

File systems for subsystems and products other than the z/OS product itself might also increase in size. When examining the volume for how much space your z/OS file system is using, check other product file system sizes too.

Reference information

For more information, see z/OS DFSMS Implementing System-Managed Storage.

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMUSS,ZOSMIGREC_ROOT_FS_SIZE.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".


Step 3.1.1.5 : Verify that you have enough XCF groups and XCF group members


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Over time, as various z/OS functions and applications exploit XCF services, you must ensure that there is enough space in the sysplex couple data set for all the XCF groups and members that are to be defined by the exploiters. It is possible that your sysplex couple data set could contain an inadequate number of XCF groups or members.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended to ensure that you have an adequate number of XCF groups and members formatted in your sysplex couple data sets.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

Use Health Checker for z/OS check IBMXCF,XCF_SYSPLEX_CDS_CAPACITY, which checks the adequacy of the number of groups, members, and systems for which a sysplex CDS is formatted.

Steps to take

Follow these steps:

  1. Issue the DISPLAY XCF,COUPLE command on your current system. Notice the values of MAXGROUP and PEAK for your sysplex couple data sets. These values show you the maximum number of XCF groups that the couple data sets can support, and the peak number of XCF groups ever in use in the sysplex. Also notice the values of MAXMEMBER and PEAK for your sysplex couple data sets. These values show you the maximum number of members that the couple data set can support in one group, and the greatest number of members ever in use in the largest group in the sysplex.
  2. If your peak member value is close to the maximum member value, you might want to reformat your sysplex couple data sets to support a larger maximum number of members to be used by any one group.
Reference information

For more information, see the following references:

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMXCF,XCF_SYSPLEX_CDS_CAPACITY.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".


Step 3.1.1.6 : Ensure that the CustomPac Installation Dialog is updated


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

As of May 22, 2016, you can no longer download orders from IBM download servers by using standard FTP.

To download your ServerPac or dump-by-data-set SystemPac order securely, you require a sufficient level of the RECEIVE job that is provided in the CustomPac Installation Dialog. The specific level that is required depends on the download method to be used, as follows:

FTP over SSL (FTPS)
To download your order securely by using FTP over SSL (FTPS), you require the updated RECEIVE job that is provided in the CustomPac Installation Dialog level 27.12.00 or higher.
HTTPS
HTTPS To download your order securely by using HTTPS, you require the updated RECEIVE job that is provided in the CustomPac Installation Dialog level 27.20.00 or higher.

To determine the current level of the CustomPac Installation Dialog in use on your system, check the primary panel CPPPPOLI.

To prepare for downloading an order, IBM recommends that you begin by visiting the Connectivity Test website to verify your system setup. No change is required for using Download Director with encryption; however, you can also verify Download Director with the Connectivity Test. The Connectivity Test can be found at Connectivity Test for SW Download Readiness.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Customized Offerings for z/OS

When change was introduced:

General upgrade action not tied to a specific release. See Washington Systems Center Flash 10863 at IBM Technical Support Flashes site.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes, if your existing CustomPac Installation Dialog is not at a sufficient level, such as 27.12.00 or 27.20.20.

Target system hardware requirements:

None.

Target system software requirements:

See Identifying driving system software requirements for installing z/OS using ServerPac or dump-by-data-set SystemPac in z/OS Planning for Installation.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

Failure to update the CustomPac Installation Dialog to a sufficient level can result in the RECEIVE job failing or the inability to download your order securely.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  • For ServerPac customers, see the topic on updating your dialogs in ServerPac: Using the Installation Dialog. Refer to the section for your order's delivery media (DVD or internet delivery) to determine the steps to take.
  • For CustomPac customers, see the topic on updating your dialogs in CustomPac: Installation Dialog Reference. Refer to the section for your order's delivery media (DVD or internet delivery) to determine the steps to take.

Reference information

For more information, see the following references:

  • For more information about the internet delivery method to choose for downloading your ServerPac or CustomPac (SystemPac, ProductPac, FunctionPac) Internet Delivery order, see "Choosing the Internet download method: direct or intermediate" in z/OS Planning for Installation.
  • For ServerPac customers who want more information about updating your CustomPac Installation Dialog, see the topic on updating your dialogs in ServerPac: Using the Installation Dialog. Refer to the section for your order's delivery media.
  • For ServerPac customers who want more information about receiving an order from a server by using the CustomPac Installation Dialog, see "Receiving an Order from a Server" in ServerPac: Using the Installation Dialog. Refer to the section for your order's delivery media.
  • For CustomPac customers who want more information about updating your CustomPac Installation Dialog, see the topic on updating your dialogs in CustomPac: Installation Dialog Reference.
  • For CustomPac customers who want more information about receiving an order from a server by using the CustomPac Installation Dialog, see "Receiving an Order from a Server" in CustomPac: Installation Dialog Reference.
  • See the README and Checklist documents on the Shopz download pages for your order.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.1.7 : Consider using the new JOB statement for the CustomPac installation dialog


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

A new default JOB statement with the LINES parameter is provided with CustomPac dialog level 27.20.00 or later. If you want to use the new default JOB statement, ensure that the CPP@JOB member is not present in data set userid.ISPF.ISPPROF before you start the installation dialog. However, if you want to continue to use your existing JOB statement for the RECEIVE job and installation jobs, do nothing.

The LINES parameter indicates the maximum amount of output, in thousands of lines, that a job can print to its SYSOUT data set. The LINES parameter also specifies the action that the system is to take if this maximum is exceeded. In CustomPac dialog level 27.20.00 or later, the LINES parameter in the default JOB statement is set to the following specification:

LINES=(999999,WARNING)

As a result, the CustomPac jobs can print up to 999999000 lines of output before the system issues a warning to the system operator.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Customized Offerings for z/OS

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes, if you want to use the new default JOB statement.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

Failure to remove your existing CPP@JOB member from the userid.ISPF.ISPPROF data set means that the existing JOB statement is used instead of the new default JOB statement.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  1. If your installation uses a customized JOB statement with the RECEIVE and installation jobs, determine whether to use the default JOB statement instead. The JOB statement is contained in the CPP@JOB member in data set userid.ISPF.ISPPROF.
  2. To use the new JOB statement, remove the CPP@JOB member from data set userid.ISPF.ISPPROF before you start the installation dialog. Otherwise, do nothing; the CustomPac jobs continue to use your existing JOB statement values.

Reference information

For more information, see the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.1.8 : Prepare for the discontinuation of tape delivery


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

IBM has discontinued delivery of z/OS platform products and service on magnetic tape. IBM recommends downloading products and service. However, if you have a requirement for physical media, products and service are also available on DVD.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Customized Offerings for z/OS

When change was introduced:

z/OS V2R4. Also, see IBM United States Software Announcement 217-085, "IBM z/OS Version 2 Release 3 - Engine for digital transformation," dated February 21, 2017.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

IBM recommends downloading products and service. However, if you have a requirement for physical media, products and service are also available on DVD.

Reference information

For more information, see z/OS Planning for Installation.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.1.9 : Plan for removed z/OS national language translations


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

As of z/OS V2R4, z/OS is provided only in U.S. English (ENU), Uppercase English (ENP), and Japanese (JPN).

The following optional language features are no longer shipped with z/OS V2R4:

  • Brazilian Portuguese
  • Canadian French
  • Danish
  • French
  • German
  • Italian
  • Korean
  • Netherlands Dutch
  • Norwegian
  • Simplified Chinese
  • Spanish
  • Swedish
  • Swiss German
  • Traditional Chinese

This change affects the subset of z/OS elements that provided translations in previous releases:

  • GDDM
  • ISPF
  • TSO/E
  • z/OS UNIX

Therefore, as of z/OS V2.4, the following translated elements and features are sent when you specify the language feature number in your order.

Language

Base elements

Japanese, which also includes Uppercase English support for ISPF only.

  • Alternate Library for REXX
  • BCP
  • DFSMSdfp
  • GDDM
  • HCD
  • IBM TDS
  • Integrated Security Services
  • ICKDSF
  • ISPF
  • JES2
  • Language Environment
  • NFS
  • Runtime Library Extensions
  • SMP/E
  • SSL component of Cryptographic Services
  • TSO/E
  • z/OS File System
  • z/OS UNIX

This change does not affect fonts. z/OS continues to provide double-byte fonts for China, Japan, Korea, and so on.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

GDDM, ISPF, TSO/E, z/OS UNIX

When change was introduced:

z/OS V2R3. Announced as a Statement of Direction in IBM Software Announcement Letter 217-246, dated July 2017.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes, if you use any of the removed languages.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Stop using the removed languages from the affected elements.

Reference information

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2 : Upgrade actions for everyone before the first IPL of z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes general upgrade actions that you can perform after you have installed z/OS V2R4 but before the first time you IPL. These actions might require the z/OS V2R4 level of code to be installed, but do not require it to be active.


Step 3.1.2.1 : Set up an IPCS environment


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The interactive problem control system (IPCS) is a tool in the BCP that provides formatting and analysis support for dumps and traces. You must set up an IPCS environment so that you can process any dumps taken on the newly-built z/OS system.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if the target system cannot be used for native IPCS and usage of IPCS for information produced by the target system is necessary.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

The version and release level of IPCS must match the level of the system that produced the dump. You must use the z/OS MVS libraries of IPCS code, for example, to analyze a dump or trace produced by that level of the z/OS MVS system.

Tip:

If it is necessary to have unique IPCS data set names for your current system (because you already have the IPCS data sets with similar names on your earlier system), you can create a unique alias in your catalog that resolves to the current IPCS data sets. This will allow you to have duplicately-named IPCS data sets that are uniquely referenced.

When using unique aliases, you might have to update the security definition for the unique high-level qualifier used in the catalog.

Restrictions

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Set up an IPCS environment; for guidance, see the documents that are listed in "Reference information." During setup, ensure that your logon procedure points to the target system's level of IPCS data sets, which are shown in the following table.

DD name

Data set name

Notes

IATTABL

SYS1.SIATTBL0, if applicable

This is a JES3 data set.

IPCSPARM

Note:

This DD name is needed if one of the following is true:

  • The system on which the dump was taken has different BCP and JES levels than the system on which the dump will be examined using IPCS.
  • You have not specified these data sets in your system's parmlib concatenation.

SYS1.PARMLIB

This is the data set that contains all the shipped z/OS V2R4 parmlib IPCS members. If the copies of BLSCECT and all the other IPCS members are not at the z/OS V2R4 level, IPCS might fail when you attempt to use it.

IPCSPARM

SYS1.SHASPARM, if applicable

This is a JES2 data set.

IPCSPARM

SYS1.SIATPARM, if applicable

This is a JES3 data set.

ISPMLIB

SYS1.SBLSMSG0

 

ISPMLIB

SYS1.SIATMSG0, if applicable

This is a JES3 data set.

ISPPLIB

SYS1.SBLSPNL0

 

ISPPLIB

SYS1.SHASPNL0, if applicable

This is a JES2 data set.

ISPPLIB

SYS1.SIATPNL0, if applicable

This is a JES3 data set.

ISPSLIB

SYS1.SBLSKEL0

 

ISPTLIB

SYS1.SBLSTBL0

 

STEPLIB

Note:

This DD name is needed if the system on which the dump was taken has different BCP and JES levels than the system on which the dump will be examined using IPCS.

SYS1.MIGLIB

 

STEPLIB

SYS1.SIEAMIGE

This data set was added in z/OS V1R7. It is a PDSE data set that complements SYS1.MIGLIB. This data set is used along with SYS1.MIGLIB for IPCS.

STEPLIB

SYS1.SHASMIG, if applicable

This is a JES2 data set.

STEPLIB

SYS1.SIATMIG, if applicable

This is a JES3 data set.

SYSEXEC

SYS1.SIATCLI0, if applicable

This is a JES3 data set.

SYSPROC

SYS1.SBLSCLI0

 

Reference information

For more information, see the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.2 : Use IBM-supplied parmlib and proclib members


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Ensure that all new and changed parmlib and proclib members that are shipped in z/OS V2R4 are updated in your parmlib and proclib concatenations.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  • For parmlib, add the data set pointed to by the z/OS V2R4 PARMLIB DDDEF to your parmlib concatenation. Generally, the data set should be added last in the concatenation, and you should ensure that the other data sets in the concatenation do not have members with the same names as the IBM-supplied members. If you place the data set on the system residence volume and use an indirect catalog entry, future migrations will not require this particular migration step.
  • For proclib:
    1. Ensure that the default proclib members are copied to your default proclib to pick up the new and changed members.
    2. Update the individual sample members that are provided and ensure that they are accessible to the system, as shown in the table of proclib member updates in z/OS Program Directory.
    3. Ensure that the procedure libraries that are listed in the table of libraries to be added to the proclib concatenation in z/OS Program Directory in the z/OS Internet library are placed in the necessary procedure library concatenations and are available to the system.
Reference information

For the parmlib and proclib members that are shipped with z/OS, see z/OS Program Directory in the z/OS Internet library.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.3 : Migrate /etc, /global, and /var system control files


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The /etc, /global, and /var directories contain system control files. The /etc directory contains customization data that you maintain. The /global and /var directories contain customization data that IBM maintains.

The following elements and features use /etc:

  • BCP (Predictive Failure Analysis).
  • CIM.
  • Communications Server (IP Services component). See the workflow step called "IP Services: Update /etc configuration files."
  • Cryptographic Services (PKI Services and System SSL components).
  • DFSMSrmm.
  • IBM HTTP Server.
  • IBM Tivoli Directory Server (TDS). The LDAP server component uses /etc/ldap.
  • Infoprint Server. See the workflow step called "Remount the Printer Inventory and copy files that were customized."
  • Integrated Security Services. The Network Authentication Service component uses /etc/skrb.
  • z/OS UNIX.

The following elements and features use /global:

  • IBM Knowledge Center for z/OS
  • IBM z/OS Management Facility (z/OSMF).

The following elements and features use /var:

  • Cryptographic Services (OCSF component). See the workflow step called "OCSF: Migrate the directory structure."
  • DFSMSrmm.
  • IBM Tivoli Directory Server (TDS). The LDAP server component uses /var/ldap.
  • Infoprint Server. See the workflow step called "Remount the Printer Inventory and copy files that were customized."
  • Integrated Security Services. The Network Authentication Service component uses /var/skrb.

During installation, subdirectories of /etc, /global, and /var are created. If you install z/OS with ServerPac, some files are loaded into /etc, /global, and /var because of the customization that is performed in ServerPac. You must merge the files in /etc, /global, and /var with those on your previous system. If you install z/OS with CBPDO, copy the files from your old system to the z/OS V2R4 /etc, /global, and /var subdirectories.

After merging or copying the contents of /etc, /global, and /var, you must inspect and modify the files as necessary to reflect z/OS V2R4 requirements.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Copy files from your old system to the z/OS V2R4 /etc, /global, and /var subdirectories, and then modify the files as required for z/OS V2R4. If you have other files under your existing /var directory, you must merge the old and new files under /var. The easiest way to do this is to create a clone of your current /var file system and then copy the new /var files into the clone.

Many z/OS UNIX utilities are available for comparing and copying directory structures and files. Two that are especially helpful for /etc, /global, and /var migration work are:

  • diff (with the -r option, for recursion). This utility is useful for comparing the path structures and file contents, and has many options available. The dircmp utility has fewer options for directory comparisons, and the cmp utility stops after the first difference in a file comparison and has output that is more cumbersome.
  • pax . The -rw option works like a copy (instead of making or extracting from a single file archive) for directories, symbolic links, and files. Consider the -pe option for saving the attributes when doing the copy. The -k option prevents overwriting of existing files. The -c option causes pax to continue after encountering an error on the source file system. That is, pax prints an error message and returns a nonzero value after the command ends. Errors on the target file system (such as out of space or write errors) still cause the pax command to end as it always has.

To determine what you need to migrate, first compare the ServerPac /etc, /global, and /var file systems with your existing /etc, /global, and /var file systems. Mount a copy of your existing /etc, /global, and /var file systems to a location outside of the ServerPac file system. For instance, you might have your ServerPac file systems at /ServerPac/zOS_Rx/etc and /ServerPac/zOS_Rx/var, and your existing file systems at /Service/ImageX/etc and /Service/ImageX/var. You might have several file systems to mount that are copies of each of your image's /etc and /var file systems (ImageX, ImageY, and ImageZ, for instance). To compare the ServerPac and existing system's /etc and /var, you can run two z/OS UNIX commands, such as:

diff -r /ServerPac/zOS_Rx/etc /Service/ImageX/etc diff -r /ServerPac/zOS_Rx/var /Service/ImageX/var

These command results give you a list of the changes that your existing system's /etc and /var file systems are missing, including both the structure differences and the file content differences.

After you determine which directories, symbolic links, and files you are missing from your existing system, you can use one of several ways to propagate the ServerPac information forward:

  • You can use the pax command (with the -k option) to copy from the ServerPac /etc, /global, and /var file systems to each of your existing system's /etc, /global, and /var file systems. For example:
    cd /ServerPac/zOS_Rx/etc pax -rvwkC -pe * /Service/ImageX/etc

    Another example:

    cd /ServerPac/zOS_Rx/var pax -rvwkC -pe * /Service/ImageX/var

    The pax command is a good choice because it copies all files, directories, and symbolic links for each file system from the ServerPac system using a single command without overlaying any existing files.

  • You can rerun the product-supplied MKDIR jobs to recreate the directories and symbolic links on each of your existing system's /etc, /global, and /var file systems. A list of the MKDIR jobs is found in z/OS Program Directory in the z/OS Internet library and the other program directories for the products that were in your ServerPac order. MKDIR jobs can be run multiple times without damaging your existing file system. For the files under /var/ocsf, rerun the OCSF-supplied ocsf_install_crypto installation script. Or, you can combine these jobs and script them into a single batch job to make the execution more consolidated and repeatable.

After you make changes to a copy of your existing image's /etc, /global, and /var file systems, you can unmount them and use them for your deployment of the ServerPac system, as your schedule indicates. Remember, you are using copies of your existing /etc, /global, and /var file systems, and you are preserving what you had previously by modifying copies, so your customization for those specific existing images is not lost.

Reference information

For more information, see z/OS Program Directory in the z/OS Internet library.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.4 : Update automation and procedures for changed and deleted messages


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Every release, many messages change and some are deleted. If you use automation programs to handle messages, or you have operator or other procedures that deal with messages, you should update the programs or procedures.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if you use automation programs or other procedures to handle messages.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Review the lists of changed and deleted messages in z/OS Release Upgrade Reference Summary. Update programs that automate on these messages and make other necessary accommodations.

Reference information

For a list of new, changed, and deleted messages, see z/OS Release Upgrade Reference Summary.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.5 : Rework and install user modifications


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

A user modification is a change that is constructed by a user to modify an existing function, add to an existing function, or add a user-defined function.

Common types of user modifications are:

  • User-written and vendor-written exit routines.
  • User-written and vendor-written SVCs.
  • User-written and vendor-written termination routines.
  • Modifications of IBM source code.
  • Unit information modules (UIMs) for non-IBM hardware.
  • User-written and vendor-written modules that are listed in a NUCLSTxx parmlib member.
  • Updates to default modules to set site defaults differently than the IBM-supplied defaults, such as for the following element and features:
    • DFSORT. Consider using ICEPRMxx parmlib members to eliminate the assembler language installation option modules.
    • HLASM.
    • ISPF configuration table.
    • SDSF. For more information, see the workflow step called "SDSF: Use dynamic statements for ISFPARMS to avoid reassembly."
    • z/OS XL C/C++.

If you made any user modifications, you must determine which ones need to be reworked and which ones need only to be reinstalled.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4

Is the upgrade action required?

Yes, if you made any user modifications.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Determine which user modifications need to be reworked and which need only to be reinstalled. You can use SMP/E LIST commands to retrieve information about installed products and features.

Note:

IBM recommends that you use exit routines for any user modifications where possible. You can install the exit routines by using SMP/E. With SMP/E, it is easier to bring forward modifications to the z/OS release you are installing.

Reference information

For more information, see the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.6 : Reconnect non-IBM products


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

If you use any independent software vendor (ISV) products, you must make them usable with the new system.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if you use any ISV products and need to reconnect them after performing a ServerPac installation.

Target system hardware requirements:

None.

Target system software requirements :

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Check with your ISVs to make sure the product levels you are using support the new z/OS release, and then reconnect your ISV products to the new release of z/OS following the instructions provided by the ISVs. If any ISV products do not need to be installed in the same libraries and zones as z/OS, place them in their own sets of libraries and SMP/E zones. This means that, unless you have to change ISV product code, such as installing PTFs, or obtain a new level of the product, you will not need to reinstall it after you install a new ServerPac.

Reference information

For more information, see the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.7 : Reconnect subsystems


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

If you use subsystems, you need to make them usable with the new system.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if you use CICS®, DB2®, IMS, or NCP on your new system.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Ensure that any required target system PTFs are installed before you use the subsystem with the new z/OS system. This work includes any required SVCs, system modifications, parmlib setup, and proclib setup. Follow the instructions for the subsystem that you need to reconnect.

Tip: The required IBM PTFs for z/OS V2R4 are identified with the FIXCAT IBM.TargetSystem-RequiredService.z/OS.V2R4

Reference information

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.8 : Update operational and other procedures


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Depending on which method you used to install (ServerPac, CBPDO, or another deliverable), and which functions you plan to exploit, you might need to update the operation, automation, administration, security, backup, and recovery procedures for your site.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Review your operation, automation, administration, security, backup, and recovery procedures, and make any necessary changes depending on how you installed and which functions you plan to exploit. Some possible changes are:

  • Allowing applicable users access to new high-level qualifiers. The default new high-level qualifiers are shown in the workflow step called "Add references to new data sets and paths."
  • Updating and testing your backup and recovery procedures to accommodate the new target system.
  • Updating and testing any disaster recovery procedures.
  • Updating and testing any automation procedures to take advantage of new functions.
  • Updating security system definitions, such as defining new users and resources, permitting users to use new resources, and defining new profiles in the RACF® FACILITY class.
Reference information

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.9 : Verify that virtual storage limits are set properly


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Because virtual storage requirements can increase from release to release, it is recommended that you review your current settings for virtual storage limits.

Consider the following areas of potential concern:

  • Common areas (above and below the 16 MB line). An increase in virtual storage for the common areas reduces the virtual storage size of all address spaces.
  • Individual address spaces. An increase in virtual storage for individual address spaces impacts only the individual address spaces.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

To determine whether your virtual storage limits are set properly, use the health check IBMRSM,RSM_MEMLIMIT. It checks the current setting for the MEMLIMIT parameter in SMFPRMxx, which affects the amount of virtual storage above the 2 GB bar that is available to jobs. This check verifies that a nonzero MEMLIMIT value is in use.

Steps to take

Determine how much virtual storage use above the 2 GB bar to allow. Though there is no practical limit to the number of virtual addresses an address space can request above the bar, the system can limit the amount of virtual storage above the bar that an address space can use.

The amount of virtual storage above the bar is determined as follows:

  • The MEMLIMIT parameter in parmlib member SMFPRMxx sets the default system-wide limit, which defaults to 2 GB.
  • MEMLIMIT can be overridden for particular jobs by specifying REGION=0M or MEMLIMIT on JOB or EXEC statements in JCL.

To set a limit on the use of virtual storage above the bar, use the SMF exit IEFUSI or the parmlib member SMFLIMxx. For more information, see the topic on limiting the use of memory objects in z/OS MVS Programming: Extended Addressability Guide.

If you want to control the use of virtual storage above the 2 GB bar, do one or more of the following:

  • If the MEMLIMIT default of 2 GB is acceptable to you, no change to SMFPRMxx is necessary.

  • You can specify MEMLIMIT explicitly in JCL to override the system default that was set (or allowed to default) in SMFPRMxx.

  • You can specify REGION=0M on the job statement in JCL to implicitly set MEMLIMIT to NOLIMIT, which also overrides the system default (from SMFPRMxx).

  • You can use IEFUSI or parmlib member SMFLIMxx to establish a system default MEMLIMIT for different classes of work (for example, JOB, TSO, STC) and limit the amount of virtual storage that can be used above the bar, if an explicit or implicit nonzero MEMLIMIT is in effect from JCL or SMFPRMxx. The keyword HONORIEFUSIREGION NOHONORIEFUSIREGION is available in SCHEDxx to identify if the region and MEMLIMIT settings that are specified through or otherwise affected by the IEFUSI exit are to take effect for a program. If you are overriding the attribute of HASJES20 (JES2) in SCHEDxx parmlib member, specify NOHONORIEFUSIREGION explicitly so the default of HONORIEFUSIREGION is not used for this program.

Note: When calculating the large frame area (LFAREA) for your system, be aware of the following considerations:

  • z/OS with JES2 requires a minumum of 2M of LFAREA
  • z/OS without JES2 requires a minimum of 1M of LFAREA.

Reference information

For more information, see the following references:

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMRSM,RSM_MEMLIMIT.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".

NOTE: The successful running of this IBM Health Checker for z/OS check only partially covers this upgrade action. Refer to the upgrade action text for the complete list of steps to take.


Step 3.1.2.10 : Back virtual storage with sufficient real and auxiliary storage


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

As you use more virtual storage by defining additional address spaces or by exploiting memory objects, ensure that you have enough real and auxiliary storage defined.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Using an RMF report, determine whether more real or auxiliary storage is needed by checking the following real storage concentration indicators:

  • UIC and average available frames
  • Demand page rates
  • Percentage of auxiliary slots in use
Reference information

For more information about memory objects, see z/OS MVS Programming: Extended Addressability Guide.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.11 : Update your check customization for modified IBM Health Checker for z/OS checks


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Changes that IBM makes to the checks provided by IBM Health Checker for z/OS can affect any updates that you might have made.

The following health checks are new in z/OS V2R4:

  • IBMCS,ZOSMIGV2R4_NEXT_CS_OSIMGMT
  • IBMCS,ZOSMIGV2R4PREV_CS_IWQSC_tcpipstackname
  • IBM_JES2, JES2_UPGRADE_CKPT_LEVEL_JES2
  • IBMICSF,ICSF_PKCS_PSS_SUPPORT
  • IBMINFOPRINT, INFOPRINT_CENTRAL_SECURE_MODE
  • IBMINFOPRINT, ZOSMIGV2R3_NEXT_INFOPRINT_IPCSSL
  • IBMISPF,ISPF_WSA
  • IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

The following health checks are changed by IBM in z/OS V2R4:

  • IBMCS,CSVTAM_CSM_STG_LIMIT
  • IBMUSS,ZOSMIGV2R3_NEXT_USS_SMB_DETECTED

The following health checks were added in z/OS V2R3:

  • IBMISPF,ZOSMIGV2R3_Next_ISPF_GW_HTTPS

    The following health checks were deleted by IBM in z/OS V2R3:

    • IBMCNZ,CNZ_CONSOLE_OPERATING_MODE
    • IBMCS,CSAPP_FTPD_ANONYMOUS_JES
    • IBMCS,CSAPP_SMTPD_MAIL_RELAY
    • IBMCS,CSVTAM_VIT_OPT_STDOPTS.
    • IBMCS,ZOSMIGV2R2_NEXT_CS_LEGACYDEVICE
    • IBMCS,ZOSMIGV2R2_NEXT_CS_SENDMAILCLIEN
    • IBMCS,ZOSMIGV2R2_NEXT_CS_SENDMAILDAEMN
    • IBMCS,ZOSMIGV2R2_NEXT_CS_SENDMAILMSA
    • IBMCS,ZOSMIGV2R2_NEXT_CS_SENDMAILMTA
    • IBMCS,ZOSMIGV2R2_NEXT_CS_SMTPDDAEMON
    • IBMCS,ZOSMIGV2R2_NEXT_CS_SMTPDMTA
    • IBMCS,ZOSMIGV2R2_NEXT_CS_TFTP
    • IBMIXGLOGR,ZOSMIGV2R2_NEXT_IXG_REMOVE_DRXRC
    • IBMRSM,RSM_REAL
    • IBMRSM,ZOSMIGV2R3_RSM_MINIMUM_REAL
    • IBMVSAM,VSAM_CA_RECLAIM

    Information about this upgrade action

    The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

    Element or feature:

    Multiple.

    When change was introduced:

    General upgrade action not tied to a specific release.

    Applies to upgrade from:

    z/OS V2R3 and z/OS V2R2.

    Timing:

    Before the first IPL of z/OS V2R4.

    Is the upgrade action required?

    No, but recommended to ensure that your checks continue to work as you intend them to work.

    Target system hardware requirements:

    None.

    Target system software requirements:

    None.

    Other system (coexistence or fallback) requirements:

    None.

    Restrictions:

    None.

    System impacts:

    None.

    Related IBM Health Checker for z/OS check:

    See "Steps to take."

    Steps to take

    Follow these steps:

    1. Refer to the updated checks in IBM Health Checker for z/OS User's Guide.
    2. Review changes you made for those checks, in HZSPRMxx parmlib members, for example.
    3. Make any further updates for the checks to ensure that they continue to work as intended.
    Reference information

    For information about updating the checks, see IBM Health Checker for z/OS User's Guide.

    Instructions:

    This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.12 : Remove deleted data sets, paths, and references


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Data sets and paths are routinely removed from z/OS for reasons such as consolidation of data sets and removal of elements and features. You must determine whether these changes affect your environment.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Using the following tables as a guide, remove data sets and paths that do not exist in the current release (z/OS V2R4). Also, remove references to them. You might find references in the following places:

  • Parmlib
  • Proclib
  • Logon procedures
  • Catalogs
  • Security definitions, including program control definitions
  • DFSMS ACS routines
  • /etc/profile
  • SMP/E DDDEF entry
  • Backup and recovery procedures, as well as any references to them

In the tables, the data sets are identified as distribution library (DLIB) data sets or target library data sets.

Note:

Do not remove any data sets, paths, or references that are needed by earlier-level systems until those systems no longer need them.

Table 1. Data sets and paths deleted from z/OS V2R4 (in alphabetic order by DDDEF name)

DDDEF

Data set name or path (high-level qualifiers are defaults)

DLIB or target

From element or feature

When deleted

Why deleted

ABPXMCHS

SYS1.ABPXMCHS

DLIB

BCP

z/OS V2R4

FMID was removed from z/OS

ABPXPCHS

SYS1.ABPXPCHS

DLIB

BCP

z/OS V2R4

FMID was removed from z/OS

ABPXTCHS

SYS1.ABPXTCHS

DLIB

BCP

z/OS V2R4

FMID was removed from z/OS

AMSGCHS

SYS1.AMSGCHS

DLIB

BCP

z/OS V2R4

FMID was removed from z/OS

APHELP

SYS1.APHELP

DLIB

BCP

z/OS V2R4

FMID was removed from z/OS

 

 

 

 

 

 

AEOXFONT

EOY.AEOXFONT

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOXIENU

EOY.AEOXIENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOXOENU

EOY.AEOXOENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOX1ENU

EOY.AEOX1ENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOX2ENU

EOY.AEOX2ENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOX3ENU

EOY.AEOX3ENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOX4ENU

EOY.AEOX4ENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AEOXINLD

EOY.AEOXINLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOXONLD

EOY.AEOXONLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOX1NLD

EOY.AEOX1NLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOX2NLD

EOY.AEOX2NLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOX3NLD

EOY.AEOX3NLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOX4NLD

EOY.AEOX4NLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOYBNLD

EOY.AEOYBNLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOYGNLD

EOY.AEOYGNLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOYLNLD

EOY.AEOYLNLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOYMNLD

EOY.AEOYMNLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOYPNLD

EOY.AEOYPNLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOYSNLD

EOY.AEOYSNLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOYTNLD

EOY.AEOYTNLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

AEOYXNLD

EOY.AEOYXNLD

DLIB

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AEOXIFRA

EOY.AEOXIFRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOXOFRA

EOY.AEOXOFRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOX1FRA

EOY.AEOX1FRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOX2FRA

EOY.AEOX2FRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOX3FRA

EOY.AEOX3FRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOX4FRA

EOY.AEOX4FRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOYBFRA

EOY.AEOYBFRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOYGFRA

EOY.AEOYGFRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOYLFRA

EOY.AEOYLFRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOYMFRA

EOY.AEOYMFRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOYPFRA

EOY.AEOYPFRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOYSFRA

EOY.AEOYSFRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOYTFRA

EOY.AEOYTFRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

AEOYXFRA

EOY.AEOYXFRA

DLIB

BookManager READ French

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AEOXIDEU

EOY.AEOXIDEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOXODEU

EOY.AEOXODEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOX1DEU

EOY.AEOX1DEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOX2DEU

EOY.AEOX2DEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOX3DEU

EOY.AEOX3DEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOX4DEU

EOY.AEOX4DEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOYBDEU

EOY.AEOYBDEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOYGDEU

EOY.AEOYGDEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOYLDEU

EOY.AEOYLDEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOYMDEU

EOY.AEOYMDEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOYPDEU

EOY.AEOYPDEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOYSDEU

EOY.AEOYSDEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOYTDEU

EOY.AEOYTDEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

AEOYXDEU

EOY.AEOYXDEU

DLIB

BookManager READ German

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AEOXIESP

EOY.AEOXIESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOXOESP

EOY.AEOXOESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOX1ESP

EOY.AEOX1ESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOX2ESP

EOY.AEOX2ESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOX3ESP

EOY.AEOX3ESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOX4ESP

EOY.AEOX4ESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOYBESP

EOY.AEOYBESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOYGESP

EOY.AEOYGESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOYLESP

EOY.AEOYLESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOYMESP

EOY.AEOYMESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOYPESP

EOY.AEOYPESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOYSESP

EOY.AEOYSESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOYTESP

EOY.AEOYTESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

AEOYXESP

EOY.AEOYXESP

DLIB

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AEOXIITA

EOY.AEOXIITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOXOITA

EOY.AEOXOITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOX1ITA

EOY.AEOX1ITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOX2ITA

EOY.AEOX2ITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOX3ITA

EOY.AEOX3ITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOX4ITA

EOY.AEOX4ITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOYBITA

EOY.AEOYBITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOYGITA

EOY.AEOYGITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOYLITA

EOY.AEOYLITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOYMITA

EOY.AEOYMITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOYPITA

EOY.AEOYPITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOYSITA

EOY.AEOYSITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOYTITA

EOY.AEOYTITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

AEOYXITA

EOY.AEOYXITA

DLIB

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AEOXIPTB

EOY.AEOXIPTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOXOPTB

EOY.AEOXOPTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOYBPTB

EOY.AEOYBPTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOX1PTB

EOY.AEOX1PTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOX2PTB

EOY.AEOX2PTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOX3PTB

EOY.AEOX3PTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOX4PTB

EOY.AEOX4PTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOYGPTB

EOY.AEOYGPTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOYLPTB

EOY.AEOYLPTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOYMPTB

EOY.AEOYMPTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOYPPTB

EOY.AEOYPPTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOYSPTB

EOY.AEOYSPTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOYTPTB

EOY.AEOYTPTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

AEOYXPTB

EOY.AEOYXPTB

DLIB

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AEOXIFRC

EOY.AEOXIFRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOXOFRC

EOY.AEOXOFRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOX1FRC

EOY.AEOX1FRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOX2FRC

EOY.AEOX2FRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOX3FRC

EOY.AEOX3FRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOX4FRC

EOY.AEOX4FRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOYBFRC

EOY.AEOYBFRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOYGFRC

EOY.AEOYGFRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOYLFRC

EOY.AEOYLFRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOYMFRC

EOY.AEOYMFRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOYPFRC

EOY.AEOYPFRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOYSFRC

EOY.AEOYSFRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOYTFRC

EOY.AEOYTFRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

AEOYXFRC

EOY.AEOYXFRC

DLIB

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AEOXIDAN

EOY.AEOXIDAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOXODAN

EOY.AEOXODAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOX1DAN

EOY.AEOX1DAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOX2DAN

EOY.AEOX2DAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOX3DAN

EOY.AEOX3DAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOX4DAN

EOY.AEOX4DAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOYBDAN

EOY.AEOYBDAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOYGDAN

EOY.AEOYGDAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOYLDAN

EOY.AEOYLDAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOYMDAN

EOY.AEOYMDAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOYPDAN

EOY.AEOYPDAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOYSDAN

EOY.AEOYSDAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOYTDAN

EOY.AEOYTDAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

AEOYXDAN

EOY.AEOYXDAN

DLIB

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AEOYBENU

EOY.AEOYBENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYCLIB

EOY.AEOYCLIB

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYGENU

EOY.AEOYGENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYLENU

EOY.AEOYLENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYLEXS

EOY.AEOYLEXS

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYLOAD

EOY.AEOYLOAD

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYMENU

EOY.AEOYMENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYPENU

EOY.AEOYPENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYPROC

EOY.AEOYPROC

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYSAMP

EOY.AEOYSAMP

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYSENU

EOY.AEOYSENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYTENU

EOY.AEOYTENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEOYXENU

EOY.AEOYXENU

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEPHBOK1

EOX.AEPHBOK1

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEPHCLB1

EOX.AEPHCLB1

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEPHDAT1

EOX.AEPHDAT1

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEPHLOD1

EOX.AEPHLOD1

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEPHMSG1

EOX.AEPHMSG1

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEPHPNL1

EOX.AEPHPNL1

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEPHSAM1

EOX.AEPHSAM1

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

AEPHTBL1

EOX.AEPHTBL1

DLIB

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AIOEHSAM

IOE.AIOEHSAM

DLIB

DFS/SMB

z/OS V2R4

Element was removed from z/OS

AIOEHSHL

IOE.AIOEHSHL

DLIB

DFS/SMB

z/OS V2R4

Element was removed from z/OS

AIOEHSRC

IOE.AIOEHSRC

DLIB

DFS/SMB

z/OS V2R4

Element was removed from z/OS

AIOEHJPN

IOE.AIOEHJPN

DLIB

DFS/SMB

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AISPGDES

ISP.AISPGDES

DLIB

ISPF Swiss German

z/OS V2R4

FMID was withdrawn from z/OS

AISPMDES

ISP.AISPMDES

DLIB

ISPF Swiss German

z/OS V2R4

FMID was withdrawn from z/OS

AISPPDES

ISP.AISPPDES

DLIB

ISPF Swiss German

z/OS V2R4

FMID was withdrawn from z/OS

AISPSDES

ISP.AISPSDES

DLIB

ISPF Swiss German

z/OS V2R4

FMID was withdrawn from z/OS

AISPTDES

ISP.AISPTDES

DLIB

ISPF Swiss German

z/OS V2R4

FMID was withdrawn from z/OS

 

 

 

 

 

 

AISPGDEU

ISP.AISPGDEU

DLIB

ISPF German

z/OS V2R4

FMID was withdrawn from z/OS

AISPMDEU

ISP.AISPMDEU

DLIB

ISPF German

z/OS V2R4

FMID was withdrawn from z/OS

AISPPDEU

ISP.AISPPDEU

DLIB

ISPF German

z/OS V2R4

FMID was withdrawn from z/OS

AISPSDEU

ISP.AISPSDEU

DLIB

ISPF German

z/OS V2R4

FMID was withdrawn from z/OS

AISPTDEU

ISP.AISPTDEU

DLIB

ISPF German

z/OS V2R4

FMID was withdrawn from z/OS

 

 

 

 

 

 

AEPHBOOK

EPH.AEPHBOOK

DLIB

Library Server

z/OS V2R4

Element was removed from z/OS

AEPHCLIB

EPH.AEPHCLIB

DLIB

Library Server

z/OS V2R4

Element was removed from z/OS

AEPHLOAD

EPH.AEPHLOAD

DLIB

Library Server

z/OS V2R4

Element was removed from z/OS

AEPHSAMP

EPH.AEPHSAMP

DLIB

Library Server

z/OS V2R4

Element was removed from z/OS

AEPHTAB

EPH.AEPHTAB

DLIB

Library Server

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AIOAIBIN

IOA.AIOAIBIN

DLIB

OSA/SF

z/OS V2R4

Element was removed from z/OS

AIOALMOD

IOA.AIOALMOD

DLIB

OSA/SF

z/OS V2R4

Element was removed from z/OS

AIOAMMOD

IOA.AIOAMMOD

DLIB

OSA/SF

z/OS V2R4

Element was removed from z/OS

AIOASAMP

IOA.AIOASAMP

DLIB

OSA/SF

z/OS V2R4

Element was removed from z/OS

AIOAJAVA

IOA.AIOAJAVA

DLIB

OSA/SF

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

AICQPAB

SYS1.AICQPAB

DLIB

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

AICQPILB

SYS1.AICQPILB

DLIB

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

AICQPMA1

SYS1.AICQPMA1

DLIB

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

AICQPMA3

SYS1.AICQPMA3

DLIB

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

AICQPMA4

SYS1.AICQPMA4

DLIB

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

AICQPMA5

SYS1.AICQPMA5

DLIB

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

APLIB

SYS1.APLIB

DLIB

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

 

 

 

 

 

 

AGHELP

SYS1.AGHELP

DLIB

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

AGLIB

SYS1.AGLIB

DLIB

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

AICQGAB

SYS1.AICQGAB

DLIB

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

AICQGILB

SYS1.AICQGILB

DLIB

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

AICQGMA1

SYS1.AICQGMA1

DLIB

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

AICQGMA3

SYS1.AICQGMA3

DLIB

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

AICQGMA4

SYS1.AICQGMA4

DLIB

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

AICQGMA5

SYS1.AICQGMA5

DLIB

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

AMSGDEU

SYS1.AMSGDEU

DLIB

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

 

 

 

 

 

MSGCHS

SYS1.MSGCHS

Target

BCP

z/OS V2R4

FMID was removed from z/OS

PHELP

SYS1.PHELP

Target

BCP

z/OS V2R4

FMID was removed from z/OS

SBPXMCHS

SYS1.SBPXMCHS

Target

BCP

z/OS V2R4

FMID was removed from z/OS

SBPXPCHS

SYS1.SBPXPCHS

Target

BCP

z/OS V2R4

FMID was removed from z/OS

SBPXTCHS

SYS1.SBPXTCHS

Target

BCP

 

FMID was removed from z/OS

 

 

 

 

 

 

SEOXFONT

EOY.SEOXFONT

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOXIENU

EOY.SEOXIENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOXOENU

EOY.SEOXOENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOX1ENU

EOY.SEOX1ENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOX2ENU

EOY.SEOX2ENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOX3ENU

EOY.SEOX3ENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOX4ENU

EOY.SEOX4ENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYBENU

EOY.SEOYBENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYCLIB

EOY.SEOYCLIB

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYGENU

EOY.SEOYGENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYLENU

EOY.SEOYLENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYLEXS

EOY.SEOYLEXS

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYLOAD

EOY.SEOYLOAD

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYLPA

EOY.SEOYLPA

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYMENU

EOY.SEOYMENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYPENU

EOY.SEOYPENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYPROC

EOY.SEOYPROC

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYSAMP

EOY.SEOYSAMP

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYSENU

EOY.SEOYSENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYTENU

EOY.SEOYTENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEOYXENU

EOY.SEOYXENU

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEPHBOK1

EOX.SEPHBOK1

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEPHCLB1

EOX.SEPHCLB1

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEPHDAT1

EOX.SEPHDAT1

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEPHLOD1

EOX.SEPHLOD1

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEPHMSG1

EOX.SEPHMSG1

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEPHPNL1

EOX.SEPHPNL1

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEPHSAM1

EOX.SEPHSAM1

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

SEPHTBL1

EOX.SEPHTBL1

Target

BookManager READ Base and English

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

SEOXINLD

EOY.SEOXINLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOXONLD

EOY.SEOXONLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOX1NLD

EOY.SEOX1NLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOX2NLD

EOY.SEOX2NLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOX3NLD

EOY.SEOX3NLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOX4NLD

EOY.SEOX4NLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOYBNLD

EOY.SEOYBNLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOYGNLD

EOY.SEOYGNLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOYLNLD

EOY.SEOYLNLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOYMNLD

EOY.SEOYMNLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOYPNLD

EOY.SEOYPNLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOYSNLD

EOY.SEOYSNLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOYTNLD

EOY.SEOYTNLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

SEOYXNLD

EOY.SEOYXNLD

Target

BookManager READ Dutch

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

SEOXIFRA

EOY.SEOXIFRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOXOFRA

EOY.SEOXOFRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOX1FRA

EOY.SEOX1FRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOX2FRA

EOY.SEOX2FRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOX3FRA

EOY.SEOX3FRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOX4FRA

EOY.SEOX4FRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOYBFRA

EOY.SEOYBFRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOYGFRA

EOY.SEOYGFRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOYLFRA

EOY.SEOYLFRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOYMFRA

EOY.SEOYMFRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOYPFRA

EOY.SEOYPFRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOYSFRA

EOY.SEOYSFRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOYTFRA

EOY.SEOYTFRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

SEOYXFRA

EOY.SEOYXFRA

Target

BookManager READ French

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

SEOXIDEU

EOY.SEOXIDEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOXODEU

EOY.SEOXODEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOX1DEU

EOY.SEOX1DEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOX2DEU

EOY.SEOX2DEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOX3DEU

EOY.SEOX3DEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOX4DEU

EOY.SEOX4DEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOYBDEU

EOY.SEOYBDEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOYGDEU

EOY.SEOYGDEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOYLDEU

EOY.SEOYLDEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOYMDEU

EOY.SEOYMDEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOYPDEU

EOY.SEOYPDEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOYSDEU

EOY.SEOYSDEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOYTDEU

EOY.SEOYTDEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

SEOYXDEU

EOY.SEOYXDEU

Target

BookManager READ German

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

SEOXIESP

EOY.SEOXIESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOXOESP

EOY.SEOXOESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOX1ESP

EOY.SEOX1ESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOX2ESP

EOY.SEOX2ESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOX3ESP

EOY.SEOX3ESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOX4ESP

EOY.SEOX4ESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOYBESP

EOY.SEOYBESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOYGESP

EOY.SEOYGESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOYLESP

EOY.SEOYLESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOYMESP

EOY.SEOYMESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOYPESP

EOY.SEOYPESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOYSESP

EOY.SEOYSESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOYTESP

EOY.SEOYTESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

SEOYXESP

EOY.SEOYXESP

Target

BookManager READ Spanish

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

SEOXIITA

EOY.SEOXIITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOXOITA

EOY.SEOXOITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOX1ITA

EOY.SEOX1ITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOX2ITA

EOY.SEOX2ITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOX3ITA

EOY.SEOX3ITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOX4ITA

EOY.SEOX4ITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOYBITA

EOY.SEOYBITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOYGITA

EOY.SEOYGITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOYLITA

EOY.SEOYLITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOYMITA

EOY.SEOYMITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOYPITA

EOY.SEOYPITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOYSITA

EOY.SEOYSITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOYTITA

EOY.SEOYTITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

SEOYXITA

EOY.SEOYXITA

Target

BookManager READ Italian

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

SEOXIPTB

EOY.SEOXIPTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOXOPTB

EOY.SEOXOPTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOX1PTB

EOY.SEOX1PTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOX2PTB

EOY.SEOX2PTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOX3PTB

EOY.SEOX3PTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOX4PTB

EOY.SEOX4PTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOYBPTB

EOY.SEOYBPTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOYGPTB

EOY.SEOYGPTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOYLPTB

EOY.SEOYLPTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOYMPTB

EOY.SEOYMPTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOYPPTB

EOY.SEOYPPTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOYSPTB

EOY.SEOYSPTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOYTPTB

EOY.SEOYTPTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

SEOYXPTB

EOY.SEOYXPTB

Target

BookManager READ Brazilian Portuguese

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

SEOXIFRC

EOY.SEOXIFRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOXOFRC

EOY.SEOXOFRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOX1FRC

EOY.SEOX1FRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOX2FRC

EOY.SEOX2FRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOX3FRC

EOY.SEOX3FRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOX4FRC

EOY.SEOX4FRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOYBFRC

EOY.SEOYBFRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOYGFRC

EOY.SEOYGFRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOYLFRC

EOY.SEOYLFRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOYMFRC

EOY.SEOYMFRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOYPFRC

EOY.SEOYPFRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOYSFRC

EOY.SEOYSFRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOYTFRC

EOY.SEOYTFRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

SEOYXFRC

EOY.SEOYXFRC

Target

BookManager READ Canadian French

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

SEOXIDAN

EOY.SEOXIDAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOXODAN

EOY.SEOXODAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOX1DAN

EOY.SEOX1DAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOX2DAN

EOY.SEOX2DAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOX3DAN

EOY.SEOX3DAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOX4DAN

EOY.SEOX4DAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOYBDAN

EOY.SEOYBDAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOYGDAN

EOY.SEOYGDAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOYLDAN

EOY.SEOYLDAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOYMDAN

EOY.SEOYMDAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOYPDAN

EOY.SEOYPDAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOYSDAN

EOY.SEOYSDAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOYTDAN

EOY.SEOYTDAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

SEOYXDAN

EOY.SEOYXDAN

Target

BookManager READ Danish

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

SIOEHJPN

IOE.SIOEHJPN - Japanese

Target

DFS/SMB

z/OS V2R4

Element was removed from z/OS

SIOEHLIB

usr/lpp/dfs/global/lib/IBM/

Target

DFS/SMB

z/OS V2R4

Element was removed from z/OS

SIOEHSAM

usr/lpp/dfs/global/examples/IBM/

Target

DFS/SMB

z/OS V2R4

Element was removed from z/OS

SIOEHSHL

usr/lpp/dfs/global/scripts/IBM/

Target

DFS/SMB

z/OS V2R4

Element was removed from z/OS

SIOEHSRC

usr/lpp/dfs/global/src/IBM/

Target

DFS/SMB

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

SAOPICSE

/usr/lpp/Printsrv/InfoprintCentral/Scripts/nls/IBM/

Target

Infoprint Server

z/OS V2R4

Function was removed from the z/OS element.

SAOPICSJ

/usr/lpp/Printsrv/InfoprintCentral/Scripts/nls/ja/IBM/

Target

Infoprint Server

z/OS V2R4

Function was removed from the z/OS element.

SAOPICXC

/usr/lpp/Printsrv/InfoprintCentral/xsl/Controls/IBM/

Target

Infoprint Server

z/OS V2R4

Function was removed from the z/OS element.

SAOPICXP

/usr/lpp/Printsrv/InfoprintCentral/xsl/Page/IBM/

Target

Infoprint Server

z/OS V2R4

Function was removed from the z/OS element.

 

 

 

 

 

 

SISPGDES

ISP.SISPGDES

Target

ISPF - Swiss German

z/OS V2R4

FMID was withdrawn from z/OS

SISPMDES

ISP.SISPMDES

Target

ISPF - Swiss German

z/OS V2R4

FMID was withdrawn from z/OS

SISPPDES

ISP.SISPPDES

Target

ISPF - Swiss German

z/OS V2R4

FMID was withdrawn from z/OS

SISPSDES

ISP.SISPSDES

Target

ISPF - Swiss German

z/OS V2R4

FMID was withdrawn from z/OS

SISPTDES

ISP.SISPTDES

Target

ISPF - Swiss German

z/OS V2R4

FMID was withdrawn from z/OS

SISPGDEU

ISP.SISPGDEU

Target

ISPF - German

z/OS V2R4

FMID was withdrawn from z/OS

SISPMDEU

ISP.SISPMDEU

Target

ISPF - German

z/OS V2R4

FMID was withdrawn from z/OS

SISPPDEU

ISP.SISPPDEU

Target

ISPF - German

z/OS V2R4

FMID was withdrawn from z/OS

SISPSDEU

ISP.SISPSDEU

Target

ISPF - German

z/OS V2R4

FMID was withdrawn from z/OS

SISPTDEU

ISP.SISPTDEU

Target

ISPF - German

z/OS V2R4

FMID was withdrawn from z/OS

 

 

 

 

 

 

SEPHBOOK

/usr/lpp/booksrv/books/IBM/

Target

Library Server

z/OS V2R4

Element was removed from z/OS

SEPHCASE

/usr/lpp/booksrv/cases/IBM/

Target

Library Server

z/OS V2R4

Element was removed from z/OS

SEPHCLIB

EPH.SEPHCLIB

Target

Library Server

z/OS V2R4

Element was removed from z/OS

SEPHGIF

/usr/lpp/booksrv/public/bookmgr/IBM/

Target

Library Server

z/OS V2R4

Element was removed from z/OS

SEPHLOAD

/usr/lpp/booksrv/cgi-bin/IBM/

Target

Library Server

z/OS V2R4

Element was removed from z/OS

SEPHPLIB

/usr/lpp/booksrv/plugins/IBM/

Target

Library Server

z/OS V2R4

Element was removed from z/OS

SEPHPUB

/usr/lpp/booksrv/public/IBM/

Target

Library Server

z/OS V2R4

Element was removed from z/OS

SEPHSAMP

EPH.SEPHSAMP

Target

Library Server

z/OS V2R4

Element was removed from z/OS

SEPHSHLF

/usr/lpp/booksrv/public/bookmgr/shelves/IBM/

Target

Library Server

z/OS V2R4

Element was removed from z/OS

SEPHSRVR

/usr/lpp/booksrv/public/bookmgr/libraryserver/IBM/

Target

Library Server

z/OS V2R4

Element was removed from z/OS

SEPHTAB

EPH.SEPHTAB

Target

Library Server

z/OS V2R4

Element was removed from z/OS

SEPHTPLT

/usr/lpp/booksrv/public/bookmgr/templates/IBM/

Target

Library Server

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

SIOAIBIN

IOA.SIOAIBIN

Target

OSA/SF

z/OS V2R4

Element was removed from z/OS

SIOALMOD

IOA.SIOALMOD

Target

OSA/SF

z/OS V2R4

Element was removed from z/OS

SIOAMMOD

IOA.SIOAMMOD

Target

OSA/SF

z/OS V2R4

Element was removed from z/OS

SIOASAMP

IOA.SIOASAMP

Target

OSA/SF

z/OS V2R4

Element was removed from z/OS

SIOAJAVA

IOA.SIOAJAVA

Target

OSA/SF

z/OS V2R4

Element was removed from z/OS

 

 

 

 

 

 

CHSLIB

SYS1.CHSLIB

Target

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

ICQPABTX

ICQ.ICQPABTX

Target

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

ICQPCLIB

ICQ.ICQPCLIB

Target

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

ICQPILIB

ICQ.ICQPILIB

Target

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

ICQPMLIB

ICQ.ICQPMLIB

Target

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

ICQPPLIB

ICQ.ICQPPLIB

Target

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

ICQPTABL

ICQ.ICQPTABL

Target

TSO/E Chinese

z/OS V2R4

FMID was withdrawn from z/OS

GERLIB

SYS1.GERLIB

Target

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

GHELP

SYS1.GHELP

Target

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

ICQGABTX

ICQ.ICQGABTX

Target

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

ICQGCLIB

ICQ.ICQGCLIB

Target

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

ICQGILIB

ICQ.ICQGILIB

Target

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

ICQGMLIB

ICQ.ICQGMLIB

Target

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

ICQGPLIB

ICQ.ICQGPLIB

Target

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

ICQGTABL

ICQ.ICQGTABL

Target

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

MSGDEU

SYS1.MSGDEU

Target

TSO/E German

z/OS V2R4

FMID was withdrawn from z/OS

 

 

 

 

 

 

SFSUMCHS

/usr/lib/nls/msg/Zh_CN/IBM/

Target

z/OS UNIX

z/OS V2R4

FMID is withdrawn from z/OS

Table 2. Data sets and paths deleted from z/OS V2R3 (in alphabetic order by DDDEF name)

DDDEF

Data set name or path (high-level qualifiers are defaults)

DLIB or target

From element or feature

When deleted

Why deleted

/usr/lpp/bcp/mca

BCP

z/OS V2R3

Obsolete; GPMP component was removed.

/usr/lpp/bcp/mca/bin

BCP

z/OS V2R3

Obsolete; GPMP component was removed.

/usr/lpp/bcp/mca/bin/migration

BCP

z/OS V2R3

Obsolete; GPMP component was removed.

/usr/lpp/bcp/mca/lib

BCP

z/OS V2R3

Obsolete; GPMP component was removed.

/usr/lpp/bcp/mca/classes

BCP

z/OS V2R3

Obsolete; GPMP component was removed.

/usr/lpp/bcp/mca/classes/fb

 

BCP

z/OS V2R3

Obsolete; GPMP component was removed.

/usr/lpp/bcp/mca/classes/ARM

 

BCP

z/OS V2R3

Obsolete; GPMP component was removed.

/usr/lpp/bcp/mca/classes/ms

BCP

z/OS V2R3

Obsolete; GPMP component was removed.

/usr/lpp/bcp/mca/samples

BCP

z/OS V2R3

Obsolete; GPMP component was removed.

/usr/lpp/bcp/mca/util

BCP

z/OS V2R3

Obsolete; GPMP component was removed.

ACBDEHFS

SYS1.ACBDEHFS

DLIB

HCD

z/OS V2R3

Remove the HFS parts

AISFLINK

ISF.AISFLINK

DLIB

SDSF

z/OS V2R3

Obsolete

CCSSLIB

N/A

Target

ICSF

z/OS V2R3

Remove the DDDEF

SCBDETCH

/usr/lpp/hcd/etc/IBM/

Target

HCD

z/OS V2R3

Remove the HFS parts

SCBDEXMP

/usr/lpp/hcd/examples/IBM/

Target

HCD

z/OS V2R3

Remove the HFS parts

SCBDHFSL

/usr/lpp/hcd/bin/IBM/

Target

HCD

z/OS V2R3

Remove the HFS parts

SCBDMLDP

/usr/lpp/hcd/msg/IBM/

Target

HCD

z/OS V2R3

Remove the HFS parts

Reference information

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.13 : Add references to new data sets and paths


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

New data sets and paths are routinely added to z/OS for reasons such as consolidation of data sets and addition of new elements and features. You must determine whether these additions affect your environment.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Using the following tables as a guide, add references in the following places for data sets and paths that have been added to z/OS:

  • Parmlib
  • Proclib
  • Logon procedures
  • Catalogs
  • Security definitions, including program control definitions
  • DFSMS ACS routines
  • /etc/profile
  • SMP/E DDDEF entry
  • Backup and recovery procedures, as well as any references to them
Restriction:

Some of the data sets shipped with z/OS are PDSEs and are most likely in your LNKLST. If one or more are in your LNKLST and on your system residence volume, adhere to the following PDSE sharing rules to avoid data set corruption:

  • If you specified PDSESHARING(NORMAL), do not share PDSE data sets beyond the scope of the global resource serialization complex.
  • If you specified PDSESHARING(EXTENDED), do not share PDSE data sets beyond the scope of the sysplex.

In the tables, the data sets are identified as distribution library (DLIB) data sets or target library data sets.

Table 1. Data sets added to z/OS V2R4 (in alphabetic order by DDDEF name)

DDDEF

Data set name (high-level qualifiers are defaults) or path

DLIB or target

To element or feature

When added

Why added

AAZDFFS

AZD.AAZDFFS

DLIB

z/OS Container Extensions (zCX)

V2R4

Element was added to z/OS

SAZDFFS

/usr/lpp/zcx_zos/IBM/

Target

z/OS Container Extensions (zCX)

V2R4

Element was added to z/OS

/usr/include/zos

Target

BCP

V2R4

New C header path

Table 2. Data sets added to z/OS V2R3 (in alphabetic order by DDDEF name)

DDDEF

Data set name (high-level qualifiers are defaults) or path

DLIB or target

To element or feature

When added

Why added

ABBLEXEC

BBL.ABBLEXEC

DLIB

IBM z/OS Liberty Embedded (new element)

z/OS V2R3

New data set

ABBLJCL

BBL.ABBLJCL

DLIB

IBM z/OS Liberty Embedded (new element)

z/OS V2R3

New data set

ABBLLIB

BBL.ABBLLIB

DLIB

IBM z/OS Liberty Embedded (new element)

z/OS V2R3

New data set

ACCNSR6

CBC.ACCNSR6

DLIB

z/OS XL C/C++

z/OS V2R3

New data set

ACCNSR7

CBC.ACCNSR7

DLIB

z/OS XL C/C++

z/OS V2R3

New data set

SBBLEXEC

BBL.SBBLEXEC

Target

IBM z/OS Liberty Embedded (new element)

z/OS V2R3

New data set

SBBLJCL

BBL.SBBLJC

Target

IBM z/OS Liberty Embedded (new element)

z/OS V2R3

New data set

SBBLLIB

/usr/lpp/liberty_zos/IBM

Target

IBM z/OS Liberty Embedded (new element)

z/OS V2R3

New data set

SCCNM12

CBC.SCCNM12

Target

z/OS XL C/C++

z/OS V2R3

New data set

SCCNN12

CBC.SCCNN12

Target

z/OS XL C/C++

z/OS V2R3

New data set

SCSFSTUB

CSF.SCSFSTUB

Target

ICSF

z/OS V2R3

New data set

Reference information

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.2.14 : Accommodate new address spaces


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The MAXUSER value in parmlib member IEASYSxx specifies a value that the system uses to limit the number of jobs and started tasks that can run concurrently during a particular IPL. You might want to increase your MAXUSER value to take new address spaces into account.

The following elements add new address spaces for z/OS V2R4:

  • z/OS Container Extensions (zCX) is a new element in z/OS V2R4. It provides the runtime support to deploy and run Linux on IBM Z applications that are packaged as Docker Container images on z/OS.

The following address space is new for z/OS V2R4:

  • zCX creates one address space for each provisioned server that is started by the user.

The following elements add new address spaces for z/OS V2R3:

  • JES2.

The following address space is new for z/OS V2R3:

  • JES2 Email Delivery Services (EDS). One new persistent address space is created by JES2 when JES2 email interfaces are used:
    • A job is submitted with the NOTIFY JCL statement that requests notification by an email message.
    • The Notify user message service (SSI 75) is called with email address as the target of a message.

    The address space is named jesxEDS, where jesx is the name of the JES2 subsystem. You must ensure that a proper user ID is assigned to the address space. This user identifier does not have to be the same as the user identifier for JES2, but you can avoid unnecessary complexity by using the same one. The user ID is specified either by adding an entry in the started procedures table (ICHRIN03) or by creating a profile in the STARTED class that matches address space name. If you prefer, both the started procedures table and STARTED class profile can be used. This action ensures that the correct user ID is assigned to the address space.

The following address spaces existed in prior releases, but are now started automatically in z/OS V2R3 during the IPL process:

HZR
Runtime Diagnostics address space
IZUANG1
IBM z/OS Management Facility (z/OSMF) angel process
IZUSVR1
IBM z/OS Management Facility (z/OSMF) server process

More information about the Runtime Diagnostics address space is provided in the workflow step called "Remove commands or logic that start or restart Runtime Diagnostics."

More information about the z/OSMF address spaces is provided in the workflow step called "Prepare for z/OSMF autostart."

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

  • z/OS Container Extensions (zCX)
  • JES2

When change was introduced:

  • z/OS V2R4 for the following:
    • ZCX
  • z/OS V2R3 for the following:
    • jesx EDS

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

No, but recommended to ensure that your MAXUSER value in parmlib member IEASYSxx is adequate.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

If necessary, increase your MAXUSER value in parmlib member IEASYSxx to accommodate the new address spaces. One way to determine how many address spaces you use is to enter the DISPLAY A,L command. Then, add the number of address spaces in the output messages IEE114I and IEE115I on the old and new systems to determine the total number. As of z/OS V2R3, these messages are replaced by messages CNZ4015I and CNZ4016I, respectively.

Note:
  • A modest over-specification of MAXUSER should not affect system performance.
  • The number of total address spaces is the sum of M/S, TS USERS, SYSAS, and INITS.
  • If you change the MAXUSER value, you must re-IPL to make the change effective.
Reference information

For more information about the MAXUSER parameter, see z/OS MVS Initialization and Tuning Reference.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.1.3 : Upgrade actions for everyone after the first IPL of z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes upgrade actions that you can perform only after you have IPLed z/OS V2R4. You need a running z/OS V2R4 system to perform these actions.

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2 : Hardware upgrade actions


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes hardware upgrade actions. The information in this topic is not specifically related to upgrading to z/OSV2R4; it applies only if you are changing hardware. Therefore, this topic does not categorize the actions in terms of when they should be performed (before installing, before the first IPL, or after the first IPL).


Step 3.2.1 : Upgrade to an IBM z15 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

Description

With the new IBM® z15™ (z15™) server as the infrastructure, your business has the power to optimize digital services delivery, accelerate business innovation, and ultimately improve the bottom line. The z15 can help you adapt to planned or unplanned events while keeping services and operations running smoothly and continuously, on premises or in the cloud.

The z15 server is one hardware model (T01) and machine type (8561), with five feature codes to represent the processor capacity. The feature codes are Max34, Max71, Max108, Max145, and Max190 with (respectively) 34, 71, 108, 145, and 190 processors. The z15 ™ uses a 19-inch form factor and industry-standardized power and networking hardware. The system is configurable as a one-to-four 19-inch frame system, which easily aligns with the modern cloud data center.

z/OS base support for specific z15 functions depends on the z/OS release. Table 1 lists the z15 functions and indicates whether each function is included in a specific z/OS release (Yes or No), or whether the function requires a PTF (PTF) or a web deliverable (Web). For information about finding the appropriate PTFs, see the workflow step "Actions you can take before you order an IBM z15 server." For more information about z/OS V2R1 support, see the Table Notes.

The following table shows a summary view of which z15 server functions are included in the base support for z/OS V2R2, z/OS V2R3, and z/OS V2R4.

Table 1. z15 server functions included in the base support for z/OS V2R2, z/OS V2R3, and z/OS V2R4.

z15 function included in base z/OS support (Y/N)

V2R2 3

V2R3 3

V2R4 3

Base support ¹

PTF

PTF

Yes, and in PTFs

CPU measurement facility

PTF

PTF

PTF

FICON® Express16S+ (CHPID type FC) when using FICON or channel-to-channel (CTC) 1

  • FICON Express16S+ LX
  • FICON Express16S+ SX

PTF

PTF

Yes

New z15 machine instruction (assembly language support) 2

PTF

PTF

PTF

OSA-Express7S 1

  • OSA-Express7S GbE LX (CHPID type OSC or OSD)
  • OSA-Express7S GbE SX (CHPID type OSC or OSD)
  • OSA-Express7S 10 GbE LR (CHPID type OSD)
  • OSA-Express7S 10 GbE SR (CHPID type OSD)
  • OSA-Express7S 25 GbE SR (CHPID type OSD)

PTF

PTF

Yes

OSA-Express7S 1000BASE-T Ethernet 1 (CHPID type OSC or OSD)

PTF

PTF

Yes

CHPID type CS5 for coupling

Yes

Yes

Yes

CHPID type OSE supporting 4 or 2 ports per feature

Yes

Yes

Yes

CFCC Fair Latch Manager

PTF

PTF

PTF

Table Notes:
  1. z/OS V2R1 (compatibility only). Extended support contract for IBM Software Support Services for z/OS is required with PTFs.
  2. z/OS V2R1 with an extended support contract for IBM Software Support Services and PTFs.
  3. To determine the PTFs for base support, use FIXCAT value IBM.Device.Server.z15-8561.RequiredService for the z15, and the fix categories for earlier processors.

The exploitation of specific z15 server functions depends on the z/OS release. The following table lists the z15 functions and indicates whether each function is exploited by a specific z/OS release (Yes or No), or whether the function requires a PTF (PTF) or a web deliverable (Web). For information about finding the appropriate PTFs, see the workflow step "Actions you can take before you order an IBM z15 server." For more information about z/OS V2R1 support, see the Table Notes.

The following table shows a summary view of which z15 server functions can be exploited in z/OS V2R2, z/OS V2R3, and z/OS V2R4.

Table 2. Exploitation of z15 server functions supported by z/OS V2R2, z/OS V2R3, and z/OS V2R4.

z15 function included in base z/OS support (Y/N)

V2R2 ²

V2R3 ²

V2R4²

Processors: The maximum number of processors that can be configured per server.

For the IBM z15:

  • Up to 190 processors configurable as CPs, zIIPs, IFLs, ICFs, or optional SAPs.
  • The sum of CPs and zIIPs configured in a single z/OS LPAR cannot exceed:
    • 190 on z/OS V2R1 or later in non-SMT mode
    • 128 on z/OS V2R1 or later in SMT mode.

Yes

Yes

Yes

Two-way simultaneous multithreading (SMT) for zIIPs, IFLs, ICFs, or SAPs.

Yes

Yes

Yes

Channel subsystems.

The maximum number of channel subsystems (CSS) that can be configured per server.

For the IBM z15:

  • Up to six channel subsystems
  • Four subchannel sets per CSS.

Yes

Yes

Yes

Up to 40 TB of Redundant Array of Independent Memory (RAIM) per server. Up to 4 TB per z/OS LPAR with z/OS V2R1 or later.

Yes

Yes

Yes

2 GB Large Pages

Yes

Yes

Yes

Logical partitions.

The maximum number of logical partitions (LPARs) that can be configured per server. For the z15, up to 85 LPARs can be configured.

Yes

Yes

Yes

Coupling Facility Control Code Level 24 (CFLEVEL 24). 3

Includes support for:

  • CFCC Fair Latch Manager
  • CFCC Message Path Resiliency Enhancement

PTF

PTF

PTF

Coupling Express3 (CX3) LR 3

PTF

PTF

Yes

Support for 384 Coupling CHPIDs, 96 physical ICA SR coupling links, and 64 ICP internal coupling channels 3

Yes

Yes

Yes

Support of High-Performance FICON (zHPF) single-track or multitrack operations (CHPID type FC)

PTF

PTF

PTF

CHPID type OSC supporting TN3270E and non-SNA DFT

Yes

Yes

Yes

CHPID type OSD with exploitation of two ports per CHPID

Yes

Yes

Yes

CHPID type OSD without maximum port exploitation (one port on the PCIe adapter is available for use)

Yes

Yes

Yes

CHPID type OSE supporting 4 or 2 ports per feature

Yes

Yes

Yes

FICON Express16SA (CHPID type FC) when using FICON or channel-to-channel (CTC)¹

PTF

PTF

PTF

FICON Express16SA (CHPID type FC) for support of zHPF single track or multi-track operations 1

PTF

PTF

PTF

Checksum offload for IPV6 packets (CHPID type OSD) 1

Yes

Yes

Yes

Checksum offload for LPAR-to-LPAR traffic for IPv4 and IPV6 packets (CHPID type OSD) 1

Yes

Yes

Yes

Large Send for IPV6 packets (CHPID type OSD) 1

Yes

Yes

Yes

Crypto Express7S Toleration

Yes

Yes

Yes

Crypto Express7S support of VISA Format Preserving Encryption (VFPE)

Web: Enhanced Cryptographic Support for z/OS V2.2 (HCR77B0)

Yes

Yes

Crypto Express7S support of greater than 16 Domains

Web: Cryptographic Support for V2R2 - V2R4 (HCR77D1) with PTFs

Web: Cryptographic Support for V2R2 - V2R4 (HCR77D1) with PTFs

Web: Cryptographic Support for V2R2 - V2R4 (HCR77D1) with PTFs

Crypto Express6S Exploitation

Web: Enhanced Cryptographic Support for z/OS V2.2 – z/OS V2.4 (HCD77D1)

Web: Enhanced Cryptographic Support for z/OS V2.2 – z/OS V2.4 (HCD77D1)

Web: Enhanced Cryptographic Support for z/OS V2.2 – z/OS V2.4 (HCD77D1)

Crypto Express7S support of PCI-HSM compliance

Web: Enhanced Cryptographic Support for z/OS V2.2 – z/OS V2.4 (HCD77D1)

Web: Enhanced Cryptographic Support for z/OS V2.2 – z/OS V2.4 (HCD77D1)

Web: Enhanced Cryptographic Support for z/OS V2.2 – z/OS V2.4 (HCD77D1)

10 GbE RoCE Express2.1 for Shared Memory Communications-Remote Direct Memory Access (SMC-R)

PTF

PTF

Yes

25 GbE RoCE Express2.1 for Shared Memory Communications - Remote Direct Memory Access (SMC-R)

PTF

PTF

Yes

IBM Integrated Coupling Adapter (ICA SR1.1) (CHPID type CS5) 3

Yes

Yes

Yes

zHyperLink Express Reads support 3

PTF

PTF

Yes

zHyperLink Express Writes support

PTF

PTF

Yes

IBM Virtual Flash Memory

Yes

Yes

Yes

IBM z/OS XL C/C++ support of the ARCH(13) and TUNE(13) parameters

No

No

Yes

Integrated Accelerator for z Enterprise Data Compression

PTF

PTF

PTF

System Recovery Boost

No

PTF

PTF

IBM Z Data Privacy for Diagnostics

No

PTF

PTF

Quantum Safe Support

Web: Enhanced Cryptographic Support for z/OS V2.2 – z/OS V2.4 (HCD77D1) and coexistence PTFs for SMF.

Web: Enhanced Cryptographic Support for z/OS V2.2 – z/OS V2.4 (HCD77D1) and coexistence PTFs for SMF.

Web: Enhanced Cryptographic Support for z/OS V2.2 – z/OS V2.4 (HCD77D1) and PTFs.

Table Notes:
  1. z/OS V2R1 (compatibility only). Extended support contract for IBM Software Support Services for z/OS is required with PTFs.
  2. To determine the PTFs for base support, use FIXCAT value IBM.Device.Server.z15-8561.RequiredService for the z15, and the fix categories for earlier processors.
  3. z/OS V2R1 with PTFs.

Web deliverables are available from the z/OS downloads page at z/OS downloads.

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Table 3. Information about this upgrade action

Element or feature:

Multiple.

When change was introduced:

IBM z15, which became available in September 2019.

Applies to upgrade from:

z/OS V2R4, z/OS V2R3, and z/OS V2R2.

Timing:

Before you introduce a z15 server into your environment.

Is the upgrade action required?

Yes, if you want to run z/OS V2R4, z/OS V2R3, or z/OS V2R2 on a z15 server, or if you want to run a coupling facility on a z15 server. If you plan to run only a coupling facility on a z15 system, only the sysplex-related actions are relevant. However, you must install the appropriate z/OS service for systems that are running on other servers that use the z15 coupling facilities.

Target system hardware requirements:

  • z/OS V2R4 and z/OS V2R3 require a minimum of 8 GB of memory to IPL. When running as a z/VM guest or on an IBM Z® Personal Development Tool (zPDT), at least 2 GB is required for z/OS V2R4 and z/OS V2R3. If the minimum is not met, a warning WTOR is issued at IPL.
  • A z15 with Hardware Management Console (HMC) Version 2.15.0 plus microcode change levels (MCLs) and the Support Element Version 2.15.0. The IBM Z Hardware Management Appliance feature code 0100 can be ordered to provide HMC/SE functions within the CPC frame, eliminating the need for separate HMCs outside of the frame.
  • Additional hardware required for specific functions:
    • IBM devices that are attached to z14, z14 ZR1, z13, and z13s servers are supported for attachment to z15 channels, unless otherwise noted. The subject I/O devices must meet FICON architecture requirements.
    • IBM Virtual Flash Memory requires FC #0643.
    • 10 GbE RoCE Express2.1 requires FC #0432.
    • 25 GbE RoCE Express2.1 requires FC #0450.
    • New OSA-Express7S adapters require the following feature codes:
      • OSA-Express7S GbE LX requires FC #0442
      • OSA-Express7S GbE SX requires FC #0443
      • OSA-Express7S 10 GbE LR requires FC #0444
      • OSA-Express7S 10 GbE SR requires FC #0445
      • OSA-Express7S 25 GbE SR1.1 requires FC #0449
      • OSA-Express7S 1000BASE-T requires FC #0446.
      Note:

      For storage related requirements for OSA-Express7S 25GbE, refer to the topic about fixed storage considerations for OSA-Express interfaces in QDIO mode in IP Configuration Guide.

    • New FICON Express16SA cards require the following feature codes:
      • FICON Express16SA LX requires FC #0436
      • FICON Express16SA SX requires FC #0437.
    • zHyperLink Express1.1 adapter requires FC #0451.
    • Coupling Express LR requires FC #0433.
    • IBM Integrated Coupling Adapter (ICA SR1.1) requires FC #0176.
    • zHyperLink Express1.1 requires FC #0451.
    • If you plan to enable the temporary activation of additional physical zIIP processors to be used with System Recovery Boost, you require the Boost Authorization feature (FC #9930) and the Sys Recovery Boost Record feature (FC ##6802).
    • Crypto Express7S adapter: Crypto Express7S (2 port) requires FC #0898; Crypto Express7S (1 port) requires FC #0899.
    • Use of hardware acceleration for cryptographic operations, including the use of Visa, Inc. Data Secure Platform (DSP) functions requires CP Assist for Cryptographic Function (CPACF) (#3863) or a supported cryptographic feature, such as Crypto Express7S, or both. See Table Note 1.
    • Use of a new Trusted Key Entry (TKE) workstation requires TKE Rack Mount w/4768 (FC #0087) or TKE w/4768 (FC #0086). The TKE workstation is a combination of hardware and software, with other features required, depending on which functions you plan to use. Different feature codes are required if you are upgrading an existing TKE workstation from an earlier server.

      Trusted Key Entry (TKE) 9.2 License Internal Code (FC ##0881) is required if you plan to use the TKE to manage a Crypto Express7S. For example, TKE 9.2 is required to:

      • Manage any Crypto Express feature that is running in IBM Enterprise PKCS #11 (EP11) mode.
      • Manage Common Cryptographic Architecture (CCA) mode PCI-HSM settings that are available on the Crypto Express7S.

      CCA in PCI-HSM mode and EP11 also require a smart card reader (FC #0885 or #0891), plus FIPS certified smart cards (FC #0892).

Target system software requirements:

For more information, see the step "Support is delivered by service, z/OS features, and web deliverables" under "General recommendations and considerations for a z15 server." You will install the required service updates on your system when you perform the step "Install the necessary z/OS service" under "Actions you can take before you order an IBM z15 server."

Other system (coexistence or fallback) requirements:

  • The suggested practice is to install and run the required service on your existing server. This action enables you to fall back from a hardware perspective, yet maintain your software level.
  • If you have not installed the preconditioning and exploitation PTFs for CFLEVEL 17-23, note that those PTFs are required to be installed throughout your sysplex before implementing CFLEVEL 24. Use the appropriate fix category. For the IBM z15, use FIXCAT value IBM.Device.Server.z15-8561.RequiredService.
  • If you are using ICSF and plan to share keys with other z/OS systems that have an earlier level of ICSF, install the ICSF coexistence PTFs on those earlier levels of ICSF. For ICSF coexistence PTFs, see "Step 4.5. Determine the level of cryptographic support you require on a z15 server" for the appropriate SMP/E fix category values to use.

Restrictions:

See the steps under "Restrictions for a z15 server."

System impacts:

None.

Related IBM Health Checker for z/OS check:

Use health check IBMRSM,ZOSMIGV2R3_RSM_MINIMUM_REAL, which issues a warning for a system that is configured with less than 8 GB of real memory.


Table Note:
  1. IBM Z® cryptography features include VISA Format Preserving Encryption (VFPE) technology, which forms part of the Visa, Inc. Data Secure Platform (DSP). The use of VFPE technology requires a service agreement with Visa, Inc. For details, contact your Visa account manager or Visa at P2PE@visa.com. Clients who use IBM Z® cryptography features, but do not make use of the FPE functionality, are not required to enter into any such agreement with Visa.

Steps to take

Continue your upgrade to the z15 by performing the following steps in this workflow. Each step contains a number of sub-steps for you to perform.

  • "General recommendations and considerations for a z15 server"
  • "Restrictions for a z15 server"
  • "Actions you can take before you order an IBM z15 server"
  • "Actions you can take after installing an IBM z15 server"
  • "Accommodate functions for the z15 to be discontinued on future servers"

Reference information

For more information about new functions to exploit, see the IBM z15 Library, which is available online in Resource Link™.


Step 3.2.1.1 : General recommendations and considerations for a z15 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

As you plan your upgrade to an IBM z15™ server, observe the recommendations and considerations in the steps that follow.


Step 3.2.1.1.1 : Migration actions for IBM servers are cumulative


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

If you upgrade to a z15™ server from a z14™ or z14 ZR1 server, and have performed the upgrade actions that are associated with the z14 or z14 ZR1, you have fewer upgrade actions than if you upgrade from an earlier generation server. Thus, if you upgrade from an earlier generation server, you might need to perform more upgrade actions. For example, if you are upgrading from a z13 and z13s server, you should perform the "z14 Upgrade Workflow" or the "Upgrade to an IBM z14 server" steps in the "z/OS V2R4 Upgrade Workflow".

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.1.2 : Support is delivered by service, z/OS features, and web deliverables


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The base support for the z15™ is delivered through service (PTFs). To determine which PTFs are required, get the current enhanced HOLDDATA file, either by using the SMP/E RECEIVE ORDER command or by downloading the 2-year file and using the SMP/E RECEIVE command to process it. Then, use the SMP/E REPORT MISSINGFIX report to identify the missing PTFs, if any. For example:

SET BDY(GLOBAL). REPORT MISSINGFIX ZONES( target zone) FIXCAT(IBM.Device.Server.*.RequiredService).

If you want more granular reports for REPORT MISSINGFIX, you can use the individual fix categories for each server, plus the fix categories for any intermediate services. For the z15 server, the FIXCAT for z15 required service is: IBM.Device.Server.z15-8561.RequiredService.

Though it is more time-consuming and error-prone than using REPORT MISSINGFIX with the appropriate fix categories, you can use the Preventive Service Planning (PSP) bucket to obtain the list of required PTFs for the z15 server. PSP buckets are identified by an Upgrade name and one or more Subset names. For the IBM z15, the PSP Upgrade name is 8561DEVICE, and the z/OS support can be found in Subset 8561/ZOS.

Exploitation of some functions requires a web deliverable. Specifically:

  • Exploitation of Crypto Express7S requires the Cryptographic Support for z/OS V2R2 - z/OS V2R4 (FMID HCR77D1) web deliverable.

    If you are using this web deliverable and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs identified by the following fix category: IBM.Coexistence.ICSF.z/OS_V2R2-V2R4-HCR77D1

  • If you are running z/OS V2R1 and require Crypto Express6S exploitation support for the next Generation Coprocessor support or VISA Format Preserving Encryption (FPE), you must download and install the Enhanced Cryptographic Support for z/OS V2R1-z/OS V2R3 web deliverable (FMID HCR77C0) or the Cryptographic Support for z/OS V2R1 - z/OS V2R3 web deliverable (HCR77C1).

    If you are using either of these web deliverables (HCR77C0 or HCR77C1) and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs identified by the appropriate fix category: IBM.Coexistence.ICSF.z/OS_V2R1-z/OS_V2R3-HCR77C0 or IBM.Coexistence.ICSF.z/OS_V2R1-z/OS_V2R3-HCR77C1.

  • If you are running z/OS V2R1 and require Crypto Express5S exploitation support for the next Generation Coprocessor support or VISA Format Preserving Encryption (FPE), you must download and install the Enhanced Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77B0) or the Cryptographic Support for z/OS V1R13 - z/OS V2R2 web deliverable (HCR77B1).

    If you are using either of these web deliverables (HCR77B0 or HCR77B1) and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs identified by the appropriate fix category: IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77B0 or IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77B1.

  • To run z/OS V2R1 on a z15™ server, you require IBM Software Support Services for extended z/OS V2R1 support.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.1.3 : Larger coupling facility structure sizes might be necessary


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

When you change the coupling facility control code level (CFLEVEL), your coupling facility structure sizes might change.

If, as part of your upgrade to a z15™ server, you change the CFLEVEL, you might have larger structure sizes than you did previously. If your CFLEVEL is identical, structure sizes are not expected to change when you upgrade from a previous server to a newer generation server.

In addition, similar to CFLEVEL 17 and later, ensure that the CF LPAR has at least 512MB of storage. CFLEVEL 24, introduced on the z15, 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). This support removes inhibitors to using large CF cache structures, enabling use of Large Memory to scale to larger DB2 Local Buffer Pools (LBP) and Group Buffer Pools (GBP) in data sharing environments.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.1.4 : Use the same software level throughout a sysplex


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Having members of a sysplex at the same software level (other than during brief upgrade periods) is good software management policy.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.1.5 : Migrate hardware and software at different times


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

To minimize the amount of change that you experience at one time, do not upgrade your software release level at the same time that you upgrade your hardware.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.1.6 : Use the latest version of SCRT


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

As of z/OS V2R3, you do not need to update SCRT because it is included in the z/OS base. If you are running an earlier release of z/OS, and you use SCRT, make sure that SCRT is at the latest level. This is a requirement for sub-capacity pricing.

The latest level of SCRT for releases prior to z/OS V2R3 can be downloaded from the SCRT web site at IBM Z software pricing - Licensing - Sub-capacity licensing.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.2 : Restrictions for a z15 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

For a description of each restriction, perform the steps that follow.


Step 3.2.1.2.1 : Functional limitations


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Not all z15™ functions are available in every z/OS release.

In the step "Upgrade to an IBM z15 server," see the following:

  • Table 1 shows a summary view of which z15 server functions are included in the base support for z/OS V2R2, z/OS V2R3, and z/OS V2R4.
  • Table 2 shows a summary view of which z15 functions are available for exploitation in each z/OS release.

Some functions have upgrade or exploitation considerations. In this workflow, see the steps "Actions you can take before you order an IBM z15 server" and "Actions you can take after installing an IBM z15 server" for the applicable upgrade actions.

Many functions are enabled or disabled, based on the presence or absence of the required hardware and software. If you plan to use new z15 functions, you can install the software and hardware in either order. That is, there is no requirement to install either software or hardware first to use a specific function. However, because of outage windows and testing considerations, you might want to consider installing all the software and PTFs required for the machine and the functions you plan to use first. Then, upgrade the hardware and, finally, update your customization to use the new functions.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.2.2 : z15 servers in a sysplex


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Be aware of the following considerations:

  • A Parallel Sysplex® that contains a z15™ server either for a z/OS image or a coupling facility (CF) image can contain only other z15 servers, or z14, z14 ZR1, z13, or z13s servers.
  • The z15 requires ICA-SR and CE-LR fanouts. The older HCA3-O or the HCA3-O LR coupling fanouts are not supported on the z15 server.
  • Systems such as the z14, z14 ZR1, z13, or z13s can connect to the z15 by using the Integrated Coupling Adapter Short Reach (ICA SR) and the Coupling Express Long Reach (CE LR) coupling links. Earlier systems, such as the zEC12 and zBC12, do not support ICA SR or CE LR, and therefore cannot have coupling link connectivity to the z15 server.
  • If you are running z/OS on any servers earlier than a z13 or z13s, you cannot add a z15 to that sysplex; that is, you will not be able to perform rolling IPLs to introduce a z15 server if you have any of the earlier servers as z/OS images or coupling facility images in the sysplex.
  • The earlier servers in the sysplex must be upgraded to z13 or z13s or later to have z15™ servers supported in the sysplex. If you have any z/OS images or coupling facility images on an earlier server, and you intend to introduce a z15 server into that sysplex, you must move those images to a z13 or z13s or later server before introducing the z15 server.
  • GRS supports the use of FICON CTCs for Ring configurations. However, if you are currently using ESCON CTCs for GRS ring configurations within a sysplex, consider converting to GRS Star if possible, or using XCF signaling in a GRS ring configuration. XCF sysplex signaling is preferred instead of GRS CTC connections.
  • IBM Z® servers that require time synchronization (for example, to support a base or Parallel Sysplex) must be configured in Server Time Protocol (STP) mode. STP is designed to allow multiple servers and coupling facilities to maintain time synchronization with each other, in a coordinated timing network (CTN). STP is a hardware feature of the z15, z14, z14 ZR1, z13, z13s, zEC12, and zBC12. The most recent servers (z15, z14, z14 ZR1, z13, and z13s) can participate only in an STP-only CTN.
  • Starting with IBM z15, the IBM Z Hardware Management Appliance (FC #0100) can be ordered to provide HMC/SE functions within the CPC frame, eliminating the need for separate HMCs outside of the frame.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.2.3 : HCD and HCM support for the z15


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

As with previous servers, hardware can be defined on any supported OS version and server. However, dynamic activation of new server and new adapter types can be done only on z15™ and future high-end IBM Z® servers. Dynamic activation is supported on z/OS V2R1 and later releases.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.2.4 : Plan for discontinued functions


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

For a list of functions on the z15™ that are planned to be discontinued on future servers, see the step "Accommodate functions for the z15 to be discontinued on future servers" in this workflow.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.2.5 : Unsupported hardware features


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The following hardware features are not supported on the z15™ server. They cannot be ordered on the z15 and cannot be carried forward from an upgrade on an earlier server to the z15.

  • Host Channel Adapter (HCA) for InfiniBand is no longer supported, including the following features:
    • HCA2-O and HCA2-O LR features
    • HCA3-O and HCA3-O LR features

    Enterprises must upgrade from HCA channels to one of the following coupling links:

    • For high-speed short-range coupling connectivity, the IBM Integrated Coupling Adapter (ICA SR) is a two-port, short-distance coupling fanout that uses a new coupling channel type: CS5. The ICA SR can only be used for coupling connectivity between z15, z14, z14 ZR1, z13, and z13s servers. The ICA SR fanout requires new cabling, and can connect only to another ICA SR.
    • For long-range coupling connectivity, the Coupling Express® Long Reach (CE LR) is a two-port, long-distance coupling adapter that uses a new coupling channel type: CL5. The CE LR can be used only for coupling connectivity between z15, z14, z14 ZR1, z13, and z13s servers.

    The suggested practice is to order ICA SR (#0172) or CE LR (#0433) on the z15™ servers that are used in a Parallel Sysplex to help ensure coupling compatibility with future server generations.

  • CHPID type OSN (OSA-Express for NCP) is not supported on the OSA-Express5S GbE LX feature
  • OSA-Express4S features
  • Crypto Express3 and Crypto Express4S
  • InterSystem Channel-3 (ISC-3) coupling links feature
  • FICON Express4
  • zEDC Express (FC #0420). In the z15, the compression functions are moved into the processor chip, which is referred to as IBM Integrated Accelerator for z Enterprise Data Compression (zEDC). As an integrated part of the z15™ processor chip, the Integrated Accelerator for zEDC does not require the purchase of a hardware feature or usage of I/O slots.
  • IBM Flash Express (features #0402 and #0403), which is replaced by IBM Virtual Flash Memory (VFM), starting with the z14. VFM implements Extended Asynchronous Data Mover (EADM) Architecture that uses HSA-like memory instead of Flash card pairs. No application changes are required to change from IBM Flash Express to VFM.
  • As of HMC version 2.15.0, new builds of the Hardware Master Console (HMC) and the Support Element (SE) no longer include a CD/DVD drive as part the HMC server hardware. Instead, the HMC provides two options for installing functional updates: USB media and electronic delivery. These solutions are available for:
    • Firmware for the HMC or Support Element
    • eBusiness on Demand (eBoD) records, such as On/Off Capacity on Demand (On/Off CoD)
    • Operating system code, as used for Load from Removable Media or the Server task.

    If you select to use USB media, the appropriate USB Flash Memory Drive Media is provided with the particular feature, using either of the following feature codes:

    • Feature code 0843: USB Load media that can be used for IBM Z operating system code
    • Feature code 0848: USB Backup media that can be used for an HMC or SE Critical Data Backup task.

    If USB media is not acceptable for your environment, choose electronic delivery instead. Order feature code 0846 (No Physical Media Option) and follow the instructions on how to electronically deliver the required content over the network by using any of the following options:

    • Z Remote Support Facility (zRSF)
    • IBM Resource Link
    • FTP/SFTP/FTPS Server connections from the HMC.

    For an electronic only delivery environment, two HMCs are required on every unique network subnet on which an HMC, SE, or TKE workstation is connected.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.2.6 : Carry forward hardware features


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The following hardware features are not orderable on z15™ servers. If they are installed on your existing server at the time of an upgrade to a z15 server, they can be retained or carried forward.

  • TKE with/4768 #0080 or #0081
  • TKE workstation #0085 and #0086
  • HMC #0082, #0083, #0095, #0096
  • HMC Rack KMM #0154
  • TKE Rack Keyboard/Monitor/Mouse #0156
  • Internal Coupling Adapter Short Reach (ICA SR) #0172
  • Fanout Airflow PCIe #0174
  • FICON Express8S 10KM LX #0409
  • FICON Express8S SX #0410
  • 10 GbE RoCE Express #0411
  • 10 GbE RoCE Express #0412
  • OSA-Express5S GbE LX #0413
  • OSA-Express5S GbE SX #0414
  • OSA-Express5S 10 GbE LR #0415
  • OSA-Express5S 10 GbE SR #0416
  • OSA-Express5S 1000BASE-T #0417
  • FICON Express16S LX #0418
  • FICON Express16S SX #0419
  • OSA-Express6S GbE LX #0422
  • OSA-Express6S GbE SX #0423
  • OSA-Express6S 10 GbE LR #0424
  • OSA-Express6S 10 GbE SR #0425
  • OSA-Express6S 1000BASE-T #0426
  • FICON Express16S+ LX #0427
  • FICON Express16S+ SX #0428
  • OSA-Express7S 25 GbE SR #0429
  • 25 GbE RoCE Express2 #0430
  • zHyperLink Express #0431
  • Coupling Express LR #0433
  • Addl smart cards #0884
  • TKE Smart Card Reader #0885
  • Crypto Express5S #0890
  • TKE Smart Card Reader #0891
  • NXP Smart Card w/FIPS #0892
  • Crypto Express6S #0893
  • 512 GB MEM DIMM(5/FEAT) #1631.

For information about supported storage controllers, see the step "Ensure that you are using supported servers, storage controllers, and machine facilities" in the z/OS V2R4 Upgrade Workflow.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3 : Actions you can take before you order an IBM z15 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

These are the upgrade actions that you perform on your current system, either because they require the current system or because they are possible on the current system. You do not need the z15™ server to make these changes, and the changes do not require the z15™ server once they are made. For example, discontinuing use of hardware that is no longer supported.


Step 3.2.1.3.1 : Review the Large Systems Performance Reference (LSPR)


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

LSPR is designed to provide comprehensive z/Architecture® processor capacity ratios for different configurations of central processors (CPs) across a wide variety of system control programs and workload environments.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.2 : Review the sysplex configuration in which the z15 server will participate


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

For the limitations to observe when you are using the z15™ server with earlier servers in a Parallel Sysplex, see the step "Restrictions for a z15 server" (and its substeps) in this workflow.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.3 : Implement an STP timing network


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

You must use an STP timing network. This action is needed because Sysplex Timers (9037-002) are not supported on z15™ servers.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.4 : Upgrade from unsupported hardware features to newer technology


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

This action is needed because specific features are not available on the z15™ server. For example, OSA-Express4 is not supported on the z15.

In this workflow, see the following step:

  • "Restrictions for a z15 server"

In the z/OS V2R4 Upgrade Workflow, see the following steps:

  • "Replace unsupported devices"
  • "Provide for new device installations"

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.5 : Determine the level of cryptographic support you require on a z15 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The level of function that is provided for cryptographic support differs by z/OS release and the installed ICSF web deliverable. Also, toleration PTFs are available for some cryptographic web deliverables

For z/OS V2R4, consider the following:

  • If you are using the level of ICSF that is shipped as part of z/OS V2R4 (FMID HCR77D0), you can use most functions of the Crypto Express7S feature on a z15™ server.
  • ICSF Web Deliverable HCR77D1 - Cryptographic Support for z/OS V2R2 – z/OS V2R4 (FMID HCR77D1) provides some additional function and also incorporates enhancements that are available in PTFs for the base level of ICSF included in z/OS V2R4. This web deliverable includes support for:
    • Crypto Express7S adapter
    • Ability to use CP Assist for Cryptographic Functions (CPACF) for certain clear key ECC operations
    • CCA Release 5.5 and CCA Release 6.3
    • Coupling Facility Level (CFLEVEL) 24
    • Integrated Accelerator for z Enterprise Data Compression
    • System Recovery Boost
    • IBM Data Privacy Passports
    • IBM Data Privacy for Diagnostics.

    If you are using this web deliverable and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs that are identified by SMP/E fix category IBM.Coexistence.ICSF.z/OS_V2R2-V2R4-HCR77D1.

  • If you require support for more than 16 domains on Crypto Express7S, you must install the PTFs that are identified by the SMP/E fix category for the z15™ server: IBM.Device.Server.z15-8561.Exploitation.

For z/OS V2R3, consider the following:

  • If you are using the level of ICSF that is shipped as part of z/OS V2R3 (FMID HCR77C0), you can use most functions of the Crypto Express6S feature on a z15™ server.
  • ICSF Web Deliverable HCR77D1 - Cryptographic Support for z/OS V2R2 – z/OS V2R4 (FMID HCR77D1) provides additional function and enhancements. If you are using this web deliverable and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs that are identified by SMP/E fix category IBM.Coexistence.ICSF.z/OS_V2R2-V2R4-HCR77D1.
  • ICSF Web Deliverable HCR77C1 - Cryptographic Support for z/OS V2R1 - z/OS V2R3 provides some additional function and also incorporates enhancements that are available in PTFs for the base level of ICSF included in z/OS V2R3. The web deliverable includes support for a PCI HSM (“ Payment Card Industry Hardware Security Module”) configured CCA coprocessor. Crypto Express6S also introduces the use of X.509 certificates in CCA. If you are using this web deliverable and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs that are identified by SMP/E fix category IBM.Coexistence.ICSF.z/OS_V2R1-V2R3-HCR77C1

For z/OS V2R2, consider the following:

  • If you are using the level of ICSF that is shipped as part of z/OS V2R2 (FMID HCR77B0), you can use most functions of the Crypto Express6S feature on a z15™ server.
  • ICSF Web Deliverable HCR77D1 - Cryptographic Support for z/OS V2R2 – z/OS V2R4 (FMID HCR77D1) provides additional function and enhancements. If you are using this web deliverable and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs that are identified by SMP/E fix category IBM.Coexistence.ICSF.z/OS_V2R2-V2R4-HCR77D1.
  • ICSF Web Deliverable HCR77C1 - Cryptographic Support for z/OS V2R1 – z/OS V2R3 provides some additional function and also incorporates enhancements that are available in PTFs for the base level of ICSF included in z/OS V2R2. The web deliverable includes support for a PCI HSM (“ Payment Card Industry Hardware Security Module”) configured CCA coprocessor. Crypto Express6S also introduces the use of X.509 certificates in CCA.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.6 : Ensure that enough real memory is installed


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

For z/OS V2R4 with the IBM z15 (z15) server, a minimum of 8 GB of real memory is required to IPL. When running as a z/VM guest or on an IBM Z® Personal Development Tool (zPDT), a minimum of 2 GB is required for z/OS V2R4.

If you attempt to IPL z/OS V2R4 on a z15 with less than the minimum amount of real memory, z/OS issues the following warning message (a WTOR) during IPL:

IAR057D LESS THAN 8 GB OF REAL STORAGE IMPACTS SYSTEM AVAILABILITY - ADD STORAGE OR REPLY C TO CONTINUE

Continuing with less than the minimum amount of real memory might impact the availability of your system. If you attempt to IPL z/OS V2R4 on an earlier IBM server, no warning message is issued.

To help you with upgrading from z/OS V2R2, IBM provides a new health check, IBMRSM,ZOSMIGV2R3_RSM_MINIMUM_REAL, which issues a warning for a system that is configured with less than 8 GB of real memory.

Steps to take

For a z/OS V2R4 system that you plan to run on a z15 server, follow these steps:

  • For a system that is running as a z/VM guest, ensure that the server has a minimum of 2 GB of real memory.
  • For a system that is running on IBM Z® Personal Development Tool (zPDT), ensure that the server has a minimum of 2 GB of real memory.
  • Otherwise, ensure that the LPAR has a minimum of 8 GB of real memory.
Reference information

For more information about the minimum real memory requirement, see z/OS Planning for Installation.

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMRSM,ZOSMIGV2R3_RSM_MINIMUM_REAL.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".

This check is available on the following releases: z/OS V2R2 and z/OS V2R3.

NOTE: The successful running of this IBM Health Checker for z/OS check only partially covers this upgrade action. Refer to the upgrade action text for the complete list of steps to take.


Step 3.2.1.3.7 : Install the necessary z/OS service


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

IBM recommends that you use the SMP/E REPORT MISSINGFIX command to identify PTFs for the z15™ server that you do not already have installed. The simplest way to do that is to specify IBM.Device.Server.* and IBM.Function.* as the fix categories for the REPORT MISSINGFIX command. Doing so identifies not only z15™ support PTFs, but also the PTFs for prior generations of IBM servers that you might need, and those required to enable various functions. Also, REPORT MISSINGFIX creates a batch job for the SMP/E RECEIVE ORDER command that you can use to get any PTFs you do not already have. SMP/E also provides an Explorer function that you can use to find new fix categories that might be of interest. For a description of all the fix categories, see the Values and Descriptions page at IBM Fix Category Values and Descriptions. For more information about the REPORT MISSINGFIX command, see z/OS SMP/E Commands.

Here is an example of the SMP/E control statements you can use for REPORT MISSINGFIX:

SET BDY(GLOBAL). REPORT MISSINGFIX ZONES( target zone) FIXCAT(IBM.Device.Server.**, IBM.Function.*)

If you want to use specific fix categories, you can specify the following fix categories either individually or together for the z/OS PTFs that are required to use a z15™ server, exploit its functions and features, and those that IBM recommends that you install if you are using a z15™ server. Also needed are the fix categories for intermediate servers.

  • For the IBM z15:
    • IBM.Device.Server.z15-8561.RequiredService
    • IBM.Device.Server.z15-8561.Exploitation
    • IBM.Device.Server.z15-8561.RecommendedService

If you are exploiting z15™ capabilities by installing a web deliverable, more PTFs might be required. Follow the instructions in the Program Directory that is associated with each web deliverable to identify the required PTFs.

If you choose not to use SMP/E FIXCAT IBM.Device.Server.z15-8561.RecommendedService, another way to find the recommended list of PTFs is to use the Preventive Service Planning (PSP) “buckets” for the applicable hardware and software. However, note that using PSP buckets and checking the status of the PTFs listed in them is more time-consuming and potentially error-prone than using REPORT MISSINGFIX with the appropriate fix category. For the IBM z15, the PSP Upgrade name is 8561DEVICE, and the z/OS support can be found in Subset 8561/ZOS.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.8 : Run the CFSIZER tool


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

If you are moving your coupling facilities, and the coupling facility structures are on a higher CFLEVEL than they were previously, run the Coupling Facility Structure Sizer (CFSIZER) tool to find out whether you must increase coupling facility structure sizes. Prepare to make the necessary changes to the CFLEVEL as indicated by the tool.

You can download the CFSIZER tool at: Coupling Facility sizer.

Also, see the following step in the z/OS V2R4 Upgrade Workflow:

  • "Update your CFRM policy with coupling facility structure size changes"

Note: After you make a coupling facility available on the new hardware, you can run the Sizer utility, which is an authorized z/OS program that you can use 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 CFSizer Alternate Sizing Techniques.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.9 : Prepare for the new machine instruction mnemonics


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The instruction set has been expanded on the z15™ server, as is usual for new servers. Each machine instruction is represented by a mnemonic in Assembler language. It is possible that the new mnemonics can match names that you chose for Assembler macro instructions. If such naming collisions occur, the Assembler default opcode table (UNI) processes new mnemonics as instructions, not as macros, after z15™ required service is installed. If this occurs, it is likely to cause Assembler error messages and can cause incorrect object code to be generated. If you write programs in Assembler Language, compare the names of your existing Assembler macro instructions to the new machine instructions, to identify any such conflicts or collisions that would occur. The Assembler macro instructions are documented in z/Architecture Principles of Operation. For information about a tool to help in identifying mnemonic conflicts, see the IBM Techdocs web site under Presentations and Tools. Search for the Techdoc PRS5289.

If a conflict is identified, take one of these actions:

  • Change the name of your macro instruction.
  • Specify PARM='...OPTABLE(YOP)...' (or some other earlier opcode table).
  • Specify a separate ASMAOPT file containing assembler options such as in the previous method (this method requires no changes to source code or JCL).
  • Add as the first statement of your source program: *PROCESS OPTABLE(YOP) (or some other earlier opcode table).
  • Specify the PROFILE option either in JCL or the ASMAOPT file, and the specified or default member of the SYSLIB data set is copied into the front of the source program.
  • If you must use both a new instruction and a macro with the same name in an assembly, use a coding technique that allows the use of a new instruction and a macro with the same name in an assembly, such as HLASM mnemonic tags ( :MAC:ASM).

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.10 : Learn about the HiperDispatch enhancement


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

In HiperDispatch processing, changes in LPAR weight can cause I/O enabled vertical-high (Vh) and vertical-medium (Vm) processors to be converted to vertical-low (Vl) processors, and immediately parked by HiperDispatch. That is, the Vh and Vm processors can be pushed to the lowest configured online processors.

Starting with z/OS V2R4, the system resources manager (SRM) component of z/OS reverses the search direction that is used to find processors for I/O enablement. SRM enables processors for I/O interrupts from the lowest configured CPU ID to the highest configured CPU ID. This enhancement keeps Vh or Vm processors enabled for I/O interrupts after processor topology changes.

The HiperDispatch enhancement is included in the z/OS V2R4 base. It can be added to z/OS V2R2 and z/OS V2R3 by installing the PTF for APAR OA55935. It is identified by SMP/E fix category IBM.Device.Server.z15-8561.Exploitation.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.11 : Learn about the z/OS SLIP enhancements


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The z/OS SLIP command is enhanced to monitor an address or range of addresses for a key change and in response take a memory dump or set a trace. This behavior is supported in z/OS V2R4 running on the z15. No toleration support is required on earlier releases.

To enable the SLIP function, enter the SLIP command with new options, as follows:

SLIP SET[,options],END

To disable the SLIP function, enter the SLIP command with new options, as follows:

SLIP DEL[,options]

For more information, see SLIP command in z/OS MVS System Commands.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.12 : Accommodate the changes to default ARCH and TUNE level


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The z15™ supports the new levels ARCH(13) and TUNE(13), which are needed to take advantage of most of the enhanced vector instructions available on the z15™ in z/Architecture mode. ARCH(13) produces code that uses instructions that are available on the z15, such as the following:

  • Vector Enhancement Facility 2
  • Miscellaneous-Instruction-Extension Facility 3
  • Aligned Vector Load/Store Hint instructions
  • Limited exploitation of Vector Packed Decimal Enhancement Facility.

Application developers can recompile their applications with the ARCH 13 compiler option to instruct the compiler to generate code that uses the instructions available on the z15. This action can bring performance improvements for applications without requiring any changes to source code.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.13 : Upgrade actions for IBM Integrated Accelerator for z Enterprise Data Compression (zEDC)


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

In the z15, the compression functions are moved into the processor chip, which is referred to as IBM Integrated Accelerator for z Enterprise Data Compression (zEDC). IBM Integrated Accelerator for zEDC replaces zEDC Express (FC #0420). IBM Integrated Accelerator for zEDC uses industry standard compression formats for file compression that can enable reduction in the size of data, which can save storage space and increase data transfer rates. The z/OS APIs, both authorized and zlib, transparently enable all existing software exploitation on z15, which was already enabled on z14 and earlier with zEDC Express. Support is available on z/OS V2R1, z/OS V2R2, z/OS V2R3, and z/OS V2R4 when running on z15.

No toleration support is required.

Data that is compressed with zEDC Express can be decompressed with IBM Integrated Accelerator for zEDC. The software inflate routine is updated to be RFC-compliant. This change allows for fallback so that IBM Integrated Accelerator for zEDC compressed data can be decompressed on z14 and earlier servers.

As with zEDC Express, IBM Integrated Accelerator for zEDC compression supports two types of processing:

  • Synchronous processing in problem state, which is requested through the zlib data compression library services
  • Asynchronous processing in authorized state, which is requested through the IBM Z authorized compression services.

As was done previously for zEDC, parmlib member IFAPRDxx is used to enable compression. However, with IBM Integrated Accelerator for zEDC compression on the z15, you use IFAPRDxx only for enabling asynchronous processing. It is not required for zlib-based (problem state) uses.

The following example shows a typical IFAPRDxx entry for IBM Integrated Accelerator for zEDC compression, which uses the same format as the zEDC Express. If your IFAPRDxx member already contains this entry, you can retain it on the z15.

PRODUCT OWNER('IBM CORP') NAME('Z/OS') FEATURENAME('ZEDC') ID(5650-ZOS) VERSION(*) RELEASE(*) MOD(*) STATE(ENABLED)

Before upgrading to the z15, you must install z/OS zlib PTFs for this support, which are identified by SMP/E fix category IBM.Device.Server.z15-8561.RequiredService. Also, you must apply the PTF for APAR OA56143. Then, relink your applications with the updated zlib data compression library. If the PTFs are not installed, z/OS attempts to find a zEDC device, which is not supported on the z15. If so, no compression or decompression can occur.

The IBM Z Batch Network Analyzer (zBNA) tool is updated to provide usage estimation for IBM Integrated Accelerator for zEDC compression.

In the future, after you have upgraded all servers to the z15™ level (including servers that are used for disaster recovery), and you have installed the related PTFs on all of your z/OS systems, you might have the following clean-up actions to perform:

  • In parmlib member IQPPRMxx, the MAXSEGMENTS option is obsolete and therefore ignored. Also, the defaults for DEFMINREQSIZE and INFMINREQSIZE are changed and those values can no longer be updated through parmlib. You can remove these settings from your IQPPRMxx parmlib member.
  • Applications that use zlib no longer require READ access to SAF resource FPZ.ACCELERATOR.COMPRESSION in the FACILITY CLASS. You can remove these application authorizations from your external security manager, such as RACF

Reference information

For more information, see Integrated Accelerator for zEnterprise Data Compression (zEDC) content solution.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.3.14 : Upgrade the I/O Configuration Program (IOCP) for z15


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

It is possible carry forward an IOCDS from a z13 or z14, if no new functions are required from the z15. However, to use the new I/O hardware that is available only on the z15, you must apply the required PTFs, which are identified by SMP/E fix category IBM.Device.Server.z15-8561.RequiredService. Also, you must apply the PTF for APAR OA56761.

Note that the z15™ I/O hardware includes:

  • Increased coupling CHPIDs per CEC from 256 to 384
  • Support for increased ICA-SR to 96 and ICP to 64.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.4 : Actions you can take after installing an IBM z15 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

These are upgrade actions that you perform only after you have installed the z15™ server. You need a running z15™ server to perform these actions.

For information about PTFs, see the table notes in the the workflow step called "Upgrade to an IBM z15 server."


Step 3.2.1.4.1 : FICON Express16SA


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

FICON Express16SA supports a link data rate of 16 gigabits per second (Gbps) and auto-negotiation to 8 Gbps for synergy with current generation switches, directors, and storage devices. With support for native FICON, High Performance FICON for z Systems (zHPF), and Fibre Channel Protocol (FCP), the IBM z15™ server is designed to help you to prepare for an end-to-end 16 Gbps infrastructure to meet the lower latency and increased bandwidth demands of your applications.

The FICON Express16SA adapter will work with your existing fiber optic cabling environment, both single mode and multimode optical cables.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.4.2 : Upgrade to Virtual Flash Memory (VFM)


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

IBM Virtual Flash Memory (VFM) is the replacement for the Flash Express features (#0402, #0403) which were available on the IBM zEC12 and IBM z13. No application changes are required to change from IBM Flash Express to VFM.

Ensure that you replace your Flash memory with adequate VFM.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.4.3 : Upgrade actions for Hardware Instrumentation Services (HIS)


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

New extended and crypto counters and diagnostic samples are added for the z15. If you want to enable them, you must have Hardware Instrumentation Services (HIS) set up on z/OS.

To start or stop collecting extended or crypto counters or diagnostic sampling, enter the command MODIFY HIS.

No toleration support is needed.

If you want to ignore the HIS enhancements, you might need to update your HIS profilers. For more information, see the topic about starting, configuring, and stopping hardware event data collection. in z/OS MVS System Commands.

Note: If you use the CPU Measurement Facility, IBM recommends that your installation collect SMF 113 subtype 1 and 2 records. IBM also recommends that products process SMF 113 subtype 1 records when available because that is where future enhancements are made. If subtype 1 records are not available, products can process subtype 2 records.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.4.4 : Learn about System Recovery Boost


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

New for the z15, this enhancement can provide faster operating system IPL, middleware and workload restart and recovery, and planned shutdown. During "boost periods" that apply during operating system shutdown and following a reIPL or restart, the IBM z15™ can make additional processing capacity available to the system in a variety of ways to help accelerate processing, and apply that same boosted capacity to improve workload throughput and response time and elapsed time during the boost. Enhancements in Geographically Dispersed Parallel Sysplex (GDPS) automation are also designed to provide faster, more efficient, and more highly-parallel orchestration of GDPS automated reconfiguration activities, such as activating or deactivating images, IPLing images, and so on.

During a boost period, System Recovery Boost works by providing additional processor capacity and parallelism, using your installation's already-entitled CPUs and zIIPs. System Recovery Boost does this without increasing the four-hour rolling average (4HRA) software billing cost or MSU consumption associated with your workload during this time.

For more information about System Recovery Boost, see the following books:

  • IBM z15 Technical Introduction, SG24-8850
  • IBM Z Capacity on Demand User's Guide, SC28-6985-03

These books are included in the IBM z15 Library, which is available online in Resource Link™.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.4.5 : Grant cross-partition authority to the support element


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

For Support Elements that run on the z15, the setting for the “Cross Partition Authority” option is replaced by new security settings on the System Details panel and the Customize Image Profiles panel.

For more information, see the workflow step "Enable BCPii communications on the support element."

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.4.6 : Learn about IBM Integrated Accelerator for z Enterprise Data Compression (zEDC)


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Beginning with the z15, IBM Integrated Accelerator for z Enterprise Data Compression (zEDC) replaces the zEDC Express (FC #0420). As an integrated part of the z15™ processor chip, the Integrated Accelerator for zEDC does not require the purchase of a hardware feature or usage of I/O slots.

No change is required when z/OS is upgraded from a z14 to a z15.

Observe the following differences in processing:

  • RMF changes:
    • On earlier IBM Z servers, you used the RMF PCIE report to monitor the usage of zEDC devices. Starting with the z15, you can now monitor compression activity by referring to the I/O Queuing Activity report and the Extended Asynchronous Data Mover (EADM) device summary instead. RMF EADM reporting (RMF 74.10) is enhanced with asynchronous execution information.
    • On the z15, the RMF PCIE report no longer contains any information about compression.
  • Synchronous mode compression is not recorded; it is treated as an instruction invocation.
  • Asynchronous mode compression is recorded, as follows:
    • SMF30 information is captured
    • In RMF, the EADM device summary provides information about compression.
    • SAP utilization is updated to include time for compression and decompression.

Reference information

For more information, see Integrated Accelerator for zEnterprise Data Compression (zEDC) content solution.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.5 : Accommodate functions for the z15 to be discontinued on future servers


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

Note:

IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

The steps in this section involve changes in hardware support that could affect your environment. Make the appropriate changes, as needed.


Step 3.2.1.5.1 : Prepaid On/Off Capacity on Demand tokens will not carry forward


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Beginning with IBM z15™, new prepaid On/Off Capacity on Demand (On/Off CoD) temporary CP resource tokens do not carry forward to future systems. On/Off CoD from IBM allows you to enable and disable hardware engines to meet temporary peak business needs. On the IBM Z platform, this hardware offering has been made available exclusively on supported IBM Z servers. Charges that are related to both hardware and software are tied to the duration of the temporary enablement and the capacity enabled.

Note: IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.5.2 : Prepare for the removal of the internal battery feature


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

IBM z15™ is planned to be the last IBM Z server to offer the Internal Battery Feature (IBF), which is an internal short term uninterruptible power supply (UPS). The IBF is available on z15 T01 servers with the Balanced Power Plan Ahead feature (FC#3003). The IBF is not available on the z15 z15 T02.

As client data centers continue to improve power stability and uninterruptible power supply (UPS) coordination, IBM Z continues to innovate to help clients take advantage of common power efficiency and monitoring across their ecosystems.

Additional support for data center power planning can berequested through your IBM Sales contact.

Note: IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.1.5.3 : Prepare for the removal of support for TLS 1.0 and TLS 1.1 for SE, HMC, and OSC


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

IBM z15™ is planned to be the last IBM Z server to to support the use of the Transport Layer Security protocol versions 1.0 (TLS 1.0) and version 1.1 (TLS 1.1) for establishing secure connections to the Support Element (SE), Hardware Management Console (HMC), and Open Systems Adapter (OSA) Integrated Console Controller (channel path type OSC).

Note: IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies.


Step 3.2.2 : Upgrade to an IBM z14 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

Description

The IBM z14™ (z14™) is designed to be the cornerstone for a trust economy. The z14 provides a scalable, highly available platform that delivers differentiated value to enable business growth, reduce cost, and protect existing investments. z/OS V2R3 enhances the role of the z14 by supporting solutions for a trusted digital economy. Capabilities that are designed to optimize high availability, performance, security, and operational flexibility can help organizations grow and secure their most critical transaction environments.

The IBM z14 family of mainframes includes the following models, which are dual frame configurations: M01, M02, M03, M04, M05. The newest addition to the IBM z14 family, the IBM z14™ Model ZR1 (z14 ZR1), is a single frame configuration. The z14 ZR1 is designed for clients who do not need the capacity of the larger M01-M05 models.

In this document, references to "z14" pertain to all models of the IBM z14, including the z14 Model ZR1, unless otherwise noted.

z/OS base support for specific z14 functions depends on the z/OS release. Table 1 lists the z14 functions and indicates whether each function is included in a specific z/OS release (Yes or No), or whether the function requires a PTF (PTF) or a web deliverable (Web). For information about finding the appropriate PTFs, see the workflow step called "Actions you can take before you order an IBM z14 server." For more information about V1R13 support, see the Table Notes.

Table 1. z14 server functions included in the base support for z/OS V2R2, z/OS V2R3, and z/OS V2R4.

z14 function included in base z/OS support (Y/N)

V2R2 4

V2R3 4

V2R4 4

Base support ¹

PTF

PTF

Yes, and in PTFs

CHPID type CS5 for coupling

Yes

Yes

Yes

CHPID type OSE supporting 4 or 2 ports per feature

Yes

Yes

Yes

CHPID type OSM for intranode management network (INMN)

Yes

Yes

Yes

CPU measurement facility

PTF

Yes

Yes

Crypto Express6S Toleration 2

One of the following:

  • z/OS V2.2 with Cryptographic Support for z/OS V1R13 - z/OS V2R2 (HCR77B1) with PTFs
  • z/OS V2.2 with Cryptographic Support for z/OS V2R1 - z/OS V2R2 (HCR77CO) with PTFs

PTF

Yes

FICON® Express8S (CHPID type FC)

Yes

Yes

Yes

FICON Express16S (CHPID type FC)

Yes

Yes

Yes

FICON Express16S+ (CHPID type FC) when using FICON or channel-to-channel (CTC) 3

  • FICON Express16S+ LX
  • FICON Express16S+ SX

PTF

PTF

Yes

IBM z BladeCenter Extension (zBX) Model 004

Yes

Yes

Yes

IBM z Unified Resource Manager

Yes

Yes

Yes

New z14 machine instruction (assembler support) 3

PTF

PTF

Yes

OSA-Express6S (CHPID type OSD) 3

  • OSA-Express6S GbE LX
  • OSA-Express6S GbE SX
  • OSA-Express6S 10 GbE LR
  • OSA-Express6S 10 GbE SR
  • OSA-Express6S 1000BASE-T

Yes

Yes

Yes

Parallel Sysplex Infiniband (PSIFB) Coupling Link 5

Yes

Yes

Yes

z/OS global resource serialization (GRS) support for FICON CTCs

Yes

Yes

Yes

Table Notes:
  1. z/OS V1R13 (compatibility only). Extended support contract for IBM Software Support Services for z/OS is required with PTFs.
  2. z/OS V1R13 with PTFs, the Enhanced Cryptographic Support for z/OS V1R13-z/OS V2R1 (HCR77B0) Web deliverable installed, and an extended support contract for IBM Software Support Services. The web deliverable is available at z/OS downloads.
  3. z/OS V1R13 with an extended support contract for IBM Software Support Services and PTFs.
  4. PTFs for base support have the following fix categories:
    • For IBM z14 models M01 through M05, use FIXCAT value IBM.Device.Server.z14-3906.RequiredService and the FIXCATs for earlier processors.
    • For IBM z14 Model ZR1, use FIXCAT value IBM.Device.Server.z14ZR1-3907.RequiredService and the FIXCATs for earlier processors.
  5. InfiniBand coupling links are not supported on the z14 Model ZR1.

The exploitation of specific z14 server functions depends on the z/OS release. Table 2 shows a summary view of which z14 server functions can be exploited in z/OS V2R2, z/OS V2R3, and z/OS V2R4. The table lists z14 functions and indicates whether each function is exploited by a specific z/OS release (Yes or No), or whether the function requires a PTF (PTF) or a web deliverable (Web). For information about finding the appropriate PTFs, see the workflow step called "Actions you can take before you order an IBM z14 server." For more information about V1R13 support, see the Table Notes.

Table 2. Exploitation of z14 server functions supported by z/OS V2R2, z/OS V2R3, and z/OS V2R4.

z14 function included in base z/OS support (Y/N)

V2R2 ²

V2R3 ²

V2R4²

Processors: The maximum number of processors that can be configured per server.

For IBM z14 models M01 through M05:

  • Up to 170 processors configurable as CPs, zIIPs, IFLs, ICFs, or optional SAPs.
  • The sum of CPs and zIIPs configured in a single z/OS LPAR cannot exceed:
    • 170 on z/OS V2R1 or later in non-SMT mode
    • 128 on z/OS V2R1 or later in SMT mode.

For IBM z14 Model ZR1:

  • Up to 30 processors configurable as CPs, zIIPs, IFLs, ICFs, or optional SAPs.
  • The sum of CPs and zIIPs configured in a single z/OS LPAR cannot exceed 30 on z/OS V2R1 or later (in either SMT or non-SMT mode).

Yes

Yes

Yes

Two-way simultaneous multithreading (SMT)

Yes

Yes

Yes

Channel subsystems.

The maximum number of channel subsystems (CSS) that can be configured per server:

  • For IBM z14 models M01 through M05:
    • Up to six channel subsystems
    • Up to four subchannel sets per CSS.
  • For IBM z14 Model ZR1:
    • Up to three channel subsystems
    • Up to three subchannel sets per CSS.

Yes

Yes

Yes

Up to 4 TB of Redundant Array of Independent Memory (RAIM) per z/OS LPAR with z/OS V2.1 or later.

Yes

Yes

Yes

Transactional memory

Yes

Yes

Yes

2 GB Large Pages

Yes

Yes

Yes

Logical partitions.

The maximum number of logical partitions (LPARs) that can be configured per server:

  • For IBM z14 models M01 through M05, up to 85 LPARs can be configured.
  • For IBM z14 Model ZR1, up to 40 LPARs can be configured.

Yes

Yes

Yes

Coupling Facility Control Code Level 22 (CFLEVEL 22)

PTF

Yes 3

Yes

Coupling Express LR (CHPID type CL5)

PTF

Yes

Yes

Support for 256 Coupling CHPIDs

Yes

Yes

Yes

Support of High Performance FICON (zHPF) single-track or multitrack operations (CHPID type FC)

PTF

Yes

Yes

IBM Integrated Coupling Adapter Fanout (ICA SR) (CHPID type CS5)

Yes

Yes

Yes

CHPID type OSX for access control to the intra-ensemble data network (IEDN) from IBM z14 to Unified Resource Manager functions

Yes

Yes

Yes

CHPID type OSC supporting TN3270E and non-SNA DFT

Yes

Yes

Yes

OSA-Express6S (CHPID type OSD) without maximum port exploitation

Yes

Yes

Yes

OSA-Express6S IWQ IPSec

PTF

PTF

Yes

CHPID type OSD with exploitation of two ports per CHPID

Yes

Yes

Yes

Inbound workload queuing for Enterprise Extender (CHPID type OSD)

Yes

Yes

Yes

Checksum offload for IPv6 packets (CHPID type OSD)

Yes

Yes

Yes

Checksum offload for LPAR-to-LPAR traffic for IPv4 and IPv6 packets (CHPID type OSD)

Yes

Yes

Yes

Large Send for IPv6 packets (CHPID type OSD)

Yes

Yes

Yes

Crypto Express6S support of VISA Format Preserving Encryption (VFPE)

Yes

Yes

Yes

Crypto Express6S support of greater than 16 Domains

Yes

Yes

Yes

Crypto Express6S Exploitation

Web: Cryptographic Support for z/OS V2R1 - z/OS V2R3 (HCR77C1)

Web: Cryptographic Support for z/OS V2R1 - z/OS V2R3 (HCR77C1)

Web: Cryptographic Support for z/OS V2R1 - z/OS V2R3 (HCR77C1)

Crypto Express6S support of PCI-HSM compliance

Web: Cryptographic Support for z/OS V2R1 - z/OS V2R3 (HCR77C1)

Web: Cryptographic Support for z/OS V2R1 - z/OS V2R3 (HCR77C1)

Web: Cryptographic Support for z/OS V2R1 - z/OS V2R3 (HCR77C1)

10 GbE RoCE Express2 for Shared Memory Communications-Remote Direct Memory Access (SMC-R)

PTF

Yes

Yes

Single Instruction Multiple Data (SIMD) instruction set 4

Yes

Yes

Yes

IBM Virtual Flash Memory 1

Yes

Yes

Yes

zHyperLink Express

PTF

PTF

Yes

HiperDispatch enhancements

PTF

Yes

Yes

Data set encryption

PTF

Yes

Yes

Guarded Storage Facility (GSF)

PTF

Yes

Yes

IBM z/OS XL C/C++ compiler support of the ARCH(12) and TUNE(12) parameters.

No

Yes

Yes

IBM z/OS XL C/C++ runtime support of ARCH(12) and TUNE(12) parameters.

PTF 4

Yes

Yes

Instruction Execution Protection (IEP)

PTF

Yes

Yes

zEDC capability using zEDC Express®

Y (requires the z/OS zEDC software feature to be enabled)

Y (requires the z/OS zEDC software feature to be enabled)

Y (requires the z/OS zEDC software feature to be enabled)

Table Notes:
  1. z/OS V1R13 with PTFs, the z/OS V1.13 RSM Enablement Offering web deliverable installed, and an extended support contract for IBM Software Support Services. The web deliverable is available at z/OS downloads.
  2. PTFs for exploitation have the following fix categories:
    • For IBM z14 models M01 through M05, use FIXCAT value IBM.Device.Server.z14-3906.Exploitation and the FIXCATs for earlier processors.
    • For IBM z14 Model ZR1, use FIXCAT value IBM.Device.Server.z14ZR1-3907.Exploitation and the FIXCATs for earlier processors.
  3. Full support (duplexing with master/slave for CFLEVEL 22 on a z14) requires a V2R3 PTF.
  4. Running the code on z/OS V2R1 or z/OS V2R2 requires the PTF for APAR PI12281.

Web deliverables are available from the z/OS downloads page at z/OS downloads.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

  • IBM z14 models M01 through M05, which became available September, 2017.
  • IBM z14 Model ZR1, which became available May, 2018.

Applies to migration from:

z/OS V2R3 and z/OS V2R2.

Timing:

Anytime before you introduce a z14 server into your environment.

Is the upgrade action required?

Yes, if you want to run z/OS V2R4, z/OS V2R3, or z/OS V2R2 on a z14 server, or if you want to run a coupling facility on a z14 server. If you plan to run only a coupling facility on a z14 system, only the sysplex-related actions are relevant. However, you must install the appropriate z/OS service for systems that are running on other servers that use the z14 coupling facilities.

Target system hardware requirements:

  • z/OS V2R4 with IBM z14 (z14) requires a minimum of 8 GB of memory to IPL. When running as a z/VM guest or on an IBM Z® Personal Development Tool (zPDT), a minimum of 2 GB is required for z/OS V2R4. If the minimum is not met, a warning WTOR is issued at IPL.
  • A z14 with Hardware Management Console (HMC) Version 2.14.0 plus microcode change levels (MCLs) and the Support Element Version 2.14.0.
  • Additional hardware required for specific functions.
    • IBM devices that are attached to z13, z13s, zEC12, and zBC12 servers are supported for attachment to z14 channels, unless otherwise noted. The subject I/O devices must meet FICON architecture requirements.
    • IBM Virtual Flash Memory requires FC #0604
    • zEDC Express requirements:
      • IBM z14 models M01 through M05 require FC #0420.
      • IBM z14 Model ZR1 requires FC #0420 and PCIe I/O drawer (FC #4001).
    • 10 GbE RoCE Express2 requires FC #0412
    • New OSA-Express6S cards require the following feature codes:
      • OSA-Express6S GbE LX requires FC #0422
      • OSA-Express6S GbE SX requires FC #0423
      • OSA-Express6S 10 GbE LR requires FC #0424
      • OSA-Express6S 10 GbE SR requires FC #0425
      • OSA-Express6S 1000BASE-T requires FC #0426
    • New FICON Express16S cards require the following feature codes:
      • FICON Express16S+ LX requires FC #0427
      • FICON Express16S+ SX requires FC #0428
    • zHyperLink Express requires FC #0431
    • Coupling Express LR requires FC #0433
    • Crypto Express6S requires FC #0893
    • Use of hardware acceleration for cryptographic operations, including the use of Visa, Inc. Data Secure Platform (DSP) functions requires a CPACF (FC #3863) or a CEX5S (FC #0890) feature, or both.

      See Table Note 1.

    • Use of a new Trusted Key Entry (TKE) workstation requires TKE Rack Mount w/4768 (FC #0085) or TKE w/4768 (FC #0086). The TKE workstation is a combination of hardware and software, with other features required, depending on which functions you plan to use. Different feature codes are required if you are upgrading an existing TKE workstation from an earlier server.

      TKE 9.0 (FC #0879) is also required if you plan to use the TKE workstation to manage any of the following:

      • A Crypto Express6S
      • The new CCA mode PCI-HSM settings that are available on the Crypto Express6S
      • Any Crypto Express feature that is running in IBM Enterprise PKCS #11 (EP11) mode.

Target system software requirements:

See the topic Support is delivered by service, z/OS features, and web deliverables in the workflow step "General recommendations and considerations for a z14 server" and Install the necessary z/OS service, as indicated in the PSP buckets that are described in the workflow step "Actions you can take before you order an IBM z14 server."

Other system (coexistence or fallback) requirements:

  • The suggested practice is to install and run the required service on your existing server. This action enables you to fall back from a hardware perspective, yet maintain your software level.
  • If you have not installed the preconditioning and exploitation PTFs for CFLEVEL 17-21, note that those PTFs are required to be installed throughout your sysplex before implementing CFLEVEL 22. Use the appropriate fix category, as follows:
    • For IBM z14 models M01 through M05, use FIXCAT value IBM.Device.Server.z14-3906.RequiredService
    • For IBM z14 Model ZR1, use FIXCAT value IBM.Device.Server.z14ZR1-3907.RequiredService
  • If you plan to implement zEDC, you should install the z/OS toleration PTFs on systems that access data that is compressed using zEDC Express on a z14 server.
  • If you are using ICSF and plan to share keys with other z/OS systems that have an earlier level of ICSF, you should install the ICSF coexistence PTFs on those earlier levels of ICSF. For ICSF coexistence PTFs, see the workflow step called "Actions you can take before you order an IBM z14 server" for the appropriate SMP/E FIXCAT values to use.

Restrictions:

See the workflow step called "Restrictions for a z14 server."

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Table Note:
  1. IBM Z® cryptography features include VISA Format Preserving Encryption (VFPE) technology, which forms part of the Visa, Inc. Data Secure Platform (DSP). The use of VFPE technology requires a service agreement with Visa, Inc. For details, contact your Visa account manager or Visa at P2PE@visa.com. Clients who use IBM Z® cryptography features, but do not make use of the FPE functionality, are not required to enter into any such agreement with Visa.

Steps to take

Continue with the workflow steps "General recommendations and considerations for a z14 server" and "Restrictions for a z14 server," and perform the tasks that are described in the following steps:

  • "Actions you can take before you order an IBM z14 server"
  • "Actions you can take after installing an IBM z14 server"
  • "Accommodate functions for the z14 to be discontinued on future servers"

Reference information

For more information about new functions to exploit, see the IBM z14 Library.


Step 3.2.2.1 : General recommendations and considerations for a z14 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

As you plan your migration to an IBM z14™ server, consider the following items.

  1. Upgrade actions for IBM servers are cumulative. If you migrate to a z14 server from a z13™ or z13s server, and have performed the upgrade actions that are associated with the z13 or z13s, you have fewer upgrade actions than if you migrate from an earlier generation server. Thus, if you migrate from an earlier generation server, you might need to perform more upgrade actions. For example, if you migrate from a zEC12 server, you should read about and perform the z13 and z13s server upgrade actions in the workflow step called "Upgrade to an IBM z13 or IBM z13s server."
  2. Support is delivered by service, z/OS features, and web deliverables. The base support for the z14 is delivered through service (PTFs). To determine which PTFs are required, get the current enhanced HOLDDATA file, either by using the SMP/E RECEIVE ORDER command or by downloading the 2-year file and using the SMP/E RECEIVE command to process it. Then, use the SMP/E REPORT MISSINGFIX report to identify the missing PTFs, if any. For example:
    SET BDY(GLOBAL). REPORT MISSINGFIX ZONES(target zone) FIXCAT(IBM.Device.Server.*.RequiredService).

    If you want more granular reports for REPORT MISSINGFIX, you can use the individual FIXCATs for each server, plus the FIXCATs for any intermediate services. The FIXCATs for the z14 servers are:

    • For IBM z14 models M01 through M05, the FIXCAT for z14 required service is: IBM.Device.Server.z14-3906.RequiredService.
    • For IBM z14 Model ZR1, the FIXCAT for z14 required service is: IBM.Device.Server.z14ZR1-3907.RequiredService.

    Exploitation of some functions requires a web deliverable. Specifically:

    • Exploitation of the Crypto Express6S requires the Cryptographic Support for z/OS V2R1 - z/OS V2R3 (FMID HCR77C1) web deliverable.

      If you are using this web deliverable and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs identified by the following fix category: IBM.Coexistence.ICSF.z/OS_V2R1-V2R3-HCR77C1

    • If you are running z/OS V2R1 and require Crypto Express4S functionality for CCA 4.4 and other EP11 cryptographic enhancement support, which includes: RKX Key Export Wrap, UDX Reduction/simplification, additional EP11 algorithms, expanded EMV support, AP Configuration simplification, CTRACE Enhancements, and KDS Key Utilization Stats, then you must download and install the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77A1) or the Cryptographic Support for z/OS V1R13 - z/OS V2R2 web deliverable (HCR77B1).

      If you are using either of these web deliverables (HCR77A1 or HCR77B1) and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs identified by the appropriate Fix Category: IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77A1 or IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77B1.

    • If you are running z/OS V2R1 and require Crypto Express5S exploitation support for the next Generation Coprocessor support or VISA Format Preserving Encryption (FPE), you must download and install the Enhanced Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77B0) or the Cryptographic Support for z/OS V1R13 - z/OS V2R2 web deliverable (HCR77B1).

      If you are using either of these web deliverables (HCR77B0 or HCR77B1) and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs identified by the appropriate fix category: IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77B0 or IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77B1.

    • If you are running z/OS V1R13, you might need to install a Cryptographic Support web deliverable, depending on which ICSF functions you require.

      To run z/OS V1R13 on a z14 server, you require IBM Software Support Services for extended z/OS V1R13 support.

  3. Larger coupling facility structure sizes might be necessary. When you change the coupling facility control code level (CFLEVEL), your coupling facility structure sizes might change. If, as part of your migration to a z14 server, you change the CFLEVEL, you might have larger structure sizes than you did previously. If your CFLEVEL is identical, structure sizes are not expected to change when you migrate from a previous server to a newer generation server. In addition, similar to CFLEVEL 17 and later, ensure that the CF LPAR has at least 512MB of storage. CFLEVEL 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). This support removes inhibitors to using large CF cache structures, enabling use of Large Memory to scale to larger DB2 Local Buffer Pools (LBP) and Group Buffer Pools (GBP) in data sharing environments.
  4. Use the same software level throughout a sysplex. Having members of a sysplex at the same software level (other than during brief migration periods) is good software management policy.
  5. Migrate hardware and software at different times. To minimize the amount of change that you experience at one time, do not migrate your software release level at the same time that you migrate your hardware.
  6. Use the latest version of SCRT. In z/OS V2R3, you do not need to update SCRT because it is included in the z/OS base. If you are running an earlier release of z/OS, and you use SCRT, make sure that SCRT is at the latest level. This is a requirement for sub-capacity pricing. The latest level of SCRT for releases prior to z/OS V2R3 can be downloaded from the SCRT web site at IBM Z software pricing - Licensing - Sub-capacity licensing.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.2.2 : Restrictions for a z14 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Restrictions that are associated with the IBM z14™ server are described as follows:

  1. Functional limitations. Not all z14 functions are available in every z/OS release. See Table 1 and Table 2 in the workflow step "Upgrade to an IBM z14 server" for a list of the z14 functions available in each z/OS release. Some functions have migration or exploitation considerations. See the workflow steps "Actions you can take before you order an IBM z14 server" and "Actions you can take after installing an IBM z14 server.") Many functions are enabled or disabled, based on the presence or absence of the required hardware and software. If you plan to exploit new z14 functions, you can install the software and hardware in either order; that is, there is no requirement to install either software or hardware first to exploit a specific function. However, because of outage windows and testing considerations, you might want to consider installing all the software and PTFs required for the machine and the functions you plan to exploit first, then upgrade the hardware and, finally, update your customization to exploit the new functions.
  2. z14 servers in a sysplex.
    • A Parallel Sysplex® that contains a z14 server either for a z/OS image or a coupling facility (CF) image can only contain other z14 servers, or z13, z13s, zEC12, or zBC12 servers.

      Note that no coupling link connectivity is possible between IBM zEC12 and IBM zBC12 systems and the IBM z14 Model ZR1. Other systems, such as the z13, z13s, and z14, can connect to the z14 Model ZR1 by using the Integrated Coupling Adapter Short Reach (ICA SR) and the Coupling Express Long Reach (CE LR) coupling links. The zEC12 and zBC12 systems do not support ICA SR or CE LR, and therefore cannot have coupling link connectivity to the z14 Model ZR1. Also, the InfiniBand coupling links are not supported on the z14 Model ZR1.

      If you are running z/OS on any servers earlier than a zEC12 or zBC12 server, you cannot add a z14 server to that sysplex; that is, you will not be able to perform rolling IPLs to introduce a z14 server if you have any of the earlier servers as z/OS images or coupling facility images in the sysplex.

      The earlier servers in the sysplex must be upgraded to zEC12, zBC12, or later to have z14 servers supported in the sysplex. If you have any z/OS images or coupling facility images on an earlier server, and you intend to introduce a z14 server into that sysplex, you must migrate those images to a zEC12, zBC12, or later server before introducing the z14 server.

      GRS supports the use of FICON CTCs for Ring configurations. However, if you are currently using ESCON CTCs for GRS ring configurations within a sysplex, consider converting to GRS Star if possible, or using XCF signaling in a GRS ring configuration. XCF sysplex signaling is preferred instead of GRS CTC connections.

    • Starting with z13, servers that require time synchronization (for example, to support a base or Parallel Sysplex) must be configured in Server Time Protocol (STP) mode. STP is designed to allow multiple servers and coupling facilities to maintain time synchronization with each other, in a coordinated timing network (CTN). STP is a hardware feature of the z14, z13, z13s, zEC12, and zBC12. The most recent servers (z14, z13, and z13s) can participate only in an STP-only CTN.

      Starting with the z14 and the IBM Hardware Management Console (HMC) Version 2.14.0, you can use the Manage System Time task to configure an STP-only CTN. This task provides a simplified workflow for system time management, and features a visual topology display that surfaces configuration errors, if any, in the CTN.

  3. HCD and HCM support for the z14. As with previous servers, hardware can be defined on any supported OS version and server. However, dynamic activation of new server and new adapter types can be done only on z14 and future high-end IBM Z® servers.

    Dynamic activation is fully supported on z/OS V2R1 and later releases. Dynamic activation is restricted on z/OS V1R13; no hardware activation is permitted, if PCIe functions or the PNETID attribute for channel paths are defined. Limited software activation is available with hardware validation support.

    To run z/OS V1R13 on a z14 server, you require IBM Software Support Services for extended z/OS V1R13 support.

  4. Environmental Record Editing and Printing (EREP) support for the z14. Starting with the PTF for APAR IO24874, EREP supports any specification for the CPU parameter. That is, EREP does not fail an unrecognized value on the CPU parameter. If no matching records are found, EREP issues warning message IFC120I, as done in previous releases.
  5. Removal of support for running an operating system in ESA/390 architecture mode. Starting with the z14, the IBM Z® servers no longer support running in ESA/390 mode. The z14 and future systems support operating systems running in z/Architecture® mode. However, all 24-bit and 31-bit problem-state application programs that were originally written to run on the ESA/390 architecture are not affected by this change.
  6. Plan for discontinued functions. For a list of functions on the z14 that are planned to be discontinued on future servers, see the workflow step "Accommodate functions for the z14 to be discontinued on future servers."
  7. Unsupported hardware features. The following hardware features are not supported on the z14. They cannot be ordered on the z14 and cannot be carried forward from an upgrade on an earlier server to the z14.
    • Host Channel Adapter fanout:
      • The HCA2-O and HCA2-O LR features are not supported on any of the z14 models.
      • The HCA3-O and HCA3-O LR coupling fanouts are not supported on the z14 Model ZR1. This model requires ICA-SR and CE-LR fanouts.
    • IFB-MP Daughter Card #0326
    • STI-A8 Mother Card #0327
    • InterSystem Channel-3 (ISC-3) coupling links feature
    • CHPID type OSN (OSA-Express for NCP) is not supported on the OSA-Express5S GbE LX feature
    • OSA-Express4S features
    • Crypto Express4S feature
    • FICON Express8 features
    • Flash Express, which is replaced by Virtual Flash Memory on the z14
    • IBM zAware Firmware Appliance. IBM zAware analytics functions are now available through software, starting with IBM Operations Analytics for z Systems® Version 3.1. For more information, go to IBM Operations Analytics for z Systems.
    • STP Mixed CTN. The zEC12 and zBC12 were the last IBM Z® servers to support connections to an STP Mixed CTN. This also includes the Sysplex Timer (9037). Starting with the z13, servers that require Time synchronization, such as to support a base or Parallel Sysplex, require Server Time Protocol (STP) and all servers in that network must be configured in STP-only mode.
    • IBM zEnterprise® Application Assist Processor (zAAP). IBM continues to support running zAAP workloads on IBM z Integrated Information Processors (zIIPs). IBM has removed the restriction preventing zAAP-eligible workloads from running on zIIPs when a zAAP is installed on the CEC. This change was intended to help facilitate migration and testing of zAAP workloads on zIIPs. With a z14, one CP must be installed with the installation of any zIIPs or prior to the installation of any zIIPs. The total number of zIIPs purchased cannot exceed twice the number of CPs purchased. However, for upgrades from zEC12s with zAAPs, conversions from zAAPs can increase this ratio to 4:1.
  8. Carry forward hardware features. The following hardware features are not orderable on z14 servers. If they are installed on your existing server at the time of an upgrade to a z14 server, they can be retained or carried forward.
    • HMC #0092, #0094, #0095, and #0096
    • TKE with/4767 #0096 or #0097
    • OSA-Express4S 1000BASE-T #0408
    • OSA-Express5S GbE LX #0413
    • OSA-Express5S GbE SX #0414
    • OSA-Express5S 10 GbE LR #0415
    • OSA-Express5S 10 GbE SR #0416
    • OSA-Express5S 1000BASE-T #0417
    • FICON Express8S 10KM LX #0409
    • FICON Express8S SX #0410
    • FICON Express16S LX #0418
    • FICON Express16S SX #0419
    • 10GbE RoCE Express #0411
    • TKE workstation #0842
    • TKE workstation w/4767 #0847
    • Addl smart cards #0884
    • TKE Smart Card Reader #0885 or #0891
    • Crypto Express5S #0890
    • Fill and Drain Kit #3378
    • Universal Lift Tool/Ladder #3759.

    For information about supported storage controllers, see the workflow step "Ensure that you are using supported servers, storage controllers, and machine facilities."

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.2.3 : Actions you can take before you order an IBM z14 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

These are upgrade actions that you perform on your current system, either because they require the current system or because they are possible on the current system. You do not need the z14™ server to make these changes, and the changes do not require the z14 server once they are made. For example, discontinuing use of hardware that is no longer supported.

You can perform the following upgrade actions before you order or install a z14 server:

  1. Review the Large Systems Performance Reference (LSPR). LSPR is designed to provide comprehensive z/Architecture processor capacity ratios for different configurations of central processors (CPs) across a wide variety of system control programs and workload environments.
  2. Review the sysplex configuration in which the z14 server will participate. See the workflow step called "Restrictions for a z14 server" for a description of the limitations when using z14 server with certain earlier servers in a Parallel Sysplex.
  3. Implement an STP timing network. This action is needed because Sysplex Timers (9037-002) are not supported on z14 servers.
  4. Upgrade from ISC-3 links to the Integrated Coupling Adapter (ICA) links. This action is needed because ISC-3 links are not supported on z14 servers. If desired, you can take this action after you order a z14 server, as you upgrade to the new server.
  5. Upgrade from InfiniBand coupling links, if you are ordering a z14 Model ZR1. For connectivity to other systems, the z14 ZR1 requires Integrated Coupling Adapter Short Reach (ICA SR) and the Coupling Express Long Reach (CE LR) coupling links. The z14 ZR1 does not support InfiniBand coupling links.
  6. Upgrade from unsupported hardware features to newer technology. This action is needed because specific features are not available on the z14 server. For example, Crypto Express4S and OSA-Express4 are not supported. See the following workflow steps:
    • "Restrictions for a z14 server"
    • "Replace unsupported devices"
    • "Provide for new device installations"
  7. Determine the level of cryptographic support you require on a z14 server. The level of function that is provided for cryptographic support differs by z/OS release and the installed ICSF web deliverable. Also, toleration PTFs are available for some cryptographic web deliverables.

    For z/OS V2R3, consider the following:

    • If you are using the level of ICSF that is shipped as part of z/OS V2R3 (FMID HCR77C0), you can use most functions of the Crypto Express6S feature on a z14 server.
    • ICSF Web Deliverable HCR77C1 - Cryptographic Support for z/OS V2R1 - z/OS V2R3 provides some additional function and also incorporates enhancements that are available in PTFs for the base level of ICSF included in z/OS V2R3. The web deliverable includes support for a PCI HSM (“Payment Card Industry Hardware Security Module”) configured CCA coprocessor. Crypto Express6S also introduces the use of X.509 certificates in CCA.
    • If you are using this web deliverable and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs identified by the following Fix Category: IBM.Coexistence.ICSF.z/OS_V2R1-V2R3-HCR77C1

    For z/OS V2R2, consider the following:

    • If you are using the level of ICSF that is shipped as part of z/OS V2R2 (FMID HCR77B0), you can use most functions of the Crypto Express6S feature on a z14 server.
    • ICSF Web Deliverable HCR77C1 - Cryptographic Support for z/OS V2R1 – z/OS V2R3 provides some additional function and also incorporates enhancements that are available in PTFs for the base level of ICSF included in z/OS V2R2. The web deliverable includes support for a PCI HSM (“Payment Card Industry Hardware Security Module”) configured CCA coprocessor. Crypto Express6S also introduces the use of X.509 certificates in CCA.

    For z/OS V2R1, consider the following:

    • If you are using the level of ICSF that is shipped as part of z/OS V2R1 (FMID HCR77A0), Crypto Express5S is tolerated on a z14 server, which treats Crypto Express5S cryptographic coprocessors and accelerators as Crypto Express4S coprocessors and accelerators. However, you must install the required PTFs identified by the SMP/E fix category:
      • For IBM z14 models M01 through M05, use FIXCAT value IBM.Device.Server.z14-3906.RequiredService
      • For IBM z14 Model ZR1, use FIXCAT value IBM.Device.Server.z14ZR1-3907.RequiredService
    • If you require support for more than 16 domains on Crypto Express5S, you must install the PTFs that are identified by the appropriate fix category for your z14 server (either IBM.Device.Server.z14-3906.Exploitation or IBM.Device.Server.z14ZR1-3907.Exploitation), or install the ICSF Web Deliverable HCR77C1 - Cryptographic Support for z/OS V2R1 – z/OS V2R3, or a later ICSF web deliverable.
    • If you require Crypto Express4S functionality for CCA 4.4 and other EP11 cryptographic enhancement support that includes: RKX Key Export Wrap, UDX simplification, more EP11 algorithms, expanded EMV support, AP Configuration simplification, CTRACE Enhancements, and KDS Key Utilization stats, you must download and install the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77A1) or the Enhanced Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77B0) or a later ICSF web deliverable. Note:

      If you are using the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77A1) or a later ICSF web deliverable, and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs listed here, which are identified by fix category: IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77A1, or the FIXCAT for the ICSF level that you are using.

    • If you require Crypto Express6S exploitation support for the next Generation Coprocessor support or VISA Format Preserving Encryption (FPE), you must download and install the Enhanced Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77B0) or a later ICSF web deliverable. Note:

      If you are using ICSF Web Deliverable HCR77C1 - Cryptographic Support for z/OS V2R1 – z/OS V2R3, or a later ICSF web deliverable, and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs listed here, which are identified by fix category: IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77B0, or a later ICSF web deliverable.

  8. Install the necessary z/OS service. IBM recommends that you use the SMP/E REPORT MISSINGFIX command to identify PTFs for the z14 server that you do not already have installed. The simplest way to do that is to specify IBM.Device.Server.* and IBM.Function.* as the fix categories for the REPORT MISSINGFIX command. Doing so will identify not only z14 support PTFs, but those for prior generations of IBM servers that you might need, and those required to enable various functions. Also, REPORT MISSINGFIX creates a batch job for the SMP/E RECEIVE ORDER command that you can use to get any PTFs you do not already have. SMP/E also provides an Explorer function that you can use to find new fix categories that might be of interest. For a description of all the fix categories, see the Values and Descriptions page at IBM Fix Category Values and Descriptions. For more information about the REPORT MISSINGFIX command, see z/OS SMP/E Commands.

    Here is an example of the SMP/E control statements you can use for REPORT MISSINGFIX:

    SET BDY(GLOBAL) . REPORT MISSINGFIX ZONES(target zone) FIXCAT(IBM.Device.Server.* IBM.Function.*) .

    If you want to use specific fix categories, you can specify the following fix categories either individually or together for the z/OS PTFs that are required to use a z14 server, exploit its functions and features, and those that IBM recommends you install if you are using a z14 server. Also needed are the FIXCATs for intermediate processors.

    • For IBM z14 models M01 through M05:
      • IBM.Device.Server.z14-3906.RequiredService
      • IBM.Device.Server.z14-3906.Exploitation
      • IBM.Device.Server.z14-3906.RecommendedService
    • For IBM z14 Model ZR1:
      • IBM.Device.Server.z14ZR1-3907.RequiredService
      • IBM.Device.Server.z14ZR1-3907.Exploitation
      • IBM.Device.Server.z14ZR1-3907.RecommendedService

    In addition, if you choose to use specific fix categories, your environment might require that you specify one or more of these fix categories:

    • IBM.Function.DataSetEncryption
    • IBM.Function.ParallelSysplexInfiniBandCoupling
    • IBM.Function.PricingInfrastructure
    • IBM.Function.ServerTimeProtocol
    • IBM.Function.UnifiedResourceManager
    • IBM.Function.zEDC
    • IBM.Function.zHighPerformanceFICON
    • IBM.Function.zHyperLink

    If you are exploiting z14 capabilities by installing a web deliverable, additional PTFs might be required. Follow the instructions in the Program Directory that is associated with each web deliverable to identify the required PTFs.

    Another way to find required PTFs is by using Preventive Service Planning (PSP) "buckets." In addition to the applicable hardware PSP buckets, you must also obtain the software PSP buckets. The hardware PSP bucket lists the recommended, required, and exploitation PTFs, and also includes information about the appropriate fix categories that are needed to identify those PTFs. However, using PSP buckets and checking on the status of the PTFs listed in them is more time-consuming and potentially error-prone than using REPORT MISSINGFIX with the appropriate fix categories. 1

  9. Run the CFSIZER tool. If you are moving your coupling facilities and the coupling facility structures are on a higher CFLEVEL 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 CFLEVEL as indicated by the tool.

    You can download the CFSIZER tool at Coupling Facility sizer. Also, see the workflow step called "Update your CFRM policy with coupling facility structure size changes."

    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 CFSizer Alternate Sizing Techniques.

  10. Prepare for the new machine instruction mnemonics. The instruction set has been expanded on the z14 server, as is usual for new servers. Each machine instruction is represented by a mnemonic in Assembler language. The new mnemonics can be identical to the names you chose for Assembler macro instructions. In the event of such naming collisions, the Assembler's default opcode table (UNI) processes new mnemonics as instructions, not as macros, after z14 required service has been installed. If this occurs, it is likely to cause Assembler error messages and can cause incorrect object code to be generated. If you write programs in Assembler Language, compare the names of Assembler macro instructions that are used to the new machine instructions (documented in the latest z/Architecture Principles of Operation, SA22-7832) to identify any such conflicts or collisions that would occur. Identical names cause Assembler errors or the generation of incorrect object code when you assemble your programs. For information about a tool to help in identifying mnemonic conflicts, see IBM Techdocs. Search for the Techdoc PRS5289.

    If a conflict is identified, take one of these actions:

    • Change the name of your macro instruction.
    • Specify PARM='...OPTABLE(YOP)...' (or some other earlier opcode table).
    • Specify a separate ASMAOPT file containing assembler options such as in the previous method (this method requires no changes to source code or JCL).
    • Add as the first statement of your source program: *PROCESS OPTABLE(YOP) (or some other earlier opcode table).
    • Specify the PROFILE option either in JCL or the ASMAOPT file, and the specified or default member of the SYSLIB data set is copied into the front of the source program.
    • If you must use both a new instruction and a macro with the same name in an assembly, you can use a coding technique that permits both use of a new instruction and a macro with the same name in an assembly such as HLASM mnemonic tags ( :MAC:ASM).
  11. Accommodate the changes to default ARCH and TUNE level. Starting with z/OS V2R3, the default ARCH level is changed from ARCH(8) to ARCH(10), and the default TUNE level is changed from TUNE(8) to TUNE(10). The new default levels align with the zEC12; thus, code can run on any server that is supported by z/OS V2R3 without requiring changes to compiler options. However, if you compile programs to be run on processors at lower architecture levels, you must specify the appropriate ARCH and TUNE levels when you compile those programs.

    The z14 supports the new levels ARCH(12) and TUNE(12), which are needed to take advantage of the new z14 instructions, and are intended to provide performance improvements for applications. ARCH(12) produces code that uses instructions that are available on the z14 in z/Architecture mode. The z14 adds instructions for vector programming, including allowing packed decimal operations to be performed in registers rather than memory. TUNE(12) generates code that is executable on all models, but is optimized for the z14.

  12. Update I/O Configuration Program (IOCP) for earlier FICON cards. To continue using FICON Express8S cards, you must specify the new IOCP keyword MIXTYPE.
  13. Use the LOADxx MACHMIG statement to help with upgrade. In the LOADxx member, you can include the new MACHMIG statement to specify particular z14 hardware facilities that you want to disable during your upgrade to another processor, z/OS release, or both. You can exclude the following z14 facilities:
    • Hardware-based enhanced-DAT facility (EDAT2)
    • Hardware-based transactional-execution facility (TX)
    • Hardware-based vector registers (VR) in support of SIMD (VEF)
    • Guarded Storage Facility (GSF).

    If you omit the MACHMIG statement, z/OS does not limit its use of the machine facilities.

  14. Decide on the steps to take for your upgrade to a z14 server. Besides the steps that are listed here, see the following workflow step for guidance: "Actions you can take after installing an IBM z14 server."

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.2.4 : Actions you can take after installing an IBM z14 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

These are upgrade actions that you perform only after you have installed the z14 server. You need a running z14 server to perform these actions.

For more information about PTFs, see the table notes for "Base support for z/OS V2R2, z/OS V2R3, and z/OS V2R4."

  1. FICON Express16S. FICON Express16S supports a link data rate of 16 gigabits per second (Gbps) and auto-negotiation to 4 or 8 Gbps for synergy with existing switches, directors, and storage devices. With support for native FICON, High Performance FICON for z IBM z Systems (zHPF), and Fibre Channel Protocol (FCP), the new FICON Express16S channel is designed to work with your existing fiber optic cabling environment. The FICON Express16S feature running at end-to-end 16 Gbps link speeds can provide reduced latency for large read/write operations, and increased bandwidth compared to the FICON Express8S feature.
  2. Upgrade to Virtual Flash Memory (VFM). IBM Virtual Flash Memory (VFM) is the replacement for the Flash Express features (#0402, #0403) which were available on the IBM zEC12 and IBM z13. No application changes are required to change from IBM Flash Express to VFM. Ensure that you replace your Flash memory with adequate VFM.
  3. Upgrade actions for Hardware Instrumentation Services (HIS). New diagnostic samples are added for the z14. If you want to ignore them, you might need to update your HIS profilers. Also, to tolerate the new counters (cycle and instruction) in the Problem Counter Set, you might need to update your HISSERV profilers, SMF 113 records, or z/OS UNIX System Services counter file consumers. For more information, see the topic "Starting, configuring, and stopping hardware event data collection" in z/OS MVS System Commands.

    Note: As of z/OS V2R1, if you use the CPU Measurement Facility, IBM recommends that your installation collect SMF 113 subtype 1 and 2 records. IBM also recommends that products process SMF 113 subtype 1 records when available because that is where future enhancements are made. If subtype 1 records are not available, products can process subtype 2 records.

  4. Enable BCPii communications on the support element. For Support Elements that run on z14, the setting for the “Cross Partition Authority” option is replaced by new security settings on the System Details panel and the Customize Image Profiles panel. For more information, see the workflow step "Enable BCPii communications on the support element."

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.2.5 : Accommodate functions for the z14 to be discontinued on future servers


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Note:

IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

Description

The following changes in hardware support could affect your environment. Make the appropriate changes, as needed.

  1. Removal of support for Host Channel Adapter fanout optical features. The z14™ is the last IBM Z® high-end server to support HCA3-O fanout (#0171) and HCA3-O LR fanout for 1x IFB (#0170). Note:

    The z14 Model ZR1 does not support the HCA3-O or the HCA3-O LR coupling fanouts. This model requires ICA-SR and CE-LR fanouts.

    Enterprises should begin migrating from HCA3-O and HCA3-O LR channels to one of the following coupling links on the z14, z13, and z13s.

    • For high-speed short-range coupling connectivity, the IBM Integrated Coupling Adapter (ICA SR). The ICA SR is a two-port, short-distance coupling fanout that uses a new coupling channel type: CS5. The ICA SR can only be used for coupling connectivity between z14, z13, and z13s servers. The ICA SR fanout requires new cabling, and can only connect to another ICA SR.
    • For long-range coupling connectivity, the Coupling Express Long Reach (CE LR). The CE LR is a two-port, long-distance coupling adapter that uses a new coupling channel type: CL5. The CE LR can only be used for coupling connectivity between z14, z13, and z13s servers.

    The suggested practice is to order ICA SR (#0172) or CE LR (#0433) on the z14 processors that are used in a Parallel Sysplex to help ensure coupling compatibility with future processor generations.

  2. Removal of FICON Express8S support. The z14 is the last IBM Z® high-end server to support FICON Express8S (#0409 and #0410) channels. Your installation should begin migrating from FICON Express8S channels to FICON Express16S+ channels(#0427 and #0428). FICON Express8S will not be supported on future high-end IBM Z® servers as carry forward on an upgrade.
  3. Removal of support for the zEDC Express. The z14 is the last IBM Z® high-end server to support the zEDC Express (#0420). In the future, IBM Z® high-end server compression acceleration functionality moves from the zEDC adapter to processors.
  4. Removal of support for OSA-Express6S 1000BASE-T adapters. The OSA-Express6S 1000BASE-T adapter (#0426) is the last generation of OSA 1000BASE-T adapters to support connections operating at 100 Mb/second link speed. Future OSA-Express 1000BASE-T adapter generations will support operation only at 1000 Mb/second (1 Gb/s) link speed.
  5. Removal of support for sysplex coexistence between zEC12 and zBC12 servers and future servers.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.3 : Upgrade to an IBM z13 or IBM z13s server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

Description

z/OS running on the z13 or z13s sets the groundwork for digital business by providing the foundation you need to support demanding workloads, such as operational analytics and clouds, and your traditional mission-critical applications.

In a Parallel Sysplex that includes a z13 or z13s with either a z/OS system running in at least one LPAR or at least one LPAR being used as a coupling facility (CF), you can include the following servers:

  • z13 and z13s servers
  • zEC12 and zBC12 servers
  • zEnterprise servers (z196 or z114)

The specific z13 and z13s functions, including base support, that are used by z/OS depend on the z/OS release. PTFs might be required for many of these functions. See the workflow step called "Actions you can take before you order a z13 or z13s server" for information about finding the appropriate PTFs.

Base support for z/OS V2R2, z/OS V2R3, and z/OS V2R4

The following table shows a summary view of which z13 and z13s server functions are included in the base support for z/OS V2R2, z/OS V2R3, and z/OS V2R4.

z13 and z13s function included in base z/OS support (Y/N)

V2R2¹

V2R3¹

V2R4¹

Base support

Y

Y

Yes, and in PTFs

CHPID type CS5 for coupling

Y

Y

Y

CHPID type OSE supporting 4 or 2 ports per feature

Y

Y

Y

CHPID type OSM for intranode management network (INMN)

Y

Y

Y

CHPID type OSN for OSA-Express for NCP (LPAR-to-LPAR)

Y

Y

Y

CPU measurement facility

Y

Y

Y

Crypto Express5S Toleration

Y

Y

Y

FICON Express 8S (CHPID FC)

Y

Y

Y

FICON Express16S (CHPID FC)

Y

Y

Y

IBM z BladeCenter Extension (zBX) Model 004

Y

Y

Y

IBM z Unified Resource Manager

Y

Y

Y

New z13 machine instruction (assembler support)

Y

Y

Y

OSA-Express4S (GbE LX and SX, 1000BASE-T, 10 GbE LR and SR)

Y

Y

Y

OSA-Express5S (GbE LX and SX, 1000BASE-T, 10 GbE LR and SR)

Y

Y

Y

Parallel Sysplex InfiniBand (PSIFB) Coupling Link

Y

Y

Y

z/OS global resource serialization (GRS) support for FICON CTCs

Y

Y

Y

Note:
  1. PTFs for base support have the following fix category:
    • For z13: IBM.Device.Server.z13-2964.RequiredService
    • For z13s: IBM.Device.Server.z13S-2965.RequiredService

Exploitation support for z/OS V2R2, z/OS V2R3, and z/OS V2R4

The following table shows a summary view of which z13 and z13s server functions can be exploited in z/OS V2R2, z/OS V2R3, and z/OS V2R4.

z13 and z13s function included in base z/OS support (Y/N)

V2R2²

V2R3²

V2R4²

Coupling Facility Control Code Level 20 (CFLEVEL 20)

Y

Y

Y

CFCC Dump Reasons support for CFLEVEL 21

Y

Y

Y

Crypto Express5S support for up to 85 Domains

Y

Y

Y

High Performance FICON (zHPF)

Y

Y

Y

IBM Integrated Coupling Adapter (ICA SR)

Y

Y

Y

Support for 256 coupling CHPIDs

Y

Y

Y

2 GB Large Pages

Y

Y

Y

Checksum offload for IPv6 packets (CHPID OSD)

Y

Y

Y

Checksum offload for LPAR-to-LPAR traffic for IPv4 and IPv6 packets (CHPID OSD)

Y

Y

Y

Crypto Express5S support of VISA Format Preserving Encryption (FPE), Next Generation Coprocessor support

Y

Y

Y

Flash Express (Storage Class Memory or SCM)

Y

Y

Y

IBM System Advanced Workload Analysis Reporter (IBM zAware)

Y

Y

Y

Inbound workload queuing for Enterprise Extender (CHPID OSD)

Y

Y

Y

Large Send for IPv6 packets (CHPID OSD)

Y

Y

Y

Manage FICON Dynamic Routing Support

Y

Y

Y

Transactional memory

Y

Y

Y

Up to 4 Subchannels Sets per CSS (z13)

Y

Y

Y

Up to 3 Subchannels Sets per CSS (z13s)

Y

Y

Y

Up to 85 LPARs (z13)

Y

Y

Y

Up to 40 LPARs (z13s)

Y

Y

Y

Greater than 100 CPs per z/OS system image

Y (z13 only). The z13 can have a maximum of 128 CPs in non-SMT mode, or up to 213 threads in SMT mode.

The z13s can have a maximum of 40 CPs in non-SMT mode, or up to 66 threads in SMT mode.

Y (z13 only). The z13 can have a maximum of 128 CPs in non-SMT mode, or up to 213 threads in SMT mode.

The z13s can have a maximum of 40 CPs in non-SMT mode, or up to 66 threads in SMT mode.

Y (z13 only). The z13 can have a maximum of 128 CPs in non-SMT mode, or up to 213 threads in SMT mode.

The z13s can have a maximum of 40 CPs in non-SMT mode, or up to 66 threads in SMT mode.

Miscellaneous PCIe enhancements

Y

Y

Y

RoCE Express for Shared Memory Communications-Remote (SMC-R) Direct Memory Access including shared RoCE Express support

Y

Y

Y

Shared Memory Communications-Direct Memory Access (SMC-D)

Y

Y

Y

Simultaneous multithreading (SMT)

Y

Y

Y

Single Instruction Multiple Data (SIMD) instruction set

Y

Y

Y

XL C/C++ support of ARCH(11) and TUNE(11) parameters

Y

Y

Y

zEDC capability using zEDC Express

Y (requires the z/OS zEDC software feature to be enabled)

Y

Y

Notes:
  1. PTFs for base support have the following fix category:
    • For z13: IBM.Device.Server.z13-2964.RequiredService
    • For z13s: IBM.Device.Server.z13S-2965.RequiredService
  2. PTFs for exploitation have the following fix category:
    • For z13: IBM.Device.Server.z13-2964.Exploitation
    • For z13s: IBM.Device.Server.z13S-2965.Exploitation

Web deliverables are available from the z/OS downloads page at z/OS downloads.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

  • IBM z13®, which first shipped March 2015.
  • z13s, which first shipped March 2016.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Anytime before you introduce a z13 or z13s server into your environment.

Is the upgrade action required?

Yes, if you want to run z/OS V2R4, z/OS V2R3, or z/OS V2R2 on a z13 or z13s server, or if you want to run a coupling facility on a z13 or z13s server. If you plan to run only a coupling facility on a z13 or z13s system, only the sysplex-related actions are relevant. However, you must install the appropriate z/OS service for systems that are running on other servers that use the z13 or z13s coupling facilities.

Target system hardware requirements:

  • A z13 or z13s
  • Additional hardware required for specific functions.
    • IBM devices previously attached to zEC12, zBC12, and zEnterprise servers are supported for attachment to z13 or z13s channels, unless otherwise noted. The subject I/O devices must meet FICON architecture requirements
    • IBM zAware requires the following server firmware:
      • IBM zAware 10 pack FC #1010
      • IBM zAware 10 pack on a Disaster Recovery Server FC #1011
    • Flash Express requires FC #0403
    • zEDC Express requires FC #0420
    • 10 GbE RoCE Express FC #0411
    • Use of IBMWebSphere DataPower® Integration Appliance XI50 for zEnterprise (DataPower XI50z) or select IBM BladeCenter PS701 Express blades or IBM BladeCenter HX5 blades requires a z BladeCenter Extension (zBX) Model 004
    • z BladeCenter Extension (zBX) Model 004 requires:
      • AIX® 5.3, AIX 6.1, AIX 7.1 and up, and PowerVM® Enterprise Edition (on POWER7® blade)
      • Red Hat RHEL 5.5, 6.0, 7.0 and up, SLES 10 (SP4), 11 (SP1), 12 and up, 64-bit only (on HX5 blade)
      • Microsoft Windows Server 2012, Microsoft Windows Server 2012 R2, Microsoft Windows Server 2008 R2, and Microsoft Windows Server 2008 (SP2) (Datacenter Edition recommended), 64-bit only (on HX5 blade)
    • Use of hardware acceleration for cryptographic operations, including the use of the Visa, Inc. Data Secure Platform (DSP) functions requires a CPACF (FC #3863) or a CEX5S (FC #0890) feature, or both.

      See Table Note 1.

  • - Use of a Trusted Key Entry (TKE) workstation requires FC #0847.

Target system software requirements:

See the topic Support is delivered by service, z/OS features, and web deliverables in the workflow step "General recommendations and considerations for a z13 or z13s server" and Install the necessary z/OS service, as indicated in the PSP buckets that are described in the workflow step "Actions you can take before you order a z13 or z13s server."

Other system (coexistence or fallback) requirements:

  • It is recommended that you install and run the required service on your existing server. This will enable you to fall back from a hardware perspective, yet maintain your software level.
  • If you have not installed the preconditioning and exploitation PTFs for CFLEVEL 17-19, note that those PTFs are required to be installed throughout your sysplex before implementing CFLEVEL 20 or CFLEVEL 21.
  • If you plan to implement zEDC, you should install the z/OS toleration PTFs on systems that access data that is compressed using zEDC Express on a z13 or z13s server.
  • If you are using ICSF and plan to share keys with other z/OS systems that have an earlier level of ICSF, you should install the ICSF coexistence PTFs on those earlier levels of ICSF.

Restrictions:

See the workflow step called "Restrictions for a z13 or z13s server."

System impacts:

None.

Related IBM Health Checker for z/OS check:

A health check for FICON dynamic routing, CHECK(IBMIOS,IOS_FABRIC_MONITOR), is available with the PTF for APAR OA40548 for z/OS V2R1, and included in z/OS V2R2 and z/OS V2R3. This health check is designed to check all components of a dynamic routing fabric, the channel subsystem, and disk control units to make sure that dynamic routing requirements are met if dynamic routing is enabled for one or more FICON switches. This support is intended to help you identify misconfiguration errors that can result in data integrity exposures.

Table Note:
  1. IBM Z® cryptography features include VISA Format Preserving Encryption (VFPE) technology, which forms part of the Visa, Inc. Data Secure Platform (DSP). The use of VFPE technology requires a service agreement with Visa, Inc. For details, contact your Visa account manager or Visa at P2PE@visa.com. Clients who use IBM Z® cryptography features, but do not make use of the FPE functionality, are not required to enter into any such agreement with Visa.

Steps to take

Perform the workflow steps that follow:

  • "General recommendations and considerations for a z13 or z13s server"
  • "Restrictions for a z13 or z13s server"

Reference information

None.


Step 3.2.3.1 : General recommendations and considerations for a z13 or z13s server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

As you plan your migration to a z13 or z13s TM server, consider the following:

  1. Relatively few upgrade actions are new when coming from an IBM zEnterprise EC12 or zEnterprise BC12 server. Migration to an IBM z13 or IBM z13s® server has, as its base, a migration to the IBM zEnterprise EC12 or zEnterprise BC12 servers. This means that if you are migrating to a z13 or z13s server from a zEC12 or zBC12 server, and have performed the upgrade actions that are associated with the zEC12 or zBC12, you have fewer upgrade actions than if you were migrating from an earlier generation server and have not yet performed the upgrade actions that are associated with these servers. It is important to note that you can migrate directly to a z13 or z13s server without installing the intermediate servers, but you still need to ensure that any migration considerations are satisfied for the servers that you skipped. To read about the zEC12 and zBC12 server upgrade actions, see the workflow step called "Upgrade to an IBM zEnterprise EC12 or IBM zEnterprise BC12 server."
  2. Support is delivered by service, z/OS features, and web deliverables. The base support for the z13 and z13s is delivered by service (PTFs).
    • The PSP bucket that contains the required list of PTFs for the z13 server is: Upgrade 2964DEVICE, Subset 2964/ZOS and is identified by the following SMP/E Fix Category IBM.Device.Server.z13-2964.RequiredService
    • The PSP bucket that contains the required list of PTFs for the z13s server is: Upgrade 2965DEVICE, Subset 2965/ZOS and is identified by the following SMP/E Fix Category IBM.Device.Server.z13S-2965.RequiredService.

    Exploitation of some functions requires a web deliverable. Specifically:

    • If you are running z/OS V2R1 and require Crypto Express4S functionality for CCA 4.4 and other EP11 cryptographic enhancement support that includes: RKX Key Export Wrap, UDX Reduction/simplification, additional EP11 algorithms, expanded EMV support, AP Configuration simplification, CTRACE Enhancements, and KDS Key Utilization Stats, then you must download and install the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77A1) or the Cryptographic Support for z/OS V1R13 - z/OS V2R2 web deliverable (HCR77B1).

      If you are using either of these web deliverables (HCR77A1 or HCR77B1) and sharing keys with other z/OS systems that have a lower-level of ICSF, you require the coexistence PTFs identified by the appropriate Fix Category: IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77A1 or IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77B1.

    • If you are running z/OS V2R1 and require Crypto Express5S exploitation support for the next Generation Coprocessor support or VISA Format Preserving Encryption (FPE), you must download and install the Enhanced Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77B0) or the Cryptographic Support for z/OS V1R13 - z/OS V2R2 web deliverable (HCR77B1).

      If you are using either of these web deliverables (HCR77B0 or HCR77B1) and sharing keys with other z/OS systems that have a lower-level of ICSF, you require the coexistence PTFs identified by the appropriate Fix Category: IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77B0 or IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77B1.

    • If you are running z/OS V2R1 and require exploitation of new hardware instructions using XL C/C++ ARCH(11) and TUNE(11) including SIMD, vector programming, MASS and ATLAS libraries, you must download and install the XL C/C++ V2R1M1 web deliverable with z13 support for z/OS 2.1.
    • If you are running z/OS V1R13 and want to exploit Flash Express (including pageable 1 MB Large Page Support, optional paging of PLPA and Common (CSA, ECSA) pages to Flash Express, and Dynamic reconfiguration support for Flash Express); or 2 GB Large Page support, you must download and install the z/OS V1.13 RSM Enablement Offering Web deliverable and install the required PTFs identified by the Fix Category.
    • If you are running z/OS V1R13, you might need to install a Cryptographic Support web deliverable, depending on which ICSF functions you require.
  3. Larger coupling facility structure sizes might be necessary. When you change the coupling facility control code level (CFLEVEL), your coupling facility structure sizes might change. If, as part of your migration to a z13 server, you change the CFLEVEL, you might have larger structure sizes than you did previously. If your CFLEVEL is identical, structure sizes are not expected to change when you migrate from a previous server to a newer generation server. In addition, similar to CFLEVEL 17 and later, ensure that the CF LPAR has at least 512MB of storage. CFLEVEL Levels 20 and 21, introduced on the z13 and 13s, support 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). 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.
  4. Use the same software level throughout a sysplex. Having members of a sysplex at the same software level (other than during brief migration periods) is good software management policy.
  5. Migrate hardware and software at different times. To minimize the amount of change (and therefore risk) that you experience at one time, do not migrate your software release level at the same time that you migrate your hardware.
  6. Use the latest version of SCRT. In z/OS V2R3, you do not need to update SCRT because it is included in the z/OS base. If you are running an earlier release of z/OS, and you use SCRT, make sure that SCRT is at the latest level. This is a requirement for sub-capacity pricing. The latest level of SCRT for releases prior to z/OS V2R3 can be downloaded from the SCRT web site at IBM Z software pricing - Licensing - Sub-capacity licensing.

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMIOS,IOS_FABRIC_MONITOR.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".

NOTE: The successful running of this IBM Health Checker for z/OS check only partially covers this upgrade action. Refer to the upgrade action text for the complete list of steps to take.


Step 3.2.3.2 : Restrictions for a z13 or z13s server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Restrictions associated with the z13™ and z13s™ servers are described as follows:

  1. Functional limitations. Not all z13 or z13s functions are available in every z/OS release. See the tables in workflow step "Upgrade to an IBM z13 server" for a list of the z13 and z13s functions available in each z/OS release. Some functions have migration or exploitation considerations (see workflow step "Actions you can take before you order a z13 or z13s server" and "Migration and exploitation considerations for z13 and z13s server functions.") Many functions are enabled or disabled, based on the presence or absence of the required hardware and software. If you plan to exploit new z13 or z13s functions, you can install the software and hardware in either order; that is, there is no requirement to install either software or hardware first to exploit a specific function. However, because of outage windows and testing considerations, you might want to consider installing all the software and PTFs required for the machine and the functions you plan to exploit first, then upgrade the hardware and, finally, update your customization to exploit the new functions.
  2. z13 and z13s servers in a sysplex.
    • A Parallel Sysplex that contains a z13 or z13s server either for a z/OS image or a CF image can only contain other z13 or z13s servers, or z196, z114, zEC12, or zBC12 servers.

      If you are running z/OS on any servers earlier than a z196 or z114 server, you cannot add a z13 or z13s server to that sysplex; that is, you will not be able to perform rolling IPLs to introduce a z13 or z13s server if you have any of the earlier servers as z/OS images or coupling facility images in the sysplex.

      The earlier servers in the sysplex must be upgraded to z196, z114, or later to have z13 or z13s servers supported in the sysplex. If you have any z/OS images or coupling facility images on an earlier server, and you intend to introduce a z13 or z13s server into that sysplex, you must migrate those images to a z196, z114, or later server before introducing the z13 or z13s server.

      GRS supports the use of FICON CTCs for Ring configurations. However, if you are currently using ESCON CTCs for GRS ring configurations within a sysplex, consider converting to GRS Star if possible, or using XCF signalling in a GRS ring configuration. XCF sysplex signalling is preferred instead of GRS CTC connections.

    • InterSystem Channel 3 (ISC-3) and Integrated Cluster Bus 4 (ICB-4) Coupling Links are not supported on z13 or z13s CPC. Instead, the IBM Integrated Coupling Adapter (ICA SR), introduced on the z13 and z13s, is a two-port, short distance coupling fanout that utilizes a new coupling channel type: CS5. The ICA SR can only be used for coupling connectivity between z13 or z13s servers, and the ICA SR can only connect to another ICA SR. IBM recommends that you order ICA SR (#0172) on the z13 processors used in a Parallel Sysplex to help ensure coupling compatibility with future processor generations. You can also use 12x InfiniBand coupling links, which are designed to replace Integrated Cluster Bus 4 (ICB-4), and to complement 1x InfiniBand and ISC-3 on a z13 or z13s server. InfiniBand coupling can provide significantly improved service times compared to ISC-3s for distances up to 150 meters. You can read about coupling links in IBM System z® Connectivity Handbook (SG24-5444).
    • The z13 or z13s server cannot be connected to a Sysplex Timer (9037-002). The Server Time Protocol (STP) feature is the follow-on to the Sysplex Timer. STP is designed to allow multiple servers and coupling facilities to maintain time synchronization with each other without requiring a Sysplex Timer. STP is a hardware feature of the z13, z13s, zEC12, zBC12, z196, and z114. For more information about how to implement STP, see the Server Time Protocol (STP) website.

      The STP design introduced a concept called Coordinated Timing Network (CTN). A CTN is a collection of servers and coupling facilities that are time-synchronized to a time value called Coordinated Server Time. A CTN can be configured in two ways:

      • STP-only CTN, which does not require a Sysplex Timer. A z13 or z13s must participate in an STP-only CTN.
      • Mixed-CTN (External Time Reference and STP), which does require a Sysplex Timer. zEC12 and zBC12 were the last servers to support mixed-CTN. The z13 and z13s do not support connections to a Mixed-CTN. All servers in the network must be configured in STP-only mode. Consider migrating servers that require time synchronization, such as to support a base or Parallel Sysplex, to the Server Time Protocol (STP).

    For more information, see the following references:

  3. Plan for discontinued functions. For a list of functions on the z13 server that are planned to be discontinued on future servers, see the workflow step "Accommodate functions for the z13 server or z13s to be discontinued on future servers."
  4. Unsupported hardware features. The following hardware features cannot be ordered and cannot be carried forward from an upgrade on an earlier server to the z13 server.
    • HCA2-O
    • HCA2-O LR
    • ISC-3 links
    • CHPID type OSN (OSA-Express for NCP) is not supported on the OSA-Express5S GbE LX feature
    • Crypto Express3 (#0864)
    • Crypto Express4S (#0865)
    • STP Mixed CTN. The zEC12 and zBC12 were the last IBM Z® servers to support connections to an STP Mixed CTN. This also includes the Sysplex Timer (9037). Starting with z13, servers that require Time synchronization, such as to support a base or Parallel Sysplex, will require Server Time Protocol (STP) and all servers in that network must be configured in STP-only mode.
    • IBM zEnterprise Application Assist Processor (zAAP). IBM continues to support running zAAP workloads on IBM z Integrated Information Processors (zIIPs). IBM has removed the restriction preventing zAAP-eligible workloads from running on zIIPs when a zAAP is installed on the CEC. This change was intended to help facilitate migration and testing of zAAP workloads on zIIPs. With a z13, one CP must be installed with the installation of any zIIPs or prior to the installation of any zIIPs. The total number of zIIPs purchased cannot exceed twice the number of CPs purchased. However, for upgrades from zEC12s with zAAPs, conversions from zAAPs may increase this ratio to 4:1.
  5. Carry forward hardware features. The following hardware features are not orderable on z13 servers. If they are installed on your existing server at the time of an upgrade to a z13 server, they can be retained or carried forward.
    • HMC #0091
    • HCA2-C Fanout #0162
    • IFB-MP Daughter Card #0326
    • STI-A8 Mother Card #0327
    • Flash Express #0402 and #0403
    • OSA-Express4S 1 GbE LX #0404
    • OSA-Express4S 1 GbE SX #0405
    • OSA-Express4S 10 GbE LR #0406
    • OSA-Express4S 10 GbE SR #0407
    • OSA-Express4S 1000BASE-T #0408
    • OSA-Express5S GbE LX #0413
    • OSA-Express5S GbE SX #0414
    • OSA-Express5S 10 GbE LR #0415
    • OSA-Express5S 10 GbE SR #0416
    • OSA-Express5S 1000BASE-T #0417
    • TKE workstation #0842
    • Addl smart cards #0884
    • TKE Smart Card Reader #0885
    • FICON Express8 10KM LX #3325
    • FICON Express8 SX #3326
    • FICON Express8S 10Km LX #0409
    • FICON Express8S SX #0410
    • 10GbE RoCE Express #0411
    • zEDC Express #0420
    • Fill and Drain Kit #3378
    • Universal Lift Tool/Ladder #3759

    Also, FICON Express8 will not be supported on future high-end IBM Z® servers as carry forward on an upgrade. The z13 and z13s servers will be the last IBM Z® servers to offer ordering of FICON Express8S channel features. Enterprises that have 2GB device connectivity requirements must carry forward these channels.

    For information about supported storage controllers, see the workflow step "Ensure that you are using supported servers, storage controllers, and machine facilities."

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.3.3 : Actions you can take before you order a z13 or z13s server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

You can perform the following upgrade actions before you order or install a z13 or z13s TM server:

  1. Review the sysplex configuration in which the z13 or z13s server will participate. See the workflow step called "Restrictions for a z13 or z13s server" for a description of the limitations when using z13 or z13s servers with certain earlier servers in a Parallel Sysplex.
  2. Implement an STP timing network. This action is needed because Sysplex Timers (9037-002) are not supported on z13 or z13s servers.
  3. Migrate from ISC-3 links to Infinband or Integrated Coupling Adapter (ICA) links. This action is needed because ISC-3 links are not supported on z13 or z13s servers. If desired, you can take this action after you order a z13 or z13s server, as you upgrade to the new server.
  4. Migrate from unsupported hardware features to newer technology. This action is needed because ESCON, FICON Express4, Crypto Express3, and OSA-Express3 are not supported on z13 or z13s servers. See the following steps in this workflow:
    • "Restrictions for a z13 or z13s server"
    • "Replace unsupported devices"
    • "Provide for new device installations"
  5. Determine the level of cryptographic support you require on a z13 or z13s server. The level of function provided for cryptographic support differs by z/OS release and the installed ICSF web deliverable. Also, toleration PTFs are available for some cryptographic web deliverables.

    For z/OS V2R3, if you are using the level of ICSF that is shipped as part of z/OS V2R3, you can use all functions of the Crypto Express5 feature on a z13 or z13s server.

    For z/OS V2R2, consider the following:

    • If you are using the level of ICSF that is shipped as part of z/OS V2R2, you can use the most functions of the Crypto Express5 feature on a z13 or z13s server.
    • The Cryptographic Support for z/OS V1R13 - z/OS V2R2 web deliverable (FMID HCR77B1) provides some additional function and also incorporates enhancements that are available in PTFs for the base level of ICSF included in z/OS V2R1. The web deliverable includes new operator commands with Parallel Sysplex wide scope that can be used to perform certain cryptographic administrative functions. These functions include activating, deactivating, and restarting cryptographic coprocessors. This support can also be used to display status for available cryptographic devices and information about active key data sets (KDSs).

    For z/OS V2R1, consider the following:

    • If you are using the level of ICSF that is shipped as part of z/OS V2R1, you can tolerate Crypto Express5 on a z13 or z13s server, which treats Crypto Express5S cryptographic coprocessors and accelerators as Crypto Express4S coprocessors and accelerators. However, you must install the required PTFs identified by the SMP/E fix category:
      • For the z13: IBM.Device.Server.z13-2964.RequiredService
      • For the z13s: IBM.Device.Server.z13S-2965.RequiredService
    • If you require support for greater than 16 domains (up to 85) on Crypto Express5S, you must install the PTFs that are identified by the appropriate fix category IBM.Device.Server.z13-2964.Exploitation or IBM.Device.Server.z13S-2965.Exploitation, or install the Enhanced Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77B0) or a later ICSF web deliverable.
    • If you require Crypto Express4S functionality for CCA 4.4 and other EP11 cryptographic enhancement support that includes: RKX Key Export Wrap, UDX simplification, additional EP11 algorithms, expanded EMV support, AP Configuration simplification, CTRACE Enhancements, and KDS Key Utilization stats, you must download and install the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77A1) or the Enhanced Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77B0) or a later ICSF web deliverable.

      Note: If you are using the Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77A1) or a later ICSF web deliverable, and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs listed here, which are identified by fix category: IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77A1, or the FIXCAT for the ICSF level that you are using.

    • If you require Crypto Express5S exploitation support for the next Generation Coprocessor support or VISA Format Preserving Encryption (FPE), you must download and install the Enhanced Cryptographic Support for z/OS V1R13-z/OS V2R1 web deliverable (FMID HCR77B0) or a later ICSF web deliverable.

      Note: If you are using the Enhanced Cryptographic Support for z/OS V1R13-z/OS V2R1 Web Deliverable (FMID HCR77B0) or a later ICSF web deliverable, and sharing keys with other z/OS systems that have a lower level of ICSF, you require the coexistence PTFs listed here, which are identified by fix category: IBM.Coexistence.ICSF.z/OS_V1R13-z/OS_V2R1-HCR77B0, or a later ICSF web deliverable.

  6. Install the necessary z/OS service, as indicated in PSP buckets. You must obtain all of the appropriate Preventive Service Planning (PSP) buckets. In addition to the hardware PSP buckets, you must also obtain the software PSP buckets. Use the Fix Categories that are specified in the associated FIXCAT HOLDDATA to identify PTFs required for the z13 server, PTFs needed to exploit z13 capabilities, and PTFs recommended to fix known problems. Specifically, fixes in the following categories:
    • For the z13:
      • IBM.Device.Server.z13-2964.RequiredService
      • IBM.Device.Server.z13-2964.Exploitation
      • IBM.Device.Server.z13-2964.RecommendedService
    • For the z13s:
      • IBM.Device.Server.z13S-2965.RequiredService
      • IBM.Device.Server.z13S-2965.Exploitation
      • IBM.Device.Server.z13S-2965.RecommendedService

    Fixes required for several zEnterprise functions (such as Parallel Sysplex InfiniBand Coupling Links, Server Time Protocol (STP), the Unified Resource Manager, High Performance FICON for IBM z Systems (zHPF), and zEnterprise Data Compression (zEDC) are not listed in the hardware PSP bucket, but can be found by using the following Fix Categories:

    • For the z13:
      • IBM.Device.Server.z13-2964.ParallelSysplexInfiniBandCoupling
      • IBM.Device.Server.z13-2964.ServerTimeProtocol
      • IBM.Device.Server.z13-2964.UnifiedResourceManager
      • IBM.Device.Server.z13-2964.zHighPerformanceFICON
      • IBM.Function.zEDC
    • For the z13s:
      • IBM.Device.Server.z13S-2965.ParallelSysplexInfiniBandCoupling
      • IBM.Device.Server.z13S-2965.ServerTimeProtocol
      • IBM.Device.Server.z13S-2965.UnifiedResourceManager
      • IBM.Device.Server.z13S-2965.zHighPerformanceFICON
      • IBM.Function.zEDC

    Because the PTFs associated with these Fix Categories are not specific to a z13 server, you should consider specifying a generic wildcard for the server to ensure that you have all the appropriate service installed. For example:

    • IBM.Device.Server.*.ParallelSysplexInfiniBandCoupling
    • IBM.Device.Server.*.ServerTimeProtocol
    • IBM.Device.Server.*.UnifiedResourceManager
    • IBM.Device.Server.*.zHighPerformanceFICON

    Similarly, fixes needed for zBX or to support the IBM DB2 Analytics Accelerator (IDAA) are not listed in the hardware PSP bucket, but can be found by using the following Fix Categories:

    • IBM.Device.Server.zBX-2458
    • IBM.DB2.AnalyticsAccelerator.*

    If you are exploiting z13 capabilities by installing a web deliverable, you must install the PTFs listed in the software PSP buckets for each of the web deliverables that you are installing. See the program directory for the web deliverable to identify the required software PSP buckets.

    The REPORT MISSINGFIX command checks your GLOBAL zone for FIXCAT HOLDDATA matching the FIXCAT values specified on the command. The command then compares the APARs identified in that FIXCAT HOLDDATA with the PTFs installed in the specified zones, and produces a report to identify any APARs not resolved. In other words, it reports which PTFs (fixes) are missing for the specified fix categories. Furthermore, the command produces a customized job that is used to obtain any PTFs not already received through the RECEIVE ORDER command, and install any missing service via the APPLY CHECK command.

    The FIXCAT operand on the REPORT MISSINGFIX command can list multiple fix categories, as well as using the same wildcarding techniques described in this topic for the SOURCEID operand. Because both of these techniques are simple and integrated into basic SMP/E commands, use them periodically to ensure the latest PTFs specified in the hardware and software PSP buckets are installed (because PSP buckets can be updated daily). SMP/E also provides an Explorer function which helps in identifying new fix categories which might be of interest. For a description of all the fix categories, see the Values and Descriptions page at IBM Fix Category Values and Descriptions. For more information about the REPORT MISSINGFIX command, see z/OS SMP/E Commands.

  7. Run the CFSIZER tool. If you are moving your coupling facilities and the coupling facility structures are on a higher CFLEVEL 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 CFLEVEL as indicated by the tool.

    You can download the CFSIZER tool at Coupling Facility sizer. Also, see the workflow step called "Update your CFRM policy with coupling facility structure size changes."

    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 CFSizer Alternate Sizing Techniques.

  8. Prepare for the new machine instruction mnemonics. In support of the z13 server, there are new machine instructions. The new machine instructions (mnemonics) can collide with (be identical to) the names of Assembler macro instructions you use. In the event of such collisions, the Assembler default opcode table (UNI) treats specification of these names as instructions when the z13 required service is installed, probably causing Assembler error messages and possibly causing generation of incorrect object code. If you write programs in Assembler Language, compare the names of Assembler macro instructions that are used to the new machine instructions (documented in the latest z/Architecture Principles of Operation, SA22-7832) to identify any such conflicts or collisions that would occur. Identical names cause Assembler errors or the generation of incorrect object code when you assemble your programs. For information about a tool to help in identifying mnemonic conflicts, see IBM Techdocs. Search for the Techdoc PRS5289.

    If a conflict is identified, take one of these actions:

    • Change the name of your macro instruction.
    • Specify PARM='...OPTABLE(YOP)...' (or some other earlier opcode table).
    • Specify a separate ASMAOPT file containing assembler options such as in the previous method (this method requires no changes to source code or JCL).
    • Add as the first statement of your source program: *PROCESS OPTABLE(YOP) (or some other earlier opcode table).
    • Specify the PROFILE option either in JCL or the ASMAOPT file, and the specified or default member of the SYSLIB data set is copied into the front of the source program.
    • If you must use both a new instruction and a macro with the same name in an assembly, you can use a coding technique that permits both use of a new instruction and a macro with the same name in an assembly such as HLASM mnemonic tags (:MAC :ASM).
  9. Decide on the steps to take for your migration to a z13 server. Besides the steps listed here, see the following workflow step for guidance: "Migration and exploitation considerations for z13 and z13s server functions."

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.3.4 : Migration and exploitation considerations for z13 and z13s server functions


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

The following z13 and z13s TM functions have considerations when you are planning for migration and exploitation. For PTF information, see the table notes for "Base support for z/OS V2R2, z/OS V2R3, and z/OS V2R4."

  1. Large Systems Performance Reference (LSPR) method. LSPR is designed to provide comprehensive z/Architecture processor capacity ratios for different configurations of central processors (CPs) across a wide variety of system control programs and workload environments.
  2. Simultaneous multithreading (SMT). Incremental throughput is achieved partly because the new processor chip offers intelligently implemented 2-way simultaneous multithreading. Simultaneous multithreading allows two active instruction streams per core, each dynamically sharing the core's execution resources. SMT is available on the z13 for workloads that are running on the Integrated Facility for Linux (IFL) and the IBM z Integrated Information Processor (zIIP).
  3. CFLEVEL 20 and CFLEVEL 21 support. CFLEVEL 20 and 21 support 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. This support removes inhibitors to using large CF cache structures, enabling use of Large Memory to scale to larger DB2 Local Buffer Pools and Group Buffer Pools in data sharing environments.
  4. Coupling links. IBM z13 introduced new PCIe (Integrated Coupling Adapter ICA SR) based Short Reach coupling links using a new CHPID type, CS5. ICA-SR links can only connect z13 and z13s CPCs to other z13 and z13s CPCs.

    IBM z13 and z13s CPC now support up to 256 links. A single z/OS or a CF Image supports a maximum of 128 links. When displaying STP (DISPLAY ETR) from a z/OS image, information is provided for the entire CPC. If more than 128 links are defined, the z/OS support must be installed on all z/OS releases running on that CPC, so that information about more than 128 links, including STP timing information, can be displayed.

  5. SIMD. z/OS V2R1 (and later) is designed to support the new vector extension facility (Single Instruction Multiple Data, SIMD) instructions available on IBM z13 servers. SIMD provides a powerful framework for development of new Business Analytics workloads, porting math-intensive workloads from other platforms, and accelerating Business Analytics workloads on IBM z13 and z13s servers. High Data Intensity, High Computational Intensity, Predictive IT Analytics, Advanced Security/Crypto, BI Reporting, Perspective Analytics, and Next-Generation Data Warehousing are some of the workloads that may benefit from Data Parallelism (SIMD). z/OS support includes enablement of Vector Registers (VR) on IBM z13 and z13s servers, Mathematical Acceleration Subsystem (MASS), and Automatically Tuned Linear Algebra Software (ATLAS) support, as well as Language Environment enablement for C runtime functions.
  6. Cryptographic Enhancements. Cryptographic enhancements for z/OS V2R1 (and later) on z13 servers include:
    • VISA Format Preserving Encryption (VFPE). Support for VFPE algorithms in CCA-based callable services helps legacy databases to contain encrypted data of sensitive fields without having to restructure the database or applications. This support relies on the Crypto Express5S coprocessor.
    • Greater than 16 Domain support. This support allows a cryptographic coprocessor to be shared across more than 16 domains, up to the maximum number of LPARs on the system. This support relies on enhanced firmware available with a minimum microcode level for the Crypto Express5S coprocessor.
    • Trusted Key Entry (TKE) 8.0 Licensed Internal Code (LIC). This support includes Crypto Express5S Coprocessor support, FIPS Certified Smart Card, Crypto Coprocessors with more than 16 domains, a full-function migration wizard for EP11 coprocessors, new master key management functions, a Smart Card Readers Available indicator, a Configure Displayed Hash Size utility, ECC Authority Signature Keys, print capability, new features in the Crypto Node Management (CNM) utility, ENC-Zero verification pattern for 24-byte DES operational keys, and usability enhancements.

    See Decide on the steps you will take for your migration to a z13 server in the workflow step called "Actions you can take before you order a z13 or z13s server."

  7. IBM zAware system. The IBM zAware feature is designed to offer a near real-time, continuous learning, and diagnostics capability intended to help you pinpoint and resolve potential problems quickly enough to minimize impacts to your business. The new version of IBM zAware introduces a new generation of technology with improved analytics to provide better results. After you order a z13 or z13s server, you can prepare to set up an IBM zAware environment by defining the IBM zAware logical partition (LPAR), defining and using OPERLOG log streams, and network definitions to connect the z/OS LPAR to the IBM zAware LPAR. For more information, see IBM z Advanced Workload Analysis Reporter (IBM zAware) Guide, (SC27-2623), and z/OS MVS Setting Up a Sysplex.
  8. Java exploitation. This support is added by:
    • IBM 31-bit SDK for z/OS, Java Technology Edition, Version 8 (5655-DGG)
    • IBM 64-bit SDK for z/OS, Java Technology Edition, Version 8 (5655-DGH)
  9. Flash Express. With this support, z/OS is designed to help improve system availability and responsiveness by using Flash Express across transitional workload events such as market openings, and diagnostic data collection. z/OS is also designed to help improve processor performance by supporting middleware exploitation of pageable large (1 MB) pages. This support requires the Flash Express hardware feature.
  10. 2GB Large Page support. This support includes support for 2 GB large fixed pages.
  11. New z/Architecture instructions: XL C/C++ ARCH(11) and TUNE(11) parameters. This function provides new hardware instruction support, including support for the vector facility, the decimal floating point packed conversion facility, and numerous performance improvements (machine model scheduling and code generation updates). Single Instruction Multiple Data (SIMD) instruction set and execution support is provided through the new vector support in the compiler, including Business Analytics vector processing through the MASS and ATLAS libraries. Unlike prior generations of servers, to use any of these functions on z/OS V2R1, you must download and install the XL C/C++ V2R1M1 web deliverable with z13 support for z/OS 2.1.
  12. FICON Express16S. FICON Express16S supports a link data rate of 16 gigabits per second (GBPS) and auto-negotiation to 4 or 8 GBPS for synergy with existing switches, directors, and storage devices. With support for native FICON, High Performance FICON for System z (zHPF), and Fibre Channel Protocol (FCP), the new FICON Express16S channel is designed to work with your existing fiber optic cabling environment. The FICON Express16S feature running at end-to-end 16 GBPS link speeds provides reduced latency for large read/write operations, and increased bandwidth compared to the FICON Express8S feature.
  13. FICON Dynamic Routing. With z13, FICON channels are no longer restricted to the use of static Storage Area Network (SAN) routing policies for Inter-Switch Links (ISLs) for cascaded FICON directors. You need to ensure that all devices in your FICON SAN support FICON Dynamic Routing before implementing this feature.
  14. Improved High Performance FICON for System z (zHPF) I/O Execution at Distance. High Performance FICON for System z (zHPF) has been enhanced to allow all large write operations (> 64 KB) at distances up to 100 km to be executed in a single return trip to the control unit, thereby not elongating the I/O service time for these write operations at extended distances.
  15. Improved Channel Subsystem (CSS) Scalability. The IBM Z® servers have improved the channel subsystem (CSS) scalability, as follows:
    • The z13 server improves CSS scalability with support for six logical channel subsystems (LCSSs), which are required to support the 85 LPARs for z13, four subchannel sets (to support more devices per logical channel subsystem), and 32K devices per FICON channel, up from 24K channels in the previous generation. Additionally, a fourth subchannel set for each LCSS is provided to facilitate elimination of single points of failure for storage after a disk failure.
    • The z13s server improves CSS scalability with support for three logical channel subsystems (LCSSs) which are required to support the 40 LPARs for IBM z13s, three subchannel sets (to support more devices per logical channel subsystem), and 32K devices per FICON channel up from 24K channels in the previous generation. Additionally, a third subchannel set for each logical channel subsystem (LCSS) is provided to facilitate elimination of single points of failure for disk storage devices.
  16. PCIe and HCD Definitions. z/OS V2R1, and z/OS V2R1 HCD (FMID HCS7790) support full exploitation for z13 and z13s processors (types 2964 and 2965) with support for up to 6 channel subsystems and 4 subchannel sets. To support PCIe functions for systems that are running on zEC12, zBC12, z13, or z13s servers, HCD introduced a new dialog for defining PCIe functions and assigning the functions to LPARs.

    IBM recommends that you define and activate all the new hardware definitions on a z/OS V2R2 system, or on a V2R1 system with the appropriate HCD PTF (APAR OA44294) installed and perform software activations (with hardware validation) only on lower-level systems.

  17. Consider the changes in the CPU Measurement Facility counters. The number of CPU measurement facility counters for z13 and z13s servers remains at 128. Though the structure of the SMF 113 record does not change, the values, interpretations, and frequency of certain sections do change; therefore, current tools that use the data must be updated for the z13 and z13s servers.

    For example, consider the following SMF record field:

    • SMF113_2_CtrVN2 identifies how to interpret the MT-Diagnostic, Crypto, and Extended Counter Sets. As described in The IBM CPU Measurement Facility Extended Counters Definition for z10 and z196, SA23-2260, this field is set to 1 (for z10), 2 (for z196 or z114), 3 (for zEC12 and zBC12), or 4 (for z13 and z13s).

    Note: As of z/OS V2R1, if you use the CPU Measurement Facility, IBM recommends that your installation collect SMF 113 subtype 1 and 2 records. IBM also recommends that products process SMF 113 subtype 1 records when available because that is where future enhancements are made. If subtype 1 records are not available, products can process subtype 2 records.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.3.5 : Accommodate functions for the z13 server or z13s to be discontinued on future servers


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Note:

IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

Description

The following changes in hardware support could affect your environment. Make the appropriate changes, as needed.

  • Removal of support for running an operating system in ESA/390 architecture mode. The z13 and z13s™ are the last IBM Z® servers to support running in ESA/390 mode. All future systems will support only operating systems running in z/Architecture mode. However, all 24-bit and 31-bit problem-state application programs originally written to run on the ESA/390 architecture will be unaffected by this change.
  • Removal of support for Classic Style User Interface on the Hardware Management Console and Support Element. The z13 and z13s are the last IBM Z® servers to support Classic Style User Interface. In the future, user interface enhancements will be focused on the Tree Style User Interface.
  • Removal of support for the Hardware Management Console Common Infrastructure Model (CIM) Management Interface. The z13 and z13s are the last IBM Z® servers to support the Hardware Console Common Infrastructure module (CIM) Management Interface. The Hardware Management Console Simple Network Management Protocol (SNMP), and Web Services Application Programming Interfaces (APIs) will continue to be supported.
  • Removal of FICON Express8 support. The z13 and z13s are the last IBM Z® servers to support FICON Express8. You should begin migrating from FICON Express8 channel features (#3325, #3326) to FICON Express16S channel features (#0418, #0419). FICON Express8 will not be supported on future high-end IBM Z® servers as carry forward on an upgrade.
  • Removal of support for ordering FICON Express8S channel features. Enterprises that have 2GB device connectivity requirements must carry forward these channels.
  • Removal of an option for the way shared logical processors are managed under PR/SM LPAR. The z13 and z13s are the last IBM Z® servers to support selection of the option Do not end the timeslice if a partition enters a wait state when the option to set a processor run-time value has been previously selected in the CPC RESET profile. The CPC RESET profile applies to all shared logical partitions on the machine, and is not selectable by logical partition.
  • Removal of support for configuring OSN CHPID types. OSN CHPIDs are used to communicate between an operating system instance running in one logical partition and the Communications Controller for Linux (CCL) product in another logical partition on the same CPC. See announcement letter #914-227 dated 12/02/2014 for details regarding withdrawal from marketing for the CCL product.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.4 : Upgrade to an IBM zEnterprise EC12 or IBM zEnterprise BC12 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

Description

An IBM zEnterprise EC12 (zEC12) and IBM zEnterprise BC12 (zBC12) server can include the following in a zEnterprise environment:

  • IBM zEnterprise EC12 server Central Processing Complex (CPC) or IBM zEnterprise BC12 server CPC
  • zEnterprise BladeCenter Extension (zBX) Model 003 with its integrated optimizers or select IBM blades
  • zEnterprise Unified Resource Manager (Unified Resource Manager)

The zEC12 and zBC12 are distinct from the earlier zEnterprise and other servers. In this publication, the IBM zEnterprise EC12 server is referred to as the model zEC12 server and the IBM zEnterprise BC12 server is referred to as the model zBC12 server.

In a Parallel Sysplex, you can include the following servers:

  • zEC12 and zBC12 servers
  • zEnterprise servers (z196 or z114)
  • z10 EC and z10 BC servers.

The specific zEC12 and zBC12 functions including base support that are used by z/OS depend on the z/OS release. Availability and other restrictions are noted in the Notes column. PTFs might be required for many of these functions. See the workflow step called "Actions you can take before you order a zEC12 or zBC12 server" for information about finding the appropriate PTFs.

Base support for z/OS V2R2, z/OS V2R3, and z/OS V2R4

The following table shows a summary view of which zEC12 and zBC12 server functions are included in the base support for z/OS V2R2, z/OS V2R3, and z/OS V2R4.

zEC12 and zBC12 function included in base z/OS support (Y/N)

V2R2¹

V2R3¹

V2R4¹

Base support

Y

Y

Y

OSA-Express4S (GbE LX and SX, 1000BASE-T, 10 GbE LR and SR)

Y

Y

Y

OSA-Express5S (GbE LX and SX, 1000BASE-T, 10 GbE LR and SR)

Y

Y

Y

FICON Express 8S (CHPID FC)

Y

Y

Y

High Performance FICON (zHPF)

Y

Y

Y

Parallel Sysplex InfiniBand (PSIFB) Coupling Link

Y

Y

Y

CPU measurement facility

Y

Y

Y

New z/Architecture instructions: XL C/C++ ARCH(10) and TUNE(10) parameters

Y

Y

Y

Crypto Express3 Toleration (if carried forward)

Y

Y

Y

IBM zEnterprise Unified Resource Manager

Y

Y

Y

IBM zEnterprise BladeCenter Extension (zBX) Model 3

Y

Y

Y

GRS FICON CTC toleration

Y

Y

Y

Notes:
  1. PTFs for base support have a fix category of either:
    • For zEC12: IBM.Device.Server.zEC12-2827
    • For zBC12: IBM.Device.Server.zBC12-2828
  2. PTFs for exploitation have a fix category of either:
    • For zEC12: IBM.Device.Server.zEC12-2827.Exploitation
    • For zBC12: IBM.Device.Server.zEC12-2828.Exploitation
  3. PTFs for zEDC exploitation or software decompression have a fix category (for both zEC12 and zBC12) of IBM.Function.zEDC.

Exploitation of zEC12 and zBC12 functions by z/OS V2R2, z/OS V2R3, and z/OS V2R4

The following table shows a summary view of which zEC12 and zBC12 server functions can be exploited in z/OS V2R2, z/OS V2R3, and z/OS V2R4.

zBC12 functional exploitation of z/OS support (Y/N)

V2R2²

V2R3²

V2R4²

Coupling Facility Control Code Level 18 (CFLEVEL 18)

Y

Y

Y

Coupling Facility Control Code Level 18 (CFLEVEL 19)

Y

Y

Y

CFLEVEL 19 Coupling thin interrupt support

Y

Y

Y

Crypto Express4S (#0865) exploitation, including Enterprise Security PKCS #11-Hardware Security Module (HSM), DUKPT for MAC and Data Encryption, Cipher Text Translate CCA Verb, PKDS/TKDS Constraint Relief, Random Number Cache, FIPS on Demand, and Wrapping Keys with Strong Keys

Y

Y

Y

Crypto Express4S CCA enhancements, including: Export TDES key under AES transport key, Diversified Key Generation CBC, IPEK, RKX key wrapping method, and Integration of UDX into CCA

Y

Y

Y

Crypto Express4S: EP11 enhancements when the Crypto Express4S PCIe adapter is configured as an EP11 coprocessor, including: (PKCS #11 v2.1 PSS, EP11 Key agreement algorithms, and Offload Generation of Domain Parameters)

Y

Y

Y

Crypto Express4S support of greater than 16 Domains

Y

Y

Y

Flash Express (Storage Class Memory or SCM)

Y

Y

Y

Pageable 1 MB Large Page Support.

Y

Y

Y

Dynamic reconfiguration support for Flash Express.

Y

Y

Y

2 GB Large Page support.

Y

Y

Y

Optional PLPA/common page data set support.

Y

Y

Y

10GbE RoCE Express

Y

Y

Y

Java Exploitation of Transactional Execution (requires Java7 SR3)

Y

Y

Y

IBM System Advanced Workload Analysis Reporter (IBM zAware)

Y

Y

Y

New z/Architecture instructions: XL C/C++ ARCH(10) and TUNE(10) parameters

Y

Y

Y

New z/Architecture Assembler Language instruction mnemonic

Y

Y

Y

zEDC capability using zEDC Express

Y³ (requires the z/OS zEDC software feature to be enabled)

Y³ (requires the z/OS zEDC software feature to be enabled)

Y³ (requires the z/OS zEDC software feature to be enabled)

Notes:
  1. PTFs for base support have a fix category of either:
    • For zEC12: IBM.Device.Server.zEC12-2827
    • For zBC12: IBM.Device.Server.zBC12-2828
  2. PTFs for exploitation have a fix category of either:
    • For zEC12: IBM.Device.Server.zEC12-2827.Exploitation
    • For zBC12: IBM.Device.Server.zEC12-2828.Exploitation
  3. PTFs for zEDC exploitation or software decompression have a fix category (for both zEC12 and zBC12) of IBM.Function.zEDC.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

  • IBM zEnterprise EC12, which first shipped September 2012.
  • IBM zEnterprise BC12 (zBC12), which first shipped September 2013.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Anytime before you introduce a zEC12 or zBC12 server into your environment.

Is the upgrade action required?

Yes, if you want to run z/OS V2R3 or z/OS V2R2 on a zEC12 or zBC12 server, or if you want to run a Coupling Facility on a zEC12 or zBC12 server. If you will run only a Coupling Facility on a zEC12 or zBC12 system, only the sysplex-related actions are relevant.

Target system hardware requirements:

  • A zEC12 or zBC12
  • Additional hardware required for specific functions.
    • IBM devices previously attached to IBM System z10, z196 and zSeries servers are supported for attachment to zEC12 channels, unless otherwise noted. The subject I/O devices must meet FICON architecture requirements
    • IBM zAware requires the IBM zAware server firmware (FC #0011, #0101, and #0102)
    • Flash Express requires FC #0402
    • zEDC Express requires FC #0420
    • 10 GbE RoCE Express FC #0411
    • Use of IBMWebSphere DataPower Integration Appliance XI50 for zEnterprise (DataPower XI50z) or select IBM BladeCenter PS701 Express blades or IBM BladeCenter HX5 blades requires a zEnterprise BladeCenter Extension (zBX) Model 003

Target system software requirements:

  1. See the list of PTFs in the Software Service Level section of the PSP buckets and use the SMP/E Fix Categories:
    • For zEC12 base support: IBM.Device.Server.zEC12-2827
    • For zBC12 base support: IBM.Device.Server.zBC12-2828
    • For zEC12 exploitation: IBM.Device.Server.zEC12-2827.Exploitation
    • For zBC12 exploitation: IBM.Device.Server.zBC12-2828.Exploitation
    • For zEC12 and zBC12 zEDC exploitation or toleration: IBM.Function.zEDC
  2. See Support is delivered by service, z/OS features, and web deliverables described in the workflow step called "General recommendations and considerations for a zEC12 or zBC12 server" and Install the necessary z/OS service, as indicated in PSP buckets described in the workflow step called "Actions you can take before you order a zEC12 or zBC12 server."

Other system (coexistence or fallback) requirements:

  • It is recommended that you install and run the zEnterprise required service on your existing server. This will enable you to fall back from a hardware perspective, yet maintain your software level.
  • If you have not installed the preconditioning and exploitation PTFs for CFLEVEL 17, note that these PTFs are required to be installed throughout your sysplex before implementing CFLEVEL 18 or 19.
  • If you plan to implement zEDC, you should install the z/OS toleration PTFs on systems that access data that is compressed using zEDC Express on a zEC12 or zBC12 server.

Restrictions:

See the workflow step called "Restrictions for a zEC12 or zBC12 server."

System impacts:

None.

Related IBM Health Checker for z/OS check:

To verify that HiperDispatch is enabled on a z196 or later system, use IBMSUP, SUP_HiperDispatchCPUConf, which was added to z/OS V1R12 with APAR OA30476.

Steps to take

Follow the information in the follwoing steps:

  • "General recommendations and considerations for a zEC12 or zBC12 server"
  • "Restrictions for a zEC12 or zBC12 server"

Reference information

None.


Step 3.2.4.1 : General recommendations and considerations for a zEC12 or zBC12 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

As you plan your migration to a zEnterprise server, consider the following:

  1. Relatively few upgrade actions are new when coming from a z196 or z114 server. Migration to an IBM zEnterprise EC12 or zEnterprise BC12 server has, as its base, a migration to the z196 or z114 servers. This means that if you are migrating to a zEnterprise server from a z196 or z114 server, and have performed the upgrade actions that are associated with the z196 or z114, you have fewer upgrade actions than if you were migrating from an earlier generation server and have not yet performed the upgrade actions that are associated with these servers. It is important to note that you can migrate directly to a zEC12 or zBC12 server without installing the intermediate servers, but you still need to ensure that any migration considerations are satisfied for the servers that you skipped.
  2. Support is delivered by service, z/OS features, and web deliverables. The base support for an zEC12 or zBC12 server is delivered by service (PTFs).
    • The PSP bucket that contains the required list of PTFs for zBC12 is: Upgrade 2828DEVICE, Subset 2828/ZOS and is identified by the following SMP/E Fix Category IBM.Device.Server.zBC12-2828.
    • The PSP bucket that contains the required list of PTFs for zEC12 is: Upgrade 2827DEVICE, Subset 2827/ZOS

    and is identified by the following SMP/E Fix Category IBM.Device.Server.zEC12-2827.

    For Flash Express support (including dynamic reconfiguration support and optional PLPA/COMMON page data set support), pageable 1 MB Large Page support, and 2 GB Large Page Support, a separate web deliverable for z/OS V1R13 (the z/OS V1R13 RSM Enablement Offering web deliverable) is required. For more information, see Decide on the steps you will take for your migration to a zEC12 or zBC12 server in the workflow step called "Actions you can take before you order a zEC12 or zBC12 server."

  3. Larger coupling facility structure sizes might be necessary. When you change the coupling facility control code level (CFLEVEL), your coupling facility structure sizes might change. zEC12 servers that were ordered before September 2013 initially shipped with CFLEVEL 18, zEC12 or zBC12 models ordered after September 2013 initially shipped with CFLEVEL 19. If, as part of your migration to a zEC12 or zBC12 server, you change the CFLEVEL, you might have larger structure sizes than you did previously. If your CFLEVEL is identical, structure sizes are not expected to change when you migrate from a previous server to a newer generation server. In addition, similar to CFLEVEL 17 and later, ensure that the CF LPAR has at least 512MB of storage. CFLEVEL 19 introduces support for storage-class (flash) memory in the CF and Coupling thin interrupt support. CF structures that exploit SCM might require significantly more CF real storage than they did before storage class memory exploitation.
  4. Use the same software level throughout a sysplex. Having members of a sysplex at the same software level (other than during brief migration periods) is good software management policy.
  5. Migrate hardware and software at different times. To minimize the amount of change (and therefore risk) that you experience at one time, do not migrate your software release level at the same time that you migrate your hardware.
  6. Use the latest version of SCRT. In z/OS V2R3, you do not need to update SCRT because it is included in the z/OS base. If you are running an earlier release of z/OS, and you use SCRT, make sure that SCRT is at the latest level. This is a requirement for sub-capacity pricing. The latest level of SCRT for releases prior to z/OS V2R3 can be downloaded from the SCRT web site at IBM Z software pricing - Licensing - Sub-capacity licensing.

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMSUP,SUP_HiperDispatchCPUConfig.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".

NOTE: The successful running of this IBM Health Checker for z/OS check only partially covers this upgrade action. Refer to the upgrade action text for the complete list of steps to take.


Step 3.2.4.2 : Restrictions for a zEC12 or zBC12 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

The following restrictions are associated with zEnterprise servers:

  1. Functional limitations. Not all zEC12 or zBC12 functions are available in every z/OS release. For the zEC12 and zBC12 functions that are available in each z/OS release, see the tables in the workflows step "Upgrade to an IBM zEC12 or zBC12 server."

    Some functions have migration or exploitation considerations (see the workflow steps "Actions you can take before you order a zEC12 or zBC12 server" and "Migration and exploitation considerations for zEC12 and zBC12 server functions.") Many functions are enabled or disabled, based on the presence or absence of the required hardware and software. If you wish to position yourself to exploit any new zEC12 or zBC12 functions, you can install the software and hardware in either order; that is, there is no requirement to install either software or hardware first to exploit a specific function. However, because of outage windows and testing considerations, you might want to consider installing all the required software first, then upgrading the hardware and, finally, updating your customization to exploit the new functions.

  2. zEC12 and zBC12 servers in a sysplex.
    • A Parallel Sysplex that contains an zEC12 or zBC12 server either for a z/OS image or a CF image can contain only zEC12 or zBC12 servers or zEnterprise z196, z114, z10 EC, or z10 BC servers.

      If you are running z/OS on any servers earlier than a z10 EC or z10 BC server, you cannot add a zEC12 or zBC12 server to that sysplex; that is, you cannot perform rolling IPLs to introduce a zEC12 or zBC12 server if you have any of the earlier servers either as z/OS images or coupling facility images in the sysplex.

      The earlier servers in the sysplex must be upgraded to System z10 or later to have zEC12 or zBC12 servers supported in the sysplex. If you have any z/OS images or coupling facility images on an earlier server, and you intend to introduce a zEC12 or zBC12 server into that sysplex, you must migrate those images to a System z10 (or later) server before introducing the zEC12 or zBC12 server.

      If you are currently using ESCON CTCs for GRS ring configurations within a sysplex, consider using XCF signaling in a GRS ring configuration. XCF sysplex signaling is preferred instead of GRS CTC connections.

    • The Integrated Cluster Bus 4 (ICB-4) Coupling Links are not supported on a zEC12 or zBC12 CPC. Use 12x InfiniBand coupling links, which are designed to replace Integrated Cluster Bus 4 (ICB-4), and to complement 1x InfiniBand and ISC-3 on a zEC12 or zBC12 server. InfiniBand coupling can provide significantly improved service times compared to ISC-3s for distances up to 150 meters. You can read about InfiniBand coupling links in IBM System z Connectivity Handbook (SG24-5444).
    • The zEC12 or zBC12 server cannot be connected to a Sysplex Timer (9037-002). The Server Time Protocol (STP) feature is the follow-on to the Sysplex Timer. STP is designed to allow multiple servers and coupling facilities to maintain time synchronization with each other without requiring a Sysplex Timer. STP is a hardware feature of the zEC12, zBC12, z196, z114, z10 EC, and z10 BC. For more information about how to implement STP, see the Server Time Protocol (STP) website.

      The STP design introduced a concept that is called Coordinated Timing Network (CTN). A CTN is a collection of servers and coupling facilities that are time-synchronized to a time value called Coordinated Server Time. A CTN can be configured in two ways:

      • STP-only CTN, which does not require a Sysplex Timer.
      • Mixed-CTN (External Time Reference and STP), which does require a Sysplex Timer.

        The Sysplex Timer provides the timekeeping information in a Mixed-CTN. Even though the zEC12 or zBC12 servers do not support attachment to a Sysplex Timer, they can participate in a Mixed-CTN with a z10 server that is synchronized to the Sysplex Timer. This maintains the capability for enterprises to concurrently migrate from an existing External Time Reference (ETR) to a Mixed-CTN and from a Mixed-CTN to an STP-only CTN.

      Note:

      The zEC12 and zBC12 are the last high-end servers to support connections to an STP Mixed-CTN. All servers in the network must be configured in STP-only mode. Consider migrating servers that require time synchronization, such as to support a base or Parallel Sysplex, to the Server Time Protocol (STP).

  3. For a list of functions on the zEC12 or zBC12 server that are planned to be discontinued on future servers, see the workflow step "Accommodate functions for the zEC12 and zBC12 servers to be discontinued on future servers."
  4. Unsupported hardware features. The following hardware features cannot be ordered and cannot be carried forward from an upgrade on an earlier server to the zEC12 or zBC12 server.
    • Power® Sequence Controller (PSC).
    • FICON Express. Your installation should begin migrating to FICON Express8S channels.
    • FICON Express2. Your installation should begin migrating to FICON Express8S channels.
    • FICON Express4 4KM LX. Your installation should begin migrating to FICON Express8S channels.
    • OSA Express2. Your installation should begin migrating to OSA-Express4S (GbE LX and SX, 1000BASE-T, 10 GbE LR and SR).
    • ESCON. Your installation should begin migrating to FICON Express8S channels.
    • Dial up modems. The currently available Network Time Protocol (NTP) server option for ETS, as well as Internet time services available using broadband connections, can be used to provide the same degree of accuracy as dial-up time services. You should begin migrating from dial-up modems to broadband for RSF connections.
    Carry forward hardware features.

    The following hardware features are not orderable on zEC12 or zBC12 servers. If they are installed on your existing server at the time of an upgrade to a zEC12 or zBC12 server, they can be retained or carried forward.

    • ISC-3. Your installation should begin migrating from ISC-3 features (#0217, #0218, #0219) to 12x InfiniBand (#0163 - HCA2-O or #0171- HCA3-O fanout) or 1x InfiniBand (#0168 - HCA2-O LR or #0170 - HCA3-O LR fanout) coupling links.
    • FICON Express4 10KM LX. Your installation should begin migrating to FICON Express8S channels.
    • FICON Express4 SX. Your installation should begin migrating to FICON Express8S channels.
    • Crypto Express3.

    For information about supported storage controllers, see the workflow step "Ensure that you are using supported servers, storage controllers, and machine facilities."

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.4.3 : Actions you can take before you order a zEC12 or zBC12 server


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

You can perform the following upgrade actions before you order or install a zEC12 or zBC12 server:

  1. Review the sysplex configuration in which the zEC12 or zBC12 server will participate. See the workflow step called "Restrictions for a zEC12 or zBC12 server" for the limitations of using zEC12 or zBC12 servers with certain earlier servers in a Parallel Sysplex.
  2. Implement STP (or a Mixed-CTN) timing network. This action is necessitated because Sysplex Timers (9037-002) are not supported on zEC12 or zBC12 servers.
  3. Migrate from ICB-4 to InfiniBand coupling links. This action is necessitated because ICB-4 links are not supported on zEC12 or zBC12 servers. If desired, you can take this action after you order a zEC12 or zBC12 server, as you upgrade to the new server.
  4. Migrate from unsupported hardware features to newer technology. This action is necessitated because FICON Express, FICON Express2, Crypto Express2, and OSA-Express2 10 GbE LR are not supported on zEnterprise servers. See the following steps in this workflow:
    • "Restrictions for a zEC12 or zBC12 server"
    • "Replace unsupported devices"
    • "Provide for new device installations"
  5. Install the necessary z/OS service, as indicated in PSP buckets.
    • For an IBM zEnterprise BC12 CPC, PTFs are identified in the in the 2828DEVICE PSP bucket ( Subset 2828/ZOS).
    • For an IBM zEnterprise EC12 CPC, PTFs are identified in the 2827DEVICE PSP bucket ( Subset 2827/ZOS).
    • For an IBM zEnterprise BladeCenter Extension (zBX) attached to your zEC12 CPC or zBC12 CPC, the PTFs are identified in the 2458DEVICE PSP bucket ( Subset 2458/ZOS).
    In each PSP bucket, the content is dependent on the z/OS release you will run on the zEnterprise server. If you reviewed the PSP buckets some time ago, review them again to ensure that any newly identified z/OS service has been installed. To assist you in determining if you have the recommended service (identified in these PSP buckets) installed on your system, you can use the SMP/E REPORT MISSINGFIX command in conjunction with the FIXCAT type of HOLDDATA, as follows:
    1. Acquire and RECEIVE the latest HOLDDATA onto your z/OS system(s). Use your normal service acquisition portals or download the two (2) year HOLDDATA directly from Enhanced HOLDDATA for z/OS. Ensure that you select Full from the Download NOW column (last 730 days) to receive the FIXCAT HOLDDATA, as the other files do not contain FIXCAT HOLDDATA.
    2. Run the SMP/E REPORT MISSINGFIX command on your z/OS systems and specify one or more of the following Fix Categories (FIXCAT):
      • IBM.Device.Server.zEC12-2827
      • IBM.Device.Server.zEC12-2827.Exploitation
      • IBM.Device.Server.zEC12-2827.ParallelSysplexInfiniBandCoupling
      • IBM.Device.Server.zEC12-2827.ServerTimeProtocol
      • IBM.Device.Server.zEC12-2827.zHighPerformanceFICON
      • IBM.Device.Server.zEC12-2827.UnifiedResourceManager
      • IBM.Function.zEDC
      • IBM.Device.Server.zBC12-2828
      • IBM.Device.Server.zEC12-2828.Exploitation
      • IBM.Device.Server.zBC12-2828.ParallelSysplexInfiniBandCoupling
      • IBM.Device.Server.zBC12-2828.ServerTimeProtocol
      • IBM.Device.Server.zBC12-2828.zHighPerformanceFICON
      • IBM.Device.Server.zBC12-2828.UnifiedResourceManager

      The report will identify any missing coexistence and fallback PTFs for that system. For complete information about the REPORT MISSINGFIX command, see z/OS SMP/E Commands.

    3. Periodically, you might want to acquire the latest HOLDDATA and rerun the REPORT MISSINGFIX command to find out if there are any new PTFs recommended for the zEnterprise servers.
    Notes:
    1. You can also use Service Link's PSP Service Extraction tool.
    2. Because the Enhanced PSP Tool (EPSPT) was removed the end of 2010, you can no longer use that tool to identify missing PSP bucket service. You should use SMP/E Fix Category support, which is fully integrated into SMP/E procedures and IBM product and service deliverables.
  6. Run the CFSIZER tool. If you are moving your coupling facilities and the coupling facility structures will be on a higher CFLEVEL than they were previously, run the Coupling Facility Structure Sizer (CFSIZER) tool to find out if you have to increase coupling facility structure sizes.

    If ordered before September 2013, zEC12 servers initially ship with CFLEVEL 18. For zEC12 and zBC12 servers ordered after September 2013, the servers ship with CFLEVEL 19; prepare to make the necessary changes as indicated by the tool.

    You can download the CFSIZER tool at Coupling Facility sizer. Also see the workflow step called "Update your CFRM policy with coupling facility structure size changes."

    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 CFSizer Alternate Sizing Techniques.

  7. Decide on the steps you will take for your migration to a zEC12 or zBC12 server. In addition to the actions listed in the workflow step called "Actions you can take before you order a zEC12 or zBC12 server," also see the workflow step "Migration and exploitation considerations for zEC12 and zBC12 server functions." Also, note the following web deliverables considerations.

    The level of function provided for cryptographic support differs by z/OS release and the ICSF web deliverable that is installed. Toleration PTFs are also available for some cryptographic web deliverables:

    Consider the following:

    • For z/OS V1R13 and z/OS V2R1, if you require the cryptographic enhancements support for CCA (including Export TDES key under AES transport key, Diversified Key Generation CBC, IPEK, RKX key wrapping method, and integration of UDX into CCA), you must install the web deliverable Cryptographic Support for z/OS V1R13-z/OS V2R1 (FMID HCR77A1). You must also perform the required ICSF upgrade actions.
    • PTFs for coexistence: Coexistence PTFs must be installed on older levels of ICSF. To assist in identifying the coexistence service, you can use the following Fix Categories:
      • IBM.Coexistence.ICSF.z/OS_V1R11-V1R13-HCR7790
      • IBM.Coexistence.ICSF.z/OS_V1R12-V1R13-HCR77A0
      • IBM.Coexistence.ICSF.z/OS_V1R13-V2R1-HCR77A1

    If you plan to use the IBM zEnterprise Data Compression (zEDC) feature, you must enable it, similar to enabling other z/OS priced features. To do so, you must:

    • Notify IBM that you are using the feature
    • Update the IFAPRDxx PARMLIB member to specify that the z/OS ZEDC software feature is enabled
    • Follow the z/OS documentation to customize the exploiting functions.

    You should also ensure that all z/OS V1R13 systems that will access zEDC compressed data have the required toleration maintenance installed to enable software decompression.

  8. Review the new mnemonics introduced for the zEC12 or zBC12 server. The new mnemonics might collide with (be identical to) the names of assembler macro instructions you use or provide. In the event of such collisions, the HLASM default opcode table (UNI) treats specification of these names as instructions when APAR PM49761 and PM86821 are installed. This will probably cause assembler error messages and possibly cause generation of incorrect object code.

    If you write programs in Assembler Language, you should compare the list provided in z/Architecture Principles of Operation, SA22-7832 to the names of assembler macro instructions you use or provide, to identify any such conflicts or collisions that would occur following installation of HLASM APAR PM49761 and PM86821. If a conflict is identified, take one of the following actions:

    • Change the name of your macro instruction.
    • Specify PARM='...OPTABLE(YOP)...' (or some other earlier opcode table).
    • Specify a separate ASMAOPT file containing assembler options, such as in the previous method (this method requires no changes to source code or JCL).
    • Add, as the first statement of your source program, *PROCESS OPTABLE(YOP).
    • Specify the PROFILE option either in JCL or the ASMAOPT file, and the specified or default member of the SYSLIB data set is copied into the front of the source program.
    • If you must use both a new instruction and a macro with the same name in an assembly, you can use the following technique (where XXX is a sample mnemonic):
      Assume the default OPTABLE(UNI) is in effect XXX a,b new instruction PUSH ACONTROL save current optable definition ACONTROL OPTABLE(YOP) switch optable dynamically XXX r,s,t macro invocation POP ACONTROL restore previous definition XXX c,d new instruction

    For more information about HLASM opcode table, see HLASM Programmer's Guide, which is available at High Level Assembler and Toolkit Feature in IBM Knowledge Center.

  9. Plan for changes to your global resource serialization complex with the zEC12 or zBC12 server. If you use a global resource serialization ring complex that spans more systems than is part of the sysplex or does not use sysplex signaling for communications within the complex, you need to take upgrade actions. Instead of using global resource serialization ring, consider using the global resource serialization star configuration in a sysplex. You can take the following actions before you install the zEC12 or zBC12 server:
    • Migrate to a Parallel Sysplex that uses the recommended global resource serialization star complex.
    • Convert to a basic sysplex that uses XCF sysplex signaling with global resource serialization ring instead of GRS-managed channel-to-channel (CTC) communications.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.4.4 : Migration and exploitation considerations for zEC12 and zBC12 server functions


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Consider the number of CPU measurement facility counters for zEC12 or zBC12. The number of CPU measurement facility counters for zEC12 and zBC12 is increased to 128. More extended counters means that more internal storage is required. Though the structure of the SMF 113 record does not change, the values, interpretations, and frequency of certain sections do change; therefore, current tools using the data must be updated for the zEC12 or zBC12.

For example, consider the following SMF record field:

  • SMF113_2_CtrVN2 identifies how to interpret the Crypto and Extended counter sets. As described in The IBM CPU Measurement Facility Extended Counters Definition for z10 and z196, SA23-2260, this field is set to 1 (for z10), 2 (for z196 or z114), or 3 (for zEC12 and zBC12).
Note:

As of z/OS V2R1, if you use the CPU Measurement Facility, IBM recommends that your installation collect SMF 113 subtype 1 and 2 records. IBM also recommends that products process SMF 113 subtype 1 records when available, because that is where future enhancements will be made. If subtype 1 records are not available, products can process subtype 2 records.

The following zEC12 and zBC12 functions are available on z/OS V2R1. For PTF information, see the table notes for "Server functions that can be exploited in z/OS V2R2, z/OS V2R3, and z/OS V2R4."

  1. CFLEVEL 19 Coupling thin interrupt support. With PTFs CFLEVEL 19 provides Coupling thin interrupt support that allows a shared logical coupling facility partition to be dispatched by PR/SM if not already dispatched and allows for more timely processing of events to which the CF must respond. It is designed to improve service times for shared engine coupling facilities, and to help improve the response time for asynchronous CF operations. This function requires CFLEVEL 19.
  2. Cryptographic Enhancements. Cryptographic enhancements for z/OS V2R1 on zEC12 and zBC12 server include:
    • Crypto Express4S CCA enhancements when the PCIe adapter is configured as CCA coprocessor including: Export TDES key under AES transport key, Diversified Key Generation CBC, IPEK, RKX key wrapping method, and Integration of UDX into CCA requires z/OS V2R1 with the Cryptographic Support for z/OS V1R13-z/OS V2R1 Web deliverable (FMID HCR77A1) installed.
    • Crypto Express4S EP11 enhancements when the Crypto Express4S PCIe adapter is configured as an EP11 coprocessor including: (PKCS #11 V2R1 PSS, EP11 Key agreement algorithms, and Offload Generation of Domain Parameters) and requires z/OS V2R1 with the Cryptographic Support for z/OS V1R13-z/OS V2R1 Web deliverable (FMID HCR77A1) to be installed.
    • Crypto Express4S (#0865) exploitation including Enterprise Security PKCS #11-Hardware Security Module (HSM), DUKPT for MAC and Data Encryption, Cipher Text Translate CCA Verb, PKDS/TKDS Constraint Relief, Random Number Cache, FIPS on Demand, and Wrapping Keys with Strong Keys.

    See Decide on the steps to take for your migration to a zEC12 or zBC12 server in the workflow step called "Actions you can take before you order a zEC12 or zBC12 server."

  3. zEDC capability using zEDC Express. zEDC provides IBM zEnterprise data compression/decompression capability. For z/OS V2R2, the zEDC software feature must be enabled with your product enablement policy (IFAPRDxx); then follow the z/OS V2R2 documentation to customize the exploiting functions.
  4. IBM zAware system. The IBM zAware feature is designed to offer a near real-time, continuous learning, and diagnostics capability intended to help you pinpoint and resolve potential problems quickly enough to minimize impacts to your business. After you order a zEC12 or zBC12, you can prepare to set up an IBM zAware environment by defining the IBM zAware logical partition (LPAR), defining and using OPERLOG log streams, and network definitions to connect the z/OS LPAR to the IBM zAware LPAR. For more information, see IBM z Advanced Workload Analysis Reporter (IBM zAware) Guide, (SC27-2623) and z/OS MVS Setting Up a Sysplex.
  5. Java Exploitation of Transactional Execution (requires Java 7 SR3). This function provides support for Java exploitation of the Transaction Execution Facility on IBM zEnterprise zEC12 or zBC12. Transactional Execution will offer increased scalability and parallelism to drive higher transaction throughput. Java exploitation is planned with
    • IBM 31-bit SDK for z/OS, Java Technology Edition, V7.0.0 (5655-W43)
    • IBM 64-bit SDK for z/OS, Java Technology Edition, V7.0.0 (5655-W44).
    Note:

    Using z/OS V1R13 XL C/C++ compiler and later, specify ARCH(10) to provide the hardware with built-in functions to enable applications to use the Java Transactional Execution Facility.

  6. Flash Express (Storage Class Memory or SCM). This support includes pageable 1 MB Large Page support, dynamic reconfiguration support of SCM, and optional PLPA/COMMON page data set usage. This support requires the Flash Express hardware feature.
  7. 2GB Large Page support. This support includes support for 2 GB large fixed pages.
  8. CFLEVEL 19 Flash Express. This exploitation will provide improved resilience for MQ shared queues. The function requires CFLEVEL 19 and is planned to be available in a future update.
  9. New z/Architecture instructions: XL C/C++ ARCH(10) and TUNE(10) parameters. This function provides new zArchitecture instructions.
  10. Shared Memory Communications using RDMA (SMC-R) exploitation. Shared Memory Communication using RDMA (Remote Direct Memory Access) enables transparent exploitation of RDMA technology for TCP/IP sockets based applications. It requires the 10 GbE RoCE Express hardware feature.
  11. 24k subchannels per channel (port) for the FICON Express features. This is planned to help facilitate growth as well as continuing to enable server consolidation. You will be able to define more devices per FICON channel, which includes primary, secondary, and alias devices. This support applies to the FICON Express8S, FICON Express8, and FICON Express4 features when defined as CHPID type FC.
  12. OSA-Express5S. OSA-Express5S provides a new generation of Ethernet features for use in the PCIe I/O drawer and continues to be supported by the 8 GBps PCIe Gen2 host bus. This support includes: 1000BASE-T Ethernet for copper environments, in addition to 10 Gigabit Ethernet (10 GbE) and Gigabit Ethernet (GbE) for single-mode and multimode fiber optic environment.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.4.5 : Accommodate functions for the zEC12 and zBC12 servers to be discontinued on future servers


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The following changes in hardware support could affect your environment. Make the appropriate changes as needed.

  • Removal of support for connections to an STP Mixed CTN. The zEC12 and zBC12 are the last IBM Z® servers to support connections to an STP Mixed CTN. This also includes the Sysplex Timer (9037). After the zEC12 and the zBC12, servers that require Time synchronization, such as to support a base or Parallel Sysplex, will Require Server Time Protocol (STP) and all servers in that network must be configured in STP-only mode.
  • Removal of support for Ethernet half-duplex operation and 10 Mbps link data rate. The OSA-Express4S 1000BASE-T Ethernet feature is planned to be the last copper Ethernet feature to support half-duplex operation and a 10 Mbps link data rate. The zEC12 and zBC12 servers are planned to be the last IBM Z® servers to support half-duplex operation and a 10 Mbps link data rate for copper Ethernet environments. Any future 1000BASE-T Ethernet feature will support full-duplex operation and auto-negotiation to 100 or 1000 Mbps exclusively. This hardware statement of direction is fulfilled with the delivery of OSA-Express5S.
  • Removal of ISC-3 support on IBM Z®. The zEC12 and zBC12 are planned to be the last IBM Z® servers to offer support of the InterSystem Channel-3 (ISC-3) for Parallel Sysplex environments at extended distances. ISC-3 will not be supported on future IBM Z® servers as carry forward on an upgrade. Previously, it was announced that the IBM zEnterprise 196 (z196) and IBM zEnterprise 114 (z114) servers were the last to offer ordering of ISC-3. Enterprises should continue upgrading from ISC-3 features (#0217, #0218, #0219) to 12x InfiniBand (#0171 - HCA3-O fanout) or 1x InfiniBand (#0170 - HCA3-O LR fanout) coupling links.
  • Removal of OSA-Express3 support on IBM Z®. The zEC12 and zBC12 servers are planned to be the last IBM Z® servers to offer support of the Open System Adapter-Express3 (OSA-Express3 #3362, #3363, #3367, #3370, #3371) family of features. OSA-Express3 will not be supported on future IBM Z® servers as carry forward on an upgrade. Enterprises should continue upgrading from the OSA-Express3 features to the OSA-Express4S (#0404, #0405, #0406, #0407, #0408) and OSA-Express5S features (#0413, #0414, #0415, #0416, #0417).
  • Removal of FICON Express4 support on IBM Z®. The zEC12 and zBC12 servers are planned to be the last IBM Z® servers to offer support of the FICON Express4 features (#3321, #3322). FICON Express4 will not be supported on future IBM Z® servers as carry forward on an upgrade. Enterprises should continue upgrading from the FICON Express4 features to the FICON Express8S features (#0409, #0410).
  • Removal of Crypto Express3 support on IBM Z®. The zEC12 and zBC12 servers are planned to be the last IBM Z® servers to offer support of the Crypto Express3 features (#0864 and #0871 - zBC12). Crypto Express3 will not be supported on future IBM Z® servers as carry forward on an upgrade. Enterprises should continue upgrading from the Crypto Express3 features to the Crypto Express4S feature (#0865).
  • IBM z Integrated Information Processor (zIIP) and IBM zEnterprise Application Assist Processor (zAAP) simplification. The zEC12 and zBC12 are planned to be the last IBM Z® servers to offer support for zAAP specialty engine processors. IBM intends to continue support for running zAAP workloads on zIIP processors ( zAAP on zIIP). This change is intended to help simplify capacity planning and performance management, while still supporting all the currently eligible workloads.
  • Removal of support for the HCA2-O fanouts for 12x IFB and 1x IFB InfiniBand coupling links. The zEC12 and zBC12 are planned to be the last IBM Z® servers to support the following features as carry forward on an upgrade: HCA2-O fanout for 12x IFB coupling links (#0163) and HCA2-O LR fanout for 1x IFB coupling links (#0168). Enterprises should continue upgrading to the HCA3-O fanout for 12x IFB (#0171) and the HCA3-O LR fanout for 1x IFB (#0170).
  • Removal of support for IEEE 802.3 Ethernet frame types. The zEC12 and zBC12 are planned to be the last IBM Z® servers to support IEEE 802.3 Ethernet frame types. All OSA-Express features supported on future IBM Z® servers are planned to support DIX Version 2 (DIX V2) exclusively.
Note:

IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

  • 28 August 2012 in U.S. Announcement Letter for the zEC12.
  • 23 July 2013 in U.S. Announcement Letter for the zBC12.

Applies to migration from:

z/OS V2R2.

Timing:

Before upgrading to a zEC12 or zBC12 server.

Is the upgrade action required?

No, but recommended if you are using a zEC12 or zBC12 server because this is the last IBM Z® server that will support the changes that are mentioned in Description.

Target system hardware requirements:

See "Description."

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Consider the statements in "Description" as you migrate to zEC12 or zBC12.

Reference information

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.5 : Ensure that you are using supported servers, storage controllers, and machine facilities


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

z/OS V2R4 is supported on the following IBM Z® servers:

  • IBM z14™ (z14) models M01 through M05
  • IBM z14™ Model ZR1 (z14 ZR1)
  • IBM z13
  • IBM z13s™
  • IBM zEnterprise EC12 (zEC12)
  • IBM zEnterprise BC12 (zBC12)
z/OS V2R4

supports these and later IBM storage control units:

  • 3990 Model 3 and 3990 Model 6
  • 9393
  • 2105
  • 2107
  • 2421
  • 2422
  • 2423
  • 2424

z/OS uses particular machine facilities on these servers, depending on the z/OS release. Though additional machine facilities might be available on a server, it does not mean that z/OS supports those facilities. For a list of the machine facilities that are supported for each release of z/OS, see z/OS Planning for Installation.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

z/OS V2R4

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Anytime

Is the upgrade action required?

Yes, if you use any of the servers, controllers, or machine facilities that are no longer supported to run with z/OS V2R4.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

  • During IPL/NIP processing, if you try to use an unsupported control unit for z/OS V2R4, you receive the following error condition for devices under the control unit.
    IEA434I (nnnn) ONLINE IS NOT ALLOWED, INVALID CONTROL UNIT MODEL

    During VARY ONLINE command processing after IPL/NIP, you receive the following error condition for devices under the unsupported control unit:

    IEA434I DEVICE ONLINE IS NOT ALLOWED, INVALID CONTROL UNIT MODEL
  • If you IPL z/OS V2R4 on a server that it does not support, you might receive wait state 07B-1E (decimal 30). Note:

    The number of IEA434I messages is limited to 32 during IPL/NIP to avoid exhausting initial ESQA. An IEA444I message is reported one time during IPL/NIP to indicate that more IEA434I messages are suppressed:

    IEA444I NUMBER OF IEA434I MESSAGES EXCEEDS NIP MAXIMUM

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  1. Determine whether the servers, control units, and machine facilities that you use are supported for z/OS V2R4. If you have a question about support for any hardware that are not listed, contact your IBM representative.
  2. Install replacement servers and control units. Detach unsupported servers and control units from the system and delete their corresponding definitions from the input/output definition file (IODF).

Reference information

For more information, see the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.6 : Enable BCPii communications on the support element


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

It is necessary to grant authority on the support element (SE) to allow the support element to accept the BCPii APIs flowing from the user application through the HWIBCPii address space. With this enablement, a logical partition can issue a subset of control program instructions to other logical partitions that are activated on the same CPC.

For Support Elements that run on z14, the method for enabling cross-partition authority is changed from previous IBM Z® servers. The setting of the cross-partition authority checkbox is replaced by new security settings in the Hardware Management Console (HMC) and the Support Element (SE), as follows:

  • CPC permission is now specified by using the System Details task.
  • Image (LPAR) permission is now specified by using the Image Activation Profile or the Change LPAR Security task.

These new security controls allow for more granular control for specifying BCPii send and receive capabilities. For example, you can enable all partitions or a subset of partitions to receive BCPii requests.

For previous IBM Z® servers, you enabled cross-partition authority by selecting the cross-partition checkbox. You selected this option on the local SE for the CPC of the image that the z/OS BCPii application is running on, plus any other systems for which BCPii communication was required.

This table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple

When change was introduced:

IBM z14, which became available September 2017.

Applies to migration from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes, if you are migrating from an earlier IBM Z® server to the z14, and you want to maintain the same BCPii permissions on the z14.

Target system hardware requirements:

IBM z14 server.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

To maintain the same permissions:

If you are migrating from an earlier IBM Z® server to the z14, and you want to maintain the same BCPii permissions on the z14, you can port (export/import) your definitions to the new server. Then, perform the following steps on the HMC:

  1. Select Systems Management
  2. Select the CPC that is required.
  3. Click the System Details task.
  4. Click the Security tab to display the default settings.
    • To grant authority to all partitions on all CPCs to issue BCPii calls against this CPC, ensure that the following options are selected:
      1. Enable the system to receive commands from partitions
      2. All partitions
  5. Select CPC Operational Customization > Change LPAR Security. For each LPAR that was identified to support BCPii on the pre-z14 machine, click the current BCPii enablement level in the BCPii Permissions column and perform the following:
    • Ensure that the option Enable the partition to send commands is selected to grant authority for this LPAR to send BCPii requests to other CPCs and LPARs.
    • Ensure that the option Enable the partition to receive commands from other partitions is selected to allow other LPARs to target this LPAR with BCPii requests.
    • Ensure that the option All partitions is selected, which grants all partitions on all CPCs permission to issue BCPii calls against this LPAR.

To use more granular permissions: If you are migrating from an earlier IBM Z® server, and you want to use more granular BCPii permissions on the z14, you can select individual partitions by using the Selected partitions option for both CPC and LPAR authority.

To disable permissions:

If you do not want to enable BCPii permissions on the z14, perform the following steps on the HMC:

  1. Select Systems Management
  2. Select the CPC that is required.
  3. Click the System Details task.
  4. Click the Security tab to display the default settings.
  5. To deny authority to LPARs to issue BCPii calls against this CPC, ensure that the option Enable the system to receive commands from partitions is not selected.

If your installation has just a few LPARs for which to disable permissions, consider the following steps:

  • Select CPC Operational Customization > Change LPAR Security. For each LPAR that is not disabled, select the BCPii enablement level in the BCPii Permissions column and do the following:
    1. Deselect the option Enable the partition to send commands. This action denies authority for this LPAR to send BCPii requests to other CPCs and LPARs.
    2. Deselect the option Enable the partitions to receive commands from other partitions. This action prevents other LPARs from sending BCPii requests to this LPAR.

If your installation has multiple LPARs for which to disable BCPii permissions, consider changing multiple Image Activation Profiles at one time. To do so, follow these steps:

  1. Select CPC Operational Customization > Customize/Delete Activation Profiles
  2. Select multiple images for which you want to change the BCPii permissions.
  3. Select the option Customize profile.
  4. Select Next until the Security page is shown.
  5. For BCPii permissions, select Apply to all profiles and deselect the options Send and Receive.
  6. Select Next until Summary is shown. Review your changes.
  7. If the settings are correct, select Finish to save your changes. Otherwise, if the settings are not correct, select Back to return to the tasks and make corrections. Or, select Cancel to end your session.

Reference information

For more information, see the following references:

  • Support Element Operations Guide
  • zEnterprise System Processor Resource/Systems Manager Planning Guide.

These books are included in the IBM z15 Library, which is available online in Resource Link™.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.7 : Replace unsupported devices


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

You should remove and replace devices that were supported by earlier releases but cannot be used with the current release of z/OS because they are no longer supported.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

V2R3 and V2R2.

Timing:

Anytime.

Is the upgrade action required?

Yes, if you use any of the devices that are no longer supported.

Target system hardware requirements:

Replacement devices as necessary.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  1. Determine whether the I/O devices you use are supported. A list of supported IBM devices is in the topic about identifying I/O device requirements in z/OS Planning for Installation. If you have a question about support for any devices not listed, contact your IBM representative.
  2. Install replacement devices. Move data that is stored on unsupported devices to the supported devices. Detach unsupported devices from the system and delete their corresponding device definitions from the input/output definition file (IODF).

Reference information

For more information, see the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.8 : Provide for new device installations


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The hardware configuration of your processors and I/O devices determines how many devices you can attach to your system. z/OS supports attachment of up to 65,280 devices in Subchannel Set 0, each with eight access paths, and the attachment of up to 64,000 secondary devices in each additional subchannel set.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

V2R3 and V2R2.

Timing:

Anytime.

Is the upgrade action required?

Yes, if you are going to use new devices with z/OS V2R4 and later.

Target system hardware requirements:

Dependent upon the new devices used.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

The following are general considerations related to I/O device support.

  • Attaching devices through HCD. You can define, or attach, new devices to your system through the interactive panels of the Hardware Configuration Definition (HCD) base element. HCD has dynamic I/O capabilities, changing hardware definitions without the need for an IPL or hard power-on reset.

    Any time you make changes to your I/O configuration, you need to use HCD to modify your system's I/O definition file (IODF). You should also update the input/output configuration data set (IOCDS) when you run HCD to ensure that the configuration information is consistent across the software and microcode.

  • Operating modes. Most devices attached to z/OS operate in full function mode, that is, all features on the device are compatible with, and usable on, the operating system. Some of these features include:
    • For DASD devices: dynamic path reconnection, extended count-key-data operation, and caching and cache-related facilities
    • For tape devices: cartridge stack loading and data compaction.

    Some devices also operate in compatibility mode, which allows you to simulate the function of another device or model. Compatibility mode causes the device to function like a different device of the same type, ignoring some or all of the additional features the device might have. This allows you to migrate between devices with minimal impact on programs that have device dependencies.

  • UCB virtual storage constraint relief. Each device attached to the system has one or more UCBs associated with it. The size of the I/O configuration and placement of UCBs affects the amount of available virtual memory, both below 16MB and below 2GB. For more information, see the description of the LOCANY parameter in z/OS HCD Planning and the topic "Module placement effect on virtual storage" in z/OS MVS Initialization and Tuning Guide. The system programmer should review the contents of the link pack area (LPA) list to determine whether to remove or move libraries to gain virtual storage constraint relief.
  • Hardware maintenance. Some devices require a specific level of hardware maintenance to operate properly on a z/OS system. DFSMS software support for new hardware devices might also require the installation of PTFs.

Reference information

For more information, see the following references:

  • For a summary of the most commonly-used I/O devices supported by z/OS that are also directly supported by DFSMS functions, see the topic about identifying I/O devices in z/OS Planning for Installation. If you have a question about support for a device that is not listed, contact your IBM representative.
  • For more information about HCD, see z/OS HCD Planning.
  • For information about working with IODFs, see z/OS HCD User's Guide.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 3.2.9 : Update your CFRM policy with coupling facility structure size changes


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

If you are upgrading to a new coupling facility control code level (CFLEVEL), you must make the appropriate coupling facility structure size updates in the z/OS coupling facility resource management (CFRM) policy.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Multiple.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

V2R3 and V2R2.

Timing:

Anytime.

Is the upgrade action required?

Yes, if you are upgrading to a new CFLEVEL.

Target system hardware requirements:

For information about coupling facility code levels and the processors that support those levels, see Coupling Facility Level (CFLEVEL) Considerations.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

If you are upgrading to a new CFLEVEL, do the following:

  1. Run the Coupling Facility Structure Sizer (CFSizer) tool. This tool sizes structures based on the amount of space needed for the current CFLEVEL. The tool sizes for the most currently available level; you might find that the results are oversized if you use an earlier CFLEVEL. You can find the tool at Coupling Facility sizer.

    Alternatively, you can run an as-is batch utility program that is called SIZER after you bring a new CFLEVEL coupling facility into use in your configuration. SIZER examines your currently allocated coupling facility structures and recalculates the size that should be used for them with the new later-CFLEVEL coupling facility. The as-is SIZER utility is available as a compressed package that you can download from CFSizer Alternate Sizing Techniques.

  2. Update the CFRM policy with the size modifications that are needed.
  3. Activate the updated CFRM policy so that it becomes the active policy that governs structure allocation in the sysplex.

Reference information

Coupling facility code levels have hardware and software requirements. For more information, see Coupling Facility Level (CFLEVEL) Considerations.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4 : Upgrading from z/OS V2R3


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This level of the z/OS Upgrade Workflow corresponds to z/OS V2R4.


Step 4.1 : BCP upgrade actions


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes upgrade actions for the base element BCP (Base Control Program).


Step 4.1.1 : BCP actions to perform before installing z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes BCP upgrade actions that you can perform on your current (old) system. You do not need the z/OS V2R4 level of code to make these changes, and the changes do not require the z/OS V2R4 level of code to run once they are made.


Step 4.1.1.1 : BCP: The ASCB and WEB are backed in 64-bit real storage by default


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

In a future release of z/OS, the address space control block (which is mapped by IHAASCB) and the work element block (which is mapped by IHAWEB) will be backed in 64-bit real storage by default. Currently, these data structures are backed in 31-bit storage, unless your DIAGxx parmlib member specifies CBLOC REAL31(IHAASCB,IHAWEB).

In z/OS 2.4, the keywords REAL31 and REAL64 are added to the CBLOC statement of parmlib member DIAGxx. With these keywords, you can specify which data structures are backed in 31-bit real storage or 64-bit real storage.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP.

When change was introduced:

z/OS V2R4.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended if you have an application that relies on the ASCB or WEB to be in 31-bit storage.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Check for programs that issue the load real address (LRA) instruction in 31-bit addressing mode for the ASCB or WEB data structures. The LRA instruction cannot be used to obtain the real address of locations backed by real frames above 2 gigabytes in 24-bit or 31-bit addressing mode. For those situations, use the LRAG instruction instead of LRA.

The TPROT instruction can be used to replace the LRA instruction when a program is using it to verify that the virtual address is translatable and the page backing it is in real storage.

If you have programs that do not tolerate 64-bit real storage backing for the ASCB or WEB data structures, update the DIAGxx parmlib member to specify CBLOC REAL31(IHAASCB,IHAWEB).

Reference information

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.1.2 : BCP: Plan for removal of support for the IEWTPORTS transport utility


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

z/OS V2R4 is the last release of z/OS that will include the transport utility, IEWTPORT. This program management binder utility converts a program object in a PDSE into a "transportable program file" in a sequential (nonexecutable) format and conversely can also reconstruct the program object from a transportable program file and store it back into a PDSE. The use of this utility has been discouraged for a number of years, as described in z/OS MVS Program Management: User's Guide and Reference.

The appropriate utility for copying load modules and program objects is the IEBCOPY.IEWTPORTS transport utility.

In a future release, z/OS will not include the IEWTPORTS transport utility.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP

When change was introduced:

z/OS V2R4. Also, see IBM United States Software Announcement 220-226, dated June 16, 2020

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended if you use the IEWTPORTS transport utility.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

If your installation currently uses the IEWTPORTS transport utility, update your procedures to use the IEBCOPY.IEWTPORTS transport utility instead. After z/OS V2R4, z/OS will not include the IEWTPORTS transport utility.

Reference information

For more information, see z/OS MVS Program Management: User's Guide and Reference.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.1.3 : BCP: Recompile programs with the new IRARMCTZ macro in APAR OA55218


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

In z/OS V2R3, several fields in the IRARMCTZ control block were moved to incorrect offsets. APAR OA55218 corrects the offsets of these fields.

After you apply the PTF for APAR OA55218, you must recompile any programs that use the affected fields in the IRARMCTZ control block.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP

When change was introduced:

z/OS V2R3 with APAR OA55218 applied.

Applies to upgrade from:

z/OS V2R3 (without APAR OA55218 applied) and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes, if you have programs that use the affected fields in the IRARMCTZ control block.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Check your programs for any use of the following fields in the IRARMCTZ control block:

  • RMCTZ_WLMIRDSTRUC
  • RMCTZ_FLAGS
  • RMCTZ_WLMIRDSTRUC_SET
  • RMCTZ_RTCapLeadTime
  • RMCTZ_Time_To_Cap
  • RMCTZ_Time_To_Cap_Group

After you apply the PTF for APAR OA55218, recompile any affected programs with the new version of the IRARMCTZ macro. The macro version ( RMCTZ_Version) is updated to Version 6 by this APAR.

Reference information

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.1.4 : BCP: Stop using z/OS Batch Runtime


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

As of z/OS V2R4, support is removed for z/OS Batch Runtime. This component provided a framework for interoperability between PL/I, COBOL, and Java applications that run on z/OS. It was 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.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP

When change was introduced:

z/OS V2R4.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes, if you use z/OS Batch Runtime.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  1. Determine whether your programs use z/OS Batch Runtime. Check for references to:
    • JCL PROC BCDPROC
    • BCDBATCH
    • Java classes in com.ibm.zos.batch.container.BCDBatchContainer.
  2. If your programs use z/OS Batch Runtime, you must modify them to use the WebSphere JSR 352 compliant container. Running the programs requires that WebSphere Application Server is installed.

Reference information

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.1.5 : BCP: Evaluate your stand-alone dump data set allocations and your IPCS processing of them


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

As your applications grow in size and use greater amounts of storage, you should evaluate whether the DASD allocated for your stand-alone dump data continues to be adequate.

In z/OS V1R6, support was introduced for extended-format sequential data sets, a form of data set that is SMS-managed and can occupy more than 64 K tracks per volume. In z/OS V1R7, this support was supplemented with support for large format sequential data sets (DSNTYPE=LARGE), a form of data set that is essentially the same as conventional sequential data sets except that more than 64 K tracks may be spanned per volume. If your stand-alone dump data sets are spread over more volumes than you want, both types of support can help you gain better control over the number of volumes used for each stand-alone dump data set.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended because of changes that have been made to stand-alone dump processing (that reorder dump records with the intent of recording more important data early), and especially recommended if you deploy any LPARs with significantly more main storage than previously used.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  • Use multivolume stand-alone dump data sets. Adjust the number of volumes and their separation to achieve tolerable stand-alone dump capture times.
  • Use extended-format sequential data sets or large format sequential data sets. Copy their contents to an extended-format, compressed, striped data set using the IPCS COPYDUMP subcommand before analysis. Use the same or a larger striping factor than you used for your stand-alone dump data sets. Dump data sets to which stand-alone dump can write may be neither compressed nor striped, but both attributes are advantageous for the target of the copy operation. Starting with z/OS V1R12, stand-alone dump data sets can be placed in track-managed space as well as cylinder-managed space on Extended Address Volumes (EAV).
  • Use a large CISIZE and striping for IPCS dump directories, and use blocking, striping, and compression for the stand-alone dump data set. Very large stand-alone dumps might require that you define your directory with the extended addressing attribute, allowing it to hold more than 4 GB. Tip:

    Control interval sizes less than 24K have been shown to be more vulnerable to fragmentation when used as IPCS dump directories, and IPCS performance can be degraded when such fragmentation occurs. In this background, warning message BLS21110I will be issued and you might recreate the DDIR by using the CLIST BLSCDDIR.

    BLS21110I CISIZE(cisize) is less than 24K. It may degrade IPCS performance

Reference information

For more information, see the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.1.6 : BCP: Regenerate the Unicode conversion image


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

APAR OA50306 introduced extension tables for conversions with code points of length 3 or larger through a PTF on z/OS V2R2 and z/OS V2R1. If your system uses Unicode conversion images that were created before OA50306, you might encounter ABEND 0C4 in module CUN4MCNV or have unexpected output that contains FEFE. This problem can also occur with the base code of z/OS V2R3.

If your system does not use dynamic loading of conversion data ( Unicode on demand), and you have not applied the PTF for APAR OA56812, you must perform this upgrade action.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP.

When change was introduced:

z/OS V2R3. z/OS V2R2 with the PTF for APAR OA50306 applied.

Applies to upgrade from:

z/OS V2R3. z/OS V2R2 without APAR OA50306.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes, if your system uses Unicode conversion images that were generated before OA50306 was applied.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

You might encounter ABEND 0C4 in module CUN4MCNV or have unexpected output that contains FEFE.

Related IBM Health Checker for z/OS check:

None.

Steps to take

If your system performs dynamic loading of conversion data (also known as Unicode on demand), no further action is needed.

To determine whether your system uses dynamic loading of conversion data, check the active CUNUNIxx parmlib member. The UNI parameter of IEASYSxx specifies the CUNUNIxx parmlib member for your conversion environment.

If your system does not use dynamic loading of conversion data, you must do either of the following:

  • Apply the PTF for APAR OA56812. This service makes regenerating the Unicode conversion image unnecessary.
  • Regenerate the Unicode conversion image and IPL your system again.

Reference information

For more information, see the topic about creating a conversion image in z/OS Unicode Services User's Guide and Reference.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.1.7 : BCP: Prepare for the removal of service coefficients from WLM service definitions


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

z/OS V2R4 is the last release of the operating system to support specifying service coefficients in the WLM service definition.

The amount of system resources an address space or enclave consumes is measured in service units. Service units are calculated based on the CPU, SRB, I/O, and storage (MSO) service the address space or enclave consumes.

Service units are the basis for period switching within a service class that has multiple periods. The duration of a service class period is specified in terms of service units. When an address space or enclave running in the service class period has consumed the amount of service that is specified by the duration, workload management moves it to the next period. The work is then managed to the goal and importance of the new period.

Because not all kinds of services are equal in every installation, more weight can be assigned to one kind of service over another. These weights are called service coefficients.

Assigning different weights made sense in the past, when resources like storage and I/O were scarce. However, in today's environments, it does not make sense to allow storage and I/O to influence period switch, or weight CPU and SRB service differently. Therefore, to streamline and simplify user experience, and to facilitate more consistent management, the service coefficients are removed from the WLM service definition, and set to hardcoded defaults.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP.

When change was introduced:

z/OS V2R4. Also, see IBM United States Software Announcement 219-344, dated July 23, 2019.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended because specifying service coefficients in the WLM service definition will not be supported in a future release.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

If the upgrade action is not done, address spaces or enclaves that are running in a service class period might move faster or slower than expected to the next period.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Check the values of the service coefficients in your WLM service definitions. You can do so in z/OSMF on the Service Definition Details tab of the Workload Management task, or in the WLM ISPF application on the Service Coefficients/Options panel.

The recommended values are:

CPU
1.0
IOC
0.0
MSO
0.0000
SRB
1.0

If the values of the service coefficients in your WLM service definition differ from the recommended values, change them to the recommended values. If you do so, you must recalculate the duration of your service class periods, and your accounting procedures.

The capacity limits of resource groups and tenant resource groups are not affected by this change because they are specified in unweighted service units.

Reference information

For more information, see the topic "Defining service coefficients and options" inz/OS MVS Planning: Workload Management.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.2 : BCP actions to perform before the first IPL of z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes BCP upgrade actions that you can perform after you have installed z/OS V2R4, but before the first time you IPL. These actions might require the z/OS V2R4 level of code to be installed, but do not require it to be active.


Step 4.1.2.1 : BCP: Accommodate the new DSLIMITNUM default


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

In the SMFLIMxx parmlib member, the parameter DSLIMITNUM is used to override the maximum number of data spaces and hiperspaces that can be created by a user-key program. Currently, by default, the number of data spaces and hiperspaces is limited to 4294967295. In a future release, this default will be decreased to 4096.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP.

When change was introduced:

z/OS V2R4.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if the default is not acceptable to your environment.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

Applications that invoke DSPSERV CREATE, especially those applications that loop erroneously, might fail with the more restrictive DSLIMITNUM default in effect.

Related IBM Health Checker for z/OS check:

None.

Steps to take

SMF 30 record field SMF30NumberOfDataSpacesHWM indicates the high-water mark of the number of data spaces that are owned by the problem state or user key tasks associated with a job. This field is added with APAR OA59137 and APAR OA59126 applied.

If your installation runs jobs that rely on the default for SMFLIMxx DSLIMITNUM or IEFUSI word 7 subword 3, inspect the SMF 30 record field SMF30NumberOfDataSpacesHWM fields for values that exceed 4096. For jobs that exceed 4096, update SMFLIMxx or IEFUSI to allow the maximum number of data spaces that are required.

Reference information

For more information, see the description of the DSLIMITNUM parameter in z/OS MVS Initialization and Tuning Reference.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.2.2 : BCP: XCF/XES FUNCTIONS XTCSIZE is enabled by default


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

In z/OS V2R4, the FUNCTIONS statement is added to the COUPLExx parmlib member. This statement specifies the initial enablement state of XCF/XES optional functions on the current system. Included on the FUNCTIONS statement is the option XTCSIZE. When enabled, XTCSIZE causes XCF to automatically manage message size segregation when sending messages to a z/OS system. By enabling XTCSIZE, you no longer need to manually configure for message size segregation.

The XTCSIZE keyword is ENABLED by default. You can disable it, if necessary. You can set the state of the FUNCTIONS statement dynamically by using the SETXCF FUNCTIONS system command.

The status of the XTCSIZE option does not impact XCF message traffic that includes systems earlier than z/OS V2R4. Existing XCF transport class definitions do not need to be changed.

Removing transport class definitions for message size segregation should not be done until all systems in the sysplex are z/OS V2R4 or later and you have no plans to fall back to an earlier release.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP.

When change was introduced:

z/OS V2R4.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

No, but recommended. Disabling XTCSIZE is possible, but not recommended.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

Health check IBMXCF,XCF_TCLASS_CLASSLEN is enhanced to check the status of the XTCSIZE option, in addition to definitions for message size segregation. If you do not want XTCSIZE to be enabled, you can change the health check parameter from XCFMGD to USERMGD.

Steps to take

The XTCSIZE keyword is ENABLED by default. You can disable it, if necessary. You can set the state of the FUNCTIONS statement dynamically by using the SETXCF FUNCTIONS system command.

Reference information

For more information, see the description of the XCF/XES FUNCTIONS options in z/OS MVS Setting Up a Sysplex.

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMXCF,XCF_TCLASS_CLASSLEN.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".


Step 4.1.2.3 : BCP: Create IPL text


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

IPL text is bootstrap information that is required for IPL, such as the location of the nucleus library. You must create IPL text by running ICKDSF against the system residence volume.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  • Update and run the IPLTEXT job to write a new copy of the IPL text. If you install z/OS with a ServerPac, an installation dialog job is provided to perform this action. If you install z/OS with a CBPDO, refer to the instructions in z/OS Program Directory in the z/OS Internet library.

Tip: With ICKDSF R17 APAR PM42057 applied, you can use the REFORMAT command with the new parameter REMOVEIPLTXT to remove IPL text from the volume.

Note:

When the IPLTXTEXIST parameter (which was introduced by ICKDSF R17 APAR PK16403) is specified with the REFORMAT command with the IPLDD parameter, WTOR message ICK21836D is suppressed if IPL text exists.

Reference information

For a sample IPLTEXT job, see z/OS Program Directory in the z/OS Internet library. ServerPac provides a similar job for accomplishing this task; see ServerPac: Installing Your Order.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.2.4 : BCP: Review the list of WTORs in parmlib member AUTOR00


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The IBM-supplied parmlib includes the AUTOR00 member. When the member is found in your parmlib concatenation during IPL, it causes auto-reply processing to be started. If the WTORs listed in AUTOR00 are automated by your existing automation product, ensure that the replies in AUTOR00 are appropriate.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if you use the auto reply facility of z/OS, which is enabled by default when the AUTOR00 member is found in the parmlib concatenation.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  • Examine the WTOR replies in the AUTOR00 parmlib member. If the replies or delay duration are not desirable, you can create a new AUTORxx parmlib member and make corresponding changes. Also compare the replies to what your automation product would reply to these WTORs. Make sure that the AUTOR00 replies are in accordance with the replies from your automation product. IBM does not recommend making updates to AUTOR00, because updates to AUTOR00 might be made by the service stream or in new z/OS releases.

Note: The IBM-shipped data set SYS1.IBM.PARMLIB contains the AUTOR00 member. So, if you specify it within the PARMLIB concatenation and will not intend to activate the auto reply functionality, you need to specify AUTOR=OFF in the IEASYSxx parmlib member.

Reference information

For more information, see the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.2.5 : BCP: Reassemble the stand-alone dump program


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The stand-alone dump program produces a dump of storage that is occupied by a system that failed or a stand-alone dump program that failed. You must reassemble the stand-alone dump program each release. When the stand-alone dump program is properly created on a DASD residence volume, it resides in the SYS1.PAGEDUMP.Vvolser data set.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP.

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Follow these steps:

  • Reassemble the stand-alone dump program. If you install z/OS with a ServerPac, an installation dialog job is provided to perform this action. If you install z/OS with a CBPDO, instructions to perform this action are provided in z/OS MVS Diagnosis: Tools and Service Aids.

Reference information

For more information, see the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.2.6 : BCP: Removal of support for user key common areas


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

IBM strongly recommends that you eliminate all use of user key common storage. Allowing programs to obtain user key (8-15) common storage creates a security risk because the storage can be modified or referenced, even if fetch protected, by any unauthorized program from any address space. Therefore, without the restricted use common service area (RUCSA) optional priced feature, 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: This 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 statements 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 following:

    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

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP.

When change was introduced:

V2R4.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

  • If running CICS Transaction Server for z/OS, you require V5.2 or later.
  • If running Tivoli OMEGAMON XE for DB2 PE/PM, you require APAR PI97225 ("Removed User Key CADS Creation").

Other PTFs on other IBM products might also be required. As a reminder, use the TargetSystem-RequiredService.z/OS.V2R4 FIXCAT to identify those necessary PTFs.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

See "Steps to take."

Related IBM Health Checker for z/OS check:

Use the following IBM Health Checker for z/OS checks:

  • IBMVSM,VSM_ALLOWUSERKEYCSA to examine the setting of the ALLOWUSERKEYCSA option in the DIAGxx parmlib member.
  • IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM to detect usage of user key common storage.
Steps to take
  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 :
    • 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.
    • 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.
    • If you are running CICS Transaction Server for z/OS, ensure that you are running V5.2 or a later version.
    • 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:
    • 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.
    • Using the DSPSERV service to allocate a SCOPE=COMMON data space in a key of 8-15.
    • 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:

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

    • Activate the ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM health check. This health check issues an exception message when it detects usage of user key common storage.
    • 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:
    • 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.
    • 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.
    • 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.
    • 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
    • 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
    • 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:
    • Use a SCOPE=ALL data space to share data space storage with specific units of work in specific address spaces.
    • Use IARVSERV SHARE to share below-the-bar storage with specific address spaces.
    • Use IARV64 GETSHARED to share above-the-bar storage with specific address spaces.
    • 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:

Instructions:

This portion of the Workflow will guide you to submit jobs to run two health checks that are associated with this upgrade action, IBMVSM,VSM_ALLOWUSERKEYCSA and IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM.

These checks will be activated if they are not already active. If the checks are activated, they will be deactivated at the end of the job, so that they remain in the same state as they were found.

If the health checks run with no exceptions, this step will be marked "Complete" indicating that this upgrade action requires no further activity.

If either of the health checks find an exception, this step will be marked as "Failed". If so, further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (using any method you use to view health check output, such as SDSF) and correct any situations as appropriate. You can then re-run this workflow step to submit the health check job again, until the health checks no longer receive exceptions and the step is marked "Complete".

NOTE: The successful running of these health checks only partially covers this upgrade action. Refer to the upgrade action text for the complete list of steps to take.


Step 4.1.2.7 : BCP: Ensure that TVSAMCOM or TVSMSG are not used as job statement symbols


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

New JCL keywords are added to the JCL EXEC statement, as follows:

  • TVSAMCOM was added in z/OS V2R3.
  • TVSMSG was added in z/OS V2R1 and V2R2 with APAR OA48450.

Because JCL keyword names are reserved, you must ensure that your jobs do not use symbols with these same names. That is, if a job contains the symbolic parameter names TVSAMCOM or TVSMSG on the EXEC or PROC statement, you must edit the jobs to use alternatively named symbols. Otherwise, the jobs can fail with JCL errors.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP

When change was introduced:

TVSAMCOM
z/OS V2R3.
TVSMSG
z/OS V2R2, with APAR OA48450 applied.

Applies to upgrade from:

TVSAMCOM
z/OS V2R2.
TVSMSG
z/OS V2R2 without APAR OA48450 applied.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if you used symbols TVSAMCOM or TVSMSG in jobs.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

Jobs that use TVSAMCOM or TVSMSG as an EXEC or PROC statement symbol name fail with a JCL error.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Search for a symbol that is named TVSAMCOM or TVSMSG in all libraries that contain JCL, such as procedure libraries. Specifically, search for the following occurrences:

  • PROC statements that contain a symbolic parameter that is named TVSAMCOM or TVSMSG.

    Example:

    //PROC1 PROC TVSAMCOM=ABC //PROC1 PROC TVSMSG=ABC
  • EXEC statements that contain a symbolic parameter that is named TVSAMCOM or TVSMSG.

    Examples:

    //JSTEP1 EXEC PROC1,TVSAMCOM=ABC //JSTEP1 EXEC PROC1,TVSMSG=ABC
  • EXEC statements that contain the parameter value string '&TVSAMCOM' or '&TVSMSG'.

    Examples:

    //STEP1 EXEC PGM=MYPROG,PARM=’&TVSAMCOM’ //STEP1 EXEC PGM=MYPROG,PARM='&TVSMSG'

For any occurrences that you find, change the JCL statement to refer to a different symbolic parameter name.

Reference information

For more information about JCL statements, see z/OS MVS JCL Reference.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.2.8 : BCP: Running z/OS as a guest requires z/VM V6R4 or later


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Introduced on the IBM System z EC12, transactional execution (TX) is a hardware-based facility that supports the notion of "transactions" by using such instructions as TBEGIN, TBEGINC, TABORT, and TEND — all of which are described in z/Architecture Principles of Operation. These instructions can be grouped into a transaction and any instructions that are used to update memory are committed to memory at the transaction's end.

As of z/OS V2R3, many functions of an EC12 were required (and enforced), but not transactional execution. As a result, z/OS programs that were coded to use TX needed to be sensitive to their environment, as follows:

  • z/OS not running under VM, TX is available.
  • z/OS running under VM V6R4 or later, TX is available.
  • z/OS running under VM V6R3 or earlier, TX is not available.

Starting with z/OS V2R4, running z/OS as a guest requires z/VM V6R4 or later. This requirement means that TX is available in all configurations.

A benefit of this change is that your programs no longer need to support a dual-path, regarding whether TX is available. In z/OS V2R4, the MACHMIG TX operand is still accepted, but is ignored. It is recommended, but not required, that you remove your use of this operand.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP

When change was introduced:

z/OS V2R4.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if you are running z/OS under z/VM V6R3 or earlier.

Removing the MACHMIG TX operand in LOADxx parmlib member is recommended, but not required.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

This requirement is enforced at system IPL. If you attempt to run z/OS V2R4 under z/VM V6R3 or earlier, your system enters wait state 07B-21.

Related IBM Health Checker for z/OS check:

None.

Steps to take

If you do not plan to run z/OS V2R4 under z/VM, you have no action to take.

If you plan to run z/OS V2R4 under z/VM, ensure that you are running z/VM V6R4 or later. If not, you must upgrade to a supported z/VM release, such as z/VM V6R4.

If you have programs that support dual-paths based on the fields PSATX, PSATXC, CVTTX, or CVTTXC, and you know that your code will run on z/OS V2R4 or later, you can remove the check and the non-TX path.

Reference information

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.2.9 : BCP: Stop referencing the ETR parameters in CLOCKxx


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

In z/OS V2R4, the default values of the CLOCKxx parmlib member ETRMODE and ETRZONE parameters are changed from YES to NO.

The IBM z10 was the last IBM mainframe to support the ETRMODE and ETRZONE parameters in CLOCKxx. Because z/OS V2R4 requires a zEC12 or later processor to run, the ETRMODE and ETRZONE parameters are now obsolete. They are deactivated (set to NO) by default.

It is recommended that you set these parameters to NO, or remove them from CLOCKxx. Specifying YES can cause unexpected behavior if you also specify STPZONE NO. For details, see APAR OA54440.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP

When change was introduced:

z/OS V2R4.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

No, but recommended.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Review the CLOCKxx member that you use to IPL your system, and take one of the following actions:

  • If CLOCKxx does not specify ETRMODE or ETRZONE, you have no action to take.
  • If CLOCKxx specifies ETRMODE YES or ETRZONE YES, set these parameters to NO, or remove them so that they default to NO.
  • If CLOCKxx specifies ETRMODE NO and ETRZONE NO, you have no action to take.

Reference information

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.2.10 : BCP: Evaluate the changed default for system logger's use of IBM zHyperwrite


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

With the installation of APAR OA57408, the use of IBM zHyperWrite data replication by system logger is changed from enabled to disabled by default.

The IBM zHyperWrite function was originally provided by APAR OA54814.

In parmlib member IXGCNFxx, this option is specified, as follows:

MANAGE . . . HYPERWRITE ALLOWACCESS(YESNO)

When IBM zHyperwrite is enabled for use with system logger, it provides data replication for the following types of log stream data sets:

  • Staging data sets for DASDONLY type log streams
  • Offload data sets for both the DASDONLY type and Coupling Facility structure-based type log streams.

System logger does not use zHyperwrite for the staging data sets for Coupling Facility structure-based type log streams.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP.

When change was introduced:

z/OS V2R3 and z/OS V2R2, both with PTF for APAR OA57408 applied.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2, both without APAR OA57408.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if you want system logger to use IBM zHyperwrite data replication.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

If you do not want system logger to use IBM zHyperwrite data replication, you have no action to take. When you install APAR OA57408, the use of IBM zHyperWrite data replication by system logger is disabled by default.

To determine whether system logger on your system uses IBM zHyperwrite data replication, you can query the current setting by entering the following command:

DISPLAY LOGGER,IXGCNF,MANAGE

In response, message IXG607I identifies the current setting.

To enable system logger use of IBM zHyperwrite data replication, you can do either of the following:

  • Enter the command SETLOGR MANAGE,HYPERWRITE,ALLOWUSE(YES)
  • Update the IXGCNFxx parmlib member with ALLOWUSE(YES).

Reference information

For more information, see IXGCNFxx parmlib member in z/OS MVS Initialization and Tuning Reference.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.1.3 : BCP actions to perform after the first IPL of z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes BCP upgrade actions that you can perform only after you have IPLed z/OS V2R4. You need a running z/OS V2R4 system to perform these actions.

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.2 : BookManager READ upgrade actions


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes upgrade actions for base element BookManager READ.


Step 4.2.1 : BookManager READ actions to perform before installing z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes BookManager READ upgrade actions that you can perform on your current (old) system. You do not need the z/OS V2R4 level of code to make these changes, and the changes do not require the z/OS V2R4 level of code to run once they are made.


Step 4.2.1.1 : BookManager READ: Remove any dependencies on BookManager READ from your system


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

z/OS V2R4 removes support for the BookManager READ element. IBM recommends that you use IBM Knowledge Center for z/OS, which was introduced in z/OS V2R2, to access product documentation on the web or from your own local repository.

IBM Knowledge Center for z/OS is the IBM platform for delivering product documentation. It is the replacement for both BookManager READ and Library Server.

In z/OS V2R2, IBM Knowledge Center for z/OS (KC4z) became a base element of z/OS. With KC4z, and Version 5 of the Softcopy Librarian tool, your installation can manage collections of Knowledge Center content (plug-ins) in your own repositories, and serve the content to users from those repositories.

KC4z provides function that is equivalent to BookManager READ and Library Server, as follows:

  • Similar to BookManager READ, you can use KC4z to manage your content collections. One difference is that KC4z provides a web interface to the documentation, rather than the“green screen” TSO/E interface as found in BookManager READ.
  • Similar to Library Server, you can use KC4z to host and serve documentation from your own server, within your intranet. By using links on the KC4z content Landing Page for each "z/OS elements+features" product, KC4z can serve PDFs from the IBM Publications Center website. Or, if the PDFs are loaded into a KC4z repository on your system (using the collection of Adobe Indexed PDFs for "z/OS elements+features"), the PDFs can be served from a local KC4z repository.

In z/OS V2R1, IBM ended its production of BookManager Book format publications. At this time, the need to continue reading documentation by using the BookManager READ “green screen” interface on TSO/E is much reduced or eliminated.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

BookManager READ

When change was introduced:

z/OS V2R4

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Remove any dependencies on BookManager READ from your system.

Check for the following uses:

  • Review any invocation of BookManager READ on any customized ISPF panels that you have provided.
  • Reading BookManager Book format documentation by using the BookManager READ “green screen” interface on TSO/E. Plan to replace your BookManager Book repository with a KC4z repository of Knowledge Center plugins.
  • Using the BookManager READ command line interface to access information in BookManager Book format documentation, such as the older “ green screen” version of the LookAT message tool.

Replace any use of the BookManager READ command line interface that accesses information in BookManager Book documentation with a Knowledge Center based solution. IBM Knowledge Center includes a replacement for the legacy LookAT facility that was used for message look-ups. You can find it here: IBM Z: Look@ Knowledge Center

In KC4z, the LookAT function can be configured to perform its message lookup against either the Knowledge Center hosted on ibm.com, or against a KC4z repository of Knowledge Center documentation hosted locally on your system.

If you still need the ability read legacy BookManager books, you can do so by moving the book files to a Windows system and using Softcopy Reader for Windows to read the files. This tool is available for download without charge from IBM Support Portal on ibm.com.

Reference information

For more information, see IBM Knowledge Center for z/OS Configuration and User Guide.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.2.2 : BookManager READ actions to perform before the first IPL of z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes BookManager READ upgrade actions that you can perform after you have installed z/OS V2R4, but before the first time you IPL. These actions might require the z/OS V2R4 level of code to be installed, but do not require it to be active.

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.2.3 : BookManager READ actions to perform after the first IPL of z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes BookManager READ upgrade actions that you can perform only after you have IPLed z/OS V2R4. You need a running z/OS V2R4 system to perform these actions.

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.3 : CIM upgrade actions


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes upgrade actions for the base element Common Information Model (CIM).


Step 4.3.1 : CIM actions to perform before installing z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes CIM upgrade actions that you can perform on your current (old) system. You do not need the z/OS V2R4 level of code to make these changes, and the changes do not require the z/OS V2R4 level of code to run once they are made.


Step 4.3.1.1 : CIM: Accommodate the default change from HTTP to HTTPS


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Starting in z/OS V2R4, the common information model (CIM) server uses HTTPS connections by default. On start-up, the CIM server listens on the HTTPS port, rather than the HTTP port, as was done in previous releases.

The change from HTTP to HTTPS is intended to allow for more secure communication with the CIM server.

The following CIM server configuration defaults are affected:

  • enableHttpConnection=true
  • enableHttpsConnection=false

In z/OS V2R4, these defaults were changed to:

  • enableHttpConnection=false
  • enableHttpsConnection=true

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

BCP

When change was introduced:

z/OS V2R4.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes, if you have applications that connect to the CIM server through the HTTP protocol.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

Based on this change, the CIM server opens a listener on port 5989 by default. If a client connection on this port is not secured by AT-TLS, the connection is closed and an appropriate error message is issued on the operations console.

Related IBM Health Checker for z/OS check:

The following migration health check indicates whether the CIM server is listening on the HTTP port of the system:
IBMCIM,ZOSMIGV2R4_CIM_HTTPS_ENABLED

This check is available for z/OS V2R3 with APAR OA57687 applied.

Steps to take

It is recommended that you use HTTPS instead of HTTP, which allows the CIM server to use Application Transparent Layer Security (AT-TLS) functions. Here, the communication between the CIM client and the CIM server is encrypted.

You must also configure the CIM client applications to use HTTPS. Ensure that the applications run as CIM clients connected to the CIM server on HTTPS port 5989.

Fall back to HTTP is possible, though it is not secure and therefore not recommended.

If you need the CIM server to use the HTTP protocol on start-up, follow these steps:

  • Start the CIM server with the following settings specified in the configuration properties file:
    • enableHttpConnection=true
    • enableHttpsConnection=false
  • Alternatively, you can dynamically change the enableHttpConnection value and restart the CIM server by entering either of these commands on the operations console:
    • cimconfig -s enableHttpConnection= true -p
    • F CFZCIM,APPL=CONFIG,enableHttpConnection=true,PLANNED

Reference information

For information about how to set up HTTPS connections for the CIM server, see the topic “Configuring the CIM server HTTPS connection using AT-TLS” in CIM User’s Guide.

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMCIM,ZOSMIGV2R4_CIM_HTTPS_ENABLED.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".


Step 4.3.2 : CIM actions to perform before the first IPL of z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes CIM upgrade actions that you can perform after you have installed z/OS V2R4, but before the first time you IPL. These actions might require the z/OS V2R4 level of code to be installed, but do not require it to be active.

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.3.3 : CIM actions to perform after the first IPL of z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes CIM upgrade actions that you can perform only after you have IPLed z/OS V2R4. You need a running z/OS V2R4 system to perform these actions.

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.4 : Communications Server upgrade actions


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes upgrade actions for base element z/OS Communications Server.


Step 4.4.1 : Communications Server actions to perform before installing z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes Communications Server upgrade actions that you can perform on your current (old) system. You do not need the z/OS V2R4 level of code to make these changes, and the changes do not require the z/OS V2R4 level of code to run once they are made.


Step 4.4.1.1 : SNA services: Migrate from VTAM Common Management Information Protocol


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

z/OS V2R4 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, which is called the topology agent. IBM recommends that you use the SNA network monitoring network management interface (NMI) to monitor SNA Enterprise Extender and High Performance Routing data.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

z/OS Communications Server.

When change was introduced:

z/OS V2R4. The removal of VTAM Common Management Information Protocol (CMIP) was announced on 26 February 2019 in IBM United States Software Announcement 219-013.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended because support for this function is being removed in a future release.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

To determine whether VTAM OSIMGMT functions are in use on this system, use the health check IBMCS,ZOSMIGV2R4_NEXT_CS_OSIMGMT

The health check is available on the following releases:

  • z/OS V2R2 and V2R3 with APAR OA57227
  • z/OS V2R4
Steps to take

Determine whether you have any programs that use VTAM Common Management Information Protocol (CMIP) to monitor SNA Enterprise Extender and High Performance Routing data. An indication of current usage would be if OSIMGMT=YES is specified in your VTAM start list. If so, update the programs to use the SNA network monitoring network management interface (NMI).

Reference information

None.

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMCS,ZOSMIGV2R4_NEXT_CS_OSIMGMT.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".

The health check is available on the following releases: z/OS V2R2 and V2R3 (both with APAR OA57227) and z/OS V2R4


Step 4.4.1.2 : IP services: Ensure storage availability for IWQ IPSec traffic


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

As of z/OS V2R3 with TCP/IP APAR PI77649, or z/OS V2R2 with TCP/IP APAR PI77649 and SNA APAR OA52275, the processing of IPAQENET and IPAQENET6 INTERFACE statements is enhanced when you use OSA-Express6S. If you enabled QDIO inbound workload queuing (WORKLOADQ) and you have IPSec traffic, an additional ancillary input queue (AIQ) is established for IPSec inbound traffic. Additional storage is allocated for this input queue.

Each AIQ increases storage utilization in the following two areas:

  • Approximately 36 KB of fixed ECSA
  • 64-bit CSM HVCOMMON for READSTORAGE

    If you are using IPSec, when the first IPSec tunnel is activated (protocols ESP or AH), the new AIQ is backed with 64-bit CSM HVCOMMON fixed storage. The amount of HVCOMMON storage that is used is based on the specification of the INTERFACE READSTORAGE parameter.

If you configured QDIO inbound workload queuing (WORKLOADQ), ensure that sufficient fixed ECSA and fixed (real) 4 KB CSM HVCOMMON storage is available for the AIQ for IPSec traffic.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

z/OS Communications Server.

When change was introduced:

z/OS V2R3 (with APAR PI77649) and z/OS V2R2 (with APARs PI77649 and OA52275).

Applies to upgrade from:

z/OS V2R3 (without APAR PI77649) and z/OS V2R2 (without APARs PI77649 and OA52275).

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but it is recommended if you have the WORKLOADQ parameter that is specified on the OSA IPAQENET and IPAQENET6 INTERFACE statements, you have IPSec traffic and you have concerns about using additional ECSA or real (fixed) storage.

Target system hardware requirements:

OSA-Express6S Ethernet features or later in QDIO mode running on IBM z14 and ZR1.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

To determine whether sufficient fixed storage is available for IWQ IPSec enabling, use the following IBM health checks:

  • IBMCS,ZOSMIGV2R4PREV_CS_IWQSC_tcpipstackname issues a message if the TCP/IP stack has inbound workload queuing (IWQ) and IPSec enabled, but the OSA does not support IWQ for IPSec. Only OSA-Express6S and later support IWQ for IPSec. This health check is shipped INACTIVE and set to run once.
  • IBMCS,CSTCP_IWQ_IPSEC_tcpipstackname issues a message if the TCP/IP stack has IWQ and IPSec enabled, and the OSA does support IWQ for IPSec. This health check is shipped ACTIVE and is set to run once.

These health checks are available with PH11837 and OA57525 for V2R3, and PH12005 and OA57560 for V2R4.

Steps to take
  1. If you are using or plan to use OSA-Express6S or later, verify that the following conditions are true:
    • WORKLOADQ is specified on the IPAQENET and IPAQENET6 INTERFACE statements.
    • Have IPSec traffic; protocols ESP or AH.
  2. If step 1 is applicable, IWQ IPSec uses additional storage. Continue with step 3 - 6. Otherwise, there is no increase in storage usage, and no further action is required.
  3. To calculate the total storage increase, count the total number of IPAQENET and IPAQENET6 INTERFACE statements that are coded with the WORKLOADQ parameter that are associated with OSA-Express6S or later. Make a note of the number.
  4. Verify that sufficient ECSA is available. To calculate this, multiply the total INTERFACE statements that are counted in step 3 by 36 KB. The resulting number indicates how much additional ECSA is required.

    To determine whether sufficient ECSA is available to enable this function, verify the following ECSA definitions:

    • D CSM usage (PARMLIB member IVTPRM00, ECSA MAX value)
    • VTAM (Start Options CSALIMIT and CSA24)
    • TCPIP (GLOBALCONFIG ECSALIMIT statement in the TCPIP PROFILE)
  5. Verify that sufficient real (fixed) storage is available. 64-bit fixed (CSM HVCOMMON) storage is used for the IPSec AIQ read buffers. To calculate this value, multiply the total number of INTERFACE statements that are counted in step 3 by your configured READSTORAGE value (for example, 4 MB). You can verify how much storage is being used for READSTORAGE by using the D NET, TRLE command. The resulting number indicates how much additional fixed (64-bit) storage is required. To verify that the additional fixed storage is not a constraint for your system, take the following actions:
    • Use the DISPLAY CSM command to verify that sufficient fixed storage is available (CSM FIXED MAXIMUM defined in IVTPRM00).
    • Verify the actual amount of real storage available to this z/OS system by using D M=STOR or D M=HIGH.
  6. If sufficient ECSA or real storage is not available, increase the available real storage or consider defining some of the OSA-Express6S (or later) INTERFACE statements with the NOWORKLOADQ parameter. If your CSM FIXED MAXIMUM is too low, increase this value in IVTPRM00.
Reference information

For information about ECSA usage, see the IBM technote Communications Server ECSA and CSM Storage Usage.

For documentation updates to existing publications, check the following URL for the appropriate FMID:

Instructions:

This portion of the Workflow will guide you to submit jobs to run two IBM Health Check for z/OS health checks associated with this upgrade action, IBMCS,*IWQ*.

These checks will be activated if they are not already active. If the checks are activated, they will be deactivated at the end of the job, so that they remain in the same state as they were found.

If the health checks run with no exceptions, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health checks find an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation as you find appropriate. You can then re-run this workflow step to submit the health check jobs again, until the health checks no longer receive exceptions and the step is marked "Complete".

These health checks are available with PH11837 and OA57525 for V2R3, and PH12005 and OA57560 for V2R4.


Step 4.4.1.3 : IP Services: Plan to upgrade the DCAS server to AT-TLS security


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

z/OS V2R4 is the last release in which the 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 this server will be Application Transparent Transport Layer Security (AT-TLS).

The direct System SSL support in this component is functionally outdated and supports only TLS protocols up through TLSv1.1.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

z/OS Communications Server.

When change was introduced:

z/OS V2R4. Also, see IBM United States Software Announcement "IBM z/OS Version 2 Release 4" dated July 23, 2019.

Applies to upgrade from:

z/OS V2R2 and z/OS V2R3.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended if you are using the native TLS/SSL support for DCAS (TLSMECHANISM DCAS).

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

DCAS configuration error messages are issued if any IBM system SSL configuration keywords or parameters are configured.

Related IBM Health Checker for z/OS check:

The following migration health check can help you determine whether you are using native TLS/SSL for FTP servers:
IBMCS,ZOSMIGV2R4_NEXT_CS_DCAS_NTVSSL

This check is available for z/OS V2R2 and V2R3 with APAR OA58255 applied.

Steps to take

You must migrate the DCAS server to use AT-TLS policies.

Complete the following steps to migrate the DCAS server to use AT-TLS policies:

  1. Customize the DCAS server for TLS/SSL. For more information, see the topic about customizing DCAS for TLS/SSL in IP Configuration Guide.
  2. Migrate the DCAS configuration file. For more information about DCAS configuration keywords and equivalent AT-TLS policies, see the table that follows.

Table 2. Migrating existing DCAS server to use AT-TLS policies
DCAS configurationAT-TLS equivalent statementAT-TLS policy statement
ClientAuth

Local1

HandshakeRole ServerWithClientAuthTTLSEnvironmentAction
ClientAuthType Required

TTLSEnvironmentAction ->

TTLSEnvironmentAdvancedParms

ClientAuth

Local2

HandshakeRole ServerWithClientAuthTTLSEnvironmentAction
ClientAuthType SAFCHECKTTLSEnvironmentAction ->

TTLSEnvironmentAdvancedParms

IPADDRLocalAddrTTLSRule
KEYRINGKeyringTTLSEnvironmentAction ->

TTLSKeyringParms

LDAPPORTGSK_LDAP_SERVER_PORTTTLSEnvironmentAction ->

TTLSGskAdvancedParms ->

TTLSGskLdapParms

LDAPSERVERGSK_LDAP_SERVERTTLSEnvironmentAction ->

TTLSGskAdvancedParms ->

TTLSGskLdapParms

PortLocalPortRangeTTLSRule
SAFKEYRINGKeyringTTLSEnvironmentAction ->

TTLSKeyringParms

STASHFILEKeyringStashFileTTLSEnvironmentAction ->

TTLSKeyringParms

V3CIPHERV3CipherSuitesTTLSEnvironmentAction ->

TTLSCipherParms

Reference information

None.

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMCS,ZOSMIGV2R4_NEXT_CS_DCAS_NTVSSL.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".


Step 4.4.1.4 : IP Services: Plan to upgrade the FTP server to AT-TLS security


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

z/OS V2R4 is the last release in which the FTP server will support direct invocation of System SSL APIs for TLS/SSL protection. In the future, the only TLS/SSL protection option for this server will be Application Transparent Transport Layer Security (AT-TLS). If you are using native TLS/SSL support for the FTP server, you must upgrade to using AT-TLS policies.

The following FTP.DATA parameters and settings for the FTP server are removed:

  • TLSMECHANISM FTP
  • TLSRFCLEVEL CCCNONOTIFY
  • KEYRING
  • CIPHERSUITE
  • TLSTIMEOUT
  • SSLV3

Note: TLS/SSL support for the FTP client is unchanged.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

z/OS Communications Server.

When change was introduced:

z/OS V2R4. Also, see IBM United States Software Announcement "IBM z/OS Version 2 Release 4" dated July 23, 2019.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R4.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended if you are using the native TLS/SSL support for the FTP server.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

FTP configuration error messages are issued if any of the removed configuration keywords or parameters are configured for FTP servers.

Related IBM Health Checker for z/OS check:

The following migration health check can help you determine whether you are using native TLS/SSL for FTP servers:
IBMCS,ZOSMIGV2R4_NEXT_CS_FTPSRV_NTVSSL

This check is available for z/OS V2R2 and V2R3 with APARs PH21573 and OA59022 applied.

Steps to take

You must migrate any FTP server using native TLS/SSL to use AT-TLS policies.

Perform the following steps to migrate from an existing FTP server configuration using native TLS/SSL support to a configuration using AT-TLS:

  1. Configure AT-TLS and Policy Agent. For details about Policy Agent setup and AT-TLS policy statements, see IP Configuration Reference.

    Requirements:

    • The FTP server is a controlling application. Code a TTLSEnvironmentAdvancedParms statement with the ApplicationControlled and SecondaryMap parameters; both parameters should specify the value On. The ApplicatonControlled parameter allows FTP to start and stop TLS security on a connection. The SecondaryMap parameter enables active or passive data connections to use the AT-TLS policy that is used for the control connection. You do not need to code any additional TTLSRule statements for the data connections.
    • The FTP server requires the HandshakeRole parameter with the value Server or ServerWithClientAuth to be coded on the TTLSEnvironmentAction statement. If the SECURE_LOGIN statement is coded in FTP.DATA with the parameters REQUIRED or VERIFY_USER, the HandshakeRole parameter value must be ServerWithClientAuth.
    • The TTLSRule statement for the FTP server requires the Direction parameter with the value Inbound.

  2. Configure the FTP server to use AT-TLS by coding TLSMECHANISM ATTLS in FTP.DATA.

  3. If TLSRFCLEVEL CCCNONOTIFY is configured in FTP.DATA, update TLSRFCLEVEL to have a valid value for AT-TLS.

  4. Use Table 2 to migrate the existing FTP server configuration to AT-TLS. Remove the statements form FTP.DATA and code the AT-TLS equivalent statement.
    Table 2. Migrating existing FTP server configuration
    FTP.DATA statementAT-TLS equivalent statementAT-TLS policy statement
    KEYRINGKeyring

    TTLSKeyRingParms ->

    TTLSEnvironmentAction

    CIPHERSUITEV3CipherSuites

    TTLSCipherParms ->

    TTLSEnvironmentAction or TTLSConnectionAction

    TLSTIMEOUTGSK_V3_SESSION_TIMEOUT

    TTLSGskAdvancedParms ->

    TTLSEnvironmentAction

    SSLV3SSLv3

    TTLSEnvironmentAdvancedParms-> TTLSEnvironmentAction

    Or

    TTLSConnectionAdvancedParms-> TTLSConnectionAction


  5. Use Table 3 to migrate existing ciphers coded on CIPHERSUITE statements in FTP.DATA to AT-TLS TTLSCipherParms statements.
    Table 3. Migrating existing ciphers
    CIPHERSUITE cipherV3CipherSuites cipherHexadecimal value
    SSL_DES_SHA TLS_RSA_WITH_DES_CBC_SHA09
    SSL_3DES_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA0A
    SSL_NULL_MD5TLS_RSA_WITH_NULL_MD5 01
    SSL_NULL_SHA TLS_RSA_WITH_NULL_SHA 02
    SSL_RC2_MD5_EX TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 06
    SSL_RC4_MD5 TLS_RSA_WITH_RC4_128_MD504
    SSL_RC4_MD5_EX TLS_RSA_EXPORT_WITH_RC4_40_MD503
    SSL_AES_128_SHATLS_RSA_WITH_AES_128_CBC_SHA2F
    SSL_AES_256_SHA TLS_RSA_WITH_AES_256_CBC_SHA35

  6. AT-TLS supports more secure TLS versions and ciphers. Consider enabling TLSv1.2 or TLSv1.3 on the TTLSEnvironmentAdvancedParms or TTLSConnectionAdvancedParms statement. Consider enabling support for additional ciphers on the TTLSCipherParms statement.

Reference information

For the steps to migrate the FTP server, see the topic "Steps for migrating the FTP server and client to use AT-TLS" in IP Configuration Guide.

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMCS,ZOSMIGV2R4_NEXT_CS_FTPSRV_NTVSSL.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".


Step 4.4.1.5 : IP Services: Plan to upgrade the TN3270E server to AT-TLS security


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

z/OS V2R4 is the last release in which the TN3270E server will support direct invocation of System SSL APIs for TLS/SSL protection. In the future, the only TLS/SSL protection option for this server will be Application Transparent Transport Layer Security (AT-TLS). If you are using native TLS/SSL support for the TN3270E server, you must upgrade to using AT-TLS policies.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

z/OS Communications Server.

When change was introduced:

z/OS V2R4. Also, see IBM United States Software Announcement "IBM z/OS Version 2 Release 4" dated July 23, 2019.

Applies to upgrade from:

z/OS V2R2 and z/OS V2R3.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended if you are using native TLS/SSL support for TN3270E.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

TN3270E configuration error messages are issued if any IBM system SSL configuration keywords or parameters are configured.

Related IBM Health Checker for z/OS check:

The following migration health check can help you determine whether you are using native TLS/SSL for FTP servers:
IBMCS,ZOSMIGV2R4_NEXT_CS_TN3270_NTVSSL

This check is available for z/OS V2R2 and V2R3 with APAR OA58255 applied.

Steps to take

You must migrate the TN3270E server to use AT-TLS policies.

Complete the following steps to migrate the TN3270E server to use AT-TLS policies:

  1. Customize the TN3270E server for TLS/SSL. For more information, see the topic "TN3270E Telnet server security" in IP Configuration Guide.
  2. Migrate the TN3270E configuration file. For more information about TN3270E configuration keywords and equivalent AT-TLS policies, see Table 2.
    Table 2. Migrating existing TN3270E server to use AT-TLS policies
    Telnet statementAT-TLS equivalent statementAT-TLS equivalent statement
    CLIENTAUTH

    SSLCERT

    HandshakeRole

    ServerWithClientAuth and

    ClientAuthType Required

    TTLSConnectionAction or

    TTLSEnvironmentAction /

    TTLSEnvironmentAdvancedParms within TTLSEnvironmentAction

    CLIENTAUTH

    SAFCERT

    HandshakeRole

    ServerWithClientAuth and

    ClientAuthType SAFCHECK

    TTLSConnectionAction or

    TTLSEnvironmentAction /

    TTLSEnvironmentAdvancedParms within TTLSEnvironmentAction

    CRLLDAPSERVERGSK_LDAP_Server and

    GSK_LDAP_Server_Port

    TTLSGskLdapParms within TTLSEnvironmentAction
    ENCRYPTIONTTLSCipherParmsTTLSConnectionAction or TTLSEnvironmentAction
    KEYRINGKeyringTTLSKeyRingParms within TTLSEnvironmentAction
    SSLV2SSLv2TTLSEnvironmentAdvancedParms within TTLSEnvironmentAction or

    TTLSConnectionAdvancedParms within TTLSConnectionAction

    SSLTIMEOUTHandshakeTimeoutTTLSEnvironmentAdvancedParms within TTLSEnvironmentAction or

    TTLSConnectionAdvancedParms within TTLSConnectionAction

Reference information

For the steps to migrate the FTP server, see the topic "Steps for migrating the FTP server and client to use AT-TLS" in IP Configuration Guide.

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMCS,ZOSMIGV2R4_NEXT_CS_TN3270_NTVSSL.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".


Step 4.4.1.6 : TCP/IP: Prepare for the removal of Sysplex Distributor support for IBM DataPower Gateway products


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

z/OS V2R4 is planned to be the last release to support Sysplex Distributor target controlled distribution to DataPower Gateway products. This feature is deprecated in the DataPower Gateway. IBM recommends that you implement another solution for workload balancing, such as through an external load balancer.

This removal does not impact any other Sysplex Distributor functions. Only configurations that specify TARGCONTROLLED on the VIPADISTRIBUTE statement are affected.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

z/OS Communications Server.

When change was introduced:

See IBM United States Software Announcement "IBM z/OS Version 2 Release 4" dated July 23, 2019.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

No, but recommended because support for this function is being removed in a future release.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Typically, the PROFILE.TCPIP data set is specified on the PROFILE DD statement in the TCP/IP stack started procedure. However, other options exist for specifying it. The search order for accessing PROFILE.TCPIP information is as follows.The first file found in the search order is used.

  1. //PROFILE DD statement
  2. jobname.nodename.TCPIP
  3. TCPIP.nodename.TCPIP
  4. jobname.PROFILE.TCPIP
  5. TCPIP.PROFILE.TCPIP

For more information, see the topic PROFILE.TCPIP search order in IP Configuration Guide.

In the PROFILE.TCPIP data set, search for instances of the following keywords, which are related to Tier1 workload distribution:

  • GRE
  • ENCAP
  • TARGCONTROLLED
  • CONTROLPORT

Remove the keywords from the PROFILE.TCPIP data set.

Reference information

For more information, see the following references:

Step 4.4.2 : Communications Server actions to perform before the first IPL of z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes Communications Server upgrade actions that you can perform after you have installed z/OS V2R4, but before the first time you IPL. These actions might require the z/OS V2R4 level of code to be installed, but do not require it to be active.


Step 4.4.2.1 : IP Services: Update /etc configuration files


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

Some utilities provided by Communications Server require the use of certain configuration files. You are responsible for providing these files if you expect to use the utilities. IBM provides default configuration files as samples in the /usr/lpp/tcpip/samples directory. Before the first use of any of these utilities, you should copy these IBM-provided samples to the /etc directory (in most cases). You can further customize these files to include installation-dependent information. An example is setting up the /etc/osnmpd.data file by copying the sample file from /usr/lpp/tcpip/samples/osnmpd.data to /etc/osnmpd.data and then customizing it for the installation.

If you customized any of the configuration files that have changed, then you must incorporate the customization into the new versions of the configuration files.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Communications Server.

When change was introduced:

Various releases. See Table 2 below.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if you have customized a configuration file (listed in Table 2) that IBM has changed.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

If you added installation-dependent customization to any of the IBM-provided configuration files listed in Table 2, make the same changes in the new versions of the files by copying the IBM-provided samples to the files shown in the table and then customizing the files.

Table 2. Changed Communications Server configuration files

Utility

IBM-provided sample file

Target location

What changed and when

sendmail

/usr/lpp/tcpip/samples/sendmail/cf/sample.c

/etc/mail/sample.cf

In z/OS V2R3, this sample daemon configuration file for the sendmail application was removed. sendmail is no longer supported.

sendmail

/usr/lpp/tcpip/samples/sendmail/cf/submit.cf

/etc/mail/submit.cf

In z/OS V2R3, this sample client configuration file for the sendmail application was removed. sendmail is no longer supported.

sendmail

/usr/lpp/tcpip/samples/sendmail/cf/zOS.cf

/etc/mail/zOS.cf

In z/OS V2R3, this sample AT-TLS configuration file for the sendmail application was removed. sendmail is no longer supported.

sendmail bridge

/usr/lpp/tcpip/samples/etc/mail/ezatmail.cf

/etc/mail/ezatmail.cf

In z/OS V2R3, this sample file was added for the z/OS sendmail to CSSMTP bridge.

SNMP agent

/usr/lpp/tcpip/samples/etc/osnmpd.data

/etc/osnmpd.data

Every release, the value of the sysName MIB object is updated to the current release.

Reference information

For more information about Communications Server configuration files, see z/OS Communications Server: IP Configuration Guide.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.4.2.2 : IP Services: Make changes for Netstat enhancements


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

The Netstat command displays the status of a local host. In each release of z/OS, the Netstat reports can change in ways that can affect automation or front-end programs.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

z/OS Communications Server

When change was introduced:

General upgrade action not tied to a specific release.

Applies to upgrade from:

z/OS V2R3 and V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if the changed or removed settings affect either automation that uses the Netstat report output or front-end programs that run the Netstat command.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

None.

Steps to take

Accommodate the Netstat changes in your automation and front-end programs. You can begin by reviewing the ways in which the displays are updated in each release. For details about the changes for each Netstat report, see z/OS Release Upgrade Reference Summary. However, you must run the commands to know with certainty what changes to make after you IPL a z/OS V2R4 system.

Reference information

For more information, see the following references:

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.4.2.3 : IP Services: Decide whether to accept the new FIXED CSM default


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

In z/OS V2R4, the default amount for communications storage manager (CSM) fixed storage for buffers is increased from 200 MB to 512 MB. Your installation can specify a value for the CSM fixed storage amount on the FIXED statement in the IVTPRM00 parmlib member.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

z/OS Communications Server.

When change was introduced:

z/OS V2R4.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes, if you use the default CSM FIXED MAX value of 200M and you do not want to use the new default of 512M.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

None.

Related IBM Health Checker for z/OS check:

To determine whether the maximum amount of storage dedicated to CSM is sufficient for your system, use the health check IBMCS,CSVTAM_CSM_STG_LIMIT. This check is available for z/OS V2R3 and z/OS V2R2 systems.

The health check issues message ISTH017E if the value specified for the maximum CSM storage for the FIXED, ECSA, or HVCOMM storage types as defined in parmlib member IVTPRM00 is less than the minimum value specified for the check.

Message ISTH002I is displayed prior to this message for each CSM storage type that failed the check.

Steps to take

Review your HVCOMMON setting in IVTPRM00 and determine whether you need to increase this value to account for the fact that the system reserves a larger portion of this storage by default for CSM buffers.

If you did not previously code a value for FIXED in IVTPRM00 and you do not want the new default, specify FIXED MAX(200M) in your IVTPRM00 parmlib member to retain the value as formerly defaulted.

Tip: You can use the D NET,CSM command to display the "FIXED MAXIMUM" storage specification in message IVT5538I.

Reference information

For information about the IVTPRM00 parmlib member, see the IVTPRM00 parmlib member in z/OS MVS Initialization and Tuning Reference.

See the topic about fixed maximum storage for CSM buffers in z/OS Communications Server: IP Configuration Guide.

Instructions:

This portion of the Workflow will guide you to submit a job to run an IBM Health Check for z/OS associated with this upgrade action, IBMCS,CSVTAM_CSM_STG_LIMIT.

This check will be activated if it is not already active. If the check is activated, it will be deactivated at the end of the job, so that it remains in the same state as it was found.

If the health check runs with no exception, this step will be marked "Complete" indicating that this upgrade action requires no more activity.

If the health check finds an exception, this step will be marked as "Failed". This tells you that further investigation (and possibly more work) is necessary to complete this upgrade action. If the step is marked "Failed", you should review the health check output (via any method you use to view health check output, such as SDSF) and correct any situation that you find appropriate. You can then re-run this Workflow step to submit the health check job again, until the health check no longer receives an exception and the step is marked "Complete".


Step 4.4.2.4 : IP Services: Determine the storage impact if QDIOSTG=126 is in effect


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

If you specify QDIOSTG=126 in your VTAM start options, each OSA-Express QDIO interface that uses the default READSTORAGE setting of GLOBAL on the INTERFACE or LINK statement gets 8 MB of fixed CSM for read storage. For any OSA-Express QDIO interfaces that have a bandwidth of at least 10 GbE and use 8 MB of read storage, z/OS V2R4 allocates additional fixed CSM 4K HVCOMMON storage for work element processing.

Information about this upgrade action

The following table provides more details about this upgrade action. Use this information to plan your changes to the system.

Element or feature:

Communications Server.

When change was introduced:

z/OS V2R4.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before the first IPL of z/OS V2R4.

Is the upgrade action required?

Yes.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts:

The system allocates additional fixed CSM HVCOMMON storage for work element processing for each OSA-Express QDIO interface that is using 8 MB of read storage.

Related IBM Health Checker for z/OS check:

None.

Steps to take

See Additional fixed storage for OSA interfaces using 8 MB of read storage in z/OS Communications Server: IP Configuration Guide to understand how much additional storage z/OS V2R4 allocates for work element processing.

If you do not want the system to allocate this extra storage for a specific interface, update your INTERFACE or LINK statement to specify a READSTORAGE value other than GLOBAL.

Reference information

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.4.3 : Communications Server actions to perform after the first IPL of z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes Communications Server upgrade actions that you can perform only after you have IPLed z/OS V2R4. You need a running z/OS V2R4 system to perform these actions.

None.

Instructions:

This information was provided for your understanding and possible further action as dictated by your site policies


Step 4.5 : Cryptographic Services upgrade actions


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes upgrade actions for base element Cryptographic Services. Included are the components Integrated Cryptographic Service Facility (ICSF), Open Cryptographic Services Facility (OCSF), PKI Services, and System Secure Sockets Layer (SSL).


Step 4.5.1 : Cryptographic Services actions to perform before installing z/OS V2R4


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignednoFeedbackNo

Description:

This topic describes Cryptographic Services upgrade actions that you can perform on your current (old) system. You do not need the z/OS V2R4 level of code to make these changes, and the changes do not require the z/OS V2R4 level of code to run once they are made.


Step 4.5.1.1 : ICSF: Remove sequential data sets from the CSFPARM DD statement


Step State:Step Owner:Step Assignee:Step Feedback:Step Skills:Has called workflow:
UnassignedincompleteNo

Description:

Description

As of z/OS V2R4, it is no longer possible to specify a sequential data set on the CSFPARM DD statement in the ICSF procedure.

Information about this upgrade action

The following table provides more details about the upgrade action. Use this information to plan your changes to the system.

Element or feature:

Cryptographic Services.

When change was introduced:

z/OS V2R4.

Applies to upgrade from:

z/OS V2R3 and z/OS V2R2.

Timing:

Before installing z/OS V2R4.

Is the upgrade action required?

Yes, if you specify a sequential data set on the CSFPARM DD statement.

Target system hardware requirements:

None.

Target system software requirements:

None.

Other system (coexistence or fallback) requirements:

None.

Restrictions:

None.

System impacts: