Planning to upgrade

A significant part of the upgrade process is planning. This section summarizes the preparation that helps you to upgrade CICS® Transaction Server for z/OS®.

Preparation includes the following actions:
  • Ensure that all the correct people are involved in the plan.
  • Understand the drivers to upgrade, and the constraints on change, for your environment, and build this understanding into an upgrade strategy.
  • Check prerequisites of the new release and its compatibility with other products that you use.
  • Review your environment so that you can assess the impact of the new release and ensure that the plan for upgrade is complete.
  • Understand what changed between releases of CICS TS.

Your plan is iterative. The project team refines a plan of action and builds a critical path of activities as it finds out more about the tasks that are involved and the impact of changing the release of CICS TS.

Actions

Action Mandatory or optional?
Assess the new release or continuous delivery capability Mandatory
Clarify the driving forces for upgrade Optional, but recommended
Consider the cost of upgrade Optional, but recommended
Consider the timing Optional, but recommended
Build your upgrade project team Optional, but recommended
Choose your edition of CICS Transaction Server for z/OS Mandatory
Check hardware and software prerequisites as well as compatibility with other IBM® products Mandatory
Check downward compatibility with older releases of CICS Mandatory
Check compatibility with your vendor products Optional, but recommended
Review your applications Optional, but recommended
Review your CICS regions Mandatory
Review the CSD compatibility between different CICS releases Optional, but recommended
Review the service level of CICS Transaction Server for z/OS Optional, but recommended
Review the changes in CICS Transaction Server for z/OS Optional, but recommended
Develop your upgrade strategy Optional. but recommended

Assess the new release or continuous delivery capability

Review new or enhanced features that are delivered with the new release to help you identify the driving forces for upgrade and plan for your system capabilities. See What's New and the Announcement letter. For features that are available on existing releases through service, see CICS continuous delivery features.

Clarify the driving forces for upgrade

Clarify what motivations are driving the upgrade of CICS TS. Is it to keep current? Is it a desire to use a new capability? Is it an opportunity to upgrade only some of your regions, and use different releases for different business needs? Is it a requirement so that you can meet regulatory constraints? Is it a necessity as a result of the removal or announcement of stabilization of CICS TS features that you have to migrate to new solutions? Is it part of a bigger upgrade strategy? Your reasons affect both your choice of CICS release, and when and how you upgrade.

You can choose to run some of your regions at a newer level and leave some of them at your current level. This gives you flexibility to provide access to the latest features for some parts of your business, without having to plan an upgrade of the entire environment. See Upgrading CICS to use multiple releases concurrently for an example.

Consider the cost of upgrade

The cost of upgrade includes but is not limited to:
  • The cost of upgrading the level of operating system, to support the new release of CICS TS.
  • The cost and risk of implementing prerequisite upgrade and maintenance of other tools and packages.
  • The cost and risk associated with upgrading CICS TS, especially in the planning and execution of that update.
  • Some new features require new configurations, or changes to existing configurations, applications, and even development processes within your organization.
  • The cost of staff education and re-education.

Consider the timing

When you think about the schedule for upgrade, factor in your deadlines and key business dates, and any windows of change for the business infrastructure.

Build your upgrade project team

Upgrading is a collective effort. You must ensure that the key stakeholders are ready to support the project. Gather a team that includes the following roles:
  • Your technical representatives from roles such as system programming, application programming, security, and operations
  • Business representatives for the lines of business that are affected by the upgrade
  • Input from vendors or Business Partners whose products work with CICS TS.

Choose your edition of CICS Transaction Server for z/OS

CICS Transaction Server for z/OS is provided in three editions: CICS Transaction Server (the base edition), Developer Trial to use for a limited trial, and Value Unit Edition to use to run specific workloads with a different pricing model. As part of your planning, choose which editions to use.
Base edition
This is the full edition of CICS Transaction Server for z/OS.
Developer Trial
This edition is a no-charge evaluation version. It does not start the single-version charge (SVC) clock. Use this edition to access and explore the new technology in the new release, without having to go through a full upgrade. You can upgrade from Developer Trial to either Value Unit Edition or the full product, without having to reinstall. There are some restrictions on this edition of the product; see Developer Trial and Value Unit Edition for details.

For information about what is involved in moving from Developer Trial to a full edition, see Upgrading from Developer Trial.

Value Unit Edition
Consider this edition for eligible workloads, such as new Java™ workloads, that can qualify for a pricing model that is different from the full product. For more information about eligibility, see the CICS TS announcement letter on the IBM Offering Information web page.

