On 16-May-2014 20:02 -0500, Vernon Hamberg wrote:
Going back to the OP, couldn't he use the INCREL parameter - I think
that's the one that used field names I don't know if it needs to use
hex for packed fields - haven't tried that lately.
The Include Records By Field Test (INCREL) parameter of the Copy File
(CPYF) could be used both to name the column(s) against which to perform
selection and to specify the numeric values using digits [in external
representation, optionally with sign and decimal point] instead of
having to use the hexadecimal strings [for internal representation] as
with the From Key (FROMKEY) and To Key (TOKEY) parameters when using a
number of keys.
However the INCREL implements without keyed I/O. Effectively the
request would perform similar to reading a Logical File defined with
non-keyed Dynamic Select (DYNSLT). The effect can be verified, seeing
that the records are read exclusively via QDBGETM instead of using the
keyed Access Path for which the records would be read instead via
QDBGETKY [for native; i.e. non-SQL I/O]. That effective table-scan to
find the row(s) could be detrimental to performance for large files or
in the scenario for the OP; though there were no supporting details
about the overall needs\application of the Copy File invocation as shown
in the OP, so non-keyed selection may not be an issue.
FWiW, AFaIK, the external representation of [positive] numeric values
should be supported on the FROMKEY\TOKEY parameters when using the Build
Key (*BLDKEY) for the first element of those parameters [instead of
number of keys, for which a binary string defines the key value]. For
some reason, the feature does not properly support SIGNED packed, so
UNSIGNED must be coded for the packed key field DDS K-Spec to avoid a
diagnostic warning [and incomprehensible results]. Not recalling the OS
code for implementing that feature, I can not fathom why the default
signed capability could not be easily supported [using data pointers].