On Mon, 2010-08-23 at 17:15 -0400, Bob Flanders wrote: > Hmm. How about something like this: > > Allocate at bit string that will have an lower and upper limit. Whenever a > new value comes in that is outside the range, reallocate the and move > existing string into the new space and free the old.
This could really result in poor execution. It could lead to a lot of STORAGE OBTAIN/RELEASE and moves. And the moves would likely cause bad paging because it would be necessary to move even "unused" pages. That is, pages which are all x'00'. > > In this case, the variable will be how much memory will be used that could > change drastically based on the key values. If the spread is small, the > memory allocated will also be small. > > It's been a long time since I've done mainframe programming, but isn't there > a way to say "Only allocate pages that I actually use" and let the virtual > storage manager allocate a real page upon write access. In the very worst > case, you would have .5GB allocated. This is how it is done already. When you do a STORAGE OBTAIN, and use the BNDRY=PAGE, then all that is allocated are the page table entries. And they are marked in such a way that RSM knows that they have never been referenced. Then, when you first reference a byte within such a page, RSM knows to allocate a real page frame and zero it. No paging involved at this point. I don't know if AUX storage is reserved at STORAGE OBTAIN time, or later. I haven't found that in the books that I've looked at. But even if reserved, it is not written to until a page out actually occurs. > > Alternatively, do a single-level index of 4k pages -- .5MB, and GETMAIN the > pages as needed. max memory needed = .5GB + .5MB for index. > > My last real mainframe programming was in the early 80's, so I don't know if > .5GB is a lot these days. Back then... Fuggedaboutit. :-) I'd allocate "above the bar". And not worry about it. I'd estimate the .5Gb is maybe somewhat less than 1/2 of what could normally be allocated "above the line". Total "above the line" is addresses 0x01000000 to 0x7FFFFFFF. Of course there is all that common extended area used up by the system. And "high private" as well. > > Old and rusty... > Bob >
