Preparing for an unload and reload
Modify the database definition (DBD) to incorporate DEDB changes.Use the DBDGEN and ACBGEN utilities to construct the ACB that contains the modified definition. Save a copy of the original ACB. The original ACB is required to access the existing area data sets during the unload function.
Examples of DBD redefinition that could occur during database change using unload/reload processing include:
- Modifying area space parameters
- Increasing or decreasing the number of areas
- Changing a database structure
- Adding or deleting segments
- Adding or deleting subset pointers
If these changes affect any indexes that are registered to the DEDB that were created using the BMC AMI Fast Path Indexer for IMS product, you must incorporate these changes into the index registration.
- BMC recommends that a valid image copy be made of each area before the area is processed by the unload function. This practice ensures that, if problems arise, you can perform adequate recovery of the original area. The unload file created as output from the unload function should not be used as an alternative to making an image copy. You can specify execution of the image copy function as part of the unload function or as a separate stand-alone process.BMC recommends that a valid image copy be made of each area before the area is processed by the unload function. This practice ensures that, if problems arise, you can perform adequate recovery of the original area. The unload file created as output from the unload function should not be used as an alternative to making an image copy. You can specify execution of the image copy function as part of the unload function or as a separate stand-alone process.
- Decide the type of input to the unload function.You can use the original data sets or image copy data sets as input to the unload function:
- If input to the unload function is the original area data sets, the unload function is a DASD-to-tape operation.
- If input to the unload function is image copy data sets, the unload function is a tape-to-tape operation. This method requires sufficient cache resources to process the input data. For information about using caching with the unload function, see Enhancing-performance-of-the-CHANGE-function. Regardless of whether an image copy is used as input to the unload function, BMC recommends that you make an image copy of the original areas before executing the unload function.
- Make any required DBRC changes.Consider the implications that the changes to your DEDB will have in regard to DBRC. For example, if you are adding one or more areas to the database, you must add the new areas to the DBRC registrations. For more DBRC activity that is required before executing the reload function, see Reload-DBRC-considerations.
Make any required changes to the randomizer.Consider the implications that changes to your DEDB will have in regard to the randomizer. If you are adding one or more areas to the database, for example, you might need to modify the randomizer.
The unload function uses the randomizer that is specified by the new DMB in the NEWACB DD statement to select the output file to which the records are written. The randomizer is obtained from the NEWRESLB DD statement, if supplied, or from STEPLIB. The randomizer specified by the old DMB in the IMS ACB library or active directory is not used.
The reload function uses the randomizer that is specified by the new DMB in the IMS ACB library or staging directory. The randomizer is obtained from the IMSRESLB DD statement, if supplied, or from STEPLIB. The randomizer that is specified by the old DMB is not used.
- Consider the implications of using a generalized randomizer.If you use a generalized randomizer and any changes are made to the DEDB that affect the number of root anchor points (RAPs), then all areas in the DEDB must be input to the unload process at the same time. For information about completing the unload process when a generalized randomizer is used, see Unloading-a-DEDB-by-using-a-generalized-randomizer.
- Consider suppression of repetitious messages.For each anomaly encountered in the area, the unload or reload function generates a message with a specific suffix (severity) level. When the number of places that a particular condition exists is large, a large number of messages is produced. You can reduce the number of repetitious messages produced by using the MESSAGE_SUPPRESSION keyword to specify the maximum number of times that an informational, warning, error or critical message is to be produced. For the unload and reload processes, this keyword functions in the same manner as it does for the Fast Path/EP analysis process. For more information, see Suppressing-repetitious-messages.
- Consider rebuilding indexes after processing.If the changes to the DEDB require changes to its registered index (or indexes), you must rebuild the affected index (or indexes). You can specify execution of the index build function as part of the reload function or as a separate stand-alone process.
- Consider analyzing areas after processing.Analyzing the areas after the reload function can ensure that the results of your changes match your expectations. By default, a quick (checksum) analysis is executed as part of the reload command if you have a license for the Fast Path Analyzer/EP product. If a more detailed analysis or no analysis is desired, you can override the default by specifying the POINTER_VALIDATION keyword with the appropriate parameter value. You can specify execution of the analysis function as part of the reload function or as a stand-alone process.
- Make image copies of areas after processing.Making an image copy of the areas after the reload function and before any applications access the areas is required to ensure that if problems arise, you can perform adequate recovery. You can specify execution of the image copy function as part of the reload function or as a separate stand-alone process.