Operations

Operations

This section contains the following topics:

Introduction

Operational Considerations

Additional Tasks Performed by CA IDMS Dictionary Migrator

How CA IDMS Dictionary Migrator Operates

Running as a Single Job Execution Under Central Version

Running as a Two-Job Execution

Introduction

This chapter discusses CA IDMS Dictionary Migrator operations. It provides operational considerations, information about allocating space for the work and syntax files, how the files are used, system flow, and additional features.

Operational Considerations

Before and during the execution of CA IDMS Dictionary Migrator there are some important operational factors to consider:

• Before running CA IDMS Dictionary Migrator, the object dictionary should be backed up.
• All CA IDMS conventions regarding locking the source and object dictionaries against access are used while CA IDMS Dictionary Migrator is executing. To ensure accurate reporting prevent central version (CV) or local CA IDMS update jobs from accessing the dictionaries while CA IDMS Dictionary Migrator is executing.
• The network schema, subschemas, and their entities cannot be extracted by CA IDMS Dictionary Migrator.
• When the source dictionaries defined in the PROCESS and EXTRACT statements are at different CA IDMS levels, the EXTRACT statement is bypassed.
• Both dictionaries must be accessed in the same mode, local or CV. If SYSCTL file is used and names the Gateway CV, both dictionaries must be accessible to the CV directly, or through node communication. Node communication is discussed in the CA IDMS System Operations Guide.
• The object dictionary is not updated by extracting and comparing entities, or producing syntax. Updating the object dictionary occurs during the upload step, using the CA IDMS utilities.
• An CA IDMS environment is always started in the CA IDMS Dictionary Migrator region (partition).

Local Mode Processing

The following considerations must be taken into account for local mode processing:

• Additional JCL and EXEC statements may be needed to access files for: dictionaries, journals, UPSI, DDLDCMSG area, and the dictionary load area depending on the contents of the DMCL.
• Both dictionaries areas must be defined in the same DMCL module.
• The SYSIDMS file contents control if the job runs in local mode.

  Note: For more information about the necessary parameters, see the CA IDMS Common Facilities Guide. Do not, however, use Dictname, Nodename, Dbname or Dictnode parameter in the SYSIDMS file.

Additional Tasks Performed by CA IDMS Dictionary Migrator

Although CA IDMS Dictionary Migrator's primary function is to transfer systems from testing to production, it can also be used for these dictionary analysis and maintenance tasks:

• Thoroughly and accurately analyze a dictionary's contents. By identifying the same dictionary in both the DICTIONARY and OBJDICTIONARY parameters and specifying RUN=VERIFY or MIGRATE or AUDIT, you can direct CA IDMS Dictionary Migrator to compare the source dictionary to itself. The reports produced from this type of run show all existing relationships and entities within the source dictionary.
• Redefine schema records and elements as separate entities. When CA IDMS Dictionary Migrator decompiles a schema, it produces syntax to add the records and elements to the object dictionary as separate entities. It also produces record COPY statements for the schema definition. This enables fields to be modified without disrupting a schema structure.
• Archive a system or dictionary to a permanent data set. By specifying RUN=EXPORT, you can direct CA IDMS Dictionary Migrator to create an extract file from the source dictionary that can then be saved on tape or disk.

How CA IDMS Dictionary Migrator Operates

CA IDMS Dictionary Migrator is a parameter-driven process that uses work and syntax files. The work files are used as temporary storage for dictionary entities as they are extracted from the source dictionary, sorted, compared to the object dictionary, and retained for reports and syntax generation. CA IDMS Dictionary Migrator then produces the syntax statements for entities that are to be transferred to the object dictionary and stores these statements on syntax files. The syntax files are processed by CA IDMS utilities and compilers and the CA IDMS utilities provided with CA IDMS Dictionary Migrator to populate the object dictionary.

Extracting and comparing entities, and producing syntax does not update the object dictionary. Updating the object dictionary occurs during the final upload step, using the CA IDMS utilities and compilers and the Computer Associates utility provided with CA IDMS Dictionary Migrator.

Two Methods of Operation

There are two methods of operating CA IDMS Dictionary Migrator--as a single job execution or as a two-job execution. A single execution (see the following diagram) is used when the source and object dictionaries exist in the same CPU or when the dictionaries exist in CPUs that can be accessed by node communication. A two-job execution (EXPORT/IMPORT) is used when CA IDMS Dictionary Migrator is processed in one CPU and the object dictionary exists in another CPU without node communication (see the next diagram).

Allocating Space for Work Files and Syntax Files

CA IDMS Dictionary Migrator requires space allocations for as many as eight work files and sixteen syntax files. One of the work files-- VSAMEXT--must be a VSAM file. In addition to allocating space for the work and syntax files, the actual run of CA IDMS Dictionary Migrator requires you to allocate adequate space for sort-work files.

The first of the following tables describes each work file and suggests space allocations.

The second table provides the following information about syntax files:

• The function of each file
• The order in which the files are used by CA IDMS utilities and compilers during the upload phase
• The region size needed for each utility or compiler
• The suggested space allocation for each file.

