| Author |
Message
|
| zlj |
 Posted: Wed Nov 26, 2008 5:32 pm Post subject: Assert qm exsit? |
 |
|
Apprentice
Joined: 13 Nov 2008
Posts: 32
|
| How can I decide a queue manager is exist or not with script? |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Nov 26, 2008 5:37 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Code: |
#My awesome script
dspmq
exit
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zlj |
| Posted: Wed Nov 26, 2008 5:49 pm Post subject: |
|
|
Apprentice
Joined: 13 Nov 2008
Posts: 32
|
If i want inquire a queue manager exsit or not in my application, what should i do?
I need a method in my class, which return true or false means queue manager exsit or not. I have no scenario.
Help me further please. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 26, 2008 9:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
As Peter showed you, on the local machine the output of dspmq will show which qmgrs are known to the machine.
As for a qmgr on a different machine, the only way would be to try connect and evaluate the completion and error codes...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zlj |
| Posted: Thu Nov 27, 2008 8:51 pm Post subject: |
|
|
Apprentice
Joined: 13 Nov 2008
Posts: 32
|
| fjb_saper wrote: |
As Peter showed you, on the local machine the output of dspmq will show which qmgrs are known to the machine.
As for a qmgr on a different machine, the only way would be to try connect and evaluate the completion and error codes...
Have fun |
Thank you!
I'd like Mirosoft MQ Method.
| Code: |
if (MessageQueue.Exists(strQueuePath))
{
//...
}
|
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 27, 2008 9:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zlj wrote: |
I'd like Mirosoft MQ Method.
| Code: |
if (MessageQueue.Exists(strQueuePath))
{
//...
}
|
|
Than you should buy MSMQ and not WebSphere MQ.
You do understand that these are different animals and don't have the same interfaces or even follow the same concepts?
In theory you would not need to communicate with more than one qmgr from your application as the qmgr will move messages to other qmgrs in the MQ network and receive messages from other qmgrs in the MQ network.
I believe this works differently in MSMQ...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 28, 2008 12:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zlj wrote: |
| If i want inquire a queue manager exsit or not in my application, what should i do? |
Ask yourself why your application needs to know this. Applications should be blind to the infrastructure they run on. If your application is checking for the existance of a specific queue manager, how will you move it to a different environment (like from dev to prod).
All your application should care about is if it's connected to some queue manager someplace and is getting service.
| zlj wrote: |
| I need a method in my class, which return true or false means queue manager exsit or not. I have no scenario. |
It sounds like you're trying to produce a solution for a non-existant problem.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 28, 2008 12:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zlj wrote: |
| I'd like Mirosoft MQ Method. |
Well I suppose someone had to like Microsoft.... 
| zlj wrote: |
| Code: |
if (MessageQueue.Exists(strQueuePath))
{
//...
}
|
|
This snippet isn't checking for the existance of a queue manager but the existance of an object. You can obtain the same effect in a WMQ application by ensuring that the connection & open calls complete successfully, neither of which require your application to have a detailed knowledge of the underlying infrastructure.
This is also a bit self evident, in that a well behaved application would always check the success of any external call.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zlj |
| Posted: Sun Nov 30, 2008 5:00 pm Post subject: |
|
|
Apprentice
Joined: 13 Nov 2008
Posts: 32
|
Thank you all explanation.
Unfortunatly we need to use both MSMQ and IBM WebSphere MQ. We need a abstract factory in my application, and we want users to manager queue theirself, do whatever MQ explorer can do.
First of all, inquire a queue mananger, if not exist create it.
We use this following code to do this:
| Code: |
Using System.Messaging;
Class MQHelper
{
public static void CreateQM(string strQueueName)
{
if(!MessageQueue.Exsit(strQueueName)
{
MessageQueue.Create(strQueueName)
}
}
} |
[/code] |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Nov 30, 2008 7:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zlj wrote: |
Thank you all explanation.
Unfortunatly we need to use both MSMQ and IBM WebSphere MQ. We need a abstract factory in my application, and we want users to manager queue theirself, do whatever MQ explorer can do.
First of all, inquire a queue mananger, if not exist create it.
We use this following code to do this:
| Code: |
Using System.Messaging;
Class MQHelper
{
public static void CreateQM(string strQueueName)
{
if(!MessageQueue.Exsit(strQueueName)
{
MessageQueue.Create(strQueueName)
}
}
} |
|
Looks like you have a very grave misunderstanding here.
MessageQueue or in MQ terms MQQueue has nothing to do with the QMGR but the fact that it lives under it.
If you want a comparison factor:
- MessageQueue => presupposes the existence on the box of the MSMQ software. Once the software is installed on the box you can create queues.
- MQQueue=> Presupposes the existence on the box of the WebSphere MQ Series Server software and at least 1 qmgr.
MQQueues are dependent on the queue manager they live under, however they can be addressed from any qmgr in the MQ network.
Other difference point: you can only MQGET from a queue that defined as local (Queue Local) on the qmgr you are connected to. But you can / may create a client connection to any qmgr you can get to with your MQ communications protocol.
- So creating a queue manager when in fact what you need is a queue will lead you to multiple problems.
Remember a queue manager can handle thousands of queues.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zlj |
| Posted: Sun Nov 30, 2008 9:30 pm Post subject: |
|
|
Apprentice
Joined: 13 Nov 2008
Posts: 32
|
| fjb_saper wrote: |
Looks like you have a very grave misunderstanding here.
MessageQueue or in MQ terms MQQueue has nothing to do with the QMGR but the fact that it lives under it.
|
| Quote: |
If you want a comparison factor:
- MessageQueue => presupposes the existence on the box of the MSMQ software. Once the software is installed on the box you can create queues.
|
Client maybe change/delete queues, maybe need another one. We need a configuration application beside the install application.
EG:
We have one server, two clients. Some reason, client changed its IP address. Once server knew that, server must change its sender channel(IBM MQ), and admin can do it. The fact is we have more than 1000 client in differet area. Do we need 1000 admin? No, we need a config application, this application do as MQ Explorer do. Usually your client is not a MQ admin, he/she do not know what is channel. What they know is the aim they want to send message. All of this beginning I need a API to manage a queue, and then build my application, at last give my user a friendly interface without QM,Queue or Channel which they do not understand!
The importance is my queue is not steady, it may always be changed due to lots of things. User should handle it theirselft.
Do I miss something?
| Quote: |
MQQueue=> Presupposes the existence on the box of the WebSphere MQ Series Server software and at least 1 qmgr.
MQQueues are dependent on the queue manager they live under, however they can be addressed from any qmgr in the MQ network.
Other difference point: you can only MQGET from a queue that defined as local (Queue Local) on the qmgr you are connected to. But you can / may create a client connection to any qmgr you can get to with your MQ communications protocol.
|
I aggree with you.
| Quote: |
So creating a queue manager when in fact what you need is a queue will lead you to multiple problems.
Remember a queue manager can handle thousands of queues.
|
I aggree with you. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Dec 01, 2008 1:22 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zlj wrote: |
| ...Usually your client is not a MQ admin, he/she do not know what is channel. What they know is the aim they want to send message... |
| zlj wrote: |
| ...The importance is my queue is not steady, it may always be changed due to lots of things. User should handle it theirselft... |
These two statements are contradictory! Users should be abstracted from the underlying transport. From what you have described, you do not have a managed system, you have anarchy.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 01, 2008 1:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| From what you have described, you do not have a managed system, you have anarchy. |
You may find interesting background here:
http://www.mqseries.net/phpBB2/viewtopic.php?p=231055
It's not anarchy, but a very loosely managed system. I notice in this thread the drive seems to have moved from clients creating queues as they need them, to creating whole queue managers as they need them and with no reference to the "database" mentioned in the previous thread.
I do agree with you that a level of abstraction is desireable between application and infrastructure. Clearly the sheer number of external clients (I continue to take "clients" in the business sense in these threads) has put them off a fully managed implementation.
I'd be interested to know how the migration from dev->test->prod is managed in this scenario. Also how control is maintained if end users have (effectively) single click access to new queue managers & queues but no administrative knowledge.
zlj - any chance of a little background information? Particually on why you plumped for this design? I'm personally interested in this because, faced with 1000 end-user configs, my first thought would be to grab control and lock the whole thing solid! I'm therefore keen to see the other viewpoint. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zlj |
| Posted: Tue Dec 02, 2008 5:17 pm Post subject: |
|
|
Apprentice
Joined: 13 Nov 2008
Posts: 32
|
| Quote: |
zlj - any chance of a little background information? Particually on why you plumped for this design? I'm personally interested in this because, faced with 1000 end-user configs, my first thought would be to grab control and lock the whole thing solid! I'm therefore keen to see the other viewpoint. |
We have two abstract user(clients and server). One server faces lots of clients which maybe 1000 or more. The aim my application will do is synchronous infomation between server and clients. We do not exactly know how many clients we have or we do not care about this, that means we need a same way dealing with various client.
My illustrator:
An install apllication which two abstract users got. In this segment, user choose his user type(clients or server) MQ service(IBM/MS). At the end of setup I deploy app.config and MQ according to they have chosen. Set "server installation and IBM MQ" as an example:
1.Add a node into app.config means this is a server application.
| Code: |
<appSettings>
<add key="LocalSystem" value="Server" />
...
|
2.Init MQ(assume the IBM series service exist), create a QM with default name like "ServerQM". Create a local queue and a receive channel.
The second segment is config. this segment include many things such as country info etc. What we concern is MQ config.
As I told you, user server want to send message to clients for synchronous. Server user do know the client's IP address and name, add client info to application, I will create remote queue, XMITQ,sender channel, trigger on XMITQ internally. And then server can send message to any client they want. That is I said before "User only know the aim he want yo send message, they do not know the progress".
Although, I have leave out a lot of details on how to create a set of MQ series and ensure they are going well.
---end
Clients have the same flow.
Look back
User got application to setup, config it, I do detail automatic.
If user change config of mq, he only needs to know change the aim(IP and Name)
If 1000 clients need a new MQ, they can do it themself, No MQ amdin at all.
I'am so sorry about my english, for I am a foreigner do not speak english often, I had study hard with it, but I can not exactly express what I want to say now.
Regards!  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 02, 2008 9:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
This looks very much like a cluster setup to me. Otherwise you'll soon be dying under the load of just simple channel definitions.
However understand that unlike MSMQ in WMQ you can only GET a message that's in a QLOCAL to the qmgr you are connected to.
So this means when your customers/clients decide to connect to their own qmgr you need a pub/sub kind of mechanism for them to advertise their new "address" (qmgr name).
Creating a qmgr without any involvement of the mqadmin is inherently dangerous. If you need to change the Log type or logfilesize you need to delete and recreate the qmgr. There is no thought here about planning for sizing, type of workload, backup strategies and so forth...
Trust me with the kind of environment you have, you don't want to do without MQAdmin. If you do, you'll have to pay up even more later...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
