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