That is some useful information. Thanks. Of course in this case the application in question is a card authorization system the communicates with endpoints using simple TCP sockets (directly in to the CICS region), so your example as given probably wouldn't work, but its good to know that it isn't "terrible practice" as such to have some CICS regions that can only run in a single LPAR at a time. Or at least I think that's what you are saying.
Which is not to say we wouldn't want to put effort in to making the application Sysplex friendly. Which is why I am looking to know how to determine if an application is (probably) Sysplex friendly or not. > Date: Fri, 13 Nov 2015 15:59:20 +0800 > From: [email protected] > Subject: Re: Applications in a Sysplex/CICSplex > To: [email protected] > > Jumping slightly ahead, let's assume for sake of argument the application > in question "would not work correctly as-is" in a CICSplex. When then? > > It's not typically a "hard stop." It depends on what you're trying to > accomplish. Let's suppose, for example, that you have an MQ channel > interface logically in front of the CICS-hosted application in question. > It's possible that implementing an MQ shared queue -- one of the many > possible Sysplexed services -- could, all by itself, provide substantial > value. If the single CICS region (or single set of regions) hosting this > application is(are) offline -- perhaps because a whole z/OS LPAR is > undergoing maintenance -- MQ could still be receiving messages and queuing > them up for processing when the application comes back online. And that > could still be really useful in business service terms. In this scenario > you could also probably automate "flip flop" of the single CICS region (or > single set of regions) across LPARs to minimize service interruptions, even > with a "CICSplex hostile" application. MQ holds the incoming work across > switchovers. The queue/channel interface is continuously available, though > when there's a switchover in back the outbound response might be slightly > delayed. Not "perfect," but not so bad! > > That's just an example, and there are many variations. I simply wanted to > make the point that even if it's "the end of the world" (so speak), and the > application in question is just awfully designed and relatively difficult > to cure (hopefully not!), you still might have some reasonably or even > tremendously useful options to explore. "It depends." > > (But hopefully this whole hypothetical is moot in your particular > situation.) > > -------------------------------------------------------------------------------------------------------- > Timothy Sipples > IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA > E-Mail: [email protected] > > ---------------------------------------------------------------------- > 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
