Great answer. You covered it in great detail. One other variable that may or
may not be worth considering is what CA-1 does with the tape after it is
returned by ADSM and expired. In our shop, we have a CA-1 exit coded as you
suggest. Somewhere in this mix, we have a delay for actual reuse by CA-1 set
to 3 days. I believe, but am not certain, that this is established in a CA-1
parmlib (I'm not a TMS guru, hardly even a novice). The effect of this is
that even after a tape shows an expiration date (when ADSM returned the tape),
it is not actually used for a scratch mount until the 3 day grace period has
expired.
Jerry Lawson
jlawson AT itthartford DOT com
________________________Forward Header________________________
Author: INTERNET.OWNERAD
Subject: Re: What is volume status of Pending?
05-26-96 05:47 AM
Mike Cotton says (in part):
>Our tape management system is CA-1 - how do we
>manage retention periods for tapes - at the moment we manually
>declare our disater recovery copies as "PERMANENT" and then manually
>release them later.
First, I recommend a few things:
1) In the "Installing the Server and Administrative Client" book, read
Chapter 9 "Tape Processing Considerations". This covers the basics on
setting up ADSM to work in your tape environment.
2) In the "Administrator's Guide", read Chapter 14 "Recovering Data". This
discusses backup and recovery issues for the ADSM server (database and
storage pools).
3) In general, if you haven't done so already, I *strongly* recommend
reading the entire "Administrator's Guide" from cover to cover.
Those things said, here are some recommendations. I will assume that you
will allow ADSM to use scratch tape volumes managed by CA-1. You must also
have coded the DEVCONFIG and VOLUMEHISTORY options in the server options
file so that device configuration and volume history information will be
written to sequential files. In an SMS environment, ADSM can pre-allocate
these files. In a non-SMS environment, these files can be pre-allocated
with LRECL=1028, BLKSIZE=6144, RECFM=VB, and SPACE=(TRK,(20,20)).
1) The EXPDT setting in your tape device classes (for both storage pools
and database backups) should be 99365 (permanent retention).
UPDATE DEVCLASS <devclassname> EXPDT=99365
should do it, where <devclassname> is the name of the device class to
update.
2) Set up a tape deletion exit, if you already don't have one. I believe
that CA-1 provides a sample exit called TMSTMSTV which you can set up for
your use. Although I can't personally attest to it, I hear it is ready to
be used, as is (you'll probably have to link it in to SYS1.LINKLIB). But
you should verify this anyway, just to make sure. By the way, if you have
HSM running in your shop, the ARCTVEXT exit that HSM uses can probably be
used by ADSM, too. When I set up ADSM in my shop (prior to joining IBM I
worked with ADSM for around 2.5 years), I was able to use the exact same
exit that HSM used, as is.
3) Code the DELETIONEXIT option in the ADSM server options file. The format
is
DELETIONEXIT <exitname>
where <exitname> is the name of the tape volume exit. Example:
DELETIONEXIT ARCTVEXT
4) Set up CA-1 so it knows that ADSM is an External Data Manager. This will
cause all tapes used by ADSM to have FLAG3 set to X'20', or 'EDM'. I don't
know exactly how to do this, but your CA-1 administrator should know.
5) After performing items 1 - 4, when ADSM takes a scratch tape, that tape
will be marked in CA-1 as having permanent retention and being externally
managed. When ADSM is finished using the tape (i.e. after the tape becomes
empty), ADSM will delete the tape volume from its inventory, and invoke the
tape deletion exit (ARCTVEXT, or whatever). The tape deletion exit will
tell CA-1 that the tape is expired. If you do a CA-1 query against the
tape, it'll now show a valid expiration date rather than permanent
retention. That tape will now be eligible for scratch use.
6) If you use BACKUP STGPOOL to copy your local ADSM storage pools to a
disaster recovery pool, after the BACKUP STGPOOL command completes, you
should issue an UPDATE VOLUME command to set the ACCESS of all volumes in
your disaster recovery pool that currently have READWRITE or READONLY
access to OFFSITE. A sample command is provided in Chapter 14 of the Admin
Guide.
7) After running BACKUP STGPOOL and UPDATE VOLUME (as described in the
previous item) you should run BACKUP DB to make a backup copy of your
database. In addition, at this time you should also run a separate batch
job to back up the device configuration and volume history files. These
files will be needed in the event that you have to restore your ADSM
server.
8) At this point, you should pull all ADSM disaster recovery storage pool
volumes, database backup volumes, and devconfig and volumehist backup tapes
that are not yet offsite, and send them offsite. You should be able to get
your CA-1 administrator to create a job that can generate a pull list. In
my old shop, we used to do it by data set name. My local ADSM tapes all had
a high level qualifier of DSM. My disaster recovery and database backup
tapes had a high level qualifier of DSMVAULT. We then had a job that
queried CA-1 for all tapes with the name DSMVAULT that weren't already
vaulted
offsite, and listed them for the tape operators to pull.
9) Now how do you get your offsite volumes back, once they are empty? You
can issue an UPDATE VOLUME command for all disaster recovery pool volumes
that have a current access of OFFSITE *and* have a status of EMPTY, to
change their ACCESS to READWRITE or READONLY (doesn't matter). At that
time, they will be deleted from ADSM's inventory, passed through the tape
deletion exit to expire them, and they can then be returned for scratch
use.
10) I recommend setting the REUSEDELAY option in your disaster recovery
storage pool to something other than 0. Then when a volume becomes empty
(through reclamation, data attrition, etc.), its status will be changed to
PENDING. After the number of days specified by REUSEDELAY have passed, the
status will then become EMPTY. Why do I recommend this? Let's consider a
scenario where you last backed everything up on Tuesday (storage pools,
database, devconfig and volume history) and sent the tapes offsite. On
Wednesday one of the disaster recovery storage pool volumes becomes empty,
and because REUSEDELAY was not set to a non-zero value, the volume came
back to the local site. Then on Thursday, disaster strikes (!) and you have
to use your disaster recovery volumes to restore your ADSM server. Well,
you can recover the database to the state it was in as of last Tuesday, but
it is going to think there is data on the volume that, in real time, was
emptied and returned to the local site on Wednesday. You've now got lost
data (assuming the returned volume was destroyed with the local site).
REUSEDELAY will prevent that from happening by keeping the tape around for
the number of days specified before setting the status to EMPTY. If, for
example, REUSEDELAY was set to 5, then the tape would still have been at
the offsite location.
11) Run DELETE VOLHISTORY periodically. Besides pruning the volume history
file (which would otherwise grow ad infinitum), it will also cause tapes
created by EXPORT or BACKUP DB to be passed through the volume deletion
exit, so they can be returned to scratch. This is the only way to return
these volumes to scratch; otherwise they will stay offsite forever. For
example, you can issue:
DELETE VOLHISTORY TODATE=-7
to cause deletion of volume history records older than 7 days. Any export
or backup db volumes older than 7 days will be run through the deletion
exit, and expired. I recommend coordinating the REUSEDELAY setting in the
disaster recovery storage pool with the TODATE option you specify on DELETE
VOLHISTORY. For example, don't have REUSEDELAY of 15 and TODATE=-7, since
you'll be keeping the storage pool volumes offsite for a lot longer than
you need to. By the same tokey, don't set REUSEDELAY to 3 and issue DELETE
VOLHISTORY TODATE=-6, since if you ever restored the database from the
volumes that were created more than 3 days ago, you probably won't have the
storage pool volumes available.
Well, I think I've hit the highlights.
By the way, all of these things -- BACKUP STG, UPDATE VOLUME, BACKUP DB,
DELETE VOLHISTORY, etc., can be scheduled with ADSM Administrative command
schedules. You can also schedule the ADSM-external jobs, too (job to create
the pull list for tapes to go offsite, job to back up the devconfig and
volume history files, etc.).
Read the Admin Guide, especially chapter 14.
I hope this helps.
Andy Raibeck
ADSM Level 2 Support
408-256-0130
|
