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