You violate the ground rules at your peril. If PTF2 has a PRE(PTF1), then let GROUPEXTEND do it's thing. You can use FORCE to install PTF2 alone; not my monkeys not my circus.
Best practice rules are there for a reason. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Mike Schwab <[email protected]> Sent: Sunday, December 7, 2025 9:30 PM To: [email protected] <[email protected]> Subject: Re: ++PTF and REWORK External Message: Use Caution My example was that PTF2 modified PTF1, but a customer has not installed PTF1 and does not want to. On Sun, Dec 7, 2025 at 5:35 PM Jon Perryman <[email protected]> wrote: > On Sun, 7 Dec 2025 09:06:49 -0600, Mike Schwab <[email protected]> > wrote: > > >I'm wanting to learn the possible sequence of PTFs. > > The sequence of a PTF is defined by the creator of that PTF using PRE, > REQ, SUP & more to create PTF, APAR & FMID relationships. While a PTF will > always have relationships, PTF 1 & PTF 2 may not be related and the install > sequence can be random. If you're going to create a PTF, please see the > SMP/e doc but don't make too complicated otherwise you may be forced to > UCLIN, SUP or ??? to fix the CSI. > > PRE = prerequisite PTFs. SMP/e must install PRE before installing this > PTF. > > A PTF contains various components (++MOD, ++PANEL, ++MAC, ...). When you > start changing a source, that source is reserved for you until you complete > the PTF. The original source had a PTF id and that PTF ID is the PRE. Your > PTF becomes the PRE for the next person who modifies that source. > > REQ = corequisite PTFs. SMP/e must install these PTFs but the sequence is > not important. > > The current version of an element is needed for this PTF but does not need > to be modified. > > SUP = supersedes PTFs. The PTF completely replaces all changes in all the > superseded PTFs. > > Most often seen with APARs. An APAR is a temporary fix for a problem that > only a few customers will have installed. SMP/e ignores if the APAR was not > installed. > > >Normal updates would be > >Base + PTF1 (without install) + PTF2 gives good result. > > This depends upon the relationship that has been defined in PTF2. A PRE or > REQ of PTF1 will force the install of PTF1. A SUP of PTF1 will bypass > installing PTF1 if it has not been previously installed. > > >Site with base finds out and wants to avoid PTF1 and install PTF2. > >But PTF2 can't install without PTF1? > > Depends upon the relationships defined in PTF2 > > >Creating PTF3 with 1 and 2 for base won't install on Base + PTF1? > > PTF3 would SUP PTF1 & PTF2 causing SMP/e to ignore the state of PTF1. > > Each PTF is designed to achieve a specific outcome. The most common is a > PTF that has PRE for each element in the PTF and SUP for the APAR (even > when not used). > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
