Mike:
In this case, PTF2 would have to supersede PTF1. Otherwise PTF2
would have to pre-req PTF1 so it could be installed.
With the customer not wanting PTF1, they have no way to install
PTF2 via SMPE, short of "forcing it" which is typically a bad idea.
For instance, they could create their own PTF1, that is "empty".
But this could create new problems later. [usually such a
customer thing is a USERMOD....]
Welcome to the world of supporting customers and some of the
things they want....... BTDT.
Regards,
Steve Thompson
On 12/7/2025 9:30 PM, Mike Schwab wrote:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
