Re: Working around CPYF limitations of FROMKEY with signed keys

On Tue, Sep 29, 2009 at 1:50 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

Charles Wilt wrote:

I've got a need to enable the CPYF  using the FROMKEY/TOKEY
parameter with a signed numeric key when one specific file is
being copied. The call to CPYF is being done in a vendor's
program.

Basically, the vendor's program will do

CPYF FROMFILE(LIB1/MYFILE) TOFILE(LIB2/MYFILE)
     FROMKEY(1 -100) TOKEY(1 -100)

I'm thinking that QIBM_QCA_CHG_COMMAND may be my answer.

I can build an exit program that check to see if CPYF is being
used on MYFILE with the FROMKEY and TOKEY parameters.  If so, I
could invoke a custom written program to copy the appropriate
records.

  I really do not understand the intention as described.  Does that
mean to imply that there is no access to the vendor program to
correct their invocation?  Why not just ask the vendor to correct
their program?

The vendor doesn't show any interest in changing their application. I
had contacted them hoping there was a exit point in their software
that would allow me to specify my own program instead of using CPYF.

I'd set the vendor software up so that it passed the value as
character

CPYF FROMFILE(LIB1/MYFILE) TOFILE(LIB2/MYFILE)
     FROMKEY(1 '-100') TOKEY(1 '-100')

  So there is some ability to change the software.?

Does anybody see any possible issues with this?

The application includes a screen similar to the CPYF prompt screen
itself, I'm assuming that whatever values I key there for filename and
FROM/TO key values are simply passed to CPYF. I expect that the
vendor isn't trying to validate that the values "make sense" for the
given file name and simply rely on CPYF validating the parms.

  I do not expect the character string value '-100' to function any
better than the value -100 [treated as numeric value].  The former
is a character string x'60F1F0F0' which is not even valid BCD
numeric data, and the latter is presumably passed to the CPP of the
CPYF as x'000000010000000D' and then utilized as a binary string of
the length-in-bytes of the field.

The idea is that I'd have a custom command and CPP that would except
the string value, convert it into a proper numeric and copy the
selected records properly. Probably using a simple SQL statement.

I'd use QIBM_QCA_CHG_COMMAND to replace the CPYF command only when
CPYF was being used on one specific file and only when the
FROMKEY/TOKEY parms were specified.

I believe the desired
specification is FROMKEY(*BLDKEY (-100)) TOKEY(*BLDKEY (-100)).

  IIRC the non-*BLDKEY /key/ values for numeric types must be
specified using hex notation to match the internal representation of
the numeric data type & length.  For example, by using x'123D' for a
P(3,1) column to select the key values of -12.3 from the key.  But
even that is problematic as I recall, because the character value
for the FROMKEY() and TOKEY() are treated as binary strings instead
of being mapped to the internal type for any comparisons; e.g.
fromkey(1 x'100D') tokey(1 x'000F') may yield no results for an
ascending key, because the CPYF dismisses the illogical selection.?

I don't believe *BLDKEY would help even if the vendor's input screen
supported it, which it doesn't. The documentation for CPYF doesn't
say anything about *BLDKEY allowing signed keys; plus if I recall
correctly I tried it out a couple of months ago when I first started
investigating the issue and CPYF still choked on the signed keys.

I was originally thinking CPYF should be ok, as the file in question
has 3 key fields, all signed. But for my purposes, the only key field
that matters in the first one and I'm only looking for a specific
value, not a range. But I couldn't get it to work.

In any event, I'm now think that QIBM_QCA_CHG_COMMAND isn't going to
help either because the vendor must have another piece of the
application that deletes existing records in the TOFILE for the
specified FROMKEY/TOKEY range before they actually invoke CPYF. Since
it doesn't appear that CPYF itself handles replacing a specific range
of records.

Another thought is a select/omit logical that omits the negative
values and redefines the key fields from signed packed to unsigned
zone. As there really shouldn't be any negative keys in production.
I might play some with that possibility.

-Charles