Re: cpyf with key that is packed

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].