× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. RPG400-L
  3. January 2001

RE: CPYF using Variables in CLP

  • Subject: RE: CPYF using Variables in CLP
  • From: Evan Harris <spanner@xxxxxxxxxx>
  • Date: Tue, 23 Jan 2001 08:15:35 +1300
 
Darlene

I have encountered this annoying behaviour before (and just tested it again 
this morning). If you specify a variable as the value to test, the CPYF 
seems to strip off the blanks from the variable before performing the test 
(as you observed). Specifying a string in the CPYF with a blank between the 
quotes seems to work. I can kind of see why this might be the case although 
it can be annoying.

There may be some history as to why the behaviour is so (or I could be 
wrong :) )

Perhaps you would be better placed using OPNQRYF and CPYFRMQRYF which seems 
to behave more as one would expect.

Hope this helps
Evan Harris

>If I define the variable (&FPRDN) as *CHAR 15, the CPYF command truncates the
>ending blanks, and the result I get are any product numbers at start with
>'E-1182PF', so I get all the E-1182PF records and all the E-1182PFS 
>records  and
>so on....
>
>CLP CPYF CODE <snip>
>DCL        VAR(&FPRDN) TYPE(*CHAR) LEN(15)
>  CPYF       FROMFILE(&LIBRARY/&FILE) +
>               TOFILE(QTEMP/BMHSP100X) FROMMBR(&FMEMBER) +
>               TOMBR(&TMEMBER) MBROPT(*ADD) +
>               CRTFILE(*YES) INCREL((*IF PRDNO *EQ +
>               &FPRDN)) FMTOPT(*MAP *DROP)
></snip>
>
>Joblog...
>  4500 - CPYF FROMFILE(*LIBL/BMHSP100) TOFILE(QTEMP/BMHSP100X)
>  FROMMBR(M202) TOMBR(M102) MBROPT(*ADD) CRTFILE(*YES) INCREL((*IF PRDNO
>  *EQ 'E-1182PF'))
>
>I also just received a message about the archives having some information on
>this subject, I looked at the archive links, but they do not help me any 
>on this
>problem..
>
>Thanks again for all your responses,
>Darlene
>
>
>
>
>|--------+--------------------------->
>|        |          "McCallion,      |
>|        |          Martin"          |
>|        |          <MccalliM@Midas-K|
>|        |          apiti.com>       |
>|        |                           |
>|        |          01/22/2001 10:30 |
>|        |          AM               |
>|        |          Please respond to|
>|        |          RPG400-L         |
>|        |                           |
>|--------+--------------------------->
>   >--------------------------------------------------------|
>   |                                                        |
>   |       To:     "'RPG400-L@midrange.com'"                |
>   |       <RPG400-L@midrange.com>                          |
>   |       cc:     (bcc: Darlene H Bryant/Banpharm)         |
>   |       Subject:     RE: CPYF using Variables in CLP     |
>   >--------------------------------------------------------|
>
>
>
>
>
>
>dbryant@banpharm.com wrote:
>
> > It states to enter the character value without the 2-byte length
>field. The
> > length of the data that is entered determines the number of bytes that
>are used
> > for the comparison. If the actual data in the variable-length
>from-field is
> > shorter that the value specified for the INCREL parameter, the
>from-field data
> > is padded with single-byte blanks (X'40) for the comparison.
> >
> > BTW,    PRDNO is a 15 character field.   And we are on V4R4.
> >
> > So I left off the field length in the DCL ....
> >
> > DCL        VAR(&FPRDN) TYPE(*CHAR)
> >
> >
> >  CPYF       FROMFILE(&LIBRARY/&FILE) +
> >               TOFILE(QTEMP/BMHSP100X) FROMMBR(&FMEMBER) +
> >               TOMBR(&TMEMBER) MBROPT(*ADD) +
> >               CRTFILE(*YES) INCREL((*IF PRDNO *EQ +
> >               &FPRDN)) FMTOPT(*MAP *DROP) ERRLVL(*NOMAX)
> >
> > Here is the result I get now....
> >
> >      4500 - CPYF FROMFILE(*LIBL/BMHSP100) TOFILE(QTEMP/BMHSP100X)
> >      FROMMBR(M202) TOMBR(M102) MBROPT(*ADD) CRTFILE(*YES)
> > INCREL((*IF PRDNO
> >      *EQ 'E-1182PF       01020102000000000')) FMTOPT(*MAP *DROP)
> >      ERRLVL(*NOMAX)
> >    Value in INCREL expression number 1 not valid.
> >    Copy command ended because of error.
> >
> > It did insert the blanks as needed at the end of the product
> > number variable,
> > but I am receiving an extra 17 bytes from somewhere.
> >
> > I looked at my compiled version of the CLP and it has the
> > variable &FPRDN
> > defined as 32 in length.
>
>I don't know what your first paragraph, about leaving off the length,
>refers to, but I don't think it means decalare the comparison field with
>no length.
>
>You haven't declared a length for the field &FPRDN, so the system
>defaults it to 32 bytes.  This is standard behaviour for CL..  I presume
>that the INCREL is then failing because the fields are different
>lengths, although this surprises me somewhat.  I'd expect it to fail if
>they were different data types, but not just different lengths.
>
>Try defining &FPRDN as 15 bytes and see what happens.
>
>Cheers,
>
>Martin.
>
>--
>Martin McCallion
>Midas-Kapiti International
>Work:  mccallim@midas-kapiti.com
>Home: martin.mccallion@ukonline.co.uk
>
>Apologies for the length of this sig, but company policy says:
>This email message is intended for the named recipient only.  It may be
>privileged and/or confidential.  If you are not the intended named
>recipient of this email then you should not copy it or use it for any
>purpose, nor disclose its contents to any other person.  You should
>contact Midas-Kapiti International as shown below so that we can take
>appropriate action at no cost to yourself.
>
>Midas-Kapiti International Ltd, 1 St George's Road, Wimbledon, London,
>SW19 4DR, UK
>Email: Postmaster@midas-kapiti.com Tel: +44 (0)208 879 1188 Fax: +44
>(0)208 947 3373
>Midas-Kapiti International Ltd is registered in England and Wales under
>company no. 971479
>+---
>| This is the RPG/400 Mailing List!
>| To submit a new message, send your mail to RPG400-L@midrange.com.
>| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
>| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator: david@midrange.com
>+---
>
>
>
>+---
>| This is the RPG/400 Mailing List!
>| To submit a new message, send your mail to RPG400-L@midrange.com.
>| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
>| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator: david@midrange.com
>+---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.