Author |
Message
|
ulli |
Posted: Tue Aug 31, 2004 3:19 am Post subject: |
|
|
Novice
Joined: 16 Aug 2004 Posts: 20
|
Hi EB,
when you are deleting messages from the SYSTEM.CHANNEL.SYNCQ you are loosing channel informations (sequence numbers and logical units of work identifiers (LUWID)) and you have to reset this channel at the next restart. So it isn't recommended to delete messages from this queue. But it is worth to check if there are duplicate messages for a channel at this queue. There is a tool available it is called CSQ4UTIL.
Also I would check the SYNCQ before a stop of the qmgr and after the restart, are there any differences maybe a different qdepth?
Regards, Ulli |
|
Back to top |
|
 |
EB |
Posted: Tue Aug 31, 2004 3:54 am Post subject: |
|
|
 Acolyte
Joined: 19 Mar 2004 Posts: 70
|
Hi again
I have now checked the SYSTEM.CHANNEL.SYNCQ and discovered that we infact have several sets of messages with identical MessageIDs.
How do I proceed from here?
What are the implications?
How did this happen and how can I make sure it does not happen again?
...
..
.
Any advice is gratly appreciated.
Regards
EB |
|
Back to top |
|
 |
ulli |
Posted: Tue Aug 31, 2004 4:40 am Post subject: |
|
|
Novice
Joined: 16 Aug 2004 Posts: 20
|
Hi,
did you use the utility CSQ4SUTL for the check for duplicate messages(sorry for the wrong name in my previous update)? You can use this utility to delete the duplicate messages, but I would contact the local IBM support to find out why the problem did happen.
Regards, Ulli |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Aug 31, 2004 4:11 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
try deleting and recreating the channels that have the duplicate entries. This should force fresh correct entries into the queue.
I am pretty sure there is a more roundabout way of accomplishing the same thing, but if you can, delete/recreate is much simpler and faster.
We had to do something like this a couple of years ago. Follow a convoluted 20 step process, or just recreate the channel. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
SMWalker |
Posted: Wed Sep 01, 2004 11:00 am Post subject: |
|
|
 Novice
Joined: 20 Aug 2002 Posts: 16 Location: NJ
|
This occurs because you are stopping the queue manager when you IPL, while the other queue managers are still up and running. To solve this problem, you can use the RESET CHANNEL command on the other queue managers. This will reset the sequence numbers between the queue managers. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Sep 01, 2004 11:11 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
QMs can come up and down, either one side or both sides, in any order, without sequence number errors. If there are errors, there is a probelm that needs to be fixed. Having to issue RESET after every QM bounce is not necessary when things are working correctly. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
SMWalker |
Posted: Wed Sep 01, 2004 12:13 pm Post subject: |
|
|
 Novice
Joined: 20 Aug 2002 Posts: 16 Location: NJ
|
PeterPotkay wrote: |
QMs can come up and down, either one side or both sides, in any order, without sequence number errors. If there are errors, there is a probelm that needs to be fixed. Having to issue RESET after every QM bounce is not necessary when things are working correctly. |
He is not just talking about bringing a queue manager up or down, he is refering to a physical bounce of the box, which for an OS/390 or Z/OS box means that the master address space and the channel space that are allocated on start up have been wiped. The sequence number would be reset to 1.
To solve this you can either try resetting the sequence number to the expected number (if you are on the mainframe), or reset the channels on the other end.
I ran into this problem years ago when I worked on Mainframes connecting to OS/2 servers. The RESET CHANNEL command was the only thing that would fix the problem. Granted that was Version 2.1 for S/390, but the principal is the same. |
|
Back to top |
|
 |
kevinf2349 |
Posted: Wed Sep 01, 2004 12:25 pm Post subject: |
|
|
 Grand Master
Joined: 28 Feb 2003 Posts: 1311 Location: USA
|
We bounce our z/OS system on a weekly basis and have no problems with MQ channels....of course all our channels are triggered and have disconnect intervals set.
You could try issuing stops for all the channels and have start commands in the startup process for the Qmgr...that should do it without having to RESET I would have thought |
|
Back to top |
|
 |
EB |
Posted: Wed Sep 01, 2004 9:00 pm Post subject: |
|
|
 Acolyte
Joined: 19 Mar 2004 Posts: 70
|
Hi everyone and thanks very much for engaging in this matter.
SMWalker:
The problem also occurs when just stopping and starting the qmgrs as well as after IPL. But only for qmgrs on z/OS. Rebooting distributed systems is no problem.
To have the channels run at all, I am reseting the other end every time after IPL or bouncing QMGR on z/OS. This is actually a workaround I want to avoid having to do.
I also believe as stated by PeterPotkay that if configured correctly this problem should not arise.
At this time I am looking into the issue about duplicate messages on the SYSTEM.CHANNEL.SYNCQ as suggested by Ulli earlier. We have infact several sets of duplicate messages on the SYSTEM.CHANNEL.SYNCQ on all mainframe qmgrs. However there are not duplicate messages for all channels. Therefore I am not sure this is the solution I am looking for since the problem occurs for all channels.
Any further suggestions are greatly appreciated.
Regards
EB |
|
Back to top |
|
 |
ulli |
Posted: Thu Sep 02, 2004 3:32 am Post subject: |
|
|
Novice
Joined: 16 Aug 2004 Posts: 20
|
Hi,
when you browse your SYSTEM.CHANNEL.SYNCQ before and after the restart of MQ,
can you see the same messages (don't just check the curdepth)?
Are there any differences?
Regards, Ulli |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Sep 02, 2004 4:12 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
We IPL almost every weekend without doing anything special to the channels ahead of time and never have sequence # problems either.
EB, did you delete and recreate the problem channel? And then look to see if the duplicate entry still exists in the SYNCQ? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|