Re: Old School Maintenance Philosophy -- Never ACCEPT?
I (used to) do something similar with a few added steps: DFDSS dump the whole SMP/E environment ACCEPT CHECK ACCEPT RECEIVE APPLY CHECK (there are sometimes system holds that need addressing before APPLY and this gets the report out as well as doing the APPLY CHECK) APPLY It's probably worth noting that I'm a DB2 SysProg/DBA rather than a z/OS SysProg. The z/OS boys do all the SMP/E work in my current shop. Cheers, Mick. On 24 May 2018 at 05:11, Ed Jaffe wrote: > On 5/23/2018 9:30 AM, Jesse 1 Robinson wrote: > >> Open any IBM doc on SMP(/E) ever published and you will find the same >> canonical procedure: >> >> --RECEIVE >> --APPLY >> --ACCEPT (maybe hold off on this a while, but resolve to do it eventually) >> > > FWIW, I always do it this way: > --ACCEPT > --RECEIVE > --APPLY > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > http://www.phoenixsoftware.com/ > > > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages 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 the > sender for any loss or damage arising in any way from its opening or use. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
On 5/23/2018 9:30 AM, Jesse 1 Robinson wrote: Open any IBM doc on SMP(/E) ever published and you will find the same canonical procedure: --RECEIVE --APPLY --ACCEPT (maybe hold off on this a while, but resolve to do it eventually) FWIW, I always do it this way: --ACCEPT --RECEIVE --APPLY -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages 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 the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
On Wed, 23 May 2018 09:55:04 -0700, Gerhard Adam wrote: >Why bother? Do a RESTORE GROUP CHECK and get that information. No, GROUP doesn't work that way with RESTORE. assume you have applied two PTFs, and one defines the other as the prerequisite. When you select the prerequisite and specify the GROUP operand, SMP/E also tries to restore the other PTF. On the other hand, if you select the SYSMOD that specifies the prerequisite, SMP/E restores that particular SYSMOD only if the prerequisite has been accepted. -- Tom Marchant >> On May 23, 2018, at 9:08 AM, Tom Marchant >> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: >> >> If I want to restore PTF A and RESTORE CHECK tells me that it can't >> RESTORE it because PTFs B, C, and D have not been ACCEPTed, I can >> run ACCEPT CHECK on B, C, and D. That should give me a list of all the >> PTFs that also need to be RESTOREd in order to RESTORE A. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
> On May 22, 2018, at 3:28 PM, Ed Jaffewrote: > > z/OS Sysprogs, > > ISTR a maintenance philosophy from "eons" ago where PTFs would be applied but > never accepted. > > What was the rationale for this? Does anyone still use this philosophy? If > so, why? > > Thanks, > > -- Ed, Long ago and far away we never accepted maintenance as we wanted to be able to back fixes off, This was after the DFP fiasco (mega PTF tape). We were not loathe to change the philosophy but Management seem to cut the number of sysprogs so we started to not accept PTF’s (unless there was a need). Management kept cutting and the acting got delayed and delayed and then forgotten. I won’t say it was because of management 100 percent but 95 percent. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
>ISTR a maintenance philosophy from "eons" ago where PTFs would be >applied but never accepted. It's not my dog. > What was the rationale for this? Urban legends? 4 roses? >Does anyone still use this philosophy? If so, I don't want to know. The only case where it might make sense was for JES2 back when the consistently had packaging errors in their service. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion Liston behalf of Ed Jaffe Sent: Tuesday, May 22, 2018 4:28 PM To: IBM-MAIN@listserv.ua.edu Subject: Old School Maintenance Philosophy -- Never ACCEPT? z/OS Sysprogs, ISTR a maintenance philosophy from "eons" ago where PTFs would be applied but never accepted. What was the rationale for this? Does anyone still use this philosophy? If so, why? Thanks, -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://secure-web.cisco.com/1fsB4sUhPWP49AqaQ7Z_q84p-TXhvVzfBjsIXmwRuTGM4kZ23CdeDfT_aGviLMajJ7mWHOP_ULS4KAhrlje2S7HdZhbAF6w2-3NKDNZMLPNkIT8hGbc_gk7rgf4XhGNS1tDN_p_Suu80ToiJ9MNWWdzv8B173amuMCcfpHJEAFQXeBWM7CXqxOfegtKa6UtYm4IlIAgxFcdW4EVzcXUI4OYT4VuZY101nCpDkYHr4xy0JINdkp-on2vFI6F1A7HEIGF5fALbPyXsVon5MugosmP2_UzAzCn0QTYmpS4hd9gPdKtrfsQ_IlC00TtcOInh6QSVTls86YQD94xsXxupgza6OIRV_0PwulPbwHeivfqJbUJlCEC4D-OuM4W4S6ShEaedY336qvMsqKDweufrJEMMVVYo-EzBqdpnYOjfxla94eGQoH1FjdPxxG2HImS1g/http%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages 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 the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
Never accept what? The advice to never accept an APAR or USERMOD is sound. The advice never to accept a PTF - it's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Allan Staller <allan.stal...@hcl.com> Sent: Wednesday, May 23, 2018 8:49 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Old School Maintenance Philosophy -- Never ACCEPT? "never accept" because there might be "bad" maintenance in the stream. If you have been running on the "new maintenance" for xx months, what can be "bad"? I agree w/Tom Conley. It was wrong then (even if well intended). It is still wrong. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, May 22, 2018 5:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Old School Maintenance Philosophy -- Never ACCEPT? On 5/22/2018 1:49 PM, Allan Staller wrote: > I haven't used that philosophy in 30+ years. What was the rationale 30+ years ago? Do you remember why things were being done that way? Thanks, -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1UQ7-7D9XBwR1qCx3aiNIShyb0c2RaZdkHhbVCRk2rp9c4x0rSKhLU1Hz5Xj0ahaYKuYDUShzYIJjtR2Gj0dHQ0ZnIgtMS4d0hXUKfpGp78VydHJ75f5MUY8LFbMprU1dpfSdqekPOr9NxxC2bTRwKTVMaMyKCZqam4gfwEx3g7zVZP2a_WVJpjOpDlowCJaLnZ5M-J2xit4_C0rX9Nf6eztGVQIbF_yTpLZP_JuM0AidsuNbTlt8x4LRUCbshs3p-4t0MBfGOkxRRld1dLTr-ltKWWV7Jqd4NaAMTUzx6rLJofMXZhB4ED2XlOzLXFYJCez_6kij4kk5HbtrxEFu_RC6b7fpWN0FAtf81eZcCQHuTUMHEXZLoxVHrKbH3lNx1CfLpuaavO8lqupc0dYfGmllZFfiplx9NIb9kJGV1L-RnwQ0d3Tn5YxZCwmanE5n/https%3A%2F%2Fapac01.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fwww.phoenixsoftware.com%252F%26data%3D02%257C01%257Callan.staller%2540HCL.COM%257C0a9bd16e74284d053ffe08d5c03411e4%257C189de737c93a4f5a8b686f4ca9941912%257C0%257C0%257C636626252258061200%26sdata%3DRplEGhGyPWTc5cVIUJkB6EAo3h2uTX8R9ErgpA0OyfA%253D%26reserved%3D0 This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages 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 the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attach
Re: Old School Maintenance Philosophy -- Never ACCEPT?
On Wed, 23 May 2018 11:08:32 -0500, Tom Marchant wrote: >On Wed, 23 May 2018 10:07:16 -0400, John Eells wrote: > >>As others have pointed out, it makes RESTORE a lot harder if you never >>ACCEPT PTFs. > >I haven't had the need to do this yet, but I have an idea that I think will >make it much easier. > >If I want to restore PTF A and RESTORE CHECK tells me that it can't >RESTORE it because PTFs B, C, and D have not been ACCEPTed, I can >run ACCEPT CHECK on B, C, and D. That should give me a list of all the >PTFs that also need to be RESTOREd in order to RESTORE A. I meant to say ACCEPT CHECK GROUP on B, C, and D. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
Why bother? Do a RESTORE GROUP CHECK and get that information. Sent from my iPhone > On May 23, 2018, at 9:08 AM, Tom Marchant > <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >> On Wed, 23 May 2018 10:07:16 -0400, John Eells wrote: >> >> As others have pointed out, it makes RESTORE a lot harder if you never >> ACCEPT PTFs. > > I haven't had the need to do this yet, but I have an idea that I think will > make it much easier. > > If I want to restore PTF A and RESTORE CHECK tells me that it can't > RESTORE it because PTFs B, C, and D have not been ACCEPTed, I can > run ACCEPT CHECK on B, C, and D. That should give me a list of all the > PTFs that also need to be RESTOREd in order to RESTORE A. > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
I would go so far as to assert that there was never a 'no-ACCEPT policy', only an ad hoc practice advocated by what I always thought were outliers. Open any IBM doc on SMP(/E) ever published and you will find the same canonical procedure: --RECEIVE --APPLY --ACCEPT (maybe hold off on this a while, but resolve to do it eventually) Having never given no-ACCEPT serious consideration, I can't speak for its motivation. I suspect that it was a combination of (misguided) RESTORE concerns and a sense that ACCEPT represents wasted cycles--CPU and bioware. Some may have believed that the whole DLIB environment entailed unnecessary DASD space. When DASD became radically cheaper--and people became more expensive--no-ACCEPT may have looked like a penny saved. I personally think that's false economy. ACCEPT, besides stuffing a lot of data into distribution libraries, also performs SMP/E cleanup. Until ACCEPT, RECEIVEd sysmods remain in the PTS, which grows insidiously like the Blob over the life of each FMID. Likewise TLIBs, which hold the verbatim content of all sysmods, are not deleted until ACCEPT (if then--it's optional). Having said all that, I suspect that there are still Never ACCEPTers out there who are unlikely to change their ways. I'm guessing that OP Ed Jaffe is looking at this issue from the perspective a software supplier. It's hard to imagine that the owners of SMP/E will ever alter the recommended procedure. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Wednesday, May 23, 2018 8:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? I also don't recall a "never ACCEPT" policy. That would be silly because it becomes a "never RESTORE" policy. Sent from my iPhone > On May 23, 2018, at 7:08 AM, David L. Craigwrote: > >> On 18May23:1247+, Pommier, Rex wrote: >> >> Not sure how long ago eons was, but I started in the mid-80s on >> MVS/SP and at my first SMP/E (and I believe >> only) class, I was taught the APPLY / run for a while / ACCEPT usage >> - except for USERMODs or APARs that hadn't had a published PTF yet. > > I learned to use SMP back on MVT (am I the only one still here that > can truthfully make that statement?) and while it's been a while since > I last used SMP/E, I do not recall ever encountering a no ACCEPT > policy for any IBM MRM. > But people aren't mentioning policy for archiving snapshots of target > and DLIB volumes and restoring therefrom--much faster than reAPPLYing > LOTS of maintenance. That also requires tracking the target/DLIB > volume snapshot associations, which are not necessarily based upon the > dates of the snapshots. > -- > > May the LORD God bless you exceedingly abundantly! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
On Wed, 23 May 2018 10:07:16 -0400, John Eells wrote: >As others have pointed out, it makes RESTORE a lot harder if you never >ACCEPT PTFs. I haven't had the need to do this yet, but I have an idea that I think will make it much easier. If I want to restore PTF A and RESTORE CHECK tells me that it can't RESTORE it because PTFs B, C, and D have not been ACCEPTed, I can run ACCEPT CHECK on B, C, and D. That should give me a list of all the PTFs that also need to be RESTOREd in order to RESTORE A. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
As others have pointed out, it makes RESTORE a lot harder if you never ACCEPT PTFs. Why? To RESTORE, SMP/E requires the needed levels of the parts to be in the DLIBs. Here is a simple example. Suppose you have Part A, and the DLIB level of Part A is 001. You have installed six PTFs that replace Part A, so now the target level of Part A is, in this example, 007. There's a problem with the last PTF, and either the PE fix is not available or perhaps you're not comfortable with its age. So, you want to take off just the last PTF that replaced Part A. But, SMP/E does not have level 006 of part A in the DLIB, it has level 001. So, you must either back off all six PTFs to back off the last one, and then put five of them back, *or* ACCEPT the first five before backing off the sixth. In the first case, SMP/E restores Part A back to level 001, and then updates it to 006. In the second (after the ACCEPT for the first five PTFs), it simply restores Part A to level 006. Now, think about what happens with PTFs that PRE and IF other PTFs, and those that ship overlapping multiples of some parts. This stuff can get really complicated to untangle, fast. The RESTORE process tends to be iterative, and can be quite time-consuming, if you never or rarely run ACCEPT. So most thoughtful people, after seeing how this all works, decide how far forward to ACCEPT, and when, and do it as a matter of course to keep the plate of sticky spaghetti down to a manageable level of complexity in case they have to RESTORE a PTF later on. I hate stories that start with "when *I* did that," but I'll tell one anyway. We used to ACCEPT all non-PE PTFs ahead of each preventive service cycle, which seemed to keep it under control reasonably well because we did it quarterly (which is now pretty much the current recommendation, as it happens). If you do it less often, the amount of applied but not accepted service will be greater, and the chains to be resolved before RESTORE will be correspondingly more complex. You might want to ACCEPT by PTF age (PUT) in that case, for example. Other people have other strategies, but you should think about the complexity of RESTORE preparation and the time it will take if you have to RESTORE a PTF to resolve a severe problem. Also, not running ACCEPT on some regular basis makes your SMPPTS data sets grow forever, though this is a far smaller concern today than it was historically. This is the current state of SMP/E RESTORE processing. The requirement to "Please, *please* just let me take off this PTF and anything that PREs or IFs it without having to figure this stuff all out" is, believe me, *very* well understood. In other words, more RFEs won't hurt, but neither will they help much. Ed Jaffe wrote: z/OS Sysprogs, ISTR a maintenance philosophy from "eons" ago where PTFs would be applied but never accepted. What was the rationale for this? Does anyone still use this philosophy? If so, why? Thanks, -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
"never accept" because there might be "bad" maintenance in the stream. If you have been running on the "new maintenance" for xx months, what can be "bad"? I agree w/Tom Conley. It was wrong then (even if well intended). It is still wrong. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, May 22, 2018 5:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Old School Maintenance Philosophy -- Never ACCEPT? On 5/22/2018 1:49 PM, Allan Staller wrote: > I haven't used that philosophy in 30+ years. What was the rationale 30+ years ago? Do you remember why things were being done that way? Thanks, -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.phoenixsoftware.com%2F=02%7C01%7Callan.staller%40HCL.COM%7C0a9bd16e74284d053ffe08d5c03411e4%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636626252258061200=RplEGhGyPWTc5cVIUJkB6EAo3h2uTX8R9ErgpA0OyfA%3D=0 This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages 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 the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: Old School Maintenance Philosophy -- Never ACCEPT?
Or you restore A and B and reapply A. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, May 22, 2018 6:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Old School Maintenance Philosophy -- Never ACCEPT? On Tue, 22 May 2018 16:51:01 -0400, Tom Conley wrote: >On 5/22/2018 4:26 PM, Ed Jaffe wrote: >> >> ISTR a maintenance philosophy from "eons" ago where PTFs would be >> applied but never accepted. >> >> What was the rationale for this? Does anyone still use this philosophy? >> If so, why? > >There is no rationale. It was wrong then, and it's wrong now. It >kneecaps the most valuable feature of SMP/E - RESTORE! Unless, of >course, you like RESTOREing the entire FMID. > OTOH, doing ACCEPT kneecaps the possibility of a RESTORE to a point earlier than that ACCEPT. SMP/E strikes me as a half-hearted design. A better design would permit RESTORE to any prior service level provided the necessary elements remain in the GLOBAL zone. Suppose you have two suspect PTFs, A and B. In order to tentatively RESTORE B you must ACCEPT A. If RESTORE B doesn't solve the problem there's no posibility to RESTORE A. I believe VMSES/E does better. It has no analogue of ACCEPT. VMFREMOV simply re-installs needed components from the DELTA disk, the analog of the GLOBAL zone. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
I think people used to install their local usermods that way. I don't remember that ever being the norm for PTF's though. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
On 5/22/2018 7:37 PM, Paul Gilmartin wrote: On Tue, 22 May 2018 16:51:01 -0400, Tom Conley wrote: On 5/22/2018 4:26 PM, Ed Jaffe wrote: ISTR a maintenance philosophy from "eons" ago where PTFs would be applied but never accepted. What was the rationale for this? Does anyone still use this philosophy? If so, why? There is no rationale. It was wrong then, and it's wrong now. It kneecaps the most valuable feature of SMP/E - RESTORE! Unless, of course, you like RESTOREing the entire FMID. OTOH, doing ACCEPT kneecaps the possibility of a RESTORE to a point earlier than that ACCEPT. SMP/E strikes me as a half-hearted design. A better design would permit RESTORE to any prior service level provided the necessary elements remain in the GLOBAL zone. Suppose you have two suspect PTFs, A and B. In order to tentatively RESTORE B you must ACCEPT A. If RESTORE B doesn't solve the problem there's no posibility to RESTORE A. I believe VMSES/E does better. It has no analogue of ACCEPT. VMFREMOV simply re-installs needed components from the DELTA disk, the analog of the GLOBAL zone. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN There is a way to RESTORE prior to the ACCEPT. You need to BACKUP your entire SMP/E environment, then restore it. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
On Tue, 22 May 2018 16:51:01 -0400, Tom Conley wrote: >On 5/22/2018 4:26 PM, Ed Jaffe wrote: >> >> ISTR a maintenance philosophy from "eons" ago where PTFs would be >> applied but never accepted. >> >> What was the rationale for this? Does anyone still use this philosophy? >> If so, why? > >There is no rationale. It was wrong then, and it's wrong now. It >kneecaps the most valuable feature of SMP/E - RESTORE! Unless, of >course, you like RESTOREing the entire FMID. > OTOH, doing ACCEPT kneecaps the possibility of a RESTORE to a point earlier than that ACCEPT. SMP/E strikes me as a half-hearted design. A better design would permit RESTORE to any prior service level provided the necessary elements remain in the GLOBAL zone. Suppose you have two suspect PTFs, A and B. In order to tentatively RESTORE B you must ACCEPT A. If RESTORE B doesn't solve the problem there's no posibility to RESTORE A. I believe VMSES/E does better. It has no analogue of ACCEPT. VMFREMOV simply re-installs needed components from the DELTA disk, the analog of the GLOBAL zone. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
On 5/22/2018 1:49 PM, Allan Staller wrote: I haven't used that philosophy in 30+ years. What was the rationale 30+ years ago? Do you remember why things were being done that way? Thanks, -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages 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 the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
On 5/22/2018 4:26 PM, Ed Jaffe wrote: z/OS Sysprogs, ISTR a maintenance philosophy from "eons" ago where PTFs would be applied but never accepted. What was the rationale for this? Does anyone still use this philosophy? If so, why? Thanks, FYI, There is no rationale. It was wrong then, and it's wrong now. It kneecaps the most valuable feature of SMP/E - RESTORE! Unless, of course, you like RESTOREing the entire FMID. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old School Maintenance Philosophy -- Never ACCEPT?
I haven't used that philosophy in 30+ years. Install maintenance. Let it run until time for next round of maint. Accept "old maint" Install next round of maint. Reason: PTF chains in the event of a need to restore. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, May 22, 2018 3:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Old School Maintenance Philosophy -- Never ACCEPT? z/OS Sysprogs, ISTR a maintenance philosophy from "eons" ago where PTFs would be applied but never accepted. What was the rationale for this? Does anyone still use this philosophy? If so, why? Thanks, -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.phoenixsoftware.com%2F=02%7C01%7Callan.staller%40HCL.COM%7C2b559369bc9242c570f608d5c0229754%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636626177197737157=1QJPU5ft%2F11FiJYNl2xkh3zVds1kFBggw4j0pDwK%2FUk%3D=0 This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages 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 the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN