Thanks, Skip, for underscoring that point I was making with your real world example.
OK, Frank, so you've got an application that uses IP sockets connectivity for its inbound channel. Let's assume for sake of argument the very worst case, that the application in its present form is not easily amenable to running in two or more concurrent instances. What to do? Here are a couple ideas: 1. Shift the IP socket connectivity to MQ, then proceed along the lines I suggested. 2. Mask the issue with a front-end program. Create a very small front-end "sockets stub" program that does whatever you want/need it to do in the CICSplex, and implement automated switchover behind it. That small front-end program might do something like this (externally parameterized): (a) Try normal processing with the standard back-end program. If the back-end responds, no further action is required. (b) If unsuccessful, determine when the normal back-end program processed the last transaction. If more than XXX seconds ago, deny the card transaction and report a "system offline" error. (c) If XXX seconds ago or less, evaluate whether an "offline" transaction counter (ZZZ) has been reached. If ZZZ has been reached while the back-end is offline, deny the transaction and report a "try again in XXX seconds" error. (d) Otherwise, if the transaction is for $YYY or less record the transaction for later processing and approve it. If the transaction is over $YYY deny the transaction with an "over limit" error. The idea here is that the risk officer (or equivalent) in your organization would decide that it's OK to approve XXX seconds worth of "small" transactions (up to a transaction count limit of ZZZ per day, week, or month) "on faith" during those infrequent events when you need to "swing" the back-end application, to perform a z/OS release upgrade for example. The reason for the time and transaction count checks is to make sure that the total dollar risk to the business is firmly capped. In exchange for taking that limited risk, you might have a much easier remediation strategy, and importantly you can provide "continuous" service to card holders. If they're paying for taxi rides during the switchover they shouldn't notice anything, although the few people buying diamond earrings at 3:00 a.m. your time might have to try their transactions again. -------------------------------------------------------------------------------------------------------- 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
