-hs-mstg
(602) 977-5154
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ted MacNEIL
Sent: Saturday, May 24, 2008 10:17 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: PAGEDEL - Was "Large Page Datasets APAR OA20749"
>You would want to P
>You would want to PAGEDEL before using TDMF to swap the volume to another
>device address.
Why?
We never did.
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Of Martin Packer
Sent: Saturday, May 24, 2008 6:52 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: PAGEDEL - Was "Large Page Datasets APAR OA20749"
If I read the bit about PAGEDEL correctly it occurs to me the ESQA issue
is minimised if the data set to be removed is empty (or almost so) at
th
>If I read the bit about PAGEDEL correctly it occurs to me the ESQA issue is
>minimised if the data set to be removed is empty (or almost so) at the
time the PAGEDEL is issued. It strikes me one wouldn't typically remove a data
set at a busy time. So I'm wondering if this is a big deal.
I'm not
If I read the bit about PAGEDEL correctly it occurs to me the ESQA issue
is minimised if the data set to be removed is empty (or almost so) at the
time the PAGEDEL is issued. It strikes me one wouldn't typically remove a
data set at a busy time. So I'm wondering if this is a big deal.
Or is thi
PTFs are available.
Interesting note about PAGEDEL and use of ESQA.
Best Regards,
Sam Knutson, GEICO
System z Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
"Think
Shane wrote:
But what if customers *do* go back to single (*really* big) page
datasets per volume ???.
I don't think anyone is suggesting customers reduce the number of page
data sets in their configuration. But with the subject APAR, they can
now make them larger than 4G. (Actually, they
On Tue, 4 Mar 2008 12:31:01 +0100, Vernooy, C.P. - SPLXM wrote:
<- snip ->
>Yes, as I understood too, it is fully managed by the hardware, not by
>WLM. So this means that ASM may have to compete for exposures.
>Possibly/hopefully ASM's I/O priority will give it the needed advantage.
>Othe
"Barbara Nitz" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Kees,
>
> >I am not sure who Hiperpavs react on ASM I/O, but currently ASM
> >*reserves* PAV exposures with WLM, so ASM will never be bothered by
PAV
> >management issues, which could result in undesired bad ASM
perf
How to configure page data sets is an interesting question. I've just been
involved in a customer situation where significant paging was a problem.
Unfortunately it's still too fresh to really talk about it. But I can see
this new function is a good excuse to blog about paging. And I already
ha
I've asked for clarification on HyperPAVs and ASM. I'll post the gist of
the response when I get it.
What's not clear is whether the I/O patterns warrant it, never mind
whether it's supported.
Martin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wale
Kees,
>I am not sure who Hiperpavs react on ASM I/O, but currently ASM
>*reserves* PAV exposures with WLM, so ASM will never be bothered by PAV
>management issues, which could result in undesired bad ASM performance.
My recollection of HiperPAV presentations is fuzzy, but as far as I remember,
i
"Barbara Nitz" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> >I wonder if customers will now be inclined to use "big" (as we
currently
> >know it) volumes solely for one page dataset. Rather than perhaps
having
> >separate datasets (each eligible for PAV exposures) from differe
"Shane" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> On Tue, 2008-03-04 at 09:25 +0100, Vernooy, C.P. - SPLXM wrote:
>
> > If you don't dedicate volumes to 1 pgds, you now have better
> > performance too than in the SECP situation.
>
> No argument there Kees.
> But what if c
>I wonder if customers will now be inclined to use "big" (as we currently
>know it) volumes solely for one page dataset. Rather than perhaps having
>separate datasets (each eligible for PAV exposures) from different
>systems on a large (logical) volume. Means a lot less page datasets,
>with signifi
On Tue, 2008-03-04 at 09:25 +0100, Vernooy, C.P. - SPLXM wrote:
> If you don't dedicate volumes to 1 pgds, you now have better
> performance too than in the SECP situation.
No argument there Kees.
But what if customers *do* go back to single (*really* big) page
datasets per volume ???.
And then t
ED]>.
> > .
> > > Hi,
> > >
> > > An interesting APAR noted in SHARE session 2815 Real Storage
Manager's
> > -
> > > Functional Evolution for Scalability and Performance. OA20749 is
still
> > > open.
> > >
> > > Large Pa
"Shane" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> On Tue, 2008-03-04 at 02:47 -0500, Jim Mulder wrote:
>
> > > Is there any information about the solution? E.g. how many PAV's
does
> > > ASM reseve for the large pgds? 1 per nn slots?
> >
> > Nothing has changed with re
On Tue, 2008-03-04 at 02:47 -0500, Jim Mulder wrote:
> > Is there any information about the solution? E.g. how many PAV's does
> > ASM reseve for the large pgds? 1 per nn slots?
>
> Nothing has changed with regard to ASM's use of PAV.
I had presumed this to be the case.
I wonder if customers
x27;s
> -
> > Functional Evolution for Scalability and Performance. OA20749 is still
> > open.
> >
> > Large Page Datasets APAR OA20749
> >
> > * OA20749 for z/OS V1.8 and V1.9 will remove the 4G limit for paging
> > datasets - The maximum size for a paging da
inframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Rob Schramm
> Sent: Monday, March 03, 2008 9:45 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Large Page Datasets APAR OA20749
>
> Sam,
>
> I am curious about the unintended affect of OA20749. Do you know if
Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Rob Schramm
Sent: Monday, March 03, 2008 9:45 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Large Page Datasets APAR OA20749
Sam,
I am curious about the unintended affect of OA20749. Do you know if it
"in general" remove the restriction of n
---
I am curious about the unintended affect of OA20749. Do you know if it
"in general" remove the restriction of non-SMS VSAM being limited to 4GB?
I would tend to doubt that. A PAGE file more closely resembles a BDAM
file,
Sam,
I am curious about the unintended affect of OA20749. Do you know if it
"in general" remove the restriction of non-SMS VSAM being limited to 4GB?
Regards,
Rob Schramm
Senior Systems Engineer
Sirius Computer Solutions
--
Pushparaj, Samuel S
Sent: Monday, March 03, 2008 7:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Large Page Datasets APAR OA20749
Hello
Can anyone help me in configuring remote drives for the PM2
configurations?
Regards,
Sam.
-Original Message-
From: IBM Mainframe Discussion List [mailto
Datasets APAR OA20749
Hi,
An interesting APAR noted in SHARE session 2815 Real Storage Manager's -
Functional Evolution for Scalability and Performance. OA20749 is still
open.
Large Page Datasets APAR OA20749
* OA20749 for z/OS V1.8 and V1.9 will remove the 4G limit for paging
datasets
"Knutson, Sam" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>.
..
> Hi,
>
> An interesting APAR noted in SHARE session 2815 Real Storage Manager's
-
> Functional Evolution for Scalability and Performance. OA20749 is still
> o
Hi,
An interesting APAR noted in SHARE session 2815 Real Storage Manager's -
Functional Evolution for Scalability and Performance. OA20749 is still
open.
Large Page Datasets APAR OA20749
* OA20749 for z/OS V1.8 and V1.9 will remove the 4G limit for paging
datasets - The maximum size
28 matches
Mail list logo
