On Thu, 15 Dec 2005 15:12:53 -0600, McKown, John <[EMAIL PROTECTED]> wrote: > > You should have a DDDEF for SMPPTS (original DSN), SMPPTS1 (second DSN), > and SMPPTS2 (third DSN). SMP/E will try SMPPTS, if it fails due to out > of space, it will compress and retry. If the retry fails, it will try > SMPPTS1 and do the same series. If SMPPTS1 fails, it will try SMPPT2. > > Personally, I would make the SMPPTS datasets PDSEs not PDSes. The reason > is that SMP/E is smart enough to know that you cannot compress a PDSE, > so it will not even try. It will just try the next SMPPTSn dataset. > > As always, a PDS cannot span multiple volumes. You must use the SMPPTSn > dd names, in the correct order. If you "skip" one, then SMP/E will not > detect the "next" ones. > I hadn't really pondered this until today. So, suddenly, some questions:
o Does SMP/E keep track in the CSI of which spill data set contains each PTF? Or does it simply do a BLDL on each in sequence until it succeeds? I suppose BPAM concatenation would work. o Suppose the customer fills up all his spill data sets; ACCEPTS; and PURGEs a bunch of PTFs; then RECEIVEs a few more. Does SMP/E keep any information about where the best fit is likely to be? Or does it simply resort to the same technique of attempting to store each PTF in the respective spill data sets consecutively until one succeeds? All this has got to be excruciating. C'mon, IBM. Even if you aren't motivated to present a 21st century image, show some concern for your own developers: provide support for multi-volume PDSes. Or PDSEs. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
