I can show you my scars from an unplanned IPL last June caused by an SMSPDSE failure:-( See APAR OA15185. Still I think my opinion of PDSE is much more positive than yours. From our experience I can suggest a few things.
If you are at z/OS R6 or higher consider use the restartable SMSPDSE address space. Install recommended service (ask IBM PDSE Level 2) and implement the Partitioned Data Set Extended Restartable Address Space (SMSPDSE1) which is a feature that was available at z/OS R6. http://www.redbooks.ibm.com/abstracts/tips0531.html Implement private storage monitoring for SMSPDSE end critical address spaces. We use CA-SYSVIEW 11.5 and RMF doing this for NETSPOOL FSS tasks, CICS Temp Storage regions, DB2 production DBM1 asids, SMSPDSE, SMSPDSE1 and a few others who push the limits of what we can make available in PVT/EPVT or have had a past history of private area storage problems. We have had some discussions with IBM but have not yet completed the requisite virtual paperwork to open a marketing request to allow for the existing PDSE storage monitoring to be extended to monitor it's own private storage. When I do that I will post the request # back into this thread so others can reference it. In general PDSE is a 'Good thing'! Using PDSE has allowed us to solve a host of performance problems and avoid extra data set management steps with in house and OEM software and it has been quite reliable in it's current incarnation save the one incident last year. I certainly consider PDSE handled correctly to not be anymore of an integrity problem than VSAM, IMS database, DB2 database, etc. We have 3671 PDSE data sets sitting in our normal DASD pools as of this morning and we don't have problems with them. Quite the contrary PDSE is the default when we reallocate some libraries in our Endevor environments. Typically when we get an x37 problem with a PDS the first thing someone says is 'We should take time to reallocate all of the xyz libraries as PDSE...' GEICO worked with PDSE when it was first introduced (DFP 3.2 and some flavor of MVS/ESA IIRC) and it was not ready for heavy lifting back then. We had issues especially with large PDSE data sets used by many address spaces with PDSE sharing and corruption. IBM PDSE developers have done a lot since then with some good plans for the future based on presentations at SHARE and other public forums. My experience was that from DFSMS 1.1 on PDSE has really matured enough to use for any critical function you would use a PDS for save a few minor documented restrictions. PDSE here is doing just fine every day. I used it and other native DFSMSdfp functions to save over $200K for a software package proposed by an outside firm to solve a performance problem about two years ago. If anyone is avoiding PDSE based on old FUD you are doing yourself and your employer no favors. A final thought is that running so lean and mean that finding 1/2 of a CP suddenly occupied results in failure to meet business objectives is a good argument to provision sufficient capacity for problems. WLC charging and capping can be used to insure you don't use or pay for all installed capacity. Capacity can be available on demand with CBU or CUoD. There was a good article "Always there when you need z: Top ten best practices for near continuous availability" BY HARRIET MORRILL One of the ten practices was to provide enough capacity to handle the unexpected. http://publibz.boulder.ibm.com/epubs/pdf/e0z2n170.pdf Lesson 7: Regularly adjust capacity to protect peak needs People think of capacity as a performance issue, but capacity and performance are availability issues. Slowdowns can be viewed as a type of outage. Additionally, backup systems require extra capacity to carry on the work of a failing one. From a capacity perspective, experience teaches us that as soon as a system is set in place, it is obsolete. Typically utilization goes up. Best-of-breed clients monitor capacity regularly and add it when needed to be sure that adequate failover capacity is maintained over time. They exploit System z9 concurrent upgrade and downgrade capabilities. Good Luck! Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 The History of every major Galactic Civilization tends to pass through three distinct and recognizable phases, those of Survival, Inquiry and Sophistication, otherwise known as the How, Why and Where phases. "For instance, the first phase is characterized by the question 'How can we eat?' the second by the question 'Why do we eat?' and the third by the question 'Where shall we have lunch?' -----Original Message----- From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL Sent: Thursday, March 22, 2007 5:45 PM To: [email protected] Subject: Re: Start of a PDSE rant was Re: OA03767 PDS/E Restriction >So much for the "new PDS" idea. We just recovered from a problem due to PDSE's. Production libraries that are staged in development and used in production are PDSE's. SMSPDSE abended with a 40D. The communication from that LPAR for integrity purposes blew XCFAS from single digit usage (omegamon reported) to 60%+. We run lean and mean; this got VERY mean. Even dropping the development LPAR out of the picture didn't help. XCFAS on the production LPAR is still chewing cycles. And, this won't be fixed without an IPL. Can't happen until sat night. And, yes, IBM is engaged. ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. ---------------------------------------------------------------------- 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
