Hello. I initially opened an ETR for this issue last year, and didn't get any satisfactory resolution. The problem recurred today, so having taken a look in the Archives at related issues, and still not seeing a solution, I thought I'd see if anybody had any suggestions.
The problem as I see it is the way that allocation is building it's list of candidate devices for cartridge mounts. More specifically, the fact that it includes OFFLINE devices as candidates, even when those devices are not intended to be ONLINE (varied offline explicitly due to HW errors). This seems to affect how Allocation deals with allocating drives, specifically in situations where all online drives are in use. In our case, it is DFHSM that suffers. When all genned cartridge drives are ONLINE to z/os, and all drives are in use, I seem to recall that any further Allocation requests cause an IEF238D with an option to reply WAIT, followed by a subsequent IEF433D with an option to reply NOHOLD. This is handled by Automation and works like a charm regardless of how many tape drives we have, provided that they are all online to z/os at the time. However, when 1 or more cartridge drives are offline for repair, and all remaining ONLINE drives are in use, upon a further Allocation we do not see the WAIT option in the IEF238D message, only DEVICE NAME or CANCEL. Furthermore, the only candidate DEVICE listed in the message is the one that is OFFLINE and that we don't want to bring ONLINE. In the past I have had to bring the broken drive online, some time after the event, knowing that the DFHSM backup window has passed and that it won't get used when I reply DEVICE number. Replying CANCEL has in the past seemed to just cause the request to be redriven for the same OFFLINE device, and replying CANCEL may not be desirable anyhow. Our Automation does not currently handle this situation, and DFHSM can e stalled until it is resolved. So the behaviour of Allocation requests when all ONLINE drives are currently in use seems to differ dependent on whether there are 1 or more additional devices currently OFFLINE. I went through some of the ALLOCxx and DFHSM settings via ETR but could not find any real solution to this. Is there a way to prevent a device being eligible for inclusion as a candidate for allocation, in the event that you really do want if offline and not used, and if not how do other folks handle this situation? It is as though having the OFFLINE device genned is a problem, but if the only answer is a 'temporary' HCD change to remove the UCB, then that isn't going to help me, I have the feeling that I have missed something obvious somewhere, so feel free to point this out if it is the case. Steve O. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
