Duh
Imagine that. Not being able to copy a full 3490E (1.2 GB) to a 3480E
(200 MB) cart.
Do you have your cart types reversed?
You should always be able to copy a 3480 to a 3490.
Tom Duerbusch
THD Consulting
>>> ***@hewitt.com 2/7/2006 1:24 PM >>>
Richard,
I was never able to copy a full 3490E cart to a even brand new 3480E
cart.
Each time the output tape filled up before we got to the end, I
presumed
because of the inter-record gaps.
I seem to remember reading various posts and articles over the years
indicating that there is a physical gap on the tape whenever writing
starts again after a pause. What you say may be true, but anecdotal
evidence indicates otherwise. Why else did every single attempt to
copy
a full tape to a new or used cart of the same size fail?
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"Schuh, Richard" <***@visa.com>
Sent by: "VM/ESA and z/VM Discussions" <VMESA-***@LISTSERV.UARK.EDU>
02/07/2006 11:46 AM
Please respond to
"VM/ESA and z/VM Discussions" <VMESA-***@LISTSERV.UARK.EDU>
To
VMESA-***@LISTSERV.UARK.EDU
cc
Subject
Re: Tape conversions
Mike,
What the stopping and restarting of the tape did was to slow down the
process, not waste space by inserting gaps. In the good old days, the
IRGs
were there between the records regardless of the starting and stopping
of
the tape. A File Mark was recognized by the h/w because of an extremely
long gap that was followed by a specific block of data. The space left
by
the stop/start was short enough that the h/w counted it as an IRG and
did
not prime itself to look for the file mark.
Regards,
Richard Schuh
-----Original Message-----
From: VM/ESA and z/VM Discussions
[mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Mike Walter
Sent: Tuesday, February 07, 2006 8:36 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: Tape conversions
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" <***@wellsfargo.com>
Sent by: "VM/ESA and z/VM Discussions" <VMESA-***@LISTSERV.UARK.EDU>
02/06/2006 08:52 PM
Please respond to
"VM/ESA and z/VM Discussions" <VMESA-***@LISTSERV.UARK.EDU>
To
VMESA-***@LISTSERV.UARK.EDU
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:VMESA-***@LISTSERV.UARK.EDU]
On
Behalf Of Stephen Frazier
Sent: Monday, February 06, 2006 2:34 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: [VMESA-L] Tape conversions
I use DITTO to copy tapes.
***@wellsfargo.com 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.
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.