Migrating TST entries to the CSD

The DFHCSDUP MIGRATE command is enhanced to support migration of temporary storage tables to TSMODEL resource definitions in the CSD.

If you decide to migrate TST entries to the CSD, first reassemble your TST with the MIGRATE option specified on the TYPE=INITIAL macro, as follows:

DFHTST    TYPE=(INITIAL,MIGRATE)

This ensures that the table is assembled and link-edited with AMODE(24), which is required by the MIGRATE function of the DFHCSDUP utility program. Failing to specify MIGRATE on the TYPE=INITIAL macro causes the DFHTST macro to force AMODE(31), which causes errors when you run DFHCSDUP with the MIGRATE command for the TST.

Use the DFHCSDUP utility program to migrate TSTs to the CSD, specifying the following command:

MIGRATE TABLE(tablename) TOGROUP(groupname)

Note the following points when migrating from a TST to TSMODELs:

LOCATION attribute
The TSMODEL resource definition has a LOCATION attribute, which indicates whether matching TS queues are held in main or auxiliary storage. When your TST entries are migrated to corresponding TSMODEL definitions, the LOCATION attribute is set to AUXILIARY. You can change this is using the ALTER command, through CEDA or DFHCSDUP.
TYPE=SHARED macro
The TYPE=SHARED macro in the TST is different from the other types in that it does not have a DATAID parameter on which you can specify a TS queue prefix. Thus, to map a TS request to a TS data sharing pool, CICS® requires one of the following being specified in addition to a TYPE=SHARED macro:

This means that DFHCSDUP cannot migrate a TST TYPE=SHARED entry without its supporting TYPE=REMOTE entry, because it has no means of knowing the DATAID from which to create the corresponding PREFIX attribute in the TSMODEL. The following recommendations are made to help you to migrate your TST to TSMODELs successfully:

APAR PQ30438

Potential problems connected with TYPE=SHARED entries are addressed by the PTF for APAR PQ30438, which adds a new warning message to DFHCSDUP. This message serves two purposes:

  • First, it can be issued to indicate that, while migrating a TST to the CSD, a TYPE=SHARED entry has been found without a corresponding TYPE=REMOTE entry and could not be migrated as a TSMODEL.
  • Second, it can be issued to indicate that a TYPE=SHARED macro had a supporting TYPE=REMOTE entry and has been successfully migrated to a TSMODEL with the POOLNAME shared attribute. However, the message is issued because application programs that explicitly specify a SYSID, or which rely on a SYSID being specified in a global user exit program, may not function as intended with a TSMODEL as they did when using a TST. You should check whether the migrated TSMODEL for the shared queue works in the same way as the TST.

Using RDO, or TST, or both
The default TST=NO system initialization parameter means that CICS initializes with only RDO support for TS queues.

You can use RDO support for TSODELs and a TST if you use the TST system initialization parameter to specify a TST suffix. To use a TST as well as RDO, the specified TST load module must be assembled with the MIGRATE option. If the TST was not assembled with the MIGRATE option, CICS loads the TST only and does not provide any RDO support for TS queues, and any attempts to install TSMODELs are rejected.

If you use both a TST and TSMODELs, the use of the TST is limited to the following:

Switching
You cannot switch between a TST and RDO for TS queues on a warm restart. Switching is permitted only on a COLD or INITIAL start.
CSD target group
The contents of a TST are migrated as a single CSD group. See the CICS Resource Definition Guide for more information about migrating temporary storage tables as resource definitions in the CSD.

Support for TSTs in future releases

The replacement CSD resource definition type for TST entries is the TSMODEL, which provides equivalent function for most of the various DFHTST macro types. However, the TSMODEL resource definition does not provide support for application programs that rely on the mapping of SYSIDNTs to SHARED TST entries for queues held in a TS pool. If an application program explicitly specifies a SYSID on a TS queue request for a queue that resides in a TS data sharing pool, it requires the support of a TST. Until an alternative mapping of explicit SYSIDs is provided by a new CSD resource definition type, IBM® will continue to support the use of the TST for TYPE=SHARED entries.

[[ Contents Previous Page | Next Page Index ]]