Re: Working around CPYF limitations of FROMKEY with signed keys

Charles Wilt wrote:

<<SNIP>>

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.

<<SNIP>>

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.

MBROPT(*UPDADD) can replace unique matched values.

If the vendor program uses the implicit *LIBL/CPYF versus any explicitly library qualified request such as *SYSTEM/CPYF, then there is the option to /trojan horse/ the invocation(s) by the application. Create a CPYF command with a version [placed ahead of QSYS during invocation] having the minimal number of parameters to handle all of the requests it makes.

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.

I was originally going to suggest an OVRDBF to a logical file, but then as now, it seems probably that was\is not an option since the key value selected is dynamic? I suppose if the -100 is intended to effect no records being selected, then the S/O LF seems reasonable, but I am still not sure about the capability of CPYF to do key selection on numeric values without *BLDKEY. Although omit of negative values implicitly makes the data unsigned, there is no BCD type [on i] which is unsigned; even if there [maybe] is the ABSVAL kwd or function to make the numeric column to be effectively unsigned.

Regards, Chuck