Transfer the contents of a DCT, an RCT, a TCT, or a TST, from a CICS® load library to the CSD file.
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.
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.
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 occurbefore 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.
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:
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.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:
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.
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.
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.
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. For more information about the use of a SYSID on specific TS commands, see the relevant command in the CICS Application Programming Reference.
Back to full list of commands: Resource management utility DFHCSDUP commands