Marcy,
Back in the "bad old days" I wrote a VMBRECR8 EXEC which can be used to
"recreate" missing VM:Backup tapes with the proper internal tape chaining.
However it ran into a problem when copying from tapes that were full,
because to make the required changes to the volsers from the good tape
onto the output "COPYn" tape, it has to read the input tape's SLs and User
Header Labels, build the appropriate replacement User Header labels and
write them to the new output tape. That means stopping the output tape
repeatedly while preparing the new output labels - each time introducing
inter-record gaps which take up physical space on the tape. Just enough
space that a full input tape will usually not quite fit onto a new output
tape.
But... if you are copying VM:Backup tapes to a higher density media
one-for-one, then VMBRECR8 EXEC might work for you. OTOH, it won't update
the records in the VM:Backup with the new tape density since this is all
done completely outside of VM:Backup. Editing the catalog *could* be
done, but you'd probably want to work with CA on that issue. :-)
The syntax for VMBRECR8 is:
---<snip>---
VMBRECR8 ?
VMBACKUP is used to create tapes from the nightly VM DASD backups, and
also perform the tape I/O and TWINing for VM:Archiver service machines.
VMBRECR8 is used to create valid copies of tapes created by VMBACKUP
in cases where one tape becomes damaged or lost. It requires that
the volser of the lost or damaged tape, and the volser of the
corresponding VM:Backup COPY. Lots of damaged VM:Archiver tapes can
be re-created by running a Merge/Purge request.
The good tape should be mounted on virtual 181, and the tape to be
re-created on virtual 182 before executing this command.
Note:
Each tape written by VMBACKUP has internal pointers to the tape
before and after it, as well as volsers of the first tape in
each VM:Backup stream in the backup job.
Simply COPYing a VMBACKUP-created tape and changing the VOL1
WILL NOT WORK!
+-FROM-+
>>-VMBRECR8--+-Sibling(lost/damaged)Vol-+--+------+-------------------->
>-----------+-Input(good)Vol-+---------------------------------------->
>--+-----------------------------------------------------------------+><
+-(-+---------------------------------+--+------------------------+
+-SiblingPrevVol--SiblingNextvol--+ +-)--NOWARN--DEBUG--RPT--+
Where:
SiblingVol
is the BAD or missing VM:Backup tape (also known as the COPY
tape).
InputVol
is the GOOD Onsite or Offsite VM:Backup tape.
Options:
If the tape is chained in the TMC, the SiblingPrevVol and SiblingNextVol
are not needed, as that information will be obtained from VM:Tape.
SiblingPrevVol
is the previous volume in the chain (if any) of the Sibling.
SiblingNextVol
is the next volume in the chain (if any) of the Sibling.
PostOptions:
NOWARN
prevents display of a warning message when the VMBRECR8 command
completes.
DEBUG
do not erase "VMBRECR8 CMSUTx" work files when exiting.
There contain the re-built Standard Labels as written to the
output (SiblingVol) tape, where "x" is the physical file number
(i.e. SL 1 HDR=1, SL1 TLR=3, SL2 HDR=4).
RPT
check VMBACKUP catalog for tape copy number and stream info.
Does not require tapes to be mounted, but chaining is required
in the TMC.
Example:
E.g. where 200000 is damaged and 712345 was the Sibling as known to
VM:Backup or VM:Archiver as the COPY tape.
VMBRECR8 200000 712345
---<snip>---
Maybe this could be used as an inspiration for something you write to meet
your particular needs? Just ask for a copy.
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"Marcy Cortes" <[EMAIL PROTECTED]>
Sent by: "VM/ESA and z/VM Discussions" <[email protected]>
02/06/2006 08:52 PM
Please respond to
"VM/ESA and z/VM Discussions" <[email protected]>
To
[email protected]
cc
Subject
Re: Tape conversions
DITTO is not going to understand all the volume chaining in the
VM:Backup tapes. Only something that understood that is going to do the
trick.
Marcy Cortes
(415) 243-6343
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On
Behalf Of Stephen Frazier
Sent: Monday, February 06, 2006 2:34 PM
To: [email protected]
Subject: Re: [VMESA-L] Tape conversions
I use DITTO to copy tapes.
[EMAIL PROTECTED] wrote:
> What do folks do about moving old VM:Backup and old HIDRO tapes to new
> media types? We have a bunch that are supposed to move from IBM 3590
> to STK 9480C and the media types are different and CA doesn't support
> moving them. I suggest we just leave 1 drive, but HW manager
doesn't
> like that at all...
>
>
>
> Marcy Cortes
> (415) 243-6343
>
> "This message may contain confidential and/or privileged information.
> If you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based
> on this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation."
>
>
--
Stephen Frazier
Information Technology Unit
Oklahoma Department of Corrections
3400 Martin Luther King
Oklahoma City, Ok, 73111-4298
Tel.: (405) 425-2549
Fax: (405) 425-2554
Pager: (405) 690-1828
email: stevef%doc.state.ok.us
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.