The actual number of tracks for the work and syntax files varies depending on the size of the system being migrated, and upon the device types assigned. You may need to adjust the numbers listed in the following two tables.

Changing Block Size of Work Files and Syntax Files in z/OS

The block size of work files and syntax files can be changed by using the DCB parameter of the DD statement. The LRECL (logical record length) of each work file is listed in the first of the following tables. The LRECL of each syntax file used by the CA IDMS utility provided with CA IDMS Dictionary Migrator or CA IDMS utility or compiler is 80.

z/VSE File Assignments

An ASSIGN statement is required for every work and syntax file processed by CA IDMS Dictionary Migrator. This assignment is necessary because CA IDMS Dictionary Migrator has its own device-independent support that dynamically builds a DTF based on the device type indicated by the assignment of the logical unit. The logical unit required for each work and syntax file is provided in the following two tables.

z/VSE File Allocation Alternate Method

Occasionally, you may receive the message "FILE ASSIGNED to SYSnnn IS NOT VSAM." This means that the data set is processed SAM instead of VSAM because CA IDMS Dictionary Migrator was unable to find the data set in the VSAM catalog. SYS016, however, must be a VSAM file.

*Track Allocation expressed for 3350 disk device (30 tracks = 1 cylinder).

**File requirement depends on the run type.

***File requirement depends on environment.

Exhibit 5.2: Work Files Table

*Track allocation expressed for 3350 disk device (30 tracks = 1 cylinder).

Running as a Single Job Execution Under Central Version

Executing CA IDMS Dictionary Migrator as a single job means that you are performing a migration between two dictionaries that exist on the same machine or two machines that have node communication. You use the PARMCHECK, VERIFY, MIGRATE, or AUDIT option in the RUN parameter for a single execution.

Migration Activities - Single Job Execution

The following pages present a description of the activities for a single job execution of CA IDMS Dictionary Migrator. The complete JCL and key appear in the JCL members that were downloaded from your installation media. The JCL for a single execution perform the following migration activities:

Step 1—USMVSAM

The JCL model contained in the distribution SAMPJCL library member USMVSAM (z/OS), TOOLJCL library member USMVSAM.S (z/VSE), or the USMVSAM EXEC (z/VM), allocates the VSAM work file. The key to the JCL is also contained in USMVSAM.

Step 2--USMSYNTX—z/OS Only

The JCL model contained in the distribution SAMPJCL library member USMSYNTX (z/OS only) allocates the syntax files. The key to the model JCL is also contained in USMSYNTX. In a z/VSE or z/VM environment, the syntax files are allocated as part of the USMXTRCT step.

Step 3—USMXTRCT

The JCL model contained in the distribution SAMPJCL library member USMXTRCT (z/OS), TOOLJCL library member USMXTRCT.S (z/VSE), or the USMXTRCT EXEC (z/VM), allocates the work and syntax files (z/VSE only), extracts information from the source dictionary, compares the extract to the object dictionary, reports on the comparison, and produces the syntax files. The key to the model JCL is also contained in USMXTRCT.

Step 4—USMLOAD1

The JCL model contained in the distribution SAMPJCL library member USMLOAD1 (z/OS) TOOLJCL library member USMLOAD1.S (z/VSE), or the USMLOAD1 EXEC (z/VM), each show a step for uploading a syntax file to the object dictionary through an CA IDMS utility supplied by Computer Associates. The key to the JCL is also contained in USMLOAD1. There can be from 1 to 16 steps involved in the upload, depending on your site and the type of migration being performed. See the second of the previous tables to determine:

• The steps you need to perform
• The function of each step
• The order in which the syntax files must be processed
• The utility or compiler to be used for each file.

For each step, you must supply values for all the variables shown in the step.

Note: Some utilities are executed more than once. Do not combine syntax files for the same utility. Process the syntax files in the order outlined in the second of the previous tables to correctly populate the object dictionary.

Step 5—USMLOAD3 (Optional)

The JCL model contained in the distribution SAMPJCL library member USMLOAD3 (z/OS), TOOLJCL library member USMLOAD3.S (z/VSE), or the UMLOAD3 EXEC (z/VM), is an optional step that, when executed, deletes the migrated source from the source dictionary after migration. The key to the model JCL is also contained in USMLOAD3.

If you want to delete entities from the source dictionary after migration, make a second non-CHANGEONLY run using the same parameters as the real migration, but specifying the same dictionary for both source and object.

Step 6—USMSQLOD (Optional)

If you are using CA IDMS Dictionary Migrator to extract SQL entity definitions from a source catalog, the JCL model contained in the distribution SAMPJCL library member USMSQLOD (z/OS), TOOLJCL library member USMSQLOD.S (z/VSE), or the USMSQLOD EXEC (z/VM), can be used to update your target catalog with the syntax for the extracted SQL entities.

Using CREATESYNTAX Run Type

You can use the files created in a VERIFY run as input to CREATESYNTAX run. As a result, you can create syntax files using the data that already has produced the migration reports.

