0326 or 0307 accessing index set
search cancel

0326 or 0307 accessing index set

book

Article ID: 16037

calendar_today

Updated On:

Products

IDMS IDMS - Database IDMS - ADS

Issue/Introduction



After issuing a modify statement on a system owned index set to include a symbolic, we began to receive an end of set condition on a system owned index set.

MODIFY SET EMP-NAME-NDX MODE IS INDEX USING INDEX-SYMBOLICNAME.

 

The index INDEX-SETNAME became inaccessible (DB-END-OF-SET) even though there were indexed records. 0326 and 0307 errors are possible in this case.

How is this happening? 

Environment

In this situation, the index set was originally created without a 'within area' syntax on the OWNER IS clause. A display of the schema displays the set as follow: ADD RECORD NAME IS EMPLOYEE SHARE STRUCTURE OF RECORD EMPLOYEE VERSION 100 RECORD ID IS 415 LOCATION MODE IS CALC USING ( EMP-ID-0415 ) DUPLICATES ARE NOT ALLOWED WITHIN AREA EMP-DEMO-REGION OFFSET 5 PAGES FOR 95 PAGES . SET NAME IS EMP-NAME-NDX ORDER IS SORTED MODE IS INDEX BLOCK CONTAINS 40 KEYS OWNER IS SYSTEM *+ WITHIN AREA EMP-DEMO-REGION MEMBER IS EMPLOYEE *+ WITHIN AREA EMP-DEMO-REGION INDEX DBKEY POSITION IS 1 MANDATORY AUTOMATIC KEY IS ( EMP-LAST-NAME-0415 ASCENDING EMP-FIRST-NAME-0415 ASCENDING ) DUPLICATES ARE LAST NATURAL SEQUENCE UNCOMPRESSED. Notice that the 'within area' statement for the owner is commented out, because it was originally omitted. Generated the subschema, SXWSS96, and ran a LOOK PROGRAM...the OR52 field FORDYNPG has offset of SA73 that has a 5 page offset that matches the member record page range. As expected. Then the schema set is modified, to include a symbolic for the index set (the symbolic contains the same exact same syntax as the BLOCK CONTAINS clause that it replaces): MOD SCH SXWSCHM V 96. MODIFY SET EMP-NAME-NDX MODE IS INDEX USING INDEX-SYMBOLICNAME. VALIDATE and regen the subschema. A LOOK PROGRAM on the subschema now shows the OR52 field FORDYNPG has offset of SA73 that describes the entire area page range. So, it looks like the inclusion of the index symbolic changed the area page range for the index owner.

Resolution

IDMS has determined that the compiler is working as designed. If the WITHIN AREA is not specified, the area name in the SOR-046 record is not filled in and this causes the schema compiler to use the member area mapping to determine the page range for the index's SR7.

 

Once a symbolic is used, a hard relationship is established to the area because symbolics are defined on an area basis. Besides establishing a relation between the area record and the SOR-046 record through the SYMNAME-200 and SYMSET-202 records it also causes the area name to get filled in within the SOR-046. At that point IDMS has no way of knowing if a WITHIN AREA clause had at one time been omitted, so subsequent displays of the set will contain the WITHIN AREA statement.

 

If the original set definition had no WITHIN AREA statement on the OWNER clause, and if replacing the INDEX BLOCK CONTAINS clause with an index symbolic, the index owner should specify the WITHIN AREA statement to ensure that the index retains the same page range it had before the change.