Sorted chained sets should be used with caution
Article ID: 136180
Updated On:
Products
Issue/Introduction
Great care should be taken with sorted chained sets. This is when ORDER IS SORTED and MODE IS CHAIN is specified in the SCHEMA definition of a SET.
In a SORTED CHAINED set, the members of the set are sorted into a logical order according to the value of a specified symbolic key. This is very similar to a user-owned indexed set (MODE IS INDEX) considering that the same style of IDMS DML verbs can be used against the two, e.g. OBTAIN record-name WITHIN set-name USING symbolic-key-field.
The difference is that in a user-owned indexed set, there is an internal index implemented to provide much faster access to the individual member records based on the value of the sort key.
In a sorted set, there is no such index - the members are in a simple chain. In order to OBTAIN a record using a symbolic key value, IDMS has to walk the chain to find the correct member.
This can cause performance problems and cause batch jobs to run slow.
Environment
Release : All supported releases.
Resolution
The hidden danger with sorted chained sets is that one simple DML (e.g. a STORE of a member or an OBTAIN ... USING) can result in potentially many record accesses internally. This is due to the fact that IDMS needs to position itself at the appropriate location in the set, and the only way to do this is to walk the chain.
If it were a user-owned indexed set, it would only have to traverse the index which is one record access at each level of the index, typically three but always a much smaller number than for a sorted set.
If the members are not stored VIA the owners, the danger is even more significant because each internal record access is potentially a distinct I/O.
In summary, only use a sorted set when each instance of the set will only contain a small number of members, and always avoid non-clustered sorted chained sets.
Additional Information
Feedback
