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.

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

Description:

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

Introducing the z/OS V2R4 Upgrade Workflow

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

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

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

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

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

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

Usage tips

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


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


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

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

New information

The following upgrade actions are new:

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

Changed information

The following upgrade actions are changed:

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

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

New information

The following upgrade actions are new:

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

Changed information

The following upgrade actions are changed:

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

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

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

New information

The following upgrade actions are new:

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

Changed information

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

Changes in previous versions of this workflow

New information

New general upgrade actions:

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

New BCP actions:

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

New BookManager® READ action:

• Remove any dependencies on BookManager READ from your system

New Common Information Model (CIM) actions:

• CIM: Accommodate the default change from HTTP to HTTPS

New Communications Server actions:

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

New Cryptographic Services actions:

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

New DFSMS actions:

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

New Distributed File Service action:

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

New HCD actions:

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

New HCM action:

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

New High Level Assembler (HLASM) action:

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

New IBM z/OS Management Facility action:

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

New Infoprint Server actions:

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

New ISPF action:

• ISPF: Plan for the removal of Workstation Agent

New JES2 actions:

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

New JES3 action:

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

New Library Server action:

• Stop using Library Server

New OSA Support Facility (OSA/SF) action:

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

New RMF action:

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

New Security Server actions:

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

New SMP/E action:

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

New TSO/E action:

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

New z/OS UNIX actions:

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

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

Changed information

The following information is changed:

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

• Changed general action:

  • Migrate /etc, /global, and /var system control files

• Changed BCP action:

  • BCP: Removal of support for user key common areas

• Changed Infoprint Server action:

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

• Changed Security Server action:

  • Check for previously defined classes HBRADMIN, HBRCONN, or HBRCMD

• Changed z/OS UNIX action:

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

Deleted information

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

Step 2.1 : Typical upgrade steps

Description:

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

1. Learn about z/OS V2R4. Good sources of information include:
   • 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 V2R4. In this information, the actions you can perform on your existing system are identified by headings that say Actions to perform before installing z/OS V2R4. Note that not all of the actions are required. Some depend on your environment, configuration, and workload, and are identified accordingly. These actions should be made to, or copied (cloned) to, all existing systems that will be migrated to z/OS z/OS V2R4.

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

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

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

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

   The upgrade is now complete.

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

Instructions:

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

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

Description:

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

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

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

• Migration checks are inactive by default.
• The names of migration checks begin with the characters ZOSMIG. Following this prefix is a value to help you plan the timing of the upgrade action, as follows:

  ZOSMIGVvRr_NEXT

  Upgrade action is recommended, but will become a required upgrade action in the release after VvRr.

  ZOSMIGVvRr_NEXT2

  Upgrade action is recommended, but will become a required upgrade action two releases after VvRr.

  ZOSMIGVvRr

  Upgrade action is required in the release indicated by VvRr.

  ZOSMIGVvRrPREV

  Upgrade action is required in the release indicated by VvRr and in prior releases, with the appropriate service.

  ZOSMIGREC

  Upgrade action is recommended for the foreseeable future. The upgrade action might never be required.

  ZOSMIGREQ

  Upgrade action that is recommended now, but will be required in a future release.

  Note:

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

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

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

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

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

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

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

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

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

System REXX considerations

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

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 V2R2 to z/OS V2R4, the following z/OS elements and features do not have upgrade actions to perform:

• Alternate Library for REXX
• BDT
• BDT File-to-File
• BDT SNA NJE
• Communications Server Security Level 3
• DFSORT
• EREP
• FFST
• GDDM
• GDDM-PGF
• GDDM-REXX
• IBM HTTP Server
• IBM 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 3 : General upgrade actions for everyone migrating to z/OS V2R4

Description:

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

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

Description:

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

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

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 V2R4 and its servers. The z/OS V2R4 upgrade is ZOSV2R4; the server upgrades are shown in Table 2.
   • FIXCAT values if you use the SMP/E REPORT MISSINGFIX command in conjunction with the FIXCAT type of HOLDDATA (as mentioned in the tip that follows). The FIXCAT values are shown in Table 2. Note:
     • The values shown are for the minimum support necessary for the servers. If you exploit additional functions on a server, the FIXCAT value will have additional qualifiers.
     • You must run z/OS V2R4 on a zEC12 or zBC12 or later. See the workflow step called "Ensure that you are using supported servers, storage controllers, and machine facilities."
