Hi Lizette, I think with swapping 20 small ones for 2 large ones, you are going to hit another paging problem: performance. When ASM needs to do a (mass) page out, you can help ASM by providing as many parallel paths as possible, so 20 will page out faster than 2.
Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lizette Koehler Sent: 24 November, 2014 15:35 To: [email protected] Subject: Re: Page Data Set Sizes and Volume Types Thanks to all with help on this topic. Cheryl. Thanks very much. I was hoping to find a formula to determine the number of slots, but I think MXG can help with that. I also was trying to determine if I can swap out 20 Mod3s for 2 Mod27s and not have to create little datasets on the Mod54. I have a sandbox and I will be attempting to arrange some validations of my assumptions. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Cheryl Walker > Sent: Monday, November 24, 2014 7:30 AM > To: [email protected] > Subject: Re: Page Data Set Sizes and Volume Types > > Hi Lizette, > > Here's an item from our latest Tuning Letter (2014 No. 3). This might > help a little. > > Page Data Set Usage > > Tom Kelman of Xerox Business Services, LLC asked: "I have heard that > the process where the paging subsystem attempts to block pages > together to send them > to the paging data sets went away around z/OS 1.7 or 1.8. Is that > true, and if so is it > still necessary to keep the percent of local page space used down to 30%?" > > To answer the first part of his question, z/OS 2.1 still supports > block paging. The > 30% number is to make the contiguous slot algorithm most efficient. Contiguous > slots are used even if block paging is not in play. > > To answer the second part of his question, yes, the recommendation is still 30%, > although it could be more or less. It's relatively easy to calculate > the best value for > your installation. Here is an excellent paper on how to do the calculation: Techdoc > TD104728 (z/OS Availability: Managing SVC Dumps to Mitigate Exhausting > the Paging Subsystem). > > It all has to do with SVC dumps. SRM will identify a storage shortage > if you use > more than 70% of the page data sets. While taking an SVC dump, you > don't want to > take more than 70% of the page slots. Therefore, IBM recommends that > you keep > the total auxiliary dump space and paging space to less than 60% of > the slots. It > really depends on how much storage you have, how big your SVC dumps > are, and > how many concurrent dumps you are likely to experience. > > We asked Kathy Walsh, Distinguished Engineer at IBM's Washington > Systems Center, whether the availability of Storage Class Memory (SCM) > has any effect on > this recommendation. Her reply: > > If you have SCM on the LPAR then assuming its service time is faster > it will get > most of the pages, except for VIO which is not written to SCM. So as > far as I am > concerned the recommendation has not changed. For locals we still > don't want them > more than 30% used. Of course with SCM it will be hard to get to 30% unless there > is a lot of VIO activity. With SCM there has been no change in the Aux DASD IO > support hence nothing has changed which would merit a change in > recommendation. > > And while we're mentioning SCM, we want to remind you of our article > in Tuning > Letter 2013 No 3 (IEASYSxx Update): > > [The IEASYSxx keyword] PAGESCM indicates whether and how much storage- > class memory (SCM - also known as FlashExpress or zFlash) to allow for paging > data sets. We described zFlash, which is a priced (about $125K per 1.4 > TB in the > U.S.) hardware feature on a zEC12, in our Tuning Letter 2013 No. 1, > pages 4-7. Our > recommendation for zFlash was: > > RECOMMENDATION: If SVC dumps are hurting performance, if the start of > day brings serious performance problems, or if you want to provide > performance enhancements in Java, DB2, or IMS, you should consider > Flash Express for your > zEC12. It has great potential, and I haven't heard of any downsides. > > Best regards, > Cheryl > > ====================== > Cheryl Watson > Watson & Walker, Inc. > www.watsonwalker.com > cell & text: 941-266-6609 > ====================== > > > > > > On Nov 19, 2014, at 10:41 AM, Lizette Koehler > <[email protected]> wrote: > > I have been reviewing various documents on how to size the Page Data Sets. > > I was wondering if there are any guidelines on what can be used today. This should > be kept to z/OS V1.12, 1.13 and 2.1 which I think will be the more dominant > operating systems in use right now. > > I know that the number of Slots will drive what I allocate. So I am looking for the > following information. I have not done this in many years so I am > very rusty. > > 1) How to calculate the number of slots per page datasets > a) I need to base this on 3390 Mod 3/9/27/54 > 2) What do I need to stay away from when determining where the page datasets go > a) For example, if I use a Mod27 and I need to place multiple page datasets > on the volume > Should they all be for the same LPAR if in a PLEX > Should they all be for unique LPARs if in a Plex > 3) What are the maximum values I can create a page dataset? > Can I use a whole Mod3/9/27/54 for ONE page dataset? > > I have looked through Hot Flashes (Cheryl Watson) and MXG sourclib. I have run > through some of the Redbooks and share presentations. > > I am now looking for real life thoughts. I also thought this would be > a good topic for > the archives. > > Thanks for any information > > Lizette > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
