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
>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 f
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
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
>-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 equiv
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, access
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 i
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.
>
>
dnesday, 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 th
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 go
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
>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 'tr
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
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
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 (regard
>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
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 chann
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.
Fo
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 rea
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 n
>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 q
IBM Mainframe Discussion List 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 us
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 manageme
>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 peo
24 matches
Mail list logo
