We have an application that utilizes an RYO record locking mechanism. I believe that it predates even LPAR, when all CICS regions ran on a single OS image that occupied an entire CEC. The locks live in a CSA table, which is great for regions running in the same image but problematic for regions running on other images. Nonetheless this application was 'parallelized' decades ago and works quite well--except when we need to roll the application to another LPAR for maintenance or IPL. In that case, the table-owning region is shut down on its usual LPAR and brought up on the alternate LPAR. Of course ideally the roll should be transparent, but the lock table move imposes two minutes-long outages to the application.
If this table were transformed into a CF lock structure, the application could be rolled seamlessly. No one has been able to sell the business case for such a transformation to save a few minutes of down time per month. Despite this imperfection, the benefits of a parallelized application are truly game changing. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Thursday, November 12, 2015 11:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Applications in a Sysplex/CICSplex 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: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
