PROC statement

The PROC statement specifies the options for all databases to be processed. There must be only one PROC statement, and it must be the first control statement in the PROCCTL data set.

Subsections:

Syntax

The following syntax diagram shows the keywords for the PROC statement.

Read syntax diagramSkip visual syntax diagramPROC TYPE=ALLSCANCHECKBLKMAPESTIMATE_WK,,Optional keyword [A]Optional keyword [B]
Optional keywords [A]
Read syntax diagramSkip visual syntax diagram DBORG=ALL(,HDAMHIDAMDAMHISAMINDEXPHDAMPHIDAMPDAMPSINDX)HASH=NOYESFORCEIXKEYCHK=NOYESIXKEYCKCHK=NOYESSYMIXCHK=NOYESSYMLPCHK=NOYESEPSCHK=YESNODUPILKCHK=NOYESREPAIRILK=NOYESICRG#CHK=NOYES
Optional keywords [B]
Read syntax diagramSkip visual syntax diagram SENSOR=NOYESSENSOR_HOME=YESNOITKBSRVR=*NOservernameITKBLOAD=*NOdsnADXCFGRP=*NOAutonomics_Director_XCF_group_nameTOSIXCFGRP=*NOTOSI_XCF_group_nameCHECK=(CHK,111111)ALL(CHK, nnnnnn)USER=*NOuserid( userid1,userid2,...)RETCDDSN=*NOdsndsn( member)SEP=YESNOGROUPDIGITS=YES(NO,DBSTAT)VLSSUMM=NOYESCHECKREC=NOYESWKDATACLASS=*NOdata_class_nameWKSTORCLASS=*NOstorage_class_nameWKHLQ=*NOhlq

Keywords

The following keywords can be specified on the PROC statement:

TYPE=
Specifies the type of the process to be done. This keyword is a required keyword.
Recommendation: It is strongly recommended that you use PROC TYPE=ALL and not PROC TYPE=SCAN and CHECK because by using PROC TYPE=ALL, the performance and the size of work data sets will improve and the JCL statements are more simple.
ALL
Specifies that all of the following processes are run by HD Pointer Checker:
  • SCAN process
  • CHECK process
  • BLOCKMAP process (This process is run only when pointer errors are detected.)
SCAN
Specifies that only the SCAN process is run by HD Pointer Checker.
CHECK
Specifies that the following processes are run by HD Pointer Checker:
  • CHECK process
  • BLOCKMAP process (This process is run only when pointer errors are detected.)
BLKMAP
Specifies that a stand-alone BLOCKMAP process is run by HD Pointer Checker.

This process uses the BLKMAPIN data set, which contains the user specified control statement records, and the CHECKREC data set, which contains all sorted records, as the input.

Before you run the BLOCKMAP process, you must run either the TYPE=ALL process or the TYPE=CHECK process, with CHECKREC=YES, and you must retain the CHECKREC data set.

ESTIMATE_WK
Specifies to estimate the approximate sizes of the work data sets without scanning or checking database pointers.

HD Pointer Checker estimates the sizes of the work data sets that will be dynamically allocated by HD Pointer Checker in a TYPE=ALL job. The sizes of the work data sets that are associated with the following DD statements are estimated:

  • MERGINnn
  • MERGI2nn
  • SORTE2nn
  • CHECKREC
  • IXKEY 

For more information about these work data sets, see DD statements for work data sets.

For an instruction to estimate the sizes of work data sets with the ESTIMATE_WK parameter, see Estimating the sizes of work data sets for HD Pointer Checker automatically.

For more information about these processes, see Processes and data flow.

DBORG=
Specifies one or more database types to be processed. At least one database data set group of the DBORG parameter must be specified by the succeeding DATABASE statements.

This option can be specified when TYPE=ALL or TYPE=SCAN is specified.

If you specify TYPE=ALL, and INDEX or PSINDEX for the DBORG parameter to process an index database, you must include database type for the indexed database. This means, you cannot process index database only.

