Re: EXTERNAL EMAIL: Re: DB2 member to start on different LPAR
A few thoughts This is NOT purely an academic excersize - if an lpar crashed with a DS member on it, and the LPAR COULD NOT be immediately restarted. You would NEED to bring up the downed member on the remaining LPAR in light mode - to free any locked threads - miake sure all the drda ports are defined an ALL potential LPARS Chris Hoelscher Lead Sys DBA IBM Global Technical Services on assignmemt to Humana Inc. T 502.476.2538 or 502.407.7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jerry Whitteridge Sent: Thursday, February 11, 2021 2:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] EXTERNAL EMAIL: Re: DB2 member to start on different LPAR [External Email: Use caution with links and attachments] The answer is much more related to your infrastructure than the DB2 DS Member itself. (You can indeed run different DS members on a single LPAR) - we've done it during a DR exercise ) The question is more about do you have shared parmlibs/proclibs/RACF etc. etc. Some other considerations might be the listening ports for DDF (do the DS Members share a port or have unique ports ?) or ZFS file systems ? Jerry Whitteridge jerry.whitteri...@albertsons.com Manager Mainframe Systems & HP Non-Stop Albertsons Companies -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Thursday, February 11, 2021 11:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL EMAIL: Re: DB2 member to start on different LPAR Unless I am missing something. The point of DB2 Data Sharing is there is a GROUP (Umbrella) that connects multiple DB2 Regions. So if you have 2 or more DB2 Data Sharing regions. One on LPAR1 one on LPAR2 Then if LPAR1 is down, then LPAR2 will take on the DB2 data sharing work. Does that make Sense? Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, February 11, 2021 8:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DB2 member to start on different LPAR we are being constrained due to operations limitations. We are planning to upgrade our development environment and we need to have the development CICS regions down. Unfortunately operations says they have difficulty going thru all the regions and just stopping development cics. Our CICS regions are connected to only 1 LPAR. So only in order to ease their work they want to just bring down that LPAR with a scheduled IPL. Our primary DB2 member runs on that LPAR. So I wanted to start it on a "non-CICS" LPAR. Bill -- 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 Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助 服務。請致電 1‐877‐320‐
Re: EXTERNAL EMAIL: Re: DB2 member to start on different LPAR
The answer is much more related to your infrastructure than the DB2 DS Member itself. (You can indeed run different DS members on a single LPAR) - we've done it during a DR exercise ) The question is more about do you have shared parmlibs/proclibs/RACF etc. etc. Some other considerations might be the listening ports for DDF (do the DS Members share a port or have unique ports ?) or ZFS file systems ? Jerry Whitteridge jerry.whitteri...@albertsons.com Manager Mainframe Systems & HP Non-Stop Albertsons Companies -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Thursday, February 11, 2021 11:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL EMAIL: Re: DB2 member to start on different LPAR Unless I am missing something. The point of DB2 Data Sharing is there is a GROUP (Umbrella) that connects multiple DB2 Regions. So if you have 2 or more DB2 Data Sharing regions. One on LPAR1 one on LPAR2 Then if LPAR1 is down, then LPAR2 will take on the DB2 data sharing work. Does that make Sense? Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, February 11, 2021 8:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DB2 member to start on different LPAR we are being constrained due to operations limitations. We are planning to upgrade our development environment and we need to have the development CICS regions down. Unfortunately operations says they have difficulty going thru all the regions and just stopping development cics. Our CICS regions are connected to only 1 LPAR. So only in order to ease their work they want to just bring down that LPAR with a scheduled IPL. Our primary DB2 member runs on that LPAR. So I wanted to start it on a "non-CICS" LPAR. Bill -- 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 Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DB2 member to start on different LPAR
Are you saying you currently do not have a DB2 Data Sharing Region on LPAR2 (Non CICS?) for this DB2 Region? Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Thursday, February 11, 2021 11:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DB2 member to start on different LPAR Unless I am missing something. The point of DB2 Data Sharing is there is a GROUP (Umbrella) that connects multiple DB2 Regions. So if you have 2 or more DB2 Data Sharing regions. One on LPAR1 one on LPAR2 Then if LPAR1 is down, then LPAR2 will take on the DB2 data sharing work. Does that make Sense? Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, February 11, 2021 8:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DB2 member to start on different LPAR we are being constrained due to operations limitations. We are planning to upgrade our development environment and we need to have the development CICS regions down. Unfortunately operations says they have difficulty going thru all the regions and just stopping development cics. Our CICS regions are connected to only 1 LPAR. So only in order to ease their work they want to just bring down that LPAR with a scheduled IPL. Our primary DB2 member runs on that LPAR. So I wanted to start it on a "non-CICS" LPAR. Bill -- 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: DB2 member to start on different LPAR
Unless I am missing something. The point of DB2 Data Sharing is there is a GROUP (Umbrella) that connects multiple DB2 Regions. So if you have 2 or more DB2 Data Sharing regions. One on LPAR1 one on LPAR2 Then if LPAR1 is down, then LPAR2 will take on the DB2 data sharing work. Does that make Sense? Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, February 11, 2021 8:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DB2 member to start on different LPAR we are being constrained due to operations limitations. We are planning to upgrade our development environment and we need to have the development CICS regions down. Unfortunately operations says they have difficulty going thru all the regions and just stopping development cics. Our CICS regions are connected to only 1 LPAR. So only in order to ease their work they want to just bring down that LPAR with a scheduled IPL. Our primary DB2 member runs on that LPAR. So I wanted to start it on a "non-CICS" LPAR. Bill -- 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: DB2 member to start on different LPAR
we are being constrained due to operations limitations. We are planning to upgrade our development environment and we need to have the development CICS regions down. Unfortunately operations says they have difficulty going thru all the regions and just stopping development cics. Our CICS regions are connected to only 1 LPAR. So only in order to ease their work they want to just bring down that LPAR with a scheduled IPL. Our primary DB2 member runs on that LPAR. So I wanted to start it on a "non-CICS" LPAR. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DB2 member to start on different LPAR
Bill, Why are you wanting to do that? A DB2 Data sharing environment has a DB2 Start on each lpar that shares the Same DB2 information. If you have 4 LPARs, you would have one DB2 Data Sharing region on the LPARs you want. For example: I have a group name of DBP2, but I have 3 DB2 regions (DBP1, DBP2, DBP3) running on LPARs on LPAR1, LPAR2, LPAR3 I so long as the user is coming into one of those DB2 systems, it has access to the DBP2 group functions. So user A can be running on LPAR1 in DBP1 User B can be running on LPAR3 on DPB3 Batch DB2 job could be running on LPAR2 on DPB3 All of these activities would be for the GROUP DBP2. I am not sure why you want to change the DB2 members for the various LPARs. If DB2 Data Sharing is set up, you should only need to shut down or start up the appropriate DB2 region. Can you provide more details on what problem you are trying to solve? Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, February 11, 2021 3:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DB2 member to start on different LPAR We have DB2 data sharing and I have a need to start DB2 members on any LPAR. Aside from RACF definitions, is the only other item I need in place is the SSID symbol in SYS1.PARMLIB(IEFSSNxx) ? thanks Bill -- 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: DB2 member to start on different LPAR
no I simply want to start DB2 Member1 on LPAR2. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DB2 member to start on different LPAR
W dniu 11.02.2021 o 11:54, Bill Giannelli pisze:
Thank you for the information!
I think I was a little vague.
Let me explain further...
we have on LPAR1 DB2 Member1, on LPAR2 DB2 Member2. Both members of the same
data sharing group.
I want to be able to start DB2 Member1 on LPAR2 and DB2 Member2 on LPAR1.
That sounds you *already have* parallel sysplex and DB2 in datasharing
mode ("sysplexed").
And all you want is to replace system images:
z/OS A working on LPAR1, z/OS B working on LPAR2
And you want z/OS B on LPAR 1, z/OS A on LPAR2
I don't know what is the reason, but it seems feasible and not very hard
to do.
--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DB2 member to start on different LPAR
Thank you for the information! I think I was a little vague. Let me explain further... we have on LPAR1 DB2 Member1, on LPAR2 DB2 Member2. Both members of the same data sharing group. I want to be able to start DB2 Member1 on LPAR2 and DB2 Member2 on LPAR1. thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DB2 member to start on different LPAR
It depends ... there are many non-Db2 dependencies on things like shared dasd (implies SMS definitions), Catalog structure, XCF signalling paths, IRLM and your CF connectivity, etc. Unless your shop has deliberately setup multiple lpars to be compatible, chances are they will not be. You can even die on silly things like dump space. A whole redbook on setting up Db2 data sharing was written circa 15 years ago, so there is enough material to fill a few hundred pages. Might be wise to review it. SSID and RACF definitions are 1% of the solution. On Thu, Feb 11, 2021 at 9:17 PM Bill Giannelli wrote: > We have DB2 data sharing and I have a need to start DB2 members on any > LPAR. > Aside from RACF definitions, is the only other item I need in place is the > SSID symbol in SYS1.PARMLIB(IEFSSNxx) ? > thanks > Bill > > -- > 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
DB2 member to start on different LPAR
We have DB2 data sharing and I have a need to start DB2 members on any LPAR. Aside from RACF definitions, is the only other item I need in place is the SSID symbol in SYS1.PARMLIB(IEFSSNxx) ? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
