MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » October 2004

RE: CPYF question



fixed

I see that Simon already answered, but I have another question or two, plus
a rant to throw in.

I, too, was surprised at your initial results. *EQ is equal, not "like".  I
don't really care what the CPYF help says; it is not intuitive.  We do not
see this type of behavior (that you saw in CPYF) in RPG, nor in CL, nor in
SQL.  (If I'm wrong, man I better buy a one-way ticket to Tahiti.)

Simon said: "The help text for the parameter states that the value must be
enclosed in quotes if it contains blanks or special characters."  But, the
help specifically refers to the "character string value" which I would
initially take to mean a literal value, not a variable's value.  Also, in
CL, strings need to be enclosed in apostrophes only if there are embedded
blanks.  Here is a test I ran:

Pgm

   Dcl   &Var5    *Char  (    5   ) Value( 'MI   ' )

   If   (&Var5 *eq 'MI' )  Then( SndPgmMsg 'OK! with quotes' )
    Else                         SndPgmMsg 'Nada! with quotes'

   If   (&Var5 *eq  MI  )  Then( SndPgmMsg 'OK! without quotes' )
    Else                         SndPgmMsg 'Nada! without quotes'

Got "OK" message on both tests.  So I tried a CPYF on a file well suited for
this test:

   CPYF       FROMFILE( VATTBL ) TOFILE( *PRINT ) +
                INCREL(( *IF TXSUF *EQ &Var5 ))

and, sure enough, got the same type of results Paul experienced.

Here's where it gets really frustrating.  I must be the one having the
senior moment now, cuz I can't figure out how to embed the value of &Var5
within apostrophes.  I've tried several variations, but I keep getting
CPF2843 "Value in INCREL expression number 1 not valid."  So, how does one
do this?

But I still say "cow chips" on the whole matter.  *EQ is equal.  'MI123'
does NOT equal 'MI' and I don't give a flip what any help says that counters
that.

(BTW, I know it's never going to change, but it's just one more idiosyncracy
to have to keep track of to avoid butt burn.)

db

> -----Original Message-----
> From: midrange-l-bounces.com@xxxxxxxxxxxx / pnelson@xxxxxxxxxx
> Sent: Wednesday, October 06, 2004 7:19 PM
>
> I must be having a senior moment here. On a V5R2 machine, I just ran a
> CPYF command where I substituted a variable in a CL program. The
> shortened version of the statement was this:
>
> crtfile(*no) increl((*if ptcmpy *eq &coa) +
> (*and ptloc *eq &loc) (*and ptpart *eq +
> &part)) fmtopt(*map *drop)
>
> In this example, ptloc is a 6 character field. The variable I
> entered were
> the 4 characters 0893. I was expecting to retrieve 1 record based on the
> combination of the ptcmpy, ptloc and ptpart fields. What I got was 7
> records because the same part number exists 7 times for the company I
> requested. The location field in these 7 records looks like this:
>
> 0893
> 089303
> 089304
> 089311
> 089312
> 089323
> 089333
>
> Why did CPYF pick up all 7 records? When I ran the command from a command
> line, and I typed 0893 as the value of the location. I got all 7 records.
> When I made the value '0893  ' it worked fine. I need this to have an
> absolute value, not a "looks like".
>
> Paul Nelson
> Arbor Solutions, Inc.
> 708-670-6978  Cell
> pnelson@xxxxxxxxxx






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact