--------------------------<snip>------------------
I spent the whole day reviewing my understanding about the concept of
virtual storage and found something I cannot figure out. I hope experts here
can give me some hints.
Maybe I should start from GETMAIN. I have used GETMAIN/FREEMAIN for some
time in my programming exercises and one question has remained on my mind
from the first day I knew these services:
After a successful GETMAIN request, I will get a virtual storage area to
use. Is that area supported by either real storage or auxiliary storage as
soon as the GETMAIN completes?
--------------------------<unsnip>---------------------
No, but the various VSM control blocks will be updated to reflect your
ownership of that storage.
----------------------------<snip>---------------------
My guess is: it depends and it's very possible that it is not.
I cannot find anything to support my above guess in manuals and it's purely
from my deduction:
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.'
-----------------------------<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>-------------------------
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.
-------------------------------<unsnip>---------------------
I have NEVER recommended the use of PGRLSE; let RSM decide when a page
should be paged out or stolen, rather than trying to second-guess RSM
and "his" overall view of system real storage usage based on workload
and performance requirements. Yes, you might still be able to access the
storage, but the system load might be such that you are introducing
additional paging load. Let z/OS do it; that's part of what it's
designed for.
--------------------------------<snip>-----------------------------
Suppose my guess is true and now I start to access the area
GETMAINed. During the translation process, the hardware will find the
corresponding entry in the segment table has SEGMENT-INVALID BIT on and it
will signal a SEGMENT-TRANSLATION exception.
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. If not, it will throw the exception to my program and if my program
cannot handle it I will get a 0C4 completion code.
-------------------------------<unsnip>------------------------------
ASM, RSM and VSM all work together to resolve these kinds of issues;
it's called "Teamwork". If you've validly GETMAINed the storage, you'll
never know where the storage resided when you started the access; if you
don't validly own the storage, you'll see the mainframe equivalent of
Microsoft's "Blue Screen of Death". It's been that way all the way back
to OS/360, and, I suspect, most of the other operating systems that were
used before then.
----------------------------------<snip>-------------------------
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.
----------------------------------<unsnip>--------------------------
Quite the contrary. VSM, RSM and ASM work closely together,
communicating through the various control blocks that each uses to
maintain integrity. VSM works according to the program's perceived
needs; ASM and RSM are more concerned about actual usage and its
legality vis-a-vis VSM.
----------------------------------<snip>-----------------------
I know it's not an easy topic and you cannot expect to grasp it in one day.
So forgive me if my understanding is wrong and silly.
----------------------------------<unsnip>-----------------------
It's a very complex relationship and not always easily understood. When
is a SLOT assigned? A FRAME? When is a page "STOLEN"? SWAPPING versus
PAGING? Unless there's a really pressing need to know the intimate
details, most folks treat the whole area as a "Black Box" and assume the
management of real storage and auxilliary storage are accomplished by
"FM" (Freakin' Magic). With advances in performance management, it's
hardly worthwhile to worry about the intimate details and far more
sensible to be concerned about overall storage performance. In the "good
old days" of SRM, we built storage fences, worried about page rates for
certain applications, etc. With Workload Management, it's far more
sensible, in most cases, to be more concerned about overall workloads
and less concerned about the smaller details.
----------------------------------------------------------------------
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
