Re: introducing NORD Linux
Leland started a discussion about read-only root over on the LINUX-390 list, which reminded me to send this note. NORD Linux has a mascot. While penguins are more common in the South, NORD's black-and-white animal is Northern. http://docs.google.com/View?id=dc6n97p5_21d4qng3c4 The mascot is at the bottom of the page. Cute, eh? My kids think so. But huskies shed ... kind of like software. :-) I keep meaning to convert the supplied root disk from an ISO image to a somewhat more ordinary EXT2 image. But these things never happen as quickly as they should. I'm planning to use this critter for DNS, so I've been working on that. Oh ... did I say DNS? Hmmm... And what TCP/IP stack that we all know and love will be losing its domain name server component? Maybe a tight service virtual machine running the latest BIND would come in handy. An important feature of NORD Linux is that it can be profiled at startup from a file in CMS space. You create (default) PROFILE SH on the 191, and it gets executed automagically. If it's missing, no pain, NORD doesn't complain. -- R; On Mon, Jun 28, 2010 at 21:44, Richard Troth vmcow...@gmail.com wrote: VM friends -- Here's something I hope to mention on the Linux/390 discussion, but thought I should share it here first because it is inspired by z/VM ... and Mother. NORD is a Linux build intended for embedded use (eg: as a service virtual machine, a rescue system, or any utility Linux). I was advised to share about it with the VM community first. NORD is, in fact, heavily inspired by VM. The whole design is based on things that are commonplace in VM. For example, just as we can replace CP and CMS without altering user content or (most) third party and add-on software, so it is with NORD. You swap out the core of the op sys ... instant upgrade. Oh, and your old disks are still there if you need to fall back. I just got burned by a Linux upgrade. It wasn't one of the major players in mainframe Linux, so I'm not picking on Mark or Brad or Shawn or any of those guys. I have seen upgrades work, but not the way most distributed systems do them (and certainly not the way upgrades are done with Linux). I'll send a second note with details. -- R;
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]
Disaster Recovery TCPIP Address Issue
Hello, Everyone. We are in the planning stages for the first disaster recovery test of our new z/VM environment. This test will be done at an offsite vender location. While discussing our requirements, the topic of TCPIP addresse s came up. Since the addresses at the offsite location will be different from our local addresses, we are at a loss as to how to change them. In our z/OS environment, we just use the vendor's floor system to make our changes. However, in the z/VM restoration we will not have a floor syste m to make similar updates. We believe we're not going to have access to their HMC where we could use the Integrated 3270 Console, but we're still trying to get final confirmation on that. My question is how do other folks get their DR vendor's IP information into and active on the restored VM system? Thanks for your help. George.
Re: Disaster Recovery TCPIP Address Issue
The DR vendor should provide you with some 3270 terminals where you can logon as TCPMAINT (Or whatever user id you use) and then make changes to the TCPIP Profile. Billy On 12 Aug 2010 at 10:13, McDonough, George wrote: Hello, Everyone. We are in the planning stages for the first disaster recovery test of our new z/VM environment. This test will be done at an offsite vender location. While discussing our requirements, the topic of TCPIP addresses came up. Since the addresses at the offsite location will be different from our local addresses, we are at a loss as to how to change them. In our z/OS environment, we just use the vendor's floor system to make our changes. However, in the z/VM restoration we will not have a floor system to make similar updates. We believe we're not going to have access to their HMC where we could use the Integrated 3270 Console, but we're still trying to get final confirmation on that. My question is how do other folks get their DR vendor's IP information into and active on the restored VM system? Thanks for your help. George.
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: Disaster Recovery TCPIP Address Issue
I use an exit in node DTCPARMS that checks the DR status using the CPU serial number, e.g. .*--- .* Add user exit to stack startup .*--- :nick.TCPIP:type.server :class.stack :exit.DRCHECK .*--- .* Add user exit to MPROUTE startup .*--- :nick.MPROUTE :type.server :class.mproute :exit.DRCHECK The exit is specific to our environment, so I won't post it. It calls another EXEC that determines whether we're in DR by checking the CPU serial number. The operator is also prompted at system startup to tell the system whether we're in a DR test or real disaster. DR tests are conducted behind a firewall, so we use different OSA's for test and real DR. For the stack, it copies a DR version of PROFILE TCPIP to TCPIP 191. For MPROUTE, it returns :Config. with the name of the appropriate MPROUTE CONFIG file. We don't use SYSTEM NETID or SYSTEM CONFIG to change the node name for DR, because we have things that are dependent on the node name. Dennis If I could not go to heaven but with a [political] party, I would not go there at all. -- Thomas Jefferson -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of McDonough, George Sent: Thursday, August 12, 2010 08:13 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Disaster Recovery TCPIP Address Issue Hello, Everyone. We are in the planning stages for the first disaster recovery test of our new z/VM environment. This test will be done at an offsite vender location. While discussing our requirements, the topic of TCPIP addresse s came up. Since the addresses at the offsite location will be different from our local addresses, we are at a loss as to how to change them. In our z/OS environment, we just use the vendor's floor system to make our changes. However, in the z/VM restoration we will not have a floor syste m to make similar updates. We believe we're not going to have access to their HMC where we could use the Integrated 3270 Console, but we're still trying to get final confirmation on that. My question is how do other folks get their DR vendor's IP information into and active on the restored VM system? Thanks for your help. George.
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: Disaster Recovery TCPIP Address Issue
Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CONFIG and if so, how do I find my current model and cpuid? Looks like the 'q cupid' will give it to me. Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 -Original Message- From: David Boyes [mailto:dbo...@sinenomine.net] Sent: Thursday, August 12, 2010 11:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Disaster Recovery TCPIP Address Issue location. While discussing our requirements, the topic of TCPIP addresses came up. Since the addresses at the offsite location will be different from our local addresses, we are at a loss as to how to change them. The vendor should be able to give you the CPUIDs of the recovery systems you'll be running on during your test. Add those to SYSTEM NETID and SYSTEM CONFIG with different node names (I use DISASTER). Once that's done, when the system comes up, you can use qualifiers in the TCPIP PROFILE and SYSTEM CONFIG to set up things with the addresses of your disaster recovery system, kinda like this (not precise syntax, so RTFM for it): NORMAL: LINK FOO DISASTER: LINK FOO Presto, no need to change anything actually AT recovery site. 8-) -- db
RSCS Messages
When a user starts a link via SMSG command, it becomes a special pal of RSCS and receives messages about that link forever or until RSCS is recycled, whichever comes first. Is there any other way of causing RSCS to quit sending the messages? I tried the SETMSG ALL OFF command and found out that I was not subscribed for any messages :-( Regards, Richard Schuh
Re: Disaster Recovery TCPIP Address Issue
All fine ideas that will work for a DR test running with DR test IP addresses (from the DR vendor's LAN?) whilst your real system remains up. If the disaster happens, will your real DR invocation system run with the DR vendor's LAN addresses? If so, how will your live TCPIP clients find your TCPIP servers? VIPA can help with this if you have different policies for DR test and Real DR. Regards, Mike Mike Wawiorko Global z Connectivity and Automation Engineering GISD Core Engineering GRB Technology Barclays Bank -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bauer, Bobby (NIH/CIT) [E] Sent: 12 August 2010 17:11 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Disaster Recovery TCPIP Address Issue Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CONFIG and if so, how do I find my current model and cpuid? Looks like the 'q cupid' will give it to me. Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 -Original Message- From: David Boyes [mailto:dbo...@sinenomine.net] Sent: Thursday, August 12, 2010 11:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Disaster Recovery TCPIP Address Issue location. While discussing our requirements, the topic of TCPIP addresses came up. Since the addresses at the offsite location will be different from our local addresses, we are at a loss as to how to change them. The vendor should be able to give you the CPUIDs of the recovery systems you'll be running on during your test. Add those to SYSTEM NETID and SYSTEM CONFIG with different node names (I use DISASTER). Once that's done, when the system comes up, you can use qualifiers in the TCPIP PROFILE and SYSTEM CONFIG to set up things with the addresses of your disaster recovery system, kinda like this (not precise syntax, so RTFM for it): NORMAL: LINK FOO DISASTER: LINK FOO Presto, no need to change anything actually AT recovery site. 8-) -- db This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC.Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised and regulated by the Financial Services Authority.
Re: Disaster Recovery TCPIP Address Issue
Bobby, For a more expansive review of using the Record Qualifiers in SYSTEM CONFIG, see the post on this listserve at: http://listserv.uark.edu/scripts/wa.exe?A2=ind1002L=IBMVMP=R6649I=-3X=1C6106111E9F2D0425Y=Mike.Walter%40hewitt.com (watch out for any URL wrap) For Bobby and EVERYONE ELSE who does not YET know how to search this listserve's archives: -- You might also want to invest a few minutes learning how to search the listserve's archives at: http://listserv.uark.edu/archives/ibmvm.html There's an incredible amount of information available from people who have already trod the path that you're just beginning to go down. Searching the archives can answer immediate questions immediately (instead of overnight), and can also help to keep you from trodding down that path with a self-inflicted gunshot wound. It is very much worth the short time learning to search the archives - especially when you need help in the middle of the night or on a weekend when fewer souls are answering posts here. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. Bauer, Bobby (NIH/CIT) [E] baue...@mail.nih.gov Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/12/2010 11:10 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Disaster Recovery TCPIP Address Issue Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CONFIG and if so, how do I find my current model and cpuid? Looks like the 'q cupid' will give it to me. Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 -Original Message- From: David Boyes [mailto:dbo...@sinenomine.net] Sent: Thursday, August 12, 2010 11:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Disaster Recovery TCPIP Address Issue location. While discussing our requirements, the topic of TCPIP addresses came up. Since the addresses at the offsite location will be different from our local addresses, we are at a loss as to how to change them. The vendor should be able to give you the CPUIDs of the recovery systems you'll be running on during your test. Add those to SYSTEM NETID and SYSTEM CONFIG with different node names (I use DISASTER). Once that's done, when the system comes up, you can use qualifiers in the TCPIP PROFILE and SYSTEM CONFIG to set up things with the addresses of your disaster recovery system, kinda like this (not precise syntax, so RTFM for it): NORMAL: LINK FOO DISASTER: LINK FOO Presto, no need to change anything actually AT recovery site. 8-) -- db 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. E-mails 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 e-mail.
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: RSCS Messages
On Thu, 12 Aug 2010 09:12:27 -0700, Schuh, Richard rsc...@visa.com wrot e: When a user starts a link via SMSG command, it becomes a special pal of RSCS and receives messages about that link forever or until RSCS is recycled, whichever comes first. Is there any other way of causing RSCS t o quit sending the messages? I tried the SETMSG ALL OFF command and found out that I was not subscribed for any messages :-( Regards, Richard Schuh Have you tried: SMSG RSCS SET linkid NOMSG ? I think logging off/on the user getting the messages will stop them also. -- Dale R. Smith
Re: RSCS Messages
Logging off has no effect - messages resume as soon as the user logs back on. However, logging RSCS off and back on would work :-) I get the same response to the SET LINK NOMSG as to the SETMSG command. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Thursday, August 12, 2010 10:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages On Thu, 12 Aug 2010 09:12:27 -0700, Schuh, Richard rsc...@visa.com wrot= e: When a user starts a link via SMSG command, it becomes a special pal of = RSCS and receives messages about that link forever or until RSCS is recycled, whichever comes first. Is there any other way of causing RSCS t= o quit sending the messages? I tried the SETMSG ALL OFF command and found = out that I was not subscribed for any messages :-( Regards, Richard Schuh Have you tried: SMSG RSCS SET linkid NOMSG ? I think logging off/on the user getting the messages will stop them also.= -- Dale R. Smith
Re: Disaster Recovery TCPIP Address Issue
Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CONFIG For the SYSTEM CONFIG changes, yes. for SYSTEM NETID, you need to make the changes on MAINT 490 and then DDR 490 to 190. Note: disruptive, so do during a maintenance window. and if so, how do I find my current model and cpuid? Looks like the 'q cupid' will give it to me. Yep. Read the notes in the CP Commands manual. Note that multiple CPUIDs can map to the same node id in the case where you could end up on one of several CECs at the recovery site.
Re: RSCS Messages
Then don't start a link, define it with autostart. We do this from time to time here, with no unwanted messages. Example: SMSG RSCS STOP PRT577 SMSG RSCS DEFINE PRT577 ASTART This actually works better then a STOP/START combination because with START the link will process any queued work, then stop. It will need another START when more work arrives. With ASTART, it will process the currently queued work PLUS anything that comes later. Peter -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: August 12, 2010 14:29 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages Logging off has no effect - messages resume as soon as the user logs back on. However, logging RSCS off and back on would work :-) I get the same response to the SET LINK NOMSG as to the SETMSG command. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Thursday, August 12, 2010 10:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages On Thu, 12 Aug 2010 09:12:27 -0700, Schuh, Richard rsc...@visa.com wrot= e: When a user starts a link via SMSG command, it becomes a special pal of = RSCS and receives messages about that link forever or until RSCS is recycled, whichever comes first. Is there any other way of causing RSCS t= o quit sending the messages? I tried the SETMSG ALL OFF command and found = out that I was not subscribed for any messages :-( Regards, Richard Schuh Have you tried: SMSG RSCS SET linkid NOMSG ? I think logging off/on the user getting the messages will stop them also.= -- Dale R. Smith The information transmitted is intended only for the person 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 any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
Re: RSCS Messages
Had to change an IP address while the system was up. It normally is ASTART but that would not work in this case, it would go to the address in the config file when RSCS started. I guess I will look for an opportune moment and recycle RSCS. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of peter.w...@ttc.ca Sent: Thursday, August 12, 2010 11:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages Then don't start a link, define it with autostart. We do this from time to time here, with no unwanted messages. Example: SMSG RSCS STOP PRT577 SMSG RSCS DEFINE PRT577 ASTART This actually works better then a STOP/START combination because with START the link will process any queued work, then stop. It will need another START when more work arrives. With ASTART, it will process the currently queued work PLUS anything that comes later. Peter -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: August 12, 2010 14:29 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages Logging off has no effect - messages resume as soon as the user logs back on. However, logging RSCS off and back on would work :-) I get the same response to the SET LINK NOMSG as to the SETMSG command. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Thursday, August 12, 2010 10:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages On Thu, 12 Aug 2010 09:12:27 -0700, Schuh, Richard rsc...@visa.com wrot= e: When a user starts a link via SMSG command, it becomes a special pal of = RSCS and receives messages about that link forever or until RSCS is recycled, whichever comes first. Is there any other way of causing RSCS t= o quit sending the messages? I tried the SETMSG ALL OFF command and found = out that I was not subscribed for any messages :-( Regards, Richard Schuh Have you tried: SMSG RSCS SET linkid NOMSG ? I think logging off/on the user getting the messages will stop them also.= -- Dale R. Smith The information transmitted is intended only for the person 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 any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
Re: RSCS Messages
Here is a little EXEC I use: /* */ trace Off smsg RSCS drain ZVMUAFC sleep 2 sec smsg RSCS delete ZVMUAFC sleep 2 sec 'smsg rscs define ZVMUAFC TYPE TCPNJE Q PRI NODE ZVMUAFC DP 5 CL * ASTART RETRY' sleep 2 sec 'smsg RSCS start ZVMUAFC PARM STREAMS=2 BUFF=8192 COMP=MAX ITO=100 OPT=YES MAXD=10 TCP=TCPIP02 HOST=192.168.75.191' EXit Thank you, Scott -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, August 12, 2010 1:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages Had to change an IP address while the system was up. It normally is ASTART but that would not work in this case, it would go to the address in the config file when RSCS started. I guess I will look for an opportune moment and recycle RSCS. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of peter.w...@ttc.ca Sent: Thursday, August 12, 2010 11:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages Then don't start a link, define it with autostart. We do this from time to time here, with no unwanted messages. Example: SMSG RSCS STOP PRT577 SMSG RSCS DEFINE PRT577 ASTART This actually works better then a STOP/START combination because with START the link will process any queued work, then stop. It will need another START when more work arrives. With ASTART, it will process the currently queued work PLUS anything that comes later. Peter -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: August 12, 2010 14:29 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages Logging off has no effect - messages resume as soon as the user logs back on. However, logging RSCS off and back on would work :-) I get the same response to the SET LINK NOMSG as to the SETMSG command. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Thursday, August 12, 2010 10:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages On Thu, 12 Aug 2010 09:12:27 -0700, Schuh, Richard rsc...@visa.com wrot= e: When a user starts a link via SMSG command, it becomes a special pal of = RSCS and receives messages about that link forever or until RSCS is recycled, whichever comes first. Is there any other way of causing RSCS t= o quit sending the messages? I tried the SETMSG ALL OFF command and found = out that I was not subscribed for any messages :-( Regards, Richard Schuh Have you tried: SMSG RSCS SET linkid NOMSG ? I think logging off/on the user getting the messages will stop them also.= -- Dale R. Smith The information transmitted is intended only for the person 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 any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
DVHDRC3457I DVHUPDIR is unable to update object directory
Just happen to notice this message when TMDISKing and was wondering what would have caused it. I saw a previous thread on this list in 2009, but, in that case, the directory truly did need to be expanded. But, I'm thinking that I should have plenty of space available: q alloc drct EXTENT EXTENT % VOLID RDEV STARTEND TOTAL IN USE HIGH USED -- -- -- -- -- -- VP2W00 261F 1 20 20 1 1 5% ACTIVE -- -- SUMMARY 20 1 5% CKD And I've done other updates since the message spewed forth without it appearing again. So, do I just ignore it??? Thanks, Leland
Re: RSCS Messages
Force it back to operator by stoping/starting the link from operator. Based on what I have seen, if the user logs off *AND* RSCS tries to send another message while the user is logged off, then it reverts back to the operator automatically. Tony Thigpen -Original Message - From: Schuh, Richard Sent: 08/12/2010 12:12 PM When a user starts a link via SMSG command, it becomes a special pal of RSCS and receives messages about that link forever or until RSCS is recycled, whichever comes first. Is there any other way of causing RSCS to quit sending the messages? I tried the SETMSG ALL OFF command and found out that I was not subscribed for any messages :-( Regards, Richard Schuh
Re: RSCS Messages
Having the operator do anything other than a simple START, including PARM anything requires an approval process. That said, a scan of the config file reveals that an id that rarely logs on is authorized. I will use it as my surrogate. Thanks for the idea. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tony Thigpen Sent: Thursday, August 12, 2010 1:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages Force it back to operator by stoping/starting the link from operator. Based on what I have seen, if the user logs off *AND* RSCS tries to send another message while the user is logged off, then it reverts back to the operator automatically. Tony Thigpen -Original Message - From: Schuh, Richard Sent: 08/12/2010 12:12 PM When a user starts a link via SMSG command, it becomes a special pal of RSCS and receives messages about that link forever or until RSCS is recycled, whichever comes first. Is there any other way of causing RSCS to quit sending the messages? I tried the SETMSG ALL OFF command and found out that I was not subscribed for any messages :-( Regards, Richard Schuh
Re: RSCS Messages
Did you try using SET linkid NOMSG? Ron On Thu, Aug 12, 2010 at 2:18 PM, Schuh, Richard rsc...@visa.com wrote: Having the operator do anything other than a simple START, including PARM anything requires an approval process. That said, a scan of the config file reveals that an id that rarely logs on is authorized. I will use it as my surrogate. Thanks for the idea. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tony Thigpen Sent: Thursday, August 12, 2010 1:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages Force it back to operator by stoping/starting the link from operator. Based on what I have seen, if the user logs off *AND* RSCS tries to send another message while the user is logged off, then it reverts back to the operator automatically. Tony Thigpen -Original Message - From: Schuh, Richard Sent: 08/12/2010 12:12 PM When a user starts a link via SMSG command, it becomes a special pal of RSCS and receives messages about that link forever or until RSCS is recycled, whichever comes first. Is there any other way of causing RSCS to quit sending the messages? I tried the SETMSG ALL OFF command and found out that I was not subscribed for any messages :-( Regards, Richard Schuh
Re: RSCS Messages
Suggestion time. My auditors always had me use two different userids. My primary only had 'normal' access while my secondary user had full class-A access and was the one listed in RSCS, etc. as an authorized user. (I was the System's Programming manager in a small shop and my duties included being the security manager also.) The auditor received a report of any logons to that ID so I had to log what function I performed using that userid. Just like not giving root access to your normal linux id. Anyway, you might want to set up a secondary userid for yourself and such a userid could have been used to pull back the RSCS messages. Tony Thigpen -Original Message - From: Schuh, Richard Sent: 08/12/2010 04:18 PM Having the operator do anything other than a simple START, including PARM anything requires an approval process. That said, a scan of the config file reveals that an id that rarely logs on is authorized. I will use it as my surrogate. Thanks for the idea. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tony Thigpen Sent: Thursday, August 12, 2010 1:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages Force it back to operator by stoping/starting the link from operator. Based on what I have seen, if the user logs off *AND* RSCS tries to send another message while the user is logged off, then it reverts back to the operator automatically. Tony Thigpen -Original Message - From: Schuh, Richard Sent: 08/12/2010 12:12 PM When a user starts a link via SMSG command, it becomes a special pal of RSCS and receives messages about that link forever or until RSCS is recycled, whichever comes first. Is there any other way of causing RSCS to quit sending the messages? I tried the SETMSG ALL OFF command and found out that I was not subscribed for any messages :-( Regards, Richard Schuh
Re: RSCS Messages
The CP for command may be your friend here; after all, SMSG IS a CP command... -- Mike Harding z/VM System Support The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 08/12/2010 01:18:40 PM: From: Schuh, Richard rsc...@visa.com To: IBMVM@LISTSERV.UARK.EDU Date: 08/12/2010 01:19 PM Subject: Re: RSCS Messages Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Having the operator do anything other than a simple START, including PARM anything requires an approval process. That said, a scan of the config file reveals that an id that rarely logs on is authorized. I will use it as my surrogate. Thanks for the idea. Regards, Richard Schuh
DTCSS022E
Greetings, I am trying to use the services of SSL server for telnet and getting the nasty message of: DTCSSL022E Handshake failed: rc: 6 reason: Key label is not found. Please clue me on where this label is expected to be. I thought this same setup had worked in the past but not now! This is on zVM 5.4. Thanks. Suleiman Shahin
Re: RSCS Messages
I have a secondary id;, it is the class G, unauthorized id. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tony Thigpen Sent: Thursday, August 12, 2010 1:29 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages Suggestion time. My auditors always had me use two different userids. My primary only had 'normal' access while my secondary user had full class-A access and was the one listed in RSCS, etc. as an authorized user. (I was the System's Programming manager in a small shop and my duties included being the security manager also.) The auditor received a report of any logons to that ID so I had to log what function I performed using that userid. Just like not giving root access to your normal linux id. Anyway, you might want to set up a secondary userid for yourself and such a userid could have been used to pull back the RSCS messages. Tony Thigpen -Original Message - From: Schuh, Richard Sent: 08/12/2010 04:18 PM Having the operator do anything other than a simple START, including PARM anything requires an approval process. That said, a scan of the config file reveals that an id that rarely logs on is authorized. I will use it as my surrogate. Thanks for the idea. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tony Thigpen Sent: Thursday, August 12, 2010 1:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages Force it back to operator by stoping/starting the link from operator. Based on what I have seen, if the user logs off *AND* RSCS tries to send another message while the user is logged off, then it reverts back to the operator automatically. Tony Thigpen -Original Message - From: Schuh, Richard Sent: 08/12/2010 12:12 PM When a user starts a link via SMSG command, it becomes a special pal of RSCS and receives messages about that link forever or until RSCS is recycled, whichever comes first. Is there any other way of causing RSCS to quit sending the messages? I tried the SETMSG ALL OFF command and found out that I was not subscribed for any messages :-( Regards, Richard Schuh
Re: RSCS Messages
Not to worry. The MVS system caused the link to go down. It came up with the IP address from the last startup, so a special pass was issued for recycling RSCS. That will end the messages. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Michael Harding Sent: Thursday, August 12, 2010 1:29 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Messages The CP for command may be your friend here; after all, SMSG IS a CP command... -- Mike Harding z/VM System Support The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 08/12/2010 01:18:40 PM: From: Schuh, Richard rsc...@visa.com To: IBMVM@LISTSERV.UARK.EDU Date: 08/12/2010 01:19 PM Subject: Re: RSCS Messages Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Having the operator do anything other than a simple START, including PARM anything requires an approval process. That said, a scan of the config file reveals that an id that rarely logs on is authorized. I will use it as my surrogate. Thanks for the idea. Regards, Richard Schuh
Re: Disaster Recovery TCPIP Address Issue
Hi. To copy 490 to 190, the better option is to use PUT2PROD CMS. Do it and more... No disruptive, and this update the CMS segment too. Regards, Clóvis | | From: | | --| |David Boyes dbo...@sinenomine.net | --| | | To:| | --| |IBMVM@LISTSERV.UARK.EDU | --| | | Date: | | --| |12/08/2010 15:36 | --| | | Subject: | | --| |Re: Disaster Recovery TCPIP Address Issue | --| | | Sent by: | | --| |The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU | --| Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CONFIG For the SYSTEM CONFIG changes, yes. for SYSTEM NETID, you need to make the changes on MAINT 490 and then DDR 490 to 190. Note: disruptive, so do during a maintenance window. and if so, how do I find my current model and cpuid? Looks like the 'q cupid' will give it to me. Yep. Read the notes in the CP Commands manual. Note that multiple CPUIDs can map to the same node id in the case where you could end up on one of several CECs at the recovery site.
Re: DTCSS022E
On Thursday, 08/12/2010 at 04:29 EDT, Suleiman Shahin s_s_sha...@hotmail.com wrote: I am trying to use the services of SSL server for telnet and getting the nasty message of: DTCSSL022E Handshake failed: rc: 6 reason: Key label is not found. Please clue me on where this label is expected to be. I thought this same setup had worked in the past but not now! This is on zVM 5.4. It means that the TLSLABEL specified on InternalClientParms in PROFILE TCPIP is not a known label in the certificate database. When you added the cert to your database, did you remember to use an UPPERCASE label Alan Altmark z/VM Development IBM Endicott
Re: DTCSS022E
That's more of a dilemma :( I did not do that part but inherited the deal from a departed co-worker. Is there a way to dig up those labels? From: alan_altm...@us.ibm.com the cert to your database, did you remember to use an UPPERCASE label Alan Altmark z/VM Development IBM Endicott
Re: DTCSS022E
Thanks You Larry Davis -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Suleiman Shahin Sent: Thursday, August 12, 2010 5:03 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DTCSS022E That's more of a dilemma :( I did not do that part but inherited the deal from a departed co-worker. Is there a way to dig up those labels? From: alan_altm...@us.ibm.com the cert to your database, did you remember to use an UPPERCASE label 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: DTCSS022E
On Thursday, 08/12/2010 at 05:02 EDT, Suleiman Shahin s_s_sha...@hotmail.com wrote: That's more of a dilemma :( I did not do that part but inherited the deal from a departed co-worker. Is there a way to dig up those labels? You need to read Chapter 20 of the TCP/IP Planning book (SSL server config) and Chapter 15 of the TCP/IP LDAP Admin book. gskkeyman is how you manage certificates. Be sure to read the SSL chapter first. Alan Altmark z/VM Development IBM Endicott
Re: Disaster Recovery TCPIP Address Issue
Why should changing the SYSTEM NETID on 190 have to be disruptive? Make the change to that file only and do a SAVESYS CMS. To keep things in step, copy the new SYSTEM NETID to 490 with OLDD. Anything that's using SYSTEM NETID will still be seeing the old info but that old file relates to the system in use at the moment. Jim On 8/12/2010 2:40 PM, David Boyes wrote: Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CON= FIG=20 For the SYSTEM CONFIG changes, yes. for SYSTEM NETID, you need to make the = changes on MAINT 490 and then DDR 490 to 190. Note: disruptive, so do durin= g a maintenance window.=20 and if so, how do I find my current model and cpuid? Looks like the 'q cupid' will give it to me. Yep. Read the notes in the CP Commands manual.=20 Note that multiple CPUIDs can map to the same node id in the case where you= could end up on one of several CECs at the recovery site. = -- James Bohnsack (972) 596-6377 home/office (972) 342-5823 cell
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: Disaster Recovery TCPIP Address Issue
On Thursday, 08/12/2010 at 05:14 EDT, Jim Bohnsack jab...@cornell.edu wrote: Why should changing the SYSTEM NETID on 190 have to be disruptive? Make the change to that file only and do a SAVESYS CMS. To keep things in step, copy the new SYSTEM NETID to 490 with OLDD. Anything that's using SYSTEM NETID will still be seeing the old info but that old file relates to the system in use at the moment. He said DDR, which is disruptive to the 190 disk. Error 3 reading file. Alan Altmark z/VM Development IBM Endicott Pt. Hey, Buddy. Over here. No, over *here*. It' me. Yes, you know who. Wanna know a secret? They (please, no names) are planning to update PUT2PROD in the next release to update production disks by using the technique you describe. I overheard them at the water cooler. Then they started talking about quantum-correlated twin photons and LGR. Whatever that is, it sounds kul. Bye.
Re: DTCSS022E
Thanks very much. Suleiman Shahin You need to read Chapter 20 of the TCP/IP Planning book (SSL server config) and Chapter 15 of the TCP/IP LDAP Admin book. gskkeyman is how you manage certificates. Be sure to read the SSL chapter first.
Re: Disaster Recovery TCPIP Address Issue
Yeah, I know he said DDR, but note that I said Make the change to that file only. Maybe I should have said Make the change to that file only rather than using DDR, but I figured that David's a big boy now. Glad to hear that there is to be an expected improvement to PUT2PROD. Jim On 8/12/2010 5:26 PM, Alan Altmark wrote: On Thursday, 08/12/2010 at 05:14 EDT, Jim Bohnsackjab...@cornell.edu wrote: Why should changing the SYSTEM NETID on 190 have to be disruptive? Make the change to that file only and do a SAVESYS CMS. To keep things in step, copy the new SYSTEM NETID to 490 with OLDD. Anything that's using SYSTEM NETID will still be seeing the old info but that old file relates to the system in use at the moment. He said DDR, which is disruptive to the 190 disk. Error 3 reading file. Alan Altmark z/VM Development IBM Endicott Pt. Hey, Buddy. Over here. No, over *here*. It' me. Yes, you know who. Wanna know a secret? They (please, no names) are planning to update PUT2PROD in the next release to update production disks by using the technique you describe. I overheard them at the water cooler. Then they started talking about quantum-correlated twin photons and LGR. Whatever that is, it sounds kul. Bye. -- James Bohnsack (972) 596-6377 home/office (972) 342-5823 cell
Re: Disaster Recovery TCPIP Address Issue
Alan is easily distracted... it's almost like someone else was at the keyboard... On 08/12/2010 04:26 PM, Alan Altmark wrote: Pt. Hey, Buddy. Over here. No, over *here*. It' me. Yes, you know who. Wanna know a secret? They (please, no names) are planning to update PUT2PROD in the next release to update production disks by using the technique you describe. I overheard them at the water cooler. Then they started talking about quantum-correlated twin photons and LGR. Whatever that is, it sounds kul. Bye. -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2011 - April 15-19, 2011 Colorado Springs, CO
OT: Our (maybe not so) regular reminder...
Cross posted to ibmvm, linux390 and vse-l. Sorry for duplications. As a reminder... The VSE, z/VM and Linux for System z job postings site can be found at: http://www.velocitysoftware.com/jobs/ -- Rich Smrcina Velocity Software, Inc. Phone: 414-491-6001 http://www.velocitysoftware.com Catch the WAVV! http://www.wavv.org WAVV 2011 - April 15-19, 2011 Colorado Springs, CO
AUTO: Lionel Dyck is out of the office (returning 08/16/2010)
I am out of the office until 08/16/2010. I am out of the office. Call my cell if this is an emergency. Note: This is an automated response to your message Re: Disaster Recovery TCPIP Address Issue sent on 8/12/10 17:19:58. This is the only notification you will receive while this person is away.
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
