|
> Haven't been following this thread that much, but the recent posts > have caught my attention. Sorry if this has already been stated. > There is something that I just heard about called a User Index that > supposedly holds up to a Terabyte of data. The IBM person said it > operated similar to a User space except you could index the entries. > You might want to check that out even though you would be in some > serious do-do if you ever got something that big;-) Oh yes, you are right, Aaron! http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm and scroll down to "Index size option" (at about 75% of the vertical scrollbar). A value of "1" means a maximum size of 1 terabyte. A value of "0" means a maximum size of 4 gigabytes. And for John's compatibility problems: prior to V2R2M0: maximum size 1 gigabyte, max. key length 120 bytes V2R2M0 - V5R1M0: maximum size 4 gigabytes, max. key length 2,000 bytes V5R2M0: 1 terabyte. But the drawback is the entry length. That can only be 2,000 bytes. A 32K chunk would make up 17 records, with unused 768 bytes in the 17th record. To take advantage of the size of 4 gigabytes, we need 4,294,967,296 unique keys, 17 for every 32K chunk. That would be a 4 byte hex key, the rest would be the "data". 1996 bytes * 16 records + 832 = 32,768 bytes. I really don't know which approach is the more cumbersome, that one or ending up with max. 256 user spaces. :-) John, the whole thing of writing the "result set" that you receive from the SQL server to *disk* is necessary? Isn't that a piece of middleware that should pass that on to a processing program? Wouldn't be allocating a decent amount of memory and reusing that as a sort of communications buffer better? Or shall that be a sort of cache for faster answers on repeating calls demanding the same data? -- Mit freundlichen Grüssen / best regards Anton Gombkötö Organisation und Projektleitung Avenum Technologie GmbH Wien - Salzburg - Stuttgart http://www.avenum.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.