How to convert a sorted set to a user-owned index
search cancel

How to convert a sorted set to a user-owned index

book

Article ID: 222507

calendar_today

Updated On:

Products

IDMS - Database

Issue/Introduction

In an IDMS database, sorted sets (MODE IS CHAIN) and user-owned indexed sets (MODE IS INDEX) are logically identical in that they both allow the members of a set occurrence to be processed in a logical order according to the value of a specified symbolic sort key in the SET definition.

However internally they are implemented very differently. A sorted set is just a chain where each member record points to the next one in sequence. A user-owned indexed set implements an index using internal SR8 records in the same way that a system-owned index does.

The result of this is that it can be difficult to convert from one to the other. Neither UNLOAD/RELOAD nor REORG can be used to accomplish this.

Note: A user-owned index in general performs better. The same DML verbs can be used against both types, but note that for processing verbs such as an OBTAIN record-name WITHIN set-name USING sort-key or STORE member-record, for a sorted set, IDMS may have to read the entire chain in order to position itself properly. In general, the only advantage that a sorted set has over a user-owned indexed set is that it uses less space. 

Environment

Release : All supported releases.
Component : IDMS

Resolution

There are two methods for converting from one MODE to the other, both of which involve writing at least one user-written program. In each method there is a disconnect process and a connect process. In between the two processes, the database must be in a state where none of the member records are connected to an owner in the set. At that point, if the number of dbkey pointers in the member record's prefix for the set is changing between the old and new definition, it will also be necessary to run a restructure to achieve that.

It may also be necessary to create a temporary schema and subschema where the set has a DISCONNECT option of OPTIONAL if one does not already exist.

Although option 1 typically involves one fewer user-program, the nature of the programs in option 2 is much simpler, and is therefore recommended.

Option 1: MAINTAIN INDEX with a user-written front-end program

The disconnect process is an execution of a user-written front end program for the MAINTAIN INDEX utility, which in addition to making the necessary IDMSTBLU calls, must also DISCONNECT every member from its owner. Documentation for this can be found in the Usage section of MAINTAIN INDEX (scroll to the heading Maintaining user-owned indexes).

The connect process is the MAINTAIN INDEX job run FROM SORT3 as documented at the above link.

There is a sample program for this option in KD 9599: Sample front-end program for rebuilding user-owned indexed sets

Note: if you are converting from a user-owned indexed set to a sorted set, option 1 cannot be used because the target set is not an index.

Option 2: Two user programs

The disconnect process is a user-written program which sweeps every occurrence of the set, writes a file of dbkeys of the records which will allow the sets to be rebuilt, and also DISCONNECTs every member from its owner.

The connect process is another user-written program which reads the dbkey file and CONNECTs the members up again.

A sample for this option, written as one program, is in KD 219347: Utility program to help rebuild user-owned indexed set .