Re: Tape drives : MVS & VM
We just reactivate the same iodef in all our mvs lpar. We suppose there was a out of sync for one of them plus an edt problem. Now all is working fine. Just have to wait for the next IPLs to validate if we are in a stable state. Alain Envoyé de mon iPhone Le 15 mars 2011 à 23:22, George Henke/NYLIC a écrit : > In HCD, IODF, IOCDS, z/OS, z/VM, or whatever, if a CHPID is SHARED, as the > poster indicates it is, then all the devices,by default, on that CHPID are > SHARED by any LPAR that is listed on either the ACCESS LIST or the CANDIDATE > LIST for that CHPID which is what SHARED as opposed to DEDICATED or > RECONFIGURABLE means. > > There is also an EXPLICIT DEVICE CANDIDATE LIST, so that when a particular > device ends up being SHARED by default because it happens to be on a SHARED > CHPID, as is the case here, it is possible to exclude that device from being > shared by a particular LPAR through the EXPLICIT DEVICE CANDIDATE LIST. > > From HCD Planning: > > This information includes whether you want to control logical partition > access to devices when logical partitions get access through a shared channel > path. If you do want to limit logical partition access, you specify that you > want an explicit device candidate list when asked by HCD. See "Defining > logical partition access to a channel path" in topic 2.4.2. > > It looks like this is what this poster may need. > > > > > Alan Altmark > Sent by: The IBM z/VM Operating System > 03/15/2011 11:48 AM > > Please respond to > The IBM z/VM Operating System > > To > IBMVM@LISTSERV.UARK.EDU > cc > Subject > Re: Tape drives : MVS & VM > > > > > > On Monday, 03/14/2011 at 01:41 EDT, Mark Pace > wrote: > > Basically all you did was tell the OSs that the devices were not being > shared. > > If you did not specifically limit the access to a particular LPAR then > all the > > LPARs can see because the CHPID is shared. > > I'm not an MVS expert, but if the MVS IODF was generated by HCD, and the > IODF says "no", then the devices are probably not shared in the IOCDS. > IOCDS and IODF out of sync? Perish the thought > > MVS also has to know that the tapes are shared so that he manages ASSIGN > operations correctly, doesn't he? The tape management software must be > willing to unassign the drives when tapes are unmounted. > > Alan Altmark > > z/VM and Linux on System z Consultant > IBM System Lab Services and Training > ibm.com/systems/services/labservices > office: 607.429.3323 > mobile; 607.321.7556 > alan_altm...@us.ibm.com > IBM Endicott >
Re: Tape drives : MVS & VM
In HCD, IODF, IOCDS, z/OS, z/VM, or whatever, if a CHPID is SHARED, as the poster indicates it is, then all the devices,by default, on that CHPID are SHARED by any LPAR that is listed on either the ACCESS LIST or the CANDIDATE LIST for that CHPID which is what SHARED as opposed to DEDICATED or RECONFIGURABLE means. There is also an EXPLICIT DEVICE CANDIDATE LIST, so that when a particular device ends up being SHARED by default because it happens to be on a SHARED CHPID, as is the case here, it is possible to exclude that device from being shared by a particular LPAR through the EXPLICIT DEVICE CANDIDATE LIST. >From HCD Planning: This information includes whether you want to control logical partition access to devices when logical partitions get access through a shared channel path. If you do want to limit logical partition access, you specify that you want an explicit device candidate list when asked by HCD. See "Defining logical partition access to a channel path" in topic 2.4.2. It looks like this is what this poster may need. Alan Altmark Sent by: The IBM z/VM Operating System 03/15/2011 11:48 AM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Tape drives : MVS & VM On Monday, 03/14/2011 at 01:41 EDT, Mark Pace wrote: > Basically all you did was tell the OSs that the devices were not being shared. > If you did not specifically limit the access to a particular LPAR then all the > LPARs can see because the CHPID is shared. I'm not an MVS expert, but if the MVS IODF was generated by HCD, and the IODF says "no", then the devices are probably not shared in the IOCDS. IOCDS and IODF out of sync? Perish the thought MVS also has to know that the tapes are shared so that he manages ASSIGN operations correctly, doesn't he? The tape management software must be willing to unassign the drives when tapes are unmounted. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Tape drives : MVS & VM
Alan, I think too of a mistmach, a out of synchro. I will check if any errors are reported to the hmc tomorrow. Mvs has no assign parameter in the vary command. And yes mvs must know if the drive is really usable or not. At this time we are like if we had attached the drives in multiuser in lpar. It seems too that the assign VM option is not propagated to VM started in lvl2 Alain Envoyé de mon iPhone Le 15 mars 2011 à 16:48, Alan Altmark a écrit : > On Monday, 03/14/2011 at 01:41 EDT, Mark Pace > wrote: >> Basically all you did was tell the OSs that the devices were not being > shared. >> If you did not specifically limit the access to a particular LPAR then > all the >> LPARs can see because the CHPID is shared. > > I'm not an MVS expert, but if the MVS IODF was generated by HCD, and the > IODF says "no", then the devices are probably not shared in the IOCDS. > IOCDS and IODF out of sync? Perish the thought > > MVS also has to know that the tapes are shared so that he manages ASSIGN > operations correctly, doesn't he? The tape management software must be > willing to unassign the drives when tapes are unmounted. > > Alan Altmark > > z/VM and Linux on System z Consultant > IBM System Lab Services and Training > ibm.com/systems/services/labservices > office: 607.429.3323 > mobile; 607.321.7556 > alan_altm...@us.ibm.com > IBM Endicott
Re: Tape drives : MVS & VM
On Tuesday, 03/15/2011 at 04:15 EDT, Rob van der Heij wrote: > But tape management on z/VM remains a challenge since a virtual > machine can unload the tape and get another volume mounted outside > control of the tape manager. I wanted to make CP trap that and involve > the tape manager, but I might very well have found additional holes. Unload a tape, yes, but unless you have the STDEVOPT LIBRARY CTL statement in your directory, you cannot issue tape management commands to the drive. That precludes you from mounting a tape that the tape manager did not already have mounted for you as "next tape". Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Tape drives : MVS & VM
On Monday, 03/14/2011 at 01:41 EDT, Mark Pace wrote: > Basically all you did was tell the OSs that the devices were not being shared. > If you did not specifically limit the access to a particular LPAR then all the > LPARs can see because the CHPID is shared. I'm not an MVS expert, but if the MVS IODF was generated by HCD, and the IODF says "no", then the devices are probably not shared in the IOCDS. IOCDS and IODF out of sync? Perish the thought MVS also has to know that the tapes are shared so that he manages ASSIGN operations correctly, doesn't he? The tape management software must be willing to unassign the drives when tapes are unmounted. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Tape drives : MVS & VM
On Tue, Mar 15, 2011 at 8:21 AM, Shimon Lebowitz wrote: > We actually wanted the opposite - > tapes shared between machines, > all attaches under control of one central program, > and since detaching an assigned drive forces a RUN, > we wanted no ASSIGN at all. > > I implemented this via CP Exit FFB, which altered the > ATTACH to include NOASSIGN on the command, > unless ASSIGN was explicitly specified. These days, the GIVE command might be your friend if you write a tape manager. I would assume the unit remains assigned during the operation, since you don't want another system to take it away after you validated the right tape is mounted. We used to have problems with VSE machines doing that kind of tricks. But tape management on z/VM remains a challenge since a virtual machine can unload the tape and get another volume mounted outside control of the tape manager. I wanted to make CP trap that and involve the tape manager, but I might very well have found additional holes. Rob
Re: Tape drives : MVS & VM
We actually wanted the opposite - tapes shared between machines, all attaches under control of one central program, and since detaching an assigned drive forces a RUN, we wanted no ASSIGN at all. I implemented this via CP Exit FFB, which altered the ATTACH to include NOASSIGN on the command, unless ASSIGN was explicitly specified. Our drives are NOT shared with MVS, each environment uses different tape addresses. Shimon On Tue, Mar 15, 2011 at 5:00 AM, Stephen Powell wrote: > On Mon, 14 Mar 2011 13:29:59 -0400 (EDT), Alain Benveniste wrote: > > > > We did a P.O.R this weekend. We added DASD rdev, the only thing we > > are supposed to do and now we can vary online a same rdev to both > > MVS & VM. We check back the modifications. The chpid are shared, > > the rdev are shareable=NO in the MVS IODEF. We don't know where > > to look at. We changed something... but what! We have one z800 > > with 2 lcss. z/OS1.10 & z/VM 530. > > > > Any idea > > It depends. The old reel-to-reel tape drives (3420 and earlier) > don't support an ASSIGN command; so there's nothing that prevents > them being on-line to two systems at once. (Unless you have some > third party software, such as CA MIM.) But the 3480 and newer > drives do support an ASSIGN command, and that has historically > prevented the drives from being online to two MVS systems at once. > In the case of VM, though, by default, the ASSIGN is not done > when the VARY ONLINE command is issued, but when an ATTACH command > is issued. We didn't like that. Operationally, we don't want > the same drive online to two systems at once. > > What we did was to create a VARY EXEC to front-end the VARY command, > since VARY is normally issued manually by an operator. The exec > examines the command and, if it detects an attempt to vary on a > tape drive(s), adds the ASSIGN option unless NOASSIGN is explicitly > specified. > > With the advent of the MVS SYSPLEX environment, the rules for > sharing tape drives between systems in a SYSPLEX get more > complicated. I remember there was something extra we had to > do, but I don't remember what it was. > > -- > .''`. Stephen Powell > : :' : > `. `'` > `- >
Re: Tape drives : MVS & VM
On Mon, 14 Mar 2011 13:29:59 -0400 (EDT), Alain Benveniste wrote: > > We did a P.O.R this weekend. We added DASD rdev, the only thing we > are supposed to do and now we can vary online a same rdev to both > MVS & VM. We check back the modifications. The chpid are shared, > the rdev are shareable=NO in the MVS IODEF. We don't know where > to look at. We changed something... but what! We have one z800 > with 2 lcss. z/OS1.10 & z/VM 530. > > Any idea It depends. The old reel-to-reel tape drives (3420 and earlier) don't support an ASSIGN command; so there's nothing that prevents them being on-line to two systems at once. (Unless you have some third party software, such as CA MIM.) But the 3480 and newer drives do support an ASSIGN command, and that has historically prevented the drives from being online to two MVS systems at once. In the case of VM, though, by default, the ASSIGN is not done when the VARY ONLINE command is issued, but when an ATTACH command is issued. We didn't like that. Operationally, we don't want the same drive online to two systems at once. What we did was to create a VARY EXEC to front-end the VARY command, since VARY is normally issued manually by an operator. The exec examines the command and, if it detects an attempt to vary on a tape drive(s), adds the ASSIGN option unless NOASSIGN is explicitly specified. With the advent of the MVS SYSPLEX environment, the rules for sharing tape drives between systems in a SYSPLEX get more complicated. I remember there was something extra we had to do, but I don't remember what it was. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Tape drives : MVS & VM
Basically all you did was tell the OSs that the devices were not being shared. If you did not specifically limit the access to a particular LPAR then all the LPARs can see because the CHPID is shared. On Mon, Mar 14, 2011 at 1:29 PM, Alain Benveniste wrote: > Hi, > > We did a P.O.R this weekend. We added DASD rdev, the only thing we are > supposed to do and now we can vary online a same rdev to both MVS & VM. We > check back the modifications. The chpid are shared, the rdev are > shareable=NO in the MVS IODEF. We don't know where to look at. We changed > something... but what ! We have one z800 with 2 lcss. z/OS1.10 & z/VM530. > > Any idea > Alain Benveniste > -- Mark D Pace Senior Systems Engineer Mainline Information Systems
Tape drives : MVS & VM
Hi, We did a P.O.R this weekend. We added DASD rdev, the only thing we are supposed to do and now we can vary online a same rdev to both MVS & V M. We check back the modifications. The chpid are shared, the rdev are shareable=NO in the MVS IODEF. We don't know where to look at. We chang ed something... but what ! We have one z800 with 2 lcss. z/OS1.10 & z/VM 530. Any idea Alain Benveniste
