Classification: Confidential Agreed, however it seems the OP is operating in a "toggle-plex" i.e. either LPAR A is running or LPARB is running. In this case, the DVIPA would be deactivated on one of the LPARS and switched manually via the V TCPIP command to activate/deactivate the DVIPA on LPARA or LPARB.
The "old LPAR" will automatically switch to backup mode when the "new LPAR" is changed from backup to active. HTH, -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Art Zeigler Sent: Tuesday, October 17, 2023 3:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DVIPA question [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] If the VIPA is set correctly, then the data can dynamically move between the two LPARs so the workload is balanced across the two LPAR servers. I did that with MQ and shared queues. Messages rotated between the two MQ managers and if one system went down, the other system continued to handle the message traffic. Art Zeigler ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Laurence Chiu <lch...@gmail.com> Sent: Tuesday, October 17, 2023 3:45 PM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: DVIPA question That is exactly the situation, The second LPAR will be on the same CEC as the first, share OSA adapters and be in a sysplex with XCF being the mechanism to share the VIPA information. From my reading of the docs, when the server application on the primary LPAR is shutdown, and an incoming transaction arrives for it, TCP on the second LPAR will see the primary host and dynamically route the transaction to the server on the second LPAR. By making it dynamic we don't hae to worry about automation moving the VIPA, we can let TCP do that. The second LPAR will be in the same subset as the first. Youi comment about OMPROUTE is noted. Thanks On Wed, Oct 18, 2023 at 1:05 AM John S. Giltner, Jr. <gil...@gmail.com> wrote: > In addition to everything Jon has stated a few other questions may > help figure out what needs to be done, or not done. > > Are both LPARS on the same CEC? > > If both LPARS are on the same CEC, do they share OSA's? > > Are the IP addresses you plan to use as VIPA's in the same subnet as > the OSA's IP addresses? > > With certain setups you may need to run OMPROUTE configured for OSPF. > > I think if both LPAR's are on the same CEC and they share OSA's and > the VIPA addresses are in the same subnet as the OSA's, there is not > much to do, but to configure both TCPIP stacks with the same VIPA > range and then with PORT definitions assign what VIPA address you want > that application to use. > > > ---------------------------------------------------------------------- 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 ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
