User owned index sets should include LINKED TO OWNER pointers

Products

• IDMS

Issue/Introduction

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.

An example of such a program is available at Sample front-end program for rebuilding user-owned indexed sets.

This document describes the advantage of having owner pointers in the member records in case such rebuild is necessary.

Environment

Release: All supported releases.

Cause

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.

Example  :

     ADD
     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
             MANDATORY AUTOMATIC
             KEY IS (
                  EMP-LAST-NAME-0415 ASCENDING
                  EMP-FIRST-NAME-0415 ASCENDING )
               DUPLICATES ARE LAST
               NATURAL SEQUENCE
               COMPRESSED
     .

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 that indicates that the current member record is participating in the set occurrence that has to be processed.

Resolution

Using the above OFFICE-EMPLOYEE set definition as example, the front-end (Cobol) program could do the following (extract from program):

       READ-DB-001.
           OBTAIN CALC OFFICE.
           IF ERROR-STATUS = 0000
               ACCEPT O-DBKEY FROM CURRENCY.
           PERFORM IDMS-STATUS.
      *       Pass this owner record to TBLU.
           CALL 'IDMSTBLU' USING OWNERTYP.
      *       Perform an area sweep on the member records

       READ-DB-010.  
           OBTAIN FIRST EMPLOYEE WITHIN EMP-DEMO-REGION.

       READ-DB-020.
           PERFORM IDMS-STATUS.
           ACCEPT M-DBKEY  FROM CURRENCY.
           PERFORM IDMS-STATUS.
           ACCEPT M-ODBKEY FROM OFFICE-EMPLOYEE OWNER CURRENCY.
           PERFORM IDMS-STATUS.
      *       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.
           GO READ-DB-020.

       READ-DB-900.
           CALL 'IDMSTBLU' USING EOFTYP.

       READ-DB-950.
           FINISH.
           PERFORM IDMS-STATUS.