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 <[email protected]> On Behalf Of John S. Giltner, Jr. Sent: Monday, October 23, 2023 9:46 AM To: [email protected] 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 +0000, Allan Staller <[email protected]> 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 <[email protected]> On >Behalf Of Jon Perryman >Sent: Friday, October 20, 2023 11:41 AM >To: [email protected] >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 +0000, Allan Staller <[email protected]> >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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
