Bill, Another way I could think of is to stop the MQ VIPA (Virtual IP address) while CICS goes down and start it when CICS comes up and fully functional. It can be done by automation package. The following needs to be taken care a) need to have VIPA for each CICS region in cases where one MQ subsystem might be servicing multiple CICS regions. b) MQ alert may be generated by monitoring software when sender channel at remote end goes into retrying status due to unavailable VIPA.
Regards, Dinesh -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Johnson Sent: Saturday, November 21, 2009 2:06 AM To: [email protected] Subject: Re: MQ set trigger and CICS Tim, Most of the messages that are sent to the queue occur during the day when the CICS regions are up. Infrequently, a message is sent to the queue when the CICS regions are starting but not yet ready. (CICS comes up at 5am) That's when the problem arises. We think the best solution is to have a batch job triggered by the CICS ready message (using Control-O) to set the TRIGGER on the queue to yes and conversely, kick off a batch job to set NOTRIGGER right before CICS comes down at night. I was hoping for another solution. Thanks, Bill Johnson ________________________________ From: Timothy Sipples <[email protected]> To: [email protected] Sent: Fri, November 20, 2009 12:54:48 AM Subject: Re: MQ set trigger and CICS Jantje writes: >It does not take much "duration" to have the issue occur. Just >the time to bounce a CICS (even if it takes only a minute) can >be enough. Been there... Yes, agreed. It depends on the incoming message rate, the size of the incoming messages, and how far the queue can back up. Those factors are situational. But what I'm wondering is whether there's been any consideration of eliminating (or at least reducing) CICS service outages when bouncing any particular CICS region(s). There are certainly ways (plural, probably) to run CICS in higher availability fashion. I suppose one alternative is to stop incoming MQ messages first, let CICS drain the remaining messages in the queue, bounce CICS, then tell MQ to resume accepting incoming messages. But then you've just converted your CICS outage into an MQ outage, and thus converted a (somewhat delayed) processing interruption into an immediate service interruption. In other words, that sounds to me like going backwards. :-) It's also apparently unacceptable, because the original question is premised on the problems with having the queue fill up and stop accepting messages. So I think the real solution here is beefing up CICS's robustness in at least one way, unless I'm missing something in the original question. It sounds like MQ is doing exactly what it's supposed to do (and to its configured limit), but the thing that's draining the queue is currently suffering from an interruption that's too long. Hence, how about we focus on shortening (or eliminating) the interruption in the draining? I don't really see any other way -- again, unless I'm just totally missing the true nature of the original question. ....Or, I guess you could (if possible) get a bigger bucket, i.e. figure out a way to enlarge the queue, to hold enough messages to survive the drainer's outage. Bigger queue, more timely/reliable draining, or some combination: isn't that the full solution choice set here? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
