HyperPAV devices (was: PLPA and COMMON PAGESPACE Size)
Jim Mulder wrote: snip It checks to see if you specified WLM PAV when you defined the device in HCD. Since WLM doesn't need to manage PAVs when the control unit has been told to use HyperPAV mode, our intention was that the specification of WLM PAV in HCD would be irrelevant for HyperPAV devices snip Well, that would be irrelevant thing brings me to the following question: If we want to migrate from PAV to HyperPAV, do we need to change the device definitions in the IODF from WLMPAV YesDevice supports work load manager to WLMPAV No Device supports work load manager and our WLM policy from Dynamic alias management . . . . . . . . YES (Yes or No) to Dynamic alias management . . . . . . . . NO (Yes or No)? -- Zaromil
Re: PLPA and COMMON PAGESPACE Size
Thanks for all of the good discussions. What I am reading here is that the only need to size the PLPA and COMMON is to save DASD space. If you have the DASD space, then just allocate a 2GB (combined PLPA and COMMON) page datasets and be done with it, until 64 bit addressing arrives. One other point of interest that I have read about is the different between the PLPA and the COMMON page dataset when it comes to storage protection. PLPA is READ and COMMON is READ/WRITE. Can this lead to potential storage overlays? For example, the 1 cylinder PLPA situation where the PLPA overflows to the COMMON page dataset. Those PLPA pages that reside in the COMMON page dataset are no longer storage protected. -- 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: PLPA and COMMON PAGESPACE Size
Mike Feeley said: One other point of interest that I have read about is the different between the PLPA and the COMMON page dataset when it comes to storage protection. PLPA is READ and COMMON is READ/WRITE. Can this lead to potential storage overlays? For example, the 1 cylinder PLPA situation where the PLPA overflows to the COMMON page dataset. Those PLPA pages that reside in the COMMON page dataset are no longer storage protected. Mike, Page protection has nothing to do with sharing the PLPA and Common page datasets. The page protection bit is in the Page Table Entry. Also, PLPA pages are never paged out (since they cannot change and already exist on the page packs) so there isn't a chance that they will be overlaid on the page packs. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: PLPA and COMMON PAGESPACE Size
So, the PLPA pages residing in the COMMON page dataset (from overflow condition) will have the page protection bit on also as if they were residing in the PLPA page dataset? -- 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: PLPA and COMMON PAGESPACE Size
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/21/2007 02:49:26 PM: So, the PLPA pages residing in the COMMON page dataset (from overflow condition) will have the page protection bit on also as if they were residing in the PLPA page dataset? Yes, they will. 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
Re: PLPA and COMMON PAGESPACE Size
Yes, The page dataset that the slot is loaded into storage from doesn't matter. Remember that the page table for PLPA/COMMON never gets paged out, just the page itself. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mike Feeley Sent: Friday, September 21, 2007 1:49 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size So, the PLPA pages residing in the COMMON page dataset (from overflow condition) will have the page protection bit on also as if they were residing in the PLPA page dataset? -- 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: PLPA and COMMON PAGESPACE Size
Mike Feeley: So, the PLPA pages residing in the COMMON page dataset (from overflow condition) will have the page protection bit on also as if they were residing in the PLPA page dataset? The Page Protection bit gets set in the Page Table Entry by the OS when PLPA is built. The page table is separate from the actual page. Where the pages reside on auxiliary storage is irrelevant. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: PLPA and COMMON PAGESPACE Size
On Wed, 12 Sep 2007 20:01:29 -0400, Jim Mulder [EMAIL PROTECTED] wrote: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/12/2007 12:46:24 PM: Mark Zelden wrote: ... I think the decision to remove suspend/resume was based on issues that kept cropping up with pav and paging. Must have been a fairly serious issue of some sort. Why else would they change the behavior via APAR and not on a release boundary? There is some prior discussion in the archives: http://bama.ua.edu/cgi-bin/wa?A2=ind0602L=ibm-mainP=R27468I=1X=- We had already been planning to remove ASM use of suspend/resume via the HyperPAV support APARs, since HyperPAV didn't mesh well with suspend resume. Then another problem cropped up with dynamic PAV and suspend/resume, and we did not have an elegant solution. Since we we going to be removing suspend/resume anyway, we simply removed it a little earlier. 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 Jim ... Perhaps you can clarify something. If I understand correctly, 2 PAVs are assigned to each page dataset; 1 PAV for single-page requests, and 1 PAV for block requests. If so, is it possible to have any block requests against the PLPA or COMMON page datasets? I understand that if both are on the same volume, each will have its own path to the dataset, but will it have both? Just curious. -- 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: PLPA and COMMON PAGESPACE Size
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/13/2007 11:47:34 AM: Perhaps you can clarify something. If I understand correctly, 2 PAVs are assigned to each page dataset; 1 PAV for single-page requests, and 1 PAV for block requests. If so, is it possible to have any block requests against the PLPA or COMMON page datasets? I understand that if both are on the same volume, each will have its own path to the dataset, but will it have both? Just curious. ASM creates two sets of I/O control blocks for each page data set - one to be used for any kind of request, and a a second set to be used for a single page read if the first set is busy. As far as I know, that applies to PLPA and Common data sets as well as Local. Common could have a long output channel program due to page steal processing, and I suppose PLPA could also if common becomes full and overflows to PLPA. 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
Re: PLPA and COMMON PAGESPACE Size
On Thu, 13 Sep 2007 16:10:04 -0400, Jim Mulder [EMAIL PROTECTED] wrote: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/13/2007 11:47:34 AM: Perhaps you can clarify something. If I understand correctly, 2 PAVs are assigned to each page dataset; 1 PAV for single-page requests, and 1 PAV for block requests. If so, is it possible to have any block requests against the PLPA or COMMON page datasets? I understand that if both are on the same volume, each will have its own path to the dataset, but will it have both? Just curious. ASM creates two sets of I/O control blocks for each page data set - one to be used for any kind of request, and a a second set to be used for a single page read if the first set is busy. As far as I know, that applies to PLPA and Common data sets as well as Local. Common could have a long output channel program due to page steal processing, and I suppose PLPA could also if common becomes full and overflows to PLPA. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY But note that ASM only supports starting 2 I/Os to a page data set when there are dynamic PAVs (as opposed to static PAVs). Unless something has changed since z/OS 1.3 when this support was introduced. 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 and OS390 expert at http://searchDataCenter.com/ateExperts/ 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: PLPA and COMMON PAGESPACE Size
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/13/2007 04:31:14 PM: ASM creates two sets of I/O control blocks for each page data set - one to be used for any kind of request, and a a second set to be used for a single page read if the first set is busy. As far as I know, that applies to PLPA and Common data sets as well as Local. Common could have a long output channel program due to page steal processing, and I suppose PLPA could also if common becomes full and overflows to PLPA. But note that ASM only supports starting 2 I/Os to a page data set when there are dynamic PAVs (as opposed to static PAVs). Unless something has changed since z/OS 1.3 when this support was introduced. That is a very good point, especially because I was going to say Dynamic PAV and of course HyperPAV, but thought I had better check the code first. It turns out that the ASM code which decides whether to create two sets of I/O control blocks for a page data set was not updated for HyperPAV (an oversight on our part). It checks to see if you specified WLM PAV when you defined the device in HCD. Since WLM doesn't need to manage PAVs when the control unit has been told to use HyperPAV mode, our intention was that the specification of WLM PAV in HCD would be irrelevant for HyperPAV devices. But for now, it looks like you would want to specify WLM PAV for HyperPAV paging devices, until we can update the ASM code (probably via an APAR) to automatically recognize HyperPAV paging devices. 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
Re: PLPA and COMMON PAGESPACE Size
Mike Feeley [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? For example, if my LPAR only requires a combined PLPA and COMMON size of 800 cylinders, can I used an entire 3390- 3 for the new PLPA (1 cylinder) and COMMON (the rest of the volume, around 3337 cylinders)? Any issues with the large number of page slots, memory usage, etc. This is for z/OS 1.8 on a z9 box. Nothing else will use this volume. It will either be 100% utilized with PAGE datasets or 100% utulized with PAGE datasets plus a placeholder (filler) dataset. I don't know why I can't just create a huge COMMON page dataset and be done with it versus creating a 700 cylinder COMMON this year and maybe then a 800 cylinder COMMON in 2 more years, etc. Just create the one huge COMMON page dataset and I will be set well into retirement. What are the downfalls from doing something like this? Mike, There are a couple of things to consider: The ancient advantage of a 1 cyl PLPA and a large COMMON, the Seldom Ending Channelprogram, has been retired a couple of z/OS releases ago, so that one has gone. However, a new feature has come into play: PAV. ASM will request 2 alias UCBs for every pagedataset on a volume, so a fullsize PLPA and a fullsized COMMON will give you 3 paths to each of them. But, if your system, like most modern systems, does not do much paging anymore and especially not on PLPA and COMMON, this advantage has little weight. So, yes, if you want to design a PLPA/COMMON configuration that is to last till your retirement, a 1 cyl PLPA and a huge COMMON will probably be the best. 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
The ancient advantage of a 1 cyl PLPA and a large COMMON, the Seldom Ending Channelprogram, has been retired a couple of z/OS releases ago Not to dispute; where is that documented? The last time I discussed this with IBM it was still recommended. - 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: PLPA and COMMON PAGESPACE Size
Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: PLPA and COMMON PAGESPACE Size
Ted MacNEIL [EMAIL PROTECTED] wrote in message news:1482040871-1189580775-cardhu_decombobulator_blackberry.rim.net-179 [EMAIL PROTECTED]... The ancient advantage of a 1 cyl PLPA and a large COMMON, the Seldom Ending Channelprogram, has been retired a couple of z/OS releases ago Not to dispute; where is that documented? The last time I discussed this with IBM it was still recommended. - OA14248, closed 2006-02-07. 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
On Sep 12, 2007, at 2:10 AM, R.S. wrote: Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. Ed -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: PLPA and COMMON PAGESPACE Size
I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. We do this so that we don't have to worry about sizing the PLPA page dataset. We just define a large common page dataset and let PLPAQ overflow into it. There is no performance degradation. Bob Shannon 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: PLPA and COMMON PAGESPACE Size
Ed Gould wrote: Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. Ed I believe that recommendation is no longer valid (not sure as of which z/OS release), but it had to do with the way I/O was handled to load LPA. Allowing it to overflow for some reason was more efficient. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: PLPA and COMMON PAGESPACE Size
Ed Gould wrote: On Sep 12, 2007, at 2:10 AM, R.S. wrote: Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. I know it WAS. My question was rather rhetorical. Many rules of thumb went obsoleted over the years. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: PLPA and COMMON PAGESPACE Size
Ed Gould [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Sep 12, 2007, at 2:10 AM, R.S. wrote: Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. Ed Ok, I already tried to send an answer but Outlook crashed, so I'll try again: One guru told me years ago: question everything and I took that to include the guru. Until recently, the good reason was ASM's usage of Seldom Ending Channel Programs, but that is not valid anymore. If you want to know more about it, let me know. Now, like Mike's proposal, it can help you make life a little easier. PLPA can spill over to COMMON, but not vica versa. So if you want to manage space for both easily, you can do this by creating a small PLPA and a large COMMON, which has free space for both. With both a large PLPA and a COMMON, you must manage growth and free space for both. Not a very big issue, but just a little thing to make life somewhat easier. 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
R.S. wrote: Ed Gould wrote: On Sep 12, 2007, at 2:10 AM, R.S. wrote: Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. I know it WAS. My question was rather rhetorical. Many rules of thumb went obsoleted over the years. I setup all my environments that way. Even if it no longer has any performance benefits it won't hurt anything and doing it that way is one less thing to worry about. -- Mark Jacobs Time Customer Service Tampa, FL -- Pound pastrami, can kraut, six bagels -- bring home for Emma. Isaac Edward Leibowitz (Saint Leibowitz) A Canticle for Leibowitz -- 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: PLPA and COMMON PAGESPACE Size
My theory on this is much like Bob Shannon's. Keep it easier, if you are worried about the performance impact of page-ins from PLPA, you are so real storage constrained that your system will be in bad shape anyway. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Vernooy, C.P. - SPLXM Sent: Wednesday, September 12, 2007 2:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size Ted MacNEIL [EMAIL PROTECTED] wrote in message news:1482040871-1189580775-cardhu_decombobulator_blackberry.rim.net-179 [EMAIL PROTECTED]... The ancient advantage of a 1 cyl PLPA and a large COMMON, the Seldom Ending Channelprogram, has been retired a couple of z/OS releases ago Not to dispute; where is that documented? The last time I discussed this with IBM it was still recommended. - OA14248, closed 2006-02-07. Kees. -- 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: PLPA and COMMON PAGESPACE Size
We do this so that we don't have to worry about sizing the PLPA page dataset. We just define a large common page dataset and let PLPAQ overflow into it. There is no performance degradation. I've been doing since at least XA, if not before. And, that was before expanded storage, so paging rates were high. Until we start paging again, I don't think it's a bad practice. - 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: PLPA and COMMON PAGESPACE Size
I believe that recommendation is no longer valid (not sure as of which z/OS release), but it had to do with the way I/O was handled to load LPA. If you're not paging, it doesn't matter. Allowing it to overflow for some reason was more efficient. The efficiency had to do with (then) expensive DASD (dollars/mb, rather than today's pennies/gb). The practice was: Define a 1-CYL PLPA and put it and the COMMON on the same pack. It saved you a pack. - 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: PLPA and COMMON PAGESPACE Size
Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? For example, if my LPAR only requires a combined PLPA and COMMON size of 800 cylinders, can I used an entire 3390- 3 for the new PLPA (1 cylinder) and COMMON (the rest of the volume, around 3337 cylinders)? Any issues with the large number of page slots, memory usage, etc. This is for z/OS 1.8 on a z9 box. Nothing else will use this volume. It will either be 100% utilized with PAGE datasets or 100% utulized with PAGE datasets plus a placeholder (filler) dataset. I don't know why I can't just create a huge COMMON page dataset and be done with it versus creating a 700 cylinder COMMON this year and maybe then a 800 cylinder COMMON in 2 more years, etc. Just create the one huge COMMON page dataset and I will be set well into retirement. What are the downfalls from doing something like this? snip There is no point in making the COMMON data set any larger than 2GB. COMMON cannot possibly grow to 2GB, since that would be _all_ the space below the bar. I'd allocate a 1-cylinder PLPA followed by a 2GB COMMON and then forget about it for (probably) the rest of my life. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- 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: PLPA and COMMON PAGESPACE Size
On Wed, 12 Sep 2007 07:07:19 +, Ted MacNEIL [EMAIL PROTECTED] wrote: The ancient advantage of a 1 cyl PLPA and a large COMMON, the Seldom Ending Channelprogram, has been retired a couple of z/OS releases ago Not to dispute; where is that documented? The last time I discussed this with IBM it was still recommended. APAR Identifier .. OA14248 Last Changed 06/10/10 NEW FUNCTION Symptom .. NF PERFM Status ... CLOSED UR1 Severity ... 3 Date Closed . 06/02/07 Component .. 5752SC1CW Duplicate of Reported Release . 708 Fixed Release 999 Component Name 5752 AUX STOR M Special Notice ATTENTION Current Target Date .. Flags SCP ...NEW FUNCTION Platform PERVASIVE Status Detail: SHIPMENT - Packaged solution is available for shipment. PE PTF List: PTF List: Release 707 : UA24291 available 06/02/22 (F602 ) Release 708 : UA24292 available 06/02/22 (F602 ) Release 709 : UA24293 available 06/02/22 (F602 ) Release 717 : UA24295 available 06/02/22 (F602 ) Release 720 : UA24294 available 06/02/22 (F602 ) Parent APAR: Child APAR list: ERROR DESCRIPTION: New function APAR As processors, control units, dasd have increased in speed the benefits of suspend/resume have decreased to the point where it has been determined the difference between suspend/ resume and start subchannel are not longer relevant. Therefore it has been decided to no longer use suspend/resume. LOCAL FIX: PROBLEM SUMMARY: * USERS AFFECTED: All users of HBB7707, HBB7708, HBB7709, * * JBB7717, and HBB7720.* * PROBLEM DESCRIPTION: ASM uses suspendable channel programs. * * When an ASM channel program completes, * * it goes into a suspended state. Later, * * when ASM wants to initiate another * * I/O request, it modifies and then * * resumes the suspended channel * * program.* * RECOMMENDATION: The use of suspend/resume channel programs * * in ASM is deleted. * The use of suspend/resume channel programs in ASM is deleted. -- 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 and OS390 expert at http://searchDataCenter.com/ateExperts/ 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: PLPA and COMMON PAGESPACE Size
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Eells Sent: Wednesday, September 12, 2007 8:38 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size snip There is no point in making the COMMON data set any larger than 2GB. COMMON cannot possibly grow to 2GB, since that would be _all_ the space below the bar. I'd allocate a 1-cylinder PLPA followed by a 2GB COMMON and then forget about it for (probably) the rest of my life. -- John Eells I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: PLPA and COMMON PAGESPACE Size
McKown, John [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED].. .. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Eells Sent: Wednesday, September 12, 2007 8:38 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size snip There is no point in making the COMMON data set any larger than 2GB. COMMON cannot possibly grow to 2GB, since that would be _all_ the space below the bar. I'd allocate a 1-cylinder PLPA followed by a 2GB COMMON and then forget about it for (probably) the rest of my life. -- John Eells I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? It is confusing these days, with lines and bars, but ECSA is still under the 2GB line. 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
On Wed, 12 Sep 2007 15:56:20 +0200, Vernooy, C.P. - SPLXM [EMAIL PROTECTED] wrote: There is no point in making the COMMON data set any larger than 2GB. COMMON cannot possibly grow to 2GB, since that would be _all_ the space below the bar. I'd allocate a 1-cylinder PLPA followed by a 2GB COMMON and then forget about it for (probably) the rest of my life. -- John Eells I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? It is confusing these days, with lines and bars, but ECSA is still under the 2GB line. Right, and as John said... that would be all the space below the bar which would mean no EPVT (31-bit private). Try IPLing a sandbox with CSA=(n,1800M) (leaving some room for EPLPA/EMLPA/EFLPA/ESQA/ENUC) and see how far you get. ;-) 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 and OS390 expert at http://searchDataCenter.com/ateExperts/ 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: PLPA and COMMON PAGESPACE Size
John, CSA and ECSA are paged to the COMMON page dataset, PLPA is paged to PLPA and (if overflow) to COMMMON. Since the combined size of PLPA+COMMON has to be less than 2GB, (at least until RMODE 64 programs are available, which may never happen), a 2GB COMMON page dataset will be more than large enough. Where is the confusion? Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Wednesday, September 12, 2007 8:47 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Eells Sent: Wednesday, September 12, 2007 8:38 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size snip There is no point in making the COMMON data set any larger than 2GB. COMMON cannot possibly grow to 2GB, since that would be _all_ the space below the bar. I'd allocate a 1-cylinder PLPA followed by a 2GB COMMON and then forget about it for (probably) the rest of my life. -- John Eells I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology -- 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: PLPA and COMMON PAGESPACE Size
On Wed, 12 Sep 2007 09:37:36 -0400, John Eells wrote: There is no point in making the COMMON data set any larger than 2GB. Until (and unless) we start having common above the bar. Even then 2GB will likely last a while. -- 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: PLPA and COMMON PAGESPACE Size
APAR Identifier .. OA14248 Thanks, Mark. That APAR only mentions suspend/resume. Nothing regarding the one cylinder PLPA. (Which was in use long before suspend/resume, and was used to save a pack -- not for performance). - 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: PLPA and COMMON PAGESPACE Size
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bob Shannon Sent: Wednesday, September 12, 2007 7:34 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size SNIP We do this so that we don't have to worry about sizing the PLPA page dataset. We just define a large common page dataset and let PLPAQ overflow into it. There is no performance degradation. SNIP In most shops where I did the system work, I made the LPA page data set 30% (min) larger than what it used at the time it was going to be rolled into production. The Common was made the max size (today, basically a volume on 3390-3). We did not do CLPA except for when we KNEW we were putting on maint that required the LPA to be refreshed. IPLs ran rather quickly (although today the difference between CLPA and non-CLPA is hardly noticeable). And we didn't have surprises of maint getting on before we were ready. Development shops may want the overflow to always force a CLPA. Regards, Steve Thompson --- -- 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: PLPA and COMMON PAGESPACE Size
I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? But, extended COMMON and below the line COMMON are still below the 2GB bar. So, they could never add up to more than 2GB. - 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: PLPA and COMMON PAGESPACE Size
Kees wrote: Now, like Mike's proposal, it can help you make life a little easier. PLPA can spill over to COMMON, but not vica versa. So if you want to manage space for both easily, you can do this by creating a small PLPA and a large COMMON, which has free space for both. With both a large PLPA and a COMMON, you must manage growth and free space for both. Not a very big issue, but just a little thing to make life somewhat easier. What prevented me from ever doing the small PLPA thing was the last part of the description of the IRL005E message... ILR005E PLPA PAGE DATA SET FULL, OVERFLOWING TO COMMON DATA SET Explanation: The PLPA page data set has become full. All subsequent writes for the PLPA will be sent to the COMMON page data set. System Action: The system continues to build the link pack area by writing pages for the remaining LPA modules to the common page data set. If the common page data set is unavailable or becomes full, the system will be terminated with a wait state code X'03C' reason 3. The way I always figured it was belts braces... if either one of them became unavailable, the other one was still there, which is why I also have them on separate volumes. Could never see the point of gambling with the possibility of downtime on a Prod system... Herbie Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- 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: PLPA and COMMON PAGESPACE Size
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Wednesday, September 12, 2007 9:26 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? But, extended COMMON and below the line COMMON are still below the 2GB bar. So, they could never add up to more than 2GB. - Yea. I desperately need more sleep. And less Oracle (don't ask, won't tell, mea culpa!). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: PLPA and COMMON PAGESPACE Size
Ted MacNEIL [EMAIL PROTECTED] wrote in message news:1253452742-1189606952-cardhu_decombobulator_blackberry.rim.net-192 [EMAIL PROTECTED]... APAR Identifier .. OA14248 Thanks, Mark. That APAR only mentions suspend/resume. Nothing regarding the one cylinder PLPA. (Which was in use long before suspend/resume, and was used to save a pack -- not for performance). - Ted, did you not get my reply with the APAR number? The 1 cylinder PLPA is a result of suspend/resume and the high cost of diskspace these days. With suspend/resume you should have only 1 pagedataset on a volume and by shifing all data to the Common and thus eliminating PLPA dataset I/O, you could get both the paging performance and the volume efficiency. 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Tom Marchant wrote: On Wed, 12 Sep 2007 09:37:36 -0400, John Eells wrote: There is no point in making the COMMON data set any larger than 2GB. Until (and unless) we start having common above the bar. Even then 2GB will likely last a while. Paging for common storage above 2G will likely not be directed toward the existing common paging data set. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: PLPA and COMMON PAGESPACE Size
Ted, did you not get my reply with the APAR number? No. I missed it. The 1 cylinder PLPA is a result of suspend/resume and the high cost of diskspace these days. I was doing it before suspend/resume came out (MVS/SP1.3.0?) The first performance course I ever took had it as a 'trick of the trade'. January 1982. (The course was actually given by Amdahl) - 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: PLPA and COMMON PAGESPACE Size
And to reduce having to seek over empty cylinders because you would allocate more space to the PLPA for growth. Regards, Gene --Original Message-- From: Ted MacNEIL Sender: IBM Mainframe Discussion List To: IBM-MAIN@BAMA.UA.EDU ReplyTo: IBM Mainframe Discussion List Sent: Sep 12, 2007 10:23 AM Subject: Re: PLPA and COMMON PAGESPACE Size APAR Identifier .. OA14248 Thanks, Mark. That APAR only mentions suspend/resume. Nothing regarding the one cylinder PLPA. (Which was in use long before suspend/resume, and was used to save a pack -- not for performance). - 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 Sent via BlackBerry by ATT -- 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: PLPA and COMMON PAGESPACE Size
On Wed, 12 Sep 2007 16:29:15 +0200, Vernooy, C.P. - SPLXM [EMAIL PROTECTED] wrote: The 1 cylinder PLPA is a result of suspend/resume and the high cost of diskspace these days. With suspend/resume you should have only 1 pagedataset on a volume and by shifing all data to the Common and thus eliminating PLPA dataset I/O, you could get both the paging performance and the volume efficiency. Now it doesn't matter if you have more than one pageds per volume if you have dynamic pav (regardless of suspend/resume). I think the decision to remove suspend/resume was based on issues that kept cropping up with pav and paging. 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 and OS390 expert at http://searchDataCenter.com/ateExperts/ 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: PLPA and COMMON PAGESPACE Size
snip--- It was recommended years ago by a guru and no one dares to question the guru. unsnip-- HORSEFEATHERS!! No guru is beyond challenging, expecially when experience indicates different from what the so-called GURU advocates. We tried it both ways at Clearing and ended up separating PAGE and COMMON page spaces and NOT using the overflow method. -- 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: PLPA and COMMON PAGESPACE Size
Thanks for that Ted. I thought it was me. ? On Wed Sep 12 14:23 , Ted MacNEIL [EMAIL PROTECTED] sent: APAR Identifier .. OA14248 Thanks, Mark. That APAR only mentions suspend/resume. Nothing regarding the one cylinder PLPA. (Which was in use long before suspend/resume, and was used to save a pack -- not for performance). - 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: PLPA and COMMON PAGESPACE Size
Mark Zelden wrote: ... I think the decision to remove suspend/resume was based on issues that kept cropping up with pav and paging. Must have been a fairly serious issue of some sort. Why else would they change the behavior via APAR and not on a release boundary? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: PLPA and COMMON PAGESPACE Size
I think that the straw which finally prompted the elimination of suspend/resume channel programs for paging was a problem exposed by products which DDR swap DASD volumes dynamically. I suspect the thinking went something like this: Since the problem exposed by DDR swap of page volumes was very severe, the complexity of correctly fixing this problem very high, and the actual performance value of suspend/resume in this day and age now extremely low, why not simply delete suspend/resume complexity from ASM? See OA09675 for more background on this. Brian On Wed, 12 Sep 2007 09:46:24 -0700, Edward Jaffe wrote: Mark Zelden wrote: ... I think the decision to remove suspend/resume was based on issues that kept cropping up with pav and paging. Must have been a fairly serious issue of some sort. Why else would they change the behavior via APAR and not on a release boundary? -- Edward E Jaffe -- 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: PLPA and COMMON PAGESPACE Size
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/12/2007 12:46:24 PM: Mark Zelden wrote: ... I think the decision to remove suspend/resume was based on issues that kept cropping up with pav and paging. Must have been a fairly serious issue of some sort. Why else would they change the behavior via APAR and not on a release boundary? There is some prior discussion in the archives: http://bama.ua.edu/cgi-bin/wa?A2=ind0602L=ibm-mainP=R27468I=1X=- We had already been planning to remove ASM use of suspend/resume via the HyperPAV support APARs, since HyperPAV didn't mesh well with suspend resume. Then another problem cropped up with dynamic PAV and suspend/resume, and we did not have an elegant solution. Since we we going to be removing suspend/resume anyway, we simply removed it a little earlier. 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
PLPA and COMMON PAGESPACE Size
I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? For example, if my LPAR only requires a combined PLPA and COMMON size of 800 cylinders, can I used an entire 3390- 3 for the new PLPA (1 cylinder) and COMMON (the rest of the volume, around 3337 cylinders)? Any issues with the large number of page slots, memory usage, etc. This is for z/OS 1.8 on a z9 box. Nothing else will use this volume. It will either be 100% utilized with PAGE datasets or 100% utulized with PAGE datasets plus a placeholder (filler) dataset. I don't know why I can't just create a huge COMMON page dataset and be done with it versus creating a 700 cylinder COMMON this year and maybe then a 800 cylinder COMMON in 2 more years, etc. Just create the one huge COMMON page dataset and I will be set well into retirement. What are the downfalls from doing something like this? -- 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
