Step 1 : 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 the z/OS V2R5 Upgrade Workflow, you can perform a z/OS V2R5 upgrade as an interactive, step-by-step process. The workflow uses the latest functions in z/OSMF to provide a smooth upgrade experience for each new release of z/OS.

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

IBM no longer provides a z/OS Migration publication. Since z/OS V2R2, the preferred method for learning about upgrade actions is the z/OS Upgrade Workflow. Discovering, performing, and verifying many upgrade actions through the z/OSMF Workflows UI instead of a more traditional book format allows for a tailored and specific upgrade path that is associated with a particular system.

Along with the change of format—from a book to a workflow—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 understood to mean moving software from one server to another. When you perform the actions that are described in this workflow, you are upgrading z/OS to a newer level of function than the prior release. Thus, upgrade is the appropriate term for what this workflow does.

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 4.0 (March 2023)

This new version of the z/OS V2R5 Upgrade Workflow is installed when you apply the PTF for APAR OA64212.

Version 4.0 replaces the previous version, Version 3.0, which was provided by IBM in April 2022.

New information

The following upgrade actions are new.

• DFSMSdfp: Accommodate change to SAF checking during open of VSAM volume data sets
• IP Services: Ensure that FTP users have access to JES mode
• IP Services: Implement the AT-TLS server-allowed KEX curves list
• JES2: Ensure that programs access checkpoint data in 64-bit storage
• SDSF: Plan to stop using a non-scrollable main panel
• Security Server: Stop sharing RACF databases between z/OS and z/VM
• Security Server: Determine whether IRRUT200 users require READ access to IDCAMS
• XL C/C++: Update programs to use the __NORETURN macro

Changed information

The following upgrade actions are changed.

• The following general upgrade actions are changed:
  • Remove deleted data sets, paths, and references
  
  
• The following IBM z16 upgrade actions are changed:
  • Evaluate the new extended counters in CPU Measurement Facility
  
  
• The following z/OS upgrade actions are changed:
  • BCP: Evaluate the changed default for system logger use of IBM zHyperwrite
  • SNA services: Stop using the VTAM Common Management Information Protocol
  • IP Services: Make changes for Netstat enhancements
  • SDSF: Use dynamic statements for ISFPARMS to avoid reassembly

Summary of changes for z/OS V2R5 Upgrade Workflow, Version 3.0 (April 2022)

This new version of the z/OS V2R5 Upgrade Workflow is installed when you apply the PTF for APAR OA62703.

Version 4.0 replaces the previous version, Version 3.0, which was provided by IBM in October 2021.

New information

This workflow contains the steps for upgrading a z/OS system in support of the IBM z16™ server.

Changed information

The following upgrade actions are changed for z/OS V2R5 Upgrade Workflow, Version 3.0:

• BCP: Removal of support for user key common areas

Summary of changes for z/OS V2R5 Upgrade Workflow, Version 2.0 (October 2021)

This new version of the z/OS V2R5 Upgrade Workflow is installed when you apply the PTF for APAR OA61406.

Version 2.0 replaces the previous version, Version 1.0, which was provided by IBM in April 2021.

New information

The following upgrade actions are new for z/OS V2R5 Upgrade Workflow, Version 2.0:

• Update processing to include usage of new SMF record types
• BDT: Plan for the removal of the Bulk Data Transfer (BDT) File-to-File feature
• BDT: Plan for the removal of the Bulk Data Transfer (BDT) SNA NJE feature
• SNA and IP services: Prepare for the removal of support for LSA and LCS devices
• IP Services: Prepare for the removal of support for OSA DEVICE/LINK/HOME configuration
• ICSF: Update references to deprecated ICSF SMF and PKDS header fields
• DFSMSdfp: Plan for the removal of z/OS Global Mirror Extended Remote Copy (XRC)
• DFSMSdfp: Update the OAM FSDELETE table
• ICSF: Negotiation of the extended master secret extension enabled by default
• JES2: Respond to PENCRYPT conflict notifications
• NFS: Update references to NFS samples, macros, and utility source parts
• RMF: Determine updates for RMF structural changes
• SDSF: Update path environment variables to refer to the 64-bit JVM
• Security Server: Be aware of new restriction on the use of certificates with long RDNs
• Security Server: Accommodate the removal of RACF TSO/E HELP text
• Security Server: Define a PTKTDATA profile to allow PassTicket-based password changes
• Security Server: Remove RACF dynamic classes named IZP and ZOWE

