NCL File Processing › Work with UDBs › Retrieve Data Using Alternate Indexes

Retrieve Data Using Alternate Indexes

Access to UDBs via an alternate index is similar to standard base key access, but the way the data is presented to the NCL procedure after completion of the &FILE GET is different.

As with standard base cluster usage, the NCL procedure must nominate the UDB to be processed:

• For base cluster processing, the ID operand on the &FILE statement is used to identify the logical file ID associated with the DD statement that defines the base cluster data set in the execution JCL.
• For alternate index processing the ID operand on the &FILE statement identifies the logical file ID associated with the DD name that defines the Path to be used. (Remember that access to a cluster using an alternate index is achieved via a VSAM path definition only and that no direct processing is done on the alternate index cluster itself.)

  

  This figure shows the different views of the data in two records on a base cluster that are seen when the UDB is accessed through the base key or through the alternate index key. (In each of the example records shown, the key portion is shown in plain text and the data portion is shown underlined.)

  

This figure show an example of reading records by using the base key. In the example shown in these figures, the UDB is a UDB (or delimited) format file and each record contains two data fields. The data fields are each terminated by a field separator (X'FF'), although these are not shown in the diagrams. The alternate index key in this example is chosen to overlay exactly the first data field, but does not include the field separator character at the end of the field.

The base key's view of a record on the UDB is that the first 10 bytes of a record are its key and that everything else is data. The alternate index view shows that everything is data, apart from the 8 bytes starting at offset 10 in each record. following example shows the effect of these conflicting views on the data actually presented to an NCL procedure on completion of an &FILE GET statement.

For the example, we will assume that the logical File ID to be used when accessing the base cluster directly is MYBASE and the logical file ID used to access the base cluster via its alternate index is MYPATH.

The previous figure shows how data is presented to an NCL procedure that reads records from the example UDB, using the base key to access the file. As noted before, it is assumed here that the alternate key is in fact a separate field within the record, although this does not have to be the case.

This figure shows the same sequence of events, but with access to the UDB being via the alternate index. There are two significant differences in the results of the &FILE GET statements compared with using the base key:

• The order of the records is different.
• The data presented in the &FILE GET variables is different.

Records on the UDB are always arranged in ascending key order, according to the key being used to access the UDB.

Therefore, when using the base key the order of the records on this example UDB is:

RECORD0001........
RECORD0002........  and so on.

However, when viewed from the perspective of the alternate index, the order of the records on the UDB has nothing to do with the value of the base key; as far as the alternate index is concerned the UDB is arranged in ascending order of the alternate keys of the various records on the file. As a result, when accessing records via the alternate index, the order becomes:

LU01290A.......
LU42600A.......  and so on.

and so, as shown in the figures, the order in which the physical records are retrieved from the UDB depends upon which key is being used to access the file.