Using a Path to Access Records

When you are processing records sequentially using a path, records from the base cluster are returned according to ascending or, if you are retrieving the previous record, descending alternate key values. If there are several records with a nonunique alternate key, those records are returned in the order they were entered into the alternate index. READNEXT and READPREV returns these nonunique alternate index records in the same sequence. VSAM sets a return code in the RPL when there is at least one more record with the same alternate key to be processed. For example, if there are three data records with the alternate key 1234, the return code would be set during the retrieval of records one and two and would be reset during retrieval of the third record.

When you use direct or skip-sequential access to process a path, a record from the base data set is returned according to the alternate key you specified in the argument field of the RPL macro. If the alternate key is not unique, the record first entered with that alternate key is returned and a feedback code (duplicate key) is set in the RPL. To retrieve the remaining records with the same alternate key, specify RPL OPTCD=NSP when retrieving the first record with a direct request, and switch to sequential processing.

You can insert and update data records in the base cluster using a path if:

The PUT request does not result in nonunique alternate keys in an alternate index (defined with the UNIQUEKEY attribute). However, if a nonunique alternate key is generated and the NONUNIQUEKEY attribute is specified, updating can occur.
You do not change the key of reference between the time the record was retrieved for update and the PUT is issued.
You do not change the primary key.

When the alternate index is in the upgrade set, the alternate index is modified automatically by inserting or updating a data record in the base cluster. If the updating of the alternate index results in an alternate index record with no pointers to the base cluster, the alternate-index record is erased.

Rule: When you use SHAREOPTIONS 2, 3, and 4, you must continue to ensure read/write integrity when issuing concurrent requests (such as GETs and PUTs) on the base cluster and its associated alternate indexes. Failure to ensure read/write integrity might temporarily cause "No Record Found" or "No Associated Base Record" errors for a GET request. Bypass such errors by reissuing the GET request, but it is best to prevent the errors by ensuring read/write integrity.