ALL
Specifies that all types of databases (HDAM, HIDAM, HISAM, INDEX, PHDAM, PHIDAM, and PSINDEX) specified by the succeeding DATABASE statements are to be processed. DBORG=ALL is the default value. If DBORG=ALL is specified with any other parameters, other parameters are ignored.
HDAM
Specifies that the HDAM databases specified by the DATABASE statements are to be processed.
HIDAM
Specifies that the primary databases of the HIDAM databases that are specified by the DATABASE statements are to be processed.
DAM
Specifies that the HDAM, HIDAM, PHDAM, and PHIDAM databases that are specified by the DATABASE statements are to be processed. If DAM is specified with HDAM, HIDAM, PHDAM, or PHIDAM parameters, these parameters are ignored.
HISAM
Specifies that the HISAM (including SHISAM) databases that are specified by the DATABASE statements are to be processed.
INDEX
Specifies that the HIDAM index, the secondary index databases, the PHIDAM index, and the PSINDEX databases that are specified by the DATABASE statements are to be processed.
PHDAM
Specifies that PHDAM databases specified by the DATABASE statement are to be processed.
PHIDAM
Specifies that PHIDAM databases specified by the DATABASE statement are to be processed. The primary index databases pointed to by the PHIDAM database are also to be processed.
PDAM
Specifies that the PHDAM and PHIDAM databases that are specified by the DATABASE statements are processed. If PDAM is specified with PHDAM or PHIDAM parameters, PHDAM or PHIDAM parameters are ignored.
PSINDX
Specifies that PSINDEX databases specified by the DATABASE statement are to be processed.
HASH=
Specifies whether you want to check the pointers by use of the HASH Check function.

This option can be specified when TYPE=ALL or SCAN is specified. When HASH=YES or FORCE is specified, INCORE=YES and EPSCHK=YES are ignored and set to NO.

YES
Specifies that all databases specified by the succeeding DATABASE statements are to be processed by the HASH Check function without in-core pointer checking. The HASH Check function provides an extra fast pointer-checking capability.
The HASH Check function has certain restrictions. If the HASH Check function is not applicable to some databases because of restrictions, the job ends. For the restrictions, see the following topics:
NO
Specifies to run the Standard Check. HD Pointer Checker creates the segment and pointer sort records without using the HASH Check function. This is the comprehensive technique for pointer checking; however, more CPU and I/O time is required. HASH=NO is the default value.
FORCE
Specifies that the HASH Check function applies to the databases that are not subject to restrictions, but the databases that are not applicable to the HASH Check function are processed using the standard pointer checking technique. HD Pointer Checker analyzes each specified database data set group to check if the HASH Check function is applicable or not.
IXKEYCHK=
Specifies whether to check the pointers and the key data by use of the Index Key Check function.

If this option is not specified, only the pointers of the primary or the secondary index databases are checked. The Index Key Check function checks not only the pointers, but also the key data of the primary and secondary index databases, against the associated segment RBA and the source key data of the primary databases.

This option can be specified when TYPE=ALL or SCAN is specified.

Abbreviation KEYCHK and IKEYCHK can be used for IXKEYCHK.
YES
Specifies that the Index Key check is to be applied to the databases. Index databases and associated primary databases must be specified in the succeeding DATABASE statements. If a primary database is indexed in more than one index database or vice versa, this option applies only to the specified database.

If /CK fields are defined by the SUBSEQ operand of the XDFLD statement, the Index Key Check is done only when IXKEYCHK=YES and IXKEYCKCHK=YES are specified.

NO
Specifies that the Index Key Check function is not to be performed. Only pointers in a primary or a secondary index are checked. IXKEYCHK=NO is the default value.
IXKEYCKCHK=
Specifies whether to run the Index Key Check function to check the keys in the primary database that has /CK fields defined by the SUBSEQ operand of the XDFLD statement, and the keys in the associated secondary index databases.

This keyword is effective when TYPE=ALL, HASH=NO, and IXKEYCHK=YES are specified.

YES
Run the Index Key Check function to check the keys in the primary database that has /CK fields defined, and the keys in the associated secondary index databases.

Secondary index databases and their associated primary databases must be specified on the DATABASE statements.

NO
Do not run the Index Key Check function against databases that have /CK fields. IXKEYCKCHK=NO is the default value.

The following figure is a conceptual diagram that shows how HD Pointer Checker checks the index keys when IXKEYCKCHK=YES is specified.

Figure 1. Conceptual diagram: How HD Pointer Checker checks index keys when IXKEYCKCHK=YES
This figure depicts How HD Pointer Checker checks index keys when IXKEYCKCHK=YES is specified. Details are described in this topic.

When IXKEYCKCHK=YES is specified, HD Pointer Checker processes each index key as follows:

  1. Decomposes the index key of the index pointer segment into the following two portions:
    • Concatenated key in the subsequence field
    • Other portions of the key
  2. Decomposes the concatenated key into the segment level.
  3. Compares the other portions of the key with the portion of the corresponding key in index source segments.
  4. Compares the decomposed keys with the keys of the corresponding segments in the primary database.

