For what it's worth I am still doing flips at not having to deal with DMKSYS assemblies and IPL's for the saved segments. Now I am thinking 'Why keep them in spool space?' Wouldn't a more logical approach be to save the segments on a CP minidisk i.e. MAINT's CF1?
That would solve a lot of backup/restore/format problems.
My two cents......
Tom
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[email protected]]On
Behalf Of David Boyes
Sent: Friday, September 08, 2006 9:33 AM
To: [email protected]
Subject: Re: Saving a backup copy of NSSs with no tape drive
> 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.
__________________________________________________________________
<< ella for Spam Control >> has removed VSE-List messages and set aside VM-List for me
You can use it too - and it's FREE! http://www.ellaforspam.com
