When using READE, READPE, SETLL for equality, or Sequential-within-limits
processing by a record address file, normally the key comparisons are done
at the data management level. However, there are some situations that do not
allow the key comparison to be done at the data management level. When data
management cannot perform the key comparison, the comparison is done using
the hexadecimal collation sequence. This may cause unexpected results. For
example, if ABSVAL is used on a numeric key, both -1 and 1 would be seen as
valid 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 features that cause the key comparison to differ are:
A Get Next Key Equal following a Read Multiple does not require a search
key to be provided. To circumvent this situation, issue an OVRDBF command
with either SEQONLY(*NO) or SEQONLY(*YES 1) specified so a Read multiple will
read only one record.
Keyed feedback was not requested for the file at open time.
The Read request was performed via a group-by view of the data. To circumvent
this situation, use a physical copy of the group-by data.
The file is a Distributed Data Management (DDM) file and the remote file
was created before Version 3 Release 1 Modification 0.
Some of the features that will cause a hexadecimal key comparison to differ
from a key comparison performed by data management are:
ALTSEQ was specified for the file
ABSVAL, ZONE, UNSIGNED or DIGIT keywords on key fields
Variable length, Date, Time or Timestamp key fields
ALWNULL(*USRCTL) is specified as a keyword on a control specification
or as a command parameter and a key in the record or search argument has a
null value. The key in the file or search argument has null values. This applies
only to externally described files.
SRTSEQ for the file is not hexadecimal
A numeric sign is different from the system-preferred sign
The CCSID of a key in the file is different from the CCSID of the job