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 <allan.stal...@hcl.com> 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 <IBM-MAIN@LISTSERV.UA.EDU> 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 +0000, Allan Staller <allan.stal...@hcl.com> >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
