|
RE: RE: Numerics PACKED, ODD format -- Always recommended? Booth, Walden Its not the wasted bit thats the problem on even packed data, its the fact that after an arthimatic operation the machine does an integrity check on the unused high order bit to ensure it was not violated by the operation. It's the integrity checking that causes the performance hit. "I believe" But (like on an 170 with a CPW of 319) we have much more important things to worry about than the performance of that now. (and/or date type performance !! I told yous guys a year ago they would make date types perform better.) Now about those 100+ I/O's per enter key......... John Carr EdgeTech ------------------ Booth, In packed data the 9th character is free from a DASD point of view. That is one of the reasons for the argument of going to the odd lengths. Think of it this way: 8,0 field with value 12345678 is stored as x'012345678F' on the database (5 bytes) 9,0 field with value 123456789 is stored as x'123456789F' on the database (still 5 bytes) The argument is: since you need the last nibble to store the sign 'F' and since all data must be byte aligned (at a minimum) you are simple wasting the high order nibble going with a even length field. -Walden -----Original Message----- From: mcsnet!midrange.com!midrange-l-owner@Mcs.Net [mailto:mcsnet!midrange.com!midrange-l-owner@Mcs.Net]On Behalf Of Booth Martin Sent: Thursday, March 12, 1998 12:36 AM To: MIDRANGE-L@midrange.com Subject: Re: Numerics PACKED, ODD format -- Always recommended? 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. +--- | 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 +--- uucp +--- | 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 +--- +--- | 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.