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



Could be ... how are you with PEX?  I'm thinking of a call trace then
perhaps an MI trace.

Richard Jackson
mailto:richardjackson@richardjackson.net
www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Mel Rothman
Sent: Friday, August 18, 2000 8:28 PM
To: RPG400-L@midrange.com
Subject: Re: Character to Decimal


My pleasure, Richard.

I just noticed a typo in my note, below.  The machine I ran the tests on has
2 GB
of memory, not KGB.

It's possible that a good part of the expense associated with the exception
is
message handling stuff used by RPG to monitor/handle  it.



Mel Rothman


Richard Jackson wrote:

> Mel:
>
> I love this stuff!  Thanks for taking the time!  Sir, I owe you a beer.
>
> JDEdwards displays all numbers on display screens and prints all numbers
in
> reports in character fields.  When reading from a display, they use a
> routine called the "numeric scrub" to extract the numeric value from
> whatever the user typed into the display field.  The numeric scrub is
> written in RPG using arrays that is copied into every program.  The
> programmer loads a character array with the data from the screen and run
the
> routine using EXSR.  The number is returned in a zoned decimal variable.
> You can imagine how it performs.  When I see a performance difference like
> this, I have to think that there might be an opportunity there.
>
> Incidentally, JDE uses a direct call to the OS system editing program to
> edit numbers for display.  In the early 90s, the system program that
> performs editing is one of the few OS programs that you can directly call
> from a user program.
>
> I wonder why the exception is so expensive?  I suspect that there is
> something amiss in the built-in.  I looked at MI instruction "set
> computational attributes" because it allows certain exceptions to be
> suppressed but it doesn't seem to allow me to suppress this exception.
> Might there be something in process attributes or program attributes?  I
> want to know that the exception happened but they can skip the error
> messages.  Does anyone know why this MCH1201 is so expensive or have any
> ideas to make it cheaper but not invisible?  I think that 2.5 milliseconds
> is an eternity for a MI instruction.
>
> JDE does something else I wish that they would change when they move data
> between programs and the database.  I think that a routine sort of like
this
> might help.
>
> Richard Jackson
> mailto:richardjackson@richardjackson.net
> www.richardjacksonltd.com
> Voice: 1 (303) 808-8058
> Fax:   1 (303) 663-4325
>
> -----Original Message-----
> From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
> Behalf Of Mel Rothman
> Sent: Friday, August 18, 2000 1:12 PM
> To: RPG400-L@midrange.com
> Subject: Re: Character to Decimal
>
> Thanks for the code, Carsten.
>
> I used it as the basis for a subprocedure that converts a 32-char input
> string to a 30/9 packed field.
>
> I have another pure RPG subprocedure, based on Barbara Morris's code,
> that does the same thing.
>
> The timings reported below were run interactively on a KGB 9406-530.
> Each subprocedure was run 10,000 times.
>
> When the input contains no errors, _CVTEFN smokes the RPG-based code.
> For example:
>
> Input: '12345.6'  RPG: 13,262/second  _CVTEFN: 26,178/second.
> Input: '123456789012345678901.123456789'  RPG: 4,458/second  _CVTEFN:
> 33,222/second
>
> When the input contains errors, _CVTEFN signals an expensive MCH1201
> exception (Scalar data cannot be changed to type required by
> instruction).  I wrote my code to catch the exception and return an
> arbitrary (and therefore, incorrect) value.  Here are sample timings:
>
> Input: 'a-1a-..3' RPG: 13,477/second.  _CVTEFN: 441/second.
> Input: 'abcdefghijabcdefghij2.abcdefgh2' RPG: 5,1222/second.  _CVTEFN:
> 438/second.
>
> If I modify the code to unconditionally check and fix up the input,
> _CVTEFN performance in the previous examples jump to 12,468/second and
> 4,837/second, both slightly worse than the pure RPG approach.
>
> Unless I can find a more efficient way to check and fix up the input, I
> think I'll stick with the pure RPG approach.
>
> Mel Rothman
>
> Carsten Flensburg wrote:
> >
> > ----- Original Message -----
> > From: "Richard Jackson" <richardjackson@richardjackson.net>
> > To: <RPG400-L@midrange.com>
> > Sent: 18. august 2000 07:59
> > Subject: RE: Character to Decimal
> >
> > > I looked at both cvtefni and cvtefnd before sending my note.  I didn't
> like
> > > the looks of either version so I didn't talk about them.
> > >
> > > The CVTEFN MI instruction has all the goodness of being implemented
> below
> > > the MI.  Can we write a routine in MI and make it bindable
> >
> > Hi Richard,
> >
> > Here's an RPG/IV version using the equivalent _CVTEFN builtin:
> >
> >      ** Valid source string symbols:
> >      **   One sign symbol . :  - or +
> >      **   Decimal point . . :  .
> >      **   Comma . . . . . . :  ,
> >      **   Blank . . . . . . :  x'40
> >      **   Digit . . . . . . :  x'F0' - x'F9'
> >      **   Currency symbol as defined by mask
> >      **
> >      D T_SIGNED        c                   x'00'
> >      D T_FLOAT         c                   x'01'
> >      D T_ZONED         c                   x'02'
> >      D T_PACKED        c                   x'03'
> >      D T_UNSIGNED      c                   x'0A'
> >      **
> >      D Mask            Ds
> >      D  CurSym                        1a   Inz( '$' )
> >      D  ComSym                        1a   Inz( ',' )
> >      D  DecPntSym                     1a   Inz( '.' )
> >      **
> >      D DPA_Template_T  Ds
> >      D  SclTyp                        1a
> >      D  RcvLen                        5i 0
> >      D   DecPos                       3i 0 Overlay( RcvLen: 1 )
> >      D   TotDig                       3i 0 Overlay( RcvLen: 2 )
> >      D  Rsv                          10i 0 Inz
> >      **
> >      D CVTEFN          Pr                  ExtProc( '_CVTEFN' )
> >      D  RcvVar                         *   Value
> >      D  RcvAtr                             Const  Like( DPA_Template_T )
> >      D  Source                         *   Value
> >      D  SrcLen                       10u 0 Const
> >      D  SymMsk                             Const  Like( Mask )
> >      **
> >      D Source          s             25a   Inz( '-12,345,678.912' )
> >      D Packed          s             15p 4
> >      D Binary          s             10i 0
> >      **
> >      **-- Zoned & Packed:
> >      C                   Eval      SclTyp     = T_PACKED
> >      C                   Eval      DecPos     = %DecPos( Packed )
> >      C                   Eval      TotDig     = %Len( Packed )
> >      **
> >      C                   CallP     CVTEFN( %Addr( Packed )
> >      C                                   : DPA_Template_T
> >      C                                   : %Addr( Source )
> >      C                                   : %Len( %TrimR( Source ))
> >      C                                   : Mask
> >      C                                   )
> >      **-- Binary & Float:
> >      C                   Eval      SclTyp     = T_SIGNED
> >      C                   Eval      RcvLen     = %Size( Binary )
> >      **
> >      C                   CallP     CVTEFN( %Addr( Binary )
> >      C                                   : DPA_Template_T
> >      C                                   : %Addr( Source )
> >      C                                   : %Len( %TrimR( Source ))
> >      C                                   : Mask
> >      C                                   )
> >      **
> >      C                   Return
> >      **
> >
> > I haven't made any performance tests though, maybe someone else will
check
> out the cpu-consumption of the various routines?!
> >
> > Best regards,
> > Carsten Flensburg
> >

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