

Index Management › Retrieving Indexed Records
Retrieving Indexed Records
In contrast to locating member records of a chained set, CA IDMS/DB locates member record occurrences in an index by searching the index. CA IDMS/DB does not have to access each member record occurrence as with chain linkage.
Types of Processing
Because CA IDMS/DB searches the index rather than actual record occurrences, indexed sets provide a quick and efficient method for the following types of processing:
- Random retrieval by symbolic key or generic key—CA IDMS/DB can retrieve individual records randomly by means of a symbolic key. CA IDMS/DB can also retrieve a group of records by using a partial (generic) symbolic key. A string of characters, up to the length of the symbolic key, can be used as a generic key.
- Sorted retrieval by db-key, symbolic key, or generic key—CA IDMS/DB can retrieve records in sorted order if the index is ordered on db-key or symbolic key. In this case, the db-keys or symbolic keys in an index are automatically maintained in sorted order and records therefore can be retrieved in ascending or descending order by db-key or symbolic key. Because records can be accessed through more than one index, they can be retrieved in more than one sort sequence.
- Unsorted in exceptionally long sets—To locate the db-keys of members in an indexed set, CA IDMS/DB walks the index. Since accessing member record occurrences' db-keys in an index requires less database I/O than accessing the record occurrences themselves, CA IDMS/DB can retrieve the db-keys of member records in exceptionally long sets more efficiently if the records are related using an index rather than a chain. This type of processing is useful for finding the nth record in a set or for manipulating lists of db-keys.
- Physical sequential processing by db-key—Member record occurrences can be clustered through an index. With this storage mode, the physical location of member records reflects the ascending or descending order of their db-key. If occurrences of a record type are to be retrieved in sequential order, clustering them through an index reduces I/O. This type of processing is most efficient when used with a stable database.
Example When Owner Pointers
Assume that the DEPT-EMPLOYEE set in the sample database is an indexed set sorted by employee identification number (EMP-ID-0415). To retrieve an occurrence of the EMPLOYEE record, a program might issue the following requests:
MOVE '0019' TO EMP-ID-0415.
OBTAIN CALC EMPLOYEE.
OBTAIN NEXT WITHIN DEPT-EMPLOYEE SET.
To fulfill the prior request, CA IDMS/DB performs the following processing:
Step 1
Using the value '0019' placed by the program in the EMP-ID-0415 field, obtains the EMPLOYEE record with an identification number of '0019'.
Step 2
Obtains the EMPLOYEE record with the next-highest identification number as follows:
- Finds the SR8 record pointed to by EMPLOYEE 19's index pointer.
- Searches the SR8 record for EMPLOYEE 19's db-key. If CA IDMS/DB finds EMPLOYEE 19's db-key, processing skips to Step 3. If CA IDMS/DB does not find EMPLOYEE 19's db-key, processing continues as follows:
- Decrements the SR8 record's orphan count by 1. If the orphan count is now 0, CA IDMS/DB erases the SR8 record if it is empty or rewrites it if it still contains entries.
- CA IDMS/DB searches the next SR8 record in the index until it finds the db-key. At this time, CA IDMS/DB updates the EMPLOYEE record's index pointer to point to the correct SR8 record.
Note: CA IDMS/DB only updates pointers and the orphan count at this time if both the area that contains the SR8 records and the area that contains the EMPLOYEE records were readied in update mode.
Step 3
Obtains the EMPLOYEE record whose db-key is adjacent to current of set (that is, the next EMPLOYEE record).
Example When No Owner Pointers
If the EMPLOYEE record did not have owner pointers, a program could issue the following request to retrieve an occurrence of the DEPARTMENT record:
MOVE '0019' TO EMP-ID-0415.
OBTAIN CALC EMPLOYEE.
OBTAIN OWNER WITHIN DEPT-EMPLOYEE SET.
When fulfilling the above request, the DBMS would discover the lack of an owner pointer in the set and use the EMPLOYEE record's index pointer to find the bottom-level SR8 record that contains the key for the requested EMPLOYEE record. CA IDMS/DB will then use the owner pointer contained in that SR8 record to obtain the DEPARTMENT record.
SR8 Record Currency
When a program uses a subschema that contains records in an indexed set, CA IDMS/DB changes SR8 record currency only when it accesses a member record through the index, since CA IDMS/DB keeps track of SR8 record currency internally. When CA IDMS/DB accesses a member record in any other manner, CA IDMS/DB does not change SR8 record currency.
For example, a program might issue the following commands:
MOVE '0019' TO EMP-ID-0415.
OBTAIN CALC EMPLOYEE.
OBTAIN NEXT WITHIN EMP-LNAME-NDX SET.
CA IDMS/DB then fulfills these requests as follows:
- Using the value '0019' for CALC entry into the database, CA IDMS/DB accesses the EMPLOYEE record with that identification number. EMPLOYEE 19 is now current of run unit, record, and the EMP-LNAME-NDX set. At this point, since CA IDMS/DB has not accessed an SR8 record, internal currency is not created for the SR8 structure of the index set.
- On OBTAIN NEXT, CA IDMS/DB accesses the SR8 record that contains the index entry for EMPLOYEE 19. At this time, CA IDMS/DB makes this SR8 record the current record of the SR8 structure of the index set.
- CA IDMS/DB finds the next index entry (either in that SR8 record or the next SR8 record). The SR8 record containing that index entry is now current of the SR8 structure.
- Using the next index entry, CA IDMS/DB obtains the corresponding EMPLOYEE record. That EMPLOYEE record is now current of run unit, record, and the EMP-LNAME-NDX.
RETURN and FIND Commands
When a program uses a subschema that contains records in an index, use:
- The RETURN command to retrieve database keys and/or symbolic keys from the index without accessing database records.
- The FIND command to maintain indexed set currency.
Copyright © 2014 CA.
All rights reserved.
 
|
|