Sam Sheppard says:
> I am running the MVS Version 2 server and also DFSMSrmm 1.2. In version
> 1, full data base backups were run daily. Retention on the DEVCLASS was
> set at 14 days.
>
> After installing Version 2, we implemented incremental data base backups
> and allowed the retention to default to 99365. On Tuesday, I ran the
> DELETE VOLHISTORY TODATE=TODAY-16 command after noting the volume
> history files had data going back almost a year. This unexpectedly
> caused the following message to be received for several tapes:
>
> ANR5228I Deleting CARTRIDGE 005608 from volume history (DUMPDB volume).
>
> These were all formerly data base backup tapes that had already expired.
> The effect here was apparently drive the ARCTVEXT exit and cause RMM to
> scratch the tapes even though they now belonged to someone else. This
> brings up a couple of questions:
>
> 1. Does the ARCTVEXT not check anything but volume serial number when
> asking to scratch tapes (I will also ask this of the DFSMS people)?
> If so, I am covered now that I have 99365 as expiration date.
>
> 2. Is it documented anywhere that the scratch request will be issued as
> well as the deletion of volume history records (the latter being all
> I expected from reading the Administrator's Reference)?
>
> 3. One of the tapes scratched had subsequently reused by ADSM and after
> the scratch was issued, was writted over. ADSM now seems to have no
> record of that volume. When passing the scratch request to ARCTVEXT,
> since the tape was in actuality an ADSM backup tape, would ADSM then
> treat this as a DELETE VOLUME in effect? If so, how can I find out
> what data was on this tape or do I need to worry? So far, all I can
> think of is to restore the data base to a point in time before the
> DEL VOLH was issued and query the volume after that.
>
> Also, the last time I can find that this volume was referenced by ADSM,
> was when the following messages were received about a week before the
> incident in question:
>
> ANR5323I Assigning volume 005608 to SCRTCH.
> IEC271I MESSAGE DISPLAY '005608' ON 388 ISSUED BY JOB ADSM
> ANR5320I Volume 005608 already in use.
> ANR5208I Dismounting volume 005608 (updated).
> IEF234E K 388,005608,PVT,ADSM,ADSM - RACK=005608
>
> My assumption is that ADSM called for a SCRATCH, wrote a label of
> ADSM.BFS on the tape and then discovered that he already had this
> volume in his inventory of DUMPDB backup tapes (ADSM still knew about
> the volume even though RMM had scratched the tape due to EXPIRATION date
> being passed). In that case, I am assuming that there is no valid data
> on this tape and I can safely scratch it.
>
> Any validation/help/comments will be greatly appreciated.
> Thanks
First:
*****
You should *immediately* open a problem with IBM on this.
DELETE VOLHISTORY shouldn't be invoking ARCTVEXT!!
*****
Next, I'm not sure why you changed your database backup volumes to have
a retention of 99365. I use this only when the tapes are to be externally
managed from the TMC (we use CA-1 instead of RMM, but the same principle
applies), which are those that ADSM defines to its tape storage pool.
Database backups, either under V1 or V2, shouldn't be externally managed.
In my shop, I created a new device class for database backup
called DUMPDB. This device class has a retention of 30 days (my number;
you used 14). This is what I used with the V1 server and I still am using
it with the V2 server. I haven't set the log to ROLL FORWARD mode yet,
so I'm not using the DBBACKUPTRIGGER definition. Rather, I've scheduled
a full database backup for Saturday and incrementals for Monday - Friday.
This way I know that no full or incremental tape will be deleted before
the next full backup is taken.
Please keep us posted on how you make out with this problem. This one
sounds like it would be of general interest.
Andy Raibeck
Connecticut Mutual
203-987-3521
|