The JCL model contained in the distribution SAMPJCL library member USMIMPRT (z/OS), executes the CREATESYNTAX step.

CREATESYNTAX is useful when the VERIFY run does not show errors that require correcting. Therefore, the CREATESYNTAX run begins where the VERIFY run stops.

Running as a Two-Job Execution

To perform a migration between two machines that do not share node communication, you must run CA IDMS Dictionary Migrator twice (in two jobs) using the EXPORT/IMPORT options in the RUN parameter. The following flowchart illustrates the system flow of a two-job execution for z/OS and z/VSE.

During the first job -- EXPORT -- CA IDMS Dictionary Migrator extracts information from a source dictionary in one machine and produces syntax, and USMCOPY stores the information and syntax on tape.

During the second job -- IMPORT-- CA IDMS Dictionary Migrator compares the source dictionary information on tape to the object dictionary in another machine and produces detailed reports of the analysis.

The CA IDMS utilities and the CA IDMS utilities supplied with CA IDMS Dictionary Migrator then upload the syntax files to the object dictionary.

Migration Activities - Two-Job Execution

The following pages present a description of the activities for a two-job execution of CA IDMS Dictionary Migrator. The complete JCL and keys are contained in the JCL members that were downloaded from your installation media. A two-job execution performs the migration activities listed below.

Step 1—USMSYNTX--z/OS Only

The JCL model contained in the distribution SAMPJCL library member USMSYNTX (z/OS) allocates the syntax files. The key to the model JCL is also contained in USMSYNTX. In a z/VSE environment, the syntax files are allocated as part of the USMEXPRT step.

Step 2—USMEXPRT

The JCL model contained in the distribution SAMPJCL library member USMEXPRT (z/OS), TOOLJCL library member USMEXPRT.S (z/VSE), or the USMEXPRT EXEC (z/VM), allocates the syntax files (z/VSE only), allocates the work files, extracts information from the source dictionary and puts it onto disk, and produces syntax files on disk. The key to the model JCL is also contained in USMEXPRT.

Step 3—Utility Copy

Use a copy utility to copy the extract file and all syntax files onto a medium that can be transported to the target machine. Model z/OS JCL that performs this action and places all files on one tape can be found in source library member USMCOPY (z/OS). The key to the model JCL is contained in USMCOPY.

Step 4—Utility Copy

Use the same copy utility used in Step 3 to copy the transported files onto disk on the target machine.

Step 5—USMVSAM

The JCL model contained in the distribution SAMPJCL library member USMVSAM (z/OS), TOOLJCL library member USMVSAM.S (z/VSE), or the USMVSAM EXEC (z/VM), allocates the VSAM work file. The key to the model JCL is also contained in USMVSAM.

Step 6—USMIMPRT

The JCL model contained in the distribution SAMPJCL library member USMIMPRT (z/OS), TOOLJCL library member USMIMPRT.S (z/VSE), or the UMIMPRT EXEC (z/VM), imports the extract tape, compares extract to object dictionary, and reports on the comparison. The key to the model JCL is also contained in USMIMPRT.

Step 7—USMLOAD1

The JCL model contained in the distribution SAMPJCL library member USMLOAD1 (z/OS), TOOLJCL library member USMLOAD1.S (z/VSE), or the USMLOAD1 EXEC (z/VM), is a step for uploading a syntax file to the object dictionary through an CA IDMS utility or through the CA ADSA application upload utility supplied by Computer Associates with CA IDMS Dictionary Migrator. The key to the model JCL is also contained in USMLOAD1. There can be from 1 to 16 steps involved in the upload, depending on your site, the type of migration being performed, and whether you want to delete the migrated syntax from the source dictionary.

See the previous table to determine:

• The steps you need to perform.
• The function of each step.
• The order in which the syntax files must be processed.
• The utility or compiler to be used for each file.

For each step, you must supply values for all the variables shown in the step.

Note: Some utilities are executed more than once. Do not combine syntax files for the same utility. Process the syntax files in the order outlined in Exhibit 5.3 to correctly populate the object dictionary.

Step 8—USMLOAD3 (Optional)

The JCL model contained in the distribution SAMPJCL library member USMLOAD3 (z/OS), TOOLJCL library member USMLOAD3.S (z/VSE), or the USMLOAD3 EXEC (z/VM), deletes the migrated entities from the source dictionary after migration. The key to the model JCL is also contained in USMLOAD3. This step is optional. If you want to delete entities from the source dictionary after migration, make a second non-CHANGEONLY run using the same parameters as the real migration, but specifying the same dictionary for both source and object.

Step 9—USMSQLOD (Optional)

If you are using CA IDMS Dictionary Migrator to extract SQL entity definitions from a source catalog, the JCL model contained in the distribution SAMPJCL library member USMSQLOD (z/OS), TOOLJCL library member USMSQLOD.S (z/VSE), or the USMSQLOD EXEC (z/VM), can be used to update your target catalog with the syntax for the extracted SQL entities.