Functions of DEDB Unload

Features

This component provides besides the unload and the reload function, a set of support utilities that can be used for unload and reload. It offers the following features:

• Both the unload and reload programs function independently of the IMS Control Region. Hence, one or more areas of a multi-area database can be unloaded or reloaded while the application continues to use the areas that are not included in the maintenance process. This feature can significantly increase application availability.
  Note: This requires specific control of area selection and application code capable of handling 'FH' status codes.
• Both processors can concurrently process multiple database areas with no database contention. This concurrent processing capability significantly decreases the time required for database maintenance, and it further increases application availability.
• During the unload/reload process, you can change any or all of the following database specifications:
  • DBD name
  • Number of database areas
  • Randomizing module
  • Segment edit/compression routine
  • UOW parameter values
  • ROOT parameter values
  • CI size
  • Size of the VSAM data set
  • Pointer options
  • Addition of new segment
  • Change of existing segment hierarchical structure within the same parent
  Notes:

  1. These DBD definition changes will be applied only during unload process by specifying an ACB library that has new DBD definition member to the NEWACB DD statement. It implies that unloaded segment records produced by the unload process will be composed on the basis of the new DBD definition information. DBD definition change cannot be specified in the reload process (FABCUR3).
  2. For how to add a new segment or to change an existing segment hierarchical structure, see Hierarchical structure changes. Existing segment names cannot be changed, nor can existing segments be deleted.
• During the unload process, a second copy option may be specified in order to prepare two sets of unloaded files. With this option specified, the unload processing will continue even if one of the copies encounters an I/O error. This function is very effective for the users with big databases.
• During the unload process, an empty area unloaded by this utility is clearly identified with a warning message. Then during the reload process, an output data set for this empty area is initialized with no segment in order to prevent IMS DB/DC accessing trouble. The Audit Control report also shows the empty DEDB area.
• During the reload process, abnormally long dependent segment twin chains can be controlled so that the impact on other database records in the same RAP CI is minimized. This feature is implemented via a user-specified limit on the number of segment occurrences that are to be placed "near" the root.
• The new area and RAP values for the database record are determined during unload processing. This allows all records for an area to be written to the same output data set, avoids an extra pass of the file, and simplifies the reload process.
• There are no source code modifications made to any user-written or IMS program or control block. Because IMS program integrity is maintained, new exposures are not introduced.
• DEDB Unload/Reload enables you to produce an expanded-format unloaded data set from compressed segments.
• The reload program can reload segment data in one area into multi-area data sets.
• The reload program can produce image copy data set(s) of an unloaded area.
• Under the image copy option, the reloaded program can do a fast scan (HASH check) of the integrity of the unloaded area.

General structure

The DEDB Unload/Reload utility consists of two functional components that operate independently of the IMS control region.

The unload processor is a z/OS® batch program that can concurrently unload multiple areas of a DEDB. But there are basically two problems that hinder DEDB unload/reload processing if operated under the control of the IMS control region:

1. To prohibit access to the areas involved in the maintenance process, all transactions that access the database must be stopped or made logically unavailable to the application. If the transactions must be stopped, application availability is adversely impacted.
2. DEDB Unload/Reload processing (or any sequential process) that uses "GN" and "ISRT" calls is exceedingly slow. The basic problem with this approach is the number of EXCPs required. An unload using "GN" processing issues one EXCP for each CI that contains data. A reload using "GN" and "ISRT" processing requires one EXCP to retrieve a CI and another EXCP to rewrite the CI. Additional EXCPs are incurred if the NBA is not large enough to hold a logical UOW (that is, the RAA BASE section CIs plus all IOVF CIs logically owned by the UOW).

The DEDB Unload/Reload utility achieves significant performance improvements (that is, elapsed time reduction) by reducing the number of EXCPs issued. Both programs use the VSAM read ahead facility to minimize the number of EXCPs (that is, a conscious decision was made to reduce EXCPs at the expense of increased memory usage). Both the unload and reload programs, if buffered correctly, read and write a minimum of 23 2048-byte CIs per EXCP for the root addressable section of an area. This number can be further increased (that is, elapsed time reduced) by providing additional VSAM buffers (within limitations).

In addition, all IMS overheads (that is, logging or sync point processing) have been eliminated, and the instruction path length to retrieve or insert a segment is exceedingly short.

