Regrettably ... this sounds correct. 

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: Thursday, August 10, 2006 03:06 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Who has the tape drive ASSIGNed?

Don Angle here pointed out that the VARY OFF GLOBAL won't work if the 
system that holds the ASSIGN is down. We think the ASSIGN bit gets reset
=

when the system is IPLed, but not before. 

Is this correct?

Thu, 10 Aug 2006 11:23:06 -0400, Imler, Steven J <[EMAIL PROTECTED]> =

wrote:

>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=2=
0
>>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
>=========================
==========================
=======================

Reply via email to