All,

>From a performance POV I have to say I favour PDSE over PDS. I've had two
experiences that affected the business end of the companies I was looking
at. 

One was a PDS Source Library with around 25,000 members that were
check-out/in all day by a couple of hundred programmers. It was the single
busiest dataset in the whole shop (two sites, 10 CEC, 19 LPARS, several 1000
ESCON Channels). Changing this to PDS-E, and assuring PDSE caching was
working (old style DFSMS 1.2 or 1.3 with MSR=3ms) took this dataset off the
RADAR and satisfied some series latent demand on that Development system.

Second and more recent example was a transaction-in-batch job with 45 steps
and a SLA of 10 second average. Converting the main application loadlibs to
PDS-E shaved several seconds off the average elapsed time (the customer did
not specify), and later adding PDSE caching with VLF sliced off another 2-3
seconds.

For my own datasets it is just that I hate interrupting what I'm doing with
a compress. I've gone over three years without compressing a PDS, because my
personal datasets are PDSE.

Ron 

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Chris Craddock
> Sent: Wednesday, February 10, 2010 6:44 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] PDS vs. PDSE
> 
> On Wed, Feb 10, 2010 at 1:46 PM, John R. Ehrman (408-463-3543 T/543-) <
> ehr...@vnet.ibm.com> wrote:
> 
> > PDSEs have been available for a long time, and provide many
> > advantages over PDSs. Why are people reluctant to use PDSEs?
> >
> 
> 
> As others have pointed out, PDSEs have a (justifiably) bad reputation for
> poor reliability and performance. They also have a litany of limitations
> (e.g. not being able to be used in the IPL-time LPA) that make them less
> useful and/or more complex to deal with than a plain old PDS. Which is
> doubly ironic since it was the limitations of PDSs that drove the creation
> of PDSE in the first place. It is another example of a piece of half
> baked/underfunded functionality where marketing factors trumped business
> needs (e.g. the completely artificial need for PDSEs to be SMS managed)
and
> nobody took the time (i.e. there was no budget) to stitch them into the
> operating system and utilities so that they could actually be used as a
> replacement for PDSs.
> 
> With all that said, the straw man arguments in favor of cross-system
sharing
> of PDS over PDSE demonstrate a lack of understanding of the fundamental
> limitations of the former. For all their faults, PDSEs are actually a
better
> deal for sharing within a SYSPLEX and for most garden variety purposes
they
> work just fine these days. Assuming you keep up with maintenance :-)
> 
> --
> This email might be from the
> artist formerly known as CC
> (or not) You be the judge.
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to