Monitoring Real Storage Utilization

2012-04-11 Thread Mark Jacobs
We had a discussion yesterday regarding our obsolete IEFUSI exit and how 
it should be modernized to even know about the virtual storage region 
above the 2GB line.


One of the concerns was that since IEFUSI has no practicable effect on 
authorized programs I was asked to come up with some ways to better 
manage our environment just in case some user decides to allocate and 
start using massive amounts of above the bar storage.


My question to the mailing list is do you manage towards this scenario 
and if so, how?


--
Mark Jacobs
Time Customer Service
Tampa, FL


Learn from yesterday, live for today, hope for tomorrow.
The important thing is to not stop questioning.

- Albert Einstein

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: Monitoring Real Storage Utilization

2012-04-11 Thread Mark Zelden
On Wed, 11 Apr 2012 10:24:10 -0400, Mark Jacobs mark.jac...@custserv.com 
wrote:

We had a discussion yesterday regarding our obsolete IEFUSI exit and how
it should be modernized to even know about the virtual storage region
above the 2GB line.

One of the concerns was that since IEFUSI has no practicable effect on
authorized programs I was asked to come up with some ways to better
manage our environment just in case some user decides to allocate and
start using massive amounts of above the bar storage.

My question to the mailing list is do you manage towards this scenario
and if so, how?


I'm not really worried about STCs and authorized users.  Nothing I can do 
about them except allocate 2000 page volumes (just kidding).   

The comments in my IEFUSI exit from 2005 still hold true and explain
what I am doing.  So far, it has worked out fine.   My client does have
64-bit usage and also large pages running 64-bit WebSphere.  
Basically, I just want to keep someone from playing with 64-bit
from destroying the system. 

My SMFPRMxx MEMLIMIT is to 10G.   

9/14/2005   M ZELDEN FORCE MEMLIMIT OF 5G FOR ANY JCL   
 SPECIFICATION OF ANYTHING OVER 5G BUT  
 ALLOW MEMLIMIT NOLIMIT (16383PB) IF
 REGION=0M. IF NO JCL SPECIFICATION IS  
 USED (OTHER THAN REGION=0M), THEN TAKE 
 THE MEMLIMIT DFLT FROM SMF (SMFPRMXX). 
 THIS WILL ALLOW SYSTEMS THAT NEED A
 HIGHER MEMLIMIT TO HAVE SMFPRMXX BE
 THE CONTROLLING FACTOR - AS LONG AS
 MEMLIMIT IS NOT SPECIFIED IN THE JCL.  
 SINCE ONLY STCS CAN USE REGION=0M, ONLY
 STCS WITH REGION=0M CAN GET MORE THAN  
 THE FORCED MEMLIMIT OR THE SMF DFLT.   

By having SMFPRMxx be the controlling factor, I could easily raise it
if a problem came up with no JCL changes etc.   So far, I've haven't
needed to do that. Keep in mind I updated this exit for the brave
new world in 2005.   I'm slightly surprised it's been 7 years and
I haven't needed to modify it except for a change in 2007 related to 
OA14391 which affected z/OS 1.7  z/OS 1.8 and above. That
APAR kept STCs with REGION=0M from  getting MEMLIMIT=NOLIMIT
so I updated the exit to force MEMLIMIT=NOLIMIT for STCs with
REGION=0M (which was the behavior prior to OA14391).

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN