| Author |
Message
|
| zhanghz |
 Posted: Wed Jul 08, 2009 11:09 pm Post subject: CSQX037E and CSQX009I Channel initiator stopping |
 |
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
Hi,
This might not be just for z/OS WMQ, that's why I post it here.
We started a qmgr in DR, and later found out the channel initiator was purged. I checked the syslog and found out the following chains of events:
12:50:18, S QMGRMSTR
12:50:22, QMGRMSTR issue command S QMGRCHIN to start CHINIT.
12:51:58, a job was run to clear queues, including SYSTEM.CHANNEL.INITQ.
12:56:20, the following messages for CHINIT came out:
| Quote: |
+CSQX141I +QMGR CSQXADPI 8 adapter subtasks started, 0 failed
+CSQX410I +QMGR CSQXREPO Repository manager started
+CSQX151I +QMGR CSQXSSLI 5 SSL server subtasks started, 0 failed
+CSQX015I +QMGR CSQXSPRI 20 dispatchers started, 0 failed
+CSQX037E +QMGR CSQXSPRI Unable to get message from 778
SYSTEM.CHANNEL.INITQ, MQCC=2 MQRC=2033
+CSQX009I +QMGR CSQXSPRI Channel initiator stopping
+CSQX419I +QMGR CSQXREPO No cluster-receivers for cluster MQCGMCPGEP
+CSQX419I +QMGR CSQXREPO No cluster-receivers for cluster MQCGMCPGEP |
I do not understand why there is a CSQX037E, and why there is a CSQX009I (chinit stopping). Does this imply SYSTEM.CHANNEL.INITQ MUST have some messages inside when CHINIT starts? But then why the CHINIT could start when I manually started it at 13:25 at which time the SYSTEM.CHANNEL.INITQ was also empty.
Please advise.
Thanks. |
|
| Back to top |
|
 |
| aditya.aggarwal |
| Posted: Thu Jul 09, 2009 2:13 am Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
| Quote: |
| Does this imply SYSTEM.CHANNEL.INITQ MUST have some messages inside when CHINIT starts? |
no it does not need any message when CHINIT starts...
you are getting mqrc 2033 because you are running a job to clear queue... and no more mesaage avialable in INITQ...
Check your job whether it is purging the CHINIT..?
Why you are running a job to clear SYSTEM queues?
Cheers,
Aditya
Cheers,
Aditya |
|
| Back to top |
|
|
| zhanghz |
| Posted: Thu Jul 09, 2009 2:53 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
the job clears all queues, stop all channels, start channels that particiate in DR test.
It's a precaution that system queues are also cleared. There was a case before that production data flew into DR environment during a DR test. So I guess, since then, several precautionary measures have been taken to avoid that from happening again. This clearing queues is one of them. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 09, 2009 3:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zhanghz wrote: |
| It's a precaution that system queues are also cleared. |
Including all the configuration information the queue manager keeps there?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Jul 09, 2009 5:03 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
My bet is that the job the clear the queues was still running when the queue manager was trying to start a triggered channel and you foolishly clobbered the trigger message before the queue manager could grab it.
Clearing all the SYSTEM queues is a recipe for disaster. So if the intent of the DR test was to see how much of a D you could inflict upon yourself it was a howling success! 
Even in the event of a disaster recovery test I can think of no reason to clear all of the SYSTEM queues and lots of reasons why not to do so.
Why are you worried about clearing them? |
|
| Back to top |
|
|
| zhanghz |
| Posted: Thu Jul 09, 2009 4:50 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
To Vitor,
Yes, if the system queues are successfully cleared, I believe all system configurations are gone.
To kevinf2349,
I agree with you. To me, no queues should be cleared, not even application queues. But this thing is there for years and no problem was reported due to this clearing, so no one would want to change that now. Because if anything did happen after the change, MQ will be the first and maybe the only party that will get interrogated and gun down.
Anyway, legacy that is. Back to topic, the clearing job had completed already when qmgr tried to get messages from SYSTEM.CHANNEL.INITQ at 12:56.
My understanding is that qmgr monitors SYSTEM.CHANNEL.INITQ for trigger messages and channel status. So, if qmgr can't find any messages in the queue, why would it think there is an error and start stopping the channel initiator? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 09, 2009 5:10 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| zhanghz wrote: |
| But this thing is there for years and no problem was reported due to this clearing, so no one would want to change that now. |
So if you went onto your roof during every thunderstorm for the past 5 years, and never got struck by lightning, do you think you should keep doing it?
Clearing all SYSTEM.* queues after you start a QM is wrong. Regardless of how many times you have done it already.
But I agree with you. A 2033 causing the CHINIT to go down seems odd.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 09, 2009 8:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| PeterPotkay wrote: |
| zhanghz wrote: |
| But this thing is there for years and no problem was reported due to this clearing, so no one would want to change that now. |
So if you went onto your roof during every thunderstorm for the past 5 years, and never got struck by lightning, do you think you should keep doing it?
Clearing all SYSTEM.* queues after you start a QM is wrong. Regardless of how many times you have done it already.
But I agree with you. A 2033 causing the CHINIT to go down seems odd. |
Are there any other error messages in the logs or any FDC created?
I would think that maybe this is safety feature looking as no information at all can be found in the SYSTEM.CHANNEL.SYNC.QUEUE 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
