I'm all about cutting extraneous corners, but some corners may object by cutting back. I looked at Ed Webb's pitch, which reads like a developer's anthem. Ed sums up his environment this way: users exist to provide a test load. Fair enough for his shop, and I assume for yours also. But my users exist to pay the bills--including my salary--and therefore have the right to be a little more picky.
I have no rebuttal to the idea of APPLYing maintenance to a running system. Yikes. But skipping the CHECK phase seems like a savings far smaller than the gamble it puts on the table. Without checking the archives, I seem to remember your reporting a recent problem with two Java PTFs that had an unhealthy interaction with each other. (Thanks for the heads up by the way. It put me on guard for the same problem shortly afterwards.) But I was puzzled by your statement that SMP/E did not catch a missing PTF until after it had lumbered through the other one, leaving you with a broken install, which took a lot of trouble on your part to straighten out. Would not APPLY CHECK have revealed the missing PTF before any real harm had been done? If not, then never mind. But if so, then I would say that the sum of all the pro forma time and effort saved by skipping CHECKs pale in comparison with the time and effort expended to fix this one problem. Just an idea. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Edward Jaffe <edja...@phoenixsoftware.com> To: IBM-MAIN@LISTSERV.UA.EDU Date: 10/06/2012 08:48 AM Subject: Re: SMP/E question Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> n 9/6/2012 8:31 PM, Skip Robinson wrote: > I have never understood the fixation with rock bottom return codes. SMP/E > maintenance is so much simpler without agonizing over every uneven > cobblestone along the path. LOL. You have provided an excellent description of, what I consider to be, the most logical way to use SMP/E. Unless you're trying to fix a specific problem with a specific PTF, just put on the service that goes on smoothly and leave everything else alone. Don't sweat the details! As a part-time sysprog, I abbreviate your approach even more. I have no time for pesky 'CHECK' operations. I submit a job that does an ACCEPT for all 14 DLIB zones we actively maintain. Space problems and the like are corrected and the job resubmitted if necessary (usually not). I then submit the job that does an APPLY for all 14 actively-maintained target zones. Again, space problems etc. are corrected and the job resubmitted if necessary. The whole thing usually takes about an hour when there are no space or other issues. Then we conduct a rolling IPL. Oh, and did I mention that this is done on a LIVE system? We have no time or personnel to 'clone' systems, switch between res packs, etc. for regular maintenance. Our philosophy is similar to that described by Ed Webb at SHARE in Anaheim in session 11581: A Different Way to Perform z/OS Maintenance. https://share.confex.com/share/119/webprogram/Handout/Session11581/A%20Different%20Way%20to%20Perform%20zOS%20Maintenance.pdf -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
