> Wouldn't it be much simpler to just change SPXTAPE to work with > SPOL-format disk volumes in addition to tapes? > Then you could backup to > dasd and then DDR to tape at your convenience. Or, just add the volume to > the CP-owned list and it's a miracle: the spool files are on it are now in > the system. Oh, and get SPXTAPE to support virtual input/output devices > so you could use minidisks. All of your existing image-backup functions > would work against spool files without having to use SPXTAPE-to-tape and > you wouldn't have to worry about copying the "live" packs or having > mindisk overlays of spool volumes. (It even enables us to have the system > *prevent* a minidisk overlay.)
It'd be a lot simpler and smarter long term to get SPXTAPE out of the business of doing direct device I/O entirely. That's a function that is trivially manageable in userspace; doesn't need to be in CP, and just complicates the maintenance of the service over time. See earlier suggestion wrt a system service, and then just connect the output of the pipeline (ex "SPDUMP STREAM ALL | TAP1" or "SPDUMP STREAM ALL | > fn ft fm", etc. Restores could look like "PIPE < fn ft fm | SPREST STREAM" All the selection and spool management code in SPXTAPE would be salvageable from the current implementation; you'd need a userspace exec to connect up the pipelines and the implementation of the IUCV service to present the data. No future mods for new device types, and a lot less testing needed. > 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 > of the spool metadata would be available. This infrastructure let's you > perform immediate archives whenever something changes (e.g. an updated > DCSS) rather than waiting for the nightly backup. Naturally a new WRITE > function would be needed to allow the SDF to be restored. Interesting, but orthogonal to the problem, I think. I think that'd be a 2nd order gadget, once you've fixed the more basic problem of SPXTAPE having to deal directly with devices.