DEDB areas requiring maintenance are deallocated from the IMS control region. The unload processor, after first ensuring that the maintenance request is valid and that all required resources are present, attaches and manages a user-specified number of subtasks. Each subtask is responsible for unloading a specific area. When completed, the subtask returns to the main task for assignment of another area or termination. As each database segment is unloaded, the subtask invokes the randomizer (if required) to determine the new area/RAP values. All subtasks share a common output writer. This allows all database records for an area to be written to the same output file. This approach simplifies the reloading process, and eliminates an extra pass of the unloaded segment file.

The number of concurrent unload subtasks depends on the UOW size and the number of required IOVF buffers. This is explained in detail in Hierarchical structure changes.

After the VSAM clusters have been deleted and redefined, multiple reload jobs can be initiated to concurrently reload the areas. The only limitation on the number of concurrent reload jobs is the number of available initiators. You can also reload the areas in a single job step.

Hierarchical structure changes

During the unload/reload process, the segments can be moved in the hierarchical structure, and the new segments can be defined if the following rules are not violated. FABCUR1 detects invalid structure changes.

1. The existing segment names cannot be changed.
2. The new segments can be added, but the existing segments cannot be deleted.
3. When a segment is being moved in the hierarchical structure (that is, its segment code is being changed), it must remain at the same hierarchical level.
4. A segment must have the same parent after being moved in the hierarchical structure.

The following table shows examples of hierarchical structure change of the unload and reload processes.

Modes

There are two basic modes to use the DEDB Unload/Reload utility. These are called "reorg" mode and "change" mode. Setting your JCL and control statements depends heavily on the mode you are using. This topic describes the techniques about how to use for each type of unload/reload.

Reorg mode

This mode is used when you do not change the database structure, the DBD, or the randomizing routine. The only change you can make in "reorg" mode is to increase or decrease the size of the SDEP part of an area.

There are two ways to reduce the size of SDEP part of an area:

• Unload with the SDEP=LOGICAL option
• Unload with the SDEP=PHYSICAL option and reload with the SDEPRELOCATE=YES option

In both ways, the SDEP marker will be lost. When reducing the size of SDEP part, you must make sure that the SDEP size after being reduced has enough space to restore all SDEP CIs that are between SDEP logical begin and logical end.

A "reorg" mode FABCUR1 run should be set up in the following manner:

• Code REORG and STATS on your DBDNAME control statement.
• Do not code HIERCHNG= or RMODTYPE= on your DBDNAME control statement.
• Do not include NEWACB or RMODLIB DD statements in your JCL.

Change mode

This mode is used when you change the database structure, the DBD, or the randomizing routine.

A "change" mode FABCUR1 run should be set up in the following manner:

• Do not code REORG on your DBDNAME control statement.
• If you are changing the segment hierarchy (that is, one or more segment codes are being changed), then code HIERCHNG=YES/YESFORCE on your DBDNAME control statement.

  For additional information, see Hierarchical structure changes.

• If your randomizing routine is "area-specific," and if you are not unloading all areas, code RMODTYPE=S on your DBDNAME control statement.
• Include the NEWACB and RMODLIB DD statements in your JCL.

Change Database Definition

Specify an ACB library that includes the current DBD type ACB in the OLDACB DD, and an ACB library that includes the new database definition DBD in the NEWACB DD.

Change Randomizer module

Specify a library that includes the NEW randomizer module in RMODLIB. The old randomizer is not needed for unloading. Do not concatenate the library that includes the old randomizer ahead of the new randomizer library, if randomizer name is the same.

Notice: If you do not change the randomizer, you should specify the library that includes the current randomizer module in the RMODLIB DD of FABCUR1.

Change Compression exit

If the compression exit name is the same, check the following:

• Specify a library that includes the current compression exit in the RMODLIB DD when unloading, then provide a library that includes the new compression exit in the RMODLIB DD of FABCUR3. If the compression exit name is different, choose one of the following:
  • Specify COMP=Y in the SYSIN DD and the concatenated libraries that include the current compression exit and the new compression exit in the RMODLIB DD of FABCUR1.
  • Specify COMP=N in the SYSIN DD and specify the library that includes the current compression exit in the RMODLIB DD of FABCUR1, then specify the library that includes the old compression exit in the RMODLIB DD of FABCUR3.

You can specify Reorg mode and Change mode by using FABCOP1D (site default table).

Even if the TYPERUN/TYPRUN=REORG keyword is specified in FABCOP1D, it will be ignored if NEWDBDNM=, HIERCHNG=, or RMODTYPE= is specified in the SYSIN DBDNAME= control statement.