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



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

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

Follow-Ups:
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.