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
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
Increase in WMQ Storage Utilization going to z/OS
Title: Increase in WMQ Storage Utilization going to z/OS My shop has just upgraded the mainframe Operating System from os/390 to z/OS 1.4 and we are noticing an increase in storage utilization for all queue managers and chins. Has anyone experienced this and what was done to reduce it? Thanks This e-mail message and any attachments contain confidential information from Medco. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.
Re: JAVA client and reason code 2085 (unknown object)
Janet, You might want to look at the BlockIP2 or LogIP channel exits. They can tell you where your SVRCONN channels are originating. That might help you correlate the events with the specific clients causing them. See: http://www.mrmq.dk/index.htm?BlockIP.htm -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of MQ Mailbox Sent: Wednesday, September 01, 2004 4:48 PM To: [EMAIL PROTECTED] 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 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: Increase in WMQ Storage Utilization going to z/OS
What version of MQ. -- Jay H. Lang Chief Technologist Distributed Computing Professionals Inc. IBM Certified Specialist - WebSphere MQ 651 406-2131 - USPS Office 303 277-1873 - Colorado Office 303 807-9700 - Cell Phone "Aroneanu, Corina" wrote: My shop has just upgraded the mainframe Operating System from os/390 to z/OS 1.4 and we are noticing an increase in storage utilization for all queue managers and chins. Has anyone experienced this and what was done to reduce it? Thanks This e-mail message and any attachments contain confidential information from Medco. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.
Re: Increase in WMQ Storage Utilization going to z/OS
Title: Increase in WMQ Storage Utilization going to z/OS We've been running MQ on z/OS 1.4 for about a month without problem. You don't mention what version of MQ you're running or your maintenance level. We're at v5.3 and RSU0407. -Original Message-From: Aroneanu, Corina [mailto:[EMAIL PROTECTED]Sent: Thursday, September 02, 2004 8:58 AMTo: [EMAIL PROTECTED]Subject: Increase in WMQ Storage Utilization going to z/OS My shop has just upgraded the mainframe Operating System from os/390 to z/OS 1.4 and we are noticing an increase in storage utilization for all queue managers and chins. Has anyone experienced this and what was done to reduce it? Thanks This e-mail message and any attachments contain confidential information from Medco. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. --- ***National City made the following annotations ---This communication is a confidential and proprietary business communication. It is intended solely for the use of the designated recipient(s). If this communication is received in error, please contact the sender and delete this communication. ===
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
Re: JAVA client and reason code 2085 (unknown object)
What do you use for administration tools? --- MQ Mailbox <[EMAIL PROTECTED]> wrote: > 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 > 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
Mike Philips is out of the office.
I will be out of the office starting 09/02/2004 and will not return until 09/07/2004. I will respond to your message when I return. 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
Migrating from 2.1 to 5.3.1 on mainframe OS/390 version 2.10
Title: Message I have scoured the internet for some old documentation that shows the new features available when companies migrated from MQSeries version of 2.1. Can someone point me to a document that list the "benefits" of migrating from version 2.1 to a more current version (whatever that is) until I get to version 5.3.1? My boss would like to send out an e-mail "touting" the new features that are now available. He doesn't want to send out --> to be supported by IBM we need to get to the current release of their product. For some reason, he doesn't think that would be very good PR for our department. TIA Doug
Re: Migrating from 2.1 to 5.3.1 on mainframe OS/390 version 2.10
Hi Doug, I have extracted the following from the WebSphere MQ 5.3.1 Concepts and Planning Guide. It shows the new features of 5.3 and 5.3.1 relative to 5.2. The main features for my site were SSL channel support, and substantial improvements to the reliability of MQ Cluster support, especially the addition of RESET CLUSTER and REFRESH CLUSTER enhancements. There are obviously a bunch of other features and enhancements which have been useful to various extents. I doubt if you will be able to go to any version other than 5.3.1 now. I suspect that IBM won't be shipping older versions, even if they do still support them. Migration from MQSeries V2.1 to WebSphere MQ 5.3.1 is fully supported, and backout is supported as well provided the compatability PTF is installed on the 2.1 code. What's new in WebSphere MQ for z/OS This section describes the new function that has been added in WebSphere MQ for z/OS Version 5 Release 3 and WebSphere MQ for z/OS Version 5 Release 3.1. Most of the changes described were introduced in WebSphere MQ for z/OS Version 5 Release 3; by default, that is the release to which the information applies. Where changes have been made in WebSphere MQ for z/OS Version 5 Release 3.1, we identify them explicitly. Support for WebSphere Application Server Version 5 WebSphere MQ for z/OS Version 5 Release 3.1 provides JMS support for WebSphere Application Server embedded messaging. You can use the embedded messaging either with the reduced function form of WebSphere MQ supplied with WebSphere Application Server, or with the full function WebSphere MQ for z/OS Version 5 Release 3.1 product itself. In WebSphere MQ and WebSphere Application Server, you'll find a general introduction to the reduced function form of WebSphere MQ, and an overview of the features of WebSphere MQ for z/OS that are not available to WebSphere Application Server users of that messaging. Shared queue recovery You can now use persistent messages on shared queues. Shared queue messages are recovered in a Coupling Facility (CF) list structure from periodic CF list structure backups, and from data about shared queue updates on the WebSphere MQ recovery logs of each queue manager in the queue sharing group. This function introduces a new object called a CF structure (CFSTRUCT), and the following new MQSC commands: DEFINE CFSTRUCT Creates a new CF structure. ALTER CFSTRUCT Modifies the backup attributes of a CF structure. DELETE CFSTRUCT Deletes a CF structure. DISPLAY CFSTRUCT Displays the attributes for a specific CF structure. BACKUP CFSTRUCT Starts a CF structure backup. DISPLAY CFSTATUS Displays the status of a CF structure, including the time and size of its latest backup, and usage information previously shown by the DISPLAY GROUP command. RECOVER CFSTRUCT Starts a CF structure recovery. See the WebSphere MQ Script (MQSC) Command Reference for details of these commands. Within a queue-sharing group, Version 5.2 queue managers can coexist with Version 5.3 or Version 5.3.1 queue managers, with some restrictions. Versions 5.3 and 5.3.1 queue managers can coexist without restriction. See the WebSphere MQ for z/OS System Setup Guide for more information. Dynamic parameters You can now dynamically change selected queue manager startup options while the queue manager is running. This function introduces commands like: SET SYS IDFORE(256) CTHREAD(512) IDBACK(128) to dynamically set selected parameters of the CSQ6SYSP, CSQ6LOGP and CSQ6ARVP startup parameter macros. This function introduces the following new MQSC commands: DISPLAY ARCHIVE Displays archive information, including the tape unit report previously produced by the DISPLAY LOG command. DISPLAY SYSTEM Displays system information. SET ARCHIVE Sets archive parameter values. SET SYSTEM Sets certain system parameter values. See the WebSphere MQ Script (MQSC) Command Reference for details of these commands. Secure Sockets Layer (SSL) support The Secure Sockets Layer (SSL) protocol provides out of the box channel security, with protection against eavesdropping, tampering, and impersonation. SSL is an industry-standard protocol that provides a data security layer between application protocols and the communications layer, usually TCP/IP. The SSL protocol was designed by the Netscape Development Corporation, and is widely deployed in both Internet applications and intranet applications. SSL defines methods for data encryption, server authentication, message integrity, and client authentication for a TCP/IP connection. SSL uses public key and symmetric techniques to provide the following security services: Message privacy SSL uses a combination of public-key and symmetric-key encryption to ensure message privacy. Before exchanging messages, an SSL server and an SSL client perform an electronic handshake during which they
Re: Connecting to more than one queue managers on solaris, linux
Pavel, It was always possible to have connections to various queue managers from UNIX child processes (still one connection per child process) and I did it myself. In the best of my knowledge starting with V5.2 it became possible to have the same type of connections from threads. Even I did not try it myself I am using products that are multithreaded and each thread has it is own connection. In some cases the number of threads is directly defined by the number of local queue managers. Eugene --- Pavel Tolkachev <[EMAIL PROTECTED]> wrote: > Well, for a loopback interface (I mean, when client > connects to localhost or 127.0.0.1), it should not > call real network drivers. I think it uses some > platform-specific IPCs (on solaris, probably streams > -- I believe both pipes and local sockets use same > underlying mechanisms, on very old Unices it were > mbufs) -- and should not be really heavy... > Although, the latency will increase due to the agent > and some overhead will still be there.. Even when > real IP is used, smart TCP stack must not hit the > network for local connections. > > Just thinking aloud.. I have never really tested it > with MQ but I did some performance testing with > locally bound TCP sockets -- as long as all socket > options were set right (especially TCP_NDELAY), the > overhead became negligible. Hopefully, IBM got it > right :-). > > Just my 2c > Pavel > > > > > "Miller, Dennis" > <[EMAIL PROTECTED]To: > [EMAIL PROTECTED] > OM> cc: > Sent by: MQSeries > Subject: Re: Connecting to more than one queue > managers on solaris, linux > List > <[EMAIL PROTECTED] > n.AC.AT> > > > 09/01/2004 02:39 > PM > Please respond to > MQSeries List > > > > > > > The client connection has a performance > disadvantage, mostly because of > network overhead. After all, every API request (and > any messages it > conveys) must pass over the network to get between > the MQ client and the > qmgr. The server channel agent, acting on behalf of > the client, uses > local bindings and should experience about the same > performance as the > application using local bindings. But the exchange > of API requests > between the MQ client and the server channel agent > is extra work. > > I am not in a position to quantify it, though, and I > expect it would > depend greatly on your network configuration. > > > -Original Message- > From: Gurney, Matthew > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 01, 2004 12:48 AM > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > What would the performance difference of using > MQClient connections to > connect to a local Queue manager on the same Unix > host, compared to > using a local bindings direct connection to the > local Queue manager. I > understand that for Pavel's situation, this be be > irrelevant, but I am > concerned with the general case? > > Matt. > > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of Miller, > Dennis > Sent: 01 September 2004 01:13 > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > I understand your hesitance to use MQ client for > such an app. But think > about what you are really asking. An app on one > server with MQM > credentials for other servers? An app on one server > with access to MQM > internals on another server? Hmmm... > > I'm sure you know that without MQ-Client, you cannot > even connect to a > single QMgr across servers, much less multitudes of > them. So, if your > thinking about monitoring even one qmgr by an app > running on a different > system, you are talking about some sort of client > model, by definition. > > But it needn't necessarily be the MQ client. You > could for example, > write a monitoring agent and run it locally on each > qmgr. The user > interface for your monitoring app is then a client > to these agents, > requesting services and receiving replies from them. > If you are > so-inclined, you can even conduct the request/reply > exchanges using > local connections and MQ messages (although, > depending on what you are > doing, one might question the wisdom of running a > monitoring application > in-band like that). > > It is somewhat analagous to how the command server > works, only > customized to your specific requirements. > > > > > -Original Message- > From: Pavel Tolkachev > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 31, 2004 1:31 PM > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > Thanks Dennis, > > This is a low-level monitoring application > (requiring mqm credentials, > by the way). M
Re: Connecting to more than one queue managers on solaris, linux
Dennis, It is really tricky to compare client/server performance with server/server performance. I agree that each application MQ client call would lose in performance compare with application MQ server call but I believe that the total throughput is better with the client/server communication because the number of I/O is low. The message is going directly to destination queue within client/server without be placed and retrieve on/from transmission queue. Eugene --- "Miller, Dennis" <[EMAIL PROTECTED]> wrote: > The client connection has a performance > disadvantage, mostly because of > network overhead. After all, every API request (and > any messages it > conveys) must pass over the network to get between > the MQ client and the > qmgr. The server channel agent, acting on behalf of > the client, uses > local bindings and should experience about the same > performance as the > application using local bindings. But the exchange > of API requests > between the MQ client and the server channel agent > is extra work. > > I am not in a position to quantify it, though, and I > expect it would > depend greatly on your network configuration. > > > -Original Message- > From: Gurney, Matthew > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 01, 2004 12:48 AM > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > What would the performance difference of using > MQClient connections to > connect to a local Queue manager on the same Unix > host, compared to > using a local bindings direct connection to the > local Queue manager. I > understand that for Pavel's situation, this be be > irrelevant, but I am > concerned with the general case? > > Matt. > > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of Miller, > Dennis > Sent: 01 September 2004 01:13 > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > I understand your hesitance to use MQ client for > such an app. But think > about what you are really asking. An app on one > server with MQM > credentials for other servers? An app on one server > with access to MQM > internals on another server? Hmmm... > > I'm sure you know that without MQ-Client, you cannot > even connect to a > single QMgr across servers, much less multitudes of > them. So, if your > thinking about monitoring even one qmgr by an app > running on a different > system, you are talking about some sort of client > model, by definition. > > But it needn't necessarily be the MQ client. You > could for example, > write a monitoring agent and run it locally on each > qmgr. The user > interface for your monitoring app is then a client > to these agents, > requesting services and receiving replies from them. > If you are > so-inclined, you can even conduct the request/reply > exchanges using > local connections and MQ messages (although, > depending on what you are > doing, one might question the wisdom of running a > monitoring application > in-band like that). > > It is somewhat analagous to how the command server > works, only > customized to your specific requirements. > > > > > -Original Message- > From: Pavel Tolkachev > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 31, 2004 1:31 PM > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > Thanks Dennis, > > This is a low-level monitoring application > (requiring mqm credentials, > by the way). Making it an MQ client makes running > listener or configured > a pre-requisite to operate the app even if there is > no business purpose > for them to be there and creates a whole number of > security issues with > the too-far-going implications of their possible > solutions. I will have > to either live with these consequences or go for > running several > instances of the app instead (which is not ideal for > my cause, > either..). > > Pavel > > > > > > "Miller, Dennis" > <[EMAIL PROTECTED]To: > [EMAIL PROTECTED] > OM> cc: > Sent by: MQSeries > Subject: Re: Connecting > to more than one queue managers on solaris, linux > List > <[EMAIL PROTECTED] > n.AC.AT> > > > 08/31/2004 04:05 > PM > Please respond to > MQSeries List > > > > > > > Yes, you can do it in the server app. Just use the > MQ client. A server > app from the perspective of the application > architecture can be a client > from the perspective of MQ. > > -Original Message- > From: Pavel Tolkachev > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 31, 2004 10:30 AM > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > Thanks David, > > Is
