Step 1 : Discover z/OS features in use

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.

Note: This step writes the output property file to the location indicated in Output File Path. You can modify the file path as appropriate for your environment. If you are running the workflow on another z/OS system, ensure that the output file path is shared with the system that you are upgrading. If you are using the tmp directory, be sure to include the system name in the directory path. Example: /SYSTEM/tmp/migration_inputfile.txt

Step 2 : Introducing the z/OS V2R5 Upgrade Workflow

Description:

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

Introducing the z/OS V2R5 Upgrade Workflow

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

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

IBM no longer provides z/OS Migration in a publication format. Since z/OS V2R2, the preferred method for learning about migration actions has been the z/OS Migration Workflow. Discovering, performing, and verifying many migration actions through the z/OSMF Workflows task instead of a more traditional book format 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.

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 V2R5 Upgrade Workflow, Version 1.0

This workflow contains the steps for upgrading to z/OS V2R5 from a previous level of the operating system. This workflow includes new and changed upgrade actions (listed below), and changes for terminology, maintenance, and editorial corrections.

New information

The following upgrade action is new for the IBM z15 server:

• Prepare for the removal of support for TLS 1.0 and TLS 1.1 for SE, HMC, and OSC

The following upgrade actions are new for z/OS V2R5:

• Accommodate the z/OS V2R5 architecture level set and supported storage devices
• Ensure that z/OS V2R5 is running as a guest under z/VM V7.1 if applicable
• BCP: Define exits USER4 and USER5 for IFASMFDP and IFASMFDL
• BCP: The ASCB and WEB are backed in 64-bit real storage by default
• BCP: Accommodate the removal of the binder transport utility IEWTPORT
• BCP: Running z/OS V2R5 as a guest requires z/VM V7.1
• BCP: Accommodate the new CHECKREGIONLOSS default
• BCP: Accommodate the new DSLIMITNUM default
• IP Services: Accommodate the removal of native TLS/SSL support from DCAS
• IP Services: Accommodate the removal of native TLS/SSL support from TN3270E
• TCP/IP: Removal of Sysplex Distributor support for Cisco Multi-Node Load Balancer (MNLB)
• TCP/IP: Removal of Sysplex Distributor support for IBM DataPower Gateway products
• HCD: Remove configurations for unsupported processor types
• ICSF: Update references to the old ICSF library
• z/OSMF: Remove references to z/OSMF mobile notification service
• z/OSMF: Be aware that error message details are no longer displayed by default
• z/OSMF: Use the z/OSMF desktop interface
• z/OSMF: Use the Diagnostic Assistant to collect diagnostic data about z/OSMF
• z/OSMF: Upgrading the IBM zERT Network Analyzer
• z/OSMF: Remove STGADMIN SAF authorization requirements for Software Management
• z/OSMF: Ensure that workflow users are authorized to read workflow files
• Network Authentication Service: Use the stronger NDBM database encryption types
• RMF: Determine updates for RMF structural changes
• RMF: Remove references to deprecated ports for the RMF DDS server
• SDSF: Use only SAF-based security to protect SDSF functions
• Security Server: Remove RACF dynamic classes named IZP and ZOWE
• Security Server: Accommodate the removal of RACF TSO/E HELP text
• z/OS UNIX: Accommodate the new LIMMSG default
• z/OS UNIX: Remove references to the MAXSHAREPAGES option in BPXPRMxx

Changed information

The following upgrade actions are changed for z/OS V2R5:

• Add references to new data sets and paths
• Remove deleted data sets, paths, and references
• BCP: Stop using z/OS Batch Runtime
• BCP: Use the recommended values for WLM service coefficients
• SNA services: Stop using VTAM Common Management Information Protocol
• IP Services: Upgrade TLS/SSL support for FTP server to AT-TLS
• ISPF: Remove any dependencies on Workstation Agent from your system
• Plan for the removal of support for EIM, OCSF, OCEP, and PKITP
• OpenSSH: Accommodate a new level of OpenSSH
• Security Server: Check for duplicate class names
• XL C/C++: Review the z/OS XL C/C++ Compiler and Runtime Migration Guide

Deleted information

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

The following upgrade actions are removed for z/OS V2R5:

