Checking in and checking out of tapes can occur while all tape subsystems
are busy. However, you do need to use the "checkl=barcode" option:
adsm>checkin libv 3575lib 200123 checkl=barcode stat=scr
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Craig Bell
> Sent: Wednesday, July 15, 1998 4:15 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Tape Questions - 3575 Library
>
>
> ADSM/AIX 3.1.1.2, AIX 4.2.1, 3575 Library
> > These comments actuall apply to All libtypes (scsi, acsls, and 349x)
>
> Does anyone know why ADSM will dismount idle tapes (in a 3575 tape
> library) for some processes, but not for others? It seems if a DB
> backup, migration, or a restore needs a drive it will dismount an idle
> volume. Yet if I need to check in a volume to satisfy a mount request
> for reclaim, restore, etc. there has to be a drive empty for the task or
> it will fail. Then I manually (via dismount volume command) dismount
> the volume, and have to run the checkin again.
>
> > You can use the Q Mount command to see if there is a free drive before
> issuing the checkin.
>
> > The problem is with the "dumber" library inventory management
> commands, ie. checkin, checkout, label, and audit library. These are in
> a set of processes distinct from data management mounts, eg backup/
> archive, backup db, etc. The inventory managment routines just borrow
> drives as they are available, and don't have the hooks in to the mount
> point logic. That's why they don't show up in Q Mount, don't apply to
> the mountlimit logic, etc. It's an architectural feature. :-(
>
> > We do hope to change this and make these part of the regular mountpoint
> logic, but it's a matter of priorities.
>
> Also, while we are on the subject of tapes, if ADSM tries to mount a
> tape that has been checked in as scratch, and for some reason the tape
> volume cannot be written to (like maybe an operator checked it in with
> write protect on), why does it continue to attempt the mount of that
> same tape over and over again. Processes fail even though there are
> other scratch volumes in the library. So I guess the question would be
>
> 1) How does ADSM select a scratch tape from the library?
> 2) Why does it give a very deceiving error message "unable to open
> drive".
>
> > The errno in the "unable to open drive" message is probably
> EWRPROTECT. It's a tricky area that admittedly needs some work.
> As far as acquiring a scratch tape, a count is kept of how many times
> each new tape was acquired from scratch, and go after the least
> acquired tape.
> If you keep getting the same scratch tape acquired over and over,
> then all your
> other tapes must have been acquired more. You can do a SHOW LIBINV to
> see this value, it's the first four bytes of the DATA2 output.
>
> And lastly, ADSM is very smart in some respects, but when it comes to
> tapes it seems the right hand doesn't know what the left is doing. When
> checking in a tape to satisfy a mount request, why does ADSM have to
> mount the tape, verify the label, put the tape away, then mount the tape
> again for use? (answer for this is probably "because that's how it
> works")
>
> > See my first set of comments. The checkin process is completely
> distinct from the mountpoint process.
> Note that you can issue a checkin with CHECKL=NO to avoid the mount,
> but checkin has to complete in order to get the volume into the library
> inventory so that it can be mounted. This is not likely to change.
>
> Craig Bell
>
|
