Re: SYSPLEX/CFRM Couple dataset(s) relationship
Mark, I don't know but we used to run into the same problem at DR until we started defining our CFRM policy with 4 CFs. CF1 and CF2 are the ones at home. CF3 and CF4 are the ones at DR. I define the policies with a preflist of (CF1,CF2,CF3,CF4). Now when we're at home or DR IPL proceeds without a hitch. I think I got the idea for doing this from a post on this list a few years ago. Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Jacobs Sent: Thursday, April 08, 2010 09:31 To: IBM-MAIN@bama.ua.edu Subject: SYSPLEX/CFRM Couple dataset(s) relationship At our last DR exercise we had an incorrect CPU serial number in our CFRM policy which resulted in a failure in our IPL. We fixed the CFRM policy and re-wrote it replacing the incorrect policy (same policy name). When we re-ipled, the system was still looking for the CF lpar with the incorrect CPU serial number even though the CFRM policy with the old serial number wasn't in the CFRM dataset. We couldn't get the system to IPL until I deleted and redefined the SYSPLEX couple dataset. Does the sysplex couple dataset retain information about the CFRM policy in use other than the name of the last used CFRM policy? -- Mark Jacobs Time Customer Service Tampa, FL It is impossible to make anything foolproof, because fools are so ingenious. -- Robert Heinlein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
"Mark Jacobs" wrote in message news:<4bbde8bb.6070...@custserv.com>... > At our last DR exercise we had an incorrect CPU serial number in our > CFRM policy which resulted in a failure in our IPL. We fixed the CFRM > policy and re-wrote it replacing the incorrect policy (same policy name). > > When we re-ipled, the system was still looking for the CF lpar with the > incorrect CPU serial number even though the CFRM policy with the old > serial number wasn't in the CFRM dataset. We couldn't get the system to > IPL until I deleted and redefined the SYSPLEX couple dataset. > > Does the sysplex couple dataset retain information about the CFRM policy > in use other than the name of the last used CFRM policy? > > -- > Mark Jacobs Yes, the CDS contains a number of slots to hold defined policies and 1 slot for the "active" policy. This one is used at IPL and can only be changed by activating a policy from on of the defined policies. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
Skip has talked about this in the past and in SHARE sessions. What we have done for years is use a different "newly formatted" sysplex couple and CFRM couple data sets that we IPL with during DR. This has also been discussed. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ On Thu, 8 Apr 2010 09:39:36 -0500, Field, Alan C. wrote: >Mark, I don't know but we used to run into the same problem at DR until >we started defining our CFRM policy with 4 CFs. > >CF1 and CF2 are the ones at home. CF3 and CF4 are the ones at DR. > >I define the policies with a preflist of (CF1,CF2,CF3,CF4). > >Now when we're at home or DR IPL proceeds without a hitch. > >I think I got the idea for doing this from a post on this list a few >years ago. > >Alan > >-Original Message- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On >Behalf Of Mark Jacobs >Sent: Thursday, April 08, 2010 09:31 >To: IBM-MAIN@bama.ua.edu >Subject: SYSPLEX/CFRM Couple dataset(s) relationship > >At our last DR exercise we had an incorrect CPU serial number in our >CFRM policy which resulted in a failure in our IPL. We fixed the CFRM >policy and re-wrote it replacing the incorrect policy (same policy >name). > >When we re-ipled, the system was still looking for the CF lpar with the >incorrect CPU serial number even though the CFRM policy with the old >serial number wasn't in the CFRM dataset. We couldn't get the system to >IPL until I deleted and redefined the SYSPLEX couple dataset. > >Does the sysplex couple dataset retain information about the CFRM policy > >in use other than the name of the last used CFRM policy? > >-- >Mark Jacobs >Time Customer Service >Tampa, FL > > >It is impossible to make anything foolproof, because fools >are so ingenious. > > -- Robert Heinlein > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
On 04/08/10 11:07, Mark Zelden wrote: Skip has talked about this in the past and in SHARE sessions. What we have done for years is use a different "newly formatted" sysplex couple and CFRM couple data sets that we IPL with during DR. This has also been discussed. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ That's what we do at DR also. I was wondering if the first IPL with the incorrect CFRM policy 'corrupted' the sysplex couple dataset in such a way that it didn't re-read the CFRM couple dataset for the policy which was rewritten with the correct CPU serial number. Mark Jacobs On Thu, 8 Apr 2010 09:39:36 -0500, Field, Alan C. wrote: Mark, I don't know but we used to run into the same problem at DR until we started defining our CFRM policy with 4 CFs. CF1 and CF2 are the ones at home. CF3 and CF4 are the ones at DR. I define the policies with a preflist of (CF1,CF2,CF3,CF4). Now when we're at home or DR IPL proceeds without a hitch. I think I got the idea for doing this from a post on this list a few years ago. Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Jacobs Sent: Thursday, April 08, 2010 09:31 To: IBM-MAIN@bama.ua.edu Subject: SYSPLEX/CFRM Couple dataset(s) relationship At our last DR exercise we had an incorrect CPU serial number in our CFRM policy which resulted in a failure in our IPL. We fixed the CFRM policy and re-wrote it replacing the incorrect policy (same policy name). When we re-ipled, the system was still looking for the CF lpar with the incorrect CPU serial number even though the CFRM policy with the old serial number wasn't in the CFRM dataset. We couldn't get the system to IPL until I deleted and redefined the SYSPLEX couple dataset. Does the sysplex couple dataset retain information about the CFRM policy in use other than the name of the last used CFRM policy? -- Mark Jacobs Time Customer Service Tampa, FL It is impossible to make anything foolproof, because fools are so ingenious. -- Robert Heinlein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark Jacobs Time Customer Service Tampa, FL It is impossible to make anything foolproof, because fools are so ingenious. -- Robert Heinlein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
Mark, It's not sufficient to define a new CFRM policy containing the corrected CPU number. Using the IXCMIAPU utility to define a new policy or update an existing policy only stores that policy in what you might think of as a standby state in the CFRM CDS. In order to activate a stored policy, you must start it with a SETXCF START,POLICY... command. Did you perhaps omit that step? The sysplex CDS does not contain any information about the CFRM policy in use. What it contains is information about the CDS configuration that was last used for all CDS types. Without a more detailed explanation of the steps you executed in establishing your CDS configuration, I can't immediately explain why redefining your sysplex CDS would have enabled you to reIPL. Bill Neiman Parallel Sysplex development, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
The failing IPL was the first one in our DR sysplex, so it wasn't possible to issue the SETXCF command. We depend on the CFRMPOL statement in our DR COUPLExx member to pull in our defined CFRM policy. I'm assuming that once we ipled with our bad CFRM policy the sysplex couple dataset was primed with the 'active' CFRM policy so it never looked at the updated CFRM policy in the CFRM couple dataset. A delete/redefine of the sysplex couple dataset resulted in the next IPL using CFRMPOL in our COUPLExx member pulling in the corrected CFRM policy. I'm just trying to confirm my assumption. Mark Jacobs -Original Message- From: IBM Mainframe Discussion List on behalf of Bill Neiman Sent: Fri 4/9/2010 9:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSPLEX/CFRM Couple dataset(s) relationship Mark, It's not sufficient to define a new CFRM policy containing the corrected CPU number. Using the IXCMIAPU utility to define a new policy or update an existing policy only stores that policy in what you might think of as a standby state in the CFRM CDS. In order to activate a stored policy, you must start it with a SETXCF START,POLICY... command. Did you perhaps omit that step? The sysplex CDS does not contain any information about the CFRM policy in use. What it contains is information about the CDS configuration that was last used for all CDS types. Without a more detailed explanation of the steps you executed in establishing your CDS configuration, I can't immediately explain why redefining your sysplex CDS would have enabled you to reIPL. Bill Neiman Parallel Sysplex development, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
Interesting case... I doubt that any CF info (like Lpar Id or Serial #) is saved in the Sysplex CDS. Maybe (I'm thinking) the CFRM CDS keeps 2 separate sections, one for the active policy and another section for the 'saved' policies, so when you updated the policy (with the right CF information) you actually updated the saved-policy portion but the 'active' policy kept the wrong CF info. Something that IBM can confirm. Regards. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
Mark, The sysplex CDS contains no information whatsoever about the CFRM policy or anything in it. The COUPLExx CFRMPOL statement only takes effect when there is no active CFRM policy. It won't help you if you are using the CFRM CDS from your production site, or if you have mirrored the CFRM CDS from your production site. In those cases, the CFRM CDS contains the active policy that was last in use in production, and CFRMPOL is irrelevant. (This is one of the reasons why IBM strongly recommends that you do not mirror packs containing the CFRM CDS.) CFRMPOL is intended for the case when you are IPLing with a freshly-formatted CFRM CDS which has had policies defined but which has never been used. The only way I can make sense out of your scenario is if you deleted and redefined your CFRM CDS, in which case the CFRMPOL specification would have allowed you to come up with your corrected policy. Deleting and redefining the sysplex CDS shouldn't have any bearing on the situation. Bill Neiman Parallel Sysplex development, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
I believe simply rewriting the policy was not sufficient. Please tell me if this is what you did: 1) First IPL at DR site specified CFRM CDS data set "one". This IPL specified CFRMPOL(policy_a). "Policy_a" was not correct. 2) Second IPL at DR site used the exact same CFRM CDS as in attempt 1. In this IPL, you specified CFRMPOL(policy_b) or else you specified CFRMPOL(policy_a) having first rewritten "policy_a" in the CFRM CDS prior to the IPL. This fails because the CFRMPOL parameter is only acted upon if there is NO active policy in the CFRM CDS. Here's the way I think about this, to keep this straight in my own mind: Whenever it is necessary to IPL at DR with a new CFRM policy, the CFRM CDS must be newly created. By the way, in my experience, the Sysplex CDS has nothing to do with this at all - this is strictly a matter of whether the CFRM CDS data set has an active policy in it, or if instead the CFRM CDS data set is newly allocated and empty when the new DR policy is loaded into it. Here's a good explanation of the one-shot nature of the CFRMPOL parameterm from Setting Up a Sysplex: -=-=-=-=-=- 4.4.2 Performing System Level Initialization CFRM performs system level initialization based on the state of the active CFRM policy. Valid CFRM policy states are: o The CFRM couple data set contains an active policy that is empty, that is, there is no currently active CFRM policy, either a policy that was never started or policy usage was stopped. A policy is activated either by issuing a SETXCF START,POLICY command or specifying CFRMPOL(POLICY-NAME) in the COUPLExx parmlib member used when the sysplex is IPLed. Policy usage is stopped by issuing a SETXCF STOP,POLICY command. o The CFRM couple data set contains an active policy that was properly defined with the administrative data utility and then activated either by using the SETXCF START command or the CFRMPOL parameter in the COUPLExx parmlib member. -=-=-=-=-=- At your first IPL, you can use CFRMPOL to load an appropriate CFRM policy. But, this only works once - if you make a mistake, you need to delete/define new CFRM CDS data sets (to make them empty again) and reload the policy, otherwise your next IPL will use the same policy as was activated by the first IPL. Brian On Thu, 8 Apr 2010 10:31:23 -0400, Mark Jacobs wrote: >At our last DR exercise we had an incorrect CPU serial number in our >CFRM policy which resulted in a failure in our IPL. We fixed the CFRM >policy and re-wrote it replacing the incorrect policy (same policy name). > >When we re-ipled, the system was still looking for the CF lpar with the >incorrect CPU serial number even though the CFRM policy with the old >serial number wasn't in the CFRM dataset. We couldn't get the system to >IPL until I deleted and redefined the SYSPLEX couple dataset. > >Does the sysplex couple dataset retain information about the CFRM policy >in use other than the name of the last used CFRM policy? > >-- >Mark Jacobs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
Basically you hit the high points of the steps that occurred during the test with one exception. I did delete and redefine the CFRM dataset writing the correct policy into it. We ipled again and the d**m system was still looking for the coupling facility on the incorrect CPU. I then did the only other thing I could think of which was to delete and redefine the sysplex couple dataset and try again. Mark Jacobs -Original Message- From: IBM Mainframe Discussion List on behalf of Brian Peterson Sent: Fri 4/9/2010 2:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSPLEX/CFRM Couple dataset(s) relationship I believe simply rewriting the policy was not sufficient. Please tell me if this is what you did: 1) First IPL at DR site specified CFRM CDS data set "one". This IPL specified CFRMPOL(policy_a). "Policy_a" was not correct. 2) Second IPL at DR site used the exact same CFRM CDS as in attempt 1. In this IPL, you specified CFRMPOL(policy_b) or else you specified CFRMPOL(policy_a) having first rewritten "policy_a" in the CFRM CDS prior to the IPL. This fails because the CFRMPOL parameter is only acted upon if there is NO active policy in the CFRM CDS. Here's the way I think about this, to keep this straight in my own mind: Whenever it is necessary to IPL at DR with a new CFRM policy, the CFRM CDS must be newly created. By the way, in my experience, the Sysplex CDS has nothing to do with this at all - this is strictly a matter of whether the CFRM CDS data set has an active policy in it, or if instead the CFRM CDS data set is newly allocated and empty when the new DR policy is loaded into it. Here's a good explanation of the one-shot nature of the CFRMPOL parameterm from Setting Up a Sysplex: -=-=-=-=-=- 4.4.2 Performing System Level Initialization CFRM performs system level initialization based on the state of the active CFRM policy. Valid CFRM policy states are: o The CFRM couple data set contains an active policy that is empty, that is, there is no currently active CFRM policy, either a policy that was never started or policy usage was stopped. A policy is activated either by issuing a SETXCF START,POLICY command or specifying CFRMPOL(POLICY-NAME) in the COUPLExx parmlib member used when the sysplex is IPLed. Policy usage is stopped by issuing a SETXCF STOP,POLICY command. o The CFRM couple data set contains an active policy that was properly defined with the administrative data utility and then activated either by using the SETXCF START command or the CFRMPOL parameter in the COUPLExx parmlib member. -=-=-=-=-=- At your first IPL, you can use CFRMPOL to load an appropriate CFRM policy. But, this only works once - if you make a mistake, you need to delete/define new CFRM CDS data sets (to make them empty again) and reload the policy, otherwise your next IPL will use the same policy as was activated by the first IPL. Brian On Thu, 8 Apr 2010 10:31:23 -0400, Mark Jacobs wrote: >At our last DR exercise we had an incorrect CPU serial number in our >CFRM policy which resulted in a failure in our IPL. We fixed the CFRM >policy and re-wrote it replacing the incorrect policy (same policy name). > >When we re-ipled, the system was still looking for the CF lpar with the >incorrect CPU serial number even though the CFRM policy with the old >serial number wasn't in the CFRM dataset. We couldn't get the system to >IPL until I deleted and redefined the SYSPLEX couple dataset. > >Does the sysplex couple dataset retain information about the CFRM policy >in use other than the name of the last used CFRM policy? > >-- >Mark Jacobs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
I agree with you that deleting the CFRM CDS should have fixed our problem but I'm 99% sure I deleted and redefined and it still didn't work. Deleting and redefining the sysplex CDS and re-ipling did. Mark Jacobs -Original Message- From: IBM Mainframe Discussion List on behalf of Bill Neiman Sent: Fri 4/9/2010 2:19 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSPLEX/CFRM Couple dataset(s) relationship Mark, The sysplex CDS contains no information whatsoever about the CFRM policy or anything in it. The COUPLExx CFRMPOL statement only takes effect when there is no active CFRM policy. It won't help you if you are using the CFRM CDS from your production site, or if you have mirrored the CFRM CDS from your production site. In those cases, the CFRM CDS contains the active policy that was last in use in production, and CFRMPOL is irrelevant. (This is one of the reasons why IBM strongly recommends that you do not mirror packs containing the CFRM CDS.) CFRMPOL is intended for the case when you are IPLing with a freshly-formatted CFRM CDS which has had policies defined but which has never been used. The only way I can make sense out of your scenario is if you deleted and redefined your CFRM CDS, in which case the CFRMPOL specification would have allowed you to come up with your corrected policy. Deleting and redefining the sysplex CDS shouldn't have any bearing on the situation. Bill Neiman Parallel Sysplex development, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
One option which works for me.. Define a DR specific CFRM CPL dataset on live system. Define DR specific CFRM in this DR specific CPL dataset. Specify DR specific CFRM policy / DR specific couple dataset in DR specific couple member. Mirror DR specific CFRM dataset. Hope this helps. Rajesh -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Jacobs Sent: Friday, April 09, 2010 3:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSPLEX/CFRM Couple dataset(s) relationship I agree with you that deleting the CFRM CDS should have fixed our problem but I'm 99% sure I deleted and redefined and it still didn't work. Deleting and redefining the sysplex CDS and re-ipling did. Mark Jacobs -Original Message- From: IBM Mainframe Discussion List on behalf of Bill Neiman Sent: Fri 4/9/2010 2:19 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSPLEX/CFRM Couple dataset(s) relationship Mark, The sysplex CDS contains no information whatsoever about the CFRM policy or anything in it. The COUPLExx CFRMPOL statement only takes effect when there is no active CFRM policy. It won't help you if you are using the CFRM CDS from your production site, or if you have mirrored the CFRM CDS from your production site. In those cases, the CFRM CDS contains the active policy that was last in use in production, and CFRMPOL is irrelevant. (This is one of the reasons why IBM strongly recommends that you do not mirror packs containing the CFRM CDS.) CFRMPOL is intended for the case when you are IPLing with a freshly-formatted CFRM CDS which has had policies defined but which has never been used. The only way I can make sense out of your scenario is if you deleted and redefined your CFRM CDS, in which case the CFRMPOL specification would have allowed you to come up with your corrected policy. Deleting and redefining the sysplex CDS shouldn't have any bearing on the situation. Bill Neiman Parallel Sysplex development, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Please do not transmit orders or instructions regarding a UBS account electronically, including but not limited to e-mail, fax, text or instant messaging. The information provided in this e-mail or any attachments is not an official transaction confirmation or account statement. For your protection, do not include account numbers, Social Security numbers, credit card numbers, passwords or other non-public information in your e-mail. Because the information contained in this message may be privileged, confidential, proprietary or otherwise protected from disclosure, please notify us immediately by replying to this message and deleting it from your computer if you have received this communication in error. Thank you. UBS Financial Services Inc. UBS Financial Services Incorporated of Puerto Rico UBS AG UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
Without logs, it is only my imagination where debugging takes place. Given that disclaimer When you said you did "delete and redefine the CFRM dataset", is it possible that you actually created a new CFRM dataset, and then tried to update COUPLExx with the new data set names and/or volser for your IPL? I am asking this, because one thing the Sysplex CDS does keep is the data set name and volume serial number of the various other couple CDS data sets used by the sysplex. So, if you thought you were using a new CDS by updating COUPLExx, you might not have. When I do DR tests, I delete and create empty a CFRM CDS on the same volume with the same name as my original, and then load that new CDS with my DR CFRM policy. It is when using this technique that IPL is always clean the first time - the CFRMPOL is processed, and DR IPL works. Just a thought. Brian On Fri, 9 Apr 2010 15:54:49 -0400, Mark Jacobs wrote: >Basically you hit the high points of the steps that occurred during the test with one exception. I did delete and redefine the CFRM dataset writing the correct policy into it. We ipled again and the d**m system was still looking for the coupling facility on the incorrect CPU. I then did the only other thing I could think of which was to delete and redefine the sysplex couple dataset and try again. > >Mark Jacobs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
I deleted and redefined the CFRM dataset using the same name and volser so no change to the couplexx member was needed. Mark Jacobs -Original Message- From: IBM Mainframe Discussion List on behalf of Brian Peterson Sent: Fri 4/9/2010 5:17 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSPLEX/CFRM Couple dataset(s) relationship Without logs, it is only my imagination where debugging takes place. Given that disclaimer When you said you did "delete and redefine the CFRM dataset", is it possible that you actually created a new CFRM dataset, and then tried to update COUPLExx with the new data set names and/or volser for your IPL? I am asking this, because one thing the Sysplex CDS does keep is the data set name and volume serial number of the various other couple CDS data sets used by the sysplex. So, if you thought you were using a new CDS by updating COUPLExx, you might not have. When I do DR tests, I delete and create empty a CFRM CDS on the same volume with the same name as my original, and then load that new CDS with my DR CFRM policy. It is when using this technique that IPL is always clean the first time - the CFRMPOL is processed, and DR IPL works. Just a thought. Brian On Fri, 9 Apr 2010 15:54:49 -0400, Mark Jacobs wrote: >Basically you hit the high points of the steps that occurred during the test with one exception. I did delete and redefine the CFRM dataset writing the correct policy into it. We ipled again and the d**m system was still looking for the coupling facility on the incorrect CPU. I then did the only other thing I could think of which was to delete and redefine the sysplex couple dataset and try again. > >Mark Jacobs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
Mark, >I agree with you that deleting the CFRM CDS should have fixed our problem >but I'm 99% sure I deleted and redefined and it still didn't work. Deleting >and >redefining the sysplex CDS and re-ipling did. I think back in 2004 or 2005 I ran into the same problem. Ever since I've made it a policy to delete and redefine the primary sysplex CDS for DR. That way, if there is a CFRM policy change, we cold-start the sysplex(es), up to twice a year (whenever we do DR). I also remember being met with shaking heads on ibmmain when I mentioned this, on the grounds that you should never have to cold-start a sysplex. In my experience, it keeps things clean. A D XCF,CPL for instance would still show an ARM CDS that had been deleted in the last millenium - until I cold-started. Regards, Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSPLEX/CFRM Couple dataset(s) relationship
We have done quite a lot of DR testing in the last year and a half. We defined all coupling facilities in our active CFRM policy, the same way Alan C. Field described, and never had a problem IPLing our sysplex. The only difference is that we start JES2 with RECONFIG parameter, to set the CKPT1 (allocated in a coupling facility) to INUSE=NO, so that the CKPT2 will be used. Never had any problems going back either. With applications it is not so easy, but starting a sysplex is just a routine. The tests were done with z/OS 1.9 and 1.10. -- Zaromil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
