For the latest information on upgrading to and from any versions of CICS TS, see CICS TS V5.6.

Conditions for running CICSPlex SM Version 5.2 and earlier releases concurrently

You can run CICSPlex® SM Version 5.2 and earlier releases concurrently, but you must take account of a number of conditions for compatibility.

The CICSPlex SM releases referred to in this information are the CICSPlex SM element of CICS® Transaction Server for z/OS® releases. They are not available as separate products. For example, CICSPlex SM Version 5.2 is the CICSPlex SM element of CICS Transaction Server for z/OS, Version 5 Release 2.

You can run CICSPlex SM Version 5.2, Version 5.1, Version 4.2, Version 4.1, Version 3.2, and Version 3.1 at the same time, with interconnected CMASs at different levels. The ability to do this allows gradual upgrading of the environment to Version 5.2. However, in CICS TS for z/OS, Version 5.2, a CICSPlex SM CMAS will run only in a CICS system at Version 5.2.

CICS systems (MASs) running the following supported CICS releases can be connected to CICSPlex SM Version 5.2: To be connected to CICSPlex SM Version 5.2, CICS systems must use the CICSPlex SM Version 5.2 MAS agent, so they must have the CICSPlex SM Version 5.2 libraries in their CICS JCL. For a CICS system running CICS TS for z/OS, Version 3.1, you must also apply the compatibility APAR PK17360 to the CICS system.

If you have difficulty running CICSPlex SM with CICS TS for z/OS, Version 3.2 because of a recursive 0c4 protection exception in module DFHSMSR, apply PTF UK43094 for apar PK77484 and restart the system.

If you have any CICS systems at the release levels listed here that are connected to an earlier release of CICSPlex SM, you are recommended to migrate them to the current release of CICSPlex SM to take full advantage of the enhanced management services.

If you want to manage CICS systems at an earlier release level than those listed here, connect them to a CMAS running at an earlier release level that supported those systems. This CMAS can be connected to your CICSPlex SM Version 5.2 CMAS, so that the older CICS systems are indirectly connected to the Version 5.2 CMAS.

The following conditions apply to environments in which CICSPlex SM Version 5.2 and earlier releases of CICSPlex SM are running concurrently:
  • For a CMAS and a MAS (including those MASs that act as Web User Interface servers) to communicate, they must be running at the same release of CICSPlex SM.
  • A CMAS running at Version 5.2 can be connected to a CMAS running at Version 5.2, Version 5.1, Version 4.2, Version 4.1, Version 3.2, or Version 3.1.
  • In a CICSplex that consists of CMASs at the Version 5.2 level and at one or more earlier levels, the maintenance point CMAS must be at the Version 5.2 level. So, when a CICSplex contains CMASs at more than one level, the first CMAS upgraded to Version 5.2 must be the maintenance point.
  • If you are using the API or Web User Interface to manage MASs connected to a CMAS at an earlier release, you must ensure that the MASs are managed indirectly from the Version 5.2 CMAS:
    • All WUI servers must connect to the Version 5.2 CMAS.
    • All API programs must run in such a way that they are connected to the Version 5.2 CMAS. This requirement applies only if the API program accesses new fields or later-level CICS systems. If the API program connects to an earlier-level CMAS, any resource tables that contain new or updated fields for the new release are not returned to the API program connected to the earlier release level CMAS.
  • You cannot view all resources of a CICS TS for z/OS, Version 5.2 region using a CMAS running at an earlier release.
  • A WUI server at an earlier release that is connected to a CMAS at an earlier release can retrieve data from a MAS connected to a Version 5.2 CMAS if the CMAS participates in the management of the CICSplex. However, the WUI server cannot retrieve data about resource types that were not available in the earlier release.
  • If you want to create any of the following CICSPlex SM objects, you must create them using a WUI server that is running at the same CICSPlex SM release level as the maintenance point CMAS:
    • CPLEXDEF (CICSPlex definition)
    • CMTCMDEF (CMAS to CMAS link definition)
    • CSYSGRP (system group definition)
    • PERIODEF (time period definition)
    • MONSPEC (monitor specification)
    • MONGROUP (monitor group)
    • MONDEF (monitor definition)
    • RTAGROUP (RTA group)
    • RTADEF (RTA definition)
    • WLMSPEC (WLM specification)
    • WLMGROUP (WLM group)
    • WLMDEF (WLM definition)
    • TRANGRP (transaction group)
    If you use the API or the BATCHREP batched repository-update facility to create these objects, CICSPlex SM and the maintenance point CMAS release level must, again, be at the same release level.
  • If you are using workload management, to use the unit of work (UOW) affinities introduced in CICS TS for z/OS, Version 4.2, the CMAS that owns the workload must be at the Version 4.2 level or later.

    Workload function is controlled by the CMAS that owns a workload. The workload owner is assigned to the CMAS that manages the first started TOR that causes the workload to be initialized. If the workload is not shown as ACTIVE, the first started TOR associated with the workload will cause its associated CMAS to be the workload owner. If the workload owning CMAS is not at the Version 4.2 level or later, any UOW affinity definitions cannot be honored, which means that affinities will not be correctly created and obeyed, and will be denied to any other CMASs that subsequently join the workload, even if those CMASs are at the Version 4.2 level or later.

    To ensure that UOW affinities can be exploited by a workload, ensure that the existing workload is cloned to a new name, and that any required UOW affinity definitions are applied to the new name. You must then ensure that the first TOR that is started for the new name is at the Version 4.2 level or later. This will cause UOW affinities to be honoured by any other region joining the workload name that is at the Version 4.2 level or later. If any regions that are at earlier release levels join the workload, they are not able to use the UOW affinity function, and must continue to make routing decisions on the basis of the standard workload routing algorithms.

    If you believe that your defined UOW affinities are not being implemented, use the System ID of workload owner hyperlink in any of the WUI workload runtime views to determine the CICSPlex SM version of the workload owning CMAS. If the CPSM version of CMAS attribute is not at least at the 0420 level, the workload is not capable of exploiting any defined UOW affinities.

Parent topic: Upgrading CICSPlex SM

dfhe5_cpsm_concur.html | Timestamp icon Last updated: Saturday, 15 June 2019