Tom,
I just thought I might point out that you are licensed for DRM automatically! You have a library with 10 drives that immediately requires you to purchase ITSM EE which comes with DRM included. So be thankful, you can now manage your offsite tapes like the rest of us The DRM commands will make life much easier!
Good Luck and if you have any more questions about this please feel free to contact me.
Kauffman, Tom wrote:
We don't do the DRM stuff (we're che/// frugal and didn't want to pop the money way back when) and with this exception, our processes have worked flawlessly.
And it just dawned on me how to fix this one. I think my brain has fossilized or something. My previous challenge was to keep the database backups from *staying* private (all my returning tapes are checked in status=private and then marked access readwrite) so I went with the 15-day deletion cycle.
All I need to do to fix this is shorten the cycle, so the volhist entries delete BEFORE the tapes are checked in again. Doh! After all, what counts is the volhist off-site; in our case, on a floppy strapped to the relevant database backup (also has the device config file and our dns zone files).
Thanks for the suggestion, and my apologies for bothering the list with this one.
Tom Kauffman NIBCO, Inc
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Stapleton, Mark Sent: Thursday, August 26, 2004 9:02 AM To: [EMAIL PROTECTED] Subject: Re: Problem with delete volhist type=dbb
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kauffman, Tom
I'm using a dedicated pool of tapes for off-site database backups, which seems to be working OK - almost. The problem is that the delete volhist returns the tape to scratch status, making it available to the next process that wants a scratch tape. 15 days later (my rotation) the database backup fails because all the tapes in my list are in use, most of them for something other than database backups.
Am I missing something on the delete?
If you offsite your database backups, you shouldn't be using DEL VOLHIST; you should be using the SET DRMDBBACKUPEXPIREDAYS parameter instead. Doing so will set old db backups to VAULTRETRIEVE status (rather than directly to scratch), which you then remedy by using the proper MOVE DRMEDIA commands.
Please review the DRM procedures on pages 560 and following of the TSM for AIX Administrator's Guide, version 5.1.5.
-- Mark Stapleton ([EMAIL PROTECTED]) Berbee Information Networks Office 262.521.5627
CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message.
-- Regards, Mark D. Rodriguez President MDR Consulting, Inc.
=============================================================================== MDR Consulting The very best in Technical Training and Consulting. IBM Advanced Business Partner SAIR Linux and GNU Authorized Center for Education IBM Certified Advanced Technical Expert, CATE AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux Red Hat Certified Engineer, RHCE ===============================================================================
