| Author |
Message
|
| silentflute |
 Posted: Wed Mar 16, 2005 11:42 am Post subject: Channel Auto Definition (CHAD) Exit |
 |
|
Apprentice
Joined: 14 Jul 2004
Posts: 32
|
Does anyone have a sample channel auto definition exit program that alters a message exit path information from a z/OS platform to a UNIX platform format, that could be shared?
I have written a message exit program to alter the 'reply-to-queue-manager-name for a request / reply model application that uses an internal cluster to initiate the request from a z/OS platform using a cluster queue that resolves to several queue managers located on a UNIX platform.
The message exit is defined on the cluster receiver channel to the UNIX queue managers, or the z/OS cluster sender channel. Because the cluster receiver channel is defined to each UNIX queue manager, the channel definition of the cluster receiver channel for each queue manager contains the name of the queue manager located in the message exit data parameter and this queue manager name is moved into the message header reply-to-queue-manager-name so the reply message will be sent back to this queue manager.
But because the message exit is located on different platforms, a channel auto definitions exit must be use to correct the message exit path information.
Thanks! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Mar 16, 2005 11:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I don't understand what you are trying to do, or why you are trying to do it with a CHAD exit. It seems like a lot of work that is likely not necessary.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| silentflute |
| Posted: Wed Mar 16, 2005 12:23 pm Post subject: |
|
|
Apprentice
Joined: 14 Jul 2004
Posts: 32
|
Jeff,
Because the message exit involves different platforms, z/Os and UNIX, and the format of the message exit path information is different, a CHAD must be used to change the z/OS cluster sender channel message exit platform to look like a UNIX message exit platform path.
Please see the WMQ Using Clusters manual, section titled 'Using security exits on cluster channels', point #5.
Thanks! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 16, 2005 12:44 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay.
I guess I don't understand why you're using the message exit, then.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| silentflute |
| Posted: Wed Mar 16, 2005 1:07 pm Post subject: |
|
|
Apprentice
Joined: 14 Jul 2004
Posts: 32
|
Jeff,
Thanks for your reply.
A single z/OS queue manager in a cluster which has a cluster request queue.
To get to an external client, the request must go through one of multiple UNIX queue managers in the same cluster using the round robin cluster algorithm. The reply should be returned to the same UNIX queue manager that the request came from. Because the message can go to any UNIX queue manager in the cluster, the application does not know which reply-to-queue-manager-name to code. So a message exit on the cluster receiver channel on the UNIX queue manager plugs in the reply-to-queue-manager-name on the message header for the receiving application to be used for the reply message.
That make sense.
Thanks! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 16, 2005 1:15 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So, the request messages are going TO an external entity THROUGH the Unix QMs, not TO the Unix QMs? And likewise, the reply messages are going TO the z/OS THROUGH the Unix QMs?
Why is there affinity to some particular Unix QM, then?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| silentflute |
| Posted: Wed Mar 16, 2005 1:19 pm Post subject: |
|
|
Apprentice
Joined: 14 Jul 2004
Posts: 32
|
Jeff,
The UNIX servers are a common link to this external site and thus anything that needs to go to this external site, goes through the UNIX servers to get there. This limits the number of conenctions to the outside world.
Thanks! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 16, 2005 1:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
How about having them alias the qmgrs in the cluster to flow through your gateway?
The only problem I see there would be if you have dupplicate queue manager names in both networks.
Enjoy  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 17, 2005 12:19 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| silentflute wrote: |
The UNIX servers are a common link to this external site and thus anything that needs to go to this external site, goes through the UNIX servers to get there. This limits the number of conenctions to the outside world.
|
Yes, but why do you need to ensure that the Unix server that sent the request is the same Unix server that receives the reply?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| silentflute |
| Posted: Tue Mar 22, 2005 4:38 am Post subject: |
|
|
Apprentice
Joined: 14 Jul 2004
Posts: 32
|
Jeff,
That's a good question. Strictly speaking, it doesn't. But, somehow, somewhere, the reply-to-queue-manager-name of the message has to be populated with the name of one of the UNIX queue managers.
If multiple UNIX clustered queue managers are being used and the application never knows which one and what queue managers are available, then there is no way for the application to determine the reply-to-queue-manager-name.
A reply-to-queue-manager-name has to be chosen and that UNIX queue manager name must be available, so the only way that I can figure out is to use the message exit on the cluster receiver channel for any available UNIX queue manager.
Does this mean that the UNIX queue manager will always be available once the message has been transmitted to the external site? No, there is a small window while the message is being transmitted to and from the external site that the UNIX queue manager could go down.
I'm opened to any other options.
Thanks! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 22, 2005 5:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So there's no particular need for a message to leave and return through the same Unix queue manager.
Then you just need to share a Qmgr alias in the Unix cluster and use that as the ReplyToQMgr.
But maybe someone who's implemented overlapped or stacked clusters will correct me if I'm wrong.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| silentflute |
| Posted: Tue Mar 22, 2005 5:56 am Post subject: |
|
|
Apprentice
Joined: 14 Jul 2004
Posts: 32
|
Jeff,
Thanks for your response.
If I understand correctly, the qmgr alias would need to be defined by the external customer. If this is the case, it would not work as they have already refused to define any qmgr aliases in their queue manager. They take the reply-to information and put the message onto the appropriate transmission queue for the reply.
Thanks! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 22, 2005 6:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Is their queue manager in your cluster?
If not, what mechanism is being used to gateway their traffic to your cluster?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| silentflute |
| Posted: Tue Mar 22, 2005 6:14 am Post subject: |
|
|
Apprentice
Joined: 14 Jul 2004
Posts: 32
|
Jeff,
I'm sorry, this setup is a part clustering and part distributed queuing.
The internal mainframe to UNIX is an internal cluster. The cluster queue on the mainframe resolves to a remote queue definition on the UNIX servers, where the queue resolves to the external queue manager. The external queue manager 'gets' the message, processes it, and 'puts' it on the appropriate transmission queue using the reply-to information. The message arrives on a remote queue definition on the UNIX servers, which is really the reply-to-queue-name. From the UNIX servers, the message flows to the true single application reply queue on the mainframe.
Thanks! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 22, 2005 6:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Then they just need a transmission queue that is named the same as your qmgr alias.
If I remember right.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
