Re: Clustering Question
Tony, We have an application running with the same component versions. You must remember that in a cluster containing multiple copies of the same Queue name the cluster will load balance. We have also noted that with the JMS client connection if the QMGR name is used in the JMS configuration we get the dreaded 2085 error code MQRC_UNKNOWN_OBJECT_NAME. What we have done is to append the Queue name with the, in our case, division number. (example: TEST.QUEUE.012). That way you have a unique queue. This may seem simplistic but it does work. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony.Allison Sent: Monday, November 29, 2004 9:53 AM To: [EMAIL PROTECTED] Subject: Clustering Question Good morning everyone... I think I am having a brain meltdown Here is what we are trying to accomplish. Components: 1. WAS 5.1 2. Websphere MQ 5.3.0.8 1370 queue managers in single cluster. WAS application running with client connection to central queue manager needs to send a single message to one queue manager in the cluster. (There are 1364 instances of for example (TEST.QUEUE) One on each of the queue managers in the cluster. The queue managers are broken down into two categories (HQ and Stores) all stores queue managers are distributed across the country and each have a unique name. My question is, How can my local HQ application running on WAS put a message to a specific queue manager within the cluster? I know each MQ object has a unique name (Object Name / Object QMGR Name) Where in the JMS code can we put the specific name? Thanks for any input you can provide. Thanks Tony Allison Technical Architect Target Technology Services Enterprise Tools / Middleware 33 South 6th Street 11th Floor / Cube 11240 Minneapolis, MN Direct (612) 304-3740 Cell Phone (612) 306-0487 E-Mail: [EMAIL PROTECTED]
Re: Clustering Question
Sorry, I made a poor assumption, I should know better. We may do it differently than Tony has in mind. Our online app is on the WAS server and we always connect to the same QMGR with JMS. Then based on customer number, or some other factor that determines where an order is filled we send the Queue messages to the correct queue. It is at that point we require a unique queue name as any reference to the receiving queue manager name in the message header will, no can but will, cause the 2085 error message. I dont understand your reference to round robining as the original question asked about sending a message to a unique queue. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (ISD, IT) Sent: Monday, November 29, 2004 10:24 AM To: [EMAIL PROTECTED] Subject: Re: Clustering Question You should use the QMGR name attribute of the queue object, and populate it with the name of a QM in the cluster that does host the queue. If you choose a QM that does not have the queue, you will get the 2085. If you populate it with the local QM name, you lose round robining if the local QM hosts that queue, or 2085 if it does not. You don't need to make different q names on all your clustered QMs. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Bender, Alan Sent: Monday, November 29, 2004 11:17 AM To: [EMAIL PROTECTED] Subject: Re: Clustering Question Tony, We have an application running with the same component versions. You must remember that in a cluster containing multiple copies of the same Queue name the cluster will load balance. We have also noted that with the JMS client connection if the QMGR name is used in the JMS configuration we get the dreaded 2085 error code MQRC_UNKNOWN_OBJECT_NAME. What we have done is to append the Queue name with the, in our case, division number. (example: TEST.QUEUE.012). That way you have a unique queue. This may seem simplistic but it does work. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony.Allison Sent: Monday, November 29, 2004 9:53 AM To: [EMAIL PROTECTED] Subject: Clustering Question Good morning everyone... I think I am having a brain meltdown Here is what we are trying to accomplish. Components: 1. WAS 5.1 2. Websphere MQ 5.3.0.8 1370 queue managers in single cluster. WAS application running with client connection to central queue manager needs to send a single message to one queue manager in the cluster. (There are 1364 instances of for example (TEST.QUEUE) One on each of the queue managers in the cluster. The queue managers are broken down into two categories (HQ and Stores) all stores queue managers are distributed across the country and each have a unique name. My question is, How can my local HQ application running on WAS put a message to a specific queue manager within the cluster? I know each MQ object has a unique name (Object Name / Object QMGR Name) Where in the JMS code can we put the specific name? Thanks for any input you can provide. Thanks Tony Allison Technical Architect Target Technology Services Enterprise Tools / Middleware 33 South 6th Street 11th Floor / Cube 11240 Minneapolis, MN Direct (612) 304-3740 Cell Phone (612) 306-0487 E-Mail: [EMAIL PROTECTED] This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: CSD08 on Windows 2000 Server
Thanks, everyone for your suggestions and questions. We looked back at the
system event log and found the following :
Access denied attempting to launch a DCOM Server. The server is:
{E367E1A1-E917-11D0-AF5F-00A02448799A}
A search on the IBM knowledge base using the last 12 digits of the reference
number turned up the document referenced below.
http://www-1.ibm.com/support/docview.wss?uid=swg21110613
Thanks again for your help.
Alan
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Chan, Ian M
Sent: Tuesday, November 23, 2004 5:59 PM
To: [EMAIL PROTECTED]
Subject: Re: CSD08 on Windows 2000 Server
I have CSD08 installed on a testing Win XP box last week and I don't have that
problem.
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M
(ISD, IT)
Sent: Wednesday, 24 November 2004 9:43 AM
To: [EMAIL PROTECTED]
Subject: Re: CSD08 on Windows 2000 Server
After applying CSD08, but before rebooting, did you verify the MQ service was
still set to Automatic? Did you also verify that the QM was set to Automatic in
MQ Services?
If yes to both and the QM still fails to start, what does the system MQ error
log say? Are there any FDCs?
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Bender, Alan
Sent: Tuesday, November 23, 2004 2:40 PM
To: [EMAIL PROTECTED]
Subject: CSD08 on Windows 2000 Server
Recently we installed CSD08 for Websphere MQ 5.3 on our development server.
Since then when we reboot the Queue Manager does not start. The service pack
was removed and with CSD07 everything worked as expected with the QMGR starting
automatically after reboot. We then reapplied Service pack 8 and the QMGR no
longer starts after reboot. Has anyone seen this happen? Maybe we are missing
some settings or something.
Help,
Alan
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all
copies.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
CSD08 on Windows 2000 Server
Recently we installed CSD08 for Websphere MQ 5.3 on our development server. Since then when we reboot the Queue Manager does not start. The service pack was removed and with CSD07 everything worked as expected with the QMGR starting automatically after reboot. We then reapplied Service pack 8 and the QMGR no longer starts after reboot. Has anyone seen this happen? Maybe we are missing some settings or something. Help, Alan
Re: BATCH messages advice requested
Not to get into the nuts and bolts of triggering on depth that has been suggested by several already, it is not immediately obvious that your programmers MUST reset the trigger on depth before terminating each time or the trigger will turn OFF and never start your app again. This is something small but it has driven many good programmers to distraction. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Dye, Janet E Sent: Thursday, November 18, 2004 11:28 AM To: [EMAIL PROTECTED] Subject: BATCH messages advice requested Currently, most messages received on our mainframe qmgr are destined to CICS and are triggered 'on first' . We are in the process of putting in a new application that will receive large volumes (50,000+) of batch messages from a vendor. The messages will come in at different times of the day, sometimes being just a few messages at a time and other times being the large volume I just mentioned. The developer wants to schedule a job that runs different times throughout the day to process these messages. My concern is that since volume is unpredictable and as more applications do this, it will become impossible to plan disk space to hold the number of messages that could potentially be in the queues any point in time. My feeling is that I need to create a policy that messages are removed from a queue upon arrival or at least upon arrival of a certain volume. I have suggested to the developer that we will need to set up a trigger to trigger 'on first' or on 'depth', and they code the program to do a MQGET with a wait of a minute or so. I am getting a little resistance to this in that they are concerned about the job being triggered a lot, and they would prefer to just schedule it to run every hour or so. I am interested to know what policy, if any, other shops have for this situation. Thanks Janet Dye Infrastructure Systems Engineer - Middleware UMB Bank, n.a. 1008 Oak Street - Mailstop 1170305 Kansas City, MO. 64106 office: 816-860-1109 cell : 816-686-1544 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Non-responsive qgmr
We had a Listener stop once. That stops you dead in the water. Just a thought. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Boggis Sent: Wednesday, October 20, 2004 3:16 PM To: [EMAIL PROTECTED] Subject: Non-responsive qgmr Env: Solaris 5.8, WMQ 5.3 CSD05. I have a very odd situation which I am at a loss right now to either explain or fix (unless I resort to the brute force approach of kill all the mqgr processes)... I have two active queue managers running, each belonging to a different cluster, each listening on a different port (1416 1414). Up until earlier they were running (and responding) fine. Now, nothing. Even dspmq hangs. This may be related to the current HBINT on the CLUSSDR/CLUSRCVR channels (10), but I thought I'd see if the list members have seen this occurence at all. tonyB. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Starting a 5.3 Queue manager
You will need to set the channel initiator to start manual. If you are able to use MQ Services interface just right click on the channel initiator and under Tasks uncheck automatic. I have one question for you. Why would you want to do that? Without the channels all you have is a local message accumulator. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence Coombs Sent: Friday, October 15, 2004 7:37 AM To: [EMAIL PROTECTED] Subject: Re: Starting a 5.3 Queue manager Is there a way to start a 5.3 queue manager without starting the channel initiator automatically? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Disappearing cluster queues
Excuse me but if you are defining sender channels for each QM then you no longer have a true cluster but rather a distributed system and you are back to all of the admin headaches of a distributed system. I have no solution to offer but I'm sure someone at IBM has seen this and does either have a fix or a work around that doesn't include going back to a distributed system. We have had this problem with our iSeries / Windows cluster. Every time the iSeries is IPL'd we have to issue the refresh command or we begin to get the dreaded 2085 return code. Maybe it is as simple as including the refresh in a command string at startup. I don't know, just a thought. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Gray Sent: Monday, September 20, 2004 8:53 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues We were losing the defs on the partial repository qms. The solution for us was to define a static clussdr from a full repos to each partial repos. We had defined the cluster relying on dynamic clussdr channels from the full repos qms to the partial repos qms. That is, we had defined static clussdrs from partial to full, but allowed MQ to auto define the clussdr from full to partial based. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Boggis Sent: Monday, September 20, 2004 9:40 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues I'm not sure I follow... Are you saying that on each FULL-REPOS, have an additional CLUSSDR channel? So that would mean that each full repository holder having one CLUSSDR channel to another full repos and a second CLUSSDR to a partial repos (cluster member) queue manager? tonyB. Original Message Subject: Re: Disappearing cluster queues From: Scott Gray [EMAIL PROTECTED] Date: Mon, September 20, 2004 6:28 pm To: [EMAIL PROTECTED] We had that problem between sun/hp and z/os...we were told to have at least one static cluster sender between full repository and leaf node. We were relying on dynamic clussdrs from full repos to leaf node. Once we did this, that problem has not reoccured. No explanation for the behavior was provided by IBM. Good luck. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Boggis Sent: Monday, September 20, 2004 9:18 PM To: [EMAIL PROTECTED] Subject: Disappearing cluster queues Puzzling situation... Environment: Solaris, WMQ 5.3 CSD05. I have a cluster with about 24 queue managers each on it's own host. All are sharing one or more queues in the cluster, eaching being unique, giving 200+ queues. Periodically cluster queues disappear on some hosts, leaving me getting 2085 errors, even from amqsput. Manually refreshing the cluster (REFRESH CLUSTER) usually does the trick. Usually. All my CLUSSDR/CLUSRCVR channels are configured and none are Binding/Retrying, etc. I have 4 full-respository managers defined, all are up and running. This is not 60+ days or anything that would obviously point to cluster expiration. tonyB. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Disappearing cluster queues
The interpretation of that one paragraph is disputed by the QUEUE MANAGER CLUSTERS manual in chapter 3 where the setup of a cluster is explained in detail. After defining a Receiver channel you define the Sender channel to one of the full repository queue managers. The idea of defining sender channels for all repositories full and partial is never discussed as you would no longer have a cluster but a distributed system. Also in that manual in the troubleshooting section the solution given for the several cluster problems is the Refresh Cluster command. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Gray Sent: Tuesday, September 21, 2004 9:24 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Refer to T Robs note that quotes the manuals as saying this is a requirement. I wouldn't think it would have to work this way, but that is what the manual says and is backed up by our experience. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bender, Alan Sent: Tuesday, September 21, 2004 9:09 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Excuse me but if you are defining sender channels for each QM then you no longer have a true cluster but rather a distributed system and you are back to all of the admin headaches of a distributed system. I have no solution to offer but I'm sure someone at IBM has seen this and does either have a fix or a work around that doesn't include going back to a distributed system. We have had this problem with our iSeries / Windows cluster. Every time the iSeries is IPL'd we have to issue the refresh command or we begin to get the dreaded 2085 return code. Maybe it is as simple as including the refresh in a command string at startup. I don't know, just a thought. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Gray Sent: Monday, September 20, 2004 8:53 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues We were losing the defs on the partial repository qms. The solution for us was to define a static clussdr from a full repos to each partial repos. We had defined the cluster relying on dynamic clussdr channels from the full repos qms to the partial repos qms. That is, we had defined static clussdrs from partial to full, but allowed MQ to auto define the clussdr from full to partial based. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Boggis Sent: Monday, September 20, 2004 9:40 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues I'm not sure I follow... Are you saying that on each FULL-REPOS, have an additional CLUSSDR channel? So that would mean that each full repository holder having one CLUSSDR channel to another full repos and a second CLUSSDR to a partial repos (cluster member) queue manager? tonyB. Original Message Subject: Re: Disappearing cluster queues From: Scott Gray [EMAIL PROTECTED] Date: Mon, September 20, 2004 6:28 pm To: [EMAIL PROTECTED] We had that problem between sun/hp and z/os...we were told to have at least one static cluster sender between full repository and leaf node. We were relying on dynamic clussdrs from full repos to leaf node. Once we did this, that problem has not reoccured. No explanation for the behavior was provided by IBM. Good luck. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Boggis Sent: Monday, September 20, 2004 9:18 PM To: [EMAIL PROTECTED] Subject: Disappearing cluster queues Puzzling situation... Environment: Solaris, WMQ 5.3 CSD05. I have a cluster with about 24 queue managers each on it's own host. All are sharing one or more queues in the cluster, eaching being unique, giving 200+ queues. Periodically cluster queues disappear on some hosts, leaving me getting 2085 errors, even from amqsput. Manually refreshing the cluster (REFRESH CLUSTER) usually does the trick. Usually. All my CLUSSDR/CLUSRCVR channels are configured and none are Binding/Retrying, etc. I have 4 full-respository managers defined, all are up and running. This is not 60+ days or anything that would obviously point to cluster expiration. tonyB. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription
Re: MMC/Any GUI for administering MQ on AIX
I ran across MQJexplorer a few weeks back. It is pure java and works with most all platforms. You should check it out. http://www.kolban.com/mqjexplorer/ -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Mike Davidson Sent: Thursday, September 09, 2004 7:54 AM To: [EMAIL PROTECTED] Subject: Re: MMC/Any GUI for administering MQ on AIX MO71 is a great tool for administering MQ. Here's the URL: http://www-1.ibm.com/support/docview.wss?rs=203uid=swg24000142loc=en_UScs=utf-8lang=en Mike Davidson TSYS MQ Tech Support IBM Certified System Administrator - WebSphere MQ V5.3 IBM Certified Solution Designer - WebSphere MQ V5.3 [EMAIL PROTECTED] Jitender Bhatia [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 09/09/2004 08:27 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:MMC/Any GUI for administering MQ on AIX Hello, I am relatively new to MQ. I have MQ Series setup on AIX box. Now, i want a way to administer it from my windows box by using some kind of GUI. I have MMC on my windows box that i am able to use to administer MQ Series on my local desktop. Can i use it to connect to MQ Series on AIX box to administer it. How ? I am not able to figure this out. Any other ideas on what kind of UI i can use for this purpose ? A Java UI running on AIX is ok too. Thanks Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: Large message size support on MQSeries
Yes, a single message segment can be 100mb. Using segmentation only your receiving program would be the limiting factor in message size. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Yan Sent: Friday, September 03, 2004 9:31 AM To: [EMAIL PROTECTED] Subject: Large message size support on MQSeries Hi All, From what I read, that MQ supports upto 100mb for single message. It seems there is option for segmentation, Does that mean it supports over 100mb if using the segmatation option? Thank you very much!! Yan The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Large message size support on MQSeries
Yan, With MQ you get all of the message or none of the message so streaming data is not an option. As others have pointed out the documentation on this is very good. And there seem to be some very good people who have lots more experience with MQ than I do, I'd listen to them first. Personally I find many smaller messages process faster and better than one very LARGE message. But that's just me. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Yan Sent: Friday, September 03, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Large message size support on MQSeries Alan , thanks ! Does MQ support straming on solaris? If it does, sending program could steaming in to the queue and The receiving program could steaming out to disk. That way the limit is the disk. Am I right? Yan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bender, Alan Sent: Friday, September 03, 2004 10:41 AM To: [EMAIL PROTECTED] Subject: Re: Large message size support on MQSeries Yes, a single message segment can be 100mb. Using segmentation only your receiving program would be the limiting factor in message size. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Yan Sent: Friday, September 03, 2004 9:31 AM To: [EMAIL PROTECTED] Subject: Large message size support on MQSeries Hi All, From what I read, that MQ supports upto 100mb for single message. It seems there is option for segmentation, Does that mean it supports over 100mb if using the segmatation option? Thank you very much!! Yan The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JAVA client and reason code 2085 (unknown object)
Look in the Cluster Queue Reference manual on page 111. We had the same message yesterday and doing a refresh on the full repository cleared it up. Of course I am making the assumption that you are running with clusters. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Anand_Sanjeevi Sent: Thursday, September 02, 2004 3:47 AM To: [EMAIL PROTECTED] Subject: Re: JAVA client and reason code 2085 (unknown object) Hi, Are you sure your Qmgr Reference handle is calling right queues? Check the Client program Exceptions handling Cases... If possible post your client program. Regards AS -Original Message- From: MQSeries List To: [EMAIL PROTECTED] Sent: 02/09/2004 02:18 Subject: JAVA client and reason code 2085 (unknown object) We have several JAVA client applications running in our production environment. Every once in awhile I receive a MQ event for 2085, unknown object, with the object name as blank and the application as 'MQSeries Client for Java'. Other events that I have seen for a client app would have a name of an executable instead of 'MQSeries Client for Java'. Nowhere on the event record is there a username or something else that would help me to determine where that client is coming from. Looking in the AMQERR01.LOG files in /var/mqm/errors, /var/mqm/qmgr/@SYSTEM/errors and /var/mqm/qmgr/QMNAME, I don't see anything. As far as the connected SVRCONN channels, I don't see any that look suspicious. I don't know if an production application is having an occasional problem, or if someone is playing in production. Anyone have any ideas on how to determine the origin of this client. Thanks Janet Dye Infrastructure Systems Engineer - Middleware UMB Bank, n.a. 1008 Oak Street - Mailstop 1170305 Kansas City, MO. 64106 office: 816-860-1109 cell : 816-686-1544 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ** Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JAVA client and reason code 2085 (unknown object)
2085 X'0825' MQRC_UNKNOWN_OBJECT_NAME An MQOPEN or MQPUT1 call was issued, but the object identified by the ObjectName and ObjectQMgrName fields in the object descriptor MQOD cannot be found. One of the following applies: The ObjectQMgrName field is one of the following: - Blank - The name of the local queue manager - The name of a local definition of a remote queue (a queue-manager alias) in which the RemoteQMgrName attribute is the name of the local queue manager but no object with the specified ObjectName and ObjectType exists on the local queue manager. The object being opened is a cluster queue that is hosted on a remote queue manager, but the local queue manager does not have a defined route to the emote queue manager. The object being opened is a queue definition that has QSGDISP(GROUP). Such definitions cannot be used with the MQOPEN and MQPUT1 calls. Corrective action: Specify a valid object name. Ensure that the name is padded to the right with blanks if necessary. If this is correct, check the queue definitions. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Anand_Sanjeevi Sent: Thursday, September 02, 2004 3:47 AM To: [EMAIL PROTECTED] Subject: Re: JAVA client and reason code 2085 (unknown object) Hi, Are you sure your Qmgr Reference handle is calling right queues? Check the Client program Exceptions handling Cases... If possible post your client program. Regards AS -Original Message- From: MQSeries List To: [EMAIL PROTECTED] Sent: 02/09/2004 02:18 Subject: JAVA client and reason code 2085 (unknown object) We have several JAVA client applications running in our production environment. Every once in awhile I receive a MQ event for 2085, unknown object, with the object name as blank and the application as 'MQSeries Client for Java'. Other events that I have seen for a client app would have a name of an executable instead of 'MQSeries Client for Java'. Nowhere on the event record is there a username or something else that would help me to determine where that client is coming from. Looking in the AMQERR01.LOG files in /var/mqm/errors, /var/mqm/qmgr/@SYSTEM/errors and /var/mqm/qmgr/QMNAME, I don't see anything. As far as the connected SVRCONN channels, I don't see any that look suspicious. I don't know if an production application is having an occasional problem, or if someone is playing in production. Anyone have any ideas on how to determine the origin of this client. Thanks Janet Dye Infrastructure Systems Engineer - Middleware UMB Bank, n.a. 1008 Oak Street - Mailstop 1170305 Kansas City, MO. 64106 office: 816-860-1109 cell : 816-686-1544 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ** Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Windows 2003 Server
Does anyone know if there are any issues with MQ 5.3 CSD07 running on Windows 2003 servers. We are about to install MQ on a new server running Win 2003. Thanks, Alan Bender Applications Developer AmerisourceBergen Corp. Phone - (334) 215-2858 mailto:[EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Listener problem
We have Websphere MQ 5.3 installed on our servers and have had a small problem come up on two different servers at different times. The listener for one of the Queue Managers lost its Protocol and Port configuration. Has anyone seen this before or could it just be one of those rare things that come up once in a while? Thanks, Alan Bender mailto:[EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
