Sample History File Purge Process (XCOMUTIL)

History and SMF Files › XCOMUTIL DD Statements › Sample History File Purge Process (XCOMUTIL)

Sample History File Purge Process (XCOMUTIL)

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

CAI.CBXGJCL(XCOMUTIL) contains an example of a four‑step process that performs the following steps.

Copies the CA XCOM Data Transport history file to a temporary sequential dataset, using the IDCAMS REPRO command.
Executes the XCOMUTIL program to purge records from the passed sequential data set that are older than x days and passes the selected records to stage 4 below.
If XCOMUTIL purged all records from the History File, generates a new binary zero seed record for the history file using the MVS utility IEBDG.
Calls IDCAMS to do the following:
- Delete the old history file cluster, alternate indices and paths.
- Redefine the base cluster.
- Copy the seed and the selected records back into the base cluster.
- Redefine and rebuild the alternate indices and paths.

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

Sample History Migration Process (XCOMUTIL)

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

CAI.CBXGJCL(XCOMH116) contains an example of the process that performs migration of a VSAM history file from release 11.5 to 11.6.

CAI.CBXGJCL(XCOMH115) contains an example of the process that performs migration of a VSAM history file from release 11.5 to 11.6.

Copies the CA XCOM Data Transport history file to a temporary sequential data set, using the IDCAMS REPRO command.
Executes the XCOMUTIL program to purge records from the passed sequential data set that are older than x days and passes the selected records to stage 4.
Delete an existing history file cluster, alternate indexes and paths using the MVS utility IDCAMS
If XCOMUTIL purged all records from the History File, generates a new binary zero seed record for the history file using the MVS utility IEBDG.
Redefine the base history file cluster using the MVS utility IDCAMS.
Copy the seed and the selected records in the sequential file back into the base cluster, using the MVS utility IDCAMS.
Define and build the alternate indexes and paths, using the IBM utility IDCAMS.

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 history file cluster in step 3, when the cluster does not exist. The deletion of the cluster is included when the migration job is repeated for any reason.

XCV2ODBC - Migrate VSAM History Databases

You can optionally migrate one or more existing VSAM history databases to a relational table by using the new CA XCOM Data Transport conversion program XCV2ODBC. Sample JCL is provided in CAI.CBXGSAMP(XCV2ODBC) when you install CA XCOM Data Transport.

Input to XCV2ODBC is a control data set that describes the relational environment. This data set is called SYSIN01.

To define the existing CA XCOM Data Transport history file to convert, use the following format:

//XCOMHIST DD disp=shr,dsn=your.vsamfile

Input Example:

//SYSIN01 DD *
XCOMHIST=D91APTIB
XCOMHIST_USER=XCOMUSER 
XCOMHIST_PASSWORD=SECRET
XCOMHIST_OWNER=MALMA12 
XCOMHIST_TBL=XCOM_HISTORY_TBL 
SYSNAME=XCOMPM 
SYSID=CA11
SSID=D91A
DEBUG=N

XCOMHIST=

Specifies the name of the ODBC Data Source location as defined in SYSIBM.LOCATIONS; is analogous to the CA XCOM Data Transport Default Options Table parameter. This parameter is required.

Range: 1 to 128 characters

XCOMHIST_USER=

Names the authorization ID to use when doing the connect. This parameter is required.

Range: 1 to 128 characters

XCOMHIST_PASSWORD=

Is the plain text password of the authorized user. If the XCOMHIST_USER does not require a password, this parameter can be specified as a null value (' '). This parameter is required.

Range: 1 to 8 characters

XCOMHIST_OWNER=

(Optional) If XCOMHIST_USER creates the table, XCOMHIST_OWNER= specifies the owner of the table and it can be omitted. If not specified XCOMHIST_USER is used as the table owner.

Range: 1 to 128 characters

XCOMHIST_TBL=

Specifies the 1 through 128 character table name to insert rows in. This parameter is required.

SYSNAME= / SYSID=

If the existing history record does not contain that information, SYSNAME= / SYSID= specifies the system name and SMFID used. If you are converting a CA XCOM Data Transport r11 VSAM history database, this information is not present. Identify the CA XCOM Data Transport server from which this data originated.

SYSNAME (one to eight characters) is generally the name of the CA XCOM Data Transport started task.

SYSID can be the four-character SMFID on the system that the CA XCOM Data Transport started task runs on.

These parameters are required.

SSID=

Specifies the DB2 subsystem ID used at connect time.

This parameter is optional but is required for remote database connections.

DEBUG=

(Optional) Specifies whether to collect trace information for CA Technologies Technical Support.

Range: Y or N

Note: Y can be specified only when CA Technologies Technical Support directs.

SYSNAME/SYSID Example 1:

The CA XCOM Data Transport started task XCOMPM is started on system CA11. When converting the history file this task has written, specify the following values:

SYSNAME=XCOMPM
SYSID=CA11

Any existing VSAM record not containing values for SYSNAME and SYSID uses these specifications when inserting the row into the relational database.

SYSNAME/SYSID Example 2:

The CA XCOM Data Transport started task XCOMDMP is started on system CA31. When converting the history file this task has written, specify the following values:

SYSNAME=XCOMDMP
SYSID=CA31

Any existing VSAM record not containing values for SYSNAME and SYSID uses the above specifications when inserting the row into the relational database.

Note: You can convert one or more VSAM history files to the same relational table. Run the job for each VSAM history converted file, modifying the XCOMHIST DD statement to reflect the appropriate file.