Check hardware and software prerequisites as well as compatibility with other IBM products

You can create a report that includes the requirements for your target release of CICS TS by entering the product name CICS Transaction Server and selecting the latest version on the Detailed system requirements page. The report shows hardware, Hypervisor, and operating system requirements, and any requirements for supported software. You can choose to show only product releases, or include interim service fixes. The Supported Software report shows prerequisite levels for a broad range of IBM products, including development tools, Java, databases, application servers, messaging products, event management, and problem determination tools. Any requirements, such as APARs that are needed to make the software compatible, are listed in the notes or additional information in the report.

Ensure that the latest levels of service are applied to each IBM product listed. In some cases, a specific version of a product might be required to take advantage of new functions in CICS TS.

Table 1. Direct links to the detailed system requirements pages on IBM Software Product Compatibility Reports web site
Product Software Product Compatibility Reports - Detailed system requirements
CICS TS
CICS TS Value Unit Edition
CICS TS Developer Trial
CICS TS build toolkit
CICS Transaction Server resource builder

Check downward compatibility with older releases of CICS

If you are running or plan to run multiple versions of CICS in the same z/OS LPAR, check that the target release is downward compatible with older releases that you are still running. For example, assuming that currently in your production z/OS LPAR, you have a CICS TS 5.5 SDFHLPA library in the MVS™ link pack area (LPA) and a CICS TS 5.5 version of the library SDFHLINK in the LNKLIST, can you use the CICS TS 6.1 libraries in the LINKLIST and LPA instead of the CICS TS 5.5 libraries?

You can run CICS TS 6.1 regions in parallel with older CICS regions within the same LPAR if the following conditions are met:
  • Ensure that the eight CICS LPA-required modules that are installed in the LPA within the LPAR are from your CICS TS 6.1 libraries. These mandatory LPA modules are downward compatible and your older CICS TS systems will work with these modules.
    The eight CICS LPA-required modules are listed below and are supplied in hlq.SDFHLPA:
    • DFHCSVC
    • DFHDSPEX
    • DFHDUMPX
    • DFHIRP
    • DFHSSEN
    • DFHSSGC
    • DFHSSWT
    • DFH99SVC
    Note: Although all LPA-required modules are compatible with earlier releases of CICS, LPA-eligible modules, which are listed in member DFH$UMOD supplied in hlq.SDFHSAMP, are not required to be in the LPA, and are not guaranteed to be downward compatible. Therefore, they can be used only by the release of CICS to which they relate. For example, if you currently have the CICS TS 5.5 versions of LPA-eligible modules in the LPA, you must run with LPA=YES for your CICS TS 5.5 regions and LPA=NO for your CICS TS 6.1 regions. The LPA system initialization parameter applies only to the LPA-eligible modules and not to the eight LPA-required modules in SDFHLPA. If you have two releases, only one of them can specify LPA=YES. For more information, see LPA-required and LPA-eligible modules.
  • As for LINKLIST, except the modules for trace and dump formatting such as DFHPDnnn, DFHTGnnn, DFHTRnnn, DFHTTnnn), which are release dependent, the CICS TS 6.1 modules in SDFHLINK are compatible with earlier releases of CICS so they can be used with CICS TS 5.5 and earlier.
    You should leave the release-dependent modules in the LINKLIST for use only with relevant CICS release. The last three numbers in a release-dependent module name indicate the release of CICS as follows:
    740
    CICS TS 6.1
    730
    CICS TS 5.6
    720
    CICS TS 5.5
    710
    CICS TS 5.4
    700
    CICS TS 5.3
    690
    CICS TS 5.2

    For more information, see CICS- and CICSPlex SM-supplied modules required in the MVS linklist.

Check compatibility with your vendor products

When you assess a product for its compatibility with your target release, typically, it is in one of the following categories:
  • It is supported without change on your target release.
  • It requires a compatibility fix, either to CICS TS or to the product itself.
  • It must be upgraded.
The IBM Business Partner products that are supported at each in-service CICS release are listed at Business Partner Application Showcase. ISVs and service providers shows the software developers who indicate that their products support levels of z/OS. In addition to vendor compatibility with z/OS, you should always ask your vendor the following questions to determine if the vendor product is compatible with CICS:
  • Does the current version of the vendor product support the target CICS release and version?
  • Are any PTFs required in the vendor product or in CICS?
  • Can a new version of vendor code be installed in current release?
  • What actions (Hold actions) need to occur: for example, recompiling exits, or upgrade steps?

