Re: DVIPA question
Classification: Confidential My presumption is that a data-sharing partner "myserverb" is up and running on LPARB. In this case, the transfer is pretty much unnoticeable. After the transfer of the DVIPA, all new traffic will be routed to LPARB/myuserverb. LPARA/myservera will 'wither on the vine. If LPARA/myservera are shut down too quickly, any users connection to LPARA/myservera will be terminated prematurely and cause a perceived outage. -Original Message- From: IBM Mainframe Discussion List On Behalf Of John S. Giltner, Jr. Sent: Monday, October 23, 2023 9:46 AM 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.] Some situations may require manual intervention. That that could be done through automation. Some situations may involve noticeable outage outage to the user. It all depends on how it is setup and how you want to move the task. Say you have LPARA and LPARB and task "myserver" normally runs on LPARA. Do you want it to move to LPARB only when LPARA is shutdown and move back when LPARA comes back up? Or do you want to be able to move "myserver" to LPARB while LPARA is still up? Or a both? Do you want to prevent "myserver" from running on both at the same time? You may want to read up on how TCPIP's Sysplex distributor works. Although it is designed so to have multiple server tasks up at the same time, you can use it and just have one task up and running.normally move it from one LPAR to another as needed. On Mon, 23 Oct 2023 11:51:04 +, Allan Staller wrote: >Classification: Confidential > >I agree, the secondary application must be running on the other LPAR. > >I have physically tested this is a prior life and the transition is >(apparently) seamless to the end user. >In that environment, although the cutover was triggered manually, it >worked flawlessly, I also (in that environment) simulated an OSA failure by >"pulling the plug" on the specific Ethernet cable involved. >This (again) worked flawlessly, and (apparently) unnoticed by the end >user, > > >-iriginal Message- >From: IBM Mainframe Discussion List On >Behalf Of Jon Perryman >Sent: Friday, October 20, 2023 11:41 AM >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.] > >On Fri, 20 Oct 2023111:55:17 +, Allan Staller >wrote: > >> The difference iis n starting/stopping the application is a service >> interruption to the end user. >> The DVIPA activate/deactivate would be seamless to the end user > >DVIPA activate/deactivate isn't seamless. First, it would require the >application be running on the second LPAR running in standby mode. Second, >current connections are interrupted unless the application has been designed >to circumvent the problem. Third, you still have a time frame where the >application is still unreachable albeit very small hopefully. > >Each situation is different and a decision about which method best solves the >problem must be made. The OP said his application can only be active on one >LPAR. In that case, using activate/deactivate would not provide an advantage >although it would work equally as well.. > >-- >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 r
Re: DVIPA question
On Mon, 23 Oct 2023 11:51:04 +, Allan Staller wrote: >I agree, the secondary application must be running on the other LPAR. Don't say "must" because every situation is different and every situation has defined limitations. The OP said their app cannot run in standby mode. The majority of apps running in standby mode, cancel all inflight transactions because inflight transaction recovery is difficult. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DVIPA question
Some situations may require manual intervention. That that could be done through automation. Some situations may involve noticeable outage outage to the user. It all depends on how it is setup and how you want to move the task. Say you have LPARA and LPARB and task "myserver" normally runs on LPARA. Do you want it to move to LPARB only when LPARA is shutdown and move back when LPARA comes back up? Or do you want to be able to move "myserver" to LPARB while LPARA is still up? Or a both? Do you want to prevent "myserver" from running on both at the same time? You may want to read up on how TCPIP's Sysplex distributor works. Although it is designed so to have multiple server tasks up at the same time, you can use it and just have one task up and running.normally move it from one LPAR to another as needed. On Mon, 23 Oct 2023 11:51:04 +, Allan Staller wrote: >Classification: Confidential > >I agree, the secondary application must be running on the other LPAR. > >I have physically tested this is a prior life and the transition is >(apparently) seamless to the end user. >In that environment, although the cutover was triggered manually, it worked >flawlessly, >I also (in that environment) simulated an OSA failure by "pulling the plug" on >the specific Ethernet cable involved. >This (again) worked flawlessly, and (apparently) unnoticed by the end user, > > >-iriginal Message- >From: IBM Mainframe Discussion List On Behalf Of >Jon Perryman >Sent: Friday, October 20, 2023 11:41 AM >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.] > >On Fri, 20 Oct 2023111:55:17 +, Allan Staller >wrote: > >> The difference iis n starting/stopping the application is a service >> interruption to the end user. >> The DVIPA activate/deactivate would be seamless to the end user > >DVIPA activate/deactivate isn't seamless. First, it would require the >application be running on the second LPAR running in standby mode. Second, >current connections are interrupted unless the application has been designed >to circumvent the problem. Third, you still have a time frame where the >application is still unreachable albeit very small hopefully. > >Each situation is different and a decision about which method best solves the >problem must be made. The OP said his application can only be active on one >LPAR. In that case, using activate/deactivate would not provide an advantage >although it would work equally as well.. > >-- >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DVIPA question
Classification: Confidential I agree, the secondary application must be running on the other LPAR. I have physically tested this is a prior life and the transition is (apparently) seamless to the end user. In that environment, although the cutover was triggered manually, it worked flawlessly, I also (in that environment) simulated an OSA failure by "pulling the plug" on the specific Ethernet cable involved. This (again) worked flawlessly, and (apparently) unnoticed by the end user, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Friday, October 20, 2023 11:41 AM 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.] On Fri, 20 Oct 2023 11:55:17 +, Allan Staller wrote: > The difference iis n starting/stopping the application is a service > interruption to the end user. > The DVIPA activate/deactivate would be seamless to the end user DVIPA activate/deactivate isn't seamless. First, it would require the application be running on the second LPAR running in standby mode. Second, current connections are interrupted unless the application has been designed to circumvent the problem. Third, you still have a time frame where the application is still unreachable albeit very small hopefully. Each situation is different and a decision about which method best solves the problem must be made. The OP said his application can only be active on one LPAR. In that case, using activate/deactivate would not provide an advantage although it would work equally as well.. -- 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
Re: DVIPA question
On Fri, 20 Oct 2023 11:55:17 +, Allan Staller wrote: > The difference iis n starting/stopping the application is a service > interruption to the end user. > The DVIPA activate/deactivate would be seamless to the end user DVIPA activate/deactivate isn't seamless. First, it would require the application be running on the second LPAR running in standby mode. Second, current connections are interrupted unless the application has been designed to circumvent the problem. Third, you still have a time frame where the application is still unreachable albeit very small hopefully. Each situation is different and a decision about which method best solves the problem must be made. The OP said his application can only be active on one LPAR. In that case, using activate/deactivate would not provide an advantage although it would work equally as well.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DVIPA question
FYI, this is more than the OP needs to know to solve his problem. On Fri, 20 Oct 2023 06:06:33 -0500, John S. Giltner, Jr. wrote: >Correct, it's not a "full router", it can route traffic to a specific LPAR if >the IP address as been registered. IBM says "not a full router" because they don't want us to contemplate using it as a full router and unnecessarily route all traffic to an LPAR. Why use expensive equipment when cheap equipment can be used. Ask yourself if your home router is "not a full router" because it discards traffic that is not registered. If you were to define where to send unregistered traffic, does your home router become a full router? >Not sure if it was true but I had heard that the I/O cards for the zSystems >were > single board computers using either x86 or PowerPC based CPU's > and running some form of either OS2 (early on) or Linux (later on). Most routers today are Linux based. I wouldn't be surprised if OSA is running Linux but then again maybe it's running AIX. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DVIPA question
Classification: Confidential Either method would be successful in moving the workload. The difference iis n starting/stopping the application is a service interruption to the end user. The DVIPA activate/deactivate would be seamless to the end user. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Thursday, October 19, 2023 1:28 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.] On Thu, 19 Oct 2023 12:08:04 +, Allan Staller wrote: >That is not correct. The DVIPA and be started/stopped in a specific TCPIP >instance. >IIRC, the commad is something like V >TCPIP,,SYSPLEX,ACTIVATE,DVIPA=xx.xx.xx.xx >There is also a DEACTIVATE parameter as well. John Giltner says he stops his app on one LPAR and starts it on another. He implies that he is not issuing activate/deactivate for the DVIPA address. It would make more sense for IBM to automatically deactivate the address when it has no ports in use and to automatically activate it when the first listener starts. There are times when activate / deactivate command is needed. For instance, you may have applications running in case of failover recovery but you don't want them used until the other system fails. Recovery would only need to activate the address without the need to startup the applications and resources. -- 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
Re: DVIPA question
Correct, it's not a "full router", it can route traffic to a specific LPAR if the IP address as been registered. If it has not been registered any packets received when a non-registered (unknown to any LPAR) address it will be dropped, unless you have defined one of the OSA's as a "PRIMARY ROUTER". If an OSA defined as "PARIMARY" ROUTER in one of the LPARS's then all traffic that is received on the OSA from a unknown IP address is passed to TCPIP on the designated LPAR and the TCPIP stack does the routing. Not sure if it was true but I had heard that the I/O cards for the zSystems were single board computers using either x86 or PowerPC based CPU's and running some form of either OS2 (early on) or Linux (later on). On Thu, 19 Oct 2023 13:36:27 -0500, Jon Perryman wrote: >On Thu, 19 Oct 2023 06:59:43 -0500, John S. Giltner, Jr. >wrote: > >>There is a Share presentation called "Getting the most out of your OSA (Opens >>Systems Adapter)" >> that does a much better job of describing how the OSA works than I can. > >I only did a quick scan of the presentation. It says one of the OSA functions >is router. It talks more about non-dynamic routing. I didn't see a discussion >about dynamic routing with regards to IP addresses and ports. OSA is very >impressive. > >Thanks for pointing out the presentation. > >-- >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: DVIPA question
On Thu, 19 Oct 2023 06:59:43 -0500, John S. Giltner, Jr. wrote: >There is a Share presentation called "Getting the most out of your OSA (Opens >Systems Adapter)" > that does a much better job of describing how the OSA works than I can. I only did a quick scan of the presentation. It says one of the OSA functions is router. It talks more about non-dynamic routing. I didn't see a discussion about dynamic routing with regards to IP addresses and ports. OSA is very impressive. Thanks for pointing out the presentation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DVIPA question
On Thu, 19 Oct 2023 12:08:04 +, Allan Staller wrote: >That is not correct. The DVIPA and be started/stopped in a specific TCPIP >instance. >IIRC, the commad is something like V TCPIP,,SYSPLEX,ACTIVATE,DVIPA=xx.xx.xx.xx >There is also a DEACTIVATE parameter as well. John Giltner says he stops his app on one LPAR and starts it on another. He implies that he is not issuing activate/deactivate for the DVIPA address. It would make more sense for IBM to automatically deactivate the address when it has no ports in use and to automatically activate it when the first listener starts. There are times when activate / deactivate command is needed. For instance, you may have applications running in case of failover recovery but you don't want them used until the other system fails. Recovery would only need to activate the address without the need to startup the applications and resources. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DVIPA question
Classification: Confidential That is not correct. The DVIPA and be started/stopped in a specific TCPIP instance. IIRC, the commad is something like V TCPIP,,SYSPLEX,ACTIVATE,DVIPA=xx.xx.xx.xx There is also a DEACTIVATE parameter as well. Don't ask me for the exact syntax. I haven't looked it up and it has been several years since I have been in the environment. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Wednesday, October 18, 2023 10:58 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.] On Wed, 18 Oct 2023 17:18:33 +, Allan Staller wrote: >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. The way I read the OP's response, he says everything is handled in the OSA and TCP automatically notifies the OSA when changes affect packet routing. -- 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
Re: DVIPA question
There is a Share presentation called "Getting the most out of your OSA (Opens Systems Adapter)" that does a much better job of describing how the OSA works than I can. On Wed, 18 Oct 2023 22:58:15 -0500, Jon Perryman wrote: >On Wed, 18 Oct 2023 17:18:33 +, Allan Staller >wrote: > >>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. > >The way I read the OP's response, he says everything is handled in the OSA and >TCP automatically notifies the OSA when changes affect packet routing. > >-- >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: DVIPA question
On Wed, 18 Oct 2023 17:18:33 +, Allan Staller wrote: >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. The way I read the OP's response, he says everything is handled in the OSA and TCP automatically notifies the OSA when changes affect packet routing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DVIPA question
On Wed, 18 Oct 2023 11:50:21 -0500, John S. Giltner, Jr. wrote: >When TCPIP on z/OS allocates a IP address that address is registered in the >OSA > so that the OSA has a list of every IP address that is open and which LPAR it > is opened on. This tells us that in addition to SNA, the OSA is also functioning as an internet router. As for "OPEN IP addresses", I believe it registers all "defined IP addresses". Prior to DVIPA, each application needed its own IP addresses because you couldn't depend upon 2 applications moving to the same LPAR. If you have 100 applications moving between 2 LPARs, you needed 100 IP addresses. IP addresses are a very limited resource. I'm guessing that IBM now uses port number routing. All 100 applications would use the same IP address with different ports. >So if you have a VIPA that is defined in the DYNAMIC VIPA range that opens on >LPARA, > the OSA knows that IP address is valid and is on LPARA, when it sees > packet for that address it sends it to the TCPIP stack on LPARA. I interpret this as packets are sent to the LPAR where the application port is active. Move the application to another LPAR, then packets will be sent to that LPAR. > If the STC that allocated that address stops and TCPIP unregisters it from > theOSA. > If that STC is started on LPARB, then the address is registered on the OSA as > belonging to LPARB and any traffic for that address is now sent to LPARB. The OSA detects if the LPAR fails and stops sending it packets. If the application stops (port inactive) or the DVIPA address is deleted, then TCP notifies OSA not to send packets (unregister). As soon as the app is started on another LPAR, that LPAR notifies OSA the port is active (register). >Now if the traffic is routed, this normally means that the OSA's addresses are > in a different subnet from the VIPA's addresses. > You will need OMPROUTE and OSPF setup so the z/OS can tell the distributed > router that it is connected Before looking at OMPROUTE, I would suggest investigating TCP capabilities using the coupling facility. Does it support DVIPA routing and will it correctly route data (DVIPA addresses/ports) when a primary adapter is down? The network people would have set this up as a failure recovery which does not require router changes for the sysplex. If the coupling facility has DVIPA capability, then the network people simply configure the DVIPA address just like the LPAR routes even though it has a different subnet. If my suspicion is correct, as long as the packets get to a valid OSA, the OSA, TCP and coupling facility should handle the rest. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DVIPA question
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 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 on behalf of Laurence Chiu Sent: Tuesday, October 17, 2023 3:45 PM To: 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. 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
Re: DVIPA question
I'll try to explain this as best as I can, but this can get confusing and this is based on my understanding. We do have DB2 setup in Data Sharing and configured using SYSPLEX distributor, which some of the configuration is similar. When TCPIP on z/OS allocates a IP address that address is registered in the OSA so that the OSA has a list of every IP address that is open and which LPAR it is opened on. So if you have a VIPA that is defined in the DYNAMIC VIPA range that opens on LPARA, the OSA knows that IP address is valid and is on LPARA, when it sees packet for that address it sends it to the TCPIP stack on LPARA. If the STC that allocated that address stops and TCPIP unregisters it from theOSA. If that STC is started on LPARB, then the address is registered on the OSA as belonging to LPARB and any traffic for that address is now sent to LPARB. If the OSA is connected to a switch and the traffic is switched, not routed, then nothing should need to be done on the "distributed network" side. The switch won't see any difference. What you need to do on z/OS is define the IP address a DYNAMIC VIPA in your TCPIP PROFILE for each LPAR. Then also define the PORT your server tasks listen on in your PROFILE's PORT definitions on each LPAR something like: 80 TCP MYSERVER BIND 192.168.40.99 What this does is when MYSERVER starts and try to open's TCP port 80 to listen on TCPIP will allocate it to IP address 192.168.40.99 specifically. No matter which LPAR "MYSERVER" is started on the traffic will et sent to the correct LPAR. If you accidentally start it on both at the same time, bad things could start to happen. There are ways that you can have MYSERVER up and running on both LPAR's at the same time, but it does involve a little more configuration and understanding of your application. Now if the traffic is routed, this normally means that the OSA's addresses are in a different subnet from the VIPA's addresses. You will need OMPROUTE and OSPF setup so the z/OS can tell the distributed router that it is connected to which LPAR to route the traffic to. This is a more complex setup and typically is only needed when you have multiple CEC's and you want to move IP addresses from one CEC to another. On Wed, 18 Oct 2023 08:45:52 +1300, Laurence Chiu wrote: >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. >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
Re: DVIPA question
On Wed, 18 Oct 2023 08:45:52 +1300, Laurence Chiu wrote: >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. Since I've never seen an OSA, I must assume that OSA has smart router capabilities and that it's configured correctly. If that's correct, then don't discuss DVIPA with the network people because it's not important to them. I assume that TCP will communicate any router changes needed for DVIPA directly to the OSA or it is using OMPROUTE to make those changes. That's up to you to figure out. >The second LPAR will be in the same subset as the first. Subnet doesn't play a role for DVIPA. Anything we derive from it is an assumption which can be false. For instance, if the subnet is full, then your DVIPA address won't be in that subnet without reorganizing the subnet. There is no requirement that it be in the same subnet. > 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. John Gitner very wisely told you "figure out what needs to be done, or not done". You are at the point that you need to understand DVIPA details. There is more than 1 way to solve most problems. DVIPA can solve many problems but not everything. You must review DVIPA configuration to determine how you will use it to solve your problem. Some things you might want to consider. 1. Are you going to use DVIPA ownership with move or as Art hinted at using workload balance? 2. Will you use DVIPA port protection or have the network people setup a firewall? 3. Can DVIPA detect when you move your app or must you notify DVIPA when the app is moved? About the DVIPA address you need from your network people, I assume the internet data will use existing company assigned addresses but use NAT to convert the ports to your IP address / ports. Do you require the intranet port to be the same as the internet port? You need a static IP address from your network people. This IP address destination will be the OSA NIC's used for both LPARs. Hopefully they are the same NICs. They need to know if you need a firewall or if DVIPA will protect connections. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DVIPA question
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 on behalf of Laurence Chiu Sent: Tuesday, October 17, 2023 3:45 PM To: 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. 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
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. 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
Re: DVIPA question
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. On Tue, 17 Oct 2023 01:52:07 -0500, Jon Perryman wrote: >On Tue, 17 Oct 2023 16:00:56 +1300, Laurence Chiu wrote: > >>We have one LPAR with static IP > >You are saying: >LPAR 1 has static IP address 192.168.40.70 >LPAR 2 has static IP address 192.168.40.71 > >> and a server on that LPAR > >"on that LPAR" is wrong. You actually mean: >You have a server "application" sometimes on LPAR 1 and other times on LPAR 2. >A third static IP address is needed to specifically for server application. > >STOP CALLING THIS IP ADDRESS DVIPA. Technically DVIPA but it's confusing you. >IPA stands for IP Address. You want a static IP Address. DV is unimportant >until it becomes important. Avoid discussing the technology with your network >people since they don't understand it. > >> that supports both internal and external clients. > >When you say "internal", I assume you mean intranet and "external" internet. >For security purposes, your company probably has multiple intranets. For >instance, you would want an intranet for the lobby where untrusted people come >and go. It's still part of your company. > >Your network people will want to know who needs protection from this IP >address because your server may be dangerous. They will also want to know what >protections this IP address will need because others thon your network can be >dangerous. > >Step 1 for you is to create the basic DVIPA definitions. The network people >don't trust you because you didn't prep to understand your software. You can't >answer their questions until you know your setup and what you will take care >of. For instance, apparently you don't care that everyone in the world has >access to TN3270 on your systems. Will your DVIPA definitions have incoming >port numbers restricted to the server application port numbers? What are these >port numbers that must pass thru to the internet? They will want to know that >this IP address is as trustworthy as LPAR 1 & LPAR 2 IP addresses. > >> We want to duplicate that server >>application on a second LPAR and they will be in a sysplex. If the first >>LPAR goes goes down, we want incoming traffic not worry about it. This is >>because automation will startup the server on the second LPAR (they cannot >>be up at the same time since they need to share a VSAM file and we do not >>have VSAM/RLS. > >Keep it simple. You have a server application that will be moved between 2 >LPARS but never active on both. You want the move to be as automatic as >possible. > >We don't duplicate in z/OS which is an important distinction with Unix. There >are situations where the server application moves and both LPARS are active. > >>What we want is for z/OS to move the VIPA to the second LPAR. Since the two >>TCP stacks on the two LPARs are sharing information via XCF, the second >>LPAR should see the primary LPAR is down and take over the service. >> >>So from my reading of the IBM docs, I need the host IP to be a dynamic VIPA >>(DVIPA) so that quoting this manual >> >>https://www.ibm.com/docs/en/zos/2.1.0?topic=addressing-static-vipas-dynamic-vipas-distributed-dvipas >> >>Dynamic VIPAs have the following characteristics:uc >> >> - They can be configured to be moved dynamically from a failing stack to >> a backup stack within the same sysplex without operator intervention ord >> external automation. >> >>I don't want to have to make any changes to upstream routers, IP changes >>etc. The goal is to make it transparent. > >Step 2 you need to educate yourself about the routers that are connected LPAR >1 and LPAR 2. > >DVIPA automatically deletes the IP address in LPAR 1 and defines it in LPAR 2 >but the routers must be told to send data to LPAR 2 instead of LPAR 1. You >need to find out if they are from IBM and IBM automatically changes them. Or >maybe they are unique unshared routers that require automation include router >changes. This is something you must determine > >-- >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
Re: DVIPA question
On Tue, 17 Oct 2023 16:00:56 +1300, Laurence Chiu wrote: >We have one LPAR with static IP You are saying: LPAR 1 has static IP address 192.168.40.70 LPAR 2 has static IP address 192.168.40.71 > and a server on that LPAR "on that LPAR" is wrong. You actually mean: You have a server "application" sometimes on LPAR 1 and other times on LPAR 2. A third static IP address is needed to specifically for server application. STOP CALLING THIS IP ADDRESS DVIPA. Technically DVIPA but it's confusing you. IPA stands for IP Address. You want a static IP Address. DV is unimportant until it becomes important. Avoid discussing the technology with your network people since they don't understand it. > that supports both internal and external clients. When you say "internal", I assume you mean intranet and "external" internet. For security purposes, your company probably has multiple intranets. For instance, you would want an intranet for the lobby where untrusted people come and go. It's still part of your company. Your network people will want to know who needs protection from this IP address because your server may be dangerous. They will also want to know what protections this IP address will need because others thon your network can be dangerous. Step 1 for you is to create the basic DVIPA definitions. The network people don't trust you because you didn't prep to understand your software. You can't answer their questions until you know your setup and what you will take care of. For instance, apparently you don't care that everyone in the world has access to TN3270 on your systems. Will your DVIPA definitions have incoming port numbers restricted to the server application port numbers? What are these port numbers that must pass thru to the internet? They will want to know that this IP address is as trustworthy as LPAR 1 & LPAR 2 IP addresses. > We want to duplicate that server >application on a second LPAR and they will be in a sysplex. If the first >LPAR goes goes down, we want incoming traffic not worry about it. This is >because automation will startup the server on the second LPAR (they cannot >be up at the same time since they need to share a VSAM file and we do not >have VSAM/RLS. Keep it simple. You have a server application that will be moved between 2 LPARS but never active on both. You want the move to be as automatic as possible. We don't duplicate in z/OS which is an important distinction with Unix. There are situations where the server application moves and both LPARS are active. >What we want is for z/OS to move the VIPA to the second LPAR. Since the two >TCP stacks on the two LPARs are sharing information via XCF, the second >LPAR should see the primary LPAR is down and take over the service. > >So from my reading of the IBM docs, I need the host IP to be a dynamic VIPA >(DVIPA) so that quoting this manual > >https://www.ibm.com/docs/en/zos/2.1.0?topic=addressing-static-vipas-dynamic-vipas-distributed-dvipas > >Dynamic VIPAs have the following characteristics:uc > > - They can be configured to be moved dynamically from a failing stack to > a backup stack within the same sysplex without operator intervention ord > external automation. > >I don't want to have to make any changes to upstream routers, IP changes >etc. The goal is to make it transparent. Step 2 you need to educate yourself about the routers that are connected LPAR 1 and LPAR 2. DVIPA automatically deletes the IP address in LPAR 1 and defines it in LPAR 2 but the routers must be told to send data to LPAR 2 instead of LPAR 1. You need to find out if they are from IBM and IBM automatically changes them. Or maybe they are unique unshared routers that require automation include router changes. This is something you must determine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DVIPA question
I am probably not understanding it correctly either. We have one LPAR with static IP and a server on that LPAR that supports both internal and external clients. We want to duplicate that server application on a second LPAR and they will be in a sysplex. If the first LPAR goes goes down, we want incoming traffic not worry about it. This is because automation will startup the server on the second LPAR (they cannot be up at the same time since they need to share a VSAM file and we do not have VSAM/RLS. What we want is for z/OS to move the VIPA to the second LPAR. Since the two TCP stacks on the two LPARs are sharing information via XCF, the second LPAR should see the primary LPAR is down and take over the service. So from my reading of the IBM docs, I need the host IP to be a dynamic VIPA (DVIPA) so that quoting this manual https://www.ibm.com/docs/en/zos/2.1.0?topic=addressing-static-vipas-dynamic-vipas-distributed-dvipas Dynamic VIPAs have the following characteristics: - They can be configured to be moved dynamically from a failing stack to a backup stack within the same sysplex without operator intervention or external automation. I don't want to have to make any changes to upstream routers, IP changes etc. The goal is to make it transparent. On Tue, Oct 17, 2023 at 1:15 PM Jon Perryman wrote: > You're confusing dynamic IP addresses with dynamic VIPA. I've never seen > DVIPA use dynamic IP addresses. > > A static IP address is an address that doesn't change. Many people > incorrectly assume it's assigned to a specific machine. You decide how this > IP address is used. > > Talk with your IBM hardware / software reps because you may not even need > to involve your non-z/OS network people. The world has gone to smart > routers and I suspect IBM included IBM smart routers in your configuration. > In that case, everything is in your domain. It wouldn't be surprising if > IBM smart routers automagically changed with DVIPA requirements. I'm more > familiar with Unix these days which has seen improvements in high > availability requirements. > > If you must involve your network people, don't tell them more than they > need to know. You determine your DVIPA setup which is more about you than > them. Let's assume a simple scenario. Let's say you have 10 systems in a > sysplex with IP addresses 192.168.40.#. You have a static IP address > 192.168.40.177 for DVIPA that will be on one or more of those machines. How > will you tell his router the next hop for 192.168.40.177? Does he want to > keep it simple and forward the packets to the next available z/OS system > and let z/OS forward it to the correct system? > > As for DNS, he defines 192.168.40.177 once. DNS doesn't care where or what > machine uses this address. > > If you're network person is insistent about DVIPA, tell him to think about > it as a virtual network adapter but with more capabilities. This is all > very dependent upon how you will use DVIPA. > > On Tue, 17 Oct 2023 10:07:14 +1300, Laurence Chiu > wrote: > > >I am having a debate with a network person (but not z/OS) how DVIPA works. > >We have a LPAR with static IP which many hosts and firewalls know about > it. > >I want to make this host part of a sysplex and so need to make certain IP > >addresses/ports dynamic so they can be switched to the second LPAR if the > >first goes down. This is a typical business requirement for DVIPA. > > > >My view is we change the IP definition of the IP address from static to > >virtual (VIPA) and the make it dynamic - hence DVIPA but it's actual value > >does not change so that we need no firewall changes or DNS changes. > > > >He thinks we need a new IP address for the host and that means firewall > and > >DNS changes. Not not having worked in a static to VIPA environment before > I > >don't know but from my reading of the TCP documentation for z/OS it seems > >we don't need a new IP address - just a change in the way it's defined. > > -- > 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: DVIPA question
You're confusing dynamic IP addresses with dynamic VIPA. I've never seen DVIPA use dynamic IP addresses. A static IP address is an address that doesn't change. Many people incorrectly assume it's assigned to a specific machine. You decide how this IP address is used. Talk with your IBM hardware / software reps because you may not even need to involve your non-z/OS network people. The world has gone to smart routers and I suspect IBM included IBM smart routers in your configuration. In that case, everything is in your domain. It wouldn't be surprising if IBM smart routers automagically changed with DVIPA requirements. I'm more familiar with Unix these days which has seen improvements in high availability requirements. If you must involve your network people, don't tell them more than they need to know. You determine your DVIPA setup which is more about you than them. Let's assume a simple scenario. Let's say you have 10 systems in a sysplex with IP addresses 192.168.40.#. You have a static IP address 192.168.40.177 for DVIPA that will be on one or more of those machines. How will you tell his router the next hop for 192.168.40.177? Does he want to keep it simple and forward the packets to the next available z/OS system and let z/OS forward it to the correct system? As for DNS, he defines 192.168.40.177 once. DNS doesn't care where or what machine uses this address. If you're network person is insistent about DVIPA, tell him to think about it as a virtual network adapter but with more capabilities. This is all very dependent upon how you will use DVIPA. On Tue, 17 Oct 2023 10:07:14 +1300, Laurence Chiu wrote: >I am having a debate with a network person (but not z/OS) how DVIPA works. >We have a LPAR with static IP which many hosts and firewalls know about it. >I want to make this host part of a sysplex and so need to make certain IP >addresses/ports dynamic so they can be switched to the second LPAR if the >first goes down. This is a typical business requirement for DVIPA. > >My view is we change the IP definition of the IP address from static to >virtual (VIPA) and the make it dynamic - hence DVIPA but it's actual value >does not change so that we need no firewall changes or DNS changes. > >He thinks we need a new IP address for the host and that means firewall and >DNS changes. Not not having worked in a static to VIPA environment before I >don't know but from my reading of the TCP documentation for z/OS it seems >we don't need a new IP address - just a change in the way it's defined. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DVIPA question
I am having a debate with a network person (but not z/OS) how DVIPA works. We have a LPAR with static IP which many hosts and firewalls know about it. I want to make this host part of a sysplex and so need to make certain IP addresses/ports dynamic so they can be switched to the second LPAR if the first goes down. This is a typical business requirement for DVIPA. My view is we change the IP definition of the IP address from static to virtual (VIPA) and the make it dynamic - hence DVIPA but it's actual value does not change so that we need no firewall changes or DNS changes. He thinks we need a new IP address for the host and that means firewall and DNS changes. Not not having worked in a static to VIPA environment before I don't know but from my reading of the TCP documentation for z/OS it seems we don't need a new IP address - just a change in the way it's defined. Appreciate any advice in this area. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
