So what if you have a very large environment that has many usermods, if you do not do regular accepts, it becomes almost impossible to do a restore, depending on the chain, in-order to apply normal ptfs. The other gotcha is if IBM writes an APAR1+APAR2 to fix an issue and then requires a restore in between and/or if they decide to NOT SUP the apar, your PTF chain of restore is could be another nightmare.
Thanks Ms. Terri E. Shaffer [email protected] Engineer J.P.Morgan Chase & Co. GTI DCT ECS Core Services zSoftware Group / Emerging Technologies Office: # 614-213-3467 Cell: # 412-519-2592 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Ed Gould Sent: Saturday, April 30, 2011 4:06 PM To: [email protected] Subject: Re: SMPPTS run out of Space (another approach) Paul: AT one place where I worked. We never did an accept either. What we did was a selective apply (to fix one problem). We would make a copy of the LMOD involved and then do an apply to the "maintenance" pack. We then did a copy replace of the LMOD to the new (temp) res pack. IPL and run with that for some time (depended on some variable). We very rarely applied maintenance to more than one LMOD (isolation and backout was our concern). Of course this was 15 years ago and the need for large PTS's wasn't there. We also kept current on maintenance (some time bleeding edge) on some FMID's (PSF and JES2 and TSO/e) . We were an essentially small shop and we knew how to backout each others fixes. I won't comment on CICS as the person who did it was in another solar system. The only time we got burned was with a vendors software that did not keep current with IBM's maintenance. We had to back it out and I never trusted the vendor again (even to this day). I will omit the name of the well known vendor. Ed ps: SMPe's backout was just a PITA as far as I was concerned. a few times I tried to back out a PTF, SMPE would always need a different backout than what we had put on. I gave up trying to understand it. ________________________________ From: Paul Gilmartin <[email protected]> To: [email protected] Sent: Sat, April 30, 2011 2:47:24 PM Subject: Re: SMPPTS run out of Space (another approach) On Sat, 30 Apr 2011 10:41:10 -0700, Dick Bond wrote: >*Exactly! *This is the correct way of doing RSU**** maintenance upgrades. >It also solves some of the objections to the way RESTORE works as well. >There are those who say they never ACCEPT maintenance which will cause a lot >of problems which is then attributed to poor SMP/E design. SMP/E is the >best thing since bacon-and-eggs if used properly. > Complete with the LDL cholesterol. An ideally designed SMP/E would have no need for ACCEPT. Simply, the systems programmer should be able to restore any previous service level. It should be a multi-level UNDO. I suppose this could be done by taking a flash copy of the entire CSI after each individual PTF and eschewing ACCEPT. ACCEPT creates an undesirable firewall. If I wish to RESTORE to a particular level, I must ACCEPT to that level, then I can never RESTORE to an earlier level. Our testers don't bother with ACCEPT. They take frequent backups and preserve them indefinitely. Then if a particular service level is needed for problem recreation, they restore (in the sense of DFSMS, not of SMP/E) the service level needed. Similarly, for the testing I need to do, it's easiest for me to create a new CSI; install the product, and add PTFs to taste. The practice terrifies some of our developers. -- gil ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. ---------------------------------------------------------------------- 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
