On Sun, 7 Dec 2025 20:30:35 -0600, Mike Schwab <[email protected]> wrote:
>My example was that PTF2 modified PTF1, but a customer has not installed >PTF1 and does not want to. PTFs cannot modify PTFs. A PTF is a set of rules (++ statements) and elements (e.g. ++mod) that are full replacements. Consider the situation where you have 1 ISPF panel and 4 REXX execs that use the ISPF panel. The following PTFs will be installed in sequence but because of SUPs in PTF4, you can exclude PTF2 and PTF3. Despite excluding these PTFs, their functionality is installed as part of PTF4. It makes no difference if PTF2 and PTF3 are included or excluded. You modified REXX1, REXX2, REXX3, REXX4 and ISPFPNL and create PTF1 for the changes: ++PTF( PTF1 ) . ++PANEL( ISPFPNL ). ++REXX( REXX1 ) . ++REXX( REXX2 ) . ++REXX( REXX3 ) . ++REXX( REXX4 ) . Now you modify REXX2 and ISPFPNL. PTF1 is a PRE because we tell SMP/e to completely replace ISPFPNL which include the panel changes from PTF1. SMP/e does not support selectively changing lines specific to PTF2 and will only perform complete element replacement. You cannot bypass PTF1 because the ISPFPNL changes in PTF1 are part of this PTF but ISPFPNL will not work correctly when using REXX1, REXX3 & REXX4. ++PTF( PTF2 ) PRE( PTF1 ) . ++PANEL( ISPFPNL ). ++REXX( REXX2 ) . Now you modify REXX1. PTF1 is a PRE because of REXX1. ++PTF( PTF3 ) PRE( PTF1 ). ++REXX( REXX1 ) . Now you modify REXX1, REXX2, REXX3 and ISPFPNL. Notice everything in PTF3 is in this PTF which means we can either PRE or SUP PTF3. Same for PTF2. As for PTF1, we see REXX4 is not part of this PTF and therefore must be a PRE. For a SUP, SMP/e does not tell you that PTF2 and PTF3 have been installed. If you look at PTF2 and PTF3 in the target zone, they show as installed by SUP. ++PTF( PTF4 ) PRE( PTF1 ) SUP( PTF2, PTF3 ) . ++REXX( REXX1 ) . ++REXX( REXX2 ) . ++REXX( REXX3 ) ++PANEL( ISPFPNL ) . Notice PRE and SUP are for the entire PTF instead of for each element. We could code PTF1 and PTF2 in such a way that they are independent but then it becomes so confusing that screwups would be inevitable. In PTF2, we would need to remove PTF1 ISPFPNL and REXX2 changes until PTF1 is installed and we would need to code PTF1 in such a way that it integrates into PTF2. This would involve additional PTFs but I don't believe anyone wants more PTFs. You want the ability to install PTF2 without installing PTF1 but realize this increases the QA permutations by magnitudes. Consider the situation where REXX1 has been changed by 10 PTFs and you write a new PTF for REXX1. Currently QA runs tests once for PTF11. If as you suggest PTF11 did not require PTF1 thru PTF10, then each combination would need QA validation which increases QA tests by 11 factorial (11*10*9*...*1). QA staff would outnumber the rest of the staff. Support & QA become far too complex. While customers find installing 10 PTFs inconvenient when they only wanted PTF11, remember that they demand stability over inconvenience. SMP/e is a great compromise when you consider that Unix requires you install a new release when all you wanted was 1 thing fixed and you would need to test the entire product instead of 11 well documented changes. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