Concatenated keys in the subsequence field are compared at the segment level. Index keys are not compared as a whole.

SYMIXCHK=
Specifies whether to validate the symbolic pointers in secondary index databases and the key data. When the target segment is not a root segment, HD Pointer Checker decomposes the symbolic pointers into segment level of keys, and checks the keys. Combination of keys is not checked.

This option can be specified when TYPE=ALL and HASH=NO are specified.

YES
Specifies to validate the symbolic pointers. Index databases and associated primary databases must be specified in the DATABASE statements.
NO
Specifies not to validate the symbolic pointers. SYMIXCHK=NO is the default value.
SYMLPCHK=
Specifies whether to check the symbolic LP pointers. If both direct LP and symbolic LP pointers are defined in the logical child, both are validated. When the target segment is not a root segment, HD Pointer Checker decomposes the symbolic pointers into segment level of keys, and checks the keys. Combination of keys is not checked.

This option can be specified when TYPE=ALL and HASH=NO is specified.

YES
Specifies to validate the symbolic LP pointers. Both the databases having logical parent segment and logical child segments must be specified in the DATABASE statements.
NO
Specifies not to validate the symbolic LP pointers. SYMLPCHK=NO is the default value.
EPSCHK=
This keyword specifies whether EPS evaluation is done for the HALDB.

The EPS evaluation validates the following pointers:

  • The LP pointers or the paired LC pointers
  • Pointers in secondary indexes (PSINDEXes)

After the target partition is reorganized or migrated, some of the target RBAs in these pointers might be outdated. The latest RBA information is stored in an ILE (indirect list entry). The ILEs are in an ILDS. HD Pointer Checker validates EPS by referring to the ILEs as follows:

  • EPS healing

    If the pointer has the outdated RBA value, HD Pointer Checker revises the RBA with reference to the corresponding ILE. The revised RBA value is validated in the CHECK process. If there is no corresponding ILE, the reason is probably that either an ILK (indirect list key) in the source segment, or the index of ILDS has been corrupted, and HD Pointer Checker identifies the trouble as a pointer error.

  • ILK checking

    ILKs are contained in the source segment, ILE, and the target segment. These three objects are related to each other by the ILK value. During the CHECK process, HD Pointer Checker checks whether the ILK in the source segment and the ILK in the target segments are equivalent. As was just explained, the ILK in the ILE is checked during EPS healing.

This keyword can be specified if TYPE=ALL or TYPE=SCAN is specified. If HASH=YES is specified, this keyword is ignored.

EPS evaluation is effective only for HALDBs. If EPSCHK=YES is specified and a non-HALDB is included in the DATABASE statement, this keyword does not affect the non-HALDB.
YES
EPS is checked. EPSCHK=YES is the default value.
NO
EPS is not checked.
DUPILKCHK=
Enables HALDB Duplicate ILKs Checking. When enabled, HALDB partition reorganization numbers in HALDB partitions are checked for corruption and whether incorrect indirect list keys (ILKs) exist.

HALDB partition reorganization numbers can become corrupted by inappropriate reorganization procedures, and cause incorrect ILKs. For information about HALDB partition reorganization numbers and how they can become corrupted, see the topic "HALDB partition reorganization numbers" in IMS Database Administration.

This keyword can be specified if TYPE=ALL or TYPE=SCAN is specified. When HASH=NO and EPSCHK=YES are specified, this keyword is effective.

YES
Checks whether HALDB partition reorganization numbers are corrupted and whether incorrect ILKs exist.
NO
Do not check HALDB partition reorganization numbers and ILKs. DUPILKCHK=NO is the default value.
Consider specifying DUPILKCHK=YES if any of the following conditions are met:
  • If a HALDB has logical relationships or secondary indexes (PSINDEXes).
  • If the database was being used without the HALDB reorganization number verification function of IMS. Especially, consider specifying DUPILKCHK=YES after performing one or more of the following tasks:
    • Initialized the partitions of the HALDB after the partitions were used
    • Added partitions to the HALDB
    • Changed a high key that defines a boundary between partitions of the HALDB
    The HALDB reorganization number verification function of IMS is activated by specifying the REORGV parameter on the INIT.RECON command or the CHANGE.RECON command. If the REORGV parameter is not specified on these commands, the default (the HALDB reorganization number verification function of IMS deactivated) is used.
  • If you encounter errors that are related to indirect list data sets (ILDSs) during a HALDB reorganization and if you want to analyze the cause of the errors.
