× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: %CHAR()
  • From: Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>
  • Date: Wed, 22 Nov 2000 10:46:04 -0800
  • Organization: Pacer International

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

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.