>>After a successful GETMAIN request, I will get a virtual storage area to >Is that area supported by either real storage or auxiliary storage as >soon as the GETMAIN completes?
This is where PIC 10/11 enter the scene: You got your virtual storage but it is not yet associated with any real storage. When your code references any address in that range for the first time, DAT will fail to translate the virtual address and will signal a PIC 10 or 11 (as explained in my previous post). z/OS gets control, validates your request using the VSM control blocks, and if it is valid (i.e. your trying to access GETMAINed storage), a real storage frame will be assigned, your instruction is repeated and will succeed. (No auxiliary storage involved so far.) >1. I once read in the list that 'if you GETMAIN a two large area and as soon >as you begin to access it, it will cause a heavy usage of auxiliary >storage.' Auxiliary storage is only used when the real storage is not large enough to handle all request from running code. The real storage manager (RSM) tries to keep a certain amount of real frames available to respond to requests for a real frame (e.g. to fulfill first time reference requests as described above). If the stock of available frame drops below a certain level, RSM tries to refill it. It will ask the auxiliary storage manager (ASM) to copy the least recently used frames to auxiliary storage slots (i.e. copy the 4KB of data to a page data set), RSM can then put these real storage frames onto the available frame queue. The page table entry has to be updated correspondingly, so that DAT will fail translating any address in those 4KB ranges, should some code reference that storage at a later time. When this happens, a PIC 11 will result but this time z/OS will not assign a new frame but will recognize the data is out on the page data set. ASM is asked to read the data back into a real storage frame and RSM updates the page table, and finally re-drives the failing instruction. So, you statement is true *if* your program is accessing all of that large area (or at least a single byte every 4KB) *and* RSM does not have enough real storage available. RSM and ASM will be busy to replenish the available frame queue to make frames available for your program. In today's systems this is much less likely, since there is much more real storage in the machines than a decade ago. >>-----------------------------<unsnip>------------------------- >>No. ASM and RSM will work together to provide storage on a >>page-by-page basis as you use it, based on the contents of the VSM >>control blocks that describe the storage. If and when you exceed >>the boundaries described by the VSM blocks, you'll get ABENDed. >>-----------------------------<snip>------------------------- To be precise here: You'll get an abend only if you're accessing an address in a 4KB area where nothing has been GETMAINed at all. Even if you GETMAIN only 400 bytes, the system will still allocate 4KB of real storage once you access any byte in the GETMAINed area. If you reference any address outside the 400 byte area but still within the same 4KB range, you will not notice that. Well, your program reads invalid data or overwrites some storage unintentionally and some code may abend but its not the system abending your code because of referencing invalid (i.e. non-GETMAINed) storage). >2. There is an example in an assembler language book which is about the >usage of PGRLSE: Release the area GETMAINed using PGRLSE and then you can >still access it. As might be clear now, PGRLSE asks RSM to disassociate the real frame from the given virtual address. VSM is not involved, so the area is still GETMAINed and the next reference is a "first time" reference, so a new frame will be associated again. >How will the OS handle it? If the area has been GETMAINed, OS will allocate >it in the unit of segment: back it up using either real or auxiliary >storage. Storage management is done in 4KB units (aka pages). A segment is 1MB. >So GETMAIN/FREEMAIN has no direct relation to virtual storage backing up: >when you GETMAIN, it doesn't mean OS will try to back up that area and >FREEMAIN doesn't mean that area will be released like what PGRLSE does. While GETMAIN does not immediately associate real storage, FREEMAIN does disassociate and free any associated real storage and all slots on page data sets if any of the pages have been paged out. -- Peter Hunkeler Credit Suisse ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