When this check is enabled, HD Pointer Checker processes the HALDB, its indirect list data sets (ILDSs), and its related databases, including logically related databases and PSINDEXes, and detects the following incorrect ILKs:
Duplicate ILKs
If a HALDB partition reorganization number becomes corrupted and if the database was continuously used under such condition, ILKs might become duplicated. If you reorganize a database that has duplicate ILKs, either the reorganization fails or the data that has the duplicate ILK becomes inaccessible. HD Pointer Checker detects duplicate ILKs to prevent such conditions.
Incorrect ILKs that occur due to a corrupted HALDB partition reorganization number
If a HALDB is reorganized appropriately, the partition reorganization number in an ILK is equal to or lower than the HALDB partition reorganization number of the partition. However, if a HALDB is reorganized by inappropriate reorganization procedures, the HALDB partition reorganization number of the partition might become corrupted. In such a case, the partition reorganization number in an ILK might become greater than the HALDB partition reorganization number of the partition. If a HALDB is continuously used under such condition, ILKs whose partition reorganization number is greater than the HALDB partition reorganization number of the partition can become duplicated. HD Pointer Checker refers such ILKs as potentially duplicate ILKs.

HD Pointer Checker detects potentially duplicate ILKs and also detects, for each partition, what the reorganization number of the partition should be. You can figure out the appropriate reorganization number of the partition from the Reorganization Number Information part of the Evaluation of ILKS report.

As described in the topic "HALDB partition reorganization numbers" in IMS Database Administration, these two types of incorrect ILKs do not cause immediate problems. However, if you later reorganize the database partitions, the reorganization fails or you are likely to lose data.

When HD Pointer Checker detects these types of ILKs, it reports them as errors and prints the details in the Evaluation of ILKS report (in the Duplicate ILKs Information part and the Reorganization Number Information part). These ILKs cannot be repaired by the standard IMS recovery methods or by reorganizing the database. Reorganizing a database that has such ILKs can cause database corruption. Therefore, before reorganizing the database, repair these ILKs and the corrupted reorganization number of the partition.
Considerations for specifying HALDBs and HALDB partitions on DATABASE statements
To ensure that all the incorrect ILKs are detected, specify both the HALDB database and its related databases, including logically related databases and PSINDEXes, on the DATABASE statement.
  • If a HALDB contains only the target segments of unidirectional logical relationships, PSINDEXes, or both, and if you specify to check only several partitions, HD Pointer Checker quickly checks duplicate ILKs within the specified partitions. When the number of partitions is limited, the job runs faster, but HD Pointer Checker cannot accurately determine whether the HALDB partition reorganization numbers are corrupted and whether potentially duplicate ILKs exist within the entire HALDB. Therefore, if you want to ensure that all the incorrect ILKs are detected, specify all the partitions of the HALDB.
  • If you are planning to add partitions, delete partitions, or change boundaries between partitions during a reorganization of a HALDB, you must detect all the incorrect ILKs before the reorganization, even if the HALDB contains only the target segments of unidirectional logical relationships, PSINDEXes, or both. To ensure that all the incorrect ILKs are detected, specify all the partitions of the HALDB.
REPAIRILK=
Specifies whether to generate repair information records for HALDB databases that contain corrupted HALDB partition reorganization numbers, duplicate ILKs, or potentially duplicate ILKs. Such errors can be detected by running the HD Pointer Checker utility with the DUPILKCHK=YES option. Use the REPAIRILK keyword when you detect such errors with the DUPILKCHK=YES option.

The generated records are required by the ILK Repair utility of IMS Database Repair Facility to repair HALDB databases that have such errors. For a complete procedure to repair such databases, see Repairing HALDB partition reorganization numbers and duplicate ILKs.

This keyword can be specified if TYPE=ALL, HASH=NO, EPSCHK=YES, and DUPILKCHK=YES are all specified.

YES
Generates repair information records in the data set that is specified by the FABPILK DD statement. The FABPILK DD statement must be specified.
NO
Do not generate repair information records. REPAIRILK=NO is the default value.
ICRG#CHK=
Specifies whether to do the HALDB Reorganization Number Verification for image copy data sets.

IMS maintains the HALDB partition reorganization numbers in the RECON data set and the partition data set. IMS validates these numbers to maintain the correctness of HALDB partitions. The HALDB partition reorganization validation is enabled by the INIT.RECON REORGV command or the CHANGE.RECON REORGV command.

