Alan, Unfortunately, I think the only way to find the offending system is by the hunt-and-peck method you have described ... going to *every* system and issuing a CP ATTACH for the drive in question until you get to the system that doesn't deny you with "assigned elsewhere".
<<< History you may or may not know >>> The CP ATTACH will by default perform the ATTACH *with* ASSIGN. Correspondingly CP will know that happened, and when you do the CP DETACH, CP will clean up after himself by issuing the UNASSIGN CCW. MIM on the other hand does ATTACH with NOASSIGN by default. It thinks it is control and nothing can go wrong. When CP sees that an ATTACH was done with NOASSIGN ... even if the subsequent application that runs sets the ASSIGN flag (like CA-BAB for example) ... CP will *not* intervene when the DETACH is done to issue the UNASSIGN CCW. This is because CP knows that the initial ATTACH was done with NOASSIGN. CP yields to the applications that were in control assuming the ASSIGN CCW was issued for some good reason and that at some point the application which issue the ASSIGN will clean up and issue the NOASSIGN when it has completed all of it's work. <<< end History ... >>> The other "incantation" that will reset the ASSIGN (other than CP RESET ASSIGN ON RDEV) is the CP VARY OFF/VARY ON sequence. Because you indicated you run MIM, you have to ability to issue a MIM command from one system to VARY OFF the drive on *all* systems, then VARY ON again. That's why the suggestion was offered to use that approach to minimize the effort to resolve the problem. Of course, what this doesn't do is identify the offending node with the "bad application". If that's important to you, then I think you're stuck with the hunt-and-peck method of resolution. JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman Sent: Tuesday, August 08, 2006 06:29 PM To: [email protected] Subject: Re: Who has the tape drive ASSIGNed? I am informed that this particular case was NOT caused by CA-BAB. (We hav= e had other cases.) We don't know what was the cause. z/OS isn't relevent here, though we have had similar error messages involving sharing with z/OS at other times. We have 3 VM systems, and 10 guests, involved. We issued: QUERY 366 (or QUERY TAPE FREE) on all systems that have access to 366. = Every system responded with TAPE 0366 FREE ATTACH 366 * on some systems produced "Tape 0366 not attached; tape assigned elsewhere." Eventually we found a guest that allowed us to attach the tape, so we assune that system had it assigned. We haven't the foggiest why -- that = system wasn't running anything special. I gather that CP (or VMTAPE) sends a CCW to the controller to get the "assigned elsewhere" information. Is there any CCW to find out where = it IS assigned?
