On Thursday, 08/23/2007 at 11:00 EDT, Colin Allinson <[EMAIL PROTECTED]> wrote: > Our procedure is to build the IBM system (2nd level - vanilla) using all the > standard tools. We then do a vendor build, which involves an override disk and > results in a modified CP module using the vendor procedures. This pulls in all > the SES applied updates applied.
That's pretty cool since it requires an analysis of the PTF source update to see if it conflicts with the vendor mods. Physical conflicts (update overlap) are easy. Logical conflicts are harder, depending on the specific mod. If CP is *extended* with new functionality that get loaded dynamically via CPXLOAD and ASSOCIATE commands, then there may be just a recompile and rebuild. > If we have new IBM service we apply that using SERVICE & PUT2PROD (without the > override disk) and then do the vendor build again. > > Any other mods, (local or from any other source), are applied as SES mods on > the localmod disk so they just get included automatically. > > Richard is right that we cannot use SERVICE & PUT2PROD for the updates from > this vendor (but they have a pretty slick process anyway) and the final build > but that does not stop us using them for all other (particularly IBM) updates. OK. I just don't want anyone to mistakenly equate "local mods" with "can't use SERVICE or PUT2PROD". Alan Altmark z/VM Development IBM Endicott
