On 04/12/2017 10:16 AM, Paul Gilmartin wrote:
> On Wed, 12 Apr 2017 09:50:44 -0500, Joel C. Ewing wrote:
>> GETMAIN returns a success indication based purely on whether virtual
>> storage is available to the address space within the REGION size
>> constrains.
>>
> Does it not check for available paging space? Does this imply that your
> job and my job can each do a GETMAIN for storage which in the aggregate
> exceeds the available paging space and both will succeed?
>
>> It is the SysProg's non-trivial job to configure the LPAR real memory
>> and configure z/OS to adequately constrain max REGION sizes, the number
>> of address spaces and size the paging subsystem so that page thrashing
>> doesn't occur and critical page slot thresholds in the paging subsystem
>> aren't exceeded. There are tools, configuration parameters, and exits
>> that make that possible.
>>
> Then if you job touches all its pages then my job attempts to touch all
> its pages, may I experience a failure because there are no slots to page
> something out?
>
> -- gil
To reach a scenario where two jobs could potentially interfere with each
other in that way would seemingly indicate a serious failure in
configuration if two ill-behaved jobs with such large REGION constraints
were allowed to run concurrently without an adequately sized page data
set pool to support them. And the implication that each would also
impose a serious impact on real storage by them self further suggests
that such jobs should be constrained to a job class that disallows two
running concurrently.
Any job or subsystem deliberately designed to use large amounts of
virtual memory above the bar or a significant percentage of the real
memory assigned to an LPAR should be under the control of people smart
enough to know they need to coordinate their plans to the SysProgs that
support that LPAR so that things can be sized appropriately and new page
datasets can be created and added. If one is in an environment where
you can't trust that communication to take place, then the SysProgs need
to add REGION size enforcement so that people are forced to communicate
before their jobs can get authority to successfully allocate enough
virtual storage to become a problem.
I don't think your job would fail immediately, just wait. I believe
there would be all sorts of nasty console messages which start at a
fairly low level of page slots in use (30%?) and maybe even include
indications if one job consumes an unreasonable percentage of aux paging
pool space, so there is potentially some advance warning. If the
operator were able to dynamically add a sufficient number of new page
data sets, or cancel one of the jobs causing the problem, things should
be able to proceed. If the page auxiliary storage becomes 100% full and
there is no way to add more space in time or determine the offending
address spaces and cancel them, I suspect the whole system, not just
your job, is toast.
In the environment I worked, the only really big users of virtual
storage at the time were CICS and DB2, and the people supporting those
subsystems understood quite well the need to communicate to z/OS support
any significant plans to change their virtual/real storage usage. If
other application areas are planning to use 64-bit virtual storage, they
also need to be properly educated to communicate their plans and
understand the consequences of failing to do so.
Joel C. Ewing
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
