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