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