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
