Re: CPYF bug - or working as designed?

OK. So it uses varying character to get the *INT2 length of the value passed to the CPP QCPEX0FL [instead of TYPE(*X)]; which also means that numeric /value/ specifications are also passed as character data. The issue\effect remains the same however, irrespective of the PARM definition used to get there.

I can not explain why they [the OS CP /copy utility/ design and development] did not effect padding for the specified /value/ to the length of the field [the _key_ field for xxKEY parameters]. The docs sure do little to explain the effects for the INCREL parameter [or for the FROMKEY and TOKEY parameters when not using *BLDKEY]. The docs even seem to imply padding, per the suggestion that one can "use the INCREL parameter to select records for copying by testing for the value of an *entire* field." [emphasis mine]. But I can confirm the effects for testing only for the length of the field for the length of the supplied value, has always been that way; as I described in my earlier reply.

So as I noted, what is seen is either working-as-coded or working-as-designed. And if the former, then the effects are unlikely to ever change [without some new element or parameter to influence the behavior]. As I had alluded in a older message to which a link was provided, I thought there was a "Technical Document" KB article on the IBM service\support website that described the effect, but I found none then and I found none still. One could submit an electronic reader feedback\comment from the page(s) of on the InfoCenter which document these parameters; e.g. the following page and its subtopics:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/dm/rbal3selrecords.htm

And FWiW... That is what some of us in the lab referred to as a .feeture. because it is an effect that is not generally the most desirable, yet it serves a valid function in the manner that it works. So although it is not regarded as a /feature/ in the preferred sense, described with the spelling as /feeture/ implied its possibly specious effect; just as how both _words_ would be pronounced the same and similar enough when written to convey a message, even if not the genuine spelling ;-)

Regards, Chuck

On 08 May 2013 08:43, Steve Landess wrote:

RTVCMDSRC output:
<<SNIP>>
31400 ELEM TYPE(*CHAR) +
31500 LEN(256) +
31600 SPCVAL( +
31700 (*NULL )) +
31800 MIN(1) +
31900 EXPR(*YES) +
32000 VARY(*YES) +
32100 PROMPT('Value')
<<SNIP>>
* * * * E N D O F S O U R C E * * * *

On 07 May 2013 16:15, CRPence wrote:

Working /correctly/ as coded; thus probably a .feeture. ;-)
Whether that is working-as-designed is moot, after having always
functioned that way... since the S/38, I believe. The value passed
on the INCREL parameter has an actual or effective length attribute
[ELEM TYPE(*X) I believe; someone could use their version of a
RTVCMDSRC to validate that], and the /field/ being compared against
the specified /value/ elment is compared only up to the length of
the literal value that was specified. Thus the comparison is
effectively the following predicate [as expressed using SQL; e.g.
as a predicate in a WHERE clause]:
left(LMLL, length('BR_T')) = 'BR_T'

At the command line [i.e. a command string without a CL variable
for the /value/ element of the Include Relationship], to copy just
the one row with the value 'BR_T', use the following
specification:
INCREL((*IF LMLL *EQ 'BR_T '))

Or similarly, as I had explained here:
http://archive.midrange.com/midrange-l/201107/msg00408.html

<<SNIP>>