Previous Topic: Sample History File Purge Process (XCOMUTIL)Next Topic: Sample Files


Request Queue Migration

This appendix describes the CA XCOM Data Transport Request Queue Migration facility (XCOMMIGR), which migrates a request queue for use with another version of CA XCOM Data Transport for z/OS.

This section contains the following topics:

XCOMMIGR Request Queue Migration Utility

XCOMMIGR Parameters

XCOMMIGR DD Statements

XCOMMIGR Request Queue Migration Utility

XCOMMIGR is the CA XCOM Data Transport utility that performs migration of a request queue to allow it to be used with a different version of CA XCOM Data Transport . Starting with version 12.0, this migration utility can be used to upgrade an existing request queue VSAM file from prior releases to the v12.0 format to enable it for use with version 12.0.

To convert an existing file (Migration)
  1. Copy the request queue file to a sequential file.
  2. Run XCOMMIGR against this sequential file to convert queue records to the format used by version 12.0.
  3. Create a new request queue file, deleting an existing one from a previous migration run.
  4. Copy the new sequential file to the new request queue file.

Note: The CA XCOM Data Transport server cannot be executing when XCOMMIGR is used.

A backward migration can also be performed from version 12.0 to release 11.6 in the event that a fallback is needed. However, migration from version 12.0 to release 11.5 is not supported due to changes in the request queue for release 11.6 in support of new features.

XCOMMIGR Parameters

There is only one parameter that controls the processing performed by XCOMMIGR. This parameter is input to XCOMMIGR through a SYSIN file.

RELEASE

Specifies the release of CA XCOM Data Transport to convert the request queue file to.

12.0

Indicates forward migration of an existing request queue file from r11.5 or r11.6 to the 12.0 version of CA XCOM Data Transport.

11.6

Indicates backward migration of an existing request queue file from v12.0 to the 11.6 release of CA XCOM Data Transport.

XCOMMIGR DD Statements

This section describes the DD statements that are needed to execute XCOMMIGR.

There are four DD statements required to execute XCOMMIGR:

RRDSIN

A sequential file consisting of CA XCOM Data Transport request queue records. The request queue file is reproduced as a sequential file prior to running XCOMMIGR. Then, RRDSIN is used to input this file.

RRDSOUT

The sequential output file containing the converted request queue records. After running XCOMMIGR (and receiving a 0 return code), a new request queue file is created, leaving the original file intact. Then, the RRDSOUT file is copied into the new request queue file.

SYSIN

Used to enter the XCOMMIGR parameters described earlier.

SYSPRINT

XCOMMIGR prints a report providing details about the migration procedure just performed.

Sample of Required JCL

The complete sample JCL can be found in CAI.CBXGJCL(XCOMH120) and CAI.CBXGJCL(XCOMR116).

Return Codes

The following are XCOMMIGR return codes:

0

XCOMMIGR ran successfully.

4

XCOMMIGR ran successfully, but no request queue output records were written.

8

XCOMMIGR was unable to open one of the files.

12

XCOMMIGR found a parameter error processing the SYSIN file.

16

Attempt to perform an unsupported backward migration.

Sample Request Queue Migration Process (XCOMMIGR)

Note: Because XCOMMIGR is an offline procedure, remember to bring CA XCOM Data Transport down using a console command (for example, F XCOM, STOP).

CAI.CBXGJCL(XCOMR120) contains an example of the process that performs migration of a VSAM request queue file from release 11.5 or 11.6 to version 12.0.

CAI.CBXGJCL(XCOMH116) contains an example of the process that performs migration of a VSAM request queue file from version 12.0 to release 11.6.

When the migration finishes, restart CA XCOM Data Transport with another command (for example, START XCOM).

Note: This job could end with a return code of 8. This result could be due to the deletion of an existing request queue file in step 3, when the cluster does not exist. The deletion of the file is included when the migration job is repeated for any reason.