|
Scott, I myself, was only saying that dimming an array limits you to the size of dim. But lets say that you don't use all the elements in the array. Now your program is taking up space to account for those empty arrays, where with a temp file, it'll grow with you.
And, as I've already replied to you, the file won't be any better. In the extreme case, my array with have 9999 elements, since that's how big SFLSIZ can be.
D Zip s 9P 0 dim(9999)Each entry is 5 bytes, theres 9999 elements. So that's 49995 bytes of space.
On the other hand, if you coded the following file: A UNIQUE A R ZIPREC A ZIPCODE 9P 0 A K ZIPCODE Then just create it as an empty file: crtpf qtemp/ziptest srcfile(mylib/qddssrc) When I check the size of that file with DSPOBJD, here's what it shows: Opt Object Type Attribute Size ZIPTEST *FILE PF 49152So, without ANY records in it, it's already about the same size as the array. Sure, you're saving 800ish bytes, but those 800 bytes are completely insignificant (as is 50k, by the way, on todays computers)
Now, if he only needed 9800 elements in his array, then the arrray would actually use less memory than an EMPTY file.
The iSeries single-level store will cause the parts of the array that aren't getting any use to be shuffled out of physical memory and onto disk if the system is short on memory, so the difference between a disk object and a memory object aren't important, either.
Furthermore, where do you think subfiles are stored? In magic elfenland? No, they're stored in memory. If each subfile record takes up, say, 60 bytes of memory, then setting SFLSIZ(9999) means that you're using 600k of memory. Yet, you don't seem too worried about setting SFLSIZ too high for the number of loaded records, yet you're worried about the array. It doesn't make sense.
I don't think any of us tried to offend you.
I wasn't offended by your post, I just didn't agree with you. Alan Shore's post offended me, however.
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.