We are implementing a DS8800 with Hyperpav and like to give ASM the best
paging configuration. However, the recommendations in Initialization and
Tunig Guide are outdated, speaking of 3380 devices, Seek penalties,
dedicated devices, channels and control units and the Suspend/Resume
logic. Occasionally PAV is mentioned, as well as z/OS 1.8, where the
Suspend/Resume is no longer used, without explaining the consequences.

There is no good recommendation how to set up a good paging
configuration on a  modern DS8800 device, nor does it explain the
consequences of Hyperpav and WLMPAV set to NO in relation with OA32453
where ASM is still building a " I/O infrastructure" that utilizes
Hyperpav. Nowhere is explained what this infrastructure looks like. From
conversations with Greg Dyke when he was the expert in that area, I know
that in the WLM managed PAV environment ASM reserved 2 access paths to
each page dataset, resulting in 2n-1 aliases dedicated to a paging
volume. Is this still done so in the Hyperpav situation?

Our production Sysplex has 10 LCUs on the DS8800 and is connected with 8
Ficon channels. Hyperpav can select alias devices within an LCU, not
over LCUs.

I can allocate 10 page volumes, 1 per LCU, with 1 local page dataset per
volume. This would give ASM 20 access paths to its paging configuration.

I can allocate 2 page datasets on each volume, giving ASM 40 access
paths to its paging configuration. Or 60 or 80.

However, this all has to be handled by the 8 Ficon channels.

How do I determine the optimum? I know page-in is hardly a performance
factor these days, but page-out bursts from large dumps can impact
performance, if not handled rapidly.

Are there any ASM experts willing to elaborate on this? And possibly
update the Initialization and Tuning Guide for modern Dasd devices?

Thanks,

Kees.

********************************************************
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

As far as I can determine this recommendation hasn't changed much since ESA/390.

I use ( REAL STOR FRAMES *3 ) for total page slots. This is per LPAR.

Allocate total local paging space as  (total page slots/0.35) to facilitate the block paging slot allocation algorithm.
I recommend a max of 100 pps/device. (personally, I dedicate the device to paging).

Spread over as many devices/paths as practical.

The "optimum" VSTOR config is 2:1 virtual to real. I personally use 3:1 (RSTOR *3). This is a trade off between page rate and devices allocated.

I.e. the sum of all working sets for the LPAR(in frames)  is up to 3 times the number of real storage frames available.
This paging rate goes up *VERY VERY* quickly after 3:1 IIRC, this is a SQUARE function.
For a given original page rate:
To go from 2:1 virtual/real to 3:1 virtual/real generates the ratio (9/4 * original page rate) 2.25 times
To go from 2:1 virtual/real to 4:1 virtual/real generates the ratio (16/4 * original page rate) 4 times the original page rate.

Additional comments interspersed below.
HTH,

<snip>
We are implementing a DS8800 with Hyperpav and like to give ASM the best paging configuration. However, the recommendations in Initialization and Tunig Guide are outdated, speaking of 3380 devices, Seek penalties, dedicated devices, channels and control units and the Suspend/Resume logic. Occasionally PAV is mentioned, as well as z/OS 1.8, where the Suspend/Resume is no longer used, without explaining the consequences.

There is no good recommendation how to set up a good paging configuration on a  modern DS8800 device, nor does it explain the consequences of Hyperpav and WLMPAV set to NO in relation with OA32453 where ASM is still building a " I/O infrastructure" that utilizes Hyperpav. Nowhere is explained what this infrastructure looks like. From conversations with Greg Dyke when he was the expert in that area, I know that in the WLM managed PAV environment ASM reserved 2 access paths to each page dataset, resulting in 2n-1 aliases dedicated to a paging volume.

 Is this still done so in the Hyperpav situation?

 >>>>>As far as I know, this is still the case

Our production Sysplex has 10 LCUs on the DS8800 and is connected with 8 Ficon channels. Hyperpav can select alias devices within an LCU, not over LCUs.

I can allocate 10 page volumes, 1 per LCU, with 1 local page dataset per volume. This would give ASM 20 access paths to its paging configuration.