• Ensure that the CustomPac Installation Dialog is updated
• Consider using the new JOB statement for the CustomPac installation dialog
• Prepare for the discontinuation of tape delivery
• BCP: Ensure that enough real memory is installed
• BCP: Ensure that TVSAMCOM or TVSMSG are not used as job statement symbols
• BCP: Regenerate the Unicode conversion image
• DFSMSdfp: Check for an out-of-synch condition in the OAM configuration
• DFSMSdfp: Accommodate code 4 for empty objects in the IDCAMS LISTCAT command
• DFSMSdfp: Prepare for the encryption of data sets

z/OS V2R5 requires an IBM z13 or later to IPL. Therefore, the following upgrade actions for the IBM zEC12 and zBC12 processors are removed:

• Upgrade to an IBM zEnterprise EC12 or IBM zEnterprise BC12 server
• General recommendations and considerations for a zEC12 or zBC12 server
• Restrictions for a zEC12 or zBC12 server
• Actions you can take before you order a zEC12 or zBC12 server
• Migration and exploitation considerations for zEC12 and zBC12 server functions
• Accommodate functions for the zEC12 and zBC12 servers to be discontinued on future servers

Step 2.1 : Typical upgrade steps

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 V2R5. Good sources of information include:
   • z/OS Introduction and Release Guide
   • z/OS Planning for Installation
   • The z/OS Library at z/OS Internet Library.
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 V2R5. In this workflow, the actions you can perform on your existing system are identified by headings that say Actions to perform before installing z/OS V2R5. 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 V2R5.

   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."

