Well....First stupid question <g> When you take the drive out of the mix for maintenance, do you vary the unit address offline to all systems?
On Thu, 18 Jan 2007 10:09:21 -0600, Steve O'Connell <steve.m.o'[EMAIL PROTECTED]> wrote: >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
