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" <[email protected]>
03/09/2007 01:03 PM
Please respond to
"The IBM z/VM Operating System" <[email protected]>
To
[email protected]
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
<br><font size=2 face="sans-serif">> </font><font size=2><tt>But 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. They are serial
<br>
activities.</tt></font>
<br>
<br><font size=2 face="sans-serif">"</font><font size=2><tt>They are
serial activities.</tt></font><font size=2 face="sans-serif">" True
in an LPAR. But VM offers this unique thingy you may have heard of
called a Virtual Machine.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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. ;-)</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif"><br>
Mike Walter
<br>
Hewitt Associates
<br>
Any opinions expressed herein are mine alone and do not necessarily represent
the opinions or policies of Hewitt Associates.<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=37%><font size=1 face="sans-serif"><b>"Alan Altmark"
<[EMAIL PROTECTED]></b> </font>
<br>
<br><font size=1 face="sans-serif">Sent by: "The IBM z/VM Operating
System" <[email protected]></font>
<p><font size=1 face="sans-serif">03/09/2007 01:03 PM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
"The IBM z/VM Operating System"
<[email protected]></font></div></table>
<br>
<br>
<td width=62%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">[email protected]</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: DFDSS and an IFL</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>On Friday, 03/09/2007 at 09:14 CST, Brian Ferguson
<br>
<[EMAIL PROTECTED]> wrote:<br>
> They have dumped the MVS volumes to tape using DFDSS.<br>
> <br>
> And are attempting to use a standalone version of DFDSS to place the<br>
> volumes onto DASD attached to the VM image.<br>
<br>
DFDSS is a z/OS utility and z/OS is not licensed to run on IFLs. As
<br>
you've discovered, there is a reason we don't license z/OS to IFLs: it
<br>
won't run. If you plan to restore an MVS system from VM, use DDR
to back <br>
it up. DDR is designed to run on any type of CPU.<br>
<br>
I can only speculate that standalone DFDSS detected a higher level of <br>
hardware and wandered into the Void and was Lost, being sent to the <br>
equivalent of Software Hell. To find out whether this is true and/or
<br>
intentional, you'd have to open a PMR (start with DFDSS).<br>
<br>
But 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. They are serial
<br>
activities.<br>
<br>
Alan Altmark<br>
z/VM Development<br>
IBM Endicott<br>
<br>
</tt></font>
<br>
<P><pre wrap></pre><hr><font size=2 face="serif">
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.
</font>
</pre></P>
--=_alternative 006AC5F986257299_=--
--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]
