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
|
