Gil I would advise that at the very least you ask ASG about adding address space usage of shared memory objects into TMON - having done this a few years ago for MXI I know that it is information that is NOT complicated to work out!
The system maintains some ShrMObj stats for an address space in the RAX control block (mapping macro IARRAX) pointed to by the ASCBRSME field. Until support is added in TMON, you could probably knock up a quick and dirty asm program (or REXX exec) to list out memory object usage for all ASIDs). If you want to find out information about specific memory objects (shared and non-shared) for an ASID then things get a bit more complicated - something along the lines of shooting an SRB into the target address space to execute the IARV64 REQUEST=LIST service. Rob Scott Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Gil Peleg Sent: 07 April 2009 12:14 To: [email protected] Subject: Monitoring high virtual shared storage Hi all, We have an LPAR running z/OS R9 with 6Gb of real storage and about 30Gb of paging space (allocated in 3 page data sets on 3 3390-9 volumes). We are using the default HVSHARE value of 510Tb from IEASYSxx and the RSM_HVSHARED health check reports that everything is great. We use an ISV product that uses high virtual shared storage. When things are normal, we use the D VS,HVSHARE command to verify that the amount of megabytes allocated to shared memory objects is static. Lately we have been having situations of auxiliary storage shortage. When looking in RMF III storage frames report, everything looks normal. However, the D VS,HVSHARE command reports about 36Gb of allocated shared (a 9 times increase than its supposed to be, as defined to the product). For this LPAR, as described above, this amount of storage storage is more than enough to cause auxiliary storage shortage. And we had to immediately add more page data sets to relieve the situation. When looking in TMON (which is the monitor we use for MVS) auxiliary storage status screen, we see that RASP is using most of the page space. I trust that the culprit is not really RASP. I assume TMON is merely showing the effect of shared memory objects which are owned by the system. Since our monitors did not provide us with the proof we needed to contact the ISV, we took a dump of RASP in order to use the IPCS RSMDATA command to check what is really going on. Since we do not have much HVSHARE usage, the IPCS command RSMDATA HVSHRDATA was very helpful in quickly identifying the jobs that hold interest in HVSHARE storage. We did a couple of tests (mainly recycling the ISV product) and took more dumps to confirm our theory, and eventually found the problem in the product. During this, I wanted to limit the HVSHARE area to 12Gb, which a lot is more than we need, using HVSHARE= in IEASYSxx. However, as documented, the HVSHARE= value is rounded up to the next 64Gb boundary. So even the minimum value of 64Gb is way more than we need, and doesn't help us protect our system from a runaway job. I ended up changing the parameters of the RSM_HVSHARED health check to issue a high severity critical message whenever the allocated shared area reaches 20% of 64Gb, which is about the 12Gb we needed. The operator would then see the message and know what to do. And finally to my question... Did I miss anything? Is there an easy way to get information about the users of HVSHARED storage? Or is IPCS RSMDATA HVSHRDATA the only way? RMF III reports memory objects count for an address space, but that number apparently does not include shared memory objects. Seems to me that there should be an easier way... Thanks, Gil. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
