|
midrange.com
I can think of many ways to do this, but not with a combination of %char
and %editc. This is a definite need for directory (library) function.
Use %Char(Number) to return '1234.21'. The following code works, and I
will admit, it is in no way pretty. I am just evaluating SomeChar to '1234.21'
because I'm on V3R7M0 and I don't have the %Char bif. If I had to do something
like this, I would write this as a function and stick it in a library so I never
had to see this ugly code again <g>
* SomeNum is actually not used in the code, but this is what you would
* do an Eval SomeChar = %Char(SomeNum) on.
D SomeNum S 10S 2 Inz(1234.21)
D SomeChar S 10A
D Result S 10A
D Position S 3B 0
C Eval SomeChar = '1234.21'
C '.' SCAN SomeChar Position 99
C If Position <> 0
C Eval Result = %SubSt(SomeChar:1:Position - 1)
C + %SubSt(SomeChar:Position + 1)
C Else
C Eval Result = SomeChar
C EndIf
C Result Dsply
C Eval *INLR = *On
Regards,
Jim Langston
"Smith, Mike" wrote:
>
>
> 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
> +---
+---
| 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 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.
