COMPAKTOR Technical Description

This section deals with a few items of a technical nature that should be considered when using COMPAKTOR.

Access technique

COMPAKTOR uses EXCP level code to access DASD volumes. COMPAKTOR always reads or writes one or more entire tracks at a time. Hence, it is access-method independent. Individual data sets are not opened.

Volume label processing

As a default, COMPAKTion from an FDR backup restores the volume serial number of the dumped volume. If either the VTOC location or the volume serial number of the output volume is changed, COMPAKTOR automatically updates the UCB to reflect the changes. If another mounted volume has the same volume serial number COMPAKTOR places this volume offline. In that case, you may want to vary the original volume offline and then mount the new volume in its place. Optionally, you may request that COMPAKTOR retain the volume serial number of the target volume; however, if the volume contains VSAM clusters or is SMS-managed, this may make the volume unusable.

Volume types

COMPAKTOR only supports validly formatted OS direct-access volumes. VSE volumes with VTOCs starting at cylinder zero head zero and VM/CMS formatted DASD volumes are not supported.

COMPAKTOR automatically supports volumes with a non-standard size (a number of cylinders not matching the size of a standard IBM DASD) by honoring the number of cylinders shown in the VTOC of the output DASD volume. This supports OS-formatted VM mini-disk and non-IBM DASD subsystems with a non-standard size.

Diagnostics

COMPAKTOR performs a unique VTOC validation function. All VTOC errors and/or inconsistencies detected cause appropriate diagnostic messages to be issued.

Upon termination of a COMPAKTOR job step, either a completion code of zero is provided or one of a number of user abends is issued. User abends are used rather than non-zero completion codes to ensure that attention is drawn to all diagnostic messages. Non-zero completion codes often tend to be overlooked.

User abend U0888 is used to indicate that COMPAKTOR encountered an unusual condition, but that it did not stop COMPAKTOR from completing the COMPAKTion. The abend is issued to call attention to the message documenting the error, since it may have affected the usability of the COMPAKTed volume. However, the option CPKCC in the FDR option table may be changed to substitute a non-zero completion code for the U0888 ABEND.

Update indicators

After a volume has been COMPAKTed, the update indicator is turned on in the Format 1 DSCB of every data set that COMPAKTOR moved on the volume, as if those data sets had been opened for output.

This is done for compatibility with ABR incremental backup. Because of the “backward recovery” technique used by ABR full-volume recovery (see “ABR Volume Restores” in Section 50.1), a data set must be backed up by ABR if its location changes, even if its contents have not changed. This means that the next ABR incremental backup (DUMP TYPE=ABR) done on a volume after a COMPAKTion backs up many of the data sets on the volume.

The SIZEKEEP= operand of COMPAKTOR is designed to reduce the impact of this. SIZEKEEP= attempts to avoid moving the largest data sets on the volume as long as it can still achieve a significant reduction in the number of free-space areas on the volume by moving the smaller data sets. If it is successful, then only the smaller data sets have their update flag set and the amount of data to be backed up by the ABR incremental is significantly less.

Security

Before modifying a volume, COMPAKTOR checks to see if any other jobs in the system have OPEN data sets on the device to be restored by testing an OPEN count in the UCB of the DASD volume. If so, COMPAKTOR may issue a WTOR for console message FDRW81 and prevent modification until all other users of the device have closed their open data sets. However, the operator has the option to allow the COMPAKTion to proceed despite the active data sets. This is not desirable unless the rules for compacting an active volume has been followed (see Compacting Active Volumes). This WTOR can be suppressed by the option ACTMESS=NO on the COMPAKT statement or in the ABR option table. Fast COMPAKTion (TYPE=FASTCPK) and space release (TYPE=RLSE) default to compacting active volumes and assumes ACTMESS=NO.

A WTOR for console message FDRW80 is normally issued to allow the system console operator to confirm a CPK operation; if the COMPAKTion is undesirable, the operator may cancel it at this point. This WTOR may be suppressed by the option CONFMESS=NO on the COMPAKT statement. Fast COMPAKTion and space release assume CONFMESS=NO.

IBM RACF volume protection (CLASS= ’DASDVOL’), or the equivalent in other security systems, is supported by COMPAKTOR if the ALLCALL option is enabled in the FDR option table (see ALLCALL); COMPAKTOR does not yet support the FDR.NOALLCALL security profile). Individual data sets are not checked.

COMPAKTOR supports the FDR OPEN EXIT. Control is passed to the user exit prior to any modification of the volume. The COMPAKTion or release can be terminated by this exit.

Shared DASD environment

When compacting a DASD volume in a shared DASD environment, you must be extremely careful. Unless you have a cross-system enqueue facility (GRS or MIM from Broadcom), COMPAKTOR has no way to know what data sets are in use on another CPU or to prevent other CPUs from OPENing data sets in the middle of COMPAKTion. In this case, you may need to manually ensure that the volume is OFFLINE to the other systems in the shared DASD environment.

If you have a cross-system enqueue facility, and that facility is broadcasting SYSDSN enqueues to other CPUs, then you can use the DSNENQ= option (as described in Compacting Active Volumes for compacting active volumes) to identify the data sets in use on the other systems and make them unmovable. If that facility also broadcasts SYSVTOC enqueues, it may be possible to have that facility convert the hardware reserve done by CPK into a global enqueue instead, so that only the VTOC is enqueued rather than the entire volume being RESERVEd. However, the vendor documentation for your cross-system enqueue facility should be consulted before allowing SYSVTOC to be converted, as there may be additional considerations.