🚀 go-pugleaf

> Note sure if this is any help, but.......
>
> Normally we DO NOT write  twins when running VMArchive.
> (The main reason for this is that with only two tape drives you
> couldn't then do merge/purge correctly)
>
> However to make sure that we  are in a 'reasonable' position to get
> back a file  in the event of  a tape crash, we use  VMBTCPY EXEC to
> copy each  set of VMARCH  tapes as it is  closed and move  the copy
> offsite.
>
> As in  your case its  fairly simple to  use the output  from VMARCH
> VOLUME QUERY to determine which tapes need to be copied.
>
> Note: I seem to recall something having been said at one time about
>       the need  to be careful  when copying VMBACKUP tapes  as they
>       sometimes have very long reocrd/block length, hence VMBTCPY.

Graham,

Thanks for the feedback.  We started out using VMBTCPY.  Unfortunately,
VMBTCPY copies the first file, including the VOL1 record, to the
output tape.  When these tapes go scratch they would go back into the
scratch pool.  The next time the operator would mount this tape as
a scratch tape VM/Tape would spit it out; after reading the copied
VOL1 record it thought this was a production VM/Archive tape.

As you mentioned, you waited until the tape set was closed.  We don't
have enough VM/Archive activity to close our tape sets that frequently.
In addition, our Disaster Recovery requirements include recovering the
entire datacenter as it was at 5:00 PM the night before the disaster.
We'd need to close a tape set and VMBTCPY it every day.  With hundreds
of tapes being sent off site and hundreds returning every day finding
these tapes with the wrong VOL1 record would be a real pain in the
neck.

In my previous posting I said that we just used MOVEFILE to move
data from the VM/Archive tapes to our scratch tapes.  That is true
but with a little twist to keep us from trashing the VOL1 record.
The first file on the tape has the VOL1 record that identifies the
VOLSER of the tape and HDRn records generated and required by
VM/Archive.  What we do is use MOVEFILE to move the first file from
the input tape to a disk file.  We then use EXECIO to overwrite the
first record of this disk file, the VOL1 record, with the VOL1 record
from the output scratch tape.  We now have a disk file with the VOL1
record from the scratch tape and the HDRn records from the VM/Archive
tapes.  This disk file is then MOVEFILed to the first file on the
output tape; then files 2 through the end of the input tape are
MOVEFILEd from the input tape to the output tape.

When these tapes go scratch they have the correct VOLSER and do not need
to be reinitialized to go back into the scratch pool.  The only problem
occurs when you have a disaster and need to use these tapes as
VM/Archive tapes.  The VOLSERs don't match what VM/Archive thinks.
To account for this we use the exact same process of copying all of
the data with the exception of the VOL1 record from one tape to
another tape to create new VM/Archive tapes at our disaster recovery
site.  This time we initialize scratch tapes to have the VOLSERs that
VM/Archive expects and call our process to copy the data from our
off site copies to the newly initialized VM/Archive tapes.

Martin J. Doyle
VM Systems Programming Contractor
Rohm and Haas Company
Philadelphia,  Pennsylvania
MBDMD@ROHVM1
(215) 592-6865 (Day)
(215) 752-2296 (Evening)