Allocation should not retry allocating devices that still have tapes mounted on them

We experienced a large number of microcode issues during the unloads of our VTS drives. The result was a tape drive that z/OS thought was unloaded but actually had a tape mounted from the VTS's perspective.

Because z/OS and the VTS are 'out of sync' the I/O issued to the drive during the allocation attempt ends up getting timed (IOS error messages seen) out after several minutes resulting in this message:

19:01:22 IEF351I ASSIGN PROCESSING TIMED OUT FOR AUTOSWITCH DEVICE AE06

Losing one single virtual drive is not a big issue. However, this single virtual drive does not get taken out of allocations selection list so we continue to see this same set of error messages across the sysplex for all the tape drive allocations to this specific VTS. Eventually this is noticed and the drive is forced offline which allows allocation to bypass the drive and select another one without issue. However, until the drive is forced offline no tape processing can occur. In some of these circumstances we have ended up getting dangerously close to locking up our systems due to DB2 or MQ being unable to unload their logs. Had those applications been more active we would have ended up locking up these major subsystems due to a single failed tape drive.

While the technical fix in this case is a newer set of microcode we believe that z/OS allocation should be enhanced to automatically bypass this single logical drive in cases where repetitive errors are being seen. This is especially criticial with ATS (Automatic Tape Switching) since the whole sysplex can end up being locked up until an operator action is taken.