Brian--The appends that followed yours and preceded mine are all good
advice, "HOWEVER" and there is always one of those.
If you don't use a VM based database, you don't have to worry about
that. If you are, you'd better, at least, shut it down for the backup
time.
The comments about the spool are right. You won't be able to do a warm
start. FORCE starts are a lot more dangerous. If you didn't get one of
your spool volumes backed up, you're really out of luck. There's no
sense in backing up page space, altho in a DR situation, it just may be
easier to restore every volume that having to read the DR doc and
CPFORMAT spool volumes. Take your choice.
Our DSS backups of the running system are done for DR purposes only.
Yes, we won't have the open spool files and if someone was updating a
mdisk at the time of the backup, you might have a messed up or
incomplete backup. We do, a VMBACKUP FULL backup at about the same time
the DSS backup is done so we're in pretty good shape. Once we've got
the DR backup restored, and bring back up VMBACKUP, we can recover it's
database from a separate backup and get that bad mdisk fixed up.
Our line of reasoning is that if the data center burns down once every
20 years, and we restore that "bad or dirty" restores, losing the open
spool files such as OPERATOR, that's good enough. Your situation may be
completely different. If you have to account for every key press of an
ATM, you're in a different situation.
Jim
Hamilton, Brian wrote:
This is a multi-part message in MIME format.
------_=_NextPart_001_01C8731B.A621A756
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Is anyone using DSS to backup their VM system under zOS and have you
been successful in restoring and IPL'ing ?=20
=20
Sample of the DSS backup statements were using,
=20
DUMP TRACKS(0,0,3338,14) INDDNAME(DASD) OUTDDNAME(TAPE) ADMIN - =20
CPVOLUME CANCELERROR =20
=20
Thanks
=20
Brian
--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]
