On 2017-03-17, at 08:01, John McKown wrote: > > 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. > There's some argument here for a design that would instead search the DDDEFs in reverse order, newest first.
Or, the prudent programmer might provide extra DDDEFs, to anticipate the need to spill, identifying empty directories until needed. Shuffle symlinks? UNIX needs /dev/emptydir, analogous to /dev/null. Of course, the comvention for the PATH list, etc. is to quietly ignore missing directories. Likewise, classic z/OS needs DSN=EMPTYPDS. And concatenation processing should not terminate on encountering NULLFILE. I use an empty temp DSN (SPACE=(1,0)) when needed. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
