> > Would any know the difference between (disabled reference storage) DREF > > e.g. > > subpool 215 and Page fixed storage e.g. subpool 223 > > > > From what I understand DREF means the program is running disable for > > interrupts and thus no pagIing should occur so the doc say use DREF storage > > > > While fixed storage means storage is fixed and the same thing applies no > > paging should occur > > > > > the differences are subtle. With FIXED storage allocations, each (virtual) > page is allocated to a (real) frame at the time of allocation and will > remain so-paired until they are freed.
As long as you are nonswappable, either via the SRM attribute, or by holding the local lock, which prevents RCT Quiesce from proceeding. Otherwise, the real frame backing a fixed page can change. If the storage is actually used then > that's a good deal, however if it is one of those cases where let's say > "maybe something happens and maybe it doesn't.' In that case, the fixed > (real) storage would be wasted in the case where it was never > referenced. That kind of thing happens often enough in real life to have > warranted the creation of DREF. The other reason for DREF was that in ESA/390, it could be paged to expanded storage, but that is defunct now. > So DREF and FIXED are essentially the same > thing (technically a form of xSQA) except for a few important differences. > > (1) None of the DREF pages is backed by a real frame until the page is > referenced. Upon reference the page fault interrupt handler jumps in and > tries to obtain a free frame from the AFQ. If it works the instruction is > redriven and everyone does the happy dance. However at that point there is > always the opportunity to be out of frames so there's even a special abend > code to tell you that it happened. And it's transient, so you could try > again and find it worked just fine. Overall this strategy means a decent > probability of tying up less real storage than you would have done > otherwise by using fixed storage. Win! > > (2) All DREF storage is above the 16MiB line just to coerce a little more > modern sanity on the punters who should never be using below the line > storage anyway. > > (3) and this is where it gets tricky... with fixed storage you can could > count on the address translation staying fixed forever. See above for caveat. > However, with DREF > it is only true most of the time. It is always true for DREF common storage > (technically that is ESQA) however (and this bit is perhaps not widely > know) it is NOT necessarily true for private area DREF (technically known > as ELSQA). When an address space is logically swapped the system knows > nobody is going to be "touching" the LSQA frames while the address space it > toes up, so the system may play a little fast and loose. A backed LSQA page > (DREF or not) will always come back in with a fixed frame backing it, but > it might not be the one it logically went out with. The operating system reserves the right to exchange the frame backing any DREF page (LSQA or SQA) at any time. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
