Extended Transactional Client WLS
Hello, Has anyone gotten these two working together? I am interested in sending a message from some session or other EJB to MQ queue, under the XA transaction, managed by Weblogic (8.1 SP2). I did not start trying yet; before going into it, I am trying to get encouraged by hearing that this is doable. Preferably, I would use pure Java MQ (i.e. non-JMS) but if it is not an option, JMS would do, too. Thank you, Pavel -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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
Removing a dead server from an MQ cluster
Howdy all,
I have a server (MQ2) that has been disconnected (forceably) from a cluster
and physically removed and will not be replaced. The existing queue manager
(MQ1) on the other server still thinks it is present. Can I issue a reset
cluster command on MQ1 as shown below safely:
Reset cluster('MQCLUSTER') QMNAME('MQ2') ACTION(FORCEREMOVE) QUEUES(YES)
Thanks
Sid
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: Message Tracking
Reconda: QN-StatWatch does it all. 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
MQ clustering experience
Hello Everyone, I am working at a shop that is revamping it's use of MQ. To date, my personal experience supporting MQ has not included using clustering. A proposal is under consideration to deploy hundreds of MQ servers as one cluster. This would include a handful of enterprise side QMGRs (including a few on z/OS) with the majority of QMGRs being widely dispersed. There is currently no need for the dispersed QMGRs to connect to each other so channels would exist between the enterprise QMGRs and the individual, dispersed QMGRs. Each dispersed QMGR would essentially be a clone of one another ... meaning something in the MQ object names on each QMGR would be unique but the number, type and attributes of the MQ objects from one QMGR to another would be uniform. There is also no use of client connections currently under consideration. The topology of the QMGRs will leave little, or no, opportunity to employ workload distribution. The enterprise side QMGRs will regularly be used to deliver messages to all of the dispersed QMGRs. While I crack the manuals and review the list's archives to learn more specifics about clustering benefits and pitfalls, I would appreciate hearing from others with experience using clustering, especially larger clusters. If the proposal is adopted, with what am I likely to be confronted? Will the single cluster transmit queue on each enterprise QMGR adequately service messages intended for many / all of the dispersed QMGRs in this cluster configuration? Without the benefits of workload distribution, I am concerned whether clustering in this situation is prudent. Thanks for your thought, Bill 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: Message Tracking
Hi, Good point. These are special test cases that I will need to look into because I have no idea how/when the API Exit is invoked in these particular cases. Regards, Roger At 12:47 AM 4/29/2004, you wrote: Roger Looks like a wild goose chase to me. Might as well dump the entire message - given that it is in development, performance shouldn't matter much and nor the volumes. That way you can correlate the logical unit of work across multiple calls. Just a curious question about capturing at API-exit. What happens if a task issues a PUT but takes a implicit rollback (not explicit application initiated rollback) because the transaction/program abends... Does the API exit will be invoked at that time ??? Similarly if some one CLEARS the messages, again does this API exit will be of any help. It is also possible for one developer putting it another developer reading it or clearing using MQ options. Sure you will have fun in trying to reconcile all these. If I were you, I would have taken a cricket/baseball bat approach to sort out these problems. Cheers Rao -Original Message- From: Arvind Chaudhary [mailto:[EMAIL PROTECTED] Sent: 29 April 2004 4:14 PM To: [EMAIL PROTECTED] Subject: Re: Message Tracking Roger, you can add two more fields, userid and the application name. That way you will know from where the message came from and where it went. Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: (bcc: arvind.chaudhary/Polaris) Sent by: MQSeriesSubject: Message Tracking List [EMAIL PROTECTED] C.AT 04/29/04 09:18 AM Please respond to MQSeries List All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. 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: Message Tracking
The API Exit is invoked at MQCMIT and MQBACK time, but you'll have royal fun keeping track of what was committed and backed out it you are logging messages to see what happened. Dave 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
Unknown Entry in .odbc.ini file
Hello everyone, I'm looking at an already existing set up of WMQI (on an AIX box) and have come across an entry in the odbc.ini file corresponding to an Oracle Database. --- QEWSD=37828 Driver=/usr/opt/wmqi/merant/lib/UKor816.so Description=Oracle8 -- Does anyone know what QEWSD stands for? I have not seen this before and I checked the original .odbc.ini file that comes with the product and I cant see this parameter. Nor does the documentation mention this .. Thanks W Samuel Yahoo! Messenger - Communicate instantly...Ping your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html 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: Message Tracking
I played around with the sample API Exit and installed it for the listener and I believe you'll get all information needed. It only works for you if the application use client connection. This will produce very big log-files so I can't recommend to use it in an production environment, but in your case it may be acceptable. Gunter 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: Message Tracking
Roger, the only thing I have to say is to agree that you want to include at least part of the actual message data. That way, if the programmer has the wrong msgid or correlid or even ends up with duplicates (if, for example, he doesn't clear these fields before his next put), you stand a chance of finding the actual message based on the data itself. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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: Message Tracking
Roger, you seem want to show them evidence that THEY are nuts. it probably won't work that way. Beside, with the time you need for one or more evidence collector, you could have long taught all of them enough to be good-enough MQ-developers. cheers, Benjamin F. Zhou Technical Specialist MessagingIntegration Supp. Mercedes-Benz USA x.2474 Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeriesSubject: Message Tracking List [EMAIL PROTECTED] C.AT 04/28/2004 11:48 PM Please respond to MQSeries List All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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: Message Tracking
Roger, I have to agree with the suggestions for logging the data as well as the MQMD. In most application environments, a user will complain about a missing message and only be able to provide a piece of data (ie, Swift CustRef field (field 20), invoice number, etc.). I would hazard a guess that most developers would only be able to supply the same (based on personal experience). The fun part, of course, will be correlating all this data against itself when Joe programmer invokes the following conversation: JP: I can't find a message I sent out 3 hours ago. You: Well, what was the messagesID of the message? JP: the what? You: The MsgID, you did log it somewhere, didn't you? JP: the what? You: What about the correlID, did you log that? JP: the what? You: Holy %^#$#*^ Regards, Dave A. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 *** Credit Lyonnais This e-mail contains confidential information or information belonging to Credit Lyonnais and is intended solely for the addressees. The unauthorized disclosure, use, dissemination or copying (either whole or partial) of this e-mail, or any information it contains, is prohibited. E-mails are susceptible to alteration and their integrity cannot be guaranteed. Credit Lyonnais shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Credit Lyonnais in the Americas: Credit Lyonnais Bank New York Branch, Credit Lyonnais Americas Services Inc., Credit Lyonnais Rouse (USA) Ltd., and Credit Lyonnais Securities (USA) Inc. *** Credit Lyonnais 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
Adding to Clusters
I currently have 2 queue managers (QM1 and QM2), which are both full repositories in cluster NATEST. I need to add another queue manager (QM3). I've attached it to QM2: On QM2, I've defined a CLUSSDR (TO.QM3) and a CLUSRCVR (TO.QM2). I then added queues on QM3 to the cluster. My problemI cannot see that these queues exist on QM2. I've refreshed the cluster on QM2 (with repos) and on QM3. What am I missing? Regards, Gina McCarthy Sr Systems Programmer MQSeries/CICS Arrow Electronics, Inc. 50 Marcus Drive Melville, NY 11747 (631) 847-5440 [EMAIL PROTECTED]
Adding QM to a Cluster.....
Ialso defined: On QM3, I've defined a CLUSSDR (TO.QM2) and a CLUSRCVR (TO.QM3). Regards, Gina McCarthy Sr Systems Programmer MQSeries/CICS Arrow Electronics, Inc. 50 Marcus Drive Melville, NY 11747 (631) 847-5440 [EMAIL PROTECTED]
Re: Can a MQ server act as MQClient?
I not sure this is true in all install instances but on Windows and OS390 it is a different install. I am not sure on the UNIX side but would bet IBM followed the same procedure. When installing one of the first things to be done is to verify that the server connection and Client connection works to the QMGR on that box. You can do this by executing the amqs... and amqs...c samples. bobbee From: Usha Suryadevara [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Can a MQ server act as MQClient? Date: Wed, 28 Apr 2004 16:43:48 -0400 Just curious, are you guys saying that you will install an MQ server and then you will also install an MQ client on the same machine ? I thought MQ Server is a super set that installs everything a client installs and a lot more. But yes i know for sure that you can write an application to use MQ API (such that it uses a client connection server connection channel combo thus making it a client server connection) to connect to another Queue Manager on a different machine. I am not sure if this is what you are looking for, but thought i would drop my few cents in just in case... Thanks Usha At 03:29 PM 4/28/2004 -0400, you wrote: To be more precise about the answer, yes, you can run an MQ Client process on a machine that is also running a queue manager, and have that client access a different queue manager than the one running on the same box. Bill -- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Sharath H V Sent: Wednesday, April 28, 2004 8:26 AM To: [EMAIL PROTECTED] Subject: Can a MQ server act as MQClient? All I have a few questions for you in MQ . We have a MQ server which is going to be used in two ways . The first one would be used for connecting the two modules of the same application.Here Module 1 writes on to the Local Q and Module 2 reads from the Local Q . The second one should be used as a client . There is a second MQServer which gets the messages from an external MQserver (MQserver 3 ) Here we want the first MQ server act as client to the second MQserver Can I use a MQserver as a MQclient to connect to another MQ Server ? If so , can i get some material on how to do the same . image0019.gif rgds H V SHarath _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ 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: Message Tracking
I guess I took the other routeI made the developers prove to me the MQ was losing messages. They coded in their put application a total messages sent and in their get application total messages got. IF those totals did not match we were notified. We did discover that we had a commitment control problem that IBM identified in 5.2. This was a major selling point for upgrading to 5.3. We have not had the problem since the upgrade. Joan Hughes IT Technical Specialist 608-827-3523 Benjamin F. ZhouTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: USA.COM Subject: Re: Message Tracking Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 04/29/2004 08:00 AM Please respond to MQSeries List Roger, you seem want to show them evidence that THEY are nuts. it probably won't work that way. Beside, with the time you need for one or more evidence collector, you could have long taught all of them enough to be good-enough MQ-developers. cheers, Benjamin F. Zhou Technical Specialist MessagingIntegration Supp. Mercedes-Benz USA x.2474 Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeriesSubject: Message Tracking List [EMAIL PROTECTED] C.AT 04/28/2004 11:48 PM Please respond to MQSeries List All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 * [This message and its contents have been scanned for viruses] * 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: Message Tracking
Roger. Isn't there a support pack, SERVER connection only, that does this to some point (MQMD and 100 bytes of data). I know a fellow that got it working for the Client connection but refuses to give up the code. bobbee From: Roger Lacroix [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Message Tracking Date: Wed, 28 Apr 2004 23:48:13 -0400 All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ 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: Can a MQ server act as MQClient?
It's a different install on OS/390, but a typical install on Windows installs both the client stubs and the client support, at least in my experience. Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Robert Broderick Sent: Thursday, April 29, 2004 9:28 AM To: [EMAIL PROTECTED] Subject: Re: Can a MQ server act as MQClient? I not sure this is true in all install instances but on Windows and OS390 it is a different install. I am not sure on the UNIX side but would bet IBM followed the same procedure. When installing one of the first things to be done is to verify that the server connection and Client connection works to the QMGR on that box. You can do this by executing the amqs... and amqs...c samples. bobbee From: Usha Suryadevara [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Can a MQ server act as MQClient? Date: Wed, 28 Apr 2004 16:43:48 -0400 Just curious, are you guys saying that you will install an MQ server and then you will also install an MQ client on the same machine ? I thought MQ Server is a super set that installs everything a client installs and a lot more. But yes i know for sure that you can write an application to use MQ API (such that it uses a client connection server connection channel combo thus making it a client server connection) to connect to another Queue Manager on a different machine. I am not sure if this is what you are looking for, but thought i would drop my few cents in just in case... Thanks Usha At 03:29 PM 4/28/2004 -0400, you wrote: To be more precise about the answer, yes, you can run an MQ Client process on a machine that is also running a queue manager, and have that client access a different queue manager than the one running on the same box. Bill -- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Sharath H V Sent: Wednesday, April 28, 2004 8:26 AM To: [EMAIL PROTECTED] Subject: Can a MQ server act as MQClient? All I have a few questions for you in MQ . We have a MQ server which is going to be used in two ways . The first one would be used for connecting the two modules of the same application.Here Module 1 writes on to the Local Q and Module 2 reads from the Local Q . The second one should be used as a client . There is a second MQServer which gets the messages from an external MQserver (MQserver 3 ) Here we want the first MQ server act as client to the second MQserver Can I use a MQserver as a MQclient to connect to another MQ Server ? If so , can i get some material on how to do the same . image0019.gif rgds H V SHarath _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ 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: Message Tracking
Roger, The api crossing exit which comes with WMQ addresses most of your concerns. Have you looked at it ? Bullock, Rebecca (CSC) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Subject: Re: Message Tracking Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 04/29/2004 08:49 AM Please respond to MQSeries List Roger, the only thing I have to say is to agree that you want to include at least part of the actual message data. That way, if the programmer has the wrong msgid or correlid or even ends up with duplicates (if, for example, he doesn't clear these fields before his next put), you stand a chance of finding the actual message based on the data itself. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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 communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. 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: World Writable files under Unix
I found an interesting description in WAS Manual: http://publib.boulder.ibm.com/infocenter/wasinfo/topic/com.ibm.websphere.base.doc/info/aes/ae/tmj_secmqm.html But I don't understand why this is missing from MQ Security Manual... HTH, Tibor I started the Post I do not remember a final answer. Emile Kearns Certified MQSeries Specialist IBM Certified System Administrator - Websphere MQ, V5.3 -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Meekin, Paul Sent: 25 March 2004 05:59 PM To: [EMAIL PROTECTED] Subject: World Writable files under Unix Hi all, Last July there was a thread about directories under /var/mqm/qmgrs/@SYSTEM having permissions drwxrwsrwx here http://www.mail-archive.com/[EMAIL PROTECTED]/msg09014.html. Was there ever a final answer about what these are used for and if the world write access allowed a potential Denial of Service? Our audit people have just discovered them and are asking awkward questions !!! 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 Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, this message. 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: Adding to Clusters
You seem to have all the needed definitions. (By the way, the CLUSSNDR you manually made from QM2 to QM3 is not needed. MQ Cluster Magic will auto define that one when it needs it, and won't even use the one you made.) On QM3: Is the TO.QM3 channel clustered? Is TO.QM3 defined properly (hostname(port))? Is the TO.QM2 channel clustered? Are the queues you defined clustered? On QM1 or QM2, what happens if you issue DIS CLUSQMGR(*)? Does it show QM3? The refresh command is not available on QM2 or QM1, since they are full repositories. However, issuing it on QM3 is supposed to push out all of QM3's data to the Full Repositories. Is the channel from QM3 to QM2 running? -Original Message-From: Gina McCarthy [mailto:[EMAIL PROTECTED]Sent: Thursday, April 29, 2004 9:21 AMTo: [EMAIL PROTECTED]Subject: Adding to Clusters I currently have 2 queue managers (QM1 and QM2), which are both full repositories in cluster NATEST. I need to add another queue manager (QM3). I've attached it to QM2: On QM2, I've defined a CLUSSDR (TO.QM3) and a CLUSRCVR (TO.QM2). I then added queues on QM3 to the cluster. My problemI cannot see that these queues exist on QM2. I've refreshed the cluster on QM2 (with repos) and on QM3. What am I missing? Regards, Gina McCarthy Sr Systems Programmer MQSeries/CICS Arrow Electronics, Inc. 50 Marcus Drive Melville, NY 11747 (631) 847-5440 [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: Message Tracking
Roger, I thought i would get my opinions here as well, other than mqseries.net. One immediate answer that you could give to your client/developers is that, they need to *prove* to you that MQ is infact loosing messages. I know this might sound a bit harsh, but if i have a queue manager and a client connects to it and complains that they are loosing messages, and i cant find any relevant info on my side(logs, ffsts, events). Then the question that would follow is, how do they concur that the messages are infact being lost. As you know MQ wouldnt ever loose a message unless there is either an app problem or MQ problem. In the latter, there would *surely* be some sort of logging some place. In the former... Hmm... Thats where i guess we need to concentrate. IMHO. And i know i dont need to mentione all this, but just adding. If the messages are persistent and the put completes and commit occurs. There is *no* way MQ would loose the message without logging anything anywhere. So, i would go back to the dev's and probably ask them to log their api calls outputs. Say after each put/get/commit/back log the reason code and correlate the same. IMO its *not* the responsibility of the QM or MQ or the one managing the qm to wonder what happened to messages put by clients. Its the clients responsibility to log everything they do. Again all this, IMO. Cheers Kumar Robert Broderick [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 04/29/2004 09:30 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Message Tracking Roger. Isn't there a support pack, SERVER connection only, that does this to some point (MQMD and 100 bytes of data). I know a fellow that got it working for the Client connection but refuses to give up the code. bobbee From: Roger Lacroix [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Message Tracking Date: Wed, 28 Apr 2004 23:48:13 -0400 All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ 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
Need for a data conversion utility?
In the course of investigating some strangeness in data conversion between OS/390 and Windows, I learned a lot (thanks to having saved threads from this group). I decided to make an actual conversion table for our developers, so they would know what to expect back from the IMS Bridge. And found it tedious. I found no utility that would dump a conversion table into some readily usable for human consumption. I did the first one manually, but last night amused myself by hacking a little utility that would turn a conversion table into a spreadsheet. Anyone else think this would be a generally useful thing to have around? I also saw no equivalent of iconv on Windows. Would there be a need for a utility that would translate one file into another using a specified code page translation table? I like to code, so if this sort of thing would be useful, I'll do it. Bill Beinert Systems Programming Con Edison When they took the fourth amendment, I was quiet because I didn't deal drugs! When they took the sixth amendment, I was quiet because, I was innocent. When they took the second amendment, I was quiet because I didn't own a gun! Now they've taken the first amendment, and I can say (or do) nothing about it. The Second Amendment is in place in case they ignore the others. MODWN DAbE 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
Using runmqtmc on Solaris
We are running our MQ software on Solaris 8. Yesterday I discovered that several applications are using the runmqtmc (client trigger monitor) executable to send messages from the client to the server. The problem is that according to the WMQ 5.3 System Guide this is only available on AIX. We have no AIX servers. Has anyone else used runmqtmc successfully on Solaris? Are there gotchas I need to look out for? We are upgrading our clients from 5.2 to 5.3 (our servers are already 5.3) and I am especially worried this may fail once we upgrade. Ed 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: Adding to Clusters
Your problem is exactly described as the second symptom (pg 110)in the TroubleShooting section of the Cluster manual. Basically, it says fix the channel definition, and wait a retry cycle for it to fix itself. If that doesn't fix it, let us know. There is a manual way to get around this, but it is multistep and probably overkill if the above method will work. -Original Message-From: Gina McCarthy [mailto:[EMAIL PROTECTED]Sent: Thursday, April 29, 2004 10:24 AMTo: 'Potkay, Peter M (PLC, IT)'; [EMAIL PROTECTED]Subject: RE: Adding to Clusters Thank you Peter! On QM3: Is the TO.QM3 channel clustered? The CLUSRCVR (TO.QM3) did not specify the cluster. I added it and restarted the CLUSSDR (TO.QM3) on QM2. Is TO.QM3 defined properly (hostname(port))? Yes, as a matter of fact. They're all started. Is the TO.QM2 channel clustered? Yes Are the queues you defined clustered? Yes. On QM1 or QM2, what happens if you issue DIS CLUSQMGR(*)? Does it show QM3? No. ;-( On QM1, it shows QM1 and QM2 only. On QM2, it shows: dis clusqmgr(*) 1 : dis clusqmgr(*) AMQ8441: Display Cluster Queue Manager details. - QM2 CLUSQMGR(AIXMQST1) CLUSTER(NATEST) CHANNEL(TO.AIXMQST1) AMQ8441: Display Cluster Queue Manager details.- QM1 CLUSQMGR(MQ1T) CLUSTER(NATEST) CHANNEL(TO.MQ1T) AMQ8441: Display Cluster Queue Manager details. -- QM3 CLUSQMGR(SYSTEM.TEMPQMGR.usmlio02.arrow.com(1414)) CLUSTER(NATEST) CHANNEL(TO.OS4MQST1) OK...this is the problem. When I originally created the CLUSRCVR on QM3, I put the wrong port of 1414 when it should have been 1415.How can I delete thisor can I??? Thanks! Gina -Original Message-From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]Sent: Thursday, April 29, 2004 9:57 AMTo: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]Subject: RE: Adding to Clusters You seem to have all the needed definitions. (By the way, the CLUSSNDR you manually made from QM2 to QM3 is not needed. MQ Cluster Magic will auto define that one when it needs it, and won't even use the one you made.) On QM3: Is the TO.QM3 channel clustered? Is TO.QM3 defined properly (hostname(port))? Is the TO.QM2 channel clustered? Are the queues you defined clustered? On QM1 or QM2, what happens if you issue DIS CLUSQMGR(*)? Does it show QM3? The refresh command is not available on QM2 or QM1, since they are full repositories. However, issuing it on QM3 is supposed to push out all of QM3's data to the Full Repositories. Is the channel from QM3 to QM2 running? -Original Message-From: Gina McCarthy [mailto:[EMAIL PROTECTED]Sent: Thursday, April 29, 2004 9:21 AMTo: [EMAIL PROTECTED]Subject: Adding to Clusters I currently have 2 queue managers (QM1 and QM2), which are both full repositories in cluster NATEST. I need to add another queue manager (QM3). I've attached it to QM2: On QM2, I've defined a CLUSSDR (TO.QM3) and a CLUSRCVR (TO.QM2). I then added queues on QM3 to the cluster. My problemI cannot see that these queues exist on QM2. I've refreshed the cluster on QM2 (with repos) and on QM3. What am I missing? Regards, Gina McCarthy Sr Systems Programmer MQSeries/CICS Arrow Electronics, Inc. 50 Marcus Drive Melville, NY 11747 (631) 847-5440 [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: Can a MQ server act as MQClient?
In Unix (at least, Solaris), you can specify that both the server and client be installed at the same time (they are options you select from a list). You cannot install the server and then go back and install the client later. This will work initially, but you'll have problems when you next put on a CSD. What happens is the list of installed options is stored in a variable as part of the package info and if you add the client later, this value is updated to list only the client. Then when you put on the next CSD, only the client code is updated; the result was very ugly. Although I suppose you could save the value in the variable, add the client, and then put the original value back. I'm not that into Solaris packages, but it sounds like it would work. Comments anyone? -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 9:36 AM To: [EMAIL PROTECTED] Subject: Re: Can a MQ server act as MQClient? It's a different install on OS/390, but a typical install on Windows installs both the client stubs and the client support, at least in my experience. Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Robert Broderick Sent: Thursday, April 29, 2004 9:28 AM To: [EMAIL PROTECTED] Subject: Re: Can a MQ server act as MQClient? I not sure this is true in all install instances but on Windows and OS390 it is a different install. I am not sure on the UNIX side but would bet IBM followed the same procedure. When installing one of the first things to be done is to verify that the server connection and Client connection works to the QMGR on that box. You can do this by executing the amqs... and amqs...c samples. bobbee From: Usha Suryadevara [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Can a MQ server act as MQClient? Date: Wed, 28 Apr 2004 16:43:48 -0400 Just curious, are you guys saying that you will install an MQ server and then you will also install an MQ client on the same machine ? I thought MQ Server is a super set that installs everything a client installs and a lot more. But yes i know for sure that you can write an application to use MQ API (such that it uses a client connection server connection channel combo thus making it a client server connection) to connect to another Queue Manager on a different machine. I am not sure if this is what you are looking for, but thought i would drop my few cents in just in case... Thanks Usha At 03:29 PM 4/28/2004 -0400, you wrote: To be more precise about the answer, yes, you can run an MQ Client process on a machine that is also running a queue manager, and have that client access a different queue manager than the one running on the same box. Bill -- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Sharath H V Sent: Wednesday, April 28, 2004 8:26 AM To: [EMAIL PROTECTED] Subject: Can a MQ server act as MQClient? All I have a few questions for you in MQ . We have a MQ server which is going to be used in two ways . The first one would be used for connecting the two modules of the same application.Here Module 1 writes on to the Local Q and Module 2 reads from the Local Q . The second one should be used as a client . There is a second MQServer which gets the messages from an external MQserver (MQserver 3 ) Here we want the first MQ server act as client to the second MQserver Can I use a MQserver as a MQclient to connect to another MQ Server ? If so , can i get some material on how to do the same . image0019.gif rgds H V SHarath _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ 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 ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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
ESQL : CASE WHEN
Can I not have multiple condition in a case like..
SET myVar = CASE UPPER(var) WHEN 'AB' THEN '12' WHEN 'CD' OR 'EF' OR 'GH' THEN '00' END;
I tried
SET myVar = CASE UPPER(var) WHEN 'AB' THEN '12' WHEN IN ('CD', 'EF', 'GH') THEN '00' END;
Gives me an error !!__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Message Tracking
Hi, Hummm, so are you suggesting that under SyncPoint the Api Exit is called twice: once for the get and then again for commit (or back). Hummm, most interesting. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting David C. Partridge [EMAIL PROTECTED]: The API Exit is invoked at MQCMIT and MQBACK time, but you'll have royal fun keeping track of what was committed and backed out it you are logging messages to see what happened. Dave 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: Message Tracking
Hi, Do you mean Message Exit? The Api Exit is associated with the queue manager rather than the channel. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Gunter Jeschawitz [EMAIL PROTECTED]: I played around with the sample API Exit and installed it for the listener and I believe you'll get all information needed. It only works for you if the application use client connection. This will produce very big log-files so I can't recommend to use it in an production environment, but in your case it may be acceptable. Gunter 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: Message Tracking
Hi, Yes, after this flurry of emails, I think it would be best to include all MQMD and part of the message data. I will make it configurable but have a default of 100 bytes. Yes, this is definitely one of the situations that has come up. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Bullock, Rebecca (CSC) [EMAIL PROTECTED]: Roger, the only thing I have to say is to agree that you want to include at least part of the actual message data. That way, if the programmer has the wrong msgid or correlid or even ends up with duplicates (if, for example, he doesn't clear these fields before his next put), you stand a chance of finding the actual message based on the data itself. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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: Message Tracking
Hi, I fully agree with you but sadly as the 'Messaging Architect' for one division I do not have the authority to request or mandate anything. I can only recommend things. I have written WMQ Naming Standards documents and WMQ Programming Standards documents for the client but it just goes over the newbie's head. So, this may be a difficult solution but it will give me fewer headaches. :) Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Benjamin F. Zhou [EMAIL PROTECTED]: Roger, you seem want to show them evidence that THEY are nuts. it probably won't work that way. Beside, with the time you need for one or more evidence collector, you could have long taught all of them enough to be good-enough MQ-developers. cheers, Benjamin F. Zhou Technical Specialist MessagingIntegration Supp. Mercedes-Benz USA x.2474 Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeriesSubject: Message Tracking List [EMAIL PROTECTED] C.AT 04/28/2004 11:48 PM Please respond to MQSeries List All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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: Using runmqtmc on Solaris
We use runmqtmc on Solaris 8 with the 5.3 client, and there's no problems at all. We previoulsy used it on 5.2 and Solaris 2.6, and that worked as well. To be honest with you, we never saw the note that said AIX clients only in the Admin manual. Runmqtmc ships with the Solaris client, and we never thought to check if the manual said it was OK to use. I think it's a typo. Ed Rutkowski [EMAIL PROTECTED]To: [EMAIL PROTECTED] GUARD.COM cc: Sent by: MQSeriesSubject: Using runmqtmc on Solaris List [EMAIL PROTECTED] n.ac.at 04/29/2004 09:28 AM Please respond to MQSeries List We are running our MQ software on Solaris 8. Yesterday I discovered that several applications are using the runmqtmc (client trigger monitor) executable to send messages from the client to the server. The problem is that according to the WMQ 5.3 System Guide this is only available on AIX. We have no AIX servers. Has anyone else used runmqtmc successfully on Solaris? Are there gotchas I need to look out for? We are upgrading our clients from 5.2 to 5.3 (our servers are already 5.3) and I am especially worried this may fail once we upgrade. Ed 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: Message Tracking
Hi, How did you know that this is a typical conversasion? :)) As per the other email, I will include all MQMD fields and part of the message data (size will be configurable). Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Awerbuch, David [EMAIL PROTECTED]: Roger, I have to agree with the suggestions for logging the data as well as the MQMD. In most application environments, a user will complain about a missing message and only be able to provide a piece of data (ie, Swift CustRef field (field 20), invoice number, etc.). I would hazard a guess that most developers would only be able to supply the same (based on personal experience). The fun part, of course, will be correlating all this data against itself when Joe programmer invokes the following conversation: JP: I can't find a message I sent out 3 hours ago. You: Well, what was the messagesID of the message? JP: the what? You: The MsgID, you did log it somewhere, didn't you? JP: the what? You: What about the correlID, did you log that? JP: the what? You: Holy %^#$#*^ Regards, Dave A. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 *** Credit Lyonnais This e-mail contains confidential information or information belonging to Credit Lyonnais and is intended solely for the addressees. The unauthorized disclosure, use, dissemination or copying (either whole or partial) of this e-mail, or any information it contains, is prohibited. E-mails are susceptible to alteration and their integrity cannot be guaranteed. Credit Lyonnais shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Credit Lyonnais in the Americas: Credit Lyonnais Bank New York Branch, Credit Lyonnais Americas Services Inc., Credit Lyonnais Rouse (USA) Ltd., and Credit Lyonnais Securities (USA) Inc. *** Credit Lyonnais 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: Message Tracking
Hi, Please see my response to David A.'s email. But basically I say prove it, and I get a blank look /response and worse they run to their VP and say MQ is losing their messages. And of course you know what happens next. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Joe H. Smith [EMAIL PROTECTED]: I guess I took the other routeI made the developers prove to me the MQ was losing messages. They coded in their put application a total messages sent and in their get application total messages got. IF those totals did not match we were notified. We did discover that we had a commitment control problem that IBM identified in 5.2. This was a major selling point for upgrading to 5.3. We have not had the problem since the upgrade. Joan Hughes IT Technical Specialist 608-827-3523 Benjamin F. ZhouTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: USA.COM Subject: Re: Message Tracking Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 04/29/2004 08:00 AM Please respond to MQSeries List Roger, you seem want to show them evidence that THEY are nuts. it probably won't work that way. Beside, with the time you need for one or more evidence collector, you could have long taught all of them enough to be good-enough MQ-developers. cheers, Benjamin F. Zhou Technical Specialist MessagingIntegration Supp. Mercedes-Benz USA x.2474 Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeriesSubject: Message Tracking List [EMAIL PROTECTED] C.AT 04/28/2004 11:48 PM Please respond to MQSeries List All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 * [This message and its contents have been scanned for viruses] * 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: Message Tracking
Hi, I think you are thinking of the Message Exit. The Api Exit is associated with the queue manager. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Robert Broderick [EMAIL PROTECTED]: Roger. Isn't there a support pack, SERVER connection only, that does this to some point (MQMD and 100 bytes of data). I know a fellow that got it working for the Client connection but refuses to give up the code. bobbee From: Roger Lacroix [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Message Tracking Date: Wed, 28 Apr 2004 23:48:13 -0400 All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ 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: Message Tracking
Hi, Am I not sure but I believe 'Api Crossing Exit' is mainframe only. (Anyone!) Although, 'Api Crossing Exit' could be the 'Api Exit' that I am referring to. Is it available on distributed platforms and configure at a queue manager level (and not channel attribute)? Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting [EMAIL PROTECTED]: Roger, The api crossing exit which comes with WMQ addresses most of your concerns. Have you looked at it ? Bullock, Rebecca (CSC) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Subject: Re: Message Tracking Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 04/29/2004 08:49 AM Please respond to MQSeries List Roger, the only thing I have to say is to agree that you want to include at least part of the actual message data. That way, if the programmer has the wrong msgid or correlid or even ends up with duplicates (if, for example, he doesn't clear these fields before his next put), you stand a chance of finding the actual message based on the data itself. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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 communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. 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: Message Tracking
Hi, Please see my other emails regard my headaches. :) I fully agree with your comments but when newbies complain to their VP, who compalins to my VP, who then complains to my manager and me being a consultant, you know what happens next!!! Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting [EMAIL PROTECTED]: Roger, I thought i would get my opinions here as well, other than mqseries.net. One immediate answer that you could give to your client/developers is that, they need to *prove* to you that MQ is infact loosing messages. I know this might sound a bit harsh, but if i have a queue manager and a client connects to it and complains that they are loosing messages, and i cant find any relevant info on my side(logs, ffsts, events). Then the question that would follow is, how do they concur that the messages are infact being lost. As you know MQ wouldnt ever loose a message unless there is either an app problem or MQ problem. In the latter, there would *surely* be some sort of logging some place. In the former... Hmm... Thats where i guess we need to concentrate. IMHO. And i know i dont need to mentione all this, but just adding. If the messages are persistent and the put completes and commit occurs. There is *no* way MQ would loose the message without logging anything anywhere. So, i would go back to the dev's and probably ask them to log their api calls outputs. Say after each put/get/commit/back log the reason code and correlate the same. IMO its *not* the responsibility of the QM or MQ or the one managing the qm to wonder what happened to messages put by clients. Its the clients responsibility to log everything they do. Again all this, IMO. Cheers Kumar Robert Broderick [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 04/29/2004 09:30 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Message Tracking Roger. Isn't there a support pack, SERVER connection only, that does this to some point (MQMD and 100 bytes of data). I know a fellow that got it working for the Client connection but refuses to give up the code. bobbee From: Roger Lacroix [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Message Tracking Date: Wed, 28 Apr 2004 23:48:13 -0400 All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ 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: Message Tracking
Hi, No, these paricular applications do not use message expiry. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Williams, Arlen [EMAIL PROTECTED]: Maybe the expiry time. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 10:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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: Message Tracking
You forgot the last response line. JP: I never had this problem with FTP From: Awerbuch, David [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Message Tracking Date: Thu, 29 Apr 2004 09:08:17 -0400 Roger, I have to agree with the suggestions for logging the data as well as the MQMD. In most application environments, a user will complain about a missing message and only be able to provide a piece of data (ie, Swift CustRef field (field 20), invoice number, etc.). I would hazard a guess that most developers would only be able to supply the same (based on personal experience). The fun part, of course, will be correlating all this data against itself when Joe programmer invokes the following conversation: JP: I can't find a message I sent out 3 hours ago. You: Well, what was the messagesID of the message? JP: the what? You: The MsgID, you did log it somewhere, didn't you? JP: the what? You: What about the correlID, did you log that? JP: the what? You: Holy %^#$#*^ Regards, Dave A. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 *** Credit Lyonnais This e-mail contains confidential information or information belonging to Credit Lyonnais and is intended solely for the addressees. The unauthorized disclosure, use, dissemination or copying (either whole or partial) of this e-mail, or any information it contains, is prohibited. E-mails are susceptible to alteration and their integrity cannot be guaranteed. Credit Lyonnais shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Credit Lyonnais in the Americas: Credit Lyonnais Bank New York Branch, Credit Lyonnais Americas Services Inc., Credit Lyonnais Rouse (USA) Ltd., and Credit Lyonnais Securities (USA) Inc. *** Credit Lyonnais 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 _ From must-see cities to the best beaches, plan a getaway with the Spring Travel Guide! http://special.msn.com/local/springtravel.armx 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: Can a MQ server act as MQClient?
I just installed on WINDOWS two days ago and the default install did not install the client. From: Beinert, William [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Can a MQ server act as MQClient? Date: Thu, 29 Apr 2004 09:35:34 -0400 It's a different install on OS/390, but a typical install on Windows installs both the client stubs and the client support, at least in my experience. Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Robert Broderick Sent: Thursday, April 29, 2004 9:28 AM To: [EMAIL PROTECTED] Subject: Re: Can a MQ server act as MQClient? I not sure this is true in all install instances but on Windows and OS390 it is a different install. I am not sure on the UNIX side but would bet IBM followed the same procedure. When installing one of the first things to be done is to verify that the server connection and Client connection works to the QMGR on that box. You can do this by executing the amqs... and amqs...c samples. bobbee From: Usha Suryadevara [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Can a MQ server act as MQClient? Date: Wed, 28 Apr 2004 16:43:48 -0400 Just curious, are you guys saying that you will install an MQ server and then you will also install an MQ client on the same machine ? I thought MQ Server is a super set that installs everything a client installs and a lot more. But yes i know for sure that you can write an application to use MQ API (such that it uses a client connection server connection channel combo thus making it a client server connection) to connect to another Queue Manager on a different machine. I am not sure if this is what you are looking for, but thought i would drop my few cents in just in case... Thanks Usha At 03:29 PM 4/28/2004 -0400, you wrote: To be more precise about the answer, yes, you can run an MQ Client process on a machine that is also running a queue manager, and have that client access a different queue manager than the one running on the same box. Bill -- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Sharath H V Sent: Wednesday, April 28, 2004 8:26 AM To: [EMAIL PROTECTED] Subject: Can a MQ server act as MQClient? All I have a few questions for you in MQ . We have a MQ server which is going to be used in two ways . The first one would be used for connecting the two modules of the same application.Here Module 1 writes on to the Local Q and Module 2 reads from the Local Q . The second one should be used as a client . There is a second MQServer which gets the messages from an external MQserver (MQserver 3 ) Here we want the first MQ server act as client to the second MQserver Can I use a MQserver as a MQclient to connect to another MQ Server ? If so , can i get some material on how to do the same . image0019.gif rgds H V SHarath _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ 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 _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ 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: Message Tracking
All, I'll correct myself. :)) 'Api Crossing Exit' is the 'Api Exit' that I am referring to. Here is a quick explanation about it from IBM: http://www.mqug.org.uk/anonftp/021131%20-%20MQUTIL.pdf Regards, Roger Lacroix 416-566-7307 Capitalware Inc. http://www.capitalware.biz Quoting Roger Lacroix [EMAIL PROTECTED]: Hi, Am I not sure but I believe 'Api Crossing Exit' is mainframe only. (Anyone!) Although, 'Api Crossing Exit' could be the 'Api Exit' that I am referring to. Is it available on distributed platforms and configure at a queue manager level (and not channel attribute)? Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting [EMAIL PROTECTED]: Roger, The api crossing exit which comes with WMQ addresses most of your concerns. Have you looked at it ? Bullock, Rebecca (CSC) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Subject: Re: Message Tracking Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 04/29/2004 08:49 AM Please respond to MQSeries List Roger, the only thing I have to say is to agree that you want to include at least part of the actual message data. That way, if the programmer has the wrong msgid or correlid or even ends up with duplicates (if, for example, he doesn't clear these fields before his next put), you stand a chance of finding the actual message based on the data itself. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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 communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. 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: Message Tracking
I wonder why DBAs don't get the same kind of statements about databases - DB2 is losing my records. If we could work out what their magic is and use some of that... Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: 29 April 2004 16:22 To: [EMAIL PROTECTED] Subject: Re: Message Tracking Hi, Please see my response to David A.'s email. But basically I say prove it, and I get a blank look /response and worse they run to their VP and say MQ is losing their messages. And of course you know what happens next. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Joe H. Smith [EMAIL PROTECTED]: I guess I took the other routeI made the developers prove to me the MQ was losing messages. They coded in their put application a total messages sent and in their get application total messages got. IF those totals did not match we were notified. We did discover that we had a commitment control problem that IBM identified in 5.2. This was a major selling point for upgrading to 5.3. We have not had the problem since the upgrade. Joan Hughes IT Technical Specialist 608-827-3523 Benjamin F. ZhouTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: USA.COM Subject: Re: Message Tracking Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 04/29/2004 08:00 AM Please respond to MQSeries List Roger, you seem want to show them evidence that THEY are nuts. it probably won't work that way. Beside, with the time you need for one or more evidence collector, you could have long taught all of them enough to be good-enough MQ-developers. cheers, Benjamin F. Zhou Technical Specialist MessagingIntegration Supp. Mercedes-Benz USA x.2474 Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeriesSubject: Message Tracking List [EMAIL PROTECTED] C.AT 04/28/2004 11:48 PM Please respond to MQSeries List All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 * [This message and its contents have been scanned for viruses] * 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 ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and/or confidential, and is intended exclusively for the addressee. Unauthorised disclosure, copying or distribution of the contents is strictly prohibited. The views expressed may not be official policy, but the personal views of the originator. If you have received this message in error, please advise the sender by using
Re: Message Tracking
Yes, that's *exactly* what I mean, so if you do 100 gets followed by a backout, the exit is called 200 times (for before get and after get entries) and then once before the backout and once afterwards. Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Roger Lacroix Sent: 29 April 2004 16:03 To: [EMAIL PROTECTED] Subject: Re: Message Tracking Hi, Hummm, so are you suggesting that under SyncPoint the Api Exit is called twice: once for the get and then again for commit (or back). Hummm, most interesting. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting David C. Partridge [EMAIL PROTECTED]: The API Exit is invoked at MQCMIT and MQBACK time, but you'll have royal fun keeping track of what was committed and backed out it you are logging messages to see what happened. Dave 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: Message Tracking
Roger, Perhaps as the Messaging Architect you can request that they first develop a messaging API that must be used by all developers. This API, based on the values of environment variables, would be able to log anything and/or everything you might want it to at a particular time. Not only would this externally controlled logging system make a great debugging tool for developers, it would probably prove invaluable in shooting down a real program bug that only raises its ugly head under very specific circumstances and only in production. I have implemented APIs like this for different clients in different messaging / store-and-forward systems more times than I care to remember. Each time, this simple interface has saved our butts during a real production problem. Each time, it proved the messaging system was working flawlessly, and that there was some other problem with the application - complex-conditional logic errors, errant pointers, dynamic static data, and compiler optimization errors, just to name four. Dave A. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 11:16 AM To: [EMAIL PROTECTED] Subject: Re: Message Tracking Hi, I fully agree with you but sadly as the 'Messaging Architect' for one division I do not have the authority to request or mandate anything. I can only recommend things. I have written WMQ Naming Standards documents and WMQ Programming Standards documents for the client but it just goes over the newbie's head. So, this may be a difficult solution but it will give me fewer headaches. :) Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Benjamin F. Zhou [EMAIL PROTECTED]: Roger, you seem want to show them evidence that THEY are nuts. it probably won't work that way. Beside, with the time you need for one or more evidence collector, you could have long taught all of them enough to be good-enough MQ-developers. cheers, Benjamin F. Zhou Technical Specialist MessagingIntegration Supp. Mercedes-Benz USA x.2474 Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeriesSubject: Message Tracking List [EMAIL PROTECTED] C.AT 04/28/2004 11:48 PM Please respond to MQSeries List All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix = David A. Awerbuch, IBM Certified MQSeries Specialist APC Consulting Services, Inc. Providing Automated Solutions to Business Challenges West Hempstead, NY(516) 481-6440 [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover 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: Message Tracking
John, When DB2 was the new kid on the block they did, just wait for a new IBM wonder technology and then everyone will blame that instead of WMQ, Nick = Nick Beckson Country Manager Benelux Region. Cressida Technology Ltd. Tel: +31 (0)416 340 447 Mob: +31 (0)6 53 20 29 29 Mail: [EMAIL PROTECTED] Web: www.cressida.info -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of John Scott Sent: donderdag 29 april 2004 18:06 To: [EMAIL PROTECTED] Subject: Re: Message Tracking I wonder why DBAs don't get the same kind of statements about databases - DB2 is losing my records. If we could work out what their magic is and use some of that... Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: 29 April 2004 16:22 To: [EMAIL PROTECTED] Subject: Re: Message Tracking Hi, Please see my response to David A.'s email. But basically I say prove it, and I get a blank look /response and worse they run to their VP and say MQ is losing their messages. And of course you know what happens next. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Joe H. Smith [EMAIL PROTECTED]: I guess I took the other routeI made the developers prove to me the MQ was losing messages. They coded in their put application a total messages sent and in their get application total messages got. IF those totals did not match we were notified. We did discover that we had a commitment control problem that IBM identified in 5.2. This was a major selling point for upgrading to 5.3. We have not had the problem since the upgrade. Joan Hughes IT Technical Specialist 608-827-3523 Benjamin F. ZhouTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: USA.COM Subject: Re: Message Tracking Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 04/29/2004 08:00 AM Please respond to MQSeries List Roger, you seem want to show them evidence that THEY are nuts. it probably won't work that way. Beside, with the time you need for one or more evidence collector, you could have long taught all of them enough to be good-enough MQ-developers. cheers, Benjamin F. Zhou Technical Specialist MessagingIntegration Supp. Mercedes-Benz USA x.2474 Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeriesSubject: Message Tracking List [EMAIL PROTECTED] C.AT 04/28/2004 11:48 PM Please respond to MQSeries List All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 * [This message and its contents have been scanned for viruses] * 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: Using runmqtmc on Solaris
Jim, Thanks, that was the type of confirmation I was looking for. Ed Jim Ford [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: (bcc: Ed Rutkowski/IT/VGI) Sent by: MQSeriesSubject: Re: Using runmqtmc on Solaris List [EMAIL PROTECTED] N.AC.AT 04/29/2004 11:17 AM Please respond to MQSeries List We use runmqtmc on Solaris 8 with the 5.3 client, and there's no problems at all. We previoulsy used it on 5.2 and Solaris 2.6, and that worked as well. To be honest with you, we never saw the note that said AIX clients only in the Admin manual. Runmqtmc ships with the Solaris client, and we never thought to check if the manual said it was OK to use. I think it's a typo. Ed Rutkowski [EMAIL PROTECTED]To: [EMAIL PROTECTED] GUARD.COM cc: Sent by: MQSeriesSubject: Using runmqtmc on Solaris List [EMAIL PROTECTED] n.ac.at 04/29/2004 09:28 AM Please respond to MQSeries List We are running our MQ software on Solaris 8. Yesterday I discovered that several applications are using the runmqtmc (client trigger monitor) executable to send messages from the client to the server. The problem is that according to the WMQ 5.3 System Guide this is only available on AIX. We have no AIX servers. Has anyone else used runmqtmc successfully on Solaris? Are there gotchas I need to look out for? We are upgrading our clients from 5.2 to 5.3 (our servers are already 5.3) and I am especially worried this may fail once we upgrade. Ed 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: Message Tracking
Hi, So the difference in the data between calls 'before get' and 'after get' would be the data conversion (if the app did a get with convert) ? Or would the be just for timestamping how long the get call took? i.e. because 'before get' call would not have the message data yet. Regards, Roger Lacroix Quoting David C. Partridge [EMAIL PROTECTED]: Yes, that's *exactly* what I mean, so if you do 100 gets followed by a backout, the exit is called 200 times (for before get and after get entries) and then once before the backout and once afterwards. Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Roger Lacroix Sent: 29 April 2004 16:03 To: [EMAIL PROTECTED] Subject: Re: Message Tracking Hi, Hummm, so are you suggesting that under SyncPoint the Api Exit is called twice: once for the get and then again for commit (or back). Hummm, most interesting. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting David C. Partridge [EMAIL PROTECTED]: The API Exit is invoked at MQCMIT and MQBACK time, but you'll have royal fun keeping track of what was committed and backed out it you are logging messages to see what happened. Dave 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: Using runmqtmc on Solaris
We use the client trigger monitor on Windows and Solaris. Also, a trigger monitor never sends messages. It only does MQGETs from the INIT queue. Well, OK, I suppose if it has to put a trigger message to the DLQ it is doing a PUT. But other than that, a TM never sends messages. -Original Message- From: Ed Rutkowski [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 10:28 AM To: [EMAIL PROTECTED] Subject: Using runmqtmc on Solaris We are running our MQ software on Solaris 8. Yesterday I discovered that several applications are using the runmqtmc (client trigger monitor) executable to send messages from the client to the server. The problem is that according to the WMQ 5.3 System Guide this is only available on AIX. We have no AIX servers. Has anyone else used runmqtmc successfully on Solaris? Are there gotchas I need to look out for? We are upgrading our clients from 5.2 to 5.3 (our servers are already 5.3) and I am especially worried this may fail once we upgrade. Ed 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 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
Re: TCP error
The CSS I mention below sits behind a PIX. It took the network group some time to figure out if it was the PIX or the CSS (or even possibly somewhere out on the WAN). In our case (we are an AIX shop) it was most definitely not the PIX. That don't mean a PIX can't do such things, but a PIX was a part of the original problem set and was ruled out. good luck Bill Anderson SITA Atlanta, GA Standard Messaging Engineering WebSphere MQ Service Owner 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ [EMAIL PROTECTED] .AU To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: TCP error [EMAIL PROTECTED] N.AC.AT 04/28/2004 04:18 PM Please respond to MQSeries List Thanks for the many responses! Our MQ servers are behind a PIX firewall in a special DMZ, The clients all run the same application and it is written using the C++ library and disconnect is the last thing called before the app terminates. Also, each object that creates a connection should close the connection when the object gets cleaned up. The information from Bill, show below looks very interesting, does the PIX firewall series do this ? Sid -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 April 2004 12:41 AM To: [EMAIL PROTECTED] Subject: Re: TCP error Don't be so quick to judge the MQ server as the problem. We just recently resolved that (almost) exact problem on AIX. The error code for AIX is AMQ9208, but it is still a tcp/ip reset. We tracked the problem down to a CSS router (Cisco equipment), not the MQ server. The CSS was reclaiming inactive tcp socket connections at an alarming rate and reeking havoc with my MQ servers. To make matters worse, it has a rather complex algorithm for determining if and when to send a reset. If it has plenty of resources available for new connections it may leave things alone. but when the system is busy, look out! cuz its going to get real stingy and kill off anything that has been idle for much less time than a heartbeat interval. I know that don't solve your problem, but you may want to look beyond the MQ server. 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: TCP error
Ahhh, the tangled webs we weave... -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Anderson Sent: Thursday, April 29, 2004 2:40 PM To: [EMAIL PROTECTED] Subject: Re: TCP error The CSS I mention below sits behind a PIX. It took the network group some time to figure out if it was the PIX or the CSS (or even possibly somewhere out on the WAN). In our case (we are an AIX shop) it was most definitely not the PIX. That don't mean a PIX can't do such things, but a PIX was a part of the original problem set and was ruled out. good luck Bill Anderson SITA Atlanta, GA Standard Messaging Engineering WebSphere MQ Service Owner 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ [EMAIL PROTECTED] .AU To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: TCP error [EMAIL PROTECTED] N.AC.AT 04/28/2004 04:18 PM Please respond to MQSeries List Thanks for the many responses! Our MQ servers are behind a PIX firewall in a special DMZ, The clients all run the same application and it is written using the C++ library and disconnect is the last thing called before the app terminates. Also, each object that creates a connection should close the connection when the object gets cleaned up. The information from Bill, show below looks very interesting, does the PIX firewall series do this ? Sid -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 April 2004 12:41 AM To: [EMAIL PROTECTED] Subject: Re: TCP error Don't be so quick to judge the MQ server as the problem. We just recently resolved that (almost) exact problem on AIX. The error code for AIX is AMQ9208, but it is still a tcp/ip reset. We tracked the problem down to a CSS router (Cisco equipment), not the MQ server. The CSS was reclaiming inactive tcp socket connections at an alarming rate and reeking havoc with my MQ servers. To make matters worse, it has a rather complex algorithm for determining if and when to send a reset. If it has plenty of resources available for new connections it may leave things alone. but when the system is busy, look out! cuz its going to get real stingy and kill off anything that has been idle for much less time than a heartbeat interval. I know that don't solve your problem, but you may want to look beyond the MQ server. 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
MQ and TXSeries....
Hi All Onto a fun new projectI am trying to configure CICS in TXSeries to use MQ. I have written small C and Cobol programs to test and they run but abnormally slowseveral minutes to complete. I put some displays in and could see the time was being spent in connecting to the qmanager so I removed the XA switch file from the region and they run normally, sub second as expected. I built the switch file according to the TXSeries CICS Admin docs and what is strange is that when the region starts up, I can see in the console output that the XA connections are established without any errors or warnings. Obviously, the problem must be in the switch file but was wondering if anyone is doing this and whether they came up with any similar problems and what they did to correct. Also, as a general question, I was wondering how many people are using TXSeries and MQ?!? Even if you haven't had this problem, would appreciate to hear your thoughts about this. Thanks Dan Dan Capodicci GE Corporation Vendor Financial Services 10 Riverview Drive, Danbury, CT. 06810 Tel: 203-749-6516, DC: 8*662-6516 [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
Re: Message Tracking
Roger, I don't exactly agree with the link. I have always known an API exit as existing on Distributed platforms, and the API Crossing Exit being the exact same thing on the mainframe but for CICS only. See the following quote from the MQ Glossary and Bibliography Manual: API exit. A user-written program that monitors or modifies the function of an MQI call. For each MQI call issued by an application, the API exit is invoked before the queue manager starts to process the call and again after the queue manager has completed processing the call. The API exit can inspect and modify any of the parameters on the MQI call. The API exit is not supported on WebSphere MQ for z/OS. API-crossing exit. A user written program that is similar in concept to an API exit. It is supported only by WebSphere MQ for z/OS and for CICS applications only. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 12:02 PM To: [EMAIL PROTECTED] Subject: Re: Message Tracking All, I'll correct myself. :)) 'Api Crossing Exit' is the 'Api Exit' that I am referring to. Here is a quick explanation about it from IBM: http://www.mqug.org.uk/anonftp/021131%20-%20MQUTIL.pdf Regards, Roger Lacroix 416-566-7307 Capitalware Inc. http://www.capitalware.biz Quoting Roger Lacroix [EMAIL PROTECTED]: Hi, Am I not sure but I believe 'Api Crossing Exit' is mainframe only. (Anyone!) Although, 'Api Crossing Exit' could be the 'Api Exit' that I am referring to. Is it available on distributed platforms and configure at a queue manager level (and not channel attribute)? Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting [EMAIL PROTECTED]: Roger, The api crossing exit which comes with WMQ addresses most of your concerns. Have you looked at it ? Bullock, Rebecca (CSC) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Subject: Re: Message Tracking Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 04/29/2004 08:49 AM Please respond to MQSeries List Roger, the only thing I have to say is to agree that you want to include at least part of the actual message data. That way, if the programmer has the wrong msgid or correlid or even ends up with duplicates (if, for example, he doesn't clear these fields before his next put), you stand a chance of finding the actual message based on the data itself. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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 communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any
Re: Message Tracking
Hi, That is what I thought, but when IBM publicly posts information that differs, you have to wonder which is correct. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]: Roger, I don't exactly agree with the link. I have always known an API exit as existing on Distributed platforms, and the API Crossing Exit being the exact same thing on the mainframe but for CICS only. See the following quote from the MQ Glossary and Bibliography Manual: API exit. A user-written program that monitors or modifies the function of an MQI call. For each MQI call issued by an application, the API exit is invoked before the queue manager starts to process the call and again after the queue manager has completed processing the call. The API exit can inspect and modify any of the parameters on the MQI call. The API exit is not supported on WebSphere MQ for z/OS. API-crossing exit. A user written program that is similar in concept to an API exit. It is supported only by WebSphere MQ for z/OS and for CICS applications only. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 12:02 PM To: [EMAIL PROTECTED] Subject: Re: Message Tracking All, I'll correct myself. :)) 'Api Crossing Exit' is the 'Api Exit' that I am referring to. Here is a quick explanation about it from IBM: http://www.mqug.org.uk/anonftp/021131%20-%20MQUTIL.pdf Regards, Roger Lacroix 416-566-7307 Capitalware Inc. http://www.capitalware.biz Quoting Roger Lacroix [EMAIL PROTECTED]: Hi, Am I not sure but I believe 'Api Crossing Exit' is mainframe only. (Anyone!) Although, 'Api Crossing Exit' could be the 'Api Exit' that I am referring to. Is it available on distributed platforms and configure at a queue manager level (and not channel attribute)? Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting [EMAIL PROTECTED]: Roger, The api crossing exit which comes with WMQ addresses most of your concerns. Have you looked at it ? Bullock, Rebecca (CSC) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Subject: Re: Message Tracking Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 04/29/2004 08:49 AM Please respond to MQSeries List Roger, the only thing I have to say is to agree that you want to include at least part of the actual message data. That way, if the programmer has the wrong msgid or correlid or even ends up with duplicates (if, for example, he doesn't clear these fields before his next put), you stand a chance of finding the actual message based on the data itself. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this
Re: Message Tracking
I'm gonna go with the info in the Glossary, since I have heard the same definitions from: My IBM rep The IBM Tech Conferance 2 Vendors that use these Exits That link you posted is the only place that contradicts that. Go figure. That link is not dated anywhere that I can see, maybe its just old, before the terms were ironed out Anyway, are you gonna market this little exit at Capitalware? Where will you store all the data? Will there be a GUI to correlate it all? :-) This is slowly evolving into a reinventing of Bristol's Transaction Vision. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 5:07 PM To: [EMAIL PROTECTED] Subject: Re: Message Tracking Hi, That is what I thought, but when IBM publicly posts information that differs, you have to wonder which is correct. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]: Roger, I don't exactly agree with the link. I have always known an API exit as existing on Distributed platforms, and the API Crossing Exit being the exact same thing on the mainframe but for CICS only. See the following quote from the MQ Glossary and Bibliography Manual: API exit. A user-written program that monitors or modifies the function of an MQI call. For each MQI call issued by an application, the API exit is invoked before the queue manager starts to process the call and again after the queue manager has completed processing the call. The API exit can inspect and modify any of the parameters on the MQI call. The API exit is not supported on WebSphere MQ for z/OS. API-crossing exit. A user written program that is similar in concept to an API exit. It is supported only by WebSphere MQ for z/OS and for CICS applications only. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 12:02 PM To: [EMAIL PROTECTED] Subject: Re: Message Tracking All, I'll correct myself. :)) 'Api Crossing Exit' is the 'Api Exit' that I am referring to. Here is a quick explanation about it from IBM: http://www.mqug.org.uk/anonftp/021131%20-%20MQUTIL.pdf Regards, Roger Lacroix 416-566-7307 Capitalware Inc. http://www.capitalware.biz Quoting Roger Lacroix [EMAIL PROTECTED]: Hi, Am I not sure but I believe 'Api Crossing Exit' is mainframe only. (Anyone!) Although, 'Api Crossing Exit' could be the 'Api Exit' that I am referring to. Is it available on distributed platforms and configure at a queue manager level (and not channel attribute)? Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting [EMAIL PROTECTED]: Roger, The api crossing exit which comes with WMQ addresses most of your concerns. Have you looked at it ? Bullock, Rebecca (CSC) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Subject: Re: Message Tracking Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 04/29/2004 08:49 AM Please respond to MQSeries List Roger, the only thing I have to say is to agree that you want to include at least part of the actual message data. That way, if the programmer has the wrong msgid or correlid or even ends up with duplicates (if, for example, he doesn't clear these fields before his next put), you stand a chance of finding the actual message based on the data itself. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix
Re: Message Tracking
Hi Roger What you are trying to do is perception management. For perception management, from my experience, the things that you are going develop will not help. It will take lot of your time in developing and explaining these reports to your newbie developers. If you think by showing all tracing reports to every tom, , and Harry and convince them that there messages aren't lost - you will have a huge battle ahead. By all this, newbie's will confuse and will scare more of the MQ product and it will aggravate the perceptions more. If I were you, I would have taken the other route - ie: talk to your boss, then your VP followed by their VP and before he/she hears their complaint sell the idea that MQ don't loose messages and new comers need some sort of in-house training/orientation to be effective. It isn't that difficult to convince the senior management given the IBM backing and others experiences in this arena. That's how I have dealt it in before, that's how I handle it in future. Anyway keep us posted with your experiences. Cheers Rao Ps: if my boss (and bosses boss) don't have a trust on me, my consultancy won't last long anyway, and I will be looking for somewhere else before it is too late. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: 30 April 2004 6:16 AM To: [EMAIL PROTECTED] Subject: Re: Message Tracking Hi, I would love to do that but it won't fly. They are already confused enough with doing JMS / Java with MQ inside WebLogic. Unless I take over the coding there is no hope in hell of implementing that type of framework. I can just hear the comments: You want to use an abstract layer to call an abstract layer (JMS) to put a message to a queue. No, I think I'll skip that headache. :) Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting David Awerbuch [EMAIL PROTECTED]: Roger, Perhaps as the Messaging Architect you can request that they first develop a messaging API that must be used by all developers. This API, based on the values of environment variables, would be able to log anything and/or everything you might want it to at a particular time. Not only would this externally controlled logging system make a great debugging tool for developers, it would probably prove invaluable in shooting down a real program bug that only raises its ugly head under very specific circumstances and only in production. I have implemented APIs like this for different clients in different messaging / store-and-forward systems more times than I care to remember. Each time, this simple interface has saved our butts during a real production problem. Each time, it proved the messaging system was working flawlessly, and that there was some other problem with the application - complex-conditional logic errors, errant pointers, dynamic static data, and compiler optimization errors, just to name four. Dave A. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 11:16 AM To: [EMAIL PROTECTED] Subject: Re: Message Tracking Hi, I fully agree with you but sadly as the 'Messaging Architect' for one division I do not have the authority to request or mandate anything. I can only recommend things. I have written WMQ Naming Standards documents and WMQ Programming Standards documents for the client but it just goes over the newbie's head. So, this may be a difficult solution but it will give me fewer headaches. :) Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Benjamin F. Zhou [EMAIL PROTECTED]: Roger, you seem want to show them evidence that THEY are nuts. it probably won't work that way. Beside, with the time you need for one or more evidence collector, you could have long taught all of them enough to be good-enough MQ-developers. cheers, Benjamin F. Zhou Technical Specialist MessagingIntegration Supp. Mercedes-Benz USA x.2474 Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeriesSubject: Message Tracking List [EMAIL PROTECTED] C.AT 04/28/2004 11:48 PM Please respond to MQSeries List All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID
Re: Message Tracking
Hello Roger, As I wrote earlier this week, users mostly care about their data, not our CorrelIDs etc. and so I would log CRC32 or some other hash of data (Date, Time, queue name and MsgID would be useful to preserve, of course). In particular, one problem will be to convince users to log MsgIDs, and another will be that even if you manage to do that, they will still be able to mess up (like not cleaning them before MQPUT and so not having them unique). Also, be prepared to give your users a standalone utility to get CRC32 of their data on their side, (or to instruct them , if on Unix, how to run cksum with their data as an argument) -- because they won't probably be willing to change their applications to log CRC32 from there (although if they did that would be most convenient for you to reconciliate their logs with your logs). Of course, checksums only work where no conversions is done.. Hope this will help, Pavel Roger Lacroix [EMAIL PROTECTED]To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeries Subject: Message Tracking List [EMAIL PROTECTED] C.AT 04/28/2004 11:48 PM Please respond to MQSeries List All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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
