On Fri, Mar 17, 2017 at 8:50 AM, Kurt Quackenbush <[email protected]> wrote:
> On 3/16/2017 7:25 PM, Gibney, Dave wrote: > >> Has this always been so? Sometime ago (1.7, 1.9) I had ACCEPT fail >> because I had compressed and moved members into lower sequenced >> SMPPTSn At least I think I remember this. I've just always added >> another SMPPTSz ever since. >> > > Yes, ever since we added the SMPPTS spill data set function (year 2000) > SMP/E has allowed you to merge data sets, move PTFs from data set to data > set, add data sets, whatever you want to do, as long as the SMPPTSnn DDDEF > entries in your global, target, and dlib zones point to your current set of > SMPPTS data sets. > > Kurt Quackenbush -- IBM, SMP/E Development > > I will mention that, at least for me, I have found that SMP/E always goes "in order". That is: SMPPTS, SMPPTS1, SMPPTS2, ... . So when I create a _new_ SMPPTS library, I always create a new SMPPTSn definition, copy the DSN in the SMPPTS definition to the new SMPPTSn, and put the new DSN in the SMPPTS definition. What I found this accomplishes is that the RECEIVE will put the newly received MCS into the new DSN (defined in SMPPTS). If I don't, I get a series of x37-04 type abends until SMP/E selects a DSN in the "earliest" SMPPTS? definition which has enough space to satisfy the RECEIVE. The same logic goes when doing other things, such as APPLY. I searches the SMPPTS? definitions in order until it finds the correct member. That is, just as you'd expect if the DSNs were concatenated to a single DD in SMPPTS? order. -- "Irrigation of the land with seawater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
