| Author |
Message
|
| cmkeller |
 Posted: Wed Dec 06, 2006 2:19 pm Post subject: Channel info in C#? |
 |
|
Apprentice
Joined: 09 Jan 2005
Posts: 41
Location: Queens, NY
|
Is there any way to get channel information in the C# MQSeries API?
I'm using Websphere 5.3 with FixPack 12.
_________________
Chaim Mattis Keller
Shadow Financial Services Corp
ckeller@shadowfinancial.com |
|
| Back to top |
|
 |
| wschutz |
| Posted: Wed Dec 06, 2006 2:39 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
sure....send a PCF "Inquire Channel Status" message to the command server.
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Dec 06, 2006 2:44 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Why do you want to get Channel Information in the C# MQSeries API?
I hope you aren't trying to code an application to decide whether to send a message based on if a channel is Running or not.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| cmkeller |
| Posted: Wed Dec 06, 2006 5:18 pm Post subject: |
|
|
Apprentice
Joined: 09 Jan 2005
Posts: 41
Location: Queens, NY
|
wschutz: How is that done in C#? I don't see anything in the pdf documentation I have.
jefflowery: I'm trying to get my application to notify the user if the channel is not actively running. When my users try to send something over an inactive channel, they're left scratching their heads wondering why the message was never received.
I'd been able to do this in C/C++, but now I have a mandate to port the whole thing to C#.
_________________
Chaim Mattis Keller
Shadow Financial Services Corp
ckeller@shadowfinancial.com |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Dec 06, 2006 5:48 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The user should never know whether any MQ server-server channels are started or not.
The user only needs to know that MQ has received the message properly.
The channels should be triggered to start automatically whenever a message arrives on a Transmit queue, or should be configured to be running all of the time. It should not be the case that messages sit on a Transmit queue until someone performs a manual step. You should also have some kind of enterprise monitoring to raise an alert to the MQ Administrators that there are messages sitting on a Transmit Queue.
If the user needs to know that their message has been received, then you should either use REPORT messages to indicate receipt by the other side, or a Request/Reply pattern.
MQ is asychronous. The only good approach to handling syncrhonous communications with MQ is to use a Request/Reply pattern.
If you really need to continue with your current design, then you can eithe r use PCF messages, or you can tell us how you acheived this in C/C++, and we can give you some idea of how to do it in C#.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| cmkeller |
| Posted: Wed Dec 06, 2006 9:01 pm Post subject: |
|
|
Apprentice
Joined: 09 Jan 2005
Posts: 41
Location: Queens, NY
|
jefflowery:
| Quote: |
| The user only needs to know that MQ has received the message properly. |
Er...no. The user needs for MQ to have received the message properly, and if it didn't, what they can do to make it happen. If a channel napping is what caused it, I'd like to be able to tell them.
| Quote: |
| The channels should be triggered to start automatically whenever a message arrives on a Transmit queue, or should be configured to be running all of the time. |
Now, this is a suggestion I can work with. How do I set the channels to be so triggered?
| Quote: |
| If the user needs to know that their message has been received, then you should either use REPORT messages to indicate receipt by the other side, or a Request/Reply pattern. |
We do this. But how does that help if the messages never get sent out across the channel?
| Quote: |
| If you really need to continue with your current design, then you can eithe r use PCF messages, or you can tell us how you acheived this in C/C++, and we can give you some idea of how to do it in C#. |
In C/C++, I used the MQ Admin Command interface. I got the transmission queue of the queue I was sending, then got a complete list of channels, then, after looping through and finding the channel which serves this transmission queue, inquiring as to the status. I used the mqExecute function, and set up "bags" for each mqExecute call.
_________________
Chaim Mattis Keller
Shadow Financial Services Corp
ckeller@shadowfinancial.com |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 06, 2006 9:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| cmkeller wrote: |
| Now, this is a suggestion I can work with. How do I set the channels to be so triggered? |
Look it up in the intercommunications manual.
Check the XMITQ set it to trigger first and set the initq to system.channel.initq....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Dec 07, 2006 2:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The MQPut will still succeed if the channel is shut down. So MQ has still received the message just fine.
If you are using Report Messages, and the channel is stopped, then the user will know that a) MQ received their message successfully because the PUT succeeded. b) They did not receive the COA/COD report message after X period of time.
If the channel is running, then the user will know that a) the message was put successfully, and that b) they did receive their COA/COD report message. (this really actually requires that both the channel from and the channel to the other queue manager are running, to make sure the COA/COD can be delivered).
Think of channels like postal trucks. As the person sending the package, you don't care which truck your package goes to, or whether it's low on gas right now or needs a new tire. All you care about is whether or not your package gets where it's going on time!
There are specific steps in the Intercommunications Guide for configuring your channels for triggering. There's a link in the Links forum on Triggering, that includes a direct pointer to that section.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| cmkeller |
| Posted: Thu Dec 07, 2006 5:52 am Post subject: |
|
|
Apprentice
Joined: 09 Jan 2005
Posts: 41
Location: Queens, NY
|
jefflowery:
| Quote: |
| Think of channels like postal trucks. As the person sending the package, you don't care which truck your package goes to, or whether it's low on gas right now or needs a new tire. All you care about is whether or not your package gets where it's going on time! |
EXACTLY - and if the truck is out of gas or has a flat, the package WON'T get there on time! That's why I had a function to check that the channel (i.e., the truck) was in a proper "running" state (i.e., is gassed up and has four good tires) to get the message to the recipient on time!
_________________
Chaim Mattis Keller
Shadow Financial Services Corp
ckeller@shadowfinancial.com |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Dec 07, 2006 5:56 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You really don't know that it won't get there on time until it's past time.
If two people call your current application almost simulataneously, and they both observe that the channel is down, and the first one starts the channel, the second one's message may have gone through just fine.
But the second one has presumably already decided not to send the message.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Dec 07, 2006 6:14 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
If you really really need to know that the channels are active in the application then maybe MQ isn't the best method for doing this? MQ is designed to be asynchronous. If you need synchronous communication it can do it, but it isn't meant to be used to monitor application components. If your application requires a quick response and can't tolerate missing replies code it that way, if it just requires to know the message has got there, code it for COA, otherwise the application shouldn't care if the infrastructure is there or not MQ will assure the delivery of the message eventually.
What happens if the channel name changes? It will be hard coded through out the application and be a nightmare to change.
One thing MQ isn't is that it isn't an answer to bad application design.
What if the channel has been stopped for a good reason or doesn't start when the start command is issued? |
|
| Back to top |
|
|
| cmkeller |
| Posted: Thu Dec 07, 2006 9:00 am Post subject: |
|
|
Apprentice
Joined: 09 Jan 2005
Posts: 41
Location: Queens, NY
|
jefflowery:
| Quote: |
| You really don't know that it won't get there on time until it's past time. |
If a significant number of unacknowledged messages pile up, it's good to know if the reason is your sending channel. That way, they don't have to wait until the deadline to determine if they'd already missed it!
| Quote: |
If two people call your current application almost simulataneously, and they both observe that the channel is down, and the first one starts the channel, the second one's message may have gone through just fine.
But the second one has presumably already decided not to send the message. |
In my situation, no one will be deciding to not send the message. If they want to send it, they still want to send it. But this gives them the knowledge to attempt to re-start the sending channel. If one re-starts it, and the other then attempts to re-start it and discovers that it has been re-started for him, that's not a problem.
kevinf2349:
| Quote: |
| If you really really need to know that the channels are active in the application then maybe MQ isn't the best method for doing this? |
It is the recipient of the messages who insists on using MQSeries for communicating with us (their customers). We do not have the option of a different vendor for these services. Nor is there any real problem here; re-starting an inactive channel is not such a big deal.
| Quote: |
| MQ is designed to be asynchronous. If you need synchronous communication it can do it, but it isn't meant to be used to monitor application components. If your application requires a quick response and can't tolerate missing replies code it that way, if it just requires to know the message has got there, code it for COA, otherwise the application shouldn't care if the infrastructure is there or not MQ will assure the delivery of the message eventually. |
It doesn't require synchronous, but the message does have to have been received by a certain time of the day. A potential allowable delay of eight hours is not synchronous. But if the message doesn't make the deadline, money can be lost. And if the reason is an inactive channel, and it can easily be re-started, it's dumb to not know that and do that.
For the record, my program already uses COAs to confirm arrival. However, knowing something hasn't yet arrived does not mean you know WHY it hasn't arrived, or whether you can do something to get it to arrive.
| Quote: |
| What happens if the channel name changes? It will be hard coded through out the application and be a nightmare to change. |
Who's hard-coding anything? The function I had written in C/C++ read the name of the transmission queue from the queue properties, then searched all sending channels for a matching transmission queue name, and found the match. That's the method I am hoping to port to C#.
| Quote: |
| What if the channel has been stopped for a good reason or doesn't start when the start command is issued? |
Then that reason needs to be addressed. But if it CAN be re-started, and the reason it went into inactive mode was simply inactivity, why the heck not let someone know it needs to be awakened?
_________________
Chaim Mattis Keller
Shadow Financial Services Corp
ckeller@shadowfinancial.com |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Dec 07, 2006 9:16 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
Then that reason needs to be addressed. But if it CAN be re-started, and the reason it went into inactive mode was simply inactivity, why the heck not let someone know it needs to be awakened?
|
Then triggering is exactly what you need.  |
|
| Back to top |
|
|
| tleichen |
| Posted: Thu Dec 07, 2006 12:32 pm Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| cmkeller wrote: |
| kevinf2349 wrote: |
| What happens if the channel name changes? It will be hard coded through out the application and be a nightmare to change. |
Who's hard-coding anything? The function I had written in C/C++ read the name of the transmission queue from the queue properties, then searched all sending channels for a matching transmission queue name, and found the match. That's the method I am hoping to port to C#. |
Someone's really got a lot of time on their hands.... While this may sound somewhat logical to the novice, it is foolhearted. It does not address reality, as there is a variable latency period, although small, between the time the channel changes status and the time that it is reflected within the queue manager. Doing things this way is really opening up a can of worms! 
| cmkeller wrote: |
| kevinf2349 wrote: |
| What if the channel has been stopped for a good reason or doesn't start when the start command is issued? |
Then that reason needs to be addressed. But if it CAN be re-started, and the reason it went into inactive mode was simply inactivity, why the heck not let someone know it needs to be awakened? |
Yes, but not by the application! 
Channel status and management are the jobs of monitoring tools, etc. They should not affect the programming of an application. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Dec 07, 2006 1:03 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
Yes, but not by the application!
|
Not to mention that you would require to give authority to the application to issue PCF commands.
(better hope the auditors don't find out about that!) |
|
| Back to top |
|
|
|
|
