Hello Jerry:

You have done an excellent job of detective work.  I think I can shed a
little light on this situation.

First I would like to cover the issue about why 3 or 4 drives were used
when there should only be 1 input and 1 output device.  Maybe ADSM has
outsmarted itself on this one.  Since your device class has a mountlimit
of 4 ADSM is smart enough to not have to wait for the rewind/unload on
one drive before attempting to mount a tape on another drive.  If you
already had 4 drives in use then ADSM would have to wait for the dismount
of the tape before attempting to mount the next tape.

Sure you could make a case for only asking for two drives but if ADSM
only used 2 drives for that reclamation and some other server process
needed tapes that were also outside of the SILO you could see the
same problem.

Why did ADSM come to a grinding halt?  You probably already know the
problem was because of the SYSZTIOT enqueue that was outstanding for
the dynamic allocation of the third tape that was waiting for a drive
to become available.  This in itself does not cause the server to come
to a grinding halt but either locks held by the process caused other
server threads to wait behind the process or the main thread needed
to update a flatfile (i.e. devconfig, volhistory, files used with a
device class type of FILE, etc... but not one of the VSAM files used by
ADSM) because that main thread would now also be waiting for the SYSZTIOT
enqueue.  The reason this same problem exists in the case where ADSM
would only use 2 tape drives for the reclamation but need another tape
drive outside of the SILO for another process is because the allocation
will be holding the SYSZTIOT enqueue while waiting for a device and
I believe a unallocate also needs the SYSZTIOT enqueue.

Take a look at APAR PN84364 that I opened for another customer.  I think
this describes the cause of your problem.  The APAR is opened as a DOC
APAR but development is considering code changes.

Another concern was about ignoring the tape drives in the SILO.  I am not
an expert in this area but I assume you have allocation exits that cause
the drives in the SILO to be ignored if the tape does not exist in the
SILO inventory.  Maybe someone with more expertise in this area can
confirm this.  Just to assure you this is all transparent to ADSM.  ADSM
just issues the dynamic allocation and MVS takes over from there to allocate
a drive and mount the tape.

I hate to say this but it is currently working (broken?) as designed.
You might want to track that APAR to see if a code change is eventually
made.  The only circumvention I can suggest is to make sure there are as
many tape drives outside the silo available as the mountlimit setting
in the device class.

Hope this helps - David Bohm, ADSM technical support