3. Order and install coexistence and fallback service for any system that will share resources with a z/OS V2R5 system. (See the step called "Install coexistence and fallback PTFs." This service needs to be installed on all systems that will coexist with z/OS V2R3 and all systems that will be migrated to z/OS V2R5 (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 and install z/OS V2R5. If you use a ServerPac, refer to ServerPac: Installing Your Order. If you use a CBPDO, see z/OS Program Directory in the z/OS Internet library.
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 V2R5. (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 V2R5 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 V2R5. (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 V2R5 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 V2R4 or z/OS V2R3, you can exploit the functions introduced in z/OS V2R5.
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

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 V2R3 to z/OS V2R5, you must activate the migration checks for changes that occurred in both z/OS V2R4 and z/OS V2R5. If you are upgrading from z/OS V2R4 to z/OS V2R5, you need to activate only the migration checks for changes that occurred in z/OS V2R5. 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).

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:

• For information about System REXX customization, see the topic on System REXX in z/OS MVS Programming: Authorized Assembler Services Guide.
• For compiled REXX exec runtime availability, see the topic on Alternate Library for REXX customization considerations in z/OS Program Directory or see the product documentation that accompanies IBM Alternate Library for REXX.

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

Description:

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

• 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 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 OpenSSH
• 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 V2R5

Description:

This z/OSMF Workflow was derived from the Abstract for the z/OS Upgrade Workflow.

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

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 V2R5

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

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.

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 V2R5 and its servers. The z/OS V2R5 upgrade is ZOSV2R5; the server upgrades are shown in the table below.
   
   
   • 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 the table below. 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 V2R5 on an IBM z13 or later processor. For more information, see the 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 the following table.

Reference information

For more information, see the following references:

• For z/OS subsets, see z/OS Program Directory in the z/OS Internet library.
• For information about the SMP/E REPORT MISSINGFIX command, see z/OS SMP/E Commands.

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

Description:

Description

By installing coexistence and fallback PTFs on your pre-z/OS V2R5 systems, you allow the systems to coexist with z/OS V2R5 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 V2R5 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.

Steps to take

Before you introduce z/OS V2R5 into your environment, install coexistence and fallback PTFs on all pre-z/OS V2R5 systems with which your z/OS V2R5 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 V2R5 systems. Use your usual 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 V2R5 systems and specify a Fix Category (FIXCAT) value of IBM.Coexistence.z/OS.V2R5. 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

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.

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

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.

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

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.

Steps to take

Follow these steps:

1. Enter 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:

• For information about formatting sysplex couple data sets with the MAXGROUP and MAXMEMBER parameters, see z/OS MVS Setting Up a Sysplex.
• For information about the DISPLAY XCF command, see z/OS MVS System Commands.

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.2 : Upgrade actions for everyone before the first IPL of z/OS V2R5

Description:

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

Step 3.1.2.1 : Accommodate the z/OS V2R5 architecture level set and supported storage devices

Description:

Description

z/OS V2R5 is supported on the following IBM Z® servers:

• IBM z15™ models T01 and T02
• IBM z14™ (z14) models M01 through M05
• IBM z14™ Model ZR1 (z14 ZR1)
• IBM z13
• IBM z13s™

z/OS V2R5 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.

Steps to take

Follow these steps:

1. Determine whether the servers, control units, and machine facilities that you use are supported for z/OS V2R5. 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:

• z/OS Planning for Installation
• Release memorandum - RFA 58183 - 04/15/13 (IBM Guide 27.10) .

Instructions:

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

This step will be in the Complete(Override) state if the server is at least a z13, indicating that this requirement has been met.

This step will be in the Ready state if the server not a z13, z14 or z15, indicating that a higher server is required for z/OS V2R5.

Step 3.1.2.2 : Ensure that z/OS V2R5 is running as a guest under z/VM V7.1 if applicable

Description:

Description

Running z/OS V2R5 as a guest requires z/VM V7.1 or later.

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.

Steps to take

If you plan to run z/OS V2R5 under z/VM, ensure that you are running z/VM V7.1 or later. Otherwise, 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 3.1.2.3 : Set up an IPCS environment

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.

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.

Reference information

For more information, see the following references:

• For more information about IPCS, see z/OS MVS IPCS Customization.
• For information about updating the logon procedure, see z/OS Program Directory in the z/OS Internet library.
• For information about setting up the JES2 IPCS environment, see z/OS JES2 Diagnosis.
• For information about setting up the JES3 IPCS environment, see z/OS JES3 Diagnosis.
• For information about running different levels of IPCS, see z/OS MVS IPCS 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.4 : Use IBM-supplied parmlib and proclib members

Description:

Description

Ensure that all new and changed parmlib and proclib members that are shipped in z/OS V2R5 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.

Steps to take

Follow these steps:

• For parmlib, add the data set pointed to by the z/OS V2R5 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.5 : Migrate /etc, /global, and /var system control files

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 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 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 step called "OCSF: Migrate the directory structure."
• DFSMSrmm.
• IBM Tivoli Directory Server (TDS). The LDAP server component uses /var/ldap.
• Infoprint Server. See the 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 V2R5 /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 V2R5 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.

Steps to take

Copy files from your old system to the z/OS V2R5 /etc, /global, and /var subdirectories, and then modify the files as required for z/OS V2R5. 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.6 : Update automation and procedures for changed and deleted messages

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.

Steps to take

Review the lists of changed and deleted messages in z/OS Release Upgrade Reference Summary. Update programs that automate based 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.7 : Rework and install user modifications

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 step "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.

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:

• For more information about z/OS XL C/C++ customization, see z/OS XL C/C++ User's Guide.
• For more information about DFSORT customization, see z/OS DFSORT Installation and Customization.
• For more information about HLASM customization, see HLASM Installation and Customization Guide.
• For more information about ISPF customization, see z/OS ISPF Planning and Customizing.

Instructions:

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

Step 3.1.2.8 : Reconnect non-IBM products

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.

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:

• For a list of independent software vendors (ISVs) that support z/OS, and announcements, testimonials, and other information, see IBM Z ISVs and service providers.
• For a directory of ISV products that support z/OS, see the Global Solutions Directory at Global Solutions Directory.

Instructions:

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

Step 3.1.2.9 : Reconnect subsystems

Description:

Description

If you use subsystems, 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.

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 V2R5 are identified with the FIXCAT IBM.TargetSystem-RequiredService.z/OS.V2R5

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.10 : Update operational and other procedures

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

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.11 : Verify that virtual storage limits are set properly

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.

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:

• Information about limiting storage use above the bar can be found in the Washington Systems Center flash 10165 at IBM Techdocs. Search for flash10165.
• Information about how to evaluate the real storage configuration can be found in the IBM Washington Systems Center (WSC) white paper z/OS Performance: Managing Processor Storage in an all Real Environment at z/OS Performance: Managing Processor Storage in an all “Real” Environment.
• For more information about controlling region size and region limits by using the IEFUSI exit, see z/OS MVS Initialization and Tuning Guide.
• For more information about the HONORIEFUSIREGION keyword, see z/OS MVS Initialization and Tuning Reference.
• Consider using the functions that are available through the SMFLIMxx parmlib member and REGIONX JCL keyword. See the following references: z/OS MVS Initialization and Tuning Guide and z/OS MVS JCL Reference.

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.12 : Back virtual storage with sufficient real and auxiliary storage

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.

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.13 : Update your check customization for modified IBM Health Checker for z/OS checks

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 V2R5:

• ZOSMIGV2R4_NEXT_WLM_ServCoeff
• IBMCS,ZOSMIGV2R4_NEXT_CS_DCAS_NTVSSL
• IBMCS,ZOSMIGV2R4_NEXT_CS_TN3270_NTVSSL
• IBMCS,ZOSMIGV2R4_NEXT_CS_FTPSRV_NTVSSL

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.

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, such as in HZSPRMxx parmlib members.
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.14 : Remove deleted data sets, paths, and references

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.

Steps to take

Using the tables in this workflow step as a guide, remove data sets and paths that do not exist in the current release (z/OS V2R5). 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.

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.15 : Add references to new data sets and paths

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.

Steps to take

Using the tables in this workflow step 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 that follow, the data sets are identified as distribution library (DLIB) data sets or target library data sets.

Reference information

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

Description:

This topic describes hardware upgrade actions. The information in this topic is not specifically related to upgrading to z/OSV2R5; 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

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 ™ 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.

The IBM z15 Model T02 (z15 T02) is the newest addition to the IBM z15 family. The z15 T02 is designed for clients who do not need the capacity of the larger T01 models.

The IBM z15 family of mainframes includes the following hardware models:

• Model T01 (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. This system is configurable as a one-to-four 19-inch frame system.
• Model T02 (machine type 8562), with five CPC size features (one or two drawers). The system is configurable as a 19-inch frame system.

In this workflow, references to "z15" pertain to all models of the IBM z15, including the z15 T02, unless otherwise noted.

z/OS base support for specific z15 functions depends on the z/OS release. Not all z15™ functions are available in every z/OS release, as shown in the tables:

• 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 z/OS V2R1 support, see the Table Notes. Information about finding the appropriate PTFs is provided in the workflow step "Actions you can take before you order an IBM z15 server" and its substeps.
• 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. Information about the applicable upgrade actions is provided in the steps and substeps for "Actions you can take before you order an IBM z15 server" and "Actions you can take after installing an IBM z15 server."

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 of 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.

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

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 V2R3, z/OS V2R4, and z/OS V2R5.

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.

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.

• "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

Description:

As you plan your migration 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

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

Description:

Description

The base support for the z15™ is delivered through service (PTFs). To determine which PTFs are required, obtain 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 command to identify the missing PTFs on your system for the IBM z15. For example:

				SET BDY(GLOBAL).				REPORT MISSINGFIX ZONES( target_zone)				FIXCAT(IBM.Device.Server.z15*.**).				

The following SMP/E FIXCATs identify the PTF support for the IBM z15:

• For the IBM z15 Model T01 server:
  • FIXCAT for required service is: IBM.Device.Server.z15-8561.RequiredService
  • FIXCAT for recommended service is: IBM.Device.Server.z15-8561.RecommendedService
  • FIXCAT for exploitation is: IBM.Device.Server.z15-8561.Exploitation
• For the IBM z15 Model T02 server:
  • FIXCAT for required service is: IBM.Device.Server.z15T02-8562.RequiredService
  • FIXCAT for recommended service is: IBM.Device.Server.z15T02-8562.RecommendedService
  • FIXCAT for exploitation service is: IBM.Device.Server.z15T02-8562.Exploitation

The RequiredService FIXCATs identify the minimum PTFs that are required to use z/OS on the z15 --- you must install these PTFs. The RecommendedService FIXCATs group the PTFs that the IBM Service organization recommends that you install. The Exploitation FIXCATs include the new functions that are provided on the z15, which you can choose to exploit.

The Preventive Service Planning (PSP) buckets for the z15 servers are identified by an upgrade name and one or more subset names, as follows:

• For the IBM z15 Model T01 server, the PSP Upgrade name is 8561DEVICE, and the z/OS support can be found in Subset 8561/ZOS.
• For the IBM z15 Model T02 server, the PSP Upgrade name is 8562DEVICE, and the z/OS support can be found in Subset 8562/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

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

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

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

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

Description:

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

Step 3.2.1.2.1 : z15 servers in a sysplex

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 z13 or later 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.
• Servers 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.2 : HCD and HCM support for the z15

Description:

Description

As with previous servers, hardware can be defined on any supported operating system 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.3 : Actions you can take before you order an IBM z15 server

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)

Description:

Description

The Large Systems Performance Reference (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.

The LSPR is available in IBM Resource Link™ at the following site: Large Systems Performance Reference for IBM Z.

Instructions:

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

Step 3.2.1.3.2 : Implement an STP timing network

Description:

Description

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.3 : Upgrade from unsupported hardware features to newer technology

Description:

Description

This action is needed because specific features are not available on the z15™ server.

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.3.4 : Carry forward hardware features

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.5 : Determine the level of cryptographic support you require on a z15 server

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 V2R5, the base level of ICSF (HCR77D2) is included in z/OS.

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

Instructions:

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

Step 3.2.1.3.6 : Install the necessary z/OS service

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. To do so, specify IBM.Device.Server.* and IBM.Function.* as the fix categories for the REPORT MISSINGFIX command. This command identifies not only the 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 descriptions of 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 Model T01:
  • IBM.Device.Server.z15-8561.RequiredService
  • IBM.Device.Server.z15-8561.Exploitation
  • IBM.Device.Server.z15-8561.RecommendedService
• For the IBM z15 Model T02:
  • IBM.Device.Server.z15T02-8562.RequiredService
  • IBM.Device.Server.z15T02-8562.Exploitation
  • IBM.Device.Server.z15T02-8562.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 the Recommended Service fix category for your z15 server, you can, alternatively, find lists of the recommended PTFs in 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 Model T01, the PSP Upgrade name is 8561DEVICE, and the z/OS support can be found in Subset 8561/ZOS.
• For the IBM z15 Model T02, the PSP Upgrade name is 8562DEVICE, and the z/OS support can be found in Subset 8562/ZOS.

Instructions:

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

Step 3.2.1.3.7 : Run the CFSIZER tool

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.8 : Prepare for the new machine instruction mnemonics

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).

To help you associate the OPTABLE levels with IBM Z processor generations:

• HLASM APAR PH03536 defines OPTABLE names Z9 through Z14 as synonyms for ZS3 through ZS8.
• HLASM APAR PH00902 adds OPTABLE name Z15 and synonym ZS9.

Similarly, HLASM APAR PH00902 extends the MACHINE option to support various other names, based on short forms of the IBM machine name, such as zEC12 and z990. This APAR adds support for values in the form ARCH-n, to select the table that most closely corresponds to the ARCH(n) option in IBM compilers for C, COBOL, and PL/I. For example, both MACHINE(z15) and MACHINE(ARCH-13) are supported with the installation of HLASM APAR PH00902.

Instructions:

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

Step 3.2.1.3.9 : Learn about the HiperDispatch enhancement

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 base for z/OS V2R5 and z/OS V2R4 base. It can be added to z/OS V2R3 by installing the PTF for APAR OA55935. It is identified by the following SMP/E fix categories:

• For the IBM z15 Model T01, use fix category IBM.Device.Server.z15-8561.Exploitation
• For the IBM z15 Model T02, use fix category IBM.Device.Server.z15T02-8562.Exploitation

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 z/OS SLIP enhancements

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.11 : Accommodate the changes to default ARCH and TUNE level

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.

It is recommended that you upgrade to the IBM z/OS XL C/C++ V2.4.1 web deliverable for IBM z/OS V2.4, which became available on December 13, 2019. This new compiler supports the C11, C++11, and C++14 language standards. It combines the C language (Clang) infrastructure with the existing advanced optimization technology in the IBM XL compilers to exploit the latest z/Architecture, including the IBM z15. The z/OS XL C/C++ V2.4.1 compiler supports English messages and EBCDIC and ASCII execution character sets, and generates AMODE 64 code, making it ideal for z/OS UNIX users who are porting applications from distributed platforms.

The XL C/C++ V2.4.1 web download is available as a no-charge add-on for installations that have enabled the XL C/C++ compiler (an optionally priced feature) on z/OS V2.4 only. It coexists with and does not replace the base XL C/C++ V2.4 compiler. XL C/C++ V2.4 and V2.4.1 compilers are both designed to be used independently and are also serviced and supported independently.

For the latest offerings from the IBM XL C/C++ compiler family on z/OS, see the z/OS downloads page at z/OS downloads.

Instructions:

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

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

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 V2R3, z/OS V2R4, and z/OS V2R5 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 the z/OS zlib PTFs for this support, which are identified by the following SMP/E fix categories:

• For the IBM z15 Model T01, use fix category IBM.Device.Server.z15-8561.RequiredService
• For the IBM z15 Model T02, use fix category IBM.Device.Server.z15T02-8562.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.

For more information about the zBNA tool, see IBM Techdoc PRS5132 at IBM Z Batch Network Analyzer (zBNA) Tool.

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.13 : Upgrade the I/O Configuration Program (IOCP) for z15

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 the following SMP/E fix categories:

• For the IBM z15 Model T01, use fix category IBM.Device.Server.z15-8561.RequiredService
• For the IBM z15 Model T02, use fix category IBM.Device.Server.z15T02-8562.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

Description:

These are migration 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 notes for Table 1 in the step "Migrate to an IBM z15 server."

Step 3.2.1.4.1 : FICON Express16SA

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.

Note:FICON Express16SA is not supported on the z15 Model T02 server.

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)

Description:

Description

Beginning with the IBM z14 server, 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)

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

Description:

Description

New for the z15, this enhancement can provide faster operating system IPL, middleware and workload restart and recovery, and planned shutdown. During a boost period that applies 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.

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

Note: The IBM z15 Model T02 does not provide the System Recovery Boost Upgrade capability to add additional "temporary capacity" zIIP processors. Thus, the z15 Model T02 does not offer System Recovery Boost Upgrade Feature Codes 9930 and 6802.

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

Description:

Description

In the support element (SE) 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. You must grant the SE the authority to accept the BCPii APIs that flow 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 more information, see the workflow step named "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)

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 (SMF 74.10), which was previously known as Storage Class Memory (SCM) Statistics, 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

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

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 is available exclusively on supported IBM Z servers. Charges that are related to both hardware and software depend on the duration of the temporary enablement and the capacity enabled.

Beginning with IBM z15 Model T02, prepaid tokens for On/Off Capacity on Demand (On/Off CoD) will expire 5 years after the LICCC expiration date.

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 support for TLS 1.0 and TLS 1.1 for SE, HMC, and OSC

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

Description:

Description

The IBM z14™ (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. The following table 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.

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

The exploitation of specific z14 server functions depends on the z/OS release. The following table lists the 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.

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

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.

Steps to take

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

• "General recommendations and considerations for a z14 server"
• "Restrictions for a z14 server"
• "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, which is available online in Resource Link™.

Step 3.2.2.1 : General recommendations and considerations for a z14 server

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 "Upgrade to an IBM z13 or IBM z13s server" and its substeps.
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

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 the tables in the workflow step "Upgrade to an IBM z14 server" for:
   • Summary of which z14 server functions are included in the base support for z/OS V2R2, z/OS V2R3, and z/OS V2R4.
   • Summary of which z14 server functions can be exploited in z/OS V2R2, z/OS V2R3, and z/OS V2R4.

   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.

     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 IBM z14 and later servers.
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 step called "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

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 "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. For more information, see the following 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. ¹

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 "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

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 notes for Table 1 in the workflow step "Migrate to an IBM z14 server."

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 the 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 named "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

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

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.

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

1. PTFs for base support have the following fix categories:
   • For z13: IBM.Device.Server.z13-2964.RequiredService
   • For z13s: IBM.Device.Server.z13S-2965.RequiredService

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

1. PTFs for base support have the following fix categories:
   • For z13: IBM.Device.Server.z13-2964.RequiredService
   • For z13s: IBM.Device.Server.z13S-2965.RequiredService
2. PTFs for exploitation have the following fix categories:
   • 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.