Re: DFDSS and an IFL
Brian I am pretty sure that IFL's can only run z/VM and Linux. HCPMCV1459E The virtual machine is placed in check-stop state due to a system=20=20=20=20= =20=20=20=20=20=20=20 malfunction with CPU 00.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 When they attempt to IPL the Standalone DFDSS code. Has the IBM IFL code on the z9 series changed? Anybody have any other suggestions? Brian Eric Schadow Mainframe Technical Support www.davisvision.com The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender.
Re: DFDSS and an IFL
Correct. An IFL will not run z/OS, or z/VSE code. On 3/9/07, Eric Schadow [EMAIL PROTECTED] wrote: Brian I am pretty sure that IFL's can only run z/VM and Linux. -- Mark Pace Mainline Information Systems
Re: DFDSS and an IFL
On Friday, 03/09/2007 at 09:14 CST, Brian Ferguson [EMAIL PROTECTED] wrote: They have dumped the MVS volumes to tape using DFDSS. And are attempting to use a standalone version of DFDSS to place the volumes onto DASD attached to the VM image. DFDSS is a z/OS utility and z/OS is not licensed to run on IFLs. As you've discovered, there is a reason we don't license z/OS to IFLs: it won't run. If you plan to restore an MVS system from VM, use DDR to back it up. DDR is designed to run on any type of CPU. I can only speculate that standalone DFDSS detected a higher level of hardware and wandered into the Void and was Lost, being sent to the equivalent of Software Hell. To find out whether this is true and/or intentional, you'd have to open a PMR (start with DFDSS). But I don't understand how restoring under VM and then IPLing MVS in another LPAR or on another nearby CEC is any faster than restoring in the LPAR and then IPLing the restored system in an LPAR. They are serial activities. Alan Altmark z/VM Development IBM Endicott
Re: DFDSS and an IFL
But I don't understand how restoring under VM and then IPLing MVS in another LPAR or on another nearby CEC is any faster than restoring in the LPAR and then IPLing the restored system in an LPAR. They are serial activities. They are serial activities. True in an LPAR. But VM offers this unique thingy you may have heard of called a Virtual Machine. If one is at a DR site and logs on multiple of these Virtual Machine thingies, each one *could* start a separate S/A DFDSS restore process. If a master Virtual Machine thingy logged on and started CMS, in theory (and in practice for us years ago using VMBSAR) that master VM could AUTOLOG other restore-only Virtual Machine thingies with a passed parameter to define which disk should be restored, and the autologged Virtual Machine thingy could link back to the master's disk (and SCIF to it) to perform any special setup, IPL the S/A DFDSS and the master Virtual Machine thingy could drive the commands through SCIF. It's akin to another thingy called multitasking. You might have heard of multitasking and these Virtual Machine thingies, but are just having a senior (or Friday) moment. ;-) And yes, DDR could back up the guest and perform the restore. But I am not familiar enough with DFDSS to know if it can reliably backup a **running** z/OS system (I suspect not) such that the image can be reliably restored. Open databases and other such apps usually make this a career-threatening technique. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Alan Altmark [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/09/2007 01:03 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DFDSS and an IFL On Friday, 03/09/2007 at 09:14 CST, Brian Ferguson [EMAIL PROTECTED] wrote: They have dumped the MVS volumes to tape using DFDSS. And are attempting to use a standalone version of DFDSS to place the volumes onto DASD attached to the VM image. DFDSS is a z/OS utility and z/OS is not licensed to run on IFLs. As you've discovered, there is a reason we don't license z/OS to IFLs: it won't run. If you plan to restore an MVS system from VM, use DDR to back it up. DDR is designed to run on any type of CPU. I can only speculate that standalone DFDSS detected a higher level of hardware and wandered into the Void and was Lost, being sent to the equivalent of Software Hell. To find out whether this is true and/or intentional, you'd have to open a PMR (start with DFDSS). But I don't understand how restoring under VM and then IPLing MVS in another LPAR or on another nearby CEC is any faster than restoring in the LPAR and then IPLing the restored system in an LPAR. They are serial activities. Alan Altmark z/VM Development IBM Endicott The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: DFDSS and an IFL
A gotcha if you are intending to get a starter system up and running with the *MVS *version of DFDSS or ADRDSSU or whatever it's called is that it cannot restore a CPVOL initialized disk. Says so right there in the ADRDSSU manual. We are doing our D/R with the idea of getting up a small (oxymoron) MVS system using the S/A ADRDSSU and then using that as a driver to restore the full MVS system as well as VM. This doesn't have anything to do with an IFL but even if you could somehow get the S/A ADRDSSU to run in the IFL, you could not restore a VM system. Jim Mike Walter wrote: This is a multipart message in MIME format. --=_alternative 006AC5F986257299_= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit But I don't understand how restoring under VM and then IPLing MVS in another LPAR or on another nearby CEC is any faster than restoring in the LPAR and then IPLing the restored system in an LPAR. They are serial activities. They are serial activities. True in an LPAR. But VM offers this unique thingy you may have heard of called a Virtual Machine. If one is at a DR site and logs on multiple of these Virtual Machine thingies, each one *could* start a separate S/A DFDSS restore process. If a master Virtual Machine thingy logged on and started CMS, in theory (and in practice for us years ago using VMBSAR) that master VM could AUTOLOG other restore-only Virtual Machine thingies with a passed parameter to define which disk should be restored, and the autologged Virtual Machine thingy could link back to the master's disk (and SCIF to it) to perform any special setup, IPL the S/A DFDSS and the master Virtual Machine thingy could drive the commands through SCIF. It's akin to another thingy called multitasking. You might have heard of multitasking and these Virtual Machine thingies, but are just having a senior (or Friday) moment. ;-) And yes, DDR could back up the guest and perform the restore. But I am not familiar enough with DFDSS to know if it can reliably backup a **running** z/OS system (I suspect not) such that the image can be reliably restored. Open databases and other such apps usually make this a career-threatening technique. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Alan Altmark [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/09/2007 01:03 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DFDSS and an IFL On Friday, 03/09/2007 at 09:14 CST, Brian Ferguson [EMAIL PROTECTED] wrote: They have dumped the MVS volumes to tape using DFDSS. And are attempting to use a standalone version of DFDSS to place the volumes onto DASD attached to the VM image. DFDSS is a z/OS utility and z/OS is not licensed to run on IFLs. As you've discovered, there is a reason we don't license z/OS to IFLs: it won't run. If you plan to restore an MVS system from VM, use DDR to back it up. DDR is designed to run on any type of CPU. I can only speculate that standalone DFDSS detected a higher level of hardware and wandered into the Void and was Lost, being sent to the equivalent of Software Hell. To find out whether this is true and/or intentional, you'd have to open a PMR (start with DFDSS). But I don't understand how restoring under VM and then IPLing MVS in another LPAR or on another nearby CEC is any faster than restoring in the LPAR and then IPLing the restored system in an LPAR. They are serial activities. Alan Altmark z/VM Development IBM Endicott The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. --=_alternative 006AC5F986257299_= Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit brfont size=2 face=sans-serifgt; /fontfont size=2ttBut I don't understand how restoring under VM and then IPLing MVS in br another LPAR or on another nearby CEC is any faster than restoring in the br LPAR and then IPLing the restored system in an LPAR. nbsp;They are serial br activities./tt/font br brfont size=2 face=sans-serifquot;/fontfont size=2ttThey are serial activities./tt/fontfont size=2 face=sans-serifquot; nbsp;True in an LPAR. nbsp;But VM offers this unique thingy you may have heard of called a Virtual Machine./font brfont size=2 face=sans-serifIf one is at a DR site and logs on multiple
Re: DFDSS and an IFL
But I don't understand how restoring under VM and then IPLing MVS in another LPAR or on another nearby CEC is any faster than restoring in the LPAR and then IPLing the restored system in an LPAR. They are serial activities. Restoring a 1 pack VM system, then doing multiple DFDSS restores allows you to have multiple restores occur in parallel, up to the number of tape drives you have available, which dramatically speed up the restore process. Standalone DFDSS is still pretty dumb about making use of multiple devices; restoring under VM removes much of this stupidity.
Re: DFDSS and an IFL
Alan Altmark wrote: DFDSS is a z/OS utility and z/OS is not licensed to run on IFLs. As you've discovered, there is a reason we don't license z/OS to IFLs: it won't run. If you plan to restore an MVS system from VM, use DDR to back it up. DDR is designed to run on any type of CPU. Surely this is backwards; it won't run because the IFL takes steps to make sure it won't. And appears to break the promise in the PofO that says that programs don't cause machine checks. Regardless, if it's not licensed, then they shouldn't be running it. Tony H.
Re: DFDSS and an IFL
On Friday, 03/09/2007 at 05:30 EST, David Boyes [EMAIL PROTECTED] wrote: Restoring a 1 pack VM system, then doing multiple DFDSS restores allows you to have multiple restores occur in parallel, up to the number of tape drives you have available, which dramatically speed up the restore process. Standalone DFDSS is still pretty dumb about making use of multiple devices; restoring under VM removes much of this stupidity. You make my point, actually: If the intent is to exploit z/VM's capabilities, then create backups using the z/VM utilities, not z/OS. Otherwise, you have to use multiple LPARs to accomplish the same task. So it's a question of how much z/VM will cost (on standard engines) vs. how much multiple LPARs will cost. Alan Altmark z/VM Development IBM Endicott
Re: DFDSS and an IFL
On Friday, 03/09/2007 at 05:30 EST, Tony Harminc [EMAIL PROTECTED] wrote: Alan Altmark wrote: DFDSS is a z/OS utility and z/OS is not licensed to run on IFLs. As you've discovered, there is a reason we don't license z/OS to IFLs: it won't run. If you plan to restore an MVS system from VM, use DDR to back it up. DDR is designed to run on any type of CPU. Surely this is backwards; it won't run because the IFL takes steps to make sure it won't. And appears to break the promise in the PofO that says that programs don't cause machine checks. If a program issues instructions in the PofO, rest assured it won't cause a check-stop condition. Regardless, if it's not licensed, then they shouldn't be running it. Amen. Alan Altmark z/VM Development IBM Endicott
