Removing schema offset clause for a system-owned index

Products

• IDMS
• IDMS - Database
• IDMS - ADS

Issue/Introduction

Question: 

Currently in the Schema the index is defined in the area OFFSET 160 PAGES for 80 PAGES.

 

To remove the offset restriction on the Index do we make the change in the Schema Set (OFFSET 0 PERCENT FOR 100 PERCENT), Validate it, create a new Subschema to pick up the OFFSET change, Generate/link that Subschema only and reference it in my Rebuild job?

//SYSIPT DD *
MAINTAIN INDEX IN SEGMENT <segmentname>
USING <new subschema with offset removed>
REBUILD <ix-setname> FROM MEMBERS;

 

 

 

Environment

Release: 19.0 for CA-IDMS
Component:

Resolution

No.

For the rebuild you will need to create a new Subschema with a unique name that contains the unrestricted page range for the index set and specify it in the the NEWSUB parameter.  The USING parameter must name the existing Subschema.

MAINTAIN INDEX IN SEGMENT <segmentname> USING <existing SS> NEWSUB <new subschema with offset removed> REBUILD <ix-setname> FROM MEMBERS;

 If you attempt the rebuild just using the updated SS, the utility will not find the existing index.

 

The owner SR7 is a CALC record. When it was stored it was the 80 page page range used in the Calc Algorithm.

You need to tell the utility both the old and new Subschema names.

It will use the old to find and delete the old index and the new to rebuild into the new page range.

 

If you just use the new SS, the old index won't be found and therefore won't be deleted, but it will try to build the index so that will probably fail due to lack of space (and if it doesn't you will have two of the same index in the area, which would be a problem).

Once the index is rebuilt correctly you must then update ALL subschemas that contain the index definition. This is very important because after the Rebuild, anyone using the Old Subschema will get errors doing OBTAINs within the index and if they Store new members with the old Subschema it will cause another SR7 and separate index structure to be created and that would be difficult to correct.

 

The PRINT SPACE report in this case shows only one SR7 record in the area. It should always show just the single SR7 if you always use a properly updated subschema after the rebuild.