Rob, thank you! I was about to write a quick REXX when I remembered Mark Zelden published here a REXX that does just that a couple of years ago! I ran Mark's REXX with the 'ALL' parameter and indeed got a list of all address spaces and their use of shared memory objects.
Thanks Mark! I wonder why doesn't RMF report this if it is so simple. However, I think there is a small misleading issue with looking at shared memory objects in a list like that. When investigating RAX for all address spaces, field RAXLVSHRNMOMB holds how many shared memory bytes/objects are allocated for each address space. Suppose you see one address space with 4GB allocated and a second address space with 4GB allocated, their total amount of HVSHARED storage can be anywhere between 4GB and 8GB, if they share none of it, some of it or all of it and so on. So it is important to also check the total amount of allocated HVSHARED storage in the system. Thank, Gil. On 4/7/09, Rob Scott <rsc...@rocketsoftware.com> wrote: > > 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: rsc...@rs.com > Web: www.rocketsoftware.com > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Gil Peleg > Sent: 07 April 2009 12:14 > To: IBM-MAIN@bama.ua.edu > 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
