|
Hello Barbara, My 'this' is the automatic trimming of leading zeros on a conversion operation. If the zeros come out it should be with an edit code or trim, it should not require an edit code to put them back. The included %trim just seems wrong to me. Typically the IBM position is (IIRC) that nothing goes away without the expressed desire of the user, however in this case it's two <clap> two <clap> two bif's in one (character conversion and trimming). I will try the edit code to return the zeroes, but I didn't ask for them to go away. :-) It seems to me that %trim(%char(fieldx)) is right and just %char(fieldx) to the same result is wrong. I'd argue that it's APARable, but I'm just one guy and others' opinions may differ. It's an issue here because we are doing a lot of conversions of data to/from pc based slot systems and ancillary hotel systems (e.g.. telephone switches, call accounting, point of sale). We take 'normal' numeric fields from our 400 applications and send them to the pc based systems as character strings within fixed formats. So there's a big difference between '123bb' and '00123'. To my chagrin, it bit me twice. "Fool me once..." :-( The character string behavior is great for actual character strings, but for 'numeric character strings' it's a pita. But it's not a big pain and I have... Tom Westdorp -----Original Message----- From: bmorris@ca.ibm.com [mailto:bmorris@ca.ibm.com] Sent: Monday, November 20, 2000 1:41 PM To: RPG400-L@midrange.com Subject: RE: %CHAR() > Date: Mon, 20 Nov 2000 11:10:27 -0800 > From: "Westdorp, Tom" <tom.westdorp@stationcasinos.com> > > This certainly seems to be an error to me, and it is the source of a lot of > remaining MOVE and/or XLATE statements in otherwise all eval form code. > This surely does not improve readability to anyone's eye, although it does > require some documentation in the form "Do NOT change the following MOVE(s) > to Eval's or necessary leading 0's will be lost." >> >> - -----Original Message----- >> From: M. Lazarus [mailto:mlazarus@ttec.com] >> Sent: Saturday, November 18, 2000 4:10 PM >>> >>> Remove the blanks of with %trim >>> >>> %trim(%char(xxxxx)) >>> %trim(%editc(xxxxx:yyy)) >>> %trim(%editw(xxxxx:yyyy)) >> There's no need to do that. These BIFs do it for you already. "This certainly seems to be an error to me ..." Tom, what "this" do you mean? I don't think you're talking about %trim since that only deals with leading blanks, not leading zeros. If you can't find an edit code or edit word to return leading zeros, you might consider a subprocedure that returns the input value with leading blanks changed to zeros. Then you could remove those MOVEL and XLATE lines, and just code this: C eval x = leadingBlanks (%editc(num : 'N')) Barbara Morris +--- | 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 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.