Jim, Sorry for the misunderstanding ...
You are correct. The only system that can UNASSIGN the drive is the system that ASSIGNED it to itself (the purpose of the ASSIGN in the nutshell). The "on one system" reference I mentioned in my response to Alan was relative to the fact that his site runs CA MIM. With MIM you can issue a VARY OFF on any one system with the GLOBAL option. This tells MIM on *every* system to VARY the drive OFFLINE. Correspondingly, the VARY ONLINE can be issued with the GLOBAL option too. Because MIM does the VARY OFF/ON on *all* systems for you ... the ASSIGN is reset. As I pointed out, when using this method you wont necessarily know which system left the ASSIGN set. 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 Jim Bohnsack Sent: Thursday, August 10, 2006 11:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Who has the tape drive ASSIGNed? I tried both the VARY OFF/ON and RESET ASSIGN ON RDEV but neither seem to do anything if issued from a system other than where the ATTACH with ASSIGN command was issued. What did work was issuing the RESET ASSIGN command on the system with the ID owning the ASSIGN bit. Doing that I was able to ATTACH the drive to an id on the other system. Right now it's ATTACHed to an id on both systems. I understood from the following that you could reset the ASSIGN bit from any system. By the way, I am on z/VM 4.4 and was experimenting with a 3480. Jim At 07:10 PM 8/8/2006, you wrote: <snip> >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: IBMVM@LISTSERV.UARK.EDU >Subject: Re: Who has the tape drive ASSIGNed? > >I am informed that this particular case was NOT caused by CA-BAB. (We >hav=3D >e=20 >had other cases.) We don't know what was the cause. > >z/OS isn't relevent here, though we have had similar error messages=20 >involving sharing with z/OS at other times.=20 > >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. = >=3D >=20 >Every system responded with TAPE 0366 FREE=20 > >ATTACH 366 * on some systems produced=20 >"Tape 0366 not attached; tape assigned elsewhere." > >Eventually we found a guest that allowed us to attach the tape, so we=20 >assune that system had it assigned. We haven't the foggiest why -- that >=3D > >system wasn't running anything special. > >I gather that CP (or VMTAPE) sends a CCW to the controller to get=20 >the "assigned elsewhere" information. Is there any CCW to find out where >=3D > >it IS assigned? Jim Bohnsack Cornell Univ. (607) 255-1760
