But the cartridges wouldn't fit. Regards, Richard Schuh
> -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] > Behalf Of Jim Bohnsack > Sent: Thursday, August 10, 2006 12:19 PM > To: [email protected] > Subject: Re: Who has the tape drive ASSIGNed? > > > Could be even more brutal and get 3420 drives. Then you > didn't have to > bother trying to figure out who owned the ASSIGNment bit. > Everyone did :-) > Jim > > At 03:08 PM 8/10/2006, you wrote: > >Then there is the brute force method of IMLing the control unit. > > > >-----Original Message----- > >From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On > >Behalf Of Alan Ackerman > >Sent: Thursday, August 10, 2006 3:06 PM > >To: [email protected] > >Subject: Re: Who has the tape drive ASSIGNed? > > > > > >Don Angle here pointed out that the VARY OFF GLOBAL won't > work if the=20 > >system that holds the ASSIGN is down. We think the ASSIGN > bit gets reset > > > >when the system is IPLed, but not before.=20 > > > >Is this correct? > > > >Thu, 10 Aug 2006 11:23:06 -0400, Imler, Steven J > <[EMAIL PROTECTED]>=20 > >wrote: > > > > >Jim, > > > > > >Sorry for the misunderstanding ... > > > > > >You are correct. The only system that can UNASSIGN the > drive is the=20 > > >system that ASSIGNED it to itself (the purpose of the > ASSIGN in the=20 > > >nutshell). > > > > > >The "on one system" reference I mentioned in my response > to Alan was=20 > > >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=20 > > >ONLINE can be issued with the GLOBAL option too. Because > MIM does the=20 > > >VARY OFF/ON on *all* systems for you ... the ASSIGN is reset. > > > > > >As I pointed out, when using this method you wont > necessarily know=20 > > >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: [email protected] > > >Subject: Re: Who has the tape drive ASSIGNed? > > > > > >I tried both the VARY OFF/ON and RESET ASSIGN ON RDEV but > neither seem=20 > > >to do anything if issued from a system other than where > the ATTACH with > > >ASSIGN=20 > > >command was issued. What did work was issuing the RESET > ASSIGN command > > >on=20 > > >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=20 > > >an id on both systems. > > > > > >I understood from the following that you could reset the > ASSIGN bit=20 > > >from > > > > > >any system. By the way, I am on z/VM 4.4 and was > experimenting with a=20 > > >3480. > > > > > >Jim > > > > > >At 07:10 PM 8/8/2006, you wrote: > > > > > ><snip> > > > > > > > > >>The other "incantation" that will reset the ASSIGN (other > than CP=20 > > >>RESET ASSIGN ON RDEV) is the CP VARY OFF/VARY ON > sequence. Because=20 > > >>you indicated you run MIM, you have to ability to issue a > MIM command=20 > > >>from one system to VARY OFF the drive on *all* systems, > then VARY ON=20 > > >>again. That's why the suggestion was offered to use that > approach to=20 > > >>minimize the effort to resolve the problem. > > >> > > >>Of course, what this doesn't do is identify the offending > node with=20 > > >>the "bad application". If that's important to you, then > I think=20 > > >>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=20 > >>hav=3D3D e=3D20 > >>had other cases.) We don't know what was the cause. > >> > >>z/OS isn't relevent here, though we have had similar error = >messages=3D20 > > >>involving sharing with z/OS at other times.=3D20 > >> > >>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 > >>=3D3D > >>=3D20 > >>Every system responded with TAPE 0366 FREE=3D20 > >> > >>ATTACH 366 * on some systems produced=3D20 > >>"Tape 0366 not attached; tape assigned elsewhere." > >> > >>Eventually we found a guest that allowed us to attach the tape, so > >we=3D20 > >>assune that system had it assigned. We haven't the foggiest why --=20 > >>that =3D3D > >> > >>system wasn't running anything special. > >> > >>I gather that CP (or VMTAPE) sends a CCW to the controller to get=3D20 = > > >>the "assigned elsewhere" information. Is there any CCW to find out > >where > >>=3D3D > >> > >>it IS assigned? > > > >Jim Bohnsack > >Cornell Univ. > >(607) 255-1760=20 > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=3D >-------------------------------------------------------- > >If you are not an intended recipient of this e-mail, please notify the = >sender, delete it and do not read, act upon, print, disclose, copy, = >retain or redistribute it. Click here for important additional terms = >relating to this e-mail. http://www.ml.com/email_terms/ >-------------------------------------------------------- Jim Bohnsack Cornell Univ. (607) 255-1760
