On Thu, 17 Nov 2016 10:46:37 -0500, Kurt Quackenbush wrote: >> I don't believe PTFS using IEBUPDTE can be RESTORED. > >Why do you believe this? Of course PTFs containing ++MACUPD or ++SRCUPD >can be RESTOREd. > I stand corrected. I misled myself by my (mis-)understanding of our own development process. Several developers perform integration testing in a common, very volatile CSI. SYSMODs are ACCEPTed only at the point at which they are passed downstream to EVT. I've learned several things to my dismay:
o APPLY REDO doesn't always undo the side effects of the prior APPLY. I suspect this is particularly true if the SYSMOD contains ++*UPD or ++ZAP or if the newer version contains fewer CSECTs than the previous and this is what I misremember as "can't RESTORE". o RECEIVE with a higher REWORK value doesn't always undo the side effects of the previous RECEIVE. Our scripts always REJECT before RECEIVE and ignore failure. (Is there a better way to test whether a SYSMOD has previously been RECEIVEd and bypass the REJECT if it has not?) On a very few occasions, a CSI has gotten so damaged that I have needed to reinstall the base and all current service. Our developers cringe: "How would this play in a customer shop?" It's no problem if the offending PTF has not been released to field. Such complexities impel my wish that LINK LMODS could appear in MCS. And that a SYSMOD containing LINK LMODS could be RESTOREd. (Grass is always greener ...? -- Colorado joke.) How do my colleagues deal with such things? One CSI per developer isn't prohibitive, but often those developers want to test SYSMOD interactions. But as SMP/E supports source updates, it's disappointing that the more flexible patch(1) isn't available as an alternative to IEBUPDTE. And that APPLY REDO doesn't reverse the (putative) prior patch. --gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
