MVSFORUMS.com

[MikeBaker]

Hi,

I'm hoping that someone might have some idea about this problem:-

1: We have a CICS system with a DB2 subsystem. At start of day, the connections to both DB2 and MQ are initiated.

2: The DB2 subsystem crashed, and was restarted.

3: We noticed that the MQ Listener appeared to not be running. All the messages were being queued up, and none were being processed.

4: Tried to restart the MQ Listener, but CICS said that it is "already running". But the messages were still being queued up.

5: The MQ Listener was stopped and then restarted, and everything was now all okay.

============================================

Question: Does anyone know what REALLY happened here. Why did the MQ Listener have to be stopped?

We can say that "the Listener needed recycling", but this is very simplistic, and is not really a knowledgable answer.

Is there anything in the IBM manuals about this, and how can we prevent the need for manual intervention in a similar future occurrence??

Many Thanks.

[kolusu]

MikeBaker,

I remember reading somewhere that you need set the listener port once again and start the listener whenever you had restart of the system. I will try to find the documentation. Also I remember there is an APAR/Fix for this.

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

[Jeba]

MikeBaker,

We too had similar kind of problem in our system. But we don't have DB2 in our shop.

The trigger setup for our queue is FIRST. Whenever new message comes in to the queue, the Queue will trigger the corresponding CICS program associated with it. This kind of problem happens when the queue receives multiple messages and the program crashed for the first message. After the program crashes, all the MQ messages will be backed out to the queue. The queue will trigger whenever the queue depth varies from 0 to 1. So the messages submitted to the queue after the backout will not trigger a new CICS task.

Whenever the CICS program crashes, the messages will be sitting in the queue and they will not be processed at all. So we usually call the MQ support person to Switch OFF and then Switch ON the trigger for the particular queue. This will solve the problem. After long time, we switched OFF and ON the queues using the job instead of calling MQ support to do the same.

Please ignore this response if it didn't solve your problem.
_________________
Thanks,
Jeba
(Known is a drop Unknown is an ocean)

[Bill Dennis]

Also check on the TRIGINT setting on the QMGR. This will re-trigger a queue with TRIG(FIRST) and messages present but no tasks reading it. Ours is set to 120000 millesecs (2 mins).

Regards,
Bill