As Rich Greenberg already pointed out, it just requires running a separate job after the normal backups have completed and updated the 1B0 catalog disk.
I like "real-life" examples, which would be hard for Rich to provide now. So I exported the separate, non-catalog job creatively called here "VMBACKUP" (I believe in useful job names), looks like: * * * Top of File * * * JOB BACKUP TYPE FULL COMMENT Backup VMBACKUP minidisks CATALOG CREATE NO OPTIONS BKPTYPE LOGICAL OPTIONS PACKDATA NO OPTIONS CMSSWITCH YES CMSTRIES 9 OPTIONS SFSTRIES 0 OPTIONS PHYSCHANGE HASH OPTIONS CMSCHANGE DATE OPTIONS DIRSCAN YES OPTIONS BKPFILE STANDARD JOBOPTIONS STREAMS 1 JOBOPTIONS HOLD NO PRIORITY NO EXCLUSIVE NO JOBOPTIONS REDUCE REMOUNTS JOBEND QUIET ONETIME NO REPORT REPDETAIL FILE REPORT REPDEST VMBSYSAD REPCLASS D REPORT ERRDEST VMBSYSAD ERRCLASS E REPORT KEYWORD YES REPORT PULLUSER SYSTEM EXCEPTIONS HEWITT OUTPUT 0 DSN VMBACKUP.VMBSYSAD.C1.ONSITE.CATALOG OUTPUT 0 POOL I-EMAGS RETPD 15 OUTPUT 1 DSN VMBACKUP.VMBSYSAD.C2.OFFSITE.CATALOG OUTPUT 1 POOL I-WMAGS RETPD 15 INCLUDE DASD * INCLUDE USERID VMBACKUP * * * * End of File * * * The old "HA$VM PROCEDUR" file that we used back we still went offsite for D.R. restores contains the lines: ---<snip>--- d) Next find the VM:Backup Catalog tapes created on the Recovery Date. The hardcopy report lists the 'primary' and 'alternate' tape volsers. IF THERE IS NO HARDCOPY REPORT, the fiche lists the the 'primary' and 'alternate' volsers in the format: +--------------+ ! VMBCat mm/dd ! ! Prime=123456 ! +--------------+ and +--------------+ ! VMBCat mm/dd ! ! Alter=123456 ! +--------------+ From the hardcopy or or fiche report, for each system DASD volume listed below, write the 'primary' tape volser: VMBCat primary tape: ___________________ VMBCat alternate tape: ___________________ ---<snip>--- The "VMBACKUP" job ran pretty quickly. But it would probably be better to run it with HiDRO or DDR now since good 'ole VMBSAR (which we used to rely on) does not support 3590 tape restores. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Jim Bohnsack" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 03/29/2008 11:57 AM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DR refresh of active SFS A point about VMBACKUP, however, is that while we don't use it for DR, we do use it. One day I was looking thru the VMBACKUP logs of what got dumped and to my surprise, found that the VMBACKUP 1B0 disk, the catalog, doesn't get dumped by VMBACKUP. I always knew that it would be kind of a fuzzy backup but I figured better that than nothing. Now I run a separate ddr dump of the VMBACKUP mdisks after VMBACKUP is finished. That DDR dump is to disk and doesn't get backed up by VMBACKUP until the next night, but a day old catalog is better than nothing. Jim Kris Buelens wrote: > One of our RxServer based serves uses DDR to take a daily backup of > key minidisks listed in a control file and count for the remainder on > the weekly & daily incremental backups taken with VMBACKUP. SFS thus > on VMBACKUP, nothing of SFS is on the DDR backup; the DDR must fit on > a single casette (as DDR doesn't support tape labels). > Part of a DR procedure is running an exec that regenerates all SFS > servers before one starts the VMBACKUP restore template (template > generated by the disaster backup procedure). The control files living > on the SFS servers' 191 disk are restored by this SFS format > procedure. > > -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED] The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
