There is nothing you should or shouldn't, but keep all metrics in mind. Allocate enough GB's on enough volumes. When we formatted our DS8800, we ended up with a number of 3390-12's and I put 2 page datasets on each of them.
How much enough is depends, as you can guess. You could try to find a moment where a large dump caused a mass page outs and see how ASM managed this with your number of paths, controlunits and volumes. For GBs, find the maximum slots allocated in the last 6 or 12 months and make 30 or 50% of your allocated GBs. Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: 24 November, 2014 15:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Page Data Set Sizes and Volume Types If I understand. I can use the larger volumes but I should allocate my Local Page Datasets in MOD3 or MOD9 sizes. So one Mod27 could have for one LPAR 3 MOD9 Size Page or 9 MOD3 size Pages. And I should not mix LPAR1 and LPAR2 Page Datasets on the same MOD27. Is that correct? Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Vernooij, CP (ITOPT1) - KLM > Sent: Monday, November 24, 2014 7:46 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Page Data Set Sizes and Volume Types > > 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:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: 24 November, 2014 15:35 > To: IBM-MAIN@LISTSERV.UA.EDU > 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Cheryl Walker > > Sent: Monday, November 24, 2014 7:30 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > 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 > > <stars...@mindspring.com> > 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 lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
