NCL File Processing › Work with Data › Key and Data Differentiation

Key and Data Differentiation

When a record is read from the UDB, whether it is a delimited format or an unmapped format file, NCL normally performs the following steps when preparing the data for presentation to the procedure, regardless of the key under which the record has been retrieved.

• The record is read as a single string.
• The full key of the record is extracted and placed in &FILEKEY.
• If the file being processed is a delimited format file and the record is not read under the base key, the section of the record previously occupied by the key is replaced by a field separator (X'FF').
• The remaining data is placed into the variables nominated on the &FILE GET statement according to the rules applicable to the type of UDB being processed.

The significant point here is that the key under which the record is retrieved is not, by default, regarded by NCL as part of the record data and does not therefore appear in the &FILE GET variables.

The result of this is that the same fields within a given record can be relocated into different &FILE GET variables, depending upon which key is used to read the record.

Previous figures show that when the records in the example are read by successive &FILE GET statements, the two separate fields of which the records are composed are placed into the two variables &1 and &2, as expected. &3, specified on the &FILE GET statement, is set to null since no data was available to place into it.

However, a different &FILE GET results when the alternate index is used to read the same two records. NCL has obeyed the rules for data presentation with the following result:

• The record is read under the alternate index key.
• The key used (LU01290A) is extracted and placed in &FILEKEY and replaced with a X'FF' field separator. Remember that the key in this case is followed by a field separator too, so now there are two consecutive field separators in the record.
• The data is placed into the nominated variables field-by-field, starting at the left-hand end of the record. This results in values:
  • &1 = RECORD0002
  • &2 = null
  • &3 = bbbbbbbb
  • The reason that &2 is null is because that which used to be the key value has been extracted from the record and replaced with a field separator. As NCL scans the data to determine the location of the various fields, two consecutive field separators are found indicating the presence of a null, or zero-length field. Consequently, &2 becomes a null variable. The result of this is that the data (bbbbbbbb) is no longer located in the same variable as it was when the record was read under the base key.

Note: When processing with alternate indices the positioning of the alternate key can significantly impact the way in which an NCL procedure must process the UDB. It is therefore recommended that you familiarize yourself with this process and try a few simple examples first, to ensure you understand it.