Using Pre-V3R1 DDM Files
If you are using a pre-Version 3 Release 1.0 DDM file, the key comparison is not done at the Data Management level during a READE or READPE operation, EQ indicator for SETLL, or during sequential-within-limits processing by a record address file. The READE or READPE operation, EQ indicator for SETLL, or during sequential-within-limits processing by a record address file, will instead compare the keys using the *HEX collating sequence.
This may give different results than expected when DDS features are
used that cause more than one search argument to match a given key in the
file. For example, if ABSVAL is used on a numeric key, both -1 and 1 would
succeed as search arguments for a key in the file with a value of 1. Using
the hexadecimal collating sequence, a search argument of -1 will not succeed
for an actual key of 1. Some of the DDS features that cause the key comparison
to differ are:
- ALTSEQ specified for the file
- ABSVAL, ZONE, UNSIGNED, or DIGIT keywords on key fields
- Variable length, Date, Time, or Timestamp key fields
- The SRTSEQ for the file is not *HEX
- ALWNULL(*USRCTL) was specified on the creation command and a key in the record or the search argument has a null value (this applies only to externally described files)
In addition, if the sign of a numeric field is different from the system preferred sign, the key comparison will also differ.
The first time that the key comparison is not done at the Data Management
level on a pre-V3R1 DDM file during the READE or READPE operation, EQ indicator
for SETLL, or during sequential-within-limits processing by a record address
file, an informational message (RNI2002) will be issued.
Note: The performance of I/O operations that have the possibility of not finding
a record (SETLL, CHAIN, SETGT, READE, READPE), will be slower than the pre-Version
3 Release 1.0 equivalent.