Preparing To Run the Load Utility
Before attempting to execute the load utility, take the following considerations into account.
Before attempting to execute the load utility, take the following considerations into account.
Preparation of DL/I Data
Unload all DL/I data, including all access methods, by using the DL/I HD unload utility. The CA IDMS DLI Transparency load utility expects the data to be in the format produced by the HD unload utility.
Unload all DL/I HDAM, HIDAM, secondary index, HISAM, and index databases. Index databases have to be unloaded only if the index entries are not created by other record occurrences in the index relationship. See "CA IDMS DLI Transparency Index Maintenance" below.
CA IDMS DLI Transparency Index Maintenance
CA IDMS DLI Transparency creates and updates DL/I index entries for the index relationships defined in the CA IDMS/DB database. In other words, when a source record is inserted, replaced, or deleted in a CA IDMS/DB index relationship, CA IDMS DLI Transparency makes sure that the index relationship's requirements can be met for the insert, replace, or delete call.
You should not input to the load utility any DL/I index entries that would be created by CA IDMS DLI Transparency's index maintenance routines. For example, assume that you have a DL/I index database that is populated whenever a particular root segment is inserted into an associated HDAM database. Since loading of the HDAM database will also populate the index database, there is no need to load the entries in the DL/I index database into the CA IDMS/DB index relationships. CA IDMS DLI Transparency will do this for you.
You can use index suppression exits or null value criteria specifications to support DL/I sparse indexing during the load process. See Index Suppression Exit Support for a discussion of index suppression exits.
Using the CA IDMS DLI Transparency Syntax Generator
It is strongly recommended that you use the syntax generator to produce the source statements for the IPSB load module and the CA IDMS/DB schema, subschema, and DMCL modules. See CA IDMS DLI Transparency Syntax Generator for instructions on creating the special load IPSB and using the GENERATE LOAD IPSB and GENERATE LOAD SCHEMA statements. While you can hand-code the IPSB, use of the syntax generator is more efficient and less time consuming.
Preparation of the IPSB and CA IDMS/DB Load Modules
To produce the CA IDMS/DB modules, input the generated source statements to the appropriate compilers. If you are running the database load in local mode, the subschema and DMCL modules must reside in a library that is accessible by a STEPLIB JCL statement.
To produce the IPSB load module, input the generated IPSB source statements to the IPSB compiler (see IPSB Compiler). Note that the subschema module must be available to compile the IPSB.
The IPSB(s) produced by the syntax generator may not be appropriate for the database load. In this case, you will have to edit the IPSB source to create special load IPSBs (see "Special Load IPSBs" below).
Special Load IPSBs
The IPSB Load Module
The IPSB load module provides the CA IDMS DLI Transparency run-time interface with a description of the DL/I database hierarchies that are referenced in the PCBs (database views) defined for the DL/I application. The IPSB also defines those logical relationships that involve other DL/I databases. Make sure that these logical relationships are correctly defined so that the load utility can find the logical parent records necessary to populate the logical workfile.
Review the IPSB
Specifically, make sure that the IPSB defines:
- Each logically related database
- The physical segments in each database
- The physical path underlying the logical path
Note that logically related databases are defined by way of multiple PCBs within the IPSB. The multiple PCBs are the equivalents of multiple logical DBD descriptions, with full hierarchical definitions, included within the same PSB. Each logically related database is represented by at least one PCB. If the logical relationships do not cross database boundaries, only one PCB that defines the logical relationships is required in the IPSB load module.
In the case of multiple DL/I databases, it is recommended, but not required, that you use one IPSB load module with multiple PCBs.
PROCOPT for Special Load IPSBs
Each PCB included in the IPSB load module must have a PROCOPT of LOAD so the CA IDMS DLI Transparency run-time interface can recognize that the load utility is active. Failure to specify the LOAD PROCOPT can result in load processing errors. If you use the CA IDMS DLI Transparency syntax generator, it will generate this PROCOPT for you automatically. See CA IDMS DLI Transparency Syntax Generator for a description of the GENERATE LOAD IPSB statement.
Availability of the IPSB Load Module
You must make sure that the IPSB load module is available to both the load utility and the CA IDMS DLI Transparency run-time interface. For central version execution, the IPSB load module must be available to the central version and the batch LOAD region.
CA IDMS/DB Schema Requirements
Junction Record Represents Logical Child Segment
For each logical relationship that exists in the DL/I database, the logical child segment must be represented by a CA IDMS/DB junction record. For the junction to exist, there must be two CA IDMS/DB sets. Since there is no assurance that the load process has stored the two set owners (parent records) before it stores the junction (logical child) record, the set with the logical parent as owner must have a set connection option of OPTIONAL MANUAL.
After completing the load process, you can change the set's connection option to MANDATORY AUTOMATIC, if desired.
Bill-of-Materials Relationship Exception
The only exception is the bill-of-materials type of relationship, which requires the junction record to be owned by two different occurrences of the same record type. In this case, the set connection option must remain OPTIONAL MANUAL.
Use the Syntax Generator
It is recommended that you use the CA IDMS DLI Transparency syntax generator to produce a basic load schema with proper set connection options for logical relationships. See CA IDMS DLI Transparency Syntax Generator for a description of the GENERATE LOAD SCHEMA statement.
Multi-Database Logical Relationships
Load Databases Separately
If logical relationships involve more than one database, you must load each database separately (Step 2, under "The Database Load Process", earlier in this section).
Separate Logical Workfiles are Created
Each database load that you perform creates a separate logical workfile. You must make sure that the workfile from each load is available for the workfile sort/merge processing (Step 3). If a required workfile is not available, the prefix resolution processing (Step 4) encounters unresolved logical relationships, and you have to perform the database loads again.
Workfile Space Allocation
Load Utility Generates Separate Workfiles
The load utility generates four separate workfiles:
- The workfile produced by Step 2 (under "The Database Load Process", earlier in this section)
- The sorted workfile produced by Step 3
- The prefix-resolved workfile produced by Step 4
- The hierarchically sorted workfile produced by Step 5
General Considerations for Workfiles
Here are some general considerations for workfiles:
- The workfiles can be allocated to either disk or tape.
- Each workfile is a sequential fixed-block data set with a logical record size of 288 and a block size of 5760.
- If you are using DASD space, you can use the following formula to calculate the number of bytes required for the first workfile produced by Step 2:((# of logical children) + (# of logical parents)) X 288
- Be sure to include all potential logical parents as well as all existing logical children. (Refer to "Workfile Usage for HISAM Logical Parents," below.) If you do not know the numbers for logical children and logical parents, you can use the preload CALC processing (Step 1) to get a count of all record occurrences that will appear in the logical workfile.
- Remember that there will be a separate workfile generated for each DL/I database that you load. (See "Multi-Database Logical Relationships," above).
- Space requirements for the second (sorted workfile) are equal to the sum of the space requirements for all the workfiles resulting from the load.
- To calculate the space requirements for the third (prefix-resolved) workfile, use the formula shown above for the first workfile, but specify 0 (zero) for # of logical parents. This workfile contains only the logical child records, but with adjusted prefixes (concatenated keys).
- Space requirements for the fourth (hierarchically sorted) workfile are the same as for the third workfile.
Workfile Usage for HISAM Logical Parents
During the database load, the load utility writes logical parent records that appear in HDAM, HIDAM, and secondary index databases out to the logical workfile. However, the load utility does not write out logical parent records for HISAM databases. Because logical parents from HISAM databases do not appear in the logical workfile, you can reduce its space requirements accordingly. If you use the DASD space requirement formula shown above, you should adjust it so that it does not include any HISAM logical parents.
Preload sorting sorts the DL/I input data into database page sequence for more efficient loading. You can preload sort only DL/I data that has been successfully preload CALC processed (Step 1, under "The Database Load Process", earlier in this section).
Diagnostic and Error Messages
The diagnostic and error messages that may be returned by the various steps in the load process are listed in CA IDMS DLI Transparency Messages and Codes.