How IDMSDBAN set validation works
Article ID: 50828
Updated On:
Products
Issue/Introduction
Occasionally sets within the database are omitted from the "Report 5 - Set Analysis Data" report or various error messages concerning set errors are generated. This article explains why IDMSDBAN may not generate report entries for all sets within a database, what error messages may be generated, and when it is possible to take corrective action.
Environment
Release: All supported releases.
Resolution
IDMSDBAN, the IDMS database analysis utility, analyzes the characteristics and structure of an IDMS database. This utility provides information useful for system tuning, database structuring, and capacity planning. IDMSDBAN also verifies the integrity of: page structures, line indexes, record lengths, record locations, and set connections. The "Report 5 -Set Analysis Data" report provides detailed statistics for each set type processed: chained sets, sets of variable-length-record fragments, and indexed sets owned by a user record.
Occasionally sets within the database are omitted from the "Report 5 - Set Analysis Data" report or various error messages concerning set errors are generated. This article explains why IDMSDBAN may not generate report entries for all sets within a database, what error messages may be generated, and when it is possible to take corrective action.
IDMSDBAN generates data for sets in the "Report 5 - Set Analysis Data" report based on the components of the sets that are available within the areas that the utility processes. In addition, the processing of index sets is dependent upon the utility being able to identify all the index sets within a given page range.
If no SET parameters are specified, IDMSDBAN does not report on sets for which all components are not included in the available page range(s). However, if specific SET parameters are provided, the utility may generate messages 598405, 598406, or 598603 indicating some problem with being able to process a requested set. The following examples provide an overview of when one of these messages can be expected to occur.
The following database is used to illustrate the IDMSDBAN set processing explanation.
REC1-INDEX and REC3-INDEX are system-owned indexes where the index structures (SR7/SR8) reside in AREA1 and AREA3, respectively. REC4-REC2 is a userowned index where the SR8s reside in the area of the owner which, in this case, is AREA3.
When the IDMSDBN1 program of the IDMSDBAN utility starts its processing, one of the first things it does is determine which sets it can process based on the set components that are available to it within the areas/page ranges requested on AREA parameters. Dealing with chain sets is very simple. All of the records that participate in the set relationship must reside in the areas/page ranges specified. Index processing is not always as intuitive.
Because IDMSDBAN is designed to interpret whether a broken chain exists, it is necessary for it to be able to relate a record occurrence to a particular set. To be able to do this with the SR8 records that make up an index, it is necessary for IDMSDBAN to process all index sets within an area as well as have all of the other set components present within the specified areas. If it is not possible for IDMSDBAN to process all index sets within an area, the utility suppresses the processing of all index sets within that area.
If IDMSDBAN is executed against our example database and AREA1 and AREA2 are specified as the areas to be processed, the following sets are included on Report 5:
REC1-REC2 REC2-REC3 REC1-INDEX= CALC (one for each area)
REC4-REC2 and REC3-INDEX are not processed because components of these sets reside in AREA3. Changing our scenario to process areas AREA2 and AREA3 results in the following sets being present on Report 5:
REC1-REC2 CALC (one for each area)
In this second case, it is not possible to process index set REC3-INDEX because RECORD3 does not reside in either of the requested areas. Since IDMSDBAN cannot process that index set, it must also suppress the processing of the REC4-REC2 user-owned index set.
Each of the above scenarios results in both the IDMSDBN1 and IDMSDBN2 steps running to a successful completion and all requested reports being generated. However if the input to IDMSDBN1 included SET cards, it is possible that error messages 598405, 598406, or 598603 may be generated if a specified set cannot be processed due to a missing component or all index sets are not included in the scan.
A missing component in a requested chain set results in the generation of message 598405. If an execution of IDMSDBN1 included AREA cards for AREA2 and AREA3 and a SET card for REC2-REC3, the following message is generated because RECORD3 is not included in one of the areas to be processed:
598405 - SET NOT IN SELECTED PAGE RANGE: REC2-REC3
Missing index components result in the generation of messages 598406 or 598603 depending on the actual scenario; but, they generally imply the same problem, i.e., all indexes within a particular area have not been requested or cannot be included due to a missing set component; hence, all processing of indexes must be suppressed.
The following examples provide an overview of when indexing processing can proceed or when one of these messages can be expected to occur. If the parameters to the IDMSDBN1 step specify areas AREA1 and AREA2 and include a SET card for REC1-INDEX, a Report 5 for REC1-INDEX is successfully generated. Although RECORD3 is indexed by REC3-INDEX, that index set's SR8 structure resides in AREA3. The only SR8s in AREA1 are for REC1-INDEX so IDMSDBAN is capable of processing that set.
Another IDMSDBAN run is attempted against areas AREA1 and AREA3. In this case, a single SET card is coded for set REC3-INDEX. Because AREA3 also contains SR8s for the unspecified REC4-REC2 set, IDMSDBAN is not able to process any index sets. In this case the following message is produced:
598406 - ALL INDEXED SETS NOT IN SPECIFIED PAGE RANGE: REC3-INDEX
In the final example, AREA1, AREA2, and AREA3 are all specified to be included in the scan. SET cards are coded to request sets REC1-INDEX and REC4-REC2. Area AREA3 also includes the index structure for set REC3-INDEX but that set is not requested. As a result IDMSDBAN cannot process set REC4-REC2 and the following message is generated:
598603 - AREA DOES NOT HAVE ALL INDEX SETS SELECTED: AREA3
It is not always easy to predict whether message 598406 or 598603 will be generated due to a missing index within an area. However your response to either of these messages should be the same, i.e., look for any unspecified indexes within the area in which your requested index's SR8 structure resides and include those indexes within your IDMSDBAN execution.
Additional Information
Attachments
Feedback
