Re: 3 Page Datasets on one Volume
We did this, long ago far away, at our time share NVIP, IBM 3880-11 w/3350's. I'm with you on this Ted, I always liked to keep this, paging environment, simple as possible with paging with own volume. This may be a bit of old school thinking but when there are problems or potential data management issues I know straight away what it most probably is not. But at this point horses for courses, if you will... Ted MacNEIL [EMAIL PROTECTED] wrote: There was a time that the recommendation was to put paging data sets on dedicated volumes attached to dedicated control units. I've never seen anyone do that with ordinary DASD. I did it 3330's, 3350's, 3380's from 1981 to 1989. Dedicated DASD, control units and channels. With 3390's, and quad pathing, we started getting away from dedicated paths and control units. But, we kept dedicated packs. I'm still biased towards the last one. (Except for the 1-Cyl PLPA 'trick') - Too busy driving to stop for gas! -- 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 -- 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
Re: 3 Page Datasets on one Volume
Ted, I always liked to keep this, paging environment, simple as possible with paging with own volume. This may be a bit of old school thinking but when there are problems or potential data management issues I know straight away what it most probably is not. I agree, obviously. But, some people want to put multiple data-types on page packs. I'm not one of them. We are going to start paging, again, sometime in the future. And, with the reduction in mainframe staff skills, why invite problems down the line? - Too busy driving to stop for gas! -- 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
Re: 3 Page Datasets on one Volume
In a message dated 5/7/2008 11:57:26 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: If I am right that resume subchannel is no longer used by ASM, than putting other low to medium use datasets on the same volume will make little or no difference to paging performance. The devil is in the details of the definition of low to medium use. If such a data set is sequential and it is not used for days on end, when it is finally used it may easily be accessed hundreds of times per second for however long it takes to read or write the entire data set. If there is a need for high paging performance during this burst, then paging performance will likely suffer. There are several things that paging can do to get its I/O request ahead of others in the queue (e.g., use of the IOSXIMEX flag bit in the IOSB), but I don't know if paging I/O does this. And paging I/O interrupts are processed ahead of other pending interrupts, I believe, thus allowing the next paging I/O to be started ahead of others. Bill Fairchild Rocket Software **Wondering what's for Dinner Tonight? Get new twists on family favorites at AOL Food. (http://food.aol.com/dinner-tonight?NCID=aolfod000301) -- 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
Re: 3 Page Datasets on one Volume
If I am right that resume subchannel is no longer used by ASM, than putting other low to medium use datasets on the same volume will make little or no difference to paging performance. I disagree. I still think that page volumes (regardless of size) should be dedicated, except the PLPA/CSA 'trick'. It's cleaner and less inviting of problems. Also, DASD is cheap enough, these days. Yes, SUSPEND/RESUME is no longer in use, on supported releases of z/OS. Mind you, I think paging is going the way of the Dodo, just like swap has. Look at DB2 V8's requirements. - Too busy driving to stop for gas! -- 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
Re: 3 Page Datasets on one Volume
In a message dated 5/8/2008 8:54:18 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Yes, SUSPEND/RESUME is no longer in use, on supported releases of z/OS. No longer in use by the paging subsystem. But still in use by XCF, at least it was the last time I looked at a GTF I/O trace. And some vendor products, probably. And that's just DASD I/O that uses it. I have no clue about other device classes' use of suspend/resume. Bill Fairchild Rocket Software **Wondering what's for Dinner Tonight? Get new twists on family favorites at AOL Food. (http://food.aol.com/dinner-tonight?NCID=aolfod000301) -- 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
Re: 3 Page Datasets on one Volume
Bill, The devil is in the detail. If the page datasets are being accessed their own alias UCB then the channel commands, FCP frames and disk IO are being interleaved with all the other volumes that share the same channels, storage ports and disk drives. Even a heavy use sequential use dataset on the same volume will create the same interference as if it was on another volume sharing the same channels and Parity Group. In your example, I don't see how isolation reduces that impact. Ron The devil is in the details of the definition of low to medium use. If such a data set is sequential and it is not used for days on end, when it is finally used it may easily be accessed hundreds of times per second for however long it takes to read or write the entire data set. If there is a need for high paging performance during this burst, then paging performance will likely suffer. There are several things that paging can do to get its I/O request ahead of others in the queue (e.g., use of the IOSXIMEX flag bit in the IOSB), but I don't know if paging I/O does this. And paging I/O interrupts are processed ahead of other pending interrupts, I believe, thus allowing the next paging I/O to be started ahead of others. Bill Fairchild Rocket Software -- 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
Re: 3 Page Datasets on one Volume
Ted, Your free to have your own opinion, but if your storage admin required demonstrable benefit of dedicated page volumes or you lose them, what would you show him? What problems are you avoiding and how is it cleaner for her/him? Ron I disagree. I still think that page volumes (regardless of size) should be dedicated, except the PLPA/CSA 'trick'. It's cleaner and less inviting of problems. Also, DASD is cheap enough, these days. Yes, SUSPEND/RESUME is no longer in use, on supported releases of z/OS. Mind you, I think paging is going the way of the Dodo, just like swap has. Look at DB2 V8's requirements. - Too busy driving to stop for gas! -- 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 -- 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
Re: 3 Page Datasets on one Volume
Your free to have your own opinion, but if your storage admin required
demonstrable benefit of dedicated page volumes or you lose them, what would
you show him? What problems are you avoiding and how is it cleaner for her/him?
1. Don't have to back anything up.
2. You don't have the potential problem of a burst of activity to the 'medium
activity' files.
3. Because (8-{}
-
Too busy driving to stop for gas!
--
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
Re: 3 Page Datasets on one Volume
On Thu, 8 May 2008 09:35:01 -0700, Ron Hawkins [EMAIL PROTECTED] wrote: Bill, The devil is in the detail. If the page datasets are being accessed their own alias UCB then the channel commands, FCP frames and disk IO are being interleaved with all the other volumes that share the same channels, storage ports and disk drives. Even a heavy use sequential use dataset on the same volume will create the same interference as if it was on another volume sharing the same channels and Parity Group. In your example, I don't see how isolation reduces that impact. Ron Ron, see my previous post and I'm sure there is something in the archives from either Jim Mulder or Peter Relson (where do ya think I got my information from?) :-) The other I/O could take the PAVs that ASM has recommended to WLM to assign. That could mean no UCB for a page request. http://bama.ua.edu/cgi-bin/wa?A2=ind0805L=ibm-mainD=1amp;O=DT=0P=49572 So while having multiple page data sets per volume should not be a problem with dynamic PAV, having other active data sets could be. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: 3 Page Datasets on one Volume
Ted,
For number 1, do logical backups and exclude the page datasets.
For number 2, on current z/OS releases I believe this is in the MVS myth
category. It's only a potential problem if you go back to early OS390 releases,
or you do not use PAV. How would you verify that the problem exists.
For number 3, no comment.
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ted MacNEIL
Sent: Thursday, May 08, 2008 9:43 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: [IBM-MAIN] 3 Page Datasets on one Volume
Your free to have your own opinion, but if your storage admin required
demonstrable benefit of dedicated page volumes or you lose them, what
would you show him? What problems are you avoiding and how is it
cleaner for her/him?
1. Don't have to back anything up.
2. You don't have the potential problem of a burst of activity to the
'medium activity' files.
3. Because (8-{}
-
Too busy driving to stop for gas!
--
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
--
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
Re: 3 Page Datasets on one Volume
Mark, Which is why in an earlier post I mentioned a dedicated LCU for Page datasets. That way you can always have an over abundance of Alias. BTW I'm not saying that one should mindlessly go out and treat paging as just another dataset. I just don't like seeing a practice perpetuated when the reason for it has gone away. I was taught that Page Datasets are on dedicated volumes so that IO to another dataset would not cause the suspended channel program from ending. All the other discussion is about managing and mitigating contention. If the suggestion that page dataset isolation is absolutely critical, then why not give them a dedicated Cache Partition and FlashAccess as well? With 512GB of cache it would be easy to carve out 32GB and go back to a solid state paging environment :-) Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Thursday, May 08, 2008 10:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] 3 Page Datasets on one Volume On Thu, 8 May 2008 09:35:01 -0700, Ron Hawkins [EMAIL PROTECTED] wrote: Bill, The devil is in the detail. If the page datasets are being accessed their own alias UCB then the channel commands, FCP frames and disk IO are being interleaved with all the other volumes that share the same channels, storage ports and disk drives. Even a heavy use sequential use dataset on the same volume will create the same interference as if it was on another volume sharing the same channels and Parity Group. In your example, I don't see how isolation reduces that impact. Ron Ron, see my previous post and I'm sure there is something in the archives from either Jim Mulder or Peter Relson (where do ya think I got my information from?) :-) The other I/O could take the PAVs that ASM has recommended to WLM to assign. That could mean no UCB for a page request. http://bama.ua.edu/cgi-bin/wa?A2=ind0805L=ibm- mainD=1amp;O=DT=0P=49572 So while having multiple page data sets per volume should not be a problem with dynamic PAV, having other active data sets could be. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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 -- 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
Re: 3 Page Datasets on one Volume
On Thu, 8 May 2008 10:05:19 -0700, Ron Hawkins wrote:
Ted,
For number 1, do logical backups and exclude the page datasets.
For number 2, on current z/OS releases I believe this is in the
MVS myth category. It's only a potential problem if you go back
to early OS390 releases, or you do not use PAV. How would you
verify that the problem exists.
For number 3, no comment.
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ted MacNEIL
Sent: Thursday, May 08, 2008 9:43 AM
Your free to have your own opinion, but if your storage admin required
demonstrable benefit of dedicated page volumes or you lose them, what
would you show him? What problems are you avoiding and how is it
cleaner for her/him?
1. Don't have to back anything up.
2. You don't have the potential problem of a burst of activity to the
'medium activity' files.
3. Because (8-{}
Also, for number 2, you can still have contention at the physical drive level
from data sets that are on different volumes. Consider this: if you have a
RAID array of 8 146 GB volumes, the array contains about a terabyte of data.
Heavy activity to enough of the nearly 40 model 27 drives on that array could
cause contention. Fortunately, cache helps a lot.
There was a time that the recommendation was to put paging data sets on
dedicated volumes attached to dedicated control units. I've never seen
anyone do that with ordinary DASD.
--
Tom Marchant
--
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
Re: 3 Page Datasets on one Volume
There was a time that the recommendation was to put paging data sets on dedicated volumes attached to dedicated control units. I've never seen anyone do that with ordinary DASD. I did it 3330's, 3350's, 3380's from 1981 to 1989. Dedicated DASD, control units and channels. With 3390's, and quad pathing, we started getting away from dedicated paths and control units. But, we kept dedicated packs. I'm still biased towards the last one. (Except for the 1-Cyl PLPA 'trick') - Too busy driving to stop for gas! -- 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
Re: 3 Page Datasets on one Volume
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/08/2008 11:52:31 AM: In a message dated 5/8/2008 8:54:18 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Yes, SUSPEND/RESUME is no longer in use, on supported releases of z/OS. No longer in use by the paging subsystem. But still in use by XCF, at least it was the last time I looked at a GTF I/O trace. And some vendor products, probably. And that's just DASD I/O that uses it. I have no clue about other device. XCF uses Suspend/Resume for signalling path CTCs. The only DASD I/O that ever used it (as far as I know) was paging, and that has been removed. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
3 Page Datasets on one Volume
I noticed again today that we have 6 local page datasets on 2 volumes - each a 3390-3. I'm sure they have Pavs, or the equivelent on the dasd, but I'm just wondering if that is a good practice or not. Eric -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- 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
Re: 3 Page Datasets on one Volume
As always, Eric, the answer to your question is: It depends ... Other than PLPA and COMMON, are you paging at all to the LOCAL datasets? Check your RMF reports to see, how much activity you have, average and peak values. That should tell you, (a) if you should spread this over more volumes and (b) if you have enough page space to handle a peak load without a negative performance hit. Regards, Ulrich Krueger -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Eric Bielefeld Sent: Wednesday, May 07, 2008 10:10 To: IBM-MAIN@BAMA.UA.EDU Subject: 3 Page Datasets on one Volume I noticed again today that we have 6 local page datasets on 2 volumes - each a 3390-3. I'm sure they have Pavs, or the equivelent on the dasd, but I'm just wondering if that is a good practice or not. Eric -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- 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 -- 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
Re: 3 Page Datasets on one Volume
I noticed again today that we have 6 local page datasets on 2 volumes - each a 3390-3. I'm sure they have Pavs, or the equivelent on the dasd, but I'm just wondering if that is a good practice or not. 1. I wouldn't do it! 2. Rather than being 'sure', 'ensure'. - Too busy driving to stop for gas! -- 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
Re: 3 Page Datasets on one Volume
You are the only one who can tell if performance is an issue. However, there is a limitation to keep in mind. You cannot delete a page data dataset from a volume if there is another active page dataset on that volume. -Original Message- From: Eric Bielefeld [mailto:snip] Sent: Wednesday, May 07, 2008 10:10 AM To: IBM-MAIN@BAMA.UA.EDU Subject: 3 Page Datasets on one Volume I noticed again today that we have 6 local page datasets on 2 volumes - each a 3390-3. I'm sure they have Pavs, or the equivelent on the dasd, but I'm just wondering if that is a good practice or not. -- 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
Re: 3 Page Datasets on one Volume
Ulrich, I was curious, so I ran just an RMF summary report. We have very little paging. For the 5 day period I ran, I think the highest demand paging for a 15 minute interval was 12 PPS. I had ran this same report in February, and the highest was 57. Most intervals are less than 1 PPS. I suspect that 3 page datasets on each of the 2 packs doesn't hurt us. When I looked earlier, the locals were a little less than 25% full. I'm just curious what other people feel about this. I'd never seen multiple page datasets on the same volume before other than a 1 CYL PLPA and Common on the same volume. I remember discussions in the past about the number and size of page datasets, and talking about when everything is abending, that that can really stress your page datasets if they aren't big enough. I would imagine in that situation that it could take a lot longer to get out of that situation. Eric Ulrich Krueger [EMAIL PROTECTED] wrote: As always, Eric, the answer to your question is: It depends ... Other than PLPA and COMMON, are you paging at all to the LOCAL datasets? Check your RMF reports to see, how much activity you have, average and peak values. That should tell you, (a) if you should spread this over more volumes and (b) if you have enough page space to handle a peak load without a negative performance hit. Regards, Ulrich Krueger Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- 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
Re: 3 Page Datasets on one Volume
-Original Message- From: Eric Bielefeld [mailto:snip] Sent: Wednesday, May 07, 2008 10:10 AM To: IBM-MAIN@BAMA.UA.EDU Subject: 3 Page Datasets on one Volume I noticed again today that we have 6 local page datasets on 2 volumes - each a 3390-3. I'm sure they have Pavs, or the equivelent on the dasd, but I'm just wondering if that is a good practice or not. Lots of misinformation being given out... 1) As long as you have dynamic PAVs, you can have more than one page data set per volume without a performance impact. These aren't SLED devices and the page data sets aren't really on the same physical volume. The bottleneck of a single UCB is eliminated with the PAVs (ASM tells WLM to keep 2 PAVs per page data set). However, it still isn't good to mix other data sets on the same volume because IOS doesn't know diddly about the PAVs assigned for ASM's use and will use them for other purposes if needed. 2) Even if you have HIPERPAV, keep WLM PAVs active or ASM won't assign the extra aliases for page data sets. This is a bug that hopefully will be fixed in z/OS 1.10. (search the archives) 3) You've been able to delete an inactive page data set from a volume even if there is another active page data set since z/OS 1.3 IIRC. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: 3 Page Datasets on one Volume
It depends. In the old SLED days this could be performance crippling, especially if there was a decent paging rate(remember only one actuator/volume). With little or no paging this would not be a large problem. Fast forward 20 years: Data is mapped transparently to many many small drives, accessed by many actuators. Again if there is no significant paging, no problem. If significant paging occurs, this MAY BE a problem, maybe not. Having said all of the above, my distinct preference would be for one page ds the size of the 3 currently occupying the volume. HTH, snip I noticed again today that we have 6 local page datasets on 2 volumes - each a 3390-3. I'm sure they have Pavs, or the equivelent on the dasd, but I'm just wondering if that is a good practice or not. /snip -- 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
Re: 3 Page Datasets on one Volume
There are only the 3 page datasets on each of the 2 volumes, and they take all of the available space. I was going to mention in the original post that our datacenter is contracted out, so there is really nothing I can do about changing our paging configuration. I know someone mentioned that it was not a good idea to put other datasets on paging volumes. When I was at PH Mining, I used the page datasets for a lot of vendor product datasets. We didn't do much paging there either, so I don't think it hurt us. I agree, its not a good practice to put other data on page packs, but when you are short of disk space, you make do with what you have. Eric Mark Zelden [EMAIL PROTECTED] wrote: Lots of misinformation being given out... 1) As long as you have dynamic PAVs, you can have more than one page data set per volume without a performance impact. These aren't SLED devices and the page data sets aren't really on the same physical volume. The bottleneck of a single UCB is eliminated with the PAVs (ASM tells WLM to keep 2 PAVs per page data set). However, it still isn't good to mix other data sets on the same volume because IOS doesn't know diddly about the PAVs assigned for ASM's use and will use them for other purposes if needed. 2) Even if you have HIPERPAV, keep WLM PAVs active or ASM won't assign the extra aliases for page data sets. This is a bug that hopefully will be fixed in z/OS 1.10. (search the archives) 3) You've been able to delete an inactive page data set from a volume even if there is another active page data set since z/OS 1.3 IIRC. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- 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
Re: 3 Page Datasets on one Volume
On Wed, 7 May 2008 14:58:21 -0500, Staller, Allan [EMAIL PROTECTED] wrote: It depends. In the old SLED days this could be performance crippling, especially if there was a decent paging rate(remember only one actuator/volume). With little or no paging this would not be a large problem. Fast forward 20 years: Data is mapped transparently to many many small drives, accessed by many actuators. Again if there is no significant paging, no problem. If significant paging occurs, this MAY BE a problem, maybe not. Having said all of the above, my distinct preference would be for one page ds the size of the 3 currently occupying the volume. HTH, snip I noticed again today that we have 6 local page datasets on 2 volumes - each a 3390-3. I'm sure they have Pavs, or the equivelent on the dasd, but I'm just wondering if that is a good practice or not. /snip -- 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 It is best to have a minimum of four(4) local page datasets; more is better. The heavy hitter that gets lost in the mix is an SVC dump. This can put quite a load on the paging configuration when it needs to page-in a lot of inactive frames, just to write them out to a dump dataset. The system will be disabled while the copy process copies this to a dataspace (which, in turn, can stress the real storage configuration, and thus cause more page-out activity). You really want to be disabled for as short a time as possible. So, more concurrent paging I/Os is better; the way to get that is more local datasets. With PAVs, they need not be on different volumes. Without PAVs, separate volumes are strongly recommended. -- 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
Re: 3 Page Datasets on one Volume
Eric, The last shop I worked for (and IIRC), we had 1 3390-3 for PLPA and COMMON and 6 or 7 3390-3 full-pack LOCALs. The paging rates were even less than yours, because the LPAR also had plenty of memory. If it doesn't hurt performance (and your phone doesn't ring, or does it?), you probably don't need to do anything. In your case, my gut-feel recommendation for your shop would be: - 1 pack for both PLPA and COMMON (or, if you can afford the disk space, 1 pack each) - create 3 to 5 LOCAL datasets, each a full-volume 3390-3 - migrate to the new LOCALs using appropriate PAGEADD commands, drain/delete the old ones - update PARMLIB to use only the new datasets eff. next IPL w/ CLPA - monitor performance In the future, if you go over 25% full on LOCALs, add another full-volume LOCAL page ds, to help with spreading the I/O. With your current configuration, I'd be a little concerned about running short on paging slots, if a sudden demand for large amounts of storage came along (e.g., new app., memory-hungry program, something causing several SVC dumps quickly). And, of course, if you could scrounge up a little more real storage for the LPAR, that would help even more than the best and fastest page dataset. Yeah, I know ... I'm dreaming ... :-) And that's my 2cents' worth. HTH. Regards, Ulrich Krueger -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Eric Bielefeld Sent: Wednesday, May 07, 2008 12:49 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 3 Page Datasets on one Volume Ulrich, I was curious, so I ran just an RMF summary report. We have very little paging. For the 5 day period I ran, I think the highest demand paging for a 15 minute interval was 12 PPS. I had ran this same report in February, and the highest was 57. Most intervals are less than 1 PPS. I suspect that 3 page datasets on each of the 2 packs doesn't hurt us. When I looked earlier, the locals were a little less than 25% full. I'm just curious what other people feel about this. I'd never seen multiple page datasets on the same volume before other than a 1 CYL PLPA and Common on the same volume. I remember discussions in the past about the number and size of page datasets, and talking about when everything is abending, that that can really stress your page datasets if they aren't big enough. I would imagine in that situation that it could take a lot longer to get out of that situation. Eric -- 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
Re: 3 Page Datasets on one Volume
John, I'm relying on my memory and not an archive search. I'm sure there is a post from Greg Dyck many years ago saying that paging is optimised for a minimum of eight page datasets. He was disagreeing with a statement (by me I think) along the lines that fewer, full-pack datasets are just as good as many smaller ones. Every MF RAID vendor support Custom Volume Sizes, so there is no need to have any wasted space whether all eight locals, PLPA and Common are on dedicated volumes, or you simply plonk them all on one or two volumes with a dedicated LCU and enough Alias assigned. If I am right that resume subchannel is no longer used by ASM, than putting other low to medium use datasets on the same volume will make little or no difference to paging performance. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Laubenheimer Sent: Wednesday, May 07, 2008 2:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] 3 Page Datasets on one Volume On Wed, 7 May 2008 14:58:21 -0500, Staller, Allan [EMAIL PROTECTED] wrote: It depends. In the old SLED days this could be performance crippling, especially if there was a decent paging rate(remember only one actuator/volume). With little or no paging this would not be a large problem. Fast forward 20 years: Data is mapped transparently to many many small drives, accessed by many actuators. Again if there is no significant paging, no problem. If significant paging occurs, this MAY BE a problem, maybe not. Having said all of the above, my distinct preference would be for one page ds the size of the 3 currently occupying the volume. HTH, snip I noticed again today that we have 6 local page datasets on 2 volumes - each a 3390-3. I'm sure they have Pavs, or the equivelent on the dasd, but I'm just wondering if that is a good practice or not. /snip -- 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 It is best to have a minimum of four(4) local page datasets; more is better. The heavy hitter that gets lost in the mix is an SVC dump. This can put quite a load on the paging configuration when it needs to page-in a lot of inactive frames, just to write them out to a dump dataset. The system will be disabled while the copy process copies this to a dataspace (which, in turn, can stress the real storage configuration, and thus cause more page-out activity). You really want to be disabled for as short a time as possible. So, more concurrent paging I/Os is better; the way to get that is more local datasets. With PAVs, they need not be on different volumes. Without PAVs, separate volumes are strongly recommended. -- 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 -- 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
