Re: DFDSS Restore ADMIN PARM
Couldn't your ESM just be a NOP program, just for such situations? Les Alan Altmark wrote: On Tuesday, 03/30/2010 at 04:57 EDT, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Thanks Alan. BTW, the floor system at our Hot Site does not have RACF nor for that matter any other ESM. You can in fact run z/OS without an ESM. You can run MVS and some of the subsystems, yes. But you cannot, as you discovered, run z/OS and all that implies. Utilities that require specific authorization won't work since they all talk to the ESM via SAF calls (aka RACROUTE Friends). With no ESM, those calls come back as defer and it is then up to the app to decide what to do. Unless it has an alternative source of authorization (99.% don't), the app has no choice but to fail. TSO works as it will, upon a defer from the call to the ESM, interrogate SYS1.UADS, as it does if the ESM is there but doesn't, in RACF terms, have a TSO segment defined for the user. Even JES2/JES3 require an ESM to process USERID=,PASSWORD= on the JOB card. (If you SUBMIT from TSO without them, they run under your TSO id without needing an ESM call.) One of my z/OS Brothers-in-Weaselhood told me ages ago, and confirmed again today, that *z/OS* was not designed to run without an ESM. Without one, you have just enough of a system up so that you can get one installed and then go about your daily chores. Alan Altmark z/VM Development IBM Endicott
Re: DFDSS Restore ADMIN PARM
On Wednesday, 03/31/2010 at 02:22 EDT, Les Koehler vmr...@tampabay.rr.com wrote: Couldn't your ESM just be a NOP program, just for such situations? For various values of NOP, yes. Look at Appendix D of the z/OS RACROUTE Reference. (Works the same way on z/VM.) Alan Altmark z/VM Development IBM Endicott
Re: DFDSS Restore ADMIN PARM
Thanks Alan. BTW, the floor system at our Hot Site does not have RACF nor for that matter any other ESM. You can in fact run z/OS without an ESM. I just waited for our system to be IPLed which does have RACF and the appropriate profiles defined to use the ADMIN keyword. Thanks again for the help. Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Monday, March 29, 2010 3:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DFDSS Restore ADMIN PARM On Monday, 03/29/2010 at 02:02 EDT, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: The problem that I am having is that I am receiving an Authority error on the ADMINSTRATOR keyword. The Hotsite system we are on does not have RACF. I tried removing the keyword but apparently there are other SUB parameters that require the ADMIN keyword. The DFSMSdss manual says that to use the ADMINISTRATOR keyword, all of the following must be true: o FACILITY class is active. o Applicable FACILITY class profile is defined. o You have READ access to that profile. So while the hotsite may not have RACF, it has something else (ACF2, Top Secret, ...), cuz you can't run z/OS without an ESM! The other ESMs manage classes and profiles, just like RACF does. Alan Altmark z/VM Development IBM Endicott
Re: DFDSS Restore ADMIN PARM
On Tuesday, 03/30/2010 at 04:57 EDT, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Thanks Alan. BTW, the floor system at our Hot Site does not have RACF nor for that matter any other ESM. You can in fact run z/OS without an ESM. You can run MVS and some of the subsystems, yes. But you cannot, as you discovered, run z/OS and all that implies. Utilities that require specific authorization won't work since they all talk to the ESM via SAF calls (aka RACROUTE Friends). With no ESM, those calls come back as defer and it is then up to the app to decide what to do. Unless it has an alternative source of authorization (99.% don't), the app has no choice but to fail. TSO works as it will, upon a defer from the call to the ESM, interrogate SYS1.UADS, as it does if the ESM is there but doesn't, in RACF terms, have a TSO segment defined for the user. Even JES2/JES3 require an ESM to process USERID=,PASSWORD= on the JOB card. (If you SUBMIT from TSO without them, they run under your TSO id without needing an ESM call.) One of my z/OS Brothers-in-Weaselhood told me ages ago, and confirmed again today, that *z/OS* was not designed to run without an ESM. Without one, you have just enough of a system up so that you can get one installed and then go about your daily chores. Alan Altmark z/VM Development IBM Endicott
Re: DFDSS Restore ADMIN PARM
Thanks Alan, Yes you are correct we just need the floor system long enough to restore our environment. Of course wouldn't try running normally without ESM just wanted to point out that it is possible although not recommended if you want to get anything done agreed. Thanks! Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Tuesday, March 30, 2010 6:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DFDSS Restore ADMIN PARM On Tuesday, 03/30/2010 at 04:57 EDT, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Thanks Alan. BTW, the floor system at our Hot Site does not have RACF nor for that matter any other ESM. You can in fact run z/OS without an ESM. You can run MVS and some of the subsystems, yes. But you cannot, as you discovered, run z/OS and all that implies. Utilities that require specific authorization won't work since they all talk to the ESM via SAF calls (aka RACROUTE Friends). With no ESM, those calls come back as defer and it is then up to the app to decide what to do. Unless it has an alternative source of authorization (99.% don't), the app has no choice but to fail. TSO works as it will, upon a defer from the call to the ESM, interrogate SYS1.UADS, as it does if the ESM is there but doesn't, in RACF terms, have a TSO segment defined for the user. Even JES2/JES3 require an ESM to process USERID=,PASSWORD= on the JOB card. (If you SUBMIT from TSO without them, they run under your TSO id without needing an ESM call.) One of my z/OS Brothers-in-Weaselhood told me ages ago, and confirmed again today, that *z/OS* was not designed to run without an ESM. Without one, you have just enough of a system up so that you can get one installed and then go about your daily chores. Alan Altmark z/VM Development IBM Endicott
Re: DFDSS Restore ADMIN PARM
Terry, I don't think racf has anything to do with the admin keyword, it lets you act as a dfdss storage admin. Dumb question, have you tired without admin?? Worst that can happen is it won't work like it isn't working now. Mace From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Monday, March 29, 2010 2:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DFDSS Restore ADMIN PARM HI, I am at the Hotsite and I am trying to restore my VM volumes under DFDSS on z/OS. The input statement for the restore is: RESTORE - ADMINISTRATOR - TRKS(0,0,30050,14) INDD(BKVM170K)- OUTDD(VM170K) - CPVOLUME - The problem that I am having is that I am receiving an Authority error on the ADMINSTRATOR keyword. The Hotsite system we are on does not have RACF. I tried removing the keyword but apparently there are other SUB parameters that require the ADMIN keyword. Any ideas on how to get around this?? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 cid:image001.jpg@01C97FB5.5EAFD6C0 - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: DFDSS Restore ADMIN PARM
Well in further reading I have stuck my foot, or should I say my fingers in my mouth. It talks of creating discrete profiles But I would still try w/o and see what happens Mace From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Monday, March 29, 2010 2:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DFDSS Restore ADMIN PARM HI, I am at the Hotsite and I am trying to restore my VM volumes under DFDSS on z/OS. The input statement for the restore is: RESTORE - ADMINISTRATOR - TRKS(0,0,30050,14) INDD(BKVM170K)- OUTDD(VM170K) - CPVOLUME - The problem that I am having is that I am receiving an Authority error on the ADMINSTRATOR keyword. The Hotsite system we are on does not have RACF. I tried removing the keyword but apparently there are other SUB parameters that require the ADMIN keyword. Any ideas on how to get around this?? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 cid:image001.jpg@01C97FB5.5EAFD6C0 - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: DFDSS Restore ADMIN PARM
I tried it without ADMIN but there are other SUB parameters on the Restore statement that require ADMIN. Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Macioce, Larry Sent: Monday, March 29, 2010 2:21 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DFDSS Restore ADMIN PARM Well in further reading I have stuck my foot, or should I say my fingers in my mouth. It talks of creating discrete profiles But I would still try w/o and see what happens Mace From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Monday, March 29, 2010 2:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DFDSS Restore ADMIN PARM HI, I am at the Hotsite and I am trying to restore my VM volumes under DFDSS on z/OS. The input statement for the restore is: RESTORE - ADMINISTRATOR - TRKS(0,0,30050,14) INDD(BKVM170K)- OUTDD(VM170K) - CPVOLUME - The problem that I am having is that I am receiving an Authority error on the ADMINSTRATOR keyword. The Hotsite system we are on does not have RACF. I tried removing the keyword but apparently there are other SUB parameters that require the ADMIN keyword. Any ideas on how to get around this?? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 cid:image001.jpg@01C97FB5.5EAFD6C0 The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: DFDSS Restore ADMIN PARMhttp://us.mc656.mail.yahoo.com/mc/welcome?.rand=49569508
--- On Mon, 3/29/10, Macioce, Larry larry.maci...@com.state.oh.us wrote: From: Macioce, Larry larry.maci...@com.state.oh.us Subject: Re: DFDSS Restore ADMIN PARM To: IBMVM@LISTSERV.UARK.EDU Date: Monday, March 29, 2010, 2:20 PM Well in further reading I have stuck my foot, or should I say my fingers in my mouth. It talks of creating discrete profiles But I would still try w/o and see what happens Mace From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Monday, March 29, 2010 2:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DFDSS Restore ADMIN PARM HI, I am at the Hotsite and I am trying to restore my VM volumes under DFDSS on z/OS. The input statement for the restore is: RESTORE - ADMINISTRATOR - TRKS(0,0,30050,14) INDD(BKVM170K) - OUTDD(VM170K) - CPVOLUME - The problem that I am having is that I am receiving an Authority error on the ADMINSTRATOR keyword. The Hotsite system we are on does not have RACF. I tried removing the keyword but apparently there are other SUB parameters that require the ADMIN keyword. Any ideas on how to get around this?? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: DFDSS Restore ADMIN PARM
On Monday, 03/29/2010 at 02:02 EDT, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: The problem that I am having is that I am receiving an Authority error on the ADMINSTRATOR keyword. The Hotsite system we are on does not have RACF. I tried removing the keyword but apparently there are other SUB parameters that require the ADMIN keyword. The DFSMSdss manual says that to use the ADMINISTRATOR keyword, all of the following must be true: o FACILITY class is active. o Applicable FACILITY class profile is defined. o You have READ access to that profile. So while the hotsite may not have RACF, it has something else (ACF2, Top Secret, ...), cuz you can't run z/OS without an ESM! The other ESMs manage classes and profiles, just like RACF does. Alan Altmark z/VM Development IBM Endicott
Re: DFDSS Dump VM formatted volumes
On Tuesday, 02/10/2009 at 02:18 EST, Brian France b...@psu.edu wrote: We use FDR here. Run CPFMTXA to put an index vtoc on the vol at 0 that z/OS can see. FDR then just dumps the entire volume. Once, we did not do CPFMTXA and z/OS could not handle the volume. Had to run CPFMTXA on the 0 - 1 cyls to put that index vtoc out there. Um, not all volumes have a VTOC on cyl 0. A guest can have cyl 0 and it is not *required* to have a VTOC. If you write one, you may well overlay user data. Of course, if there is no VTOC, the VTOC pointer will be blank (if it is a VOL1 label) or, more likely, it will not be VOL1. FDR/DFDSS need to handle these cases. There's a reason that volume labels follow a set of standards! :-) Alan Altmark z/VM Development IBM Endicott
Re: DFDSS Dump VM formatted volumes
Alan, THANX! In our user direct we place a holder on every volume from 0 1 so no overlay happens. Learned that from this fabulous list and just ass/u/me/d it was standard. Had I read this message to begin with correctly I would've understood that the individual was looking for a how to with DFDSS, not a why overall didn't it work which is why I asked if the volume was formatted. We had a guy here get a new vol, which had ickdsf run against it from z/OS, did the cpfmtxa label only, then filled it with our new experimental sles 10 sp2 shared root set up. z/OS failed to back it up or even recognize it. That's when we tried the format from 0 1 and it worked for us in that z/OS using FDR could then back it up. At 08:35 AM 2/11/2009, you wrote: On Tuesday, 02/10/2009 at 02:18 EST, Brian France b...@psu.edu wrote: We use FDR here. Run CPFMTXA to put an index vtoc on the vol at 0 that z/OS can see. FDR then just dumps the entire volume. Once, we did not do CPFMTXA and z/OS could not handle the volume. Had to run CPFMTXA on the 0 - 1 cyls to put that index vtoc out there. Um, not all volumes have a VTOC on cyl 0. A guest can have cyl 0 and it is not *required* to have a VTOC. If you write one, you may well overlay user data. Of course, if there is no VTOC, the VTOC pointer will be blank (if it is a VOL1 label) or, more likely, it will not be VOL1. FDR/DFDSS need to handle these cases. There's a reason that volume labels follow a set of standards! :-) Alan Altmark z/VM Development IBM Endicott Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu To make an apple pie from scratch, you must first invent the universe. Carl Sagan
Re: DFDSS Dump VM formatted volumes
I found this works for me: (backing up a mod9 on z/os) //INVOL1 DD VOL=SER=540RES,UNIT=3390,DISP=SHR //OUTDD1 DD DSN=MY.VM540RES.BACKUP, // LABEL=(1,SL), // DCB=(TRTCH=COMP), // VOL=(,,,1), // UNIT=JAGT, // DISP=(NEW,CATLG,DELETE) //SYSINDD* DUMP - INDDNAME(INVOL1) - OUTDDNAME( - OUTDD1 - ) - CANCELERROR - OPTIMIZE(1) - CPVOLUME - ADMIN - TRKS(0,0,10016,14) /* From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of frank.r...@daimler.com Sent: Tuesday, February 10, 2009 10:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: DFDSS Dump VM formatted volumes Hi Just installed z/VM 5.4 and wanted to make a backup from a z/OS LPAR. DFDSS does not like the vm formatted volume tried: DUMP INDDNAME(INDD)- OUTDDNAME(OUTDD) - COMPRESS - OPT(4) also tried tracks, cpvolume, admin... No tape on the z/VM LPAR (no z/vm silo stk software) So how to ? Thanks. Ed Rohr z/OS Systems Programmer 503-745-9027 Daimler Trucks North America - A Daimler Company If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation. Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. ==
Re: DFDSS Dump VM formatted volumes
We use FDR here. Run CPFMTXA to put an index vtoc on the vol at 0 that z/OS can see. FDR then just dumps the entire volume. Once, we did not do CPFMTXA and z/OS could not handle the volume. Had to run CPFMTXA on the 0 - 1 cyls to put that index vtoc out there. At 01:04 PM 2/10/2009, frank.r...@daimler.com wrote: Hi Just installed z/VM 5.4 and wanted to make a backup from a z/OS LPAR. DFDSS does not like the vm formatted volume tried: DUMP INDDNAME(INDD)- OUTDDNAME(OUTDD) - COMPRESS - OPT(4) also tried tracks, cpvolume, admin... No tape on the z/VM LPAR (no z/vm silo stk software) So how to ? Thanks. Ed Rohr z/OS Systems Programmer 503-745-9027 Daimler Trucks North America - A Daimler Company If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation. Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu To make an apple pie from scratch, you must first invent the universe. Carl Sagan
Re: DFDSS Dump VM formatted volumes
You could use.. 3390 mod3: DUMP - INDD(DASD)- OUTDD(TAPE1) - ADMINISTRATOR - CONCURRENT- CPVOLUME - OPTIMIZE(4) - TRKS(0,0,3338,14) 3390 mod9 DUMP - INDD(DASD)- OUTDD(TAPE1) - ADMINISTRATOR - CONCURRENT- CPVOLUME - OPTIMIZE(4) - TRKS(0,0,10016,14) Paul Feller AIT Mainframe Technical Support From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of frank.r...@daimler.com Sent: Tuesday, February 10, 2009 12:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DFDSS Dump VM formatted volumes Hi Just installed z/VM 5.4 and wanted to make a backup from a z/OS LPAR. DFDSS does not like the vm formatted volume tried: DUMP INDDNAME(INDD)- OUTDDNAME(OUTDD) - COMPRESS - OPT(4) also tried tracks, cpvolume, admin... No tape on the z/VM LPAR (no z/vm silo stk software) So how to ? Thanks. Ed Rohr z/OS Systems Programmer 503-745-9027 Daimler Trucks North America - A Daimler Company If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation.
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
Re: DFDSS
It appears from this thread that the question and most of the responses referred to backing up Linux volumes, but I discovered something last spring or so when we were polishing up our D/R backups. We use DFDSS on z/OS to do full volume D/R dumps for both our MVS as well as our VM dumps. My initial thought was that we could use S/A ADRDSSU to restore a single volume VM system and then get a bunch of restores running at the same time. You can't do that, at least easily. S/A ADRDSSU does not restore, at least correctly, the allocation bit map (rec 4 or 5??) on a CP owned volume that maps out space. I guess you could use S/A ADRDSSU for the restore and then S/A ICKDSF to allocate, but if your record keeping is out of sync with what's on your tape, you're out of luck. This is documented in the ADRDSSU manual, at least as far as not being able to correctly restore the allocation record for a VM volume. This is only the case for the S/A version of the program. We ended up documenting the S/A restore of a starter MVS system and then we'll use it to restore everything else. Wish we had FDR. Jim Marcy Cortes wrote: This is a multi-part message in MIME format. --_=_NextPart_001_01C6DCED.566D9DD0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Anybody backing up VM volumes using this on z/OS? =20 Marcy Cortes Enterprise Hosting Services - z/VM and z/Linux (415) 243-6343 -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: DFDSS
Title: DFDSS This is the method we use. We shut the guest down first because if you dont he gets very angry . We have restored form this to a vol also. If you need some jcl Id be more than happy to submit. mace From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Wednesday, September 20, 2006 3:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DFDSS Anybody backing up VM volumes using this on z/OS? Marcy Cortes Enterprise Hosting Services - z/VM and z/Linux (415) 243-6343 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: DFDSS
We use FDR on zOS to backup VM volumes. At 03:45 PM 9/20/2006, you wrote: Anybody backing up VM volumes using this on z/OS? Marcy Cortes Enterprise Hosting Services - z/VM and z/Linux (415) 243-6343 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: DFDSS
We have done this. I can send you some sample JCL if you need it. /Tom Kern /301-903-2211 On Wed, 20 Sep 2006 14:45:34 -0500, Marcy Cortes [EMAIL PROTECTED] wrote: Anybody backing up VM volumes using this on z/OS? Marcy Cortes Enterprise Hosting Services - z/VM and z/Linux (415) 243-6343
Re: DFDSS
We use FDR, but DFDSS should be able to do it with no problems. Just make sure to stop whichever guest you are backing up before you do your backup. Jon snip Anybody backing up VM volumes using this on z/OS? /snip
Re: DFDSS
Title: DFDSS See recent Linux390 list archives for all the reasons why this is a bad idea. Short version: if you can afford to shut down the VM system completely, you can use methods outside VM and/or Linux to do reliable dumps of VM volumes. If you dump an active system (particularly one hosting Linux systems), you are likely to get garbage. David Boyes Sine Nomine Associates From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Wednesday, September 20, 2006 4:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DFDSS Anybody backing up VM volumes using this on z/OS? Marcy Cortes Enterprise Hosting Services - z/VM and z/Linux (415) 243-6343 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: DFDSS
When we were running some Linux guests, we used FDR UPSTREAM to dump the linux guests. At 04:17 PM 9/20/2006, you wrote: See recent Linux390 list archives for all the reasons why this is a bad idea. Short version: if you can afford to shut down the VM system completely, you can use methods outside VM and/or Linux to do reliable dumps of VM volumes. If you dump an active system (particularly one hosting Linux systems), you are likely to get garbage. David Boyes Sine Nomine Associates From: The IBM z/VM Operating System [ mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Marcy Cortes Sent: Wednesday, September 20, 2006 4:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DFDSS Anybody backing up VM volumes using this on z/OS? Marcy Cortes Enterprise Hosting Services - z/VM and z/Linux (415) 243-6343 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: DFDSS
Title: DFDSS Yep, I know about all that. I'm talking about the DASD volumes that Linux minidisks are on, not the VM ones. Linux will be down at the time (we have 2 z9-109, well actually soon will be on 5), on 1systemat a time. We just need to shorten that backup downtime in order to be able to do both (all) in the same window and the window needs to get smaller because of the increased load and they have all the fancy HW and 11 LPARs to drive some really fast backups across to the other datacenter (peer to peer tape) until the time we can get full XRC made available to us. So, that's it in a big nutshell. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David BoyesSent: Wednesday, September 20, 2006 1:17 PMTo: IBMVM@LISTSERV.UARK.EDUSubject: Re: [IBMVM] DFDSS See recent Linux390 list archives for all the reasons why this is a bad idea. Short version: if you can afford to shut down the VM system completely, you can use methods outside VM and/or Linux to do reliable dumps of VM volumes. If you dump an active system (particularly one hosting Linux systems), you are likely to get garbage. David Boyes Sine Nomine Associates From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy CortesSent: Wednesday, September 20, 2006 4:00 PMTo: IBMVM@LISTSERV.UARK.EDUSubject: DFDSS Anybody backing up VM volumes using this on z/OS? Marcy Cortes Enterprise Hosting Services - z/VM and z/Linux (415) 243-6343 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation."
Re: DFDSS
That one is not installed on z/OS today. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Duane WeaverSent: Wednesday, September 20, 2006 12:50 PMTo: IBMVM@LISTSERV.UARK.EDUSubject: Re: [IBMVM] DFDSS We use FDR on zOS to backup VM volumes.At 03:45 PM 9/20/2006, you wrote: Anybody backing up VM volumes using this on z/OS? Marcy Cortes Enterprise Hosting Services - z/VM and z/Linux (415) 243-6343 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation."
