RE: %CHAR()

["Smith, Mike" <Smith-Mike@xxxxxxxxxxxxxxxxx>]

I know i remove my leading zeros with %char, and i know i can remove a
decimal just by moving to a character field.  but with the use of %char or
%editc or some combination can i remove leading zeros and suppress the
decimal point.  
ie Numbfield 7.2  (1234.21)
have it return (123421)

-----Original Message-----
From: Jim Langston [mailto:jimlangston@conexfreight.com]
Sent: Wednesday, November 22, 2000 11:44 AM
To: RPG400-L@midrange.com
Subject: Re: %CHAR()


Tom,

This is the beauty of ILE.  You don't like the way a BIF does something,
write your own!  Very simple to make a function that does exactly what
you want the way you want it and stick it in your directory for binding.
Give it whatever name you wish.  And then just call this function.

I understand that programmers are not wanting to do this, but it is the
only real logical way to go.  If you're not doing it today, I can almost
guarantee you that you will be someday.

It is really not that hard to build your own binding directory.  Put your
headers (pr declarations) into a /copy member.  Now in your programs you
have, what, one extra line of code at the beginning?

/COPY MyBind

And a few extra parameters to give when you compile.  Now you can use your
own functions in your programs.  IBM does something  you don't like?  Change
it and give it a new name.

I think the good folks at IBM could of written this BIF either way, leaving
in
leading zeros or taking them out.  Either way they did it, someone wouldn't
of
liked it <g>

Incidentally, the VALUE did remain unchanged.  '   123' is equal to one
hundred
twenty three.  Also consider that the number you are converting from could
be
in many different formats, IBM's version of BCD (Packed), Zoned, Binary.  Of
those
only one actually has the zeros and that is Zoned.  I think the argument
that
the original value had 0's is a mute point, because it's a number, not a
character.

I think we are going to find more and more that IBM is doing things
differently
then we would of wanted them done, and it is going to be much easier to just
build
our own functions to do them the way we want them to.  For every way IBM
does 
something, there's going to be 20 different ways people think it should of
been
done.  You can please some of the people some of the time...

Regards,

Jim Langston

"Westdorp, Tom" wrote:
> 
> Jim,
> 
> Your desired end is the perfect example of character conversion and a z
edit
> code combined to get an answer.  You want two things, conversion and
> editing, and %editc does two things conversion and editing.  'edit' + 'c'.
> %char on the other hand just says make things character, but then edits
the
> result to suppress leading zeros. %editc(fieldx:'Z') is clear and
> unambiguous, I submit %char(fieldx) to the same end is not.
> 
> As to "most PC applications do not use leading zeros" begs the question
> whose idea of most.  We convert a handful of fields from packed decimals
on
> the 400 send them through serial communications (albeit sometimes over
> TCP/IP) usually with LRC characters and in some cases with parity
checking.
> The formats are dictated by the other vendors to be character fields
> containing right justified numbers that are zero filled.  We do it
hundreds
> of thousands of times a day.  Frankly, that's all irrelevant.  The point
is
> that we have two bif's that do the same thing, one explicitly and one
> implicitly and the answer is to use the explicit one to specify an edit
code
> that says don't edit.
> 
> BTW, when I show my users numbers, I edit them.  %editc or %editw or an
edit
> code on DDS screen specs, etc.  Explicitly edited.  So everyone knows it
> happened.
> 
> As to XLATE, that's what we do in some cases because the choice was to
> either use a MOVE statement or EVALR followed by XLATE.  Either way I
ended
> up with a fixed format RPG400 statement in the middle of a bunch of RPGIV
> evals.  And a comment to tell the next guy why they are there.  And, as
you
> point out, it has to be the mix of MOVE's and EVALR + XLATE's because the
> EVALR + XLATE can produce unwanted substitutions in some cases.  Clear?
To
> some perhaps, but not as clear as a %char the just converts each number in
a
> field to its character value.
> 
> The 'taking out' I referred to is the zeros that disappeared not a command
> or bif or anything.  I know its relatively new, and arguably broken.
> 
> >From the book:
> >4.1.1.3 %CHAR (Convert to Character Data)
> 
> >  %CHAR(expression)
> 
> >%CHAR converts the value of the expression from graphic, UCS-2, numeric,
> date, time or
> >timestamp data to type character. The converted value remains unchanged,
> but is returned in >a format that is compatible with character data.
> 
> Note that it says the converted value remains unchanged.  To me that means
a
> zero is a zero and stays a zero.
> 
> There is a notation of:
> 
> >If a UCS-2 conversion results in substitution characters, a warning
message
> will be given in >the compiler listing if the parameter is a constant.
> >Otherwise, status 00050 will be set at run time but no error message will
> be given.
> 
> However, no mention is made of zero suppression or substitution in the
case
> of numeric values.
> 
> All that said, I will work around it however I still believe it is wrong
and
> should be APARed.  Early, before it becomes a legacy issue.
> 
> Tom Westdorp
+---
| 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
+---