Hi Lizette,

Did you take a look at that Techdoc? It shows you how to calculate the number 
of slots.

Regarding using larger rather than smaller data sets, it depends on what 
happens to your online performance during an SVC dump. In most installations, 
the only paging occurs during an SVC dump. If you can monitor performance 
during that time (e.g. online response time) and amount of paging, you might be 
able to determine whether a change in performance will affect you.

Best regards,
Cheryl

======================
Cheryl Watson
Watson & Walker, Inc.
www.watsonwalker.com
cell & text: 941-266-6609
======================

On Nov 24, 2014, at 9:35 AM, Lizette Koehler <[email protected]> wrote:

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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to