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
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
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
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
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
: 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
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
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
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
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,
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,
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
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!
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
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;
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
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
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 ?
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
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
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 ?
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
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
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
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
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
-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
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
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
@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
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
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!
-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
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!
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
-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
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
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
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
: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
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
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
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
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
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
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
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
47 matches
Mail list logo
