The DFHCSDUP MIGRATE command

Transfer the contents of a DCT, an RCT, a TCT, or a TST, from a CICS® load library to the CSD file.

Read syntax diagramSkip visual syntax diagram
MIGRATE syntax

>>-MIgrate--TAble--(--tablename--)------------------------------>

>--+----------------------------------+------------------------->
   '-TYpesgroup--(--typesgroupname--)-'   

>--+--------------------------+--------------------------------><
   '-TOGROUP--(--groupname--)-'   

Description

The contents of a table are transferred as one group, or as a set of several groups, containing definitions. When migrating large tables, make sure you allocate a sufficiently large region for the largest table to be loaded.
  • To transfer a DCT, the format is:
    MIGRATE TABLE(tablename)  TOGROUP(groupname)
    where TABLE(tablename) identifies the name of the table in the load library (DFHDCTxx).

    The contents of a table are transferred as one group, or as a set of several groups, containing definitions. When migrating large tables, make sure you allocate a sufficiently large region for the largest table loaded. For migration purposes, DCTs must be link-edited with AMODE(24) RMODE(24). To ensure this, you must specify a DFHDCT TYPE=(INITAL,MIGRATE) statement in your DCT—failure to do so causes the DFHDCT macro to force AMODE(31), which results in errors when running DFHCSDUP.

    The result is a set of groups containing TDQUEUE resource definitions. You can specify each group using the macro:
    DFHDCT TYPE=GROUP,GROUP=xxxxxxxx
    which you insert in the DCT source instructions before you assemble them for migration. All definitions after such a TYPE=GROUP macro (up to the next TYPE=GROUP macro) go into the group named by GROUP=xxxxxxxx. Definitions that occur before the first such TYPE=GROUP macro are migrated to the default group. You can also specify that definitions are to be migrated to the default group by inserting the following macro in the DCT before the definition entries:
    DFHDCT TYPE=GROUP,GROUP=*DEFAULT
    You can use the TOGROUP parameter of the MIGRATE command to assign a specific name to the default group. If you do not specify TOGROUP, the name of the default group is taken from the table name. For example, if the migrated table name is DFHDCT24, the name of the group created is DCT24.
  • To transfer an RCT, the format is:
    MIgrate TAble(tablename) [TOGROUP(groupname)]

    where TAble(tablename) identifies the name of the table in the load library, which must have the format DFHRCTxx, where xx is the suffix.

    The contents of a table are transferred as one group, or as a set of several groups, containing definitions. When migrating large tables, make sure you allocate a sufficiently large region for the largest table loaded. For migration purposes, RCTs must be link-edited with RMODE(24).

    The result is a set of groups containing DB2CONN, DB2ENTRY and DB2TRAN resource definitions. You can define each group using the macro:
    DSNCRCT TYPE=GROUP,GROUP=xxxxxxxx
    which you insert in the RCT source instructions before you assemble the RCT for migration. All definitions after such a TYPE=GROUP macro (up to the next TYPE=GROUP macro) go into the group named by GROUP=xxxxxxxx. Definitions that occur before the first such TYPE=GROUP macro are migrated to the default group. You can also specify that definitions are to be migrated to the default group by inserting the following macro in the RCT before the definition entries:
    DSNCRCT TYPE=GROUP,GRROUP=*DEFAULT
    You can use the TOGROUP parameter of the MIGRATE command to assign a specific name to the default group. If you do not specify TOGROUP, the name of the default group is taken from the table name. For example, if the table name is DFHRCT24, the name of the group created is RCT24.

    Note that the CSD migration utility honors the defaults of the RCT macro.

  • To transfer a TCT, the format is:
    MIgrate TAble(tablename) [TYpesgroup(typesgroupname)]
    where TYpesgroup(typesgroupname) specifies the name of the group to contain the TYPETERM definitions obtained from the TCT.

    If this parameter is not specified, the TYPETERM definitions are put in the GROUP currently being created, with the TERMINAL definitions.

    The result is:
    1. A set of groups containing terminal definitions. You can define each group using the macro:
      DFHTCT TYPE=GROUP,GROUP=xxxxxxxx
      which you insert in the TCT source instructions before you assemble the TCT for migration. Any terminal definitions that come before the first TYPE=GROUP macro are migrated into a group named after the table name. If the table name is DFHTCTxx, the group name is TCTxx.
    2. A group of TYPETERM definitions. These are derived from attributes of TYPE=TERMINAL macros which are often identical for many terminals. They are put into the CSD GROUP named in the TYPESGROUP parameter.

      The typeterm attributes of each TYPE=TERMINAL table macro are checked with existing TYPETERM definitions and if they don't match with any of these, a new TYPETERM is added to the CSD file.

      The existing TYPETERMs checked are:
      • TYPETERMs in the GROUP currently being created
      • TYPETERMs in the group specified in the TYPESGROUP parameter of the MIGRATE command.
      However, the scope of the checking is never extended to include any other TYPETERMs in other groups already on the CSD file. (Such groups may have been created using RDO or by a previous MIGRATE command.) For this reason, it is a good idea to use the TYPESGROUP parameter to avoid creating duplicate TYPETERMs in different groups. It is convenient to keep the TYPETERMs in a separate group anyway.

      TYPETERMs created on the CSD file during the migration are named systematically, in a way related to the TRMTYPE parameter of the original terminal definition. The name consists of a prefix (3–5 characters) with a 3-character suffix. For example, a TYPETERM defining attributes for a 3270 printer is named 3270P001. Variants with the same TRMTYPE are named 3270P002, and so on. The migration process ensures that this name is used as the TYPETERM parameter of every terminal definition that references it.

    Note: Migrating your TCT does not cause an error if the destination group already exists. Only definitions that already exist are flagged by an error message; any new or additional definitions are added to the existing group.
  • To transfer a TST, the format is:
    MIgrate TAble(tablename) [TOGROUP(groupname)]
    where TABLE(tablename tablename identifies the name of the table in the load library (DFHTSTxx) and TOGROUP(groupname) specifies the name of the group to contain the definitions obtained from the TST.

    The content of a table is transferred as a group containing TSMODEL definitions. When migrating large tables, make sure that you allocate a sufficiently large region for the largest table.

    For migration purposes, TSTs must be link-edited with AMODE(24) RMODE(24). To ensure this, you must specify a DFHTST TYPE=(INITIAL,MIGRATE) statement in your TST. Failure to do so causes the DFHTST macro to force AMODE(31), which leads to errors when running DFHCSDUP.

    You can use the TOGROUP parameter of the MIGRATE command to assign a specific name to the default group. If you do not specify TOGROUP, the name of the default group is taken from the TABLENAME. For example, if the tablename is DFHTSTJP, the name of the group created is TSTJP.

    Note:
    1. TSMODEL definitions have a location attribute, either MAIN or AUXILIARY. Migration sets this to auxiliary (although you can change it later by updating the TSMODEL definition).

      Before you define TSMODEL resource definitions to replace TST macros, you are able to specify MAIN or AUXILIARY on the WRITEQ TS API command, but this is ignored if a TSMODEL resource definition with a matching prefix is installed; the value supplied by the TSMODEL is used instead.

    2. The TYPE=SHARED macro in the TST is different from the other TST macros 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 to be specified in addition to a TYPE=SHARED macro:
      • A TYPE=REMOTE macro that specifies a SYSIDNT that matches the SYSIDNT in a corresponding TYPE=SHARED macro.
      • A SYSID specified explicitly, either on the TS API command or set by an XTSEREQ global user exit program.

      If you use the second of these two methods, and do not specify a supporting TYPE=REMOTE entry in your TST, DFHCSDUP cannot migrate a TST TYPE=SHARED entry because it has no means of knowing the DATAID from which to create the corresponding PREFIX attribute in the TSMODEL. In this case DFHCSDUP issues message DFH5139 to indicate that a TYPE=SHARED entry has been ignored.

      DFHCSDUP also issues message DFH5139 if a TYPE=SHARED macro has a supporting TYPE=REMOTE entry and has been successfully migrated to a TSMODEL with the POOLNAME shared attribute. The reason for the message in this case is that application programs that explicitly specify a SYSID, or which rely on a SYSID being specified in a global user exit program, cannot use TSMODELs, and continue to require a TST to route the request to a data sharing pool. Check that your application programs work with migrated TSMODELs for shared queues in the same way as with the migrated TST.

Options

TAble(tablename)
specifies the name in the load library of the table you want to migrate (that is, DFHDCTxx, DFHFCTxx, or DFHTCTxx).
TOgroup(groupname)
specifies the name of the group to which the definitions are to be migrated. This is for use with DCT migration only.
TYpesgroup(typesgroupname)
specifies the name of the group to which the TYPETERM definitions are to be migrated. For use with TCT migration only.