On Thu, 21 Aug 2025 09:30:31 -0500, Peter Vander Woude <peter.vanderwo...@kroger.com> wrote:
>The challenge with these large ptf's is that they are >large due to the nature of how IBM delivers java, websphere liberty, etc, I'm astonished that after 30 years of z/OS Unix, this problem still has not been addressed. Actually, the challenge is getting these products out of their Unix mindset. Not one of these products has bothered to understand SMP/e packaging. >I do run into this, quite a bit. Of course, you run into this because no one complains and demands solutions. 30 years of z/OS Unix and it sounds like these products still have the same packaging problems. These products ignore important SMP/e key features. Fine, these products need insanely large PTFs but after 30 years, why are they still causing people grief? >For these large ptf's, I will go down to applying at the FORFMID level. SMP/e has a robust set of tools available. In automation, we now have ++HOLD REASON(AO) so you can easily know when messages have been changed and added. Where is the ++HOLD REASON(INSANELY-LARGE-PTF) so that you don't jump through hoops to apply these PTFs separately. It takes 2 seconds to add ++HOLD. For these products, they could add it to their PTF generation and never think about it again. It's easier to run apply check than being forced to run APPLY FORFMID for products that may not have any PTFs. > I don't think PTF's can use RELFILE. PTFs definitely support RELFILE. Some large files are unacceptable in SMPPTS regardless of if it's in an FMID or PTF. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
