On Mon, 1 Dec 2014 13:49:37 -0600, Ed Gould wrote: > >We didn't have the DASD space at the time (we needed a few extra >volumes for maintenance and they were being used by another >application). We were in a DASD constrained environment. > Is there a further performance concern in that if the user wants to APPLY a single PTF (plus what GROUPEXTEND brings along), the user will spend network bandwidth to download everything; CPU cycles to un-pax everything; space in SMPNTS and SMPWKDIR; and more CPU cycles to pass a needlessly large SMPPTFIN? (All assuming the customer is in a hurry for an urgent PTF and is willing to defer the other stuff until later.)
Beyond those performance concerns, APPLY SELECT() GROUPEXTEND should suffice. Some years ago, a contributor to this list used the notion of "The Great SMPPTS in the Sky", his vision being that APPLY should access that cloud and transfer and unpack only the PTFs needed according to SELECT() GROUPEXTEND. The RECEIVE command, a relic of tape processing, would simply vanish. It remains an unfulfilled wish. >On Dec 1, 2014, at 8:49 AM, Kurt Quackenbush wrote: >> >> (I know I'm going to kick my self for responding, but...) >> Why didn't you want PTFs for other FMIDs received? What's the >> harm? You'll need them eventually, right? Because you will >> eventually update all the other FMIDs with service during a >> maintenance cycle, right? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
