The bit string approach will probably work very well to solve the problem. I did not mention that the range of possible values for each key will be known, so the possible range is almost always going to be much less than 2 to the 32nd power (4GB). Frequently a limit will also be placed on the number of entries coming in. This will allow for 1 GETMAIN to normally handle the whole table.
Using a bit string is a solution that is simpler and more efficient to implement that what is currently in use. I thank all who supplied thoughts (and code!) to the effort. -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Bill Fairchild Sent: Monday, August 23, 2010 4:12 PM To: [email protected] Subject: Re: Efficient Memory List If the input data is seriously random, then a sparse matrix/array would certainly cut way down on the paging load that might result from my previous suggestion, but at the cost of having to do many more small-length GETMAINs instead of one huge GETMAIN for 1/2 gigabyte of pageable, virtual storage. Bill Fairchild Rocket Software -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Bob Flanders Sent: Monday, August 23, 2010 2:04 PM To: [email protected] Subject: Re: Efficient Memory List If you are simply looking for existence, you could use a bit string, but that would be .5GB of memory if you did a single level. Perhaps you could build a sparse array using each byte as one of a four-level index. On Mon, Aug 23, 2010 at 10:45 AM, Patrick Roehl <[email protected]>wrote: > I’m looking for advice on how to handle a potentially large list of data. > The list is comprised of 4-byte entries... >
