Transfer the contents of a DCT, an RCT, a TCT, or a TST, from a CICS® load library to the CSD file.
MIGRATE syntax >>-MIgrate--TAble--(--tablename--)------------------------------> >--+----------------------------------+-------------------------> '-TYpesgroup--(--typesgroupname--)-' >--+--------------------------+-------------------------------->< '-TOGROUP--(--groupname--)-'
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.
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).
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.
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.
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.
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.