This is very interesting. When we first implemented DRM (I think we had PTF
level 13 installed), we found that moving all tapes using a single move drmedia
command with a * as an argument moved the first tape to the I/O slot, and then
dropped out. All the subsequent tapes were left in the library, but forgotten
from the ADSM library inventory. It was necessary to either audit the library,
or remove the tapes using tapeutil. We implemented a mechanism that checked the
tapes out two at a time (anybody in IBM on the ADSM team working with 3575
should note that only using one of the two slots is a real pain), and have not
revisited the problem.

When I am next in, I will have a go at this. It may simplify matters greatly.

Peter Gathercole
Open Systems Consultant

Magura, Curtis wrote:

> Peter,
>
>    We also use a 3575-L24 except we run the move drmedia command with an *
> in the place of volnum. All the tapes that  will get ejected one at a time.
> Just respond to the message to remove the tape from the I/O slot and they
> next tape will get pulled until you have removed all of them.
>
> Curt Magura
> CODA/I Support
> Lockheed Martin Mission Systems
> 301-240-6305
>
> -----Original Message-----
> From: Peter Gathercole [mailto:peter.gathercole AT virgin DOT net]
> Sent: Saturday, August 08, 1998 6:49 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Backup Storage pool question.
>
> 1. Backup stgpool picks up exactly where it left off. If there are still
> mountable tapes in the backup storage pool, they will be used until they are
> full. Each time a backup stgpool is executed, and completes, the result is
> that the copy pool contains all the data from the primary.
> 2. The DRMedia listings are complete. The tapes marked "Mountable" should
> ALL go offsite after every backup. Any tapes that are still in the library
> when a disaster happens would contain some of your backup data, and would be
> lost!. To move the tapes from the library, you use move drmedia *
> wherestate=mountable. If your library handles multiple ejects, then all
> tapes to be removed will be moved to the I/O area. If you have a 3575 (like
> me) or any other library with a single I/O slot, then you have to run a
> "move drmedia volnum wherestate=mountable" for each volume marked mountable.
>
> I will re-iterate the thine about any mountable tape. Even if a tape in the
> copy storcge pool is NOT FULL, it still holds valuable data, that probably
> is not offsite. All mountable tapes should be removed.
>
> To prevent all your scratch tapes from moving offsite, you must have
> reclaimation turned on for your offsite pool. I use 50% reclaimation. When a
> copy pool tape drops below this use, ADSM will write the data onto a new
> tape, and ask for the old tape to be returned (state=vault retrieve). In
> this way, offsite tapes are kept fairly full.
>
> 3. I have it automated on AIX, but I have had to write several shell scripts
> to work around the problem of only a single useable I/O slot on a 3575 L24.
> Unfortunatly, the conditions attached to my contract do not allow me to post
> the scripts, but I can give you pointers if you ask.
>
> Amerman, Anthony S. wrote:
>
> > Hi ADSM'ers
> > I'm kinda confused about the DRM q drmedia and the move drmedia
> > functions, and maybe you can help me.
> > I'm currently doing a backup stg <primary> <copy>, but because of the
> > size it never quite gets done
> > so I guess I have a few questions:
> > 1. Does the backup stgpool command pick up where it left off last or
> > does it try and do a full backup everytime I restart? (This is the
> > correct command to use right?)
> > 2. Do the DRMedia listings get automatically updated to what needs to go
> > offsite or do I have to do queries like
> > "q vol access=readwrite stgpool=copypool status=full" to determine which
> > ones go off to the vault?
> > 3. Is there a solid way to do this that can be automated?
> >
> > I'm using V2 (yes I'm actually going to upgrade in the next week) but I
> > have to get this sorted out in the meantime.
> >
> > Thank in Advance.
> >
> > Shane Amerman
> >
> > Anthony Shane Amerman
> > Legg Mason, Corporate Technology
> > UNIX Systems Engineer
> > 410-454-3081 25th Floor