Tech Tip: CA IDMS How to re-build a user-owned index when the member record requires a restructure which will change the key

Discussion created by baije01 Employee on May 11, 2016


Re-building restructured user-owned indexes with a user-written program calling IDMSTBLU can be problematic because after the restructure, the member records are in

the new format but the index is built according to the old format. This limits the extent to which the restructured database can be used to generate the necessary calls to IDMSTBLU.



If you need to re-build a user-owned indexed set, you must write a program which calls program IDMSTBLU and passes the required descriptor records to it, so that the

remainder of the MAINTAIN INDEX utility can perform the task of rebuilding the indexes. This procedure is documented in the Utilities manual in the section on MAINTAIN INDEX.

If the member record is being restructured such that the layout of the symbolic key of the user-owned index is changing, then the process needs more consideration.


The subschema name passed in the subschema descriptor must define the set according to the restructured data - the "new" subschema. Therefore, the layout of the member

record passed in the member descriptors must also match the record layout as defined in the restructured (new) subschema. This means that the user-written program must be

written to run against the restructured database, but the problem here is that at that point in the process, the user-owned indexed sets are structured according to the old database.

Therefore, the user-written program cannot access the index. It must sweep the area for the member records, and use OBTAIN OWNER in order to read the owner records and

generate the necessary IDMSTBLU calls with the owner descriptors.


Knowledge Document TEC1141084 contains a sample front-end program to accomplish this.


If your user program must access the user-owned index, one other possibility is to write the user-written program such that it runs against the un-restructured (old) database, but

then also make the same changes in storage to the member record layout that the restructure does, before passing it on in the IDMSTBLU call. Remember, it is mostly irrelevant

which database the user-written program runs against. What is important is that the layout of the data passed to IDMSTBLU in MEMBER-RECORD must match the restructured

data as defined in the new subschema.


Additional Information:

For more information, see the CA IDMS Utilities Guide, "Utility Statements", "MAINTAIN INDEX", "Usage" and the scroll to "Maintaining user-owned indexes".