We need generic device access. TRACKREAD and TRACKWRITE are a good start. We also need "stream" I/O like Dave B. suggests: a Pipes stage that can read all spool files and another which can restore them.
-- R; ----- Original Message ----- From: Alan Altmark [EMAIL PROTECTED] Sent: 09/08/2006 10:11 AM To: [email protected] Subject: Re: Saving a backup copy of NSSs with no tape drive On Friday, 09/08/2006 at 10:17 ZE2, Rob van der Heij <[EMAIL PROTECTED]> wrote: > While we're at it, let's wish for a generic spool file back/restore so > you can also do TRF files and what have you. > Some time ago I think we talked about the benefits of generic emulated > devices where a virtual machine does the emulation (FUSE, as Linux > calls that). If you could direct SPXTAPE to an emulated tape device, > the virtual machine could keep an index of saved files, issue commands > to backup new files, capture the data on a disk file. 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.) 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. That's what *I'd* do if I ran the zoo. (We don't need emulated I/O to accomplish these goal of .) Alan Altmark z/VM Development IBM Endicott
