We use the tostate to skip over the courier retrieve state. We do not use
the intermediate state. If we were using a third party to transport the
tapes the courier retrieve state might be useful.

Kenneth Bury
Carolinas HealthCare System

kbury AT carolinas DOT org

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Remeta, Mark
> Sent: Friday, May 28, 1999 08:32
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: DRM Losing Tapes
>
>
> Kenneth, why are you using the tostate= parameter for move drm...
>
> Just curious.
>
> Mark
>
>
> > -----Original Message-----
> > From: Kenneth Bury [SMTP:kbury AT CAROLINA.RR DOT COM]
> > Sent: Thursday, May 27, 1999 9:54 PM
> > To:   ADSM-L AT VM.MARIST DOT EDU
> > Subject:      Re: DRM Losing Tapes
> >
> >         I have placed a call today with IBM concerning the
> missing tapes.
> > It took
> > nearly a month of carefully monitoring the drm steps before we could
> > confirm
> > our suspicions. We use a simple process of doing a  ' q drm *
> > wherestate=vaultretrieve ' to print a list of tapes that are supposed to
> > come back from the vault. The next step is to move the vault retrieve
> > state
> > tapes to the onsite retrieve state with a move ' drm * wherestate=vaultr
> > tostate=onsiter'.  At this step we 'lose' a tape. What happens
> is all the
> > vault retrieve tapes are correctly selected and moved -- along with one
> > extra one. Since the 'extra' tape was not on the vault retrieve
> list, the
> > tape does not get retrieved from the vault. The tape is gone
> from the drm
> > database and is not found until a physical  inventory is
> performed. In our
> > case, it was a tape from the copy storage pool, not a database backup.
> >         By comparing the drm listings before and after the drm move
> > command we were
> > actually able catch and document the error. It took a lot of patience
> > waiting for the error. But judging from the number of 'hung' tapes that
> > have
> > come back after previous inventories, we have been 'lucky' to avoid the
> > problem for so long.
> >         My theory is that the 'extra' tape is one that has expired its
> > pending
> > period and has changed its state internally from vault to vault retrieve
> > but
> > does not show up as a tape in a vault retrieve state when
> listed. However,
> > the move drm command is able to 'see' this particular tape
> along with the
> > other tapes in the vault retrieve state and thus causing the
> disappearing
> > tape.
> >         I suggest to those of you experiencing this anomaly to
> invest the
> > time in
> > listening to IBM's classical on-hold music and let ADSM support
> know that
> > you too are having tapes disappear.
> >
> > Kenneth Bury
> > Carolinas HealthCare System
> >
> > kbury AT carolinas DOT org
> >
> > > -----Original Message-----
> > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On
> Behalf Of
> > > Virginia Hysock
> > > Sent: Thursday, May 27, 1999 16:06
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > Subject: DRM Losing Tapes
> > >
> > >
> > > AIX 3.1.2.20 Server w/IBM 3494 ATL
> > >
> > > Hello all,
> > >
> > >      I have noted that there was quite a bit of discussion on
> the list a
> > > month or so ago about DRM processes for returning tapes from the vault
> > > losing tapes, primarily due to parameters around the DRMEXPIREDAYS,
> > > REUSEDELAY and deleting of the volhistory db backup days, etc.  I also
> > saw
> > > one note that indicated the user was going to open an
> incident with IBM
> > on
> > > it, but I found nothing in searching the APAR files on IBMLINK.
> > > Can anyone
> > > provide me with information on a resolution to this?  I am in the
> > > testing/ready to implement DRM stage right now (with an implementation
> > > deadline of 6/1 - yikes!), and have found a similar problem in
> > performing
> > > the QUERY DRMEDIA * WHERESTATE=VAULTRETRIEVE.  On 5/17 the
> list produced
> > > one tape, S00161 (which was not returned, since I was only
> testing); on
> > > 5/25 the list produced one tape, S00063 (what happened to
> > > S00161?), on 5/26
> > > it produced one other tape, S00065 (no S00161 or S00063).
> > >
> > >      My DRMEXPIREDAYS parameter is set to 30 days, as is the
> REUSEDELAY
> > > period, and the DELETE VOLHIST was set to 30 - but I just
> changed it to
> > 40
> > > based on some of the suggestions in the list notes.  Should I be okay
> > now?
> > > I also saw one suggestion saying that if you are using DRM, you should
> > not
> > > be deleting your volume history db backups.  Can anyone confirm this?
> > > HELP!!
> > >
> > >                          Ginny
> > >
>