2. Obtain the PSP buckets at Preventive Service Planning buckets or from IBMLink.
3. Review the PSP buckets and take whatever actions are prescribed.

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

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

Information about this upgrade action

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

Steps to take

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

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

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

Reference information

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

Instructions:

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

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

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.

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

Reference information

For more information, see the following references:

• 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.6 : Ensure that the CustomPac Installation Dialog is updated

Description:

Description

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

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

FTP over SSL (FTPS)

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

HTTPS

HTTPS To download your order securely by using HTTPS, you require the updated RECEIVE job that is provided in the CustomPac Installation Dialog level 27.20.00 or higher.

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

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

Information about this upgrade action

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

Steps to take

Follow these steps:

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

Reference information

For more information, see the following references:

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

Instructions:

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

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

Description:

Description

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

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

LINES=(999999,WARNING)

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

Information about this upgrade action

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

Steps to take

Follow these steps:

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

Reference information

For more information, see the following references:

• For ServerPac users who want more information about updating the CustomPac Installation Dialog, see "Updating Your Dialogs" in ServerPac: Using the Installation Dialog.
• For CustomPac users who want more information about updating the CustomPac Installation Dialog, see "Updating Your Dialogs" in CustomPac: Installation Dialog Reference.

Instructions:

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

Step 3.1.1.8 : Prepare for the discontinuation of tape delivery

Description:

Description

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

Information about this upgrade action

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

Steps to take

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

Reference information

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

Instructions:

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

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

Description:

Description

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

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

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

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

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

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

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

Information about this upgrade action

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

Steps to take

Stop using the removed languages from the affected elements.

Reference information

None.

Instructions:

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

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

Description:

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

Step 3.1.2.1 : Set up an IPCS environment

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.2 : 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 V2R4 are updated in your parmlib and proclib concatenations.

Information about this upgrade action

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

Steps to take

Follow these steps:

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

Reference information

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

Instructions:

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

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

Description:

Description

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

The following elements and features use /etc:

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

The following elements and features use /global:

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

The following elements and features use /var:

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

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

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

Information about this upgrade action

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

Steps to take

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

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

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

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

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

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

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

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

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

  Another example:

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

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

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

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

Reference information

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

Instructions:

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

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

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 on these messages and make other necessary accommodations.

Reference information

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

Instructions:

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

Step 3.1.2.5 : Rework and install user modifications

Description:

Description

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

Common types of user modifications are:

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

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

Information about this upgrade action

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

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.

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.6 : 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.7 : Reconnect subsystems

Description:

Description

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

Information about this upgrade action

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

Steps to take

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

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

Reference information

None.

Instructions:

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

Step 3.1.2.8 : Update operational and other procedures

Description:

Description

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

Information about this upgrade action

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

Steps to take

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

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

Reference information

None.

Instructions:

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

Step 3.1.2.9 : Verify that virtual storage limits are set properly

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.10 : 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.11 : 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 V2R4:

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

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

• IBMCS,CSVTAM_CSM_STG_LIMIT
• IBMUSS,ZOSMIGV2R3_NEXT_USS_SMB_DETECTED

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

• IBMISPF,ZOSMIGV2R3_Next_ISPF_GW_HTTPS

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

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

Information about this upgrade action

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

Element or feature:	Multiple.
When change was introduced:	General upgrade action not tied to a specific release.
Applies to upgrade from:	z/OS V2R3 and z/OS V2R2.
Timing:	Before the first IPL of z/OS V2R4.
Is the upgrade action required?	No, but recommended to ensure that your checks continue to work as you intend them to work.
Target system hardware requirements:	None.
Target system software requirements:	None.
Other system (coexistence or fallback) requirements:	None.
Restrictions:	None.
System impacts:	None.
Related IBM Health Checker for z/OS check:	See "Steps to take."

Steps to take

Follow these steps:

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

Reference information

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

Instructions:

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

---

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

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 following tables as a guide, remove data sets and paths that do not exist in the current release (z/OS V2R4). Also, remove references to them. You might find references in the following places:

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

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

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