RE: %CHAR() -- RPG400-L

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





-----Original Message-----
From: Jim Langston [mailto:jimlangston@conexfreight.com]
Sent: Tuesday, November 21, 2000 1:09 PM
To: RPG400-L@midrange.com
Subject: Re: %CHAR()


I can understand why it would be desirable not to have leading 
zeros.  Most PC applications do not use the leading zeros.  Such
as dBase files, if I remember correctly.  They would store the number
123 as '   123' or '123    ' (don't remember which).

When I show my users numbers, I don't want to show them leading
zeros either.  I would much rather show them '   123' than '000123'.

The only reason to keep the leading zeros in, then, is for certain
applications, in which case, just use the XLATE.

I don't think this is a matter of taking anything out, this is a 
new command.  New commands usually do something differently.

I think it's a lot easier to change spaces to zeros then to change
zeros to spaces.  

' ':'0'    XLATE    MyVar   MyVar

works fine to put zeros in to a string such as '  1030.28 ' and makes
it '001030.280'

'0':' '    XLATE    MyVAr   MyVar

does not work on the string '001030.28 ' as it produces '  1 3 .28 ' which
is obviously not what I want.

Regards,

Jim Langston

"Westdorp, Tom" wrote:
> 
> This seems *VERY counter-intuitive to me.  If I just want a number
literally
> converted to character I use %editc and tell it not to edit (which would
> then just be c), but if I want it zero suppressed (aka edited) and
converted
> to character I use %char???  And the main bif for a straight conversion is
> not %char but rather %editc with an edit code specified to do nothing???
> Now I understand why this isn't in the manuals, because when you write it
> down it just doesn't make sense.  ;-)
> 
> I now understand how this works, but as to why <scratch head>
> 
> btw, Thanks Barbara.  I don't want to have this construed as 'getting on
> your case' or anything, I appreciate your explanation and guidance in this
> matter and others.  This one seems bass ackwards to me, but I'll get over
> it.  There's a lot of stuff in life that doesn't make sense to me... e.g.
> Michael Douglas & Catherine Zeta Jones.  But that's off topic.
> 
> Tom Westdorp
> 
> -----Original Message-----
> From: bmorris@ca.ibm.com [mailto:bmorris@ca.ibm.com]
> Sent: Tuesday, November 21, 2000 8:58 AM
> To: RPG400-L@midrange.com
> Subject: RE: %CHAR()
> 
> >Date: Mon, 20 Nov 2000 14:28:42 -0800
> >From: "Westdorp, Tom" <tom.westdorp@stationcasinos.com>
> >
> > ...
> >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.
> > ...
> 
> Tom, %char(num) isn't intended to be the main "convert numeric to
> character" bif, it's just intended as a convenience, to make it easy
> to convert numeric to character for "casual" conversions.  It's basically
> the same as %trim(%editc(num : 'P')).
> 
> %char can only do one thing.  For that one thing we tried to pick the end
> result of what's most usually wanted.  The only "customization" available
> is the module-wide decision about whether the decimal point is a period
> or a comma.  %editc and %editw are still the bifs to choose if you want
> customizable conversion from numeric to character.
> 
> Barbara
> 
> +---
> | 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
> +---
+---
| 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
+---