At any given time, we seem to have a some PTFs--a cupful, not a bucket load--that should not be in the GLOBAL zone at all. They are for product releases that have already been superseded. For example, at the moment we have in RECEIVE status PTF UA58781 PTF for FMID HENV54B dated 11.157. This is IBM Tivoli NetView Base 5.4. But that has been SUPed by release 6.1, which we installed on top of the R13 ServerPac. As far as I know there is nothing wrong with this PTF, but SMPE will never attempt to APPLY it because there is no longer a matching FMID in the CSI.
I should probably go through the GLOBAL, identify all of these forlorn lost souls, and put them out of their everlasting misery via REJECT. Ah, so many loose ends, so little time. I'd rather work on the ends I can weave into something useful. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Ed Gould <edgould1...@comcast.net> To: IBM-MAIN@LISTSERV.UA.EDU, Date: 02/06/2014 02:30 PM Subject: Re: Dumb SMPE question Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> Dave: Interesting reply. This is old information but it still applies IMO. I was applying TSOE CBPDO and ended up with 2400+ PTF's that wouldn't go on. I would never have gotten the product to apply if I had done the exclude list route. The root cause was a missing VTIOC(?) ptf and the 2400+ ptf's and the base would never have gone on. (it was a CBPDO packaging issue). The idea of building exclude list seems counter productive (to me). I have only done so when I needed one PTF on and the pre list was healthy. I am not suggesting it never be done but once in a while t seems necessary. Ed ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
