User Owned Index sets can be rebuilt by means of the MAINTAIN INDEX utility, but only if a front-end program is written which walks the index set and passes the involved owner and member records to the utility.
Knowledge document TEC1141084 contains an example of such a front-end program.
This document describes the advantage of having owner pointers in the member records in case such rebuild is necessary.
There have been situations where a user owned index set became corrupted and that a rebuild of the index set was necessary to remove the corrupted structures.
In those cases, the front-end program needs to walk the owner records and all of the member records. It is very well possible that the corruption doesn’t allow to find all member records via their owner records, e.g. by means of an OBTAIN NEXT IN index-set DML call. If so, the alternative is to access the member records in a different way, e.g.by means of an area sweep, and then find the owner record for each of them.
Normally, this can be done by means of an OBTAIN OWNER DML call, but again depending upon the nature of the corruption, it might be possible that this won’t work either.
In such case, it would be very helpful if the user owned index set was defined with owner pointers.
SET NAME IS OFFICE-EMPLOYEE
ORDER IS SORTED
MODE IS INDEX BLOCK CONTAINS 30 KEYS
OWNER IS OFFICE
WITHIN AREA ORG-DEMO-REGION
MEMBER IS EMPLOYEE
WITHIN AREA EMP-DEMO-REGION
LINKED TO OWNER
KEY IS (
EMP-FIRST-NAME-0415 ASCENDING )
DUPLICATES ARE LAST
In this case, the front-end program after reading a member record, can use the following DML call :
ACCEPT dbkey-workfield FROM setname OWNER CURRENCY.
This DML call will return the dbkey of the owner of the set occurrence as found in the prefix of the member record, without the need to issue an OBTAIN OWNER dml call. Note that this type of ACCEPT DML call is only allowed to use if the involved set has OWNER pointers.
If the front-end program needs to process a specific set occurrence only, then this dbkey can be compared with the dbkey of the owner record itself, and if they match, then you know that the current member record is participating in the set occurrence that has to be processed.
CA IDMS release 18.0, 18.5, 19.0
Operating Systems : z/OS, z/VSE
Using the above OFFICE-EMPLOYEE set definition as example, the front-end (Cobol) program could do the following (extract from program) :
OBTAIN CALC OFFICE.
IF ERROR-STATUS = 0000
ACCEPT O-DBKEY FROM CURRENCY.
* Pass this owner record to TBLU.
CALL 'IDMSTBLU' USING OWNERTYP.
* Perform an area sweep on the member records
OBTAIN FIRST EMPLOYEE WITHIN EMP-DEMO-REGION.
ACCEPT M-DBKEY FROM CURRENCY.
ACCEPT M-ODBKEY FROM OFFICE-EMPLOYEE OWNER CURRENCY.
* Check if Owner dbkey in Member record is equal to
* dbkey of owner (OFFICE) record.
* If so, pass this member along to TBLU.
IF M-ODBKEY = O-DBKEY
CALL 'IDMSTBLU' USING MEMBERTYP EMPLOYEE.
* Continue the area sweep of the members until 0307
OBTAIN NEXT EMPLOYEE WITHIN EMP-DEMO-REGION.
IF ERROR-STATUS = 0307 GO TO READ-DB-900.
CALL 'IDMSTBLU' USING EOFTYP.
Release: IDADSO00100-18.5-ADS-for CA-IDMS