Re: CPYF bug - or working as designed?

[CRPence <CRPbottle@xxxxxxxxx>]

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