Re: %CHAR() -- RPG400-L

Tom,

I think we are talking semantics here.  They are talking about the value
of the number, not the byte representation, which you are describing.

D Num1       S       6S  0
D Num2       S       6B  0
D Num3       S       6P  0

Those are all numeric variables that can contain the *value* 123.  Each
stores them in a different way.  But the BIF works on all 3 of them.

The Zoned does happen to store them in the character byte representation
of '00123'.  The other 2 store them in values that do not map well to 
character byte representations.  Read the documentation again but this time
don't think to yourself that they are talking about ZONED numbers, but ANY
number.

The way I read the documentation, it is doing exactly what it says it is
doing.  You are picking one subset (Zoned) from one of the many data types
that %char works on (graphic, UCS-2, Numeric, Date, Time or Timestamp) and
stating that %Char doesn't work as documented because it doesn't leave in
leading zeros and Zoned does.  Does that mean that for Packed it would take
out the leading zeros?  And for binary it would leave them out?  What about
graphic?  Should date have leading zeros (I don't know if it does or it
doesn't).

Regards,

Jim Langston

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



Regards,

Jim Langston

"Westdorp, Tom" wrote:
> 
> Jim,
> 
> Wow!  Really?  Write my own functions, and even bind them in?  The hell you
> say!
> 
> Sorry about the sarcasm, but really...
> 
> The point here is, as this thread started, we have a bif that does not
> conform to its documentation.  It says it converts numbers to characters
> without changing the value, but it removes leading zeros without being
> asked.  00123 converts to '123'.  That is a different value, '00123' is the
> same value.  To test this try comparing them.  MOVE one and either eval or
> evalr the other.  They are not the same value, an IF equal fails as does a
> COMP.  Even the system knows they are different values.
> 
> IBM says it works as designed.  I say that it duplicates the function of an
> existing bif or bif combination.
> 
> I'm sure the end result will be a change to the documentation, and I'll get
> over it.  However it is relatively early in the life of this bif and It's
> not unreasonable to think that the documentation is correct and the function
> performed by the bif should be changed to conform.
> 
> Tom Westdorp
> AS/400 Senior Programmer/Analyst
> 
> IBM Certified Specialist - RPG IV Programmer
> IBM Certified Specialist - RPG IV Developer
> Certified Master RPG IV Programmer
> Internal Telephone # 04-6859
> Voice: (702) 221-6859
> Fax:    (702) 221-6881
> tom.westdorp@stationcasinos.com
> 
> -----Original Message-----
> From: Jim Langston [mailto:jimlangston@conexfreight.com]
> Sent: Wednesday, November 22, 2000 8: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.
+---
| 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
+---