|
Hi Al, actually I have this RIDICULOUS problem: I'm working in a Bank and not in a barber shop, and I've been asked to give a technical answer to this question (and to decide). Maybe if I respond that this is a RIDICULOUS question, in the future I will probably have to ask the barber shop to give me a job. At present a certain field is 7.0 - and it must be enlarged because now - after 6 (six) years - it is going to become full. How much we should enlarge it? With 8.0 we can add more 90,000,000 items and it is enough for the next 50 years but it seems that there is an overhead (this field is part of a key in other db for a total of 800,000,000 rcds). With 9.0 there is no overhead and no waste of space but we have hundreds of panels (especially subfile lines) and reports where one more byte cannot fit. I ran a simple test (on a 830) adding 100,000,000 of records with 8.0 vs. 9.0 on a empty table with 2 of these fields (without keys or logicals) and the overhead is 0 (ZERO) but +12% compared to 7.0 (however still nothing if compared to the eternity) These ase the times: 7.0 needs 66secs of CPU while 8.0 needs 74s and 9.0 always needs 74s. I repeated the test with 2 logicals (2 keys - K1+K2 and K2+K1 on the same 7/8/9.0 pf); adding only 10,000,000 records gave these results: 7.0 needs 403secs of CPU while 8.0 needs 401secs and 9.0 needs 402secs, in other words 7,8 or 9 makes no difference. Because I remember that at s/38 times the semi-byte (oh sorry the NIBBLE) did really matter, I wanted to get some other opinions. I posted the same into MI400 newsgroup and I've been pleased to find there a very interesting answer to this problem. Take a look, Al. -- Giuseppe ----- Original Message ----- From: "Al Barsa" <barsa@barsaconsulting.com> To: <midrange-l@midrange.com> Sent: Friday, November 29, 2002 4:32 AM Subject: Re: Odd/Even packed numbers. > > Happy Thanksgiving, you all. > > I think that in this day and age, with the CPU power that we take/squander > for granted, this entire discussion is ridiculous. In the early /38 days, > we set counters in binary, because it made a difference. Today, I think > that the right thing is to set your data as you need it (from this > perspective), and not waste time thinking about system efficiencies. The > brute power of the systems tat we use today far overweighs setting the > length or type of fields. > > Al > > Al Barsa, Jr. > Barsa Consulting Group, LLC > > 400>390 > > 914-251-1234 > 914-251-9406 fax > > http://www.barsaconsulting.com > http://www.taatool.com > > > > > > > Glenn Ericson > <Glenn-Ericson@att To: midrange-l@midrange.com, <midrange-l@midrange.com> > .net> cc: > Sent by: Subject: Re: Odd/Even packed numbers. > midrange-l-admin@m > idrange.com > > > 11/28/2002 09:58 > PM > Please respond to > midrange-l > > > > > > > -- > [ Picked text/plain from multipart/alternative ] > At 09:09 PM 11/28/2002 -0500, Booth Martin wrote: > > >(zoned & signed goes back to the days of punch cards. A column punch was > >zoned" if the top three rows had a punch. The top three rows were the zone > >rows - row 1 was A-J, row 2 was K-S, and a row 3 punch was the rest of the > >characterset. If I am a bit off please forgive me - that was 30+ years > >ago.) Row 1 A-I (Plus values) Row 2 J-R (negative > >values) Row 3 Q-Z ( I don't recall) > > > >Leif, I believe your comment that signed fields take much longer, but 10 > >times longer? oh gosh... That is huge. Did you save the metrics? > > > > > >--------------------------------------------------------- > >Booth Martin http://www.MartinVT.com > >Booth@MartinVT.com > >--------------------------------------------------------- > > > >-------Original Message------- > > > >From: midrange-l@midrange.com > >Date: Thursday, November 28, 2002 08:20:03 PM > >To: midrange-l@midrange.com > >Subject: Re: Odd/Even packed numbers. > > > >From: Leif Svalgaard <leif@leif.org> > > > > > > From: Booth Martin > > > > > > > Leif, would you try one more thing since you are already there, > > > please? > > > > > > > What happens if you define it as 14S 0 and 15S 0? Does packed > vs. > > > >yes, signed (aka zoned) is 10 times slower than packed. > >_______________________________________________ > >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > list > >To post a message email: MIDRANGE-L@midrange.com > >To subscribe, unsubscribe, or change list options, > >visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > >or email: MIDRANGE-L-request@midrange.com > >Before posting, please take a moment to review the archives > >at http://archive.midrange.com/midrange-l. > -- > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > > > > > > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > >
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.