|
-----Original Message----- From: Booth Martin <boothm@ibm.net> >Bob Crothers wrote: >> >> Karen, >> >> Yes, it is best (from a performance point of view) to use odd >> length packed numeric data in your files. > > >Doesn't db/400 ignore the packed vs. zoned definitions now? I thought >all numeric fields were packed regardless of what one writes in the dds. >About the odd vs even issue: if you need 8 characters, then you need 8 >at least so you can't go to 7. My understanding always was that the >cycles for 8 are the same price as the cycles for 9, so the 9th >character is a freebie, excepting dasd. 1) I've never heard anything about the system "ignoring" packed vs.. zoned before. I'm not saying you're wrong, just that that's a new one on me. They could conceivably do that, but why would they? 2) In RPG there is a performance advantage to using odd-length packed, because the compiler uses packed for all calculations and therefore must convert non-packed numbers in both directions, and because when putting a value into an even-length packed number an extra step is required to clear the high-order nibble. I have heard people say that they can tell a difference in Performance Tools on calculation-intensive programs if they "do it wrong", but I've never encountered a demonstrable instance of it affecting user-perceived performance. Maybe the people still running S/38 Model 4's need to be concerned, though... <grin> Note that I'm saying "RPG", the situation is not exactly the same in Cobol, PL/I, Java, C, etc., nor is it the same when doing calculations in SQL or OPNQRYF. My understanding is that AT THE MI LEVEL, there's no intrinsic advantage of one fixed-point representation over the other on the /400, all differences are due to implementation details in the relevant compilers, interpreters, run-times, or whatever. Dave Shaw, General Nutrition, Greenville, SC (just down the road from BMW - Bubba Makes Wheels :) The opinions expressed may not be my employer's unless I'm sufficiently persuasive... +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To unsubscribe from this list send email to MIDRANGE-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.