> So, has anyone considered this?
CKD volumes on the VM side make it tricky. (the usual situation)
If you have a wholly FBA based VM system (sadly, a rarity these days),
then backing up VM volumes via Linux is trivial. On FBA, data blocks
are always the same size and can be safely stored as a stream of bytes
on any media. Shops with VM, VSE, and/or Linux, and no MVS workload
should consider FBA DASD. VM does not need CKD. Linux does
not particularly *like* CKD.
<ASIDE>
On a multi-vendor storage subsystem, FBA on the "channel side"
maps directly to the "SCSI side". That is, if you have emulated DASD
(as we all do!) with both a mainframe side and an "open systems" side,
and the mainframe side is presented as CKD, you either lose the
track boundaries when reading from the "open systems" side or you
get the track boundaries in-band, making them harder for
NT, Solaris, AIX, HP, and the rest to understand.
</ASIDE>
Take for example your CP Directory volume (with or without
other CP extents), often referenced at vaddr 123:
hcp link main 123 123 rr
# find what /dev entry it got, eg: /dev/dasdq
dd if=/dev/dasdq | gzip > dasdq.gz
If you want to be really "clean",
you might include bs= and count= parameters on the 'dd' command.
In my experience, 'dd' is smart enough to quit when it reaches
the end of the physical volume and not report that as a problem.
So if your 123 minidisk is FBA, you can back it up (and restore it!)
with 'dd' just as effectivly as with DDR.
I said VOLUMES. That's helpful for disaster backups,
but doesn't help you with the user's per-file backup needs.
For several reasons, I won't address that in this note,
but I think you can imagine some of the possibilities.
-- RMT
