DR Backup using DFDSS
Hi I have a dilemma. All of my z/Linux DASD volumes are formatted for a VTOC on cylinder zero so that I can leverage the z/OS DFDSS backups of these volumes. No problem, however I am getting this one guest ready for DR and as such running DFDSS on z/OS to accomplish this. This particular guest has 2 volumes that do not have z/OS VTOC (Dedicating them in the Directory entry) therefore DFDSS receives the ADR307E: error message basically because there is no z/OS VTOC. I know I could use DDR on z/VM to get around this but the problem is that these volumes are in use and I need to attach them to whatever machine I am going to do the DDR from and cannot go to another LPAR because these particular volumes were not gen'ed to be accessible from any other LPAR but the production (separation requirement). So is there any way I can get these backed up given the above? 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
Re: DR Backup using DFDSS
I don't know if a different product is what you have in mind. We use FDR (Innovation) to back up z/OS, z/VSE, z/VM and z/Linux DASD. Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, August 12, 2010 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: DR Backup using DFDSS Hi I have a dilemma. All of my z/Linux DASD volumes are formatted for a VTOC on cylinder zero so that I can leverage the z/OS DFDSS backups of these volumes. No problem, however I am getting this one guest ready for DR and as such running DFDSS on z/OS to accomplish this. This particular guest has 2 volumes that do not have z/OS VTOC (Dedicating them in the Directory entry) therefore DFDSS receives the ADR307E: error message basically because there is no z/OS VTOC. I know I could use DDR on z/VM to get around this but the problem is that these volumes are in use and I need to attach them to whatever machine I am going to do the DDR from and cannot go to another LPAR because these particular volumes were not gen'ed to be accessible from any other LPAR but the production (separation requirement). So is there any way I can get these backed up given the above? 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 cid:image001.jpg@01C97FB5.5EAFD6C0 _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: DR Backup using DFDSS
If you are going to DDR, or DFDSS for that matter, the linux should be down. If you take a DDR dump while the guest is still up and running your restore has a good chance of not running. On Thu, Aug 12, 2010 at 10:49 AM, Frank M. Ramaekers framaek...@ailife.comwrote: I don’t know if a different product is what you have in mind. We use FDR (Innovation) to back up z/OS, z/VSE, z/VM and z/Linux DASD. Frank M. Ramaekers Jr. -- *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On Behalf Of *Martin, Terry R. (CMS/CTR) (CTR) *Sent:* Thursday, August 12, 2010 9:44 AM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* DR Backup using DFDSS Hi I have a dilemma. All of my z/Linux DASD volumes are formatted for a VTOC on cylinder zero so that I can leverage the z/OS DFDSS backups of these volumes. No problem, however I am getting this one guest ready for DR and as such running DFDSS on z/OS to accomplish this. This particular guest has 2 volumes that do not have z/OS VTOC (Dedicating them in the Directory entry) therefore DFDSS receives the *ADR307E*: error message basically because there is no z/OS VTOC. I know I could use DDR on z/VM to get around this but the problem is that these volumes are in use and I need to attach them to whatever machine I am going to do the DDR from and cannot go to another LPAR because these particular volumes were not gen’ed to be accessible from any other LPAR but the production (separation requirement). So is there any way I can get these backed up given the above? 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* * * *[image: cid:image001.jpg@01C97FB5.5EAFD6C0]*** _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com. -- Mark D Pace Senior Systems Engineer Mainline Information Systems
Re: DR Backup using DFDSS
This is a shear guess on my part. Have you tried using OFFLINDR? It is file 719 on the CBT tape. http://www.cbttape.org/cbtdowns.htm?showonlynew=false This program appears to work more like DDR. It does not appear to require an OS VTOC. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-691-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, August 12, 2010 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: DR Backup using DFDSS Hi I have a dilemma. All of my z/Linux DASD volumes are formatted for a VTOC on cylinder zero so that I can leverage the z/OS DFDSS backups of these volumes. No problem, however I am getting this one guest ready for DR and as such running DFDSS on z/OS to accomplish this. This particular guest has 2 volumes that do not have z/OS VTOC (Dedicating them in the Directory entry) therefore DFDSS receives the ADR307E: error message basically because there is no z/OS VTOC. I know I could use DDR on z/VM to get around this but the problem is that these volumes are in use and I need to attach them to whatever machine I am going to do the DDR from and cannot go to another LPAR because these particular volumes were not gen'ed to be accessible from any other LPAR but the production (separation requirement). So is there any way I can get these backed up given the above? 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 [cid:image002.jpg@01CB3A09.E8D3EA70]
Re: DR Backup using DFDSS
Hi Yes, I knew that the backup would be a 'fuzzy' one but I have not had an issue with restoring since I am doing a physical cylinder by cylinder backup. We do use FDRUPSTREAM to handle the incremental and full backups of all the DASD for each guest, but the DFDSS is a little different. 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 Mark Pace Sent: Thursday, August 12, 2010 10:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DR Backup using DFDSS If you are going to DDR, or DFDSS for that matter, the linux should be down. If you take a DDR dump while the guest is still up and running your restore has a good chance of not running. On Thu, Aug 12, 2010 at 10:49 AM, Frank M. Ramaekers framaek...@ailife.com wrote: I don't know if a different product is what you have in mind. We use FDR (Innovation) to back up z/OS, z/VSE, z/VM and z/Linux DASD. Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, August 12, 2010 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: DR Backup using DFDSS Hi I have a dilemma. All of my z/Linux DASD volumes are formatted for a VTOC on cylinder zero so that I can leverage the z/OS DFDSS backups of these volumes. No problem, however I am getting this one guest ready for DR and as such running DFDSS on z/OS to accomplish this. This particular guest has 2 volumes that do not have z/OS VTOC (Dedicating them in the Directory entry) therefore DFDSS receives the ADR307E: error message basically because there is no z/OS VTOC. I know I could use DDR on z/VM to get around this but the problem is that these volumes are in use and I need to attach them to whatever machine I am going to do the DDR from and cannot go to another LPAR because these particular volumes were not gen'ed to be accessible from any other LPAR but the production (separation requirement). So is there any way I can get these backed up given the above? 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 Error! Filename not specified. _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com. -- Mark D Pace Senior Systems Engineer Mainline Information Systems
Re: DR Backup using DFDSS
We use C.A.'s Vmbackup with the HIDRO DR option. Sent from my blackberry From: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU IBMVM@LISTSERV.UARK.EDU Sent: Thu Aug 12 10:49:58 2010 Subject: Re: DR Backup using DFDSS I don’t know if a different product is what you have in mind. We use FDR (Innovation) to back up z/OS, z/VSE, z/VM and z/Linux DASD. Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, August 12, 2010 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: DR Backup using DFDSS Hi I have a dilemma. All of my z/Linux DASD volumes are formatted for a VTOC on cylinder zero so that I can leverage the z/OS DFDSS backups of these volumes. No problem, however I am getting this one guest ready for DR and as such running DFDSS on z/OS to accomplish this. This particular guest has 2 volumes that do not have z/OS VTOC (Dedicating them in the Directory entry) therefore DFDSS receives the ADR307E: error message basically because there is no z/OS VTOC. I know I could use DDR on z/VM to get around this but the problem is that these volumes are in use and I need to attach them to whatever machine I am going to do the DDR from and cannot go to another LPAR because these particular volumes were not gen’ed to be accessible from any other LPAR but the production (separation requirement). So is there any way I can get these backed up given the above? 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 [cid:image002.jpg@01CB3A09.E8D3EA70] _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: DR Backup using DFDSS
Can you can vary/mount the volume onto zOS? If yes, you should be able to use DFDSS to back it up. Were you using the CPVOLume parameter on the dump? Thx - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: DR Backup using DFDSS
On Thursday, 08/12/2010 at 11:36 EDT, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Yes, I knew that the backup would be a ?fuzzy? one but I have not had an issue with restoring since I am doing a physical cylinder by cylinder backup. We do use FDRUPSTREAM to handle the incremental and full backups of all the DASD for each guest, but the DFDSS is a little different. Not had an issue *yet*, I think you meant to say. It may simply be fuzzy, or it may be positively hirsute. Out-of-band backups of dasd, particularly multiple volumes, is a disaster waiting to happen. Multiple volumes compound the risk (think: LVM). Bring the server down, snapshot/flashcopy/whatever all of its volumes, restart the server, then backup the copies. This minimizes down time and ensures a *consistent* backup set. (The real requirement is that the volumes be unmounted, but it's just easier to bring down the server, IMO.) Linux's support for suspend/resume may be able to help with this as well and reduce the length of the outage even more. But since you're using FDRUpstream for incremental AND full backups, it seems that you only need a functioning Linux with FDRUpstream available, not a fully restored Linux image. That is, enough to kick off the restore from the FDR backups. No point in backing up, storing, and restoring data you're going to throw away anyway. IMO, of course. As a security person, it's my job to be paranoid. I don't worry about the 95% of the time that it works ok, I worry about the 5% of the time that it doesn't. Alan Altmark z/VM Development IBM Endicott
Re: DR Backup using DFDSS
As long as management knows the risks and has signed off on a formal document, no worries! Les Martin, Terry R. (CMS/CTR) (CTR) wrote: Thanks Alan. I would love to be able to shut the guests down while I am backing them up but unfortunately this guest was converted over from the Solaris side where they never brought the servers down to do backups. These guests are suppose to be 24 by 7 up time so whenever you ask to bring them down for any reason it's like pulling teeth! But I get what you are saying! 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: Thursday, August 12, 2010 12:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DR Backup using DFDSS On Thursday, 08/12/2010 at 11:36 EDT, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Yes, I knew that the backup would be a ?fuzzy? one but I have not had an issue with restoring since I am doing a physical cylinder by cylinder backup. We do use FDRUPSTREAM to handle the incremental and full backups of all the DASD for each guest, but the DFDSS is a little different. Not had an issue *yet*, I think you meant to say. It may simply be fuzzy, or it may be positively hirsute. Out-of-band backups of dasd, particularly multiple volumes, is a disaster waiting to happen. Multiple volumes compound the risk (think: LVM). Bring the server down, snapshot/flashcopy/whatever all of its volumes, restart the server, then backup the copies. This minimizes down time and ensures a *consistent* backup set. (The real requirement is that the volumes be unmounted, but it's just easier to bring down the server, IMO.) Linux's support for suspend/resume may be able to help with this as well and reduce the length of the outage even more. But since you're using FDRUpstream for incremental AND full backups, it seems that you only need a functioning Linux with FDRUpstream available, not a fully restored Linux image. That is, enough to kick off the restore from the FDR backups. No point in backing up, storing, and restoring data you're going to throw away anyway. IMO, of course. As a security person, it's my job to be paranoid. I don't worry about the 95% of the time that it works ok, I worry about the 5% of the time that it doesn't. Alan Altmark z/VM Development IBM Endicott
Re: DR Backup using DFDSS
On 8/12/2010 at 10:44 AM, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: I have a dilemma. All of my z/Linux DASD volumes are formatted for a VTOC on cylinder zero so that I can leverage the z/OS DFDSS backups of these volumes. No problem, however I am getting this one guest ready for DR and as such running DFDSS on z/OS to accomplish this. This particular guest has 2 volumes that do not have z/OS VTOC (Dedicating them in the Directory entry) therefore DFDSS receives the ADR307E: error message basically because there is no z/OS VTOC. Dedicating volumes don't have any affect on whether there is an OS VTOC on it or not, it's how Linux was told to format them. If, during dasdfmt, CDL was specified (or taken as a default) there should indeed be an OS VTOC that would allow it to be varied online to z/OS. (It was kind of the whole point of creating the CDL format.) If they are CDL formatted and there is no VTOC, then you have a huge bug that needs to be dealt with. If they are LDL formatted and not CDL, then you need to change your procedure to format them. Mark Post
Re: DR Backup using DFDSS
On Thursday, 08/12/2010 at 12:38 EDT, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Thanks Alan. I would love to be able to shut the guests down while I am backing them up but unfortunately this guest was converted over from the Solaris side where they never brought the servers down to do backups. These guests are suppose to be 24 by 7 up time so whenever you ask to bring them down for any reason it's like pulling teeth! But I get what you are saying! If you told someone in the distributed world that you had another server that was going to access a distributed server's LUNs and copy them while the server was running, you would be laughed at. It's the same problem, just a different disk technology. So if you can't ever bring down the server, then your DR strategy has to be the same as it was when it was on Solaris. That is, you install a 'starter' Linux and use that to restore your backups. The only thing that would be different is the location of the starter Linux. Forget about DDR in that context except as (maybe) the source of the starter Linux itself. Alan Altmark z/VM Development IBM Endicott
Re: DR Backup using DFDSS
Yes, these packs fell through the cracks in terms of getting a z/OS VTOC. This is the exception rather than the rule in our shop. Anyway this is just anomaly and we will work our way through it. 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 Mark Post Sent: Thursday, August 12, 2010 5:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DR Backup using DFDSS On 8/12/2010 at 10:44 AM, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: I have a dilemma. All of my z/Linux DASD volumes are formatted for a VTOC on cylinder zero so that I can leverage the z/OS DFDSS backups of these volumes. No problem, however I am getting this one guest ready for DR and as such running DFDSS on z/OS to accomplish this. This particular guest has 2 volumes that do not have z/OS VTOC (Dedicating them in the Directory entry) therefore DFDSS receives the ADR307E: error message basically because there is no z/OS VTOC. Dedicating volumes don't have any affect on whether there is an OS VTOC on it or not, it's how Linux was told to format them. If, during dasdfmt, CDL was specified (or taken as a default) there should indeed be an OS VTOC that would allow it to be varied online to z/OS. (It was kind of the whole point of creating the CDL format.) If they are CDL formatted and there is no VTOC, then you have a huge bug that needs to be dealt with. If they are LDL formatted and not CDL, then you need to change your procedure to format them. Mark Post
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
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
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: Copying one z/VM to another using DFDSS
Thanks mark. I will let you know how it goes! Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov mailto:terry.mar...@cms.hhs.gov From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mark Wheeler Sent: Sunday, April 05, 2009 9:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Copying one z/VM to another using DFDSS Terry, Let's assume for a moment that both MAINT CF1 and MAINT 2CC live on your current sysres volume (call itoldRES). 1) Copy it to another volume accessible on your current system, 2) use DDR to copy oldRES to newRES, then 3) add two temporary MAINT mdisks on your current system - CCF1 and C2CC, both on newRES at same cylinder locations as on oldRES. 4) Link and access them, update SYSTEM CONFIG and USER DIRECT per my previous append. 5) DETACH the fullpack disk of your currrent SYSRES volume. YOU DON'T WANT TO ACCIDENTALLY OVERWRITE YOUR CURRENT DIRECTORY WITH THE DEFINITIONS OF YOUR NEW SYSTEM!!! 6) ATTACH newRES (or DEFINE MDISK cuu 0 END newRES) where cuu is the address specified on the DIRECTORY statement (which you should verify specifies newRES) 7) ACCESS C2CC Z and run DIRECTXA USER DIRECT Z to write the new directory on newRES. 8) Copy all volumes as before, except copy newRES instead of oldRES 9) Relabel all volumes per previous append using ICKDSF CPVOL LABEL 10) IPL new LPAR 11) Scratch oldsys's newRES since was only temporary Just a suggestion: make sure copies of DDR MODULE and ICKSADSF MODULE live on MAINT CF1 so you can run them standalone from SALIPL if needed. Saved my bacon more than once! Good luck! Mark Date: Sun, 5 Apr 2009 20:41:36 -0400 From: terry.mar...@cms.hhs.gov Subject: Re: Copying one z/VM to another using DFDSS To: IBMVM@LISTSERV.UARK.EDU Hi Mark, Thanks for the information. The one thing I forgot to mention was that I cannot access the new addresses from the z/VM LPAR that I am copying to. So that is why I needed a way to make the changes before I copied the packs over so that when they were copied to the new the System Config and User Directory files would be reflecting the new system's addresses. I think the steps you outlined would require that both of the LPARS have access to the new addresses. It is not the case here. What do you think? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov mailto:terry.mar...@cms.hhs.gov From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mark Wheeler Sent: Sunday, April 05, 2009 8:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Copying one z/VM to another using DFDSS I neglected to mention that the new USERC DIRECT A must be copied back to the appropriate SYSC-owned mdisk (MAINT 2CC?) as USER DIRECT. Date: Sun, 5 Apr 2009 16:41:01 -0500 From: mwheele...@hotmail.com Subject: Re: Copying one z/VM to another using DFDSS To: IBMVM@LISTSERV.UARK.EDU Terry, I assume you're not using DIRMAINT or VM:Secure, so following deals only with USER DIRECT... From your current system, 1) copy all the DASD volumes (SYSRES, etc) to your new system's device addresses, then 2) use ICKDSF CPVOL LABEL commands to change to new device addrs to new volsers. 3) Update all volsers in the new SYSTEM CONFIG (you can use DEFINE MDISK to get access to the new MAINT CF1, for example) 4) Make a copy of your USER DIRECT and change the volsers on the DIRECT statement and all MDISK statements. Save as USERC DIRECT A (perhaps). 5) LINK or ATTACH the new sysres volume to your userid using the device address specified on the DIRECT statement 6) Issue DIRECTXA USERC DIRECT A 7) IPL! Best regards, Mark Wheeler http://www.linkedin.com/in/marklwheeler Rediscover Hotmail(r): Get e-mail storage that grows with you. Check it out. http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscove r_Storage1_042009 Quick access to your favorite MSN content and Windows Live with Internet Explorer 8. Download FREE now! http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B0 37MSN55C0701A
Copying one z/VM to another using DFDSS
Hi I want to copy my test system over to another LPAR. I want to be able to IPL the new system with an updated SYSTEM CONFIG file and the USER DIRECTORY. What is the best way to do this? I figured I would do something like: 1. Create a new SYSTEM CONFIG file with the changes that reflect the new DASD device addresses, such as the SYSRES, SYSSPL, etc. if applicable. 2. Create a new USER DIRECTORY with changes that reflect the new DASD addresses. 3. IPL from SYSC console and specify the new SYSTEM CONFIG file that matches the new RES volume serial and the other volumes for the new system I am not too sure of how to load the new USER DIRECTORY. Can I create another one on the RES pack that is being copied and then specify that USER DIRECTORY at IPL time? Not sure! BTW, I am using DFDSS to do a full volume copy and a restore. Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.ma...@cms.hhs.gov
Re: Copying one z/VM to another using DFDSS
I neglected to mention that the new USERC DIRECT A must be copied back to the appropriate SYSC-owned mdisk (MAINT 2CC?) as USER DIRECT. Date: Sun, 5 Apr 2009 16:41:01 -0500 From: mwheele...@hotmail.com Subject: Re: Copying one z/VM to another using DFDSS To: IBMVM@LISTSERV.UARK.EDU Terry, I assume you're not using DIRMAINT or VM:Secure, so following deals only with USER DIRECT... From your current system, 1) copy all the DASD volumes (SYSRES, etc) to your new system's device addresses, then 2) use ICKDSF CPVOL LABEL commands to change to new device addrs to new volsers. 3) Update all volsers in the new SYSTEM CONFIG (you can use DEFINE MDISK to get access to the new MAINT CF1, for example) 4) Make a copy of your USER DIRECT and change the volsers on the DIRECT statement and all MDISK statements. Save as USERC DIRECT A (perhaps). 5) LINK or ATTACH the new sysres volume to your userid using the device address specified on the DIRECT statement 6) Issue DIRECTXA USERC DIRECT A 7) IPL! Best regards, Mark Wheeler http://www.linkedin.com/in/marklwheeler _ Rediscover Hotmail®: Get e-mail storage that grows with you. http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Storage1_042009
Re: Copying one z/VM to another using DFDSS
Hi Mark, Thanks for the information. The one thing I forgot to mention was that I cannot access the new addresses from the z/VM LPAR that I am copying to. So that is why I needed a way to make the changes before I copied the packs over so that when they were copied to the new the System Config and User Directory files would be reflecting the new system's addresses. I think the steps you outlined would require that both of the LPARS have access to the new addresses. It is not the case here. What do you think? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov mailto:terry.mar...@cms.hhs.gov From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mark Wheeler Sent: Sunday, April 05, 2009 8:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Copying one z/VM to another using DFDSS I neglected to mention that the new USERC DIRECT A must be copied back to the appropriate SYSC-owned mdisk (MAINT 2CC?) as USER DIRECT. Date: Sun, 5 Apr 2009 16:41:01 -0500 From: mwheele...@hotmail.com Subject: Re: Copying one z/VM to another using DFDSS To: IBMVM@LISTSERV.UARK.EDU Terry, I assume you're not using DIRMAINT or VM:Secure, so following deals only with USER DIRECT... From your current system, 1) copy all the DASD volumes (SYSRES, etc) to your new system's device addresses, then 2) use ICKDSF CPVOL LABEL commands to change to new device addrs to new volsers. 3) Update all volsers in the new SYSTEM CONFIG (you can use DEFINE MDISK to get access to the new MAINT CF1, for example) 4) Make a copy of your USER DIRECT and change the volsers on the DIRECT statement and all MDISK statements. Save as USERC DIRECT A (perhaps). 5) LINK or ATTACH the new sysres volume to your userid using the device address specified on the DIRECT statement 6) Issue DIRECTXA USERC DIRECT A 7) IPL! Best regards, Mark Wheeler http://www.linkedin.com/in/marklwheeler Rediscover Hotmail(r): Get e-mail storage that grows with you. Check it out. http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscove r_Storage1_042009
Re: Copying one z/VM to another using DFDSS
On: Sun, Apr 05, 2009 at 08:41:36PM -0400,Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR) (CTR) Wrote: } Thanks for the information. The one thing I forgot to mention was that I } cannot access the new addresses from the z/VM LPAR that I am copying to. } So that is why I needed a way to make the changes before I copied the } packs over so that when they were copied to the new the System Config } and User Directory files would be reflecting the new system's addresses. } I think the steps you outlined would require that both of the LPARS have } access to the new addresses. It is not the case here. What do you think? Have you got enough spare volumes on the From LPAR that you could copy the res to one, relabel it, fix the files, load a directory, then copy to the dest LPAR? Put links in your running directory to give you write links to the renamed respack, a full pack and the parm areas at a minimum so you will be able to fix the files load a directory. You can delete them later or just do DEFINE MINIDISK if you have the proper privs. To load a directory, change the DIRECTORY statement to point to the renamed res pack, making sure you have a write link to the full pack at the address in the DIRECTORY statement and run DIRECTXA (or is it called something else in newer systems?). It will give you a non-zero return code indicating that the new directory was not loaded to the running system. RC=6 I think. If you DO get rc=0, you did something wrong, fix it ASAP! Have the userid (MAINT?) that you normally load the directory with logged on and the write link to the respack established so you can load your usual directory if you need to. -- Rich Greenberg N Ft Myers, FL, USA richgr atsign panix.com + 1 239 543 1353 Eastern time. N6LRT I speak for myself my dogs only.VM'er since CP-67 Canines:Val, Red, Shasta Casey (RIP), Red Zero, Siberians Owner:Chinook-L Retired at the beach Asst Owner:Sibernet-L
Re: Copying one z/VM to another using DFDSS
Terry, Let's assume for a moment that both MAINT CF1 and MAINT 2CC live on your current sysres volume (call itoldRES). 1) Copy it to another volume accessible on your current system, 2) use DDR to copy oldRES to newRES, then 3) add two temporary MAINT mdisks on your current system - CCF1 and C2CC, both on newRES at same cylinder locations as on oldRES. 4) Link and access them, update SYSTEM CONFIG and USER DIRECT per my previous append. 5) DETACH the fullpack disk of your currrent SYSRES volume. YOU DON'T WANT TO ACCIDENTALLY OVERWRITE YOUR CURRENT DIRECTORY WITH THE DEFINITIONS OF YOUR NEW SYSTEM!!! 6) ATTACH newRES (or DEFINE MDISK cuu 0 END newRES) where cuu is the address specified on the DIRECTORY statement (which you should verify specifies newRES) 7) ACCESS C2CC Z and run DIRECTXA USER DIRECT Z to write the new directory on newRES. 8) Copy all volumes as before, except copy newRES instead of oldRES 9) Relabel all volumes per previous append using ICKDSF CPVOL LABEL 10) IPL new LPAR 11) Scratch oldsys's newRES since was only temporary Just a suggestion: make sure copies of DDR MODULE and ICKSADSF MODULE live on MAINT CF1 so you can run them standalone from SALIPL if needed. Saved my bacon more than once! Good luck! Mark Date: Sun, 5 Apr 2009 20:41:36 -0400 From: terry.mar...@cms.hhs.gov Subject: Re: Copying one z/VM to another using DFDSS To: IBMVM@LISTSERV.UARK.EDU Hi Mark, Thanks for the information. The one thing I forgot to mention was that I cannot access the new addresses from the z/VM LPAR that I am copying to. So that is why I needed a way to make the changes before I copied the packs over so that when they were copied to the new the System Config and User Directory files would be reflecting the new system’s addresses. I think the steps you outlined would require that both of the LPARS have access to the new addresses. It is not the case here. What do you think? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mark Wheeler Sent: Sunday, April 05, 2009 8:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Copying one z/VM to another using DFDSS I neglected to mention that the new USERC DIRECT A must be copied back to the appropriate SYSC-owned mdisk (MAINT 2CC?) as USER DIRECT. Date: Sun, 5 Apr 2009 16:41:01 -0500 From: mwheele...@hotmail.com Subject: Re: Copying one z/VM to another using DFDSS To: IBMVM@LISTSERV.UARK.EDU Terry, I assume you're not using DIRMAINT or VM:Secure, so following deals only with USER DIRECT... From your current system, 1) copy all the DASD volumes (SYSRES, etc) to your new system's device addresses, then 2) use ICKDSF CPVOL LABEL commands to change to new device addrs to new volsers. 3) Update all volsers in the new SYSTEM CONFIG (you can use DEFINE MDISK to get access to the new MAINT CF1, for example) 4) Make a copy of your USER DIRECT and change the volsers on the DIRECT statement and all MDISK statements. Save as USERC DIRECT A (perhaps). 5) LINK or ATTACH the new sysres volume to your userid using the device address specified on the DIRECT statement 6) Issue DIRECTXA USERC DIRECT A 7) IPL! Best regards, Mark Wheeler http://www.linkedin.com/in/marklwheeler Rediscover Hotmail®: Get e-mail storage that grows with you. Check it out. _ Quick access to your favorite MSN content and Windows Live with Internet Explorer 8. http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MSN55C0701A
Re: Copying one z/VM to another using DFDSS
Martin--Unless you're doing something unusual (in my opinion) in SYSTEM
CONFIG such as specifying anything more than 3270 console or printer
addresses in SYSTEM CONFIG, there's not much that you're going to have
to do there. Are you going to be copying dasd, other than sysowned
devices, or are you moving into an existing system and keeping old
device volsers? If you will have some new dasd volids to contend
with, you should add them to User_Volume_Include stmts. Add new or
different console addresses to the Operator_Consoles in SYSTEM CONFIG
list. You can just add the new addresses to the existing SYSTEM
CONFIG, keeping the old addresses. If you are copying the entire
system, including all the dasd--user and system, you don't really have
to worry about the directory unless you are using DEDICATE statements
in it. Check that you won't have any surprises in SYSTEM CONFIG in:
Devices ,
Online_at_IPL
Sensed
Jim
Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR) (CTR)
wrote:
This is a multi-part message in MIME format.
--_=_NextPart_001_01C9B635.28BD400B
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Hi
=20
I want to copy my test system over to another LPAR. I want to be able to
IPL the new system with an updated SYSTEM CONFIG file and the USER
DIRECTORY. What is the best way to do this? I figured I would do
something like:
=20
1. Create a new SYSTEM CONFIG file with the changes that reflect
the new DASD device addresses, such as the SYSRES, SYSSPL, etc. if
applicable.=20
2. Create a new USER DIRECTORY with changes that reflect the new
DASD addresses.=20
3. IPL from SYSC console and specify the new SYSTEM CONFIG file
that matches the new RES volume serial and the other volumes for the new
system
=20
I am not too sure of how to load the new USER DIRECTORY. Can I create
another one on the RES pack that is being copied and then specify that
USER DIRECTORY at IPL time? Not sure!
=20
BTW, I am using DFDSS to do a full volume copy and a restore.
=20
Thank You,
=20
Terry Martin
Lockheed Martin - Information Technology
z/OS z/VM Systems - Performance and Tuning
Cell - 443 632-4191
Work - 410 786-0386
terry.ma...@cms.hhs.gov
=20
--_=_NextPart_001_01C9B635.28BD400B
Content-Type: text/html;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
head
meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"
meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"
style
!--
/* Font Definitions */
@font-face
{font-family:"Eras Bold ITC";
panose-1:2 11 9 7 3 5 4 2 2 4;}
@font-face
{font-family:"Arial \(W1\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Arial;
color:windowtext;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1347949525;
mso-list-type:hybrid;
mso-list-template-ids:-4959822 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--
/style
/head
body lang=3DEN-US link=3Dblue vlink=3Dpurple
div class=3DSection1
p class=3DMsoNormalfont size=3D2 face=3DArialspan =
style=3D'font-size:10.0pt;
font-family:Arial'Hio:p/o:p/span/font/p
p class=3DMsoNormalfont size=3D2 face=3DArialspan =
style=3D'font-size:10.0pt;
font-family:Arial'o:pnbsp;/o:p/span/font/p
p class=3DMsoNormalfont size=3D2 face=3DArialspan =
style=3D'font-size:10.0pt;
font-family:Arial'I want to copy my test system over to another LPAR. I =
want
to be able to IPL the new system with an updated SYSTEM CONFIG file and =
the USER
DIRECTORY. nbsp;What is the best way to do this? I figured I would do
something like:o:p/o:p/span/font/p
p class=3DMsoNormalfont size=3D2 face=3DArialspan =
style=3D'font-size:10.0pt;
font-family:Arial'o:pnbsp;/o:p/span/font/p
ol style=3D'margin-top:0in' start=3D1 type=3D1
li class=3DMsoNormal style=3D'color:red;mso-list:l0 level1 lfo1'font =
size=3D2
color=3Dred face=3D"Arial (W1)"span =
style=3D'font-size:10.0pt;font-family:
"Arial \(W1\)"'Create a new SYSTEM CONFIG file with the changes =
that
reflect the new DASD device addresses, such as the SYSRES, SYSSPL, =
etc. if
ap
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
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 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: Heads Up - z/OS 1.10 DFDSS DUMP's of z/VM and z/Linux volumes fail silently
Further update... Fixtest OA27531 is available and I have tested this and it works fine. It allows DUMP and RESTORE from z/OS. IBM is still working on a fix to allow RETORE from a bad DUMP taken previously. Regards, Fred Schmidt DCS DBE NT Government, Australia
Re: Heads Up - z/OS 1.10 DFDSS DUMP's of z/VM and z/Linux volumes fail silently
Thanks Fred! Going to z/OS 1.10 this year. Thanks, Nick From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Fred Schmidt Sent: Tuesday, January 27, 2009 12:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Heads Up - z/OS 1.10 DFDSS DUMP's of z/VM and z/Linux volumes fail silently Just a heads-up to a problem we discovered today, which has the potential to bite somebody. We went to restore some z/VM and z/Linux DASD that had been backed up via z/OS 1.10 DFDSS and it failed with... IOS000I 115B,20,CMD,E7,0E00,,E3D9D2F0,LNX025,FUSREST6, 778 80005B0400FF00140004C800732011000F0440E2 ... and ADR348E (001)-IOWD (01), PERMANENT OUTPUT ERROR ON VOLUME LNX025 E3D9D2F0,FF,0E00,80005B04,41 ADR324E (001)-TDFP (01), THE VOLUME/DATA SET SPECIFIED BY VOLSER LNX025 HAS BECOME UNUSABLE z/OS APAR OA27531 describes the problem, which is with the DUMP of the volume, not the RESTORE. The DUMP actually completes with RC=00, so there is no indication of a problem with the backup until you try to restore from it! The current target fix date for the APAR is September. A workaround is to run the DUMP from a z/OS system at 1.9 or earlier. STEPLIB'ing to an APF-authorised SYS1.LINKLIB from an earlier release also appears to work. Regards, Fred Schmidt DCS DBE NT Government Australia
Re: Heads Up - z/OS 1.10 DFDSS DUMP's of z/VM and z/Linux volumes fail silently
An update on this... IBM now expects a fix to be available early next week. Regards, Fred Schmidt DCS DBE NT Government, Australia
Re: Heads Up - z/OS 1.10 DFDSS DUMP's of z/VM and z/Linux volumes fail silently
Thank you Fred! Very timely for us. FYI - Our IBM Technical Advocate says the target date is now March 9 and it is now flagged HIPER. Marcy 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:ib...@listserv.uark.edu] On Behalf Of Fred Schmidt Sent: Monday, January 26, 2009 10:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Heads Up - z/OS 1.10 DFDSS DUMP's of z/VM and z/Linux volumes fail silently Just a heads-up to a problem we discovered today, which has the potential to bite somebody. We went to restore some z/VM and z/Linux DASD that had been backed up via z/OS 1.10 DFDSS and it failed with... IOS000I 115B,20,CMD,E7,0E00,,E3D9D2F0,LNX025,FUSREST6, 778 80005B0400FF00140004C800732011000F0440E2 ... and ADR348E (001)-IOWD (01), PERMANENT OUTPUT ERROR ON VOLUME LNX025 E3D9D2F0,FF,0E00,80005B04,41 ADR324E (001)-TDFP (01), THE VOLUME/DATA SET SPECIFIED BY VOLSER LNX025 HAS BECOME UNUSABLE z/OS APAR OA27531 describes the problem, which is with the DUMP of the volume, not the RESTORE. The DUMP actually completes with RC=00, so there is no indication of a problem with the backup until you try to restore from it! The current target fix date for the APAR is September. A workaround is to run the DUMP from a z/OS system at 1.9 or earlier. STEPLIB'ing to an APF-authorised SYS1.LINKLIB from an earlier release also appears to work. Regards, Fred Schmidt DCS DBE NT Government Australia
Heads Up - z/OS 1.10 DFDSS DUMP's of z/VM and z/Linux volumes fail silently
Just a heads-up to a problem we discovered today, which has the potential to bite somebody. We went to restore some z/VM and z/Linux DASD that had been backed up via z/OS 1.10 DFDSS and it failed with... IOS000I 115B,20,CMD,E7,0E00,,E3D9D2F0,LNX025,FUSREST6, 778 80005B0400FF00140004C800732011000F0440E2 ... and ADR348E (001)-IOWD (01), PERMANENT OUTPUT ERROR ON VOLUME LNX025 E3D9D2F0,FF,0E00,80005B04,41 ADR324E (001)-TDFP (01), THE VOLUME/DATA SET SPECIFIED BY VOLSER LNX025 HAS BECOME UNUSABLE z/OS APAR OA27531 describes the problem, which is with the DUMP of the volume, not the RESTORE. The DUMP actually completes with RC=00, so there is no indication of a problem with the backup until you try to restore from it! The current target fix date for the APAR is September. A workaround is to run the DUMP from a z/OS system at 1.9 or earlier. STEPLIB'ing to an APF-authorised SYS1.LINKLIB from an earlier release also appears to work. Regards, Fred Schmidt DCS DBE NT Government Australia
Restoring from DFDSS backup from tape
Hi, We have backed up one of our Linux guest to tape track by track (Physical) using DFDSS. Now we want to RESTORE the guest from the tape. Anyone know the control cards necessary to make this happen with DFDSS? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED]
Re: Restoring from DFDSS backup from tape
Just for comparison here is what we use for the backup of a 3390 mod9.. DUMP - INDD(DASD)- OUTDD(TAPE1) - ADMINISTRATOR - CONCURRENT- CPVOLUME - OPTIMIZE(4) - TRKS(0,0,10016,14) And here is what we would use for the restore of a 3390 mod9.. RESTORE - ADMINISTRATOR - TRKS(0,0,10016,14)- INDD(TAPE1) - OUTDD(DASD) - CPVOLUME - PURGE Paul Feller AIT Mainframe Technical Support From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, September 18, 2008 7:27 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Restoring from DFDSS backup from tape Hi, We have backed up one of our Linux guest to tape track by track (Physical) using DFDSS. Now we want to RESTORE the guest from the tape. Anyone know the control cards necessary to make this happen with DFDSS? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]
Re: Restoring from DFDSS backup from tape
Thanks Paul, this worked great! Terry From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Feller, Paul Sent: Thursday, September 18, 2008 8:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Restoring from DFDSS backup from tape Just for comparison here is what we use for the backup of a 3390 mod9.. DUMP - INDD(DASD)- OUTDD(TAPE1) - ADMINISTRATOR - CONCURRENT- CPVOLUME - OPTIMIZE(4) - TRKS(0,0,10016,14) And here is what we would use for the restore of a 3390 mod9.. RESTORE - ADMINISTRATOR - TRKS(0,0,10016,14)- INDD(TAPE1) - OUTDD(DASD) - CPVOLUME - PURGE Paul Feller AIT Mainframe Technical Support From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, September 18, 2008 7:27 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Restoring from DFDSS backup from tape Hi, We have backed up one of our Linux guest to tape track by track (Physical) using DFDSS. Now we want to RESTORE the guest from the tape. Anyone know the control cards necessary to make this happen with DFDSS? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED]
Re: z/vm dfdss standalone ipl console
I think David, with Mike's correction is correct. We've got 2nd level MVS machines that are used for our D/R tests. We always start the exercise by loading the D/R backup tapes from S/A DFDSS. The consoles on the 2nd level MVS id's are specified as being 3270 rather than 3215. Works just fine. Jim Mike Walter wrote: This is a multipart message in MIME format. --=_alternative 0065F858862573EC_= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable While I hesitate to correct David, in this case a correction is warranted. The proper command is:=20 CP TERMINAL CONMODE 3270 Perhaps David's suffering Monday Syndrome=3F Respectfully, Mike Walter=20 Hewitt Associates=20 Any opinions expressed herein are mine alone and do not necessarily=20 represent the opinions or policies of Hewitt Associates. David Boyes [EMAIL PROTECTED]=20 Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 02/11/2008 12:25 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: z/vm dfdss standalone ipl console Also, some non-VM utilities really want CONMODE 3270. If Mike=3Fs suggestio= n= =20 doesn=3Ft work, try SET CONMODE 3270 before you IPL 181, eg:=20 =20 CP SET CONMODE 3270#IPL 181 CLEAR=20 =20 (the SET CONMODE will cause CMS to choke, so be prepared). Press Enter=20 after the tape has stopped moving.=20 =20 =46rom: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On=20 Behalf Of Mike Walter Sent: Monday, February 11, 2008 1:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/vm dfdss standalone ipl console =20 Some IPLable utilities require an interrupt so that the utility can=20 identify the specific terminal to which it should reply (this goes back to= =20 ancient days of coax-connected terminals). I'm not sure about DFDSS.=20 But it can't hurt to try pressing ENTER (wherever it is mapped on your=20 3270 terminal emulator keyboard, but usually the right-Ctrl key).=20 If that doesn't work, give the ATTN or SysReq key each a try.=20 If all those fail, try pressing the PA1 key, which should cause a CP=20 READ, then enter: D PSW (or D PSWG on z/Architecture virtual machines)=20 and report back here with the displayed PSW.=20 Mike Walter=20 Hewitt Associates=20 Any opinions expressed herein are mine alone and do not necessarily=20 represent the opinions or policies of Hewitt Associates.=20 Caleb [EMAIL PROTECTED]=20 Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU=20 02/11/2008 10:29 AM=20 Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To [EMAIL PROTECTED] cc =20 Subject z/vm dfdss standalone ipl console =20 =20 =20 Hi, =20 We are running z/VM Version 5 Release 2.0 service level 0702 (64-bit)=20 We have a standalone z/OS DFDSS 1.7 which we intend to IPL=20 =66rom a z/VM guest to restore a tape backup to a dasd.=20 Upon IPL from tape (i.e. IPL 181 clear), we were able to load=20 the standalone dfdss program successfully:=20 5694-A01 DFSMSDSS STAND-ALONE v1.07.0 =20 ...=20 ADRY005E DEFINE INPUT DEVICE, REPLY 'DDD,CCUU' OR 'CONSOLE'=20 ENTER INPUT/COMMAND:=20 .=20 We reply to message above with CONSOLE ,but the program=20 just hangs without any error message. z/vm shows the status as running. Other programs such as standalone ICKDSF seems to have no problem. We know our SADFDSS is a working tape because when we ipled without z/vm, there is no problem replying CONSOLE to the ADRY0005E message. Can anyone guide me on what to check =3F thanks. Caleb -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: z/vm dfdss standalone ipl console
While I hesitate to correct David, in this case a correction is warranted. The proper command is: CP TERMINAL CONMODE 3270 Perhaps David's suffering Monday Syndrome? More like what idiot decided that Solaris kernel configuration files should be in XML syndrome. Mike is (of course) correct. My head hurts today.
Re: z/vm dfdss standalone ipl console
Also, some non-VM utilities really want CONMODE 3270. If Mike's suggestion doesn't work, try SET CONMODE 3270 before you IPL 181, eg: CP SET CONMODE 3270#IPL 181 CLEAR (the SET CONMODE will cause CMS to choke, so be prepared). Press Enter after the tape has stopped moving. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Monday, February 11, 2008 1:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/vm dfdss standalone ipl console Some IPLable utilities require an interrupt so that the utility can identify the specific terminal to which it should reply (this goes back to ancient days of coax-connected terminals). I'm not sure about DFDSS. But it can't hurt to try pressing ENTER (wherever it is mapped on your 3270 terminal emulator keyboard, but usually the right-Ctrl key). If that doesn't work, give the ATTN or SysReq key each a try. If all those fail, try pressing the PA1 key, which should cause a CP READ, then enter: D PSW (or D PSWG on z/Architecture virtual machines) and report back here with the displayed PSW. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Caleb [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 02/11/2008 10:29 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject z/vm dfdss standalone ipl console Hi, We are running z/VM Version 5 Release 2.0 service level 0702 (64-bit) We have a standalone z/OS DFDSS 1.7 which we intend to IPL from a z/VM guest to restore a tape backup to a dasd. Upon IPL from tape (i.e. IPL 181 clear), we were able to load the standalone dfdss program successfully: 5694-A01 DFSMSDSS STAND-ALONE v1.07.0 ... ADRY005E DEFINE INPUT DEVICE, REPLY 'DDD,CCUU' OR 'CONSOLE' ENTER INPUT/COMMAND: . We reply to message above with CONSOLE ,but the program just hangs without any error message. z/vm shows the status as running. Other programs such as standalone ICKDSF seems to have no problem. We know our SADFDSS is a working tape because when we ipled without z/vm, there is no problem replying CONSOLE to the ADRY0005E message. Can anyone guide me on what to check ? thanks. Caleb 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. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email.
z/vm dfdss standalone ipl console
Hi, We are running z/VM Version 5 Release 2.0 service level 0702 (64-bit) We have a standalone z/OS DFDSS 1.7 which we intend to IPL from a z/VM guest to restore a tape backup to a dasd. Upon IPL from tape (i.e. IPL 181 clear), we were able to load the standalone dfdss program successfully: 5694-A01 DFSMSDSS STAND-ALONE v1.07.0 ... ADRY005E DEFINE INPUT DEVICE, REPLY 'DDD,CCUU' OR 'CONSOLE' ENTER INPUT/COMMAND: . We reply to message above with CONSOLE ,but the program just hangs without any error message. z/vm shows the status as running. Other programs such as standalone ICKDSF seems to have no problem. We know our SADFDSS is a working tape because when we ipled without z/vm, there is no problem replying CONSOLE to the ADRY0005E message. Can anyone guide me on what to check ? thanks. Caleb
DFDSS and an IFL
I've got a site that is trying to use their VM system (4.4 on an IFL) to stage MVS volumes for disaster recovery. They dump the MVS system off using DFDSS, and restore them onto the disaster system using standalone DFDSS under VM This way they don't need to actually run and licence MVS on the recovery CPU, since MVS only runs during the actual tests. The staging allows them to drop the recovery time considerably. And the VM system is running on the IFL on the box. 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. The DFDSS being used is from a z/OS 1.7 system, they genned it onto a DAS D volume and moved it to the new VM system and IPL the DASD to bring DFDSS up to do the restore. The old CPU was a z900 and this worked just fine. Since the move to a z9-BC however, they get: HCPMCV1459E The virtual machine is placed in check-stop state due to a system malfunction with CPU 00. 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
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.
DFDSS
Title: 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
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."
Re: A question on VM/LINUX/DFDSS(MVS)
Mace, Add the COPYVOLID parameter. COPYVOLID specifies that the volser of the original source volume will be copied to the target volume. If you don't specify COPYVOLID, the target volume volser will remain the same as it was before the restore. Charlie State of Wyoming
Re: A question on VM/LINUX/DFDSS(MVS)
A q 633a shows it is the name I gave it(lprwrc) not the relabeled(origina l) name(l2pr01). So I guess I should add it as the name I gave it(lprwrc). N ow why didn't the label get overwritten?? thanks Mace
