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



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


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.