I can allocate 2 page datasets on each volume, giving ASM 40 access paths to its paging configuration. Or 60 or 80.

However, this all has to be handled by the 8 Ficon channels.

How do I determine the optimum?

Then compare your values with the 25% to 33% recommended peak utilization
for the contiguous
slot allocation algorithm to find free slots.

Barry Merrill

Herbert W. Barry Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229-5112
214 351 1966 tel
214 350 3694 fax
http://www.mxg.com
ba...@mxg.com

MXG Support:   supp...@mxg.com
MXG Admin:      ad...@mxg.com

Standard Answers: http://www.mxg.com/administration
What's Supported:   http://www.mxg.com/changes

Thanks, the sizing is not the problem. I have historical peak
utilizations and size the new page configurations to be filled for about
15% with these values.

I am more unsure about the number of page datasets which relates
directly to the amount of parallel I/O 's ASM is able to do, as I
calculated below. What is helpful for performance and what is
unrealistic: 10, 20, 40, 80?

Kees.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

From:   "Staller, Allan" <Allan.Stal...@KBMG.COM>
To:     IBM-M...@listserv.ua.edu,
Date:   11/09/2012 01:46 PM
Subject:        Re: Paging configuration recommandation on modern Dasd.
Sent by:        IBM Mainframe Discussion List <IBM-M...@listserv.ua.edu>

Hopefully Jim Mulder or Pete Relson can jump in if they disagree.

As far as I can determine this recommendation hasn't changed much since
ESA/390.

I use ( REAL STOR FRAMES *3 ) for total page slots. This is per LPAR.

Allocate total local paging space as  (total page slots/0.35) to
facilitate the block paging slot allocation algorithm.
I recommend a max of 100 pps/device. (personally, I dedicate the device to
paging).

Spread over as many devices/paths as practical.

The "optimum" VSTOR config is 2:1 virtual to real. I personally use 3:1
(RSTOR *3). This is a trade off between page rate and devices allocated.

I.e. the sum of all working sets for the LPAR(in frames)  is up to 3 times
the number of real storage frames available.
This paging rate goes up *VERY VERY* quickly after 3:1 IIRC, this is a
SQUARE function.
For a given original page rate:
To go from 2:1 virtual/real to 3:1 virtual/real generates the ratio (9/4 *
original page rate) 2.25 times
To go from 2:1 virtual/real to 4:1 virtual/real generates the ratio (16/4
* original page rate) 4 times the original page rate.

Additional comments interspersed below.
HTH,

<snip>
We are implementing a DS8800 with Hyperpav and like to give ASM the best
paging configuration. However, the recommendations in Initialization and
Tunig Guide are outdated, speaking of 3380 devices, Seek penalties,
dedicated devices, channels and control units and the Suspend/Resume
logic. Occasionally PAV is mentioned, as well as z/OS 1.8, where the
Suspend/Resume is no longer used, without explaining the consequences.

There is no good recommendation how to set up a good paging configuration
on a  modern DS8800 device, nor does it explain the consequences of
Hyperpav and WLMPAV set to NO in relation with OA32453 where ASM is still
building a " I/O infrastructure" that utilizes Hyperpav. Nowhere is
explained what this infrastructure looks like. From conversations with
Greg Dyke when he was the expert in that area, I know that in the WLM
managed PAV environment ASM reserved 2 access paths to each page dataset,
resulting in 2n-1 aliases dedicated to a paging volume.

 Is this still done so in the Hyperpav situation?

 >>>>>As far as I know, this is still the case

Our production Sysplex has 10 LCUs on the DS8800 and is connected with 8
Ficon channels. Hyperpav can select alias devices within an LCU, not over
LCUs.

I can allocate 10 page volumes, 1 per LCU, with 1 local page dataset per
volume. This would give ASM 20 access paths to its paging configuration.

I can allocate 2 page datasets on each volume, giving ASM 40 access paths
to its paging configuration. Or 60 or 80.

However, this all has to be handled by the 8 Ficon channels.

How do I determine the optimum?

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

