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
> >