ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » Using Chl Exits with Cluster Channels?

Post new topic  Reply to topic
 Using Chl Exits with Cluster Channels? « View previous topic :: View next topic » 
Author Message
TonyD
PostPosted: Mon Jan 12, 2004 4:34 pm    Post subject: Using Chl Exits with Cluster Channels? Reply with quote

Knight

Joined: 15 May 2001
Posts: 540
Location: New Zealand

We have used a variation of the Channel Message Exit Supportpac to log messages passing across channels, at the sending and receiving ends. Copies of messages are written to journal queues, and optionally to a flat file, controlled from a .ini file specified in the 'Message Exit Data' property.
We now want to implement the same exit on cluster channels. The Intercommunication manual confirms that Message Exits are supported for clussdr and clusrcvr channels. However I have run into a couple of problems.
I am testing with a 'gateway' QM (partial repository) that shares a cluster with two full repository QMs (copies of each other), QM1 and QM2. I have a cluster queue that is defined locally on each repository QM, and both are therefore available from the gateway QM.
I have specified a Message Exit on the cluster sender (automatic and explicit) channel on GWQM to QM1. The first problem that I have is that the Exit is not driven, and in fact seems to be ignored! I even deliberately misspelt the path of the Exit, stopped and restarted the channel with no problem and sent messages across the channels from GWQM to the cluster queue on QM1. So far no logging messages...and nothing in the Event Log or the AMQERR01 files.
The second problem occurs when I specify the Exit against the cluster receiver channel on QM1. Our exit connects to the Queue Manager (specified in the .ini file) in order to get the connection handle to open the journal queue. Normally it gets a warning reason code '2002' saying 'Already Connected', which is ignored. However when running against the clusrcvr channel it gets reason code '2103' which says that the thread is already connected to a different queue manager. The '2103' is recorded in our log file, the channel is terminated, and subsequent messages sit on the Cluster Transmit queue.
I have rechecked my definitions and kept things as simple as possble. The Exit works as required on non-cluster channels without problem. Has anyone tried anything similar or had success implementing this type of channel exit on cluster sender and receiver channels? The Exit works as required on non-cluster channels without problem. The platform I am using for testing is Windows 2000 with MQ 5.3 CSD4.
Back to top
View user's profile Send private message Send e-mail
oz1ccg
PostPosted: Tue Jan 13, 2004 3:06 am    Post subject: Reply with quote

Yatiri

Joined: 10 Feb 2002
Posts: 628
Location: Denmark

The options of the CLUSSDR is obtainted from the receiver end, this means that the CLUSSDR is ONLY used to establish the first initial communication where the parameteres is negotiated.

This means that the exit parms have to be specified on the CLUSRCVR, or using the CHAD exit.

I hope it clears up a bit.

Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT.
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
TonyD
PostPosted: Tue Jan 13, 2004 3:03 pm    Post subject: Reply with quote

Knight

Joined: 15 May 2001
Posts: 540
Location: New Zealand

oz1ccg, I think your suggestion might explain the behaviour that I am observing. I was aware that 'automatically defined' CLUSSDR channels derived their properties from explicitly defined CLUSRCVR channels, but had thought that 'explicitly defined' CLUSSDR channels would retain their own properties, and had therefore taken the precaution of explicitly defining the CLUSSDR channel from my 'gateway' QM (partial repos); the channel is shown as 'Automatic and Explicit Cluster Sender' and allows me to define Message Exit properties, unlike an 'Automatic Cluster Sender'.
In my Situation #1 (exit not driven) the CLUSSDR channel had the Exit specified while the CLUSRCVR channel did not.....if the CLUSRCVR properties were applied to the CLUSSDR (as you suggest) no exit would be driven.
In Situation #2 (Already connected to a QM) the Exit was specified at the CLUSRCVR but not at the CLUSSDR. A trace appeared to show an attempted connection to the destination QM1 from a Gateway QM process (AMQRMPPA - Listener), when the MCA was already connected to GW QM. This would occur if the CLUSSDR had 'inherited' the Message Exit properties from the destination CLUSRCVR channel, as the Exit attempts to connect to a QM specified in the .ini file.
I have subsequently:
1. Specified a Message Exit on my 'explicit' CLUSSDR channel, and stopped/started the channel. The Exit property is displayed in the Explorer Advanced/Channels view, but is blank when displayed under 'Cluster Queue Managers'.
2. Specified a Message Exit (different properties) on the corresponding CLUSRCVR channel and stopped/started the channel. The same Exit properties are displayed under 'Cluster Queue Managers' for both the CLUSRCVR and the CLUSSDR channels (confirming the derivation), even though the CLUSSDR view under Channels/Advanced shows different Message Exit properties (those specified in 1. above).
This effectively proves your suggestion, and appears to confirm that a Message Exit cannot be explicitly specified for a CLUSSDR channel. I don't think I have seen this documented anywhere that 'explicit' CLUSSDR channels also derive the properties from the corresponding CLUSRCVR channel.
Thanks again for putting my in the right direction.
Back to top
View user's profile Send private message Send e-mail
TonyD
PostPosted: Tue Jan 13, 2004 3:26 pm    Post subject: Reply with quote

Knight

Joined: 15 May 2001
Posts: 540
Location: New Zealand

Whoops...a quick look at the Clusters manual showed:
Quote:

Auto-defined cluster-sender channels take their attributes from those specified in the corresponding cluster-receiver channel definition on the receiving queue manager. Even if there is a manually-defined cluster-sender channel, its attributes are automatically modified to ensure that they match those on the corresponding cluster-receiver definition.

I actually read this section when wrestling with the problem, but completely missed the sentence in bold!
Back to top
View user's profile Send private message Send e-mail
oz1ccg
PostPosted: Wed Jan 14, 2004 9:59 am    Post subject: Reply with quote

Yatiri

Joined: 10 Feb 2002
Posts: 628
Location: Denmark

I can only say welcome to the club.

Anyway, when the channel is established between different platforms/companies etc. it's a good idea to have a CHAD exit to fix such "small" details. especially when dealing with Z/OS vs. all other platforms, because of the way of specifying the security exits...

The CHAR can just overload the parameters that your site don't like, so you'll allways get the right exits, timeout etc.

Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT.
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » Using Chl Exits with Cluster Channels?
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.