Upgrading CICS regions
This section summarizes the actions to take to migrate any CICS® region from one release to another. Other sections go through the actions to take for other elements of a CICS environment.
|Your current version||Action||Mandatory or optional?|
||Upgrade the CICS data sharing servers||Recommended|
|APF-authorize the CICS activation modules||Mandatory|
|Redefine and initialize the local and global catalogs||Mandatory|
|Enable z/OS® conversion services||Optional|
|Upgrade the CSD||Mandatory|
|Upgrade user-modified, CICS-supplied resource definitions||Mandatory|
|Upgrade your copies of CICS-supplied resource definitions||Mandatory|
|Reassemble all your macro tables||Mandatory|
|Review DSA size limits||Mandatory|
||Review program and transaction definitions||Mandatory|
||Review the system dump data set size||Mandatory|
||Review the use of MQCONN
CHANGE OF IMPACT
||Upgrade programs that process policy events||Mandatory|
|Migrate the DFHLRQ data set||Mandatory|
||Review whether the prerequisite PTF is installed on your z/OS operating system for IBM Health Checker for z/OS||Mandatory|
Redefine and initialize the local and global catalogs
- Delete your existing data sets.
- Define and initialize new local and global catalogs, following the instructions in Defining the global catalog and Defining the local catalog. Make sure that you use the DFHRMUTL and DFHCCUTL utility programs or the CICS-supplied JCL DFHDEFDS from your target version of CICS TS.
- Start the CICS regions with an initial start, by using the START=INITIAL parameter.
Enable z/OS conversion services
Optionally, when you start to upgrade your regions, to obtain the benefits of z/OS conversion services for data conversion, enable the z/OS conversion services and install a conversion image that specifies the conversions that you want CICS to perform. For example, your system might require support for the conversion of UTF-8 or UTF-16 data to EBCDIC.
For the instructions to set up and configure conversions that are supported through the operating system services, see z/OS Unicode Services User's Guide and Reference.
If z/OS conversion services are not enabled, CICS issues a message. If such a message is issued when you start a CICS region that is expected to use the z/OS conversion services, an IPL is necessary to enable these services. If you do not need the z/OS conversion services, you can suppress that message.
Upgrade the CSD
If you have resource definitions in your CSD that support other IBM® products, such as z/OS, you might also need to upgrade these definitions when you start the upgrade of your regions. If you need to share your upgraded CSD with different CICS releases, the CSD must be at the highest release, and compatibility groups must be specified in the correct order. For more information, especially if you use DFHLIST, see CSD compatibility between different CICS releases .
- Upgrade the CICS-supplied definitions in your CSD to the latest level. To do this upgrade, run the DFHCSDUP utility program with the UPGRADE command.
- Define a new CSD by using DFHCSDUP INITIALIZE command.
In CICS TS 4.2 or earlier, if you have the Language Environment® (LE) resource definitions in your CSD that support other IBM products, upgrade these definitions as required. For example, if you upgrade the z/OS release, you must upgrade your LE resource definitions to the new z/OS level by deleting and replacing the CSD group that contains them. The LE resource definitions are in the SCEESAMP library in member CEECCSD. Figure 1 is an example of how to delete and replace the CSD group that contains the LE definitions. For CICS TS 5.1 and later, this action is not required because the LE definitions are system-autoinstalled by CICS, provided that the required maintenance that adds autoinstall capability for LE definitions is applied. For CICS TS 5.4, the system autoinstall capability is part of the base product.
Upgrade user-modified, CICS-supplied resource definitions
If you modified any of the CICS-supplied resource definitions in your current release of CICS TS, you must upgrade them at the start of upgrading your regions. This action ensures that they are defined correctly with any new values or attributes.
- Confirm whether your CSD contains any user-modified, CICS-supplied resource definitions. Use the DFHCSDUP SCAN command to compare the CICS-supplied resource definitions with any user-modified versions. The DFHCSDUP SCAN command searches for the CICS-supplied version of a specified resource name of a specific resource type and compares it with any other resource definition of the same name and type. DFHCSDUP reports any differences between the CICS-supplied definition and a user-modified version. If you copied and changed the name of a CICS-supplied definition, the SCAN command enables you to specify the changed name as an alias.
- Copy the upgraded CICS-supplied definitions and reapply your modifications. This action is the safest way to upgrade your definitions and is necessary because the DFHCSDUP UPGRADE command does not operate on your own groups, or on CICS groups that you copied.
- If the CICS region uses CICSPlex® SM,
manually upgrade any of the dynamically created CICSPlex SM resource
definitions that you modified in your previous release, by using the
equivalents in Version 5.4.
The dynamically created resource definitions and their attributes
are in the following members of the SEYUSAMP sample library:
- EYU$CDEF contains the default resource definitions for a CMAS.
- EYU$MDEF contains the default resource definitions for a MAS.
- EYU$WDEF contains the default resource definitions for a WUI server.
Upgrade your copies of CICS-supplied resource definitions
- Review your resource definitions to determine whether you copied any CICS-supplied definitions.
- Review DFH$CSDU to determine whether the changes that it contains apply to your resource definitions.
- Make any necessary changes to DFH$CSDU. It is advisable to make a copy of DFH$CSDU and apply any changes to the copy.
- Run DFHCSDUP with your modified version of DFH$CSDU as input. As supplied, the ALTER commands in DFH$CSDU specify
GROUP(*), which means that DFHCSDUP attempts to change resources in the CICS-supplied groups. This action is not permitted and results in message DFH5151. You can ignore this message.
ALTER PROGRAM(DFHD2EDF) GROUP(*) CONCURRENCY(THREADSAFE)
When you run DFHCSDUP, the attribute is added to the definitions of program DFHD2EDF in all groups. Other attributes that are not mentioned in DFH$CSDU are unchanged.
Reassemble all your macro tables
When you start to upgrade your regions, all your macro tables must be reassembled by using the macros that are supplied with the new release. During CICS initialization, CICS detects if a macro table is not reassembled, so issues a message DFHLD0110, or DFHFC0110 for File Control table (FCT), and CICS terminates.
Review DSA size limits
It is not advisable to set the size of individual dynamic storage areas (DSAs), and usually it is not necessary. However, it is possible to set the size of some DSAs by using the CDSASZE, UDSASZE, RDSASZE, ECDSASZE, EUDSASZE, ESDSASZE, and ERDSASZE system initialization parameters. For example, CDSASZE sets the size of the CICS dynamic storage area (CDSA), and ECDSASZE specifies the size of the extended CICS dynamic storage area (ECDSA). The default value for all these parameters is 0, indicating that the size of the DSA can change dynamically. If you specify a nonzero value, the DSA size is fixed.
If you want to set DSA size limits, you must do so for each CICS region, as necessary. The limit of storage that is available for DSAs in 24-bit storage is specified by the DSALIM SIT parameter. Allow at least 256 KB for each DSA in 24-bit storage for which you have not set a size. The limit of storage available for DSAs in 31-bit storage is specified by the EDSALIM SIT parameter. Allow at least 1 MB for each DSA in 31-bit storage for which you have not set a size. You cannot set individual DSAs in 64-bit storage.
If you specify DSA size values that, in combination, do not allow sufficient space for the remaining DSAs, CICS fails to initialize.
Review your calculation of the value of the z/OS MEMLIMIT parameter to make sure that it provides sufficient 64-bit (above-the-bar) storage for the upgraded CICS region. For more information, see Estimating, checking, and setting MEMLIMIT.
Review program and transaction definitions
Defaults of the following resource attributes are changed in CICS TS 5.4. This change will have a different impact on resources, depending on the way the resources are defined. Review your resource definitions to ensure that the specification of these new defaults is appropriate.
|Resources||New attribute defaults|
Resources that are already defined through CEDA, CICSPlex SM BAS, DFHCSDUP, or a bundle are unaffected, but new definitions will default to the new value.
Resources that are installed through the EXEC CICS CREATE command will use the new default.
DATALOCATION(ANY). If you do not specify
DATALOCATIONin a program autoinstall exit, nor do you specify your own program to be used as a model in the exit, review whether the specification of
DATALOCATION(ANY)is appropriate. If not, choose one of the following ways to prevent
DATALOCATIONfrom defaulting to
- Specify the name of your own program to be used as the model in an autoinstall exit.
- Copy the definition of DFHPGAPG to your own group and alter the DATALOCATION setting. Ensure that the definition is installed after group DFHPGAIP.
Only AMODE(24) programs need to use
DATALOCATION(BELOW). CICS issues a DFHPG0104 warning message when it loads an AMODE(24) program that is defined with
DATALOCATION(BELOW) explicitly for definitions of AMODE(24) programs instead of using the default value.
Only transactions that run AMODE(24) programs need to use
TASKDATALOC(BELOW). CICS abends transactions with an AEZC abend code if an AMODE(24) program is run under a transaction that runs with
TASKDATALOC(BELOW) explicitly when you define transactions that run AMODE(24) programs instead of using the default value.
Review the use of MQCONN
The introduction of the MQMONITOR resource in CICS TS V5.4 enhances the control and security that is associated with IBM MQ connections. CICS now differentiates between the user ID under which the transaction that is monitoring the MQ queue runs and the user ID under which the initiated transactions run. All these have significant implications on MQ resources.
- MQINI(DFHMQINI) replaced with MQMONITOR(DFHQMINI)
- The MQINI(DFHMQINI) resource dynamically created by CICS when an MQCONN resource definition with
the INITQNAME parameter set to the name of an MQ queue is installed has been
replaced with a dynamically created MQMONITOR resource DFHQMINI.
DFHQMINI uses either the PLTPI user or, if not available, the region user ID as the MONUSERID value, and uses the default CICS user as the USERID value.
- User ID changes to CKTI
- As is mentioned earlier, CICS now differentiates between
the user ID under which the transaction monitoring the MQ queue runs and the user ID under which the
initiated transactions run. This has implications for any dynamically created resources.
CICS TS V5.3 or earlier CICS TS V5.4 or later Resource name: MQINI(DFHMQINI) Resource name: MQMONITOR(DFHQMINI) Transaction: CKTI Transaction: CKTI Default user ID for CKTI: Either of
- CICS region user ID
Default user ID for CKTI: Either of
The CKTI transaction runs under the authority of the transaction that initiated the CKTI instance.
The CKTI transaction uses the authority of the transaction that initiated the CKTI instance also for starting the transaction associated with the IBM MQ application queue (IBM MQ Process name).
The CKTI transaction runs under the authority of the DFHQMINI MONUSERID, which is either the CICS region user ID, or the PLTPI user ID if specified.
CKTI uses the DFHQMINI USERID, which is set to the CICS default user ID, for starting the required application transaction.
The user ID changes are required to remove a security exposure where potentially unauthorized user IDs could be used.
- Remove the INITQNAME from the MQCONN resource definition.
- Create an MQMONITOR resource with the following attributes:
- MONUSERID and USERID attributes set to the appropriate user IDs
- QNAME to match the INITQNAME that was previously specified in the MQCONN resource definition
If you have concerns about the default settings of MQMONITOR DFHMQINI (for example, migrating to DFHMQINI proves more complicated than anticipated), it's possible to install a user-defined MQMONITOR resource with the name of DFHMQINI. This gives you the flexibility in setting the AUTOSTART, STATUS, MONUSERID and USERID attributes to user-defined values so as to be backward compatible, thus making migration easier. The TRANSACTION attribute must be CKTI.
Review the system dump data set size
CICS now supports dumping of multiple address spaces and data spaces on the SET SYSDUMPCODE command. Certain system dump codes, such as LG0772 and SO0113, are added to the CICS system dump code table during CICS initialization by the user replaceable module DFHSYDMP if the PLTPI SIT parameter has a value other then NO. More dump codes might be added to the table in the future.
As a result, more data might be dumped during a system dump. Therefore, increase the system dump data set size to ensure that sufficient storage is allocated to contain dumped data.
Upgrade programs that process policy events
The order of the capture data items in policy events is changed in CICS TS 5.4. Therefore, you must upgrade any programs that process policy events as follows:
- Recompile any program that processes CFE format policy events that are emitted by the IBM MQ Queue, TD Queue, or TS Queue EP adapters.
- Modify any program that is started by the Transaction Start EP adapter, or any custom EP adapter, to change the container names that are referenced in the source to pick up each capture data item. The following table lists the changes to the container names for each capture data item in CICS TS 5.4:
For more information about the capture data items, see Data captured for a policy event.
Capture data item name Container name in previous releases Container name in CICS TS 5.4 policy_name DFHEP.DATA.00001 DFHEP.DATA.00006 rule_name DFHEP.DATA.00002 DFHEP.DATA.00007 rule_type DFHEP.DATA.00003 DFHEP.DATA.00009 rule_category DFHEP.DATA.00004 DFHEP.DATA.00022 rule_operator DFHEP.DATA.00005 DFHEP.DATA.00023 rule_threshold DFHEP.DATA.00006 DFHEP.DATA.00024 current_count DFHEP.DATA.00007 DFHEP.DATA.00025 platform_name DFHEP.DATA.00008 DFHEP.DATA.00016 application_name DFHEP.DATA.00009 DFHEP.DATA.00017 application_version_major DFHEP.DATA.00010 DFHEP.DATA.00018 application_version_minor DFHEP.DATA.00011 DFHEP.DATA.00019 application_version_micro DFHEP.DATA.00012 DFHEP.DATA.00020 operation DFHEP.DATA.00013 DFHEP.DATA.00021 bundle_name DFHEP.DATA.00014 DFHEP.DATA.00010 bundle_version_major DFHEP.DATA.00015 DFHEP.DATA.00011 bundle_version_minor DFHEP.DATA.00016 DFHEP.DATA.00012 bundle_version_micro DFHEP.DATA.00017 DFHEP.DATA.00013 bundle_id DFHEP.DATA.00018 DFHEP.DATA.00014 task_id DFHEP.DATA.00019 DFHEP.DATA.00002 transaction_id DFHEP.DATA.00020 DFHEP.DATA.00003 user_id DFHEP.DATA.00021 DFHEP.DATA.00004 program_name DFHEP.DATA.00022 DFHEP.DATA.00005 policy_user_tag DFHEP.DATA.00023 DFHEP.DATA.00015 version DFHEP.DATA.00024 DFHEP.DATA.00001 rule_group DFHEP.DATA.00025 DFHEP.DATA.00008
Migrate the DFHLRQ data set
If outstanding BTS activities for BTS processes exist in CICS, you migrate the contents of your local request queue data set, DFHLRQ. You can use a utility such as IDCAMS COPY to update the new data set with the contents of the DFHLRQ data set from your current release. You must apply this to each CICS region, as necessary.
Review whether the prerequisite PTF is installed on your z/OS operating system for IBM Health Checker for z/OS
- For z/OS V2.1: UA91584
- For z/OS V2.2: UA91583