Re: Creating new SMS environment in a monoplex
There is regularly confusion about the term Plex and Sysplex. There a many Plexes: JESPLEX (MAS) GRSPLEX MIMPLEX SMSPLEX SAPLEX and SA-SUBPLEX IMSPLEX DB2PLEX CICSPLEX Etc. And there is: SYSPLEX. Sysplex is often used when one of the others are meant: a SYSPLEX consists of the systems controlled by XCF, see the D XCF command. You can't/shouldn't share Dasd between GDPS P- and K- systems, although they are in the same Sysplex, so you can't shouldn't make SMSPLEX = SYSPLEX. If you really want to and you use MIM, you can make an SMSplex cross Sysplexes, with PDSE restrictions. Kees. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: 21 May 2020 12:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex No, not exactly. First, I meant "regular" sysplex. In that case it is possible and recommended to have SMSplex=sysplex. However it is also possible to have multiple SMSplexes within a sysplex, and within GDPS. And I mean SMSplex can be cross-plex - yes, it is possible. Multiple non-sysplexed systems can share SMS. Correct me if I'm wrong. -- Radoslaw Skorupka Lodz, Poland W dniu 20.05.2020 o 19:33, Vernooij, Kees (ITOP NM) - KLM pisze: > SMSPLEX=SYSPLEX: no, you can't. > GDPS K-systems cannot share Dasd with GDPS P-systems, so they must have > separate SMS plexes. > > If you mean: an SMSplex cannot cross Sysplexes: that is true. > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > R.S. > Sent: 20 May 2020 17:14 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Creating new SMS environment in a monoplex > > To complement: there is strict requirement to have SMSplex = Sysplex. > > SMS, as many other system components does support multihost configurations. > Multihost could mean several monoplex systems and shared CDS datasets on > shared volume. > Multihost could also mean SMSplex which covers some sysplex and few > monoplexes together. > SMSplex could also cover part of sysplex, so different sysplex member > may have different SMS settings. > > As usually IBM recommend to keep SMSplex = sysplex. > > Note: the above apply to DFSMSrmm, OAM (and tape libraries), etc. > > However each system component may have it's own specifics/restrictions. > AFAIK, in the very old days JES2 MAS could go beyond sysplex. Now it is > impossible - JES MAS is available only within sysplex boundaries. > However it is possible to have more than one MAS within sysplex. > Sometimes sysplex=*plex give some advantages, especially sysplex > communication and CF structures. > == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: Creating new SMS environment in a monoplex
Your Welcome Bob, so glad I could help someone here :) I didn't start doing storage, SMS till I left Boeing, lets see that was 1998 - wow Carmen Vitullo - Original Message - From: "Robert B. Richards" <01c91f408b9e-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 21, 2020 5:24:10 AM Subject: Re: Creating new SMS environment in a monoplex > Multiple non-sysplexed systems can share SMS. Correct me if I'm wrong. As long as the CATALOGs are shared for what you are trying to manage, yes. BTDT, 20+ years ago. Thanks to both of you, Skip, and Carmen for the confirmation of taking a copy of a SCDS and matching ACDS from a sysplex environment and making it work in a single system monoplex. It has been 20+ years since I did everyday storage management for a living. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, May 21, 2020 6:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex No, not exactly. First, I meant "regular" sysplex. In that case it is possible and recommended to have SMSplex=sysplex. However it is also possible to have multiple SMSplexes within a sysplex, and within GDPS. And I mean SMSplex can be cross-plex - yes, it is possible. Multiple non-sysplexed systems can share SMS. Correct me if I'm wrong. -- Radoslaw Skorupka Lodz, Poland W dniu 20.05.2020 o 19:33, Vernooij, Kees (ITOP NM) - KLM pisze: > SMSPLEX=SYSPLEX: no, you can't. > GDPS K-systems cannot share Dasd with GDPS P-systems, so they must have > separate SMS plexes. > > If you mean: an SMSplex cannot cross Sysplexes: that is true. > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > R.S. > Sent: 20 May 2020 17:14 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Creating new SMS environment in a monoplex > > To complement: there is strict requirement to have SMSplex = Sysplex. > > SMS, as many other system components does support multihost configurations. > Multihost could mean several monoplex systems and shared CDS datasets on > shared volume. > Multihost could also mean SMSplex which covers some sysplex and few > monoplexes together. > SMSplex could also cover part of sysplex, so different sysplex member > may have different SMS settings. > > As usually IBM recommend to keep SMSplex = sysplex. > > Note: the above apply to DFSMSrmm, OAM (and tape libraries), etc. > > However each system component may have it's own specifics/restrictions. > AFAIK, in the very old days JES2 MAS could go beyond sysplex. Now it is > impossible - JES MAS is available only within sysplex boundaries. > However it is possible to have more than one MAS within sysplex. > Sometimes sysplex=*plex give some advantages, especially sysplex > communication and CF structures. > == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -
Re: Creating new SMS environment in a monoplex
> Multiple non-sysplexed systems can share SMS. Correct me if I'm wrong. As long as the CATALOGs are shared for what you are trying to manage, yes. BTDT, 20+ years ago. Thanks to both of you, Skip, and Carmen for the confirmation of taking a copy of a SCDS and matching ACDS from a sysplex environment and making it work in a single system monoplex. It has been 20+ years since I did everyday storage management for a living. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, May 21, 2020 6:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex No, not exactly. First, I meant "regular" sysplex. In that case it is possible and recommended to have SMSplex=sysplex. However it is also possible to have multiple SMSplexes within a sysplex, and within GDPS. And I mean SMSplex can be cross-plex - yes, it is possible. Multiple non-sysplexed systems can share SMS. Correct me if I'm wrong. -- Radoslaw Skorupka Lodz, Poland W dniu 20.05.2020 o 19:33, Vernooij, Kees (ITOP NM) - KLM pisze: > SMSPLEX=SYSPLEX: no, you can't. > GDPS K-systems cannot share Dasd with GDPS P-systems, so they must have > separate SMS plexes. > > If you mean: an SMSplex cannot cross Sysplexes: that is true. > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > R.S. > Sent: 20 May 2020 17:14 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Creating new SMS environment in a monoplex > > To complement: there is strict requirement to have SMSplex = Sysplex. > > SMS, as many other system components does support multihost configurations. > Multihost could mean several monoplex systems and shared CDS datasets on > shared volume. > Multihost could also mean SMSplex which covers some sysplex and few > monoplexes together. > SMSplex could also cover part of sysplex, so different sysplex member > may have different SMS settings. > > As usually IBM recommend to keep SMSplex = sysplex. > > Note: the above apply to DFSMSrmm, OAM (and tape libraries), etc. > > However each system component may have it's own specifics/restrictions. > AFAIK, in the very old days JES2 MAS could go beyond sysplex. Now it is > impossible - JES MAS is available only within sysplex boundaries. > However it is possible to have more than one MAS within sysplex. > Sometimes sysplex=*plex give some advantages, especially sysplex > communication and CF structures. > == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Creating new SMS environment in a monoplex
No, not exactly. First, I meant "regular" sysplex. In that case it is possible and recommended to have SMSplex=sysplex. However it is also possible to have multiple SMSplexes within a sysplex, and within GDPS. And I mean SMSplex can be cross-plex - yes, it is possible. Multiple non-sysplexed systems can share SMS. Correct me if I'm wrong. -- Radoslaw Skorupka Lodz, Poland W dniu 20.05.2020 o 19:33, Vernooij, Kees (ITOP NM) - KLM pisze: SMSPLEX=SYSPLEX: no, you can't. GDPS K-systems cannot share Dasd with GDPS P-systems, so they must have separate SMS plexes. If you mean: an SMSplex cannot cross Sysplexes: that is true. Kees. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: 20 May 2020 17:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex To complement: there is strict requirement to have SMSplex = Sysplex. SMS, as many other system components does support multihost configurations. Multihost could mean several monoplex systems and shared CDS datasets on shared volume. Multihost could also mean SMSplex which covers some sysplex and few monoplexes together. SMSplex could also cover part of sysplex, so different sysplex member may have different SMS settings. As usually IBM recommend to keep SMSplex = sysplex. Note: the above apply to DFSMSrmm, OAM (and tape libraries), etc. However each system component may have it's own specifics/restrictions. AFAIK, in the very old days JES2 MAS could go beyond sysplex. Now it is impossible - JES MAS is available only within sysplex boundaries. However it is possible to have more than one MAS within sysplex. Sometimes sysplex=*plex give some advantages, especially sysplex communication and CF structures. == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Creating new SMS environment in a monoplex
SMSPLEX=SYSPLEX: no, you can't. GDPS K-systems cannot share Dasd with GDPS P-systems, so they must have separate SMS plexes. If you mean: an SMSplex cannot cross Sysplexes: that is true. Kees. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: 20 May 2020 17:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex To complement: there is strict requirement to have SMSplex = Sysplex. SMS, as many other system components does support multihost configurations. Multihost could mean several monoplex systems and shared CDS datasets on shared volume. Multihost could also mean SMSplex which covers some sysplex and few monoplexes together. SMSplex could also cover part of sysplex, so different sysplex member may have different SMS settings. As usually IBM recommend to keep SMSplex = sysplex. Note: the above apply to DFSMSrmm, OAM (and tape libraries), etc. However each system component may have it's own specifics/restrictions. AFAIK, in the very old days JES2 MAS could go beyond sysplex. Now it is impossible - JES MAS is available only within sysplex boundaries. However it is possible to have more than one MAS within sysplex. Sometimes sysplex=*plex give some advantages, especially sysplex communication and CF structures. -- Radoslaw Skorupka Lodz, Poland W dniu 19.05.2020 o 21:22, Vernooij, Kees (ITOP NM) - KLM pisze: > I can confirm that. > We have 2 sysplexes (Prod and Test), both with 2 GPDS K-systems. > GDPS K-systems don's share Dasd with the other systems of the sysplex. > So we have 6 SMS environments, each with their own SCDS, ACDS and COMMDS. > We have 1 SMS configuration that covers all systems and in the ACS routines, > we route datasets to storage groups, depending on the system it runs on. > We update the 'source' SMS configuration on the test sysplex systems, > activate it on the 3 SMS environments in the Test Sysplex and test it. > Then we transfer the SCDS to the 3 SMS environments of the Prod Sysplex and > activate it there. > We have no problem with this setup. The advantage is that you don't make > typo's when trying to copy the updates in the test-environment to the > prod-environment. > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Richards, Robert B. > Sent: 19 May 2020 17:58 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Creating new SMS environment in a monoplex > > Thanks, Radoslaw. > > My point, and I think you have also confirmed it, is that an SMS environment > has no specific dependence on a parallel sysplex, CFs, couple datasets, etc. > > All that is left for me is to finish building the system and IPL it. > > Bob > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > R.S. > Sent: Tuesday, May 19, 2020 11:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Creating new SMS environment in a monoplex > > W dniu 18.05.2020 o 20:36, Richards, Robert B. pisze: >> It has been a few decades since I have created a new SMS environment. >> >> Current environment is parallel sysplex replete with CFs and lots of lpars. >> >> I am trying to create a simple SMS environment that will be part of a >> monoplex consisting on one lpar. >> >> I did the following: >> >> >> 1. Defined the new SYSNAME into the base configuration in ISMF and >> activated same. D SMS verified it was defined and not active >> 2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to >> correct usercat) >> 3. Issued a SETSMS SAVEACDS(also using a SSA connector that I >> subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected >> to a new mastercat) >> 4. Defined an empty COMMDS that I also performed an alter/newname to >> get the desired COMMDS dataset name. >> >> My boss says the ACDS is aware of the original sysplex environment and my >> gyrations of trying to make the above work in a monoplex will not succeed. >> >> Who is right? Will it work or not? > Quick and dirty method: > 1. Add new system name to existing SCDS and ACDS. Don't worry, it is nothing > wrong to have non-present system names there. > 2. Copy all *CDS to disk belonging to new system. > 3. IPL the system. > > Of course this is method for some migration. ACS routines, class definitions > and library definitions will be moved. Is that what you want? > Otherwise there is another method, to start from scratch. ACS routines can be > easily imported, class definitions - the only way I know is to re-define them > manually. > BTW: some dummy SMS environment is delivered with ServerPac. I always start > from that point. Then IPL
Re: Creating new SMS environment in a monoplex
To complement: there is strict requirement to have SMSplex = Sysplex. SMS, as many other system components does support multihost configurations. Multihost could mean several monoplex systems and shared CDS datasets on shared volume. Multihost could also mean SMSplex which covers some sysplex and few monoplexes together. SMSplex could also cover part of sysplex, so different sysplex member may have different SMS settings. As usually IBM recommend to keep SMSplex = sysplex. Note: the above apply to DFSMSrmm, OAM (and tape libraries), etc. However each system component may have it's own specifics/restrictions. AFAIK, in the very old days JES2 MAS could go beyond sysplex. Now it is impossible - JES MAS is available only within sysplex boundaries. However it is possible to have more than one MAS within sysplex. Sometimes sysplex=*plex give some advantages, especially sysplex communication and CF structures. -- Radoslaw Skorupka Lodz, Poland W dniu 19.05.2020 o 21:22, Vernooij, Kees (ITOP NM) - KLM pisze: I can confirm that. We have 2 sysplexes (Prod and Test), both with 2 GPDS K-systems. GDPS K-systems don's share Dasd with the other systems of the sysplex. So we have 6 SMS environments, each with their own SCDS, ACDS and COMMDS. We have 1 SMS configuration that covers all systems and in the ACS routines, we route datasets to storage groups, depending on the system it runs on. We update the 'source' SMS configuration on the test sysplex systems, activate it on the 3 SMS environments in the Test Sysplex and test it. Then we transfer the SCDS to the 3 SMS environments of the Prod Sysplex and activate it there. We have no problem with this setup. The advantage is that you don't make typo's when trying to copy the updates in the test-environment to the prod-environment. Kees. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: 19 May 2020 17:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex Thanks, Radoslaw. My point, and I think you have also confirmed it, is that an SMS environment has no specific dependence on a parallel sysplex, CFs, couple datasets, etc. All that is left for me is to finish building the system and IPL it. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, May 19, 2020 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex W dniu 18.05.2020 o 20:36, Richards, Robert B. pisze: It has been a few decades since I have created a new SMS environment. Current environment is parallel sysplex replete with CFs and lots of lpars. I am trying to create a simple SMS environment that will be part of a monoplex consisting on one lpar. I did the following: 1. Defined the new SYSNAME into the base configuration in ISMF and activated same. D SMS verified it was defined and not active 2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct usercat) 3. Issued a SETSMS SAVEACDS(also using a SSA connector that I subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected to a new mastercat) 4. Defined an empty COMMDS that I also performed an alter/newname to get the desired COMMDS dataset name. My boss says the ACDS is aware of the original sysplex environment and my gyrations of trying to make the above work in a monoplex will not succeed. Who is right? Will it work or not? Quick and dirty method: 1. Add new system name to existing SCDS and ACDS. Don't worry, it is nothing wrong to have non-present system names there. 2. Copy all *CDS to disk belonging to new system. 3. IPL the system. Of course this is method for some migration. ACS routines, class definitions and library definitions will be moved. Is that what you want? Otherwise there is another method, to start from scratch. ACS routines can be easily imported, class definitions - the only way I know is to re-define them manually. BTW: some dummy SMS environment is delivered with ServerPac. I always start from that point. Then IPL with CPAC system name, then add my name to ACDS then reIPL with my system name. Then *CDS datasets can be imported (copied). Piece of cake. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy
Re: Creating new SMS environment in a monoplex
I can confirm that. We have 2 sysplexes (Prod and Test), both with 2 GPDS K-systems. GDPS K-systems don's share Dasd with the other systems of the sysplex. So we have 6 SMS environments, each with their own SCDS, ACDS and COMMDS. We have 1 SMS configuration that covers all systems and in the ACS routines, we route datasets to storage groups, depending on the system it runs on. We update the 'source' SMS configuration on the test sysplex systems, activate it on the 3 SMS environments in the Test Sysplex and test it. Then we transfer the SCDS to the 3 SMS environments of the Prod Sysplex and activate it there. We have no problem with this setup. The advantage is that you don't make typo's when trying to copy the updates in the test-environment to the prod-environment. Kees. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: 19 May 2020 17:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex Thanks, Radoslaw. My point, and I think you have also confirmed it, is that an SMS environment has no specific dependence on a parallel sysplex, CFs, couple datasets, etc. All that is left for me is to finish building the system and IPL it. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, May 19, 2020 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex W dniu 18.05.2020 o 20:36, Richards, Robert B. pisze: > It has been a few decades since I have created a new SMS environment. > > Current environment is parallel sysplex replete with CFs and lots of lpars. > > I am trying to create a simple SMS environment that will be part of a > monoplex consisting on one lpar. > > I did the following: > > >1. Defined the new SYSNAME into the base configuration in ISMF and > activated same. D SMS verified it was defined and not active >2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct > usercat) >3. Issued a SETSMS SAVEACDS(also using a SSA connector that I > subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected > to a new mastercat) >4. Defined an empty COMMDS that I also performed an alter/newname to get > the desired COMMDS dataset name. > > My boss says the ACDS is aware of the original sysplex environment and my > gyrations of trying to make the above work in a monoplex will not succeed. > > Who is right? Will it work or not? Quick and dirty method: 1. Add new system name to existing SCDS and ACDS. Don't worry, it is nothing wrong to have non-present system names there. 2. Copy all *CDS to disk belonging to new system. 3. IPL the system. Of course this is method for some migration. ACS routines, class definitions and library definitions will be moved. Is that what you want? Otherwise there is another method, to start from scratch. ACS routines can be easily imported, class definitions - the only way I know is to re-define them manually. BTW: some dummy SMS environment is delivered with ServerPac. I always start from that point. Then IPL with CPAC system name, then add my name to ACDS then reIPL with my system name. Then *CDS datasets can be imported (copied). Piece of cake. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully
Re: Creating new SMS environment in a monoplex
Skip, I think the point my boss was trying to make is that there is residual information stored in the Parallel Sysplexed ACDS that makes a SAVEACDS copy of it unusable for use on a monoplex. I begged to differ and posted here to see what others thought. I added the new lpar's system name into the base configuration and activated it prior to issuing the SAVEACDS. When I perform an IPL of the new system, I expect it to recognize that system name and a D SMS to show it active while all the other system names will show hyphens and N/A under Interval Seconds. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Tuesday, May 19, 2020 1:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex We have both parallel sysplexes and monoplexes. SMS runs on every image. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: Tuesday, May 19, 2020 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Creating new SMS environment in a monoplex CAUTION EXTERNAL EMAIL Thanks, Radoslaw. My point, and I think you have also confirmed it, is that an SMS environment has no specific dependence on a parallel sysplex, CFs, couple datasets, etc. All that is left for me is to finish building the system and IPL it. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, May 19, 2020 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex W dniu 18.05.2020 o 20:36, Richards, Robert B. pisze: > It has been a few decades since I have created a new SMS environment. > > Current environment is parallel sysplex replete with CFs and lots of lpars. > > I am trying to create a simple SMS environment that will be part of a > monoplex consisting on one lpar. > > I did the following: > > >1. Defined the new SYSNAME into the base configuration in ISMF and > activated same. D SMS verified it was defined and not active >2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct > usercat) >3. Issued a SETSMS SAVEACDS(also using a SSA connector that I > subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected > to a new mastercat) >4. Defined an empty COMMDS that I also performed an alter/newname to get > the desired COMMDS dataset name. > > My boss says the ACDS is aware of the original sysplex environment and my > gyrations of trying to make the above work in a monoplex will not succeed. > > Who is right? Will it work or not? Quick and dirty method: 1. Add new system name to existing SCDS and ACDS. Don't worry, it is nothing wrong to have non-present system names there. 2. Copy all *CDS to disk belonging to new system. 3. IPL the system. Of course this is method for some migration. ACS routines, class definitions and library definitions will be moved. Is that what you want? Otherwise there is another method, to start from scratch. ACS routines can be easily imported, class definitions - the only way I know is to re-define them manually. BTW: some dummy SMS environment is delivered with ServerPac. I always start from that point. Then IPL with CPAC system name, then add my name to ACDS then reIPL with my system name. Then *CDS datasets can be imported (copied). Piece of cake. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Creating new SMS environment in a monoplex
We have both parallel sysplexes and monoplexes. SMS runs on every image. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: Tuesday, May 19, 2020 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Creating new SMS environment in a monoplex CAUTION EXTERNAL EMAIL Thanks, Radoslaw. My point, and I think you have also confirmed it, is that an SMS environment has no specific dependence on a parallel sysplex, CFs, couple datasets, etc. All that is left for me is to finish building the system and IPL it. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, May 19, 2020 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex W dniu 18.05.2020 o 20:36, Richards, Robert B. pisze: > It has been a few decades since I have created a new SMS environment. > > Current environment is parallel sysplex replete with CFs and lots of lpars. > > I am trying to create a simple SMS environment that will be part of a > monoplex consisting on one lpar. > > I did the following: > > >1. Defined the new SYSNAME into the base configuration in ISMF and > activated same. D SMS verified it was defined and not active >2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct > usercat) >3. Issued a SETSMS SAVEACDS(also using a SSA connector that I > subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected > to a new mastercat) >4. Defined an empty COMMDS that I also performed an alter/newname to get > the desired COMMDS dataset name. > > My boss says the ACDS is aware of the original sysplex environment and my > gyrations of trying to make the above work in a monoplex will not succeed. > > Who is right? Will it work or not? Quick and dirty method: 1. Add new system name to existing SCDS and ACDS. Don't worry, it is nothing wrong to have non-present system names there. 2. Copy all *CDS to disk belonging to new system. 3. IPL the system. Of course this is method for some migration. ACS routines, class definitions and library definitions will be moved. Is that what you want? Otherwise there is another method, to start from scratch. ACS routines can be easily imported, class definitions - the only way I know is to re-define them manually. BTW: some dummy SMS environment is delivered with ServerPac. I always start from that point. Then IPL with CPAC system name, then add my name to ACDS then reIPL with my system name. Then *CDS datasets can be imported (copied). Piece of cake. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Creating new SMS environment in a monoplex
Thanks, Radoslaw. My point, and I think you have also confirmed it, is that an SMS environment has no specific dependence on a parallel sysplex, CFs, couple datasets, etc. All that is left for me is to finish building the system and IPL it. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, May 19, 2020 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex W dniu 18.05.2020 o 20:36, Richards, Robert B. pisze: > It has been a few decades since I have created a new SMS environment. > > Current environment is parallel sysplex replete with CFs and lots of lpars. > > I am trying to create a simple SMS environment that will be part of a > monoplex consisting on one lpar. > > I did the following: > > >1. Defined the new SYSNAME into the base configuration in ISMF and > activated same. D SMS verified it was defined and not active >2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct > usercat) >3. Issued a SETSMS SAVEACDS(also using a SSA connector that I > subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected > to a new mastercat) >4. Defined an empty COMMDS that I also performed an alter/newname to get > the desired COMMDS dataset name. > > My boss says the ACDS is aware of the original sysplex environment and my > gyrations of trying to make the above work in a monoplex will not succeed. > > Who is right? Will it work or not? Quick and dirty method: 1. Add new system name to existing SCDS and ACDS. Don't worry, it is nothing wrong to have non-present system names there. 2. Copy all *CDS to disk belonging to new system. 3. IPL the system. Of course this is method for some migration. ACS routines, class definitions and library definitions will be moved. Is that what you want? Otherwise there is another method, to start from scratch. ACS routines can be easily imported, class definitions - the only way I know is to re-define them manually. BTW: some dummy SMS environment is delivered with ServerPac. I always start from that point. Then IPL with CPAC system name, then add my name to ACDS then reIPL with my system name. Then *CDS datasets can be imported (copied). Piece of cake. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Creating new SMS environment in a monoplex
W dniu 18.05.2020 o 20:36, Richards, Robert B. pisze: It has been a few decades since I have created a new SMS environment. Current environment is parallel sysplex replete with CFs and lots of lpars. I am trying to create a simple SMS environment that will be part of a monoplex consisting on one lpar. I did the following: 1. Defined the new SYSNAME into the base configuration in ISMF and activated same. D SMS verified it was defined and not active 2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct usercat) 3. Issued a SETSMS SAVEACDS(also using a SSA connector that I subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected to a new mastercat) 4. Defined an empty COMMDS that I also performed an alter/newname to get the desired COMMDS dataset name. My boss says the ACDS is aware of the original sysplex environment and my gyrations of trying to make the above work in a monoplex will not succeed. Who is right? Will it work or not? Quick and dirty method: 1. Add new system name to existing SCDS and ACDS. Don't worry, it is nothing wrong to have non-present system names there. 2. Copy all *CDS to disk belonging to new system. 3. IPL the system. Of course this is method for some migration. ACS routines, class definitions and library definitions will be moved. Is that what you want? Otherwise there is another method, to start from scratch. ACS routines can be easily imported, class definitions - the only way I know is to re-define them manually. BTW: some dummy SMS environment is delivered with ServerPac. I always start from that point. Then IPL with CPAC system name, then add my name to ACDS then reIPL with my system name. Then *CDS datasets can be imported (copied). Piece of cake. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Creating new SMS environment in a monoplex
your welcome Bob, yes please let me (us) know Carmen Vitullo - Original Message - From: "Robert B. Richards" <01c91f408b9e-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, May 18, 2020 2:27:27 PM Subject: Re: Creating new SMS environment in a monoplex Thanks Carmen. I'll post the results when I try an IPL of that new system and SMS starts up -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, May 18, 2020 3:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex Hi Bob, been a while for me also, but in my current sysplex I have systems defined that no longer exist, my ACS routines do not check for these systems. my base configuration has 4 systems in the plex, only 3 exists, not sure this helps you but I think you are on the right track Carmen Vitullo - Original Message - From: "Robert B. Richards" <01c91f408b9e-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, May 18, 2020 1:36:29 PM Subject: Creating new SMS environment in a monoplex It has been a few decades since I have created a new SMS environment. Current environment is parallel sysplex replete with CFs and lots of lpars. I am trying to create a simple SMS environment that will be part of a monoplex consisting on one lpar. I did the following: 1. Defined the new SYSNAME into the base configuration in ISMF and activated same. D SMS verified it was defined and not active 2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct usercat) 3. Issued a SETSMS SAVEACDS(also using a SSA connector that I subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected to a new mastercat) 4. Defined an empty COMMDS that I also performed an alter/newname to get the desired COMMDS dataset name. My boss says the ACDS is aware of the original sysplex environment and my gyrations of trying to make the above work in a monoplex will not succeed. Who is right? Will it work or not? Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Creating new SMS environment in a monoplex
Thanks Carmen. I'll post the results when I try an IPL of that new system and SMS starts up -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, May 18, 2020 3:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex Hi Bob, been a while for me also, but in my current sysplex I have systems defined that no longer exist, my ACS routines do not check for these systems. my base configuration has 4 systems in the plex, only 3 exists, not sure this helps you but I think you are on the right track Carmen Vitullo - Original Message - From: "Robert B. Richards" <01c91f408b9e-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, May 18, 2020 1:36:29 PM Subject: Creating new SMS environment in a monoplex It has been a few decades since I have created a new SMS environment. Current environment is parallel sysplex replete with CFs and lots of lpars. I am trying to create a simple SMS environment that will be part of a monoplex consisting on one lpar. I did the following: 1. Defined the new SYSNAME into the base configuration in ISMF and activated same. D SMS verified it was defined and not active 2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct usercat) 3. Issued a SETSMS SAVEACDS(also using a SSA connector that I subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected to a new mastercat) 4. Defined an empty COMMDS that I also performed an alter/newname to get the desired COMMDS dataset name. My boss says the ACDS is aware of the original sysplex environment and my gyrations of trying to make the above work in a monoplex will not succeed. Who is right? Will it work or not? Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Creating new SMS environment in a monoplex
I forgot to mention, once the base is activated, you can alter the configuration and remove systemsIIRC Carmen Vitullo - Original Message - From: "Robert B. Richards" <01c91f408b9e-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, May 18, 2020 1:36:29 PM Subject: Creating new SMS environment in a monoplex It has been a few decades since I have created a new SMS environment. Current environment is parallel sysplex replete with CFs and lots of lpars. I am trying to create a simple SMS environment that will be part of a monoplex consisting on one lpar. I did the following: 1. Defined the new SYSNAME into the base configuration in ISMF and activated same. D SMS verified it was defined and not active 2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct usercat) 3. Issued a SETSMS SAVEACDS(also using a SSA connector that I subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected to a new mastercat) 4. Defined an empty COMMDS that I also performed an alter/newname to get the desired COMMDS dataset name. My boss says the ACDS is aware of the original sysplex environment and my gyrations of trying to make the above work in a monoplex will not succeed. Who is right? Will it work or not? Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Creating new SMS environment in a monoplex
Hi Bob, been a while for me also, but in my current sysplex I have systems defined that no longer exist, my ACS routines do not check for these systems. my base configuration has 4 systems in the plex, only 3 exists, not sure this helps you but I think you are on the right track Carmen Vitullo - Original Message - From: "Robert B. Richards" <01c91f408b9e-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, May 18, 2020 1:36:29 PM Subject: Creating new SMS environment in a monoplex It has been a few decades since I have created a new SMS environment. Current environment is parallel sysplex replete with CFs and lots of lpars. I am trying to create a simple SMS environment that will be part of a monoplex consisting on one lpar. I did the following: 1. Defined the new SYSNAME into the base configuration in ISMF and activated same. D SMS verified it was defined and not active 2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct usercat) 3. Issued a SETSMS SAVEACDS(also using a SSA connector that I subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected to a new mastercat) 4. Defined an empty COMMDS that I also performed an alter/newname to get the desired COMMDS dataset name. My boss says the ACDS is aware of the original sysplex environment and my gyrations of trying to make the above work in a monoplex will not succeed. Who is right? Will it work or not? Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Creating new SMS environment in a monoplex
It has been a few decades since I have created a new SMS environment. Current environment is parallel sysplex replete with CFs and lots of lpars. I am trying to create a simple SMS environment that will be part of a monoplex consisting on one lpar. I did the following: 1. Defined the new SYSNAME into the base configuration in ISMF and activated same. D SMS verified it was defined and not active 2. A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct usercat) 3. Issued a SETSMS SAVEACDS(also using a SSA connector that I subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected to a new mastercat) 4. Defined an empty COMMDS that I also performed an alter/newname to get the desired COMMDS dataset name. My boss says the ACDS is aware of the original sysplex environment and my gyrations of trying to make the above work in a monoplex will not succeed. Who is right? Will it work or not? Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