During the upgrade to a new release of CICS, z/OS, Db2®, IMS, or to a new IBM Z platform, if a problem is found with an IBM product, an APAR is likely to be created; if a problem is found with a vendor product, IBM Support often creates technical documents that include the problem description and a solution. See Upgrading information for CICS when changing releases of CICS, z/OS, Db2 or IMS to find these documents.

Review your applications

Upgrading can affect applications. The application programming interface or system programming interface might change between releases. There are often changes in the behavior of key resources. Some programs, such as installed CICS exits, almost always need to be recompiled for a new release. Other programs might benefit from a new version or being recompiled. Reviewing your applications helps you to answer the following questions:
  • Which applications are hosted in this region?
  • Which applications use these resources?
  • Which applications are affected by this change?
  • If I upgrade this region, which applications are affected?
  • If I upgrade this application, which regions are affected?

CICS Interdependency Analyzer can help with application analysis.

For each application, create a checklist:

  • Name
  • Owners: business, development, and infrastructure
  • Supplier: in-house or vendor
  • Execution model: single region or multiple region
  • Regions hosted
  • Current release and target release
  • Languages
  • CICS components
  • Resource definitions
  • CICS exits
  • Other products, applications, and services
  • Automation
  • Test suite: what testing is required before and after the upgrade?
  • Offline and batch interactions

Review your CICS regions

You need to know what is running in each current CICS region. Ensure that you include all regions in your check, even regions that haven't been started for some time. If you chose to partially upgrade and use a mix of releases, review the implications of running CICS regions across mixed releases. You can use CICS Interdependency Analyzer to analyze regions.
  • Check STEPLIB and DFHRPL libraries
  • Check CSD lists. Check these lists against your running regions. Sometimes resources such as LIBRARY definitions are added dynamically.
  • Check z/OS UNIX System Services and bundle definitions for application and platform resources.
  • Check the CICSPlex® SM configuration.
  • Check CICS statistics and monitoring data: what transactions are running and which applications do they belong to?
  • Does the application run across the TOR, AOR, FOR configuration of multiple regions? If so, consider the implications for transaction routing, function shipping, or DPL.

Review the CSD compatibility between different CICS releases

You can share the CICS system definition data set (CSD) between different CICS releases by using the appropriate compatibility groups. Review Table 1 for the compatibility groups that are required when you migrate from one release to another.

Review the service level of CICS Transaction Server for z/OS

Organizations that are up-to-date with service typically encounter fewer problems during the upgrade process. Gather information about the service levels in your current environment. You might want to apply fixes and enhance your CICS capability with any new function that was delivered through service as part of CICS continuous delivery.

For a summary of the new function delivered through service in each release, see CICS continuous delivery features.

Review the changes in CICS Transaction Server for z/OS

A key part of upgrading is understanding the impact of changes from your current release. Changes between releases summarizes the changes to the externals of CICS TS across all in-service versions.

Develop your upgrade strategy

Consider whether you plan to upgrade all regions at the same time, or phase your upgrade. Assuming that minimum downtime is your goal, there are various ways to approach the upgrade.

Do you want to leave some regions running at your current release?
For example, you might have an application that cannot run on your target release of CICS TS. Alternatively, you might prefer to run some applications on a newer release and rapidly pick up new features for those applications, while leaving the rest of your environment in its current state. For an example of an upgrade that is based on this approach, see Upgrading CICS to use multiple releases concurrently.
Will a workload run while the upgrade takes place?
If this is your strategy, consider the following questions:
  • Can your workload cope when the routing regions, target regions, or both are closed down for upgrading? Are alternative target regions available to run the work? Do the remaining routing and target regions have a sufficiently high value for the MXT system initialization parameter to manage the additional throughput?
  • Does your environment contain an FOR? If so, when this is shut down for an upgrade, there will be no access to the files. Are the consequences of this loss of access fully understood?
  • Does your environment have any QORs or regions that own Db2 or DBCTL connections (for example)? Are these regions single points of failure? What is the impact of closing these regions for upgrading?
  • Will you prepare all the components for upgrade offline, before you take them down?
  • How many CMASs for each release of CICS TS are active on your LPAR? During migration, new CMAS might be added temporarily. The CMAS range is 13 through 24, depending on the value you set for the z/OS MAXCAD parameter. For more information, see Specifying each CMAS correctly in IEASYSxx.
  • Are you aware of the potential impact of a phased migration on a running workload? For an example of an upgrade that is based on this approach, see Upgrading CICS with a running workload.