If you programmed the server to properly, it could keep N copies of older SDF files. N would of course be specified in the server's configuration file. You might also want to program in some exceptions.
/Tom Kern --- Rob van der Heij <[EMAIL PROTECTED]> wrote: > On 9/8/06, Alan Altmark <[EMAIL PROTECTED]> wrote: > > > For high-tech backups, I'd tweak the *SPL system service to work with SDFs > > such that the guest would be notified when there's a new SDF, just like > > it's notified of new spool files that have specific DEST values. It could > > then read the SDF using the same mechanisms and do whatever it wanted. All > > Not too fast... such a high tech backup only helps for hardware > failure but not for the one between keyboard and chair. By the time > you realize you just replaced the wrong NSS, the high-tech backup > would already have replaced the old copy ;-) > > This brings back old memories... Back in the dark ages, we had some > tooling in the startup of the system that would print a hardcopy "UCB > List" which included the list of volumes we had online. After the > weekend that hardcopy would be archived in some binder in the > Operations area. It was rarely used, until I got paged for missing > user volumes after IPL. So I asked them to find the missing volumes in > the UCB list to understand which device ranges were missing. The > process had been modernized already: the list got shipped to MVS and > was kept online with all other documentation. After a few minutes the > operator decided it was false alert since the volumes were not in his > list. And his list was recent enough, made just 30 minutes before... > and automatically replaced the only copy of the volumes at the > previous IPL. > > Rob > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