Changed information

The following upgrade actions are changed for z/OS V2R5 Upgrade Workflow, Version 2.0:

• Add references to new data sets and paths
• Remove deleted data sets, paths, and references
• Accommodate new address spaces

Summary of changes for z/OS V2R5 Upgrade Workflow, Version 1.0 (April 2021)

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: Remove references to deprecated ports for the RMF DDS server
• SDSF: Use only SAF-based security to protect SDSF functions
• 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
• BCP: Removal of support for user key common areas
• 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
• JES2: Activate z22 mode
• 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 1.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 1.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 1.3 : Elements and features that do not have upgrade actions

Description:

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

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

Instructions:

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

Step 2 : 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 3 : General upgrade actions for z/OS V2R5

Description:

This section of the workflow describes general upgrade actions that apply to everyone, regardless of which z/OS elements and features you use.

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 z/OS elements and features you use.

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

Description:

This section of the workflow describes general upgrade actions that you can perform on your current (old) system. You do not need the z/OS V2R5 level of code to make these changes, and the changes do not require the z/OS V2R5 level of code to run after 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 upgrade. 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), which allows 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 Fix Category (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 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.

Obtain the latest PTFs for the z/OS Upgrade Workflow

Updates and fixes for the z/OS V2R5 Upgrade Workflow are delivered through the standard z/OS service process. To obtain the latest PTFs for the z/OS V2R5 Upgrade Workflow, run the SMP/E REPORT MISSINGFIX command on your z/OS systems and specify a FIXCAT value of IBM.Coexistence.z/OS.V2R5. The z/OS V2R5 Upgrade Workflow can be run on z/OS releases V2R3, V2R4, and V2R5.

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 : Update processing to include usage of new SMF record types

Description:

Description

As of z/OS V2R3, SMF supports both Standard record types (0-255) and Extended or Standard record types (0-2047). As z/OS exploits more SMF record types above 255, ensure that your collection and usage of SMF records is up-to-date and continues to meet the needs of your business.

As of z/OS V2R5, JES2 generates SMF record type 1153 for JES2 resource usage and performance data.

Information about this upgrade action

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

Steps to take

Do the following:

1. Ensure that your SMFPRMxx TYPE specification is set to collect any newly generated SMF record types.


2. Review how you have coded the TYPE option in the SMF dump utilities IFASMFDP and IFASMFDL. The default for the dump utilities is TYPE(0:2047). If you have explicitly coded TYPE(0:255) and you want to include all of the recorded record types, verify that you use the default, or explicitly code TYPE(0:2047). Otherwise, record types above 255 are excluded from the selection criteria.

Note: When you code an IFASMFDL ARCHIVE or DELETE request, take care to include (explicitly or implicitly by default) all of the record types that exist in the log stream in the requested date/time range. IFASMFDL will fail ARCHIVE or DELETE requests with message IFA845I if any of the records in the requested date/time range do not match the selection criteria.

Reference information

For more information, see z/OS MVS System Management Facilities (SMF).

Instructions:

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

Step 3.1.1.6 : 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.1.7 : Remove dependencies on unsupported z/OS national language translations

Description:

Description

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

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

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

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

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

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

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

Information about this upgrade action

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

Steps to take

Stop using the removed languages from the affected elements.

Reference information

None.

Instructions:

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

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

• 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. 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.
  • High Level Assembler (HLASM).
  • ISPF configuration table.
  • SDSF. For more information, see the workflow 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 plan 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
• IBMVSM,VSM_CHECKREGIONLOSS

The following health checks were added by IBM in z/OS V2R4:

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

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

• IBMUSS,ZOSMIGV2R3_NEXT_USS_SMB_DETECTED
• IBMCS,CSVTAM_CSM_STG_LIMIT

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

• ZOSMIGV1R12_INFOPRINT_INVSIZE

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 V2R4). Also, remove references to them. You might find references in the following places:

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

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

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

The following data sets and paths were deleted from z/OS V2R5.

The following data sets and paths were deleted from z/OS V2R4.