HD Pointer Checker also validates the reorganization numbers, when the HALDB Reorganization Number Verification is enabled. If the partition data set contains a lower reorganization number than the RECON, HD Pointer Checker issues message FABP1097E in the Validation of a Pointer to a Target at Scan report telling that the ILDS rebuild is required.

HD Pointer Checker always validates the reorganization numbers when the input is a real database data set. In the mean time, HD Pointer Checker does the validation optionally for the image copy data set because the reorganization number in the image copy data set is obsolete if the database is reorganized. It is recommended that you validate the reorganization numbers immediately after taking an image copy.

This option can be specified when TYPE=ALL or TYPE=SCAN is specified. This option is available for HALDB (PHDAM or PHIDAM database) image copy data sets. This option is ignored for real database data sets and non-HALDBs.

YES
Specifies to do the HALDB Reorganization Number Verification for the image copy data set.
NO
Specifies not to do the HALDB Reorganization Number Verification for the image copy. ICRG#CHK=NO is the default value.
SENSOR=
Specifies whether DB Sensor stores sensor data in the Sensor Data repository of IMS Tools KB.

This keyword can be specified when TYPE=ALL or TYPE=SCAN is specified.

YES
DB Sensor stores sensor data in the Sensor Data repository of IMS Tools KB during the HD Pointer Checker process.
When you specify SENSOR=YES, ensure that:
  • The IMS Tools KB server XCF group name is specified on the ITKBSRVR keyword.
  • ITKBLOAD keyword is not specified.
NO
Sensor data is not stored. SENSOR=NO is the default value.
SENSOR_HOME=
Specifies whether to collect the data elements that are related to root segment distribution and store them in the Sensor Data repository of IMS Tools KB.

If SENSOR=YES is not specified, this keyword is ignored.

YES
Collects the following data elements and stores them in the Sensor Data repository of IMS Tools KB:
  • DB_NUM_ROOT_NOHOME
  • DB_PCT_NUM_ROOT_NOHOME
  • DB_AVG_LEN_SYNONYM_CHAIN
SENSOR_HOME=YES is the default value.
Consideration: When you specify SENSOR_HOME=YES, a randomizer is called to collect data for these data elements. Therefore, when SENSOR_HOME=YES is specified, the CPU time and the elapsed time will increase compared to when SENSOR_HOME=NO is specified.
NO
Does not collect the data elements that are related to root segment distribution.
Restrictions:
  • If the key compression option of the Segment Edit/Compression exit routine is specified for the root segment, these data elements are not collected even when SENSOR_HOME=YES is specified.
  • If you specify RMNAME=(rand,rap,0,bytes) or if you omit the third operand of the RMNAME parameter in the DBD macro, the number of root addressable area (RAA) blocks is defined as zero in the HDAM or PHDAM DBD. In this case, these data elements are not collected even when SENSOR_HOME=YES is specified.

The data elements that are additionally collected when SENSOR_HOME=YES are useful factors for determining the need of database reorganization. For more information about these data elements, see the topic "GLOBAL command keywords for FF Stand-alone DB Sensor" in the IMS Solution Packs Data Sensor User's Guide.

ITKBSRVR=
Specifies the IMS Tools Base Knowledge Base server XCF group name. HD Pointer Checker reports are stored in the IMS Tools KB Output repository that is managed by the IMS Tools KB server in the XCF group. When SENSOR=YES is also specified, DB Sensor stores sensor data in the Sensor Data repository that is managed by the same IMS Tools KB server.
servername
HD Pointer Checker stores reports in the IMS Tools KB Output repository of the specified server. When SENSOR=YES is also specified, DB Sensor stores sensor data in the Sensor Data repository of IMS Tools KB.
*NO
HD Pointer Checker does not store reports in the IMS Tools KB Output repository. ITKBSRVR=*NO is the default value.
ITKBLOAD=
Specifies the IMS Tools KB load module data set that is to be used by HD Pointer Checker.

This keyword cannot be specified if SENSOR=YES is specified. If SENSOR=YES is specified, the IMS Tools KB load module library must be specified in the STEPLIB concatenations.

dsn
Specifies the name of the IMS Tools KB load module data set that is to be used by HD Pointer Checker.
*NO
The IMS Tools KB modules are loaded from the private library or the system library of the job. ITKBLOAD=*NO is the default value.
ADXCFGRP=
Specifies whether to send a notification to Autonomics Director. Autonomics Director uses the notification as a trigger to schedule a policy evaluation.

If you want Autonomics Director to schedule a policy evaluation, you must specify the name of the Autonomics Director XCF group with this keyword.

If SENSOR=YES is not specified, this keyword is ignored.

Autonomic_Director_XCF_group_name
Specify the Autonomics Director XCF group name. DB Sensor sends sensor data notification to Autonomics Director after storing sensor data in the Sensor Data repository of IMS Tools KB.

If you specify the Autonomics Director XCF group, you must also specify DBRC=YES.

*NO
DB Sensor does not send sensor data notification to Autonomics Director. ADXCFGRP=*NO is the default value.
TOSIXCFGRP=
Specifies whether to monitor the latest VSAM statistics of IMS online full-function database data sets by using the IMS Tools Online System Interface.

If you specify SPMN=YES, SENSOR=YES, or both, and if you specify the IMS Tools Online System Interface XCF group name, Space Monitor, DB Sensor, or both request the IMS Tools Online System Interface to monitor the latest VSAM statistics of the online database data sets.

Because this keyword is effective for online databases, this keyword is ignored if you specify the keyword for offline databases. Also, if SENSOR=YES or SPMN=YES is not specified, this keyword is ignored.

If you specify SENSOR=YES or SPMN=YES, and you want to collect the latest VSAM statistics for an online database, you must specify the name of the IMS Tools Online System Interface XCF group with this keyword.

TOSI_XCF_group_name
XCF group name for the IMS Tools Online System Interface. The XCF group name is an alphanumeric character string, which begins with TOI and is followed by the characters that are defined on the XCFGROUP parameter in the IMS Tools Online System Interface PROCLIB member.

For details about the XCFGROUP parameter and the IMS Tools Online System Interface PROCLIB member, see the IMS Tools Base IMS Tools Common Services User's Guide and Reference.

*NO
The latest VSAM statistics for online database data sets are not monitored. TOSIXCFGRP=*NO is the default value.
CHECK=
Specifies whether to check certain kinds of pointers or whether to print all input records in the CHECK process. If this option is not supplied, it results in complete pointer checking without generating any unnecessary reports.

This option can be specified when TYPE=ALL or TYPE=CHECK is specified.

ALL
Specifies that all input records in the CHECK process and all error messages are to be printed. If this option is specified, an extremely large report is generated.
(CHK,nnnnnn)
Specifies whether to check certain kinds of pointers by the CHECK processor. You can control the pointer checking with the 6-digit nnnnnn part:
Position
Description
1
This control byte indicates whether to check HIDAM index pointers. Use one of the following codes:
1
HIDAM/PHIDAM index pointers are checked. Use this selection to run HD Pointer Checker. 1 is the default value.
0
HIDAM/PHIDAM index pointers are not checked.

This control byte is in effect when HASH=NO is specified. If 0 is specified for this control byte with HASH=YES, this value is ignored.

2
This control byte indicates whether to check physical pointers. Use one of the following codes:
1
Physical pointers are checked. Use this selection to run HD Pointer Checker. 1 is the default value.
0
Physical pointers are not checked.

This control byte is in effect when HASH=NO and INCORE=NO. If 0 is specified for this control byte with HASH=YES or INCORE=YES, this value is ignored.

3
This control byte indicates whether to check logical pointers. Use one of the following codes:
1
Logical pointers are checked. This value is the recommended value to run HD Pointer Checker. 1 is the default value.
0
Logical pointers are not checked.

This control byte is in effect when both HASH=YES and HASH=NO are specified. This control byte is also in effect when INCORE=NO. If 0 is specified for this control byte with INCORE=YES, this value is ignored.

To specify 0 on position 3, specify INCORE=NO on the OPTION statement.

4
This control byte indicates whether to check the counter field versus the number of logical child segments. Use one of the following codes:
1
Check the counter field versus the number of logical child segments. Use this selection to run HD Pointer Checker. 1 is the default value.
0
Do not check the counter field versus the number of logical child segments.

This control byte is in effect when HASH=NO is specified. If 0 is specified for this control byte with HASH=YES, this value is ignored.

5
This control byte indicates whether to check physically paired segments in Bidirectional Physically Paired Logical Relationship. Use one of the following codes:
1
Physically paired segments are checked. Use this selection to run HD Pointer Checker. 1 is the default value.
0
Physically paired segments are not checked.
Important: This control byte must not be turned off.

This control byte is in effect when HASH=NO is specified. If 0 is specified for this control byte with HASH=YES, this value is ignored.

6
This control byte indicates whether to print all hash formulas, regardless of whether they apply to the segment type or not.
1
No printing is generated. 1 is the default value.
0
Printing is generated.

This control byte is in effect when HASH=YES is specified. If 0 is specified for this control byte with HASH=NO, this value is ignored.

USER=
Specifies TSO user IDs. HD Pointer Checker sends a notification message to the TSO users when it detects pointer errors or T2 errors in a database.
userid or (userid1,userid2,....., userid20)
Specify up to 20 TSO user IDs. If the specified TSO user is not logged on to TSO or is disconnected from the terminal, the message is discarded.

You can also specify the special value *JOBUSR as one of these user IDs. This value will be converted to the user ID of the submitter of the job when HD Pointer Checker runs.

HD Pointer Checker does not check whether the specified TSO user is correct. If an incorrect ID is specified, HD Pointer Checker will attempt to send the notification to the user ID and the message will be discarded.

TSO user ID is effective when TYPE=ALL, SCAN, or CHECK is specified on the PROC statement.

*NO
Notification message is not sent to the TSO user. USER=*NO is the default value.
RETCDDSN=
Specify the data set name or the data set name and the member name that includes HPSRETCD control statements.

You can change the return codes of FABPMAIN by using the RETCDDSN control statements. HD Pointer Checker provides two methods to change the return codes: an HPSRETCD DD statement in JCL or the RETCDDSN parameter. If both the HPSRETCD DD statement and the RETCDDSN parameter are specified, HD Pointer Checker uses the specification in the HPSRETCD DD statement.

For more information about HPSRETCD, see FABPMAIN HPSRETCD data set.

dsn or dsn(member)
Specify the data set name, or specify the data set name and the member name for the partitioned data set.
*NO
RETCDDSN data set is not provided. RETCDDSN=*NO is the default value.
SEP=
Specifies whether to generate the separator pages for HD Pointer Checker reports.

This option can be specified with any TYPE= specification.

YES
Specifies that the separator pages are generated for each data set for the reports. SEP=YES is the default value.
NO
Specifies that the separator pages are not generated.
GROUPDIGITS=
Specifies whether to enable or disable digit grouping for the numeric values printed in Database Statistics reports and Partition Statistics reports. This option can be specified when TYPE=ALL or TYPE=SCAN is specified.
YES
Enables digit grouping and uses comma (,) as the digit grouping symbol. For example, a value of 1,000,000 is printed as 1,000,000. GROUPDIGITS=YES is the default value.
(NO,DBSTAT)
Disables digit grouping. For example, a value of 1,000,000 is printed as 1000000. This option allows to print numeric values that are greater than the maximum value a report field can display when digit grouping is enabled.
VLSSUMM=
Specifies whether to print "Summary of VL Segment Sizes" in the Partition Statistics report and the Database Statistics report. If VLSSUMM=YES is specified, "Summary of VL Segment Sizes" is printed for every partition and database.

This option can be specified when TYPE=ALL or SCAN in specified.

YES
Print "Summary of VL Segment Sizes".
NO
Do not print "Summary of VL Segment Sizes". VLSSUMM=NO is the default value.
CHECKREC=
Specifies the CHECKREC data set to be created. The CHECKREC data set contains work records for printing the maps and dumps of database blocks, and is used in step TYPE=BLKMAP, which follows it.

This option can be specified with TYPE=ALL or CHECK.

YES
Specifies to create the CHECKREC data set.
NO
Specifies not to create the CHECKREC data set. CHECKREC=NO is the default value.
WKDATACLASS=
Specifies the name of the data class for the work data sets that HD Pointer Checker dynamically allocates as temporary data sets.

This option can be specified when TYPE=ALL is specified. When SMS is not active, this option is ignored and set to *NO.

data_class_name
Specifies the name of the data class to be used for dynamically allocating the work data sets that are associated with the following DD statements:
  • MERGINnn
  • MERGI2nn
  • SORTE2nn
  • CHECKREC
  • IXKEY

For more information about these work data sets, see DD statements for work data sets.

The data class must have sufficient space and appropriate volume count so that the work data sets can be allocated.

Tip: Before you run the pointer check job, you can estimate the approximate sizes of work data sets. You can do so by running HD Pointer Checker with the TYPE=ESTIMATE_WK option or by manually calculating them. For instructions, see Estimating runtime resources.
*NO
Specifies that a data class is not passed to the dynamic allocation macro when HD Pointer Checker dynamically allocates the work data sets. WKDATACLASS=*NO is the default value.
Consideration: The value that you specify with this keyword might be overridden by the data class that is assigned by your ACS routine.
The size and volume count for the work data sets depend on the parameters on the WKDATACLASS, WKSTORCLASS, and WKHLQ keywords:
  • If WKDATACLASS=*NO, WKSTORCLASS=*NO, and WKHLQ=*NO are passed to HD Pointer Checker, HD Pointer Checker determines the size and volume count for the work data sets based on the sizes of input database data sets.
  • If one or more of these keywords are passed to HD Pointer Checker with a parameter other than *NO, the size and volume count are determined based on the data class that is specified by the parameters or by your ACS routine. In this case, you must ensure that the data class has sufficient space and volume count and that the storage group has sufficient number of DASD volumes so that all the work data sets are allocated without errors.
WKSTORCLASS=
Specifies the name of the storage class for the work data sets that HD Pointer Checker dynamically allocates as temporary data sets.

This option can be specified when TYPE=ALL is specified. When SMS is not active, this option is ignored and set to *NO.

storage_class_name
Specifies the name of the storage class to be used for dynamically allocating the work data sets that are associated with the following DD statements:
  • MERGINnn
  • MERGI2nn
  • SORTE2nn
  • CHECKREC
  • IXKEY

For more information about these work data sets, see DD statements for work data sets.

Tip: Before you run the pointer check job, you can estimate the approximate sizes of work data sets. You can do so by running HD Pointer Checker with the TYPE=ESTIMATE_WK option or by manually calculating them. For instructions, see Estimating runtime resources.
*NO
Specifies that a storage class is not passed to the dynamic allocation macro when HD Pointer Checker dynamically allocates the work data sets. WKSTORCLASS=*NO is the default value.
Consideration: The value that you specify with this keyword might be overridden by the storage class that is assigned by your ACS routine.
The size and volume count for the work data sets depend on the parameters on the WKDATACLASS, WKSTORCLASS, and WKHLQ keywords:
  • If WKDATACLASS=*NO, WKSTORCLASS=*NO, and WKHLQ=*NO are passed to HD Pointer Checker, HD Pointer Checker determines the size and volume count for the work data sets based on the sizes of input database data sets.
  • If one or more of these keywords are passed to HD Pointer Checker with a parameter other than *NO, the size and volume count are determined based on the data class that is specified by the parameters or by your ACS routine. In this case, you must ensure that the data class has sufficient space and volume count and that the storage group has sufficient number of DASD volumes so that all the work data sets are allocated without errors.
WKHLQ=
Specifies the high-level qualifier for the work data sets that HD Pointer Checker dynamically allocates as temporary data sets.

This option can be specified when TYPE=ALL is specified. When SMS is not active, this option is ignored and set to *NO.

hlq
Specifies the high-level qualifier to be used for dynamically allocating the work data sets that are associated with the following DD statements:
  • MERGINnn
  • MERGI2nn
  • SORTE2nn
  • CHECKREC
  • IXKEY

The value can be up to 20 bytes in length.

HD Pointer Checker dynamically allocates the work data sets by using the following naming rule: DSN=hlq.Jnnnnn.Thhmmss.ddname

where:
hlq
The value that you specify on the WKHLQ keyword.
nnnnn
The job number of the HD Pointer Checker job.
hhmmss
The time stamp.
ddname
The DD name of the work data set.

For more information about these work data sets, see DD statements for work data sets.

*NO
HD Pointer Checker dynamically allocates the work data sets as z/OS® temporary data sets. WKHLQ=*NO is the default value.
The size and volume count for the work data sets depend on the parameters on the WKDATACLASS, WKSTORCLASS, and WKHLQ keywords:
  • If WKDATACLASS=*NO, WKSTORCLASS=*NO, and WKHLQ=*NO are passed to HD Pointer Checker, HD Pointer Checker determines the size and volume count for the work data sets based on the sizes of input database data sets.
  • If one or more of these keywords are passed to HD Pointer Checker with a parameter other than *NO, the size and volume count are determined based on the data class that is specified by the parameters or by your ACS routine. In this case, you must ensure that the data class has sufficient space and volume count and that the storage group has sufficient number of DASD volumes so that all the work data sets are allocated without errors.