Hi John, If your below the line private area decreased it I will step out on a limb and say no one is monitoring and managing it. We have been able to grow PVT from a standard 9M to 10M and EPVT as well in the last few years. IBM is doing good work in the area of Virtual Storage Constraint Relief (VSCR). The MVS/SCP Project at SHARE engages with IBM on this topic. A very recent presentation from SHARE in Orlando on IBM's current VSCR accomplishments and plans is here
http://ew.share.org/client_files/callpapers/attach/SHARE_in_Orlando/S281 8ET101935.pdf 2818 - Common Storage Virtual Storage Constraint Relief (VSCR) Program: MVS Project: MVS SCP Speakers: Elpida Tzortzatos (IBM Corporation) In this session, the speaker will describe IBM's edict for brand-wide virtual storage constraint relief (VSCR), offering insights into IBM's strategies for evolving virtual storage management for improved handling of current and future workloads. She will discuss the trade offs you may have to make, between selecting the sizes of the 31-bit common areas and extended private, while configuring and tuning your z/OS system for optimal performance and reliability. The speaker will then cover your options for moving control blocks out of the 31-bit common area. With this common storage VSCR support, you can maintain more of the premium storage below the bar for private address space utilization. This is a new session for Orlando. ---------------------------------- z/OS 1.9 Rocks! I got back 17M of ESQA from the CDT enhancement described in Elpida's presentation. I got back a nice little chunk of SQA relocating the LCCA/PCCA > 16M also discussed in the presentation. A common cause of what you describe is that someone installed a ServerPac and dropped in a large library into your LPALSTxx that does not need to be LPA. ISP.SISPLPA for instance can be in link list and has some big modules that are still RM 24. Health Checker for z/OS can both monitor to insure that you know immediately if your PVT/EPVT area changes more than you expect or falls below some size threshold you specify. The check you want to look at first is CHECK(IBMVSM,VSM_PVT). This gives you some useful data like a virtual storage map and shows you how it compares to the previous IPL. CHECK(IBMVSM,VSM_PVT_LIMIT) START TIME: 07/09/2008 05:36:01.470981 CHECK DATE: 20040405 CHECK SEVERITY: LOW CHECK PARM: PVT(9M),EPVT(1200M) The current size of PVT is 10M, and satisfies the installation specified minimum of 9M for this area. The current size of EPVT is 1485M, and satisfies the installation specified minimum of 1200M for this area. VSM_PVT_LIMIT Virtual Storage Configuration Report Current IPL TOD: Compare IPL TOD: 07/09/2008 05:23:10.7588 07/02/2008 05:33:11.8391 ------------------------ ------------------------ DATE 07/09/2008 07/02/2008 TIME 05:23:10 05:33:11 LOADxx EB EB IEANUC0x 1 1 CSA() 8B (3M,400M) 8B (3M,400M) SQA() 00 (512K,64M) 00 (512K,64M) FIX() n/a n/a LPA() 00 8B 00 8B MLPA() n/a n/a MLPA() n/a n/a Storage Current Compare Location Change Size size Start End PVT 0000000000 0000A00000 0000A00000 0000000000 0000A00000 (10M) (10M) CSA 0000000000 00003C4000 00003C4000 0000A00000 0000DC4000 (3856K) (3856K) MLPA n/a 0000000000 n/a 0000000000 0000000000 (0) FLPA n/a 0000000000 n/a 0000000000 0000000000 (0) PLPA 0000000000 000010EFFF 000010EFFF 0000DC4000 0000ED2FFF (1084K) (1084K) SQA 0000000000 0000103000 0000103000 0000ED3000 0000FD6000 (1036K) (1036K) R/W NUC 0000000000 000000DF5F 000000DF5F 0000FD6000 0000FE3F5F (56K) (56K) R/O NUC 0000000000 000001BFFF 000001BFFF 0000FE4000 0000FFFFFF (112K) (112K) R/O ENUC 0000000000 00009200DF 00009200DF 0001000000 00019200DF (9345K) (9345K) R/W ENUC 0000000000 000007CFFF 000007CFFF 0001921000 000199DFFF (500K) (500K) ESQA 0000000000 0005AB3000 0005AB3000 000199E000 0007451000 (92876K) (92876K) EPLPA 0000000000 0002E75FFF 0002E75FFF 0007451000 000A2C6FFF (47576K) (47576K) EFLPA n/a 0000000000 n/a 0000000000 0000000000 (0) EMLPA n/a 0000000000 n/a 0000000000 0000000000 (0) ECSA 0000000000 0019039000 0019039000 000A2C7000 0023300000 (400M) (400M) EPVT 0000000000 005CD00000 005CD00000 0023300000 0080000000 (1485M) (1485M) No conversion of ECSA has taken place. No conversion of CSA has taken place. END TIME: 07/09/2008 05:36:01.480909 STATUS: SUCCESSFUL ------------------------------- You are going to need data from RMF or an SVC dump from before and after and do a little detective work but you can find out what changed and why. IBM from what I can see is committed to delivery of VSCR in every release of z/OS and Poughkeepsie is working with the subsystems which is where much of the needed future relief is coming from. DB2, IMS, and Communications Server for example all have big footprints in EPVT or COMMON which figure into VSCR challenges. Third party vendors have a part to play too and again you need to map out what needs attention and open support tickets, enhancement requests, whatever is needed to get the ISV's moving on exploiting XA, ESA, OS/390, z/OS features. You need to map out what is using your common storage and know when it changes. Good luck! If you find some details on what happened at your site and need help deciphering them lots of folks here will help you explore. IBM gets good marks for what they have done and what they have stated as direction. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Mattson Sent: Wednesday, July 09, 2008 5:49 PM To: [email protected] Subject: IBM using more below the line storage. IBM appears to be expanding use of storage below the 16M line, rather than converting their own code to 31-bit addressability. Here is the reply I received when I ETR asked CICS why I could no longer get a certain DSALIM value in TS22 after going to zos 1.08. "There is Common Storage shared by all address spaces, and not considered part of the private storage available for address space (task) use. In OS/390 2.10 the amount of Common Storage needed by the system was smaller than is required by z/os 1.8, which has much more function. When Common Storage increases, the amount of private storage decreases. My guess, based on my years of experience is that in your 2.10 system the amount of private storage available was 10M or possibly 11M. It must be on a meg boundry. In z/os 1.8 the amount of storage available for CICS , or any other address space has shrunk to 9M based on the increase in Common Storage." It appears to me that IBM is assuming that the below the line storage is now free and available for their use, and rather than going to 31-bit addressing themselves, they are expanding use of 24-bit. Interesting. Looks like a bit of "do as I say, not as I do." ---------------------------------------------------------------------- ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. ---------------------------------------------------------------------- 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