I have not read or found anything to refute my prior estimate, going back to MVS/ESA
(ignoring ESTOR paging and SWAP which are now obsolete, and possibly paging above the bar).

Yes the ASM algorithms have been updated to handle larger real storage sizes with less overhead, primarily by invoking the routines
less frequently under low stress, however, the actual paging routines themselves have not been altered significantly with the exception of
SUSPEND/RESUME removal and PAV support.

I might  budge on the PPS/Page dataset, but that's about it. Channel/Device/Control unit issues are smaller due to the advent of
ESCON/FICON/PAV.

A given is that particular set of workloads in an LPAR with X amount of real storage will produce a paging rate of Y.
If the workload(virtual storage wise) is increased without a corresponding increase in real storage the paging rate will increase as the square of the ratio.
Likewise, if real storage is removed without changing the workload, the same behavior will occur.

<snip>

For most installations your virtual-to-real ratio is way out of date.

Martin Packer,
zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM
</snip>

<snip>
The "optimum" VSTOR config is 2:1 virtual to real. I personally use 3:1 (RSTOR *3). This is a trade off between page rate and devices allocated.

I.e. the sum of all working sets for the LPAR(in frames)  is up to 3 times the number of real storage frames available.
This paging rate goes up *VERY VERY* quickly after 3:1 IIRC, this is a SQUARE function.
For a given original page rate:
To go from 2:1 virtual/real to 3:1 virtual/real generates the ratio (9/4 * original page rate) 2.25 times To go from 2:1 virtual/real to 4:1 virtual/real generates the ratio (16/4
* original page rate) 4 times the original page rate.
</snip>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

From:   "Staller, Allan" <Allan.Stal...@KBMG.COM>
To:     IBM-M...@listserv.ua.edu,
Date:   11/09/2012 04:50 PM
Subject:        Re: Paging configuration recommandation on modern Dasd.
Sent by:        IBM Mainframe Discussion List <IBM-M...@listserv.ua.edu>

Are you sure? What ratio are you using for your sizing estimates?

I have not read or found anything to refute my prior estimate, going back
to MVS/ESA
(ignoring ESTOR paging and SWAP which are now obsolete, and possibly
paging above the bar).

Yes the ASM algorithms have been updated to handle larger real storage
sizes with less overhead, primarily by invoking the routines
less frequently under low stress, however, the actual paging routines
themselves have not been altered significantly with the exception of
SUSPEND/RESUME removal and PAV support.

I might  budge on the PPS/Page dataset, but that's about it.
Channel/Device/Control unit issues are smaller due to the advent of
ESCON/FICON/PAV.

A given is that particular set of workloads in an LPAR with X amount of
real storage will produce a paging rate of Y.
If the workload(virtual storage wise) is increased without a corresponding
increase in real storage the paging rate will increase as the square of
the ratio.
Likewise, if real storage is removed without changing the workload, the
same behavior will occur.

<snip>

For most installations your virtual-to-real ratio is way out of date.

Martin Packer,
zChampion, Principal Systems Investigator, Worldwide Banking Center of
Excellence, IBM
</snip>

<snip>
The "optimum" VSTOR config is 2:1 virtual to real. I personally use 3:1
(RSTOR *3). This is a trade off between page rate and devices allocated.

I.e. the sum of all working sets for the LPAR(in frames)  is up to 3 times
the number of real storage frames available.
This paging rate goes up *VERY VERY* quickly after 3:1 IIRC, this is a
SQUARE function.
For a given original page rate:
To go from 2:1 virtual/real to 3:1 virtual/real generates the ratio (9/4 *
original page rate) 2.25 times To go from 2:1 virtual/real to 4:1
virtual/real generates the ratio (16/4
* original page rate) 4 times the original page rate.
</snip>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

  The recent z/OS development investment in improving ASM
performance has been in the support for paging to flash
memory on the new EC12 processor.  ASM can do many
concurrent operations, and setting up the configuration
is much less complex than page data sets - all you need
to do is decide how much flash memory to assign to each
logical partition.

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Kees.

Kees.

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN