Considerations for Image Copy processing

Image Copy processing, Type-A or Type-B, can be activated by coding IC=YES in the (REORG) block of the HPSIN data set.

Image Copy processing that is supported by the Smart Reorg utility is explained in Image Copy processing and HASH pointer checking.

An appropriate processing type is selected by the Smart Reorg utility depending on the database organization. However, you can override it by specifying the ICTYPE control statement. For details, see IC control statement and ICTYPE control statement.

You can also specify the control statements for IMS HP Image Copy in ICEIN DD. For more information, see Control statements for the Image Copy task.

For restrictions that apply to Image Copy processing, see Smart Reorg restrictions and requirements.

Note: For HALDB ILDSs and PHIDAM primary index, image copies are not taken in either Type-A or Type-B Image Copy. In recovering HALDB, ILDSs and the PHIDAM primary index are rebuilt by using the HALDB Index/ILDS Rebuild utility (DFSPREC0) and, therefore, image copies of these data sets are not used.

Subsections:

Type-A Image Copy processing

The flow of Type-A Image Copy processing is shown in Data and process flow of Type-A Image Copy.

Type-A Image Copy processing applies to reorganization of the following database organizations:
  • HDAM, HIDAM, and HISAM that do not need Prefix Resolution and Update for logical relationships
  • SHISAM
  • PHDAM and PHIDAM:
    • Single partition
    • Selected consecutive partitions
    • Entire database
PHDAM and PHIDAM databases can have any type of logical relationship.
Notes:
  • Image copy stacking is not supported. To enable image copy stacking, use Type-B Image Copy.
  • DD statements for image copy data sets of secondary index of HDAM, HIDAM, or HISAM cannot be specified. Always use dynamic allocation.

Type-B Image Copy processing

The flow of Type-B Image Copy processing is shown in Data and process flow of Type-B Image Copy with Prefix Resolution/Update.

Type-B Image Copy processing applies to HDAM and HIDAM that have internal logical relationships. Image copies are taken after the Prefix Resolution and Update processes are completed. For details, see Internal logical relationships of HDAM and HIDAM.

When ICTYPE=B is coded explicitly, the following database organizations are also supported:
  • HDAM, HIDAM, and HISAM that have no logical relationship
  • PHDAM and PHIDAM that have no logical relationship
  • PHDAM and PHIDAM that have one or more logical relationships
Only Type-B Image Copy supports image copy stacking.
Note: For information about database organizations that are not supported, see Smart Reorg restrictions and requirements.

Types of Image Copy processing when CRIC=ALWAYS

When CRIC=ALWAYS is specified, the type of Image Copy processing is determined based on the result of database evaluation performed by the CRSS.
  • If the CRSS determines that the entire database needs to be reorganized, all image copies are created with the image copy type that the ICTYPE control statement specifies.
  • If the CRSS determines that the database does not need to be reorganized, ICTYPE control statement is ignored and Type-B Image Copy processing is applied. All image copies are created from original database data sets.
  • If the CRSS determines that only some HALDB partitions need to be reorganized, ICTYPE control statement is ignored and Type-B Image Copy processing is applied. Image copies of reorganized partitions are created from shadow database data sets, and image copies of other (not reorganized) partitions are created from original database data sets.

    See also Data and process flow of conditional reorganization and image copy for HALDB.

Image Copy and DBRC

If IC=YES and NAMESWAP=YES are specified, the ICNEEDED control statement is ignored, and the DBRC notification processing is done by the combination of the following information:
  • How the database or index is registered to DBRC.
  • How the HDPC parameter is specified in the ICEIN data set.
  • How the VIC parameter is specified in the ICEIN data set.
If IC=YES is specified, image copy data sets of primary DSGs are always created. If DBRC is active and NAMESWAP=YES is specified, the reorganization is always notified to DBRC, and whether the database is registered as RECOVABL or NONRECOV, image copy data sets are always registered with NOTIFY.IC commands.

For HIDAM primary index and secondary indexes of HDAM and HIDAM databases, the image copy process depends on the combination of the following definitions:

  • HDPC=Y or O
  • VIC=N or Y
  • RECOVABL or NONRECOV in DBRC database registration
  • ICREQ or NOICREQ (for the database registered to DBRC as NONRECOV)

The system default for the HDPC and VIC parameters under the Smart Reorg utility are HDPC=Y and VIC=N. For details about the HDPC parameter under the Smart Reorg utility, see Considerations for HASH pointer checking. For details about the VIC parameter, see the IMS High Performance Image Copy User's Guide.

Recommended combinations are:

  • If you want image copies of indexes, register the indexes to DBRC as RECOVABL and accept the system defaults for HDPC and VIC parameters.
  • If you do not need image copies of the index, register the index to DBRC as NONRECOV and NOICREQ, and specify HDPC=O and VIC=N on the GLOBAL statement or the IC statement for the index. In this case, the DBRC REORG record is created without turning on the IC NEEDED flag, but neither IC nor UIC (user image copy) record is created for the index. You can reduce the number of unnecessary UIC records in RECON data sets.
  • If you do not need image copies of the index but want a UIC record, register the index to DBRC as NONRECOV and NOICREQ, and specify HDPC=Y, VIC=Y, and the VICNAME parameter on the GLOBAL statement or the IC statement for the index. Then, the DBRC REORG record without the IC NEEDED flag turned on and UIC record with the user data supplied by VICNAME are created for the index.

Image Copy and timestamps

The DBRC REORG and IC timestamps that are used by the Smart Reorg utility are different from those timestamps that you see when you use the standard IMS reorganization utilities.

The following figures show the timing at which each timestamp is taken in each Image Copy processing type.

In Type-A Image Copy, as shown in Figure 1, the REORG timestamp is taken after the database is made read-only or stopped, and just before the reorganization is started. The IC timestamp is taken about 3 seconds after the REORG timestamp is taken. Note that Type-A Image Copy process is started at the same time that the reorganization process is started.

Figure 1. Type-A Image Copy and REORG/IC timestamps
This figure depicts the timing of REORG timestamps in Type-A Image Copy. The description in this topic describes the process in detail.

In Type-B Image Copy, as shown in the following figure, the REORG timestamp is taken just before the Type-B image copy processing is started, and the IC timestamp is taken about 3 seconds after the REORG timestamp is taken, which is just before the image copy processing is started.

Figure 2. Type-B Image Copy and REORG/IC timestamps
This figure depicts the timing of REORG timestamps in Type-B Image Copy. The description in this topic describes the process in detail.
Note: In both Type-A and Type-B Image Copy processing, the timestamps that are used in the RUNTIME parameter for NOTIFY.REORG, NOTIFY.IC, and NOTIFY.UIC commands are in local time and in punctuated format. For details about the standard timestamp format, see the topic "DBRC time stamps" in IMS Commands.