Re: Using gsk6cmd to create certificates and key ring files on AI X
I have been using gsk6cmd on AIX (4.3, 5.1) for quite a while. It is a bore but it works. I have never used GUI (I tried but some windows were appearing shrinked to zero size so I dropped). Pavel Lovett, Alan J [EMAIL PROTECTED]To: [EMAIL PROTECTED] COM cc: Sent by: MQSeriesSubject: Re: Using gsk6cmd to create certificates and key ring files on AI List X [EMAIL PROTECTED] n.AC.AT 11/23/2004 05:10 AM Please respond to MQSeries List Bill, That statement does create concerns! Given that gsk6cmd and gsk6man share the same code I translate the statement as meaning little. In the interval between about a year ago and some unknown point in the future, we use gsk6cmd successfully on AIX. In my experience, rely upon JAVA_HOME to point to the Java run-time installed with MQ (/usr/mqm/ssl/jre). Attempting to set up your own class path leads to madness. We use openSSL on a Windows system to cut the PKCS12 file. We import these into a copy of our empty model key repository. When you create one with gsk6cmd, it populates it with popular CA certificates, which we most definitely don't want - we need full control of the CA. Deleting them all is then a once only activity. You might find it useful to trawl the web for general stuff about gsk6cmd. You will notice that there is a history of problems getting that first key repository created. Once past that the problems get easier. Also the AIX documentation of gsk6cmd is somewhat more forthcoming than MQ's. What are your messages? Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Anderson Sent: 22 November 2004 20:06 To: [EMAIL PROTECTED] Subject: Using gsk6cmd to create certificates and key ring files on AIX I have been struggling with setting up SSL on an AIX server running AIX 5.2 and WMQ5.3 CSD07. The IBM security manual only walks you through procedures for using the gsk6ikm which only works with a server that is X-compatible (so you can see the GUI of course). It goes on to say, and I quote, WebSphere MQ does not support the gsk6cmd command. gsk6cmd is the command line version of the ikeyman tool used to create key repositories and certificates. has anyone had success using gsk6cmd on AIX? I have tried, but get various errors depending on how I set up the environment and what command line options I use with the tool. Thanks Bill Anderson SITA Atlanta, GA Standard Messaging Engineering WebSphere MQ Service Owner 770-303-3503 (office) 404-915-3190 (cell) This e-mail contains information which is SITA - Company Confidential All sita.int addresses have changed to sita.aero [EMAIL PROTECTED] http://www.mconnect.aero/ 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 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
Re: Sending a PDF file as MQ payload
Hello Bill, Basically, use MQFMT_NONE in a message format field to avoid character conversions and maybe other smart moves of the beast.. Also, make sure your documents are less than 4 Mb; otherwise, use application-level segmentation or you will have to make sure some set of conditions is met -- to me, it seems easier to break the documents up.. Hope this will help, Pavel Bill Anderson [EMAIL PROTECTED]To: [EMAIL PROTECTED] TA.AERO cc: Sent by: MQSeriesSubject: Sending a PDF file as MQ payload List [EMAIL PROTECTED] n.AC.AT 11/22/2004 03:09 PM Please respond to MQSeries List Our development team asked me if it was possible to send a PDF document as an MQ message. My gut feeling is yes, you can, but I have never done it. anyone out there ever done such a thing? any hints or tips on how to do it? Thanks Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive -- 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
Migration QM data from Solaris to Linux
Hello all, I need to migrate user's queue manager from one platform to another (Solaris to Linux to be precise). Is there some utility or support pac that can help in migrating queue data? For example some utility that can gather all data on one platform to some platform-independent file that can be ftp-ed and easily restored on the other platform (assuming that all queues are already recreated). Another related question: Is saveqmgr the right tool for moving queue manager definition between platforms or should anything be tweaked in the file before restoring from it? Thank you in advance, Pavel David C. PartridgeTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RIMEUR.COM Subject: Re: Creating report messages ends with reason 2035 Sent by: MQSeries List [EMAIL PROTECTED] .AC.AT 09/22/2004 04:03 AM Please respond to MQSeries List When the report is generated, the ReplyToQ queue is opened and the report message put using the authority of the UserIdentifier in the MQMD of the message causing the report, except in the following cases: Exception reports generated by a receiving MCA are put with whatever authority the MCA used when it tried to put the message causing the report. The PutAuthority channel attribute determines the user identifier used. COA reports generated by the queue manager are put with whatever authority was used when the message causing the report was put on the queue manager generating the report. For example, if the message was put by a receiving MCA using the MCA's user identifier, the queue manager puts the COA report using the MCA's user identifier. Applications generating reports should normally use the same authority as they would have used to generate a reply; this should normally be the authority of the user identifier in the original message. So, if this is a remote QM to the originator, then this should be being PUT with the authority of the MCA the originally put it onto the input Q. Whether this authority is enough to write to the TQ to go back depends on the platform and what user was running the MCA. For distributed platforms the user running the MCA will almost always be mqm or equivalent so it should work, but for the 390 system, the authority is defined by the RACF permissions and the value of the setting of PUTAUT on the receiver channel. This is discussed in chapter 15 and 17 of the z/OS System Setup Guide. So my guess is that the receiving system is 390 and that you are running your receiver channels with ALTMCA and that the CHIN is writing OK to the output Q, but when the getter gets the message the only authority left is the ALT part of ALTMCA. Perhaps someone with more experience of 390 access control for MQ can comment it this is a 390 system. Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: 22 September 2004 08:14 To:
Re: Migration QM data from Solaris to Linux
Thanks Bobbee! Will report the results if I have to use it. First, I will try to verify users really need their data :-). Pavel Robert Broderick [EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM cc: Sent by: MQSeries Subject: Re: Migration QM data from Solaris to Linux List [EMAIL PROTECTED] .AC.AT 11/04/2004 12:21 PM Please respond to MQSeries List One trick is to use MO71. You can create your Linux QMGR and then define your Linux and Solaris QMGRS to the tool. Use the tool to move data from one queue at a time to the other. If you have MUCHO data on MUCHO queues this becomes a pain in the arse. Other than that it works well. bobbee From: Pavel Tolkachev [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Migration QM data from Solaris to Linux Date: Thu, 4 Nov 2004 10:19:00 -0500 Hello all, I need to migrate user's queue manager from one platform to another (Solaris to Linux to be precise). Is there some utility or support pac that can help in migrating queue data? For example some utility that can gather all data on one platform to some platform-independent file that can be ftp-ed and easily restored on the other platform (assuming that all queues are already recreated). Another related question: Is saveqmgr the right tool for moving queue manager definition between platforms or should anything be tweaked in the file before restoring from it? Thank you in advance, Pavel David C. PartridgeTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RIMEUR.COM Subject: Re: Creating report messages ends with reason 2035 Sent by: MQSeries List [EMAIL PROTECTED] .AC.AT 09/22/2004 04:03 AM Please respond to MQSeries List When the report is generated, the ReplyToQ queue is opened and the report message put using the authority of the UserIdentifier in the MQMD of the message causing the report, except in the following cases: Exception reports generated by a receiving MCA are put with whatever authority the MCA used when it tried to put the message causing the report. The PutAuthority channel attribute determines the user identifier used. COA reports generated by the queue manager are put with whatever authority was used when the message causing the report was put on the queue manager generating the report. For example, if the message was put by a receiving MCA using the MCA's user identifier, the queue manager puts the COA report using the MCA's user identifier. Applications generating reports should normally use the same authority as they would have used to generate a reply; this should normally be the authority of the user identifier in the original message. So, if this is a remote QM to the originator, then this should be being PUT with the authority of the MCA the originally put it onto the input Q. Whether this authority is enough to write to the TQ to go back depends on the platform and what user was running the MCA. For distributed platforms the user running the MCA will almost always be mqm or equivalent so it should work, but for the 390 system, the authority is defined by the RACF permissions and the value of the setting of PUTAUT on the receiver channel. This is discussed in chapter 15 and 17 of the z/OS System Setup Guide. So my guess is that the receiving system is 390 and that you are running your receiver channels with ALTMCA and that the CHIN is writing OK to the output Q, but when the getter gets the message the only authority left is the ALT part of ALTMCA. Perhaps someone with more experience of 390 access control for MQ can comment it this is a 390 system. Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: 22 September 2004 08:14 To: [EMAIL PROTECTED] Subject: Creating report messages ends with reason 2035 MQ-Guys, I have the following situation: 1. An application APP1 on qmgr MQ1, running as a user mqusr1, creates a message and sends it to a qmgr MQ2. APP1 sets the report options to MQRO_COD + MQRO_EXCEPTION + MQRO_PASS_MSG_ID + MQRO_PASS_CORREL_ID (I think, relevant in my case is only MQRO_COD ). 2. Application APP2 on qmgr MQ2, running as a user mqusr2, reads the message successfully. But when APP2 tries to put the report message, it fails with the reason code 2035 and the message is put to the local DLQ. 3. The user mqusr1
Re: Comparison of MQ monitoring tools
Just to confirm that all horror stories below are all true.. :-) Additionally, the user interface is the most counterintuitive GUI I have ever used. Additionally, now that Candle is bought, there is an uncertainty in terms of what of the product families will evolve better --- or even at all. And it costs a fortune. And still, especially after Candle is bought, TIVOLI seems to be one of few complete and solid solutions, if not the only one. One alternative (especially for those not requiring mainframe platform -- but maybe not exclusively) Nastel's AutoPilot -- see http://www.nastel.com/products/ap_wmq.shtml, http://www.nastel.com/products/ap_wsadmin.shtml. I only saw their demo but I was impressed. And they have a plugin to run it in HP's OpenView environment -- if you see it as an advantage. Hope this will help, Pavel Fred Oddo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: Comparison of MQ monitoring tools [EMAIL PROTECTED] n.AC.AT 11/04/2004 04:23 PM Please respond to MQSeries List Use ITM Or you could shoot yourself,. At lease that will be a less painful... Tivoli is beast. If you are considering ITM (IBM Tivoli Monitoring) anyway. You need to install framework management and ITM sits on top of that. You will need a few servers to implement the product plus a TEC monitor where all the messages are routed to. You need a TEC server, Framework gateway server(s), ITM server(s). How many depends on the size of the environment. Also, you will need a dedicated staff to maintain the monster. On the other hand, if you are a Z/os shop and want a Z/os only solution you could use BMC's Mainview. I think the candle product is called BM Tivoli OMEGAMON XE for WebSphere Good luck... Fred Oddo CICS / MQ Systems Architect 212 855 - 1162 Karla Kirkpatrick [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Fred Oddo/DTCC) Subject:Re: Comparison of MQ monitoring tools 11/04/2004 02:56 PM Please respond to MQSeries List You might want to look at Tivoli Monitoring for MQSeries Karla E. Kirkpatrick MQSeries, System Administrator for Special Events Work: (919) 486-2213 Cell: (919) 824-1574 e-mail: [EMAIL PROTECTED] -- 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
Re: What do MQAdmins read?
Just a hypothesis: IBM's and contributed documentation and their Web site in general, mqseries.net and this mailing list leave too narrow niche for any potential enterpreneur who would think of starting such a publication :-). Also, the stability of the product features might matter.. (I do not mean the whole Websphere, just MQ). Which raises some thoughts about good and bad software and their respective shares of coverage in media ... Pavel Christopher Fryett [EMAIL PROTECTED]To: [EMAIL PROTECTED] FOMAHA.COM cc: Sent by: MQSeriesSubject: Re: What do MQAdmins read? List [EMAIL PROTECTED] .AT 10/18/2004 04:15 PM Please respond to MQSeries List Roger, The EAI Magazine/Journal sometimes covers topics with Websphere products, but ultimately there really isn't any good magazine. So, for you folks who have deep pockets or at least know someone this might be a good opportunity maybe? Journals, I personally have never seen one other than Redbooks or EAI. Would you count a Redbook as a Journal, hmm. The etc... usually is the bathroom break with a MQ manual or user guide. Chris Roger Lacroix [EMAIL PROTECTED] PITALWARE.BIZ To Sent by: [EMAIL PROTECTED] MQSeries Listcc [EMAIL PROTECTED] n.AC.AT Subject What do MQAdmins read? 10/18/2004 11:51 AM Please respond to MQSeries List [EMAIL PROTECTED] n.AC.AT All, Ok, this is a strange question, but what magazines, journals, etc.. do MQ Admins read? I got asked that questions and I couldn't come up with a answer. (I tend to read developer / architect type magazines rather than admin stuff. i.e. JDJ, SD Times, etc...) i.e. If a company had a MQ product specific for MQ Admins (rather than developers or QA Testers) what magazines, journals, etc... should they advertise in to reach those fine people? 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 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
Re: AW: Creating report messages ends with reason 2035
I would try to set MQPMO_SET_IDENTITY_CONTEXT in your app1 and set UserIdentifier to the one of the app2. Just a blind shot -- I have never done this trick before. If it works, it sounds as another MQ security hole to me though :-). Pavel Kleinmanns, HubertTo: [EMAIL PROTECTED] Hubert.Kleinmanns@cc: DREGIS.COMSubject: AW: Creating report messages ends with reason 2035 Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 09/22/2004 05:57 AM Please respond to MQSeries List Dave, thanks for your answer (and also Darren). My MQB runs on Solaris, but the put authority of the receiver MCA is set to DEF. So the UserIdentifier in the message is not checked, when the MCA puts the message to the queue. I now understand my problem, but is there a solution? I found some Put Message Options (e. g. MQPMO_ALTERNATE_USER_AUTHORITY, MQPMO_PASS_IDENTITY_CONTEXT). May I use one of these options, to write the report option using another user id than this one, in the message descriptor? I was told, that unknown users are mapped to user and group nobody. To enable this user for the queue shuld solve the problem (described in the System Administration Guide). I tried it, but this did not work. Any other ideas? Thanks in advance. Hubert -Ursprüngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von David C. Partridge Gesendet: Mittwoch, 22. September 2004 10:03 An: [EMAIL PROTECTED] Betreff: Re: Creating report messages ends with reason 2035 When the report is generated, the ReplyToQ queue is opened and the report message put using the authority of the UserIdentifier in the MQMD of the message causing the report, except in the following cases: Exception reports generated by a receiving MCA are put with whatever authority the MCA used when it tried to put the message causing the report. The PutAuthority channel attribute determines the user identifier used. COA reports generated by the queue manager are put with whatever authority was used when the message causing the report was put on the queue manager generating the report. For example, if the message was put by a receiving MCA using the MCA's user identifier, the queue manager puts the COA report using the MCA's user identifier. Applications generating reports should normally use the same authority as they would have used to generate a reply; this should normally be the authority of the user identifier in the original message. So, if this is a remote QM to the originator, then this should be being PUT with the authority of the MCA the originally put it onto the input Q. Whether this authority is enough to write to the TQ to go back depends on the platform and what user was running the MCA. For distributed platforms the user running the MCA will almost always be mqm or equivalent so it should work, but for the 390 system, the authority is defined by the RACF permissions and the value of the setting of PUTAUT on the receiver channel. This is discussed in chapter 15 and 17 of the z/OS System
Re: Question about Security under v5.3 on Win2K
Hello Sid, Just interested: are you going to write a special program doing PCF to re-create all those objects? I would go for scripting and runmqsc response files.. sounds easier to me. Pavel [EMAIL PROTECTED] .AU To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: Question about Security under v5.3 on Win2K [EMAIL PROTECTED] n.AC.AT 09/21/2004 08:47 PM Please respond to MQSeries List Well bugger me A new twist! It seams that when I upgraded from v5.1 to v5.3, the object authorisations were lost and only queues created since the upgrade work with the new security model (v5.1 was a file based authorisation model). Under v5.3 the file authorisations are stored differently... So now I have to recreate 3000+ queues! (thank god I have my PCF manual at the ready). Sid -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 22 September 2004 9:27 AM To: [EMAIL PROTECTED] Subject: Re: Question about Security under v5.3 on Win2K Well here is a twist, despite applying the latest service pack CSD07, the problem still appears. It was suppose to be fixed in CSD04 (APAR IY34454). I assume early fixes are carried through each CSD release Yes Sid -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 17 September 2004 2:57 PM To: [EMAIL PROTECTED] Subject: Question about Security under v5.3 on Win2K G'Day all, I am trying to allow an NT group to perform a put to a specific local queue using setmqaut and it fails, below is the command and error message, can someone tell me what I am doing wrong! Local Queue name di_results User diclient Group diclients C:dmpmqaut -p diclient profile: SELF object type: qmgr entity: [EMAIL PROTECTED] entity type: principal authority: inq connect dsp setall - - - - - - - - profile: @CLASS object type: qmgr entity: [EMAIL PROTECTED] entity type: principal authority: none C:\qml\logsetmqaut -m QML_MQM -t qmgr -p diclient +inq +connect +dsp +setall The setmqaut command completed successfully. C:\setmqaut -m QML_MQM -t q -n di_results -p diclient -get +put +inq AMQ7085: Object di_results, type q not found. C:\setmqaut -m QML_MQM -t q -n di_results -g diclients -get +put +inq AMQ7085: Object di_results, type q not found. Why ?? 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 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 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
Re: AW: Cannot un-install MQ
Thanks Hubert! It is a nice program to have. Will try to use it when I have a similar program again. In my case though, I am pretty sure that was the services process that was using the DLL because I ununstalled MQ, then rebooted several times but still could not remove DLLs. So the offender would probably be svchost which is not easy to kill :-). Apparently, that version's uninstall did not deregister some services from the registry or something similar.. Maybe some subtle Windows NT bug played there as well.. I had met with a similar problem before couple of times -- of course, I did not have that nice listdll program... Pavel Kleinmanns, HubertTo: [EMAIL PROTECTED] Hubert.Kleinmanns@cc: DREGIS.COMSubject: AW: Cannot un-install MQ Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 09/22/2004 02:42 AM Please respond to MQSeries List Pavel, there is a nice freeware tool called listdlls (the link is http://www.sysinternals.com/ntw2k/freeware/listdlls.shtml) which lists which dlls are used by programs. Just search in the output of listdlls and stop the processes, which use amq*.dll. This should help. Regards Hubert -Ursprüngliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Pavel Tolkachev Gesendet: Dienstag, 21. September 2004 15:34 An: [EMAIL PROTECTED] Betreff: Re: Cannot un-install MQ Hello Mike, To check real Windows ACLs, use CACLS command on NT. As for the problem itself I noticed that couple of DLLs could not be removed when I uninstalled MQ for Windows last time (more than a year ago, so I do not remember much details like versions). I had to add some hack into the registry to remove them on reboot -- otherwise they showed there were in in use state each time I tried to remove them manually. Hope this will help, Pavel Mike Kenny - BCX - Infrastructure To: [EMAIL PROTECTED] Services cc: [EMAIL PROTECTED]Subject: Re: Cannot un-install MQ O.ZA Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 09/21/2004 02:43 AM Please respond to MQSeries List Monique, thanks for the response, but the user is an administrator and is a member of mqm. the problem is not with the user, but with the permissions on the files. All other files have open access, but the file that the uninstaller objects to is missing write permission. (I use cygwin as I am more comfortable with UNIX type tools, not sure what these map to in windows terminology) Mike -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Monique Diaz Sent: Monday, September 20, 2004 7:05 PM To: [EMAIL PROTECTED] Subject: Re: Cannot un-install MQ Mike, I havent tried this myself
Re: Cannot un-install MQ
Hello Mike, To check real Windows ACLs, use CACLS command on NT. As for the problem itself I noticed that couple of DLLs could not be removed when I uninstalled MQ for Windows last time (more than a year ago, so I do not remember much details like versions). I had to add some hack into the registry to remove them on reboot -- otherwise they showed there were in in use state each time I tried to remove them manually. Hope this will help, Pavel Mike Kenny - BCX - Infrastructure To: [EMAIL PROTECTED] Services cc: [EMAIL PROTECTED]Subject: Re: Cannot un-install MQ O.ZA Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 09/21/2004 02:43 AM Please respond to MQSeries List Monique, thanks for the response, but the user is an administrator and is a member of mqm. the problem is not with the user, but with the permissions on the files. All other files have open access, but the file that the uninstaller objects to is missing write permission. (I use cygwin as I am more comfortable with UNIX type tools, not sure what these map to in windows terminology) Mike -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Monique Diaz Sent: Monday, September 20, 2004 7:05 PM To: [EMAIL PROTECTED] Subject: Re: Cannot un-install MQ Mike, I havent tried this myself but I would check the following: Does the user who is trying to uninstall have administrative privileges on the XP machine. Is that user part of mqm user group. Let me know if this helps. Monique Diaz Mike Kenny - BCX - Infrastructure To: [EMAIL PROTECTED] Services cc: [EMAIL PROTECTED]Subject: Cannot un-install MQ O.ZA Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 09/20/2004 08:05 AM Please respond to MQSeries List I decided that my MQ installation is corrupt and that my best bet would be to un-install and re-install. This is on windows XP so I am using Add/Remove programs from Control Panel. Unfortunately the procedure objects to incorrect file permissions on an .rpf file in c:\Config.msi. Each time I attempt the un-install it objects to a different file. Using cygwin's ls -l to check the offending files shows that these files do not have write permission (the others do). As these files appear to be created by the un-install procedure, changing the permissons and re-running does not good. Has anybody come across this before? If so what is the cause/solution? If not any ideas how I can remove MQ from my system? Kind Regards, Mike Kenny Principal Consultant Professional Services Business Connexion (Pty) Ltd Office: +27 (0)11 266 5703 Mobile: +27 (0)83 266 1437 Fax: +27 (0)11 266 5769 Email: [EMAIL PROTECTED] Web Site: www.bcx.co.za NOTICES: 1. This message and any attachments are confidential and intended solely for the addressee. If you have received this message in error, please notify the sender at Business Connexion (Pty) Ltd immediately. Any unauthorised use, alteration or dissemination is prohibited. 2. Business Connexion (Pty) Ltd accepts no liability whatsoever for any loss whether it be direct, indirect or consequential, arising from information made available and actions resulting there from. 3. Please note that Business Connexion only binds itself by way of signed agreements. 'Signed' refers to a hand-written signature, excluding any signature appended by 'electronic communication' as defined in the Electronic Communications and Transactions Act, no. 25 of 2002. 4. Directors: P.A. Watt, B. Mophatlane, A.C. Farthing (British), B. Sithole, I. Mophatlane, M.W. Schoeman. 5. Business Connexion (Pty) Ltd Company Registration Number: 1993/003683/07. 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
Re: Question about Security under v5.3 on Win2K
I do not think so. Windows Shell will eat them up before giving them to the setmqaut.exe (by them I mean double quotes). This may work though (although with no guarantee, I did not try myself): C:\setmqaut -m QML_MQM -t q -n 'di_results' -p diclient -get +put +inq Pavel Potkay, Peter M (ISD, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Re: Question about Security under v5.3 on Win2K Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 09/19/2004 07:10 PM Please respond to MQSeries List Instead of: C:\setmqaut -m QML_MQM -t q -n di_results -p diclient -get +put +inq try: C:\setmqaut -m QML_MQM -t q -n di_results -p diclient -get +put +inq Just a guess. Maybe the command is folding the name to UPPERCASE behind the scenes, and the will stop it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, September 19, 2004 6:44 PM To: [EMAIL PROTECTED] Subject: Re: Question about Security under v5.3 on Win2K No, its di_results... -Original Message- From: Gunter Jeschawitz [mailto:[EMAIL PROTECTED] Sent: Friday, 17 September 2004 5:23 PM To: [EMAIL PROTECTED] Subject: Re: Question about Security under v5.3 on Win2K Am Fr, den 17.09.2004 schrieb [EMAIL PROTECTED] um 6:57: C:\setmqaut -m QML_MQM -t q -n di_results -p diclient -get +put +inq AMQ7085: Object di_results, type q not found. C:\setmqaut -m QML_MQM -t q -n di_results -g diclients -get +put +inq AMQ7085: Object di_results, type q not found. Why ?? There isn't a queue 'di_results' in this queuemanager. Maybe the name is 'DI_RESULTS'. 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 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 -- 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
Re: MMC/Any GUI for administering MQ on AIX
For someone who already owns Tivoli ITM MQ PAC: it offers, besides monitoring,, a powerful remote administration facility. However, the user interface (although formaly it can be called graphical, I guess) is the most counter-intuitive I have ever seen. Just my 2c Pavel Dawson, John [EMAIL PROTECTED]To: [EMAIL PROTECTED] IGROUP.COM cc: Sent by: MQSeries Subject: Re: MMC/Any GUI for administering MQ on AIX List [EMAIL PROTECTED] .AC.AT 09/09/2004 10:09 AM Please respond to MQSeries List Nick, You're correct. But to get the WMQ explorer on the Windows platform, it requires the WMQ server software. So , if there is no need for WMQ on the Windows software, there is no WMQ explorer. Also, the WMQ explorer cannot be used to monitor z/OS queue managers, whereas MO71 can. HTH, John -Original Message- From: Nick Denning [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 8:12 AM To: [EMAIL PROTECTED] Subject: Re: MMC/Any GUI for administering MQ on AIX Does everyone know that you can use wmq explorer on Windows to administer a remote queue manager on another machine. Right click on queue managers in explorer, execute the show queue manager and add in a reference to the remote queue manager you need. You need to configure the appropriate channel and listener on the remote server. That is all in the system administration manuals. Nick -Original Message- From: Mike Davidson [mailto:[EMAIL PROTECTED] Sent: 09 September 2004 13:54 To: [EMAIL PROTECTED] Subject: Re: MMC/Any GUI for administering MQ on AIX MO71 is a great tool for administering MQ. Here's the URL: http://www-1.ibm.com/support/docview.wss?rs=203uid=swg24000142loc=en_UScs=utf-8lang=en Mike Davidson TSYS MQ Tech Support IBM Certified System Administrator - WebSphere MQ V5.3 IBM Certified Solution Designer - WebSphere MQ V5.3 [EMAIL PROTECTED]
Re: Connecting to more than one queue managers on solaris, linux
Thanks eugene, Probably, not in 5.3. This is the error we are getting on Solaris: 2103( MQRC_ANOTHER_Q_MGR_CONNECTED) Child processes would be one option -- but it was decided against it for non-MQ-related reasons. Thanks, Pavel eugene rosenberg [EMAIL PROTECTED]To: [EMAIL PROTECTED] .COMcc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT 09/02/2004 08:46 PM Please respond to MQSeries List Pavel, It was always possible to have connections to various queue managers from UNIX child processes (still one connection per child process) and I did it myself. In the best of my knowledge starting with V5.2 it became possible to have the same type of connections from threads. Even I did not try it myself I am using products that are multithreaded and each thread has it is own connection. In some cases the number of threads is directly defined by the number of local queue managers. Eugene --- Pavel Tolkachev [EMAIL PROTECTED] wrote: Well, for a loopback interface (I mean, when client connects to localhost or 127.0.0.1), it should not call real network drivers. I think it uses some platform-specific IPCs (on solaris, probably streams -- I believe both pipes and local sockets use same underlying mechanisms, on very old Unices it were mbufs) -- and should not be really heavy... Although, the latency will increase due to the agent and some overhead will still be there.. Even when real IP is used, smart TCP stack must not hit the network for local connections. Just thinking aloud.. I have never really tested it with MQ but I did some performance testing with locally bound TCP sockets -- as long as all socket options were set right (especially TCP_NDELAY), the overhead became negligible. Hopefully, IBM got it right :-). Just my 2c Pavel Miller, Dennis [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeries Subject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT 09/01/2004 02:39 PM Please respond to MQSeries List The client connection has a performance disadvantage, mostly because of network overhead. After all, every API request (and any messages it conveys) must pass over the network to get between the MQ client and the qmgr. The server channel agent, acting on behalf of the client, uses local bindings and should experience about the same performance as the application using local bindings. But the exchange of API requests between the MQ client and the server channel agent is extra work. I am not in a position to quantify it, though, and I expect it would depend greatly on your network configuration. -Original Message- From: Gurney, Matthew [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 12:48 AM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux What would the performance difference of using MQClient connections to connect to a local Queue manager on the same Unix host, compared to using a local bindings direct connection to the local Queue manager. I understand that for Pavel's situation, this be be irrelevant, but I am concerned with the general case? Matt. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: 01 September 2004 01:13 To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux I understand your hesitance to use MQ client for such an app. But think about what you are really asking. An app on one server with MQM credentials for other servers? An app on one server with access to MQM internals on another server? Hmmm... I'm sure you know that without MQ-Client, you cannot even connect to a single QMgr across servers, much less multitudes of them. So, if your thinking about monitoring even one qmgr by an app running on a different system, you are talking about some sort of client model, by definition. But it needn't necessarily be the MQ client. You could for example, write a monitoring agent and run it locally on each qmgr. The user interface for your monitoring app is then a client to these agents, requesting services and receiving replies from them. If you are so-inclined, you can even conduct the request/reply exchanges using
Re: Connecting to more than one queue managers on solaris, linux
Yes, the question was about a local app. Pavel Miller, Dennis [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT 09/03/2004 05:11 PM Please respond to MQSeries List But I understood the question was restricted to an application writing to a local queue using local bindings vrs client bindings (i.e., no transmission queue involved). In that case, I think local bindings would always have a performance advantage. The situation for a distributed environment would be much different. And, yes, yes, really tricky. You'd more-often-than-not need to take measurements to know for sure. -Original Message- From: eugene rosenberg [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 5:57 PM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux Dennis, It is really tricky to compare client/server performance with server/server performance. I agree that each application MQ client call would lose in performance compare with application MQ server call but I believe that the total throughput is better with the client/server communication because the number of I/O is low. The message is going directly to destination queue within client/server without be placed and retrieve on/from transmission queue. Eugene --- Miller, Dennis [EMAIL PROTECTED] wrote: The client connection has a performance disadvantage, mostly because of network overhead. After all, every API request (and any messages it conveys) must pass over the network to get between the MQ client and the qmgr. The server channel agent, acting on behalf of the client, uses local bindings and should experience about the same performance as the application using local bindings. But the exchange of API requests between the MQ client and the server channel agent is extra work. I am not in a position to quantify it, though, and I expect it would depend greatly on your network configuration. -Original Message- From: Gurney, Matthew [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 12:48 AM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux What would the performance difference of using MQClient connections to connect to a local Queue manager on the same Unix host, compared to using a local bindings direct connection to the local Queue manager. I understand that for Pavel's situation, this be be irrelevant, but I am concerned with the general case? Matt. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: 01 September 2004 01:13 To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux I understand your hesitance to use MQ client for such an app. But think about what you are really asking. An app on one server with MQM credentials for other servers? An app on one server with access to MQM internals on another server? Hmmm... I'm sure you know that without MQ-Client, you cannot even connect to a single QMgr across servers, much less multitudes of them. So, if your thinking about monitoring even one qmgr by an app running on a different system, you are talking about some sort of client model, by definition. But it needn't necessarily be the MQ client. You could for example, write a monitoring agent and run it locally on each qmgr. The user interface for your monitoring app is then a client to these agents, requesting services and receiving replies from them. If you are so-inclined, you can even conduct the request/reply exchanges using local connections and MQ messages (although, depending on what you are doing, one might question the wisdom of running a monitoring application in-band like that). It is somewhat analagous to how the command server works, only customized to your specific requirements. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 1:31 PM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux Thanks Dennis, This is a low-level monitoring application (requiring mqm credentials, by the way). Making it an MQ client makes running listener or configured a pre-requisite to operate the app even if there is no business purpose for them to be there and creates a whole number of security issues with the too-far-going implications of their possible solutions. I will have to either live with these consequences or go for running several
Re: Connecting to more than one queue managers on solaris, linux
Thanks Eugene, Yes, please let us know your findings. For system management, you may either use the client (the way I do not like), or connect/disconnect each time (the one we have now), or spawn multiple processes or connect to a single QM (you can use dedicated admin qm for that -- another way I kind of fond of) and use intercommunications for others. The options are plenty which by itself tells that no one of them is perfect... Pavel eugene rosenberg [EMAIL PROTECTED]To: [EMAIL PROTECTED] .COMcc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT 09/03/2004 06:21 PM Please respond to MQSeries List Pavel, I will do some research next week. I assume it should work in 5.3. I mentioned product that I am currently using. It is MQ system management product. Several components of it are multithreaded and are keeping connections to all active local queue managers. And I am using it in multithreaded mode on several platforms including SUN Solaris. Eugene --- Pavel Tolkachev [EMAIL PROTECTED] wrote: Thanks eugene, Probably, not in 5.3. This is the error we are getting on Solaris: 2103( MQRC_ANOTHER_Q_MGR_CONNECTED) Child processes would be one option -- but it was decided against it for non-MQ-related reasons. Thanks, Pavel eugene rosenberg [EMAIL PROTECTED]To: [EMAIL PROTECTED] .COMcc: Sent by: MQSeries Subject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT 09/02/2004 08:46 PM Please respond to MQSeries List Pavel, It was always possible to have connections to various queue managers from UNIX child processes (still one connection per child process) and I did it myself. In the best of my knowledge starting with V5.2 it became possible to have the same type of connections from threads. Even I did not try it myself I am using products that are multithreaded and each thread has it is own connection. In some cases the number of threads is directly defined by the number of local queue managers. Eugene --- Pavel Tolkachev [EMAIL PROTECTED] wrote: Well, for a loopback interface (I mean, when client connects to localhost or 127.0.0.1), it should not call real network drivers. I think it uses some platform-specific IPCs (on solaris, probably streams -- I believe both pipes and local sockets use same underlying mechanisms, on very old Unices it were mbufs) -- and should not be really heavy... Although, the latency will increase due to the agent and some overhead will still be there.. Even when real IP is used, smart TCP stack must not hit the network for local connections. Just thinking aloud.. I have never really tested it with MQ but I did some performance testing with locally bound TCP sockets -- as long as all socket options were set right (especially TCP_NDELAY), the overhead became negligible. Hopefully, IBM got it right :-). Just my 2c Pavel Miller, Dennis [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeries Subject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT 09/01/2004 02:39 PM Please respond to MQSeries List The client connection has a performance disadvantage, mostly because of network overhead. After all, every API request (and any messages it conveys) must pass over the network to get between the MQ client and the qmgr. The server channel agent, acting on behalf of the client, uses local bindings and should experience about the same performance as the application using local bindings. But the exchange of API requests between the MQ client and the server channel agent is extra work. I am not in a position to quantify it, though, and I expect it would depend greatly on your network configuration. -Original Message- From: Gurney, Matthew [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 12:48 AM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one
Re: MQ Series JMS SSL Client getting Could not find trusted cert in chain.
Hello Rajesh, Are you sure your certificates are self-signed, (e.g., not signed by your own CA)? If yes, what do you mean by CA? Pavel Rajesh-IT Sharma rajesh-it.sharma+exterTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Sent by: MQSeries List Subject: MQ Series JMS SSL Client getting Could not find trusted cert in [EMAIL PROTECTED] chain. T 08/31/2004 06:13 PM Please respond to MQSeries List Hi, Environment: The server and client are both located on the same Sun Solaris 2.8 box. MQ Series V 5.3 CSD07 Could not find trusted cert in chain. main, SEND SSL v3.0 ALERT: fatal, description = certificate_unknown main, WRITE: SSL v3.0 Alert, length = 2 JMSException thrown javax.jms.JMSException: MQJMS2005: failed to create MQQueueManager for 'localhost:QM_SSL' Linked Exception com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2397 Has anyone encounter this error? I have self-signed certificates and the CA is installed on both client and server and I have CA signed certificate on Client (clients.jks) Any pointer would be highly appreciated. Thank you. Raj 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
Re: Connecting to more than one queue managers on solaris, linux
Thanks Dennis, I am talking about the agent process, which, by the way, has to monitor some other things on the box than MQ at the same time.. I just do not see any reason for running several such agents just because the box has multiple queue managers on it. If we went for several agents, the administration would get significantly more complicated (in fact, the solution we are currently working with is to open and close connection every time we need a data sample from a particular queue manager. Hopefully this won't kill the box.. this far this hasn't) I do not exactly understand your concerns about the app on one server with mqm credentials for other servers. Doesn't any MQ Server Application with mqm credentials have an access to all queue managers on the box? And doesn't any application need mqm authority to perform, for example, PING CHANNEL with PCF command? Our monitoring application has to be trusted -- that's one reason why I do not want to create a channel for it (with mqm credentials) so that someone could try to impersonate it from the network or another account on the same box. Pavel Miller, Dennis [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT 08/31/2004 08:13 PM Please respond to MQSeries List I understand your hesitance to use MQ client for such an app. But think about what you are really asking. An app on one server with MQM credentials for other servers? An app on one server with access to MQM internals on another server? Hmmm... I'm sure you know that without MQ-Client, you cannot even connect to a single QMgr across servers, much less multitudes of them. So, if your thinking about monitoring even one qmgr by an app running on a different system, you are talking about some sort of client model, by definition. But it needn't necessarily be the MQ client. You could for example, write a monitoring agent and run it locally on each qmgr. The user interface for your monitoring app is then a client to these agents, requesting services and receiving replies from them. If you are so-inclined, you can even conduct the request/reply exchanges using local connections and MQ messages (although, depending on what you are doing, one might question the wisdom of running a monitoring application in-band like that). It is somewhat analagous to how the command server works, only customized to your specific requirements. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 1:31 PM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux Thanks Dennis, This is a low-level monitoring application (requiring mqm credentials, by the way). Making it an MQ client makes running listener or configured a pre-requisite to operate the app even if there is no business purpose for them to be there and creates a whole number of security issues with the too-far-going implications of their possible solutions. I will have to either live with these consequences or go for running several instances of the app instead (which is not ideal for my cause, either..). Pavel Miller, Dennis [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT 08/31/2004 04:05 PM Please respond to MQSeries List Yes, you can do it in the server app. Just use the MQ client. A server app from the perspective of the application architecture can be a client from the perspective of MQ. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 10:30 AM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux Thanks David, Is there absolutely no way to do it in the Server app? What is so different between Windows and Unix that you can do it on one but not the other? Thanks, Pavel David C. PartridgeTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RIMEUR.COM Subject: Re: Connecting to more than one queue managers on solaris, linux Sent by: MQSeries List
Re: MQ Series JMS SSL Client getting Could not find trusted cert in chain.
Hello Rajesh, I did almost as you did although I always use ketool to work with jks keystores instead of gsk6cmd. From the error you are getting, the problem can equally be on either client or server side. Make sure that: 1. *both* your truststore and keystore java properties point to the same jks keystore you created (by default, the used truststore will be .cacert or similar). 2. Your server key database uses the certificate signed by the same authority (check the one with the label ibmwebspheremqyour_queue_manager_name, dots translated_to_something Regards, 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
Re: Connecting to more than one queue managers on solaris, linux
Well, for a loopback interface (I mean, when client connects to localhost or 127.0.0.1), it should not call real network drivers. I think it uses some platform-specific IPCs (on solaris, probably streams -- I believe both pipes and local sockets use same underlying mechanisms, on very old Unices it were mbufs) -- and should not be really heavy... Although, the latency will increase due to the agent and some overhead will still be there.. Even when real IP is used, smart TCP stack must not hit the network for local connections. Just thinking aloud.. I have never really tested it with MQ but I did some performance testing with locally bound TCP sockets -- as long as all socket options were set right (especially TCP_NDELAY), the overhead became negligible. Hopefully, IBM got it right :-). Just my 2c Pavel Miller, Dennis [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT 09/01/2004 02:39 PM Please respond to MQSeries List The client connection has a performance disadvantage, mostly because of network overhead. After all, every API request (and any messages it conveys) must pass over the network to get between the MQ client and the qmgr. The server channel agent, acting on behalf of the client, uses local bindings and should experience about the same performance as the application using local bindings. But the exchange of API requests between the MQ client and the server channel agent is extra work. I am not in a position to quantify it, though, and I expect it would depend greatly on your network configuration. -Original Message- From: Gurney, Matthew [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 12:48 AM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux What would the performance difference of using MQClient connections to connect to a local Queue manager on the same Unix host, compared to using a local bindings direct connection to the local Queue manager. I understand that for Pavel's situation, this be be irrelevant, but I am concerned with the general case? Matt. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: 01 September 2004 01:13 To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux I understand your hesitance to use MQ client for such an app. But think about what you are really asking. An app on one server with MQM credentials for other servers? An app on one server with access to MQM internals on another server? Hmmm... I'm sure you know that without MQ-Client, you cannot even connect to a single QMgr across servers, much less multitudes of them. So, if your thinking about monitoring even one qmgr by an app running on a different system, you are talking about some sort of client model, by definition. But it needn't necessarily be the MQ client. You could for example, write a monitoring agent and run it locally on each qmgr. The user interface for your monitoring app is then a client to these agents, requesting services and receiving replies from them. If you are so-inclined, you can even conduct the request/reply exchanges using local connections and MQ messages (although, depending on what you are doing, one might question the wisdom of running a monitoring application in-band like that). It is somewhat analagous to how the command server works, only customized to your specific requirements. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 1:31 PM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux Thanks Dennis, This is a low-level monitoring application (requiring mqm credentials, by the way). Making it an MQ client makes running listener or configured a pre-requisite to operate the app even if there is no business purpose for them to be there and creates a whole number of security issues with the too-far-going implications of their possible solutions. I will have to either live with these consequences or go for running several instances of the app instead (which is not ideal for my cause, either..). Pavel Miller, Dennis [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT
Connecting to more than one queue managers on solaris, linux
Hello all, Is there any way to write a C or C++ Server application (multi-threaded, anyway) that talks to more than one queue manager at the same time (meaning -- keeps open more than 1 connection handles, each to its own queue manager)? I need it on Solaris, Linux and possibly AIX. Documentation says no (http://publibfp.boulder.ibm.com/epubs/html/csqzal09/csqzal091w.htm#HDRCONSCP, 4th paragraph from the bottom) -- but I still hope it may somehow be obsolete information :-). I only need it on MQ 5.3. Anyone tried to overcome this before? How do they monitor multiple QMs on Unix these days? If we use clients, can they be secured without using SSL somehow by just using the fact we only need to connect from the local host? 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
Re: Connecting to more than one queue managers on solaris, linux
Thanks David, Is there absolutely no way to do it in the Server app? What is so different between Windows and Unix that you can do it on one but not the other? Thanks, Pavel David C. PartridgeTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RIMEUR.COM Subject: Re: Connecting to more than one queue managers on solaris, linux Sent by: MQSeries List [EMAIL PROTECTED] .AC.AT 08/31/2004 11:58 AM Please respond to MQSeries List Using MQ Client you can do this - each thread can own a connection to different QM. 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 -- 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
Re: Connecting to more than one queue managers on solaris, linux
Thanks Kelly, It is quite clear now.. will consider all options and make my decision.. Pavel Kelly F. Hickel [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT 08/31/2004 04:57 PM Please respond to MQSeries List I'm sorry for the typo, but the phrase and I would recommend, should most definitely have been and I would NOT recommend. -- Kelly F. Hickel Senior Software Architect MQSoftware, Inc 952.345.8677 [EMAIL PROTECTED] -Original Message- From: Kelly F. Hickel Sent: Tuesday, August 31, 2004 3:48 PM To: 'MQSeries List' Subject: RE: Re: Connecting to more than one queue managers on solaris, linux Just as a pure FYI, and I would recommend that anyone act on this, but at various CSD levels for MQ v5 and V5.1, solaris threaded apps COULD connect to multiple queue managers, even though it was officially not a feature. This not-a-feature seemed to come and go a couple of different times, and I don't know what the current state of it is. As you already know, the only supported platform for this feature is windows, otherwise you need to either use client connections or do sub- processes. -- Kelly F. Hickel Senior Software Architect MQSoftware, Inc 952.345.8677 [EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Pavel Tolkachev Sent: Tuesday, August 31, 2004 3:31 PM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux Thanks Dennis, This is a low-level monitoring application (requiring mqm credentials, by the way). Making it an MQ client makes running listener or configured a pre-requisite to operate the app even if there is no business purpose for them to be there and creates a whole number of security issues with the too-far-going implications of their possible solutions. I will have to either live with these consequences or go for running several instances of the app instead (which is not ideal for my cause, either..). Pavel Miller, Dennis [EMAIL PROTECTED]To: [EMAIL PROTECTED] Wien.AC.AT OM cc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List [EMAIL PROTECTED] n.AC.AT 08/31/2004 04:05 PM Please respond to MQSeries List Yes, you can do it in the server app. Just use the MQ client. A server app from the perspective of the application architecture can be a client from the perspective of MQ. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 10:30 AM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux Thanks David, Is there absolutely no way to do it in the Server app? What is so different between Windows and Unix that you can do it on one but not the other? Thanks, Pavel David C. PartridgeTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RIMEUR.COM Subject: Re: Connecting to more than one queue managers on solaris, linux Sent by: MQSeries List [EMAIL PROTECTED] .AC.AT 08/31/2004 11:58 AM Please respond to MQSeries List Using MQ Client you can do this - each thread can own a connection to different QM. 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 -- 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
Re: MQ CSD07 AIX
Hello Bobbee, At least you can try it. I remember for sure that for one of the previous service packs (CSD06?) it was the requirement for upgrading gsk to uninstall the original package first -- but not for CSD07. For CSD07 AIX , I believe, I fell into the mistake and de-installed it as well -- and then I had to re-install it back (the original gsk) and then upgrade to the CSD07. I did it a couple of months ago and I cannot remember all the details -- too bad, it did not use to be like that... What I do know, however, that if you have some problems with installing CSD (I suggest that you use smitty, BTW), and you are getting a list of failed filesets-prerequisites -- it is sometimes difficult to realize that some lucking [EMAIL PROTECTED]@.rt.base is actually a part of the original product, e.g. gsk, that you just uninstalled (or have never had installed). However, keep in mind, that unless you are trying to force them in, AIX packages are pretty much safe to install and uninstall -- so you can always try installing the package you have lying closest to you and check if it makes prerequisites happy and then uninstall it later if it doesn't. But do not try to force -- better call IBM. Hope this will help, Pavel Robert Broderick [EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM cc: Sent by: MQSeries Subject: Re: MQ CSD07 AIX List [EMAIL PROTECTED] .AC.AT 08/26/2004 12:49 PM Please respond to MQSeries List TNX, I checked, we don't have the Certificate SSL Base installed. I would think I can install the CSD07 with the SSL support and it will add it?? Or do I have to go back and start with installing the origional base product? bobbee From: Pavel Tolkachev [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MQ CSD07 AIX Date: Wed, 25 Aug 2004 18:06:28 -0400 Hello Bobbee, You can use smitty or you can use lslpp, like this: $ lslpp -l | grep gsk gskak.rte 6.0.5.41 COMMITTED AIX Certificate and SSL Base $ or $ lslpp -l | egrep mq|gsk gskak.rte 6.0.5.41 COMMITTED AIX Certificate and SSL Base mqm.Client.Bnd 5.3.0.2 COMMITTED WebSphere MQ Client Bundle mqm.Server.Bnd 5.3.0.2 COMMITTED WebSphere MQ Server Bundle mqm.base.runtime 5.3.0.7 COMMITTED WebSphere MQ Runtime for mqm.base.samples 5.3.0.7 COMMITTED WebSphere MQ Samples mqm.base.sdk 5.3.0.7 COMMITTED WebSphere MQ Base Kit for mqm.client.rte 5.3.0.7 COMMITTED WebSphere MQ Client for AIX mqm.java.rte 5.3.0.7 COMMITTED WebSphere MQ Java Client and mqm.keyman.rte 5.3.0.7 COMMITTED WebSphere MQ Support for GSKit mqm.msg.en_US 5.3.0.7 COMMITTED WebSphere MQ Messages - U.S. mqm.server.rte 5.3.0.7 COMMITTED WebSphere MQ Server mqm.base.runtime 5.3.0.7 COMMITTED WebSphere MQ Runtime for mqm.man.en_US.data 5.3.0.7 COMMITTED WebSphere MQ Man Pages - U.S. $ -- for those who still remembers what egrep and fgrep were :-). Hope this will help, Pavel Robert Broderick [EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM cc: Sent by: MQSeries Subject: MQ CSD07 AIX List [EMAIL PROTECTED] .AC.AT 08/25/2004 05:30 PM Please respond to MQSeries List I have not looked into SMITTY BUT. The CSD07 comes as with and without SSL support. I was not here for the origional install. Can you tell from SMITTY what you have installed or is there another way to find out which version you have on an AIX box?? bobbee _ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement 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
Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmd failed for -type cms GSKit V6.0.5.43 Solaris 2.8
Hello Raj, At least one of our clients runs SSL on Solaris in production and we are about to migrate another one. I am not sure what exactly you are trying to do with importing, namely, what commands do you use? Import actually imports both public and private keys and you have to have the certificate of signing CA already added to your keystore. Hope this will help, Pavel Rajesh-IT Sharma rajesh-it.sharma+exterTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Sent by: MQSeries List Subject: Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmd [EMAIL PROTECTED] failed for -type cms GSKit V6.0.5.43 Solaris 2.8 T 08/26/2004 02:02 PM Please respond to MQSeries List Thank you to all of you who replied to my earlier posting. Ok. I applied CSD07 and I am successfully able to create the certificates. Now, I am stuck at importing the certificates into the qmgr's keys db. I have created two Q Mgrs and able to create certificates for both of them that have been received into the keys db of each queue manager. Then I exported the certificate from both the queue managers into a file (-type pkcs12) and tried to import them ( qm 1's being imported into qm2's key db and vice-versa). However this fails giving me the error - An error occurred while inserting keys to the database. gsk6version information is @(#)ProductName: gsk6e (GoldCoast Build) 0406171803 @(#)ProductVersion: 6.0.5.43 @(#)ProductInfo: 04/06/15.00:00:28.04/06/17.18:11:04 Also, the classpath and path info remains the same as mentioned in the first email. I see messages that Interim fix need to be applied. I have the latest GSkit version running, do I still need to apply the Interim Fix. Finally, is anyone running MQ with SSL on Solaris in Production? Reason I ask this is that I have never had this much gotcha in setting anything with this much trouble and I would like to get a confidence level whether it is worth it at this time, or wait for it to stabilize a bit more -:) Raj Pavel Tolkachev [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 08/19/2004 03:41 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdf ailed for -type cms GSKit V6.0.5.43 Solaris 2.8 Yes, that's what I am saying: I built keystores on AIX and distributed to Solaris :-) Pavel Rajesh-IT Sharma rajesh-it.sharma+exterTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Sent by: MQSeries List Subject: Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdf ailed for [EMAIL PROTECTED] -type cms GSKit V6.0.5.43 Solaris 2.8 T 08/19/2004 02:36 PM Please respond to MQSeries List Pavel, Wouldn't it still be necessary to have a key database on Solaris even if I can create a certificate on AIX. Thank you for the response. I am considering CSD06. Raj 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 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
Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmd failed for -type cms GSKit V6.0.5.43 Solaris 2.8
Hello Raj, Not sure I can help here. You may want to call IBM. One question though: why do you need to move private keys around? Usually, the private key belongs to one and only one principal.. Also, is the key label you use (ibmwebspheremqqm_1) unique in the destination file? Pavel Rajesh-IT Sharma rajesh-it.sharma+exterTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Sent by: MQSeries List Subject: Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmd [EMAIL PROTECTED] failed for -type cms GSKit V6.0.5.43 Solaris 2.8 T 08/26/2004 03:00 PM Please respond to MQSeries List Thanks Pavel for the response. I have already added the Signing CA to the key db of bot the queue manager. That process is all complete. I have also added one signed certificate to each of the qmgr's key db with proper label name as mentioned in the guide. Now, I export the QM_1's signed certificate to be imported into QM_2's Key db using following to commands gsk6cmd -cert -export -db /var/mqm/qmgrs/QM_1/ssl/keys.kdb -pw passw0rd -label ibmwebspheremqqm_1 -type cms -target qm_1.p12 -target_pw passw0rd -target_type pkcs12 Then, import this into the QM_2's key db gsk6cmd -cert -import -file qm_1.p12 -pw passw0rd -type pkcs12 -target /var/mqm/qmgrs/QM_2/ssl/keys.kdb -target_pw passw0rd -target_type cms This is where I encounter the error. Raj Pavel Tolkachev [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 08/26/2004 02:45 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdfailed for -type cms GSKit V6.0.5.43 Solaris 2.8 Hello Raj, At least one of our clients runs SSL on Solaris in production and we are about to migrate another one. I am not sure what exactly you are trying to do with importing, namely, what commands do you use? Import actually imports both public and private keys and you have to have the certificate of signing CA already added to your keystore. Hope this will help, Pavel Rajesh-IT Sharma rajesh-it.sharma+exterTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Sent by: MQSeries List Subject: Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmd [EMAIL PROTECTED] failed for -type cms GSKit V6.0.5.43 Solaris 2.8 T 08/26/2004 02:02 PM Please respond to MQSeries List Thank you to all of you who replied to my earlier posting. Ok. I applied CSD07 and I am successfully able to create the certificates. Now, I am stuck at importing the certificates into the qmgr's keys db. I have created two Q Mgrs and able to create certificates for both of them that have been received into the keys db of each queue manager. Then I exported the certificate from both the queue managers into a file (-type pkcs12) and tried to import them ( qm 1's being imported into qm2's key db and vice-versa). However this fails giving me the error - An error occurred while inserting keys to the database. gsk6version information is @(#)ProductName: gsk6e (GoldCoast Build) 0406171803 @(#)ProductVersion: 6.0.5.43 @(#)ProductInfo: 04/06/15.00:00:28.04/06/17.18:11:04 Also, the classpath and path info remains the same as mentioned in the first email. I see messages that Interim fix need to be applied. I have the latest GSkit version running, do I still need to apply the Interim Fix. Finally, is anyone running MQ with SSL on Solaris in Production? Reason I ask this is that I have never had this much gotcha in setting anything with this much trouble and I would like to get a confidence level whether it is worth it at this time, or wait for it to stabilize a bit more -:) Raj Pavel Tolkachev [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 08/19/2004 03:41 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdf ailed for -type cms GSKit V6.0.5.43 Solaris 2.8 Yes, that's what I am saying: I built keystores on AIX and distributed to Solaris :-) Pavel Rajesh-IT Sharma rajesh-it.sharma+exterTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Sent by: MQSeries List Subject: Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdf ailed for [EMAIL PROTECTED] -type cms GSKit V6.0.5.43 Solaris 2.8
Re: MQ CSD07 AIX
Hello Bobbee, You can use smitty or you can use lslpp, like this: $ lslpp -l | grep gsk gskak.rte 6.0.5.41 COMMITTED AIX Certificate and SSL Base $ or $ lslpp -l | egrep mq|gsk gskak.rte 6.0.5.41 COMMITTED AIX Certificate and SSL Base mqm.Client.Bnd 5.3.0.2 COMMITTED WebSphere MQ Client Bundle mqm.Server.Bnd 5.3.0.2 COMMITTED WebSphere MQ Server Bundle mqm.base.runtime 5.3.0.7 COMMITTED WebSphere MQ Runtime for mqm.base.samples 5.3.0.7 COMMITTED WebSphere MQ Samples mqm.base.sdk 5.3.0.7 COMMITTED WebSphere MQ Base Kit for mqm.client.rte 5.3.0.7 COMMITTED WebSphere MQ Client for AIX mqm.java.rte 5.3.0.7 COMMITTED WebSphere MQ Java Client and mqm.keyman.rte 5.3.0.7 COMMITTED WebSphere MQ Support for GSKit mqm.msg.en_US 5.3.0.7 COMMITTED WebSphere MQ Messages - U.S. mqm.server.rte 5.3.0.7 COMMITTED WebSphere MQ Server mqm.base.runtime 5.3.0.7 COMMITTED WebSphere MQ Runtime for mqm.man.en_US.data 5.3.0.7 COMMITTED WebSphere MQ Man Pages - U.S. $ -- for those who still remembers what egrep and fgrep were :-). Hope this will help, Pavel Robert Broderick [EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM cc: Sent by: MQSeries Subject: MQ CSD07 AIX List [EMAIL PROTECTED] .AC.AT 08/25/2004 05:30 PM Please respond to MQSeries List I have not looked into SMITTY BUT. The CSD07 comes as with and without SSL support. I was not here for the origional install. Can you tell from SMITTY what you have installed or is there another way to find out which version you have on an AIX box?? bobbee _ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement 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
Re: Windows VMware and multiple QMs
Hello Peter, When planning the setup from scratch there are two reasons why I would think of putting each QM on its own machine: 1. I need (or may need in future) different QMs running on different versions of MQ 2. I want to *really isolate* one of another in terms of used resources CPU, memory, disk space, network bandwidth -- and users are willing to pay additional costs inflicted by such non-optimal hardware use. There are other tools to achieve some level of isolation, at least on AIX and Linux (workload managers), but this (different partitions) seems to be the strongest one (also, I have never seen any workload management tools on Windows although I am sure there must be some). Additionally to these reasons, if the system is just being migrated to a new hardware, and the previous setup provided for one QM per machine, it is quite possible that all infrastructure was tied to this 1-1 mapping (configuration database, HA/DR failover, using only default queue manager by applications, using only default listener port 1414, etc.). If any of these is the case, you have to think twice before changing everything. As you are going to VMWare you will probably want to change one thing at a time (first, fight all migration problems, then try to consolidate some or all QMs on one partition and see what new problems it brings in). Other than that, multiple queue managers per machine seem to be potentially more efficient in terms of the resource usage (and consolidation all queue managers to one must be even more efficient :-) -- but this would bring up more availability concerns). Hope this will help, Pavel Potkay, Peter M (ISD, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Windows VMware and multiple QMs Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 08/23/2004 03:38 PM Please respond to MQSeries List If you had 10 QMs on 10 separate Windows servers, and the plan was to consolidate those 10 servers into VMware on one physical box, what would be better? 10 partitions, (or logical servers), each with its own QM, or 1 partition that had 10 QMs? Since all the partitions share the same physical CPUs, I wonder is there any benefit to putting 1 QM per partition versus all in one. One thing I can think of is during upgrade time, you don't have to take all 10 QMs out at the same time if you have a 1 to 1 design. Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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 -- 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
Re: CRTMQM on Solaris 8
Anthony You may want to check your kernel parameters *and hard and soft limits for the number of opened file descriptors* once again... Hope this will help, Pavel Anthony G Allison [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: CRTMQM on Solaris 8 List [EMAIL PROTECTED] n.AC.AT 08/20/2004 08:54 AM Please respond to MQSeries List Good morning Listers, We are setting up a new environment on Sun Solaris V. 8 Websphere MQ V 5.3 CSD 07 I have never run across this problem on other versions of UNIX but when I issue the crtmqm -q qmgrname command i get an 893 error code?? An FDC is created each time the command is issued. Searching the IBM site I find nothing on Solaris and this problem just AIX. Any ideas or suggestions? Anthony Allison Senior Middleware Engineer CSC 1001 G Street Suite 800 WDC, 20001 (202) 824-7938 [EMAIL PROTECTED] This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. -- 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
Re: CRTMQM on Solaris 8
Yes, this looks like an insufficient # of file descriptors... Did you apply all required Solaris patches? There was one, mystically related to LDAP, after which the insufficient # of file descriptors mystically started to matter (before, MQ worked fine with only 256 descriptors despite Quick Beginning's recommendations). Hope this will help, Pavel Anthony G Allison [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: Re: CRTMQM on Solaris 8 List [EMAIL PROTECTED] n.AC.AT 08/20/2004 09:52 AM Please respond to MQSeries List Here is the FDC being generated with the crtmqm command on Solaris 8 +-+ | | | WebSphere MQ First Failure Symptom Report | | = | | | | Date/Time :- Friday August 20 08:19:41 EDT 2004 | | Host Name :- aallison2-2 (SunOS 5.8)| | PIDS :- 5724B4103 | | LVLS :- 530.7 CSD07 | | Product Long Name :- WebSphere MQ for Sun Solaris | | Vendor:- IBM| | Probe Id :- ZF048020 | | Application Name :- MQM| | Component :- zfu_as_searchprincipallist | | Build Date:- May 27 2004| | CMVC level:- p530-07-L040527| | Build Type:- IKAP - (Production)| | UserID:- 1002 (mqm) | | Program Name :- crtmqm | | Process :- 1486 | | Thread:- 0001 | | QueueManager :- TESTQM | | Major Errorcode :- Unknown(16)| | Minor Errorcode :- OK | | Probe Type:- MSGAMQ0016 | | Probe Severity:- 4 | | Probe Description :- AMQ6090: WebSphere MQ
Re: CRTMQM on Solaris 8
Well, for us the problem that looked exactly same was solved after increasing rlim_fd_cur and rlim_fd_max to 2048 and reboot... I believe that was IBM who advised us on the issue. Also, my search for this APAR (IY60895) at http://www-1.ibm.com/support/us/search/index.html does not return any results.. Pavel Justin Fries [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: CRTMQM on Solaris 8 List [EMAIL PROTECTED] n.AC.AT 08/20/2004 12:06 PM Please respond to MQSeries List Hello, Actually, this is a bug in MQ fixed by APAR IY60895. I recommend calling in to get a fix since I don't have a version built at CSD07 at the moment. Best regards, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Pavel Tolkachev [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] 08/20/2004 11:03 AM cc Subject
Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdf ailed for -type cms GSKit V6.0.5.43 Solaris 2.8
Raj, I would recommend upgrading to CSD06 or later. I think I had this problem with CSD05 on Solaris. That time, I ended up with doing gsk6cmd on AIX and distributing files from there as needed. Anyway, if I am not mistaken, you won't be able to use any KDB created with CSD05 or earlier because the root certificates expired on Jan 1st. Hope this will help, Pavel Bullock, Rebecca (CSC) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Subject: Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdf ailed for Sent by: MQSeries -type cms GSKit V6.0.5.43 Solaris 2.8 List [EMAIL PROTECTED] n.AC.AT 08/19/2004 10:56 AM Please respond to MQSeries List Raj, I don't know if this is it, but try using the extension .kdb for the key database. Here's what I used for mine and it worked (gsk at 6.0.5.39); the file extension looks like the only real difference: gsk6cmd -keydb -create -db $dbdir/key.kdb -type cms -stash I'd agree about the doc. It's not too bad (I guess) if you have a gui (at least, there are lots of pictures), but the line command doc leaves a bit to the imagination. -- Rebecca -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 9:58 AM To: [EMAIL PROTECTED] Subject: AW: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdfailed for -type cms GSKit V6.0.5.43 Solaris 2.8 Hi Raj, I strongly recommend, to follow the quick beginnings document. Be sure, that the prerequisites for SSL support are installed. Regards Hubert -Ursprungliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Rajesh-IT Sharma Gesendet: Donnerstag, 19. August 2004 15:27 An: [EMAIL PROTECTED] Betreff: Invalid key database type was found V5.3 CSD05 SSL gsk6cmd failed for -type cms GSKit V6.0.5.43 Solaris 2.8 Hi, I have seen few posts related to this topic on other forums, but haven't found a solution yet. Here is what I am trying to do- Env: Sun Solaris V 2.8 MQ Series V5.3 CSD with mqm-upd05 U487899 GSKit Info: (#)ProductName: gsk6e (GoldCoast Build) 0406171803 @(#)ProductVersion: 6.0.5.43 @(#)ProductInfo: 04/06/15.00:00:28.04/06/17.18:11:04 @(#)CMVCInfo: gsk6e_040615/gsk6e_ikm gsk6e_040615/gsk6e_ssl gsk6e_040615/gsk6e_support gsk6e_040615/gsk6e_cms NOTE: All the required Solaris patches mentioned in memo.ptf is in place. CLASSPATH /opt/mqm/ssl/lib/tools.jar:/opt/mqm/ssl/lib/i18n.jar:/opt/ibm/gsk6/classes/c fwk.zip:/opt/ibm/gsk6/classes/gsk6cls.jar:/opt/mqm/java/lib/com.ibm.mq.jar:/ opt/mqm/java/lib/com.ibm.mqbind.jar:/opt/mqm/java/lib/com.ibm.mqjms.jar:/opt /mqm/java/lib/fscontext.jar:/opt/mqm/java/lib/ldap.jar:/opt/mqm/java/lib/pro viderutil.jar:/opt/mqm/java/lib/jms.jar:/opt/mqm/java/lib/jndi.jar:/opt/mqm/ java/lib/jta.jar:/opt/mqm/java/lib/connector.jar:. PATH /opt/mqm/ssl/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/EMCpower/bin:/etc:/opt/m qm/java/lib:/data/oracle/product/8.1.7.4/bin:. JAVA_HOME=/opt/mqm/ssl Problem: Creation of Key database of type cms failed: $gsk6cmd -keydb -create -db keys -pw passw0rd -type cms -expire 3660 -stash Invalid key database type was found. Other Things Tried (to prove that I am trying my best to get this thing to work) a. Able to create keydb of type jks - Proves that GSKit is installed and works b. Used -covert option to convert the jks db to cms type. To see if the -create option only has this problem. But, it failed giving the same error too. Invalid key database type was found. Anyone has tried and succeeded in doing this - please provide some pointer as to what is wrong. IBM documentation on GSKit is bare minimum... Thank you. Raj 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
Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdf ailed for -type cms GSKit V6.0.5.43 Solaris 2.8
Yes, that's what I am saying: I built keystores on AIX and distributed to Solaris :-) Pavel Rajesh-IT Sharma rajesh-it.sharma+exterTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Sent by: MQSeries List Subject: Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdf ailed for [EMAIL PROTECTED] -type cms GSKit V6.0.5.43 Solaris 2.8 T 08/19/2004 02:36 PM Please respond to MQSeries List Pavel, Wouldn't it still be necessary to have a key database on Solaris even if I can create a certificate on AIX. Thank you for the response. I am considering CSD06. Raj 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
Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdf ailed for -type cms GSKit V6.0.5.43 Solaris 2.8
Hello Raj, Yes, you got it. BTW, the latest CSD is CSD07 if I am not mistaken. Pavel Rajesh-IT Sharma rajesh-it.sharma+exterTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Sent by: MQSeries List Subject: Re: Invalid key database type was found V5.3 CSD05 SSL gsk6cmdf ailed for [EMAIL PROTECTED] -type cms GSKit V6.0.5.43 Solaris 2.8 T 08/19/2004 04:03 PM Please respond to MQSeries List Pavel, Okay, so you have created the kdb on the AIX and instead of extracting certificates and importing it into Solaris kdb ( to avoid the -create db command on Solaris). You took the whole kdb from AIX to Solaris. I would like to go Solaris CSD06 route. Thank you. Raj 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
stunnel older MQ
Hello all, Does anyone have an experience or just thoughts about securing MQ TCP communication channels using stunnel? It is possible that for some more time many applications here will run on older versions of MQ (including 2.1), where SSL is not available. Are there any known snags? Part of the question is that IBM is often cagey about the way how TCP connection works under the hood: on the surface, it looks like a classic TCP communication with a connection to a fixed port, which should work with stunnel just fine -- but I cannot not be sure they do not open some additional connections in course of communications or do something else that may affect the plan. Any your thoughts will be appreciated. Thank you, Pawvel -- 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
Re: MQ manuals
Hello Chris, This is just kind of ISBNs. What scheme would you expect from those? I usually put each file in the separate directory with the appropriate name; I put the different versions of the same document into the same directory; usually it is easy to guess by the document name which one is newer :-). I do not feel comfortable renaming documents named by IBM because I consider the original name as another search or reference key (e.g. for searching on the Web or talking to IBM support). My 2c Pavel Smith, Christopher N. (MDCH) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: ICACMG.COM Subject: Re: MQ manuals Sent by: MQSeries List [EMAIL PROTECTED] AT 08/13/2004 03:22 PM Please respond to MQSeries List Speaking of MQ manuals. Is there some secret in the naming scheme for the pdf files that someone could clue me in on? I renamed them to something human readable after I downloaded them, but I am curious. -Chris -- Christopher Smith Logica Computer Operator Energy Utilities 617-476-8139 [EMAIL PROTECTED] North America -Original Message- From: Nick Dilauro [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 5:46 PM To: [EMAIL PROTECTED] Subject: MQ manuals Could someone please direct me to the IBM web page for manuals. I lost my previous links. I tried searching the IBM site, but it's the worst thing I've ever encountered on the Web. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -- 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
Re: MaxChannels - How high can you go?
You may want to think of the maximum number of TCP connections your box can handle (in particular, if you open too much from the same client to a server, you can get problems on the client site due to the exhausted ephemeral port numbers). On a server, you may not have exactly this problem, but still each connection takes some memory (I am not sure how much but I guess more than 36K), too, and for the stalled channels, TIME_WAITing connections will continue to hold their memory till they are timed out... Just 2c Pavel Potkay, Peter M (ISD, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Re: MaxChannels - How high can you go? Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 08/10/2004 05:27 PM Please respond to MQSeries List Hi Matt, yeah I was reading that and saw those big numbers. On Table 16, they have the MaxChannels set to 50,000! But I didn't see any advice on calculating what the biggest number can safely be. The only thing I can see is that an open queue takes 36K of memory. So do I assume 2 open queues for a client connection (request queue / reply queue) and then work the numbers that way Or does the connection itself have additional overhead? -Original Message- From: Gurney, Matthew [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 2:40 PM To: [EMAIL PROTECTED] Subject: Re: MaxChannels - How high can you go? Peter, I believe the main limiting factor is memory and cpu. There is an example in the MQ5.3 Windows 2000 Performance Report of 11,500 Client channels, see page 30. Be careful to check the fine print though, IBM have a habit of quoting performance figures for trusted connections, which while providing better performance, are rarely sensible in a production environment. ftp://ftp.software.ibm.com/software/integration/support/supportpacs/individu al/mp78_2000.pdf Matt. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (ISD, IT) Sent: 10 August 2004 14:52 To: [EMAIL PROTECTED] Subject: MaxChannels - How high can you go? How do you go about determining what the highest value you can put on a Queue Manager's MaxChannels parameter? Is there a formula to use based on your setup that will give you the largest number you can safely put there? (I am thinking in terms of instances of SVRCONN channels running at the same time.) The particular machine I am wondering about is a Windows 2000 server with 2 GIG of memory. 5.3 CSD04. Are certain hardware/OSs better suited to handle huge numbers of concurrent MQClient connections? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == 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 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
Continuous forwarding of priority queue to a non-priority queue
Hello all, One of my clients has a requirement to my application, which by its design and specification cannot properly process the queue where prioritized messages can be put, to process messages in accordance with their priorities. I figured out that the most rational way to meet it would be to just let MQ to prioritize the messages in some queue with MSGDLVSQ(PRIORITY) and transactionally forward all messages to an additional queue with MSGDLVSQ(FIFO) from where my application could then work. For performance reasons I think it is probably better for this new forwarding application to be server application. For the administration convenience and robustness, I think it might better be a triggered process rather than a standalone daemon. I need help with two questions: 1. Does my solution outlined above make sense? Especially -- what are pros and contras and gotchas for making it a triggered process (I have never written one before)? 2. Isn't there something around ready, like a service pack for doing this type of work? One requirement I feel I will have to consider is that the second queue must not be deep, otherwise, if the downstream process takes too long, the messages of different original priority will pile up in the secondary queue and the client will not be sastisfied with how we actually obey that original priority. So, the solution must properly process the destination queue is full condition. Thank you, Pavel Paul Clarke [EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM cc: Sent by: MQSeriesSubject: Re: downloading MO71 support pac List [EMAIL PROTECTED] n.AC.AT 07/22/2004 09:29 AM Please respond to MQSeries List Dan, Is it possible you're using the old webpage. The SupportPacs have been re-arranged recently. I've just tried it from http://www-1.ibm.com/support/docview.wss?rs=203uid=swg24000142loc=en_UScs=utf-8lang=en and it seems to work fine for me. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Capodicci, Dan (GE Commercial Finance) To [EMAIL PROTECTED] [EMAIL PROTECTED] .COM cc Sent by: MQSeries List Subject [EMAIL PROTECTED] downloading MO71 support pac N.AC.AT 20/07/2004 15:00 Please respond to MQSeries List Hi After having read so many positive things recently about the MO71 support pac, I decided to download it and take a look. But of course, it is never that easy :) As I am trying to download it by clicking on the link, I get the license acceptance window which I respond to accept, then I get a Not Authorized page ?!?!?!?!?!??!?!? I have only done this about a million times over the years (although it has been a while since the last) and never had this happen. Has something changed that I missed?!? Any clues about what I can do to download this support pac?!?!? Thanks Dan 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 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
Re: Continuous forwarding of priority queue to a non-priority queue
Hello T.Rob, Thank you and Rick for the insights on triggering. My plan was to trigger on MQTT_FIRST and then serve the queue continuously in a loop. If the downstream queue becomes full (let us say, its MAXDEPTH is 10 messages), then my application would wait for it to have, say, 5 free slots and then continue forwarding. While it would wait, arriving messages would be piling on the first QUEUE in the order according to their priority, so that they would go to the FIFO queue in this order, too). Would this work as I think it should (i.e., obey the priority, except for maybe last 10 messages) or am I missing something here? My understanding is that, even if my application were working from PRIORITY queue, and the processing were really fast, the messages would have been processed in a FIFO order, not according to the priority (say, if the CURDEPTH of the queue is always 1 or 0). As I said in the previous e-mail, the reason for using triggering would be to avoid the administration hassle for my own continuously running application (a daemon). After reading the doc, I got a doubt on how reliable triggering really is. If, for some reason, the triggered application crashes without calling MQCLOSE (for the sake of example, let us say it is killed with kill -9, on Unix), and the message arrives to the application queue before the crash but after the last issued MQGET, would the trigger message be sent and the triggered application re-started or the message will stuck until the next message arrives? Thank you, Pavel Wyatt, T.rob [EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeries Subject: Re: Continuous forwarding of priority queue to a non-priority queue List [EMAIL PROTECTED] C.AT 08/06/2004 10:19 AM Please respond to MQSeries List Pavel, If I understand you correctly, you would deliver the messages first to a queue with MSGDLVSQ(PRIORITY) which triggers a job to them move the messages to a FIFO queue. The only problem I can see with that is that, unless the triggered job is r e a l s l o w, or unless you trigger on depth, the messages still arrive in the FIFO queue in the same order they arrived on the PRIORITY queue. This is because the QMgr can't sort the messages by priority unless they are allowed to first build in the queue. You didn't mention whether your app would trigger on depth or not so maybe you considered this already. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel Tolkachev Sent: Thursday, August 05, 2004 12:16 PM To: [EMAIL PROTECTED] Subject: Continuous forwarding of priority queue to a non-priority queue Hello all, One of my clients has a requirement to my application, which by its design and specification cannot properly process the queue where prioritized messages can be put, to process messages in accordance with their priorities. I figured out that the most rational way to meet it would be to just let MQ to prioritize the messages in some queue with MSGDLVSQ(PRIORITY) and transactionally forward all messages to an additional queue with MSGDLVSQ(FIFO) from where my application could then work. For performance reasons I think it is probably better for this new forwarding application to be server application. For the administration convenience and robustness, I think it might better be a triggered process rather than a standalone daemon. I need help with two questions: 1. Does my solution outlined above make sense? Especially -- what are pros and contras and gotchas for making it a triggered process (I have never written one before)? 2. Isn't there something around ready, like a service pack for doing this type of work? One requirement I feel I will have to consider is that the second queue must not be deep, otherwise, if the downstream process takes too long, the messages of different original priority will pile up in the secondary queue and the client will not be sastisfied with how we actually obey that original priority. So, the solution must properly process the destination queue is full condition. Thank you, Pavel Paul Clarke [EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM cc: Sent by: MQSeriesSubject: Re: downloading MO71 support pac List [EMAIL PROTECTED] n.AC.AT 07/22/2004 09:29 AM Please respond to MQSeries List Dan, Is it possible you're using the old webpage. The SupportPacs
Re: Qmgr Discovery
Bobbee, Just hook up your script to Tivoli or other monitoring system that is approved by security in your company and your security issues are gone .. to someone else :-). Seriously, you probably do not want to write all this zoo of paging, mailing and escalating rules that your enterprise monitoring system provides (and your clients expect to enjoy). Pavel Robert Broderick [EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM cc: Sent by: MQSeries Subject: Re: Qmgr Discovery List [EMAIL PROTECTED] .AC.AT 08/04/2004 08:10 AM Please respond to MQSeries List Yes, Have your MQ admin send you an EMAIL! (tee hee hee). Unfortunately there isn't. Some of the after market products (ie QPASA, etc), once their agents are on a box, will auto-discover a QMGR. Other than that there is no method. NOWfor the active enthusiastic, it would not be so hard to write a shell or PERL script that would query the box looking for new QMGRS. You could have these scripts installed as a normal box setup by the ADMINs and it could notify a group EMAIL with the particulars of the QMGR. Is this a security issue...MAYBE, BUT... bobbee From: Isabella Shen [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Qmgr Discovery Date: Tue, 3 Aug 2004 14:18:51 -0700 Hi All, Is there a way to get notified when a queue manager is created for all the platforms? Thanks. __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail 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 _ Don t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/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 -- 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
Re: Message under cursor
Hello T.Rob: I still believe you are missing my point here: So after getting a message with MQGMO_MSG_UNDER_CURSOR, the cursor does not move nor does it point to a retrievable message. I have never argued that, I just said it was not documented. IMHO, that the MQGETting with MQGMO_MSG_UNDER_CURSOR does not affect the cursor position is worth of explicit mentioning in the documentation rather than relying on the assumption that *all* other possible ways of moving cursor are described elsewhere. I explicitly asked whether Roger was using MQGMO_MSG_UNDER_CURSOR or not in his 2nd scenario. Such as he was not, what happens in the scenario 2 is the expected behavior, (I have not look at the scenario 3 yet). I have to admit I also made an assumption -- that Roger probably used MQGMO_MSG_UNDER_CURSOR -- but that seemed to me pretty logical -- otherwise why would he hope to get messages from the middle of the queue with simple MQGET? As for grouping, segmentation etc. I just believe whether the selected way can be called 'poor' or not depends exclusively on whether or not the behavior expectations agree with what the documentation says -- as long as the documentation is in a way complete -- which for MQ I beleive it almost always is. Just my 2c, Pavel Roger Lacroix [EMAIL PROTECTED]To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeries Subject: Re: Message under cursor List [EMAIL PROTECTED] C.AT 08/03/2004 01:41 AM Please respond to MQSeries List T.Rob, Excellent. Very well said. I hope Bank of America pays you well. :)) For those that were interested in the GMO settings, I have attached 3 code C snippets that will demonstrate the 3 scenarios that I listed in my previous email. Just to summarize what I have learned from these 3 test scenarios: - Originally, when I was doing my testing, I thought that the 'Get message under cursor' call moved the Destructive Get cursor. I was wrong. It uses the Browse cursor. Basically, I was wondering if anyone knew of a trick to get it to move (except for specifying a search criteria). But it appears there is none. - Therefore, if I want to delete messages # 5,6 7 (not knowing the MsgId or CorrelId) in a queue with 10 messages, I will have to browse one by one until I get to # 5. Then use Get message under cursor, followed by Browse Next then Get message under cursor, etc... In a couple of weeks, I will be making an announcement and my questions and test scenarios will become clear. 'Crack' - there's the whip, now back to coding and documentation. Oh god I hate writing documentation!!! :)) Regards, Roger Lacroix At 04:06 PM 8/2/2004, you wrote: Hi Pavel, I think I have to address these in context to see below... Well, although this is true that there is no direct controls of the cursor, the documentation is specific enough about the behavior of the cursor. It calls it browse cursor and explains how exactly the behavior of MQGET with MQGMO_MSG_UNDER_CURSOR, MQGMO_BROWSE_MSG_UNDER_CURSOR etc.depends on this cursor's position. Ok, with you so far... What it does not explain is what happens to the cursor after getting a message with MQGMO_MSG_UNDER_CURSOR The manual lists only two ways to move the cursor: The message pointed to by the browse cursor is the one that was last retrieved using either the MQGMO_BROWSE_FIRST or the MQGMO_BROWSE_NEXT option. Since the cursor is moved only by a browse, a successful destructive GET points to a non-retrievable message. The manual says that If the browse cursor is not currently pointing to a retrievable message, an error is returned by the MQGET call. So after getting a message with MQGMO_MSG_UNDER_CURSOR, the cursor does not move nor does it point to a retrievable message. -- and Roger's experiments seem to show some contradictory behavior -- although he has not confirmed all the MQGMO options he used in every scenario yet. When he browsed to a message and then issued non-browse GET calls, the messages were delivered from the head of the queue. When he used MQGMO_BROWSE_NEXT followed by MQGMO_MSG_UNDER_CURSOR he got the target messages. The only contradiction I saw was an expectation that a non-browse GET would honor the browse cursor and that doing a non-browse GET would advance the browse cursor. But the manual contains a paragraph that says Note that the browse cursor is not moved by nonbrowse MQGET calls using the same Hobj handle. This is why I thought Roger was seeing the correct and expected behavior all along. BTW, you mentioned that using priorities may make the cursor concept 'abstract' but priorities are almost ignored when you use MQGMO_BROWSE_NEXT; basically, you will never get a
Re: Message under cursor
Hello Sid, The way I use in a similar application that is working in many environments for many years and is supposed to meet the guaranteed messaging contract (potentially with duplicates though so it is not exactly transactional)) is to browse to the next message first, get msgId and then delete it with MQMO_MATCH_MSG_ID. I have to delete from the different thread, so I could not experiment with the deletion using MQGMO_MSG_UNDER_CURSOR thing although I thing this must work under some conditions (e.g. if you take care of concurrency et al -- see T.Rob's e-mail for more potential anomalies). I mean the sequence of MQGET calls with intermittent MQGMO_BROWSE_NEXT and MQGMO_MSG_UNDER_CURSOR. Hope this will help, Pavel [EMAIL PROTECTED] .AU To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: Message under cursor [EMAIL PROTECTED] n.AC.AT 08/03/2004 02:08 AM Please respond to MQSeries List Howdy all, I am about to change the way I collect messages in all my major processing applications where message loss is not acceptable (I am using c++), I want to change to the browse, process and if successful, then delete the currently browsed message, then move to the next So which scenario do I use ? Sid -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 August 2004 3:42 PM To: [EMAIL PROTECTED] Subject: Re: Message under cursor T.Rob, Excellent. Very well said. I hope Bank of America pays you well. :)) For those that were interested in the GMO settings, I have attached 3 code C snippets that will demonstrate the 3 scenarios that I listed in my previous email. Just to summarize what I have learned from these 3 test scenarios: - Originally, when I was doing my testing, I thought that the 'Get message under cursor' call moved the Destructive Get cursor. I was wrong. It uses the Browse cursor. Basically, I was wondering if anyone knew of a trick to get it to move (except for specifying a search criteria). But it appears there is none. - Therefore, if I want to delete messages # 5,6 7 (not knowing the MsgId or CorrelId) in a queue with 10 messages, I will have to browse one by one until I get to # 5. Then use Get message under cursor, followed by Browse Next then Get message under cursor, etc... In a couple of weeks, I will be making an announcement and my questions and test scenarios will become clear. 'Crack' - there's the whip, now back to coding and documentation. Oh god I hate writing documentation!!! :)) Regards, Roger Lacroix At 04:06 PM 8/2/2004, you wrote: Hi Pavel, I think I have to address these in context to see below... Well, although this is true that there is no direct controls of the cursor, the documentation is specific enough about the behavior of the cursor. It calls it browse cursor and explains how exactly the behavior of MQGET with MQGMO_MSG_UNDER_CURSOR, MQGMO_BROWSE_MSG_UNDER_CURSOR etc.depends on this cursor's position. Ok, with you so far... What it does not explain is what happens to the cursor after getting a message with MQGMO_MSG_UNDER_CURSOR The manual lists only two ways to move the cursor: The message pointed to by the browse cursor is the one that was last retrieved using either the MQGMO_BROWSE_FIRST or the MQGMO_BROWSE_NEXT option. Since the cursor is moved only by a browse, a successful destructive GET points to a non-retrievable message. The manual says that If the browse cursor is not currently pointing to a retrievable message, an error is returned by the MQGET call. So after getting a message with MQGMO_MSG_UNDER_CURSOR, the cursor does not move nor does it point to a retrievable message. -- and Roger's experiments seem to show some contradictory behavior -- although he has not confirmed all the MQGMO options he used in every scenario yet. When he browsed to a message and then issued non-browse GET calls, the messages were delivered from the head of the queue. When he used MQGMO_BROWSE_NEXT followed by MQGMO_MSG_UNDER_CURSOR he got the target messages. The only contradiction I saw was an expectation that a non-browse GET would honor the browse cursor and that doing a non-browse GET would advance the browse cursor. But the manual contains a paragraph that says Note that the browse cursor is not moved by nonbrowse MQGET calls using the same Hobj handle. This is why I thought Roger was seeing the correct and expected behavior all along. BTW, you mentioned that using priorities may make the cursor concept 'abstract' but priorities are almost ignored when you use MQGMO_BROWSE_NEXT; basically, you will never get a higher priority message until you reset the cursor,
Re: Message under cursor
Hello Michael, I feel I am missing a lot of messages as well although not as many as you. As for the syncpoint solution, my application needs to browse and remove from different threads. Syncpoints do not work well between thread because they are local to single-threaded MQHCONN handle -- but please let me know if I am mistaken.. Also, the following situation is possible: 1. 1st message has been browsed 2. 2nd message has beeen browsed 3. 1st message has been asynchronously processed, successfully 4. 2nd message could not be processed asynchronously. In which point I need to have removed the 1st message but not the 2nd one. This does not feet well into the transactional model (the example is simplified, the idea is that, from application's point of view, every single message must be processed transactionally, meaning, either processed successfully and removed or not removed, but application people do not need one message to wait for another and, for the sake of performance, processing is going on in a separate thread). Also, working with a non-transactional MQ client is the requirement :-). I am not sure if any or all of these conditions are applicable to Sid's application, of course. Pavel Michael Dag [EMAIL PROTECTED]To: [EMAIL PROTECTED] ET.NL cc: Sent by: MQSeriesSubject: Re: Message under cursor List [EMAIL PROTECTED] n.AC.AT 08/03/2004 05:59 PM Please respond to Michael.Dag This is the last message I got from the list, anyone else experiencing a 'silent' listserver or is it just me? Michael -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED] Roger Lacroix Verzonden: Sunday, August 01, 2004 4:18 AM Aan: [EMAIL PROTECTED] Onderwerp: Re: Message under cursor Hi Darren, My 3 scenarios that I have listed are not from a guess but from me running code. So, those are real results. There are 2 cursors available to the application when they open a queue for input: (1) Browse Cursor (2) Destructive Get Cursor. What I am trying to figure out is: How do you move the destructive get cursor? i.e. How do I position the destructive get cursor at message #5 without first deleting messages #1,2,3 and 4? Regards, Roger Lacroix At 04:32 PM 7/31/2004, you wrote: I haven't tried it... but Bobbee's scenario 2 looks like the one it should be to me - between the get_msg_under_cursors, you have to do a browse next to reposition the cursor at the msg you are really interested in. re: the detructive get under cursor, the APR clearly states that the cursor is not moved... okay, it clearly states it amidst a lot of other stuff it is clearly stating as well :) Regards Darren. - Original Message - From: Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 31, 2004 5:05 PM Subject: Re: Message under cursor Hi, Actually, Peter and I have been having a long discussion about it over at mqseries.net . http://www.mqseries.net/phpBB2/viewtopic.php?p=67451#67451 Here's a summary of what I have discovered. Please note the difference between 'Destructive Get' and 'Destructive Get message under cursor'. Here's the layout without a loop structure. Assume 10 messages in the queue for each test scenario. Scenario #1: Open Queue Browse First - returns #1 Browse Next - returns #2 Browse Next - returns #3 Browse Next - returns #4 Browse Next - returns #5 Browse Next - returns #6 Destructive Get message under cursor - - returns #6 Browse Next - returns #7 Browse Next - returns #8 Browse Next - returns #9 Browse Next - returns #10 Browse Next - returns 2033 - no more messages Close Queue Scenario #2: Open Queue Browse First - returns #1 Browse Next - returns #2 Browse Next - returns #3 Browse Next - returns #4 Browse Next - returns #5 Browse Next - returns #6 Destructive Get message under cursor - - returns #6 Destructive Get - returns #1 Destructive Get - returns #2 Destructive Get - returns #3 Destructive Get - returns #4 Destructive Get - returns #5 Destructive Get - returns 6th message in queue originally #7 Destructive Get - returns 7th message in queue originally #8 Destructive Get - returns 8th message in queue originally #9 Destructive Get - returns 9th message in queue originally #10 Destructive Get - returns 2033 - no more messages Close Queue If I don't stop it after a particular number of messages then the above happens (i.e. only destructively get 5 messages). Scenario #3: Open Queue Browse First - returns #1 Browse Next - returns #2 Browse Next - returns #3 Browse Next - returns #4 Browse Next - returns #5 Browse Next - returns #6
Re: Message under cursor
Hello Roger, The doc does not say what is supposed to happen to cursor after getting a messages with MQGMO_MSG_UNDER_CURSOR. It says, however, that If the browse cursor is not currently pointing to a retrievable message, an error is returned by the MQGET call. and it says approximately same for using MQGMO_BROWSE_MSG_UNDER_CURSOR (The call fails if .. [snipped]...or if the message that was under the browse cursor has since been retrieved destructively). From your scenario #1 it seems that the cursor actually moves to the next message by using MQGMO_MSG_UNDER_CURSOR which means, IMHO, that you must have gotten the next message after the removed one in your scenario #2 as well as in #1 *but only if you continue using MQGMO_MSG_UNDER_CURSOR in your subsequent MQGET calls*. If you are doing that and you are getting messages starting from the 1st one, I would think this is a ground for raising an issue with IBM. Just my 2 c Pavel Roger Lacroix [EMAIL PROTECTED]To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeries Subject: Re: Message under cursor List [EMAIL PROTECTED] C.AT 07/31/2004 12:05 PM Please respond to MQSeries List Hi, Actually, Peter and I have been having a long discussion about it over at mqseries.net . http://www.mqseries.net/phpBB2/viewtopic.php?p=67451#67451 Here's a summary of what I have discovered. Please note the difference between 'Destructive Get' and 'Destructive Get message under cursor'. Here's the layout without a loop structure. Assume 10 messages in the queue for each test scenario. Scenario #1: Open Queue Browse First - returns #1 Browse Next - returns #2 Browse Next - returns #3 Browse Next - returns #4 Browse Next - returns #5 Browse Next - returns #6 Destructive Get message under cursor - - returns #6 Browse Next - returns #7 Browse Next - returns #8 Browse Next - returns #9 Browse Next - returns #10 Browse Next - returns 2033 - no more messages Close Queue Scenario #2: Open Queue Browse First - returns #1 Browse Next - returns #2 Browse Next - returns #3 Browse Next - returns #4 Browse Next - returns #5 Browse Next - returns #6 Destructive Get message under cursor - - returns #6 Destructive Get - returns #1 Destructive Get - returns #2 Destructive Get - returns #3 Destructive Get - returns #4 Destructive Get - returns #5 Destructive Get - returns 6th message in queue originally #7 Destructive Get - returns 7th message in queue originally #8 Destructive Get - returns 8th message in queue originally #9 Destructive Get - returns 9th message in queue originally #10 Destructive Get - returns 2033 - no more messages Close Queue If I don't stop it after a particular number of messages then the above happens (i.e. only destructively get 5 messages). Scenario #3: Open Queue Browse First - returns #1 Browse Next - returns #2 Browse Next - returns #3 Browse Next - returns #4 Browse Next - returns #5 Browse Next - returns #6 Destructive Get message under cursor - - returns #6 Browse Next - returns #7 Destructive Get - returns #1 Browse Next - returns #8 Destructive Get - returns #2 Browse Next - returns #9 Destructive Get - returns #3 Browse Next - returns #10 Destructive Get - returns #4 Browse Next - returns 2033 - no more messages It's kinda cool that the cursors are truly independent of one another but it lends me back to my original question: How do you move the destructive get cursor? Regards, Roger Lacroix At 11:23 AM 7/31/2004, you wrote: Roger, On test #2 is this the sequence: Browse_First (#1) Browse_Next (#2) Browse_Next (#3) Browse_Next (#4) Browse_Next (#5) Browse_Next (#6) Get_Under_Cursor (#6) Get_Under_Cursor (#?) etc. OR Browse_First (#1) Browse_Next (#2) Browse_Next (#3) Browse_Next (#4) Browse_Next (#5) Browse_Next (#6) Get_Under_Cursor (#6) Browse_Next (#7 one would assume) Get_Under_Cursor (#?) Browse_Next (#8 one would assume) etc. Regardless I know the book sez that the Get_Msg_Under_Cursor will remove the last message gotten with a Browse_Msg_First or Browse_Msg_Next. So I will stick out my neck and assume that you just deleted the message pointed to by the Broswe_Next and the only pointer left pointing to a valid message is Browse_First and thus when you delete that one the cursor is moved to the next valid first message in the queue. bobbee From: Roger Lacroix [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Message under cursor Date: Fri, 30 Jul 2004 18:04:03 -0400 All, I was doing some testing of MQ code and have a question. First the testing: Test #1: I created a program to browse messages until a particular message then do a destructive get of it. I put
Re: Moving the list server ?
Also, supporting the list like this is a big commitment, often under-estimated, and the migration may be painful, especially for the infrequent users. Do we really have enough reasons to move off this one? Pavel Thomas, Don [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Moving the list server ? List [EMAIL PROTECTED] n.AC.AT 07/23/2004 08:53 AM Please respond to MQSeries List That would be bad for me as we are blocked from anything Yahoo related at our proxy server. I can read but can't reply, which would be akin to one hand clapping. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, July 22, 2004 7:01 PM To: [EMAIL PROTECTED] Subject: Moving the list server ? In light of all the problems with users sending read replies and not being able to get the owners/moderators to do anything, perhaps it is time to move the list to Yahoo groups... I know they send advertising but a group of us could be moderators and hence control things a bit better ? Any thoughts anyone... Sid Young QML Pathology Brisbane Australia 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 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
Re: MQSeries and Sun libc Patch
Hello Brian, We have experienced similar problems recently although I cannot tell you what exactly patch was applied. The core reasons turned to be the soft limit of file descriptors per process which, according to the quick beginnings book, must be boosted to 1024 (I recommend 2048) but this is often overlooked because it shows slightly aside of the kernel level parameter table that everyone looks after, and, until applying some Solaris kernel patch (mysteriously claimed as LDAP security patch or similar), it does not emerge as a problem. The default value is 256, I guess. The problem can be masked by ulimut settings in your /etc/profile (in which case ulimit may report large value than MQ will have when started by startup script), so I suggest you to go directly to /etc/system and add set rlim_fd_cur=1024 (or better 2048) if it is not there already -- and reboot (the latter is not theoretically necessary, you can use ulimit or even plimit and then the new value from /etc/system will go in effect after the next reboot, but we are on a shaky ground here). Hope this will help, Pavel Bumpass, Brian [EMAIL PROTECTED]To: [EMAIL PROTECTED] CHOVIA.COM cc: Sent by: MQSeriesSubject: MQSeries and Sun libc Patch List [EMAIL PROTECTED] n.AC.AT 07/08/2004 10:31 AM Please respond to MQSeries List I need your help... I am working with IBM and SUN concerning a failure starting QMgrs following the implementation of Sun Patches including the libc patch -- on Solaris 8 this would be 108993-##. I have tried patch revisions 33 36 to no real success. The SUN BugID is 5017781. The failing call is setgrent(). Interesting note this problem is also supposed to occur on Solaris 9; however, no problems have been experienced. Additionally, I have experimented with CSD05, CSD06, CSD07 hoping this has fixed things. From my experiences CSD05 has caused the least problems with the latest patches. With the others, intermittent hard failures have occured with the newer libc patches. I am slowly finding myself fall into that downward spiral of the vendors pointing fingers at each other and me the customer stuck in the middle. Has anyone experienced this Thanks in advance, -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 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
Re: Command Server Working Mechanisms
Hello Michael, Thanks for the answer. The answer to your questions is both and more. More is that we have some controlling/monitoring process on Unix and Windows that uses server-side MQI and if we were able to do what command server does based on PCFs, we wouldn't require this yet another process (yes, having it has security implications and also potentially affects resources and complexity and increases the number of moving parts). I feel that using runmqsc is not better (rather, worse), than using command server for our purpose. So I just wanted to know whether or not there is an API that command server (and, for this purpose, runmqsc) use to do their job that our process could use or it is all platform-specific and undocumented. We really want bare bones or the lowest level available for the MQ administration software. Thank you, Pavel Michael Dag [EMAIL PROTECTED]To: [EMAIL PROTECTED] ET.NL cc: Sent by: MQSeriesSubject: Re: Command Server Working Mechanisms List [EMAIL PROTECTED] n.AC.AT 06/29/2004 05:50 PM Please respond to Michael.Dag Pavel, the only 'process' that can create queues, etc... WITHOUT command server running is: runmqsc If you look at the runmqsc.exe for example on Windows, you'll notice it is a very small program... The API that runmqsc uses into QMgr is very obscure and IBM internal as I have understood. Now the important question... why do you not want to run the command server and find something to replace it. Is it educational or are you driven by potential security exposures? Michael -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED] Pavel Tolkachev Verzonden: Tuesday, June 29, 2004 11:25 PM Aan: [EMAIL PROTECTED] Onderwerp: Re: Command Server Working Mechanisms Thanks Tim, We (Monique and myself are working together) are actually not after that book. The book says how to do things when the command server is running; our purpose is to understand if it is possible to write monitoring application that does not require command server to, for example, create a queue, but does it instead of the command server. Is my suspicion correct that the command server works on a low level and there is no cross-platform API it uses to create a queue? Thank you in advance, Pavel Tim Armstrong [EMAIL PROTECTED]To: [EMAIL PROTECTED] YER.COM.AU cc: Sent by: MQSeriesSubject: Re: Command Server Working Mechanisms List [EMAIL PROTECTED] .AT 06/29/2004 05:07 PM Please respond to MQSeries List The manual you are after is Programmable Command Formats and Administration Interface and its not easy. Any given single thing is relatively easy to do but there are an awful lot of things you can do. Regards Tim A -Original Message- From: Monique Diaz [mailto:[EMAIL PROTECTED] Sent: Wednesday, 30 June 2004 5:58 AM To: [EMAIL PROTECTED] Subject: Command Server Working Mechanisms Hi, I would like to know the API or mechanisms used by Command Server to perform administrative tasks(eg create a queue) on the Queue Manager. Is there any API that I could use to write my own command server for Unix and / or Windows? Monique This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material. -- 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 Instructions for managing your mailing
Re: Command Server Working Mechanisms
Thanks T. Rob, Nice idea! For my purpose, it may make more sense to put messages to another queue and forward unknown ones to the command queue whose permissions must be really-really restricted. We will think of it more, but we may end up with just using command server -- it looks like nobody knows what it does to really create a queue etc.. Sincerely, Pavel Wyatt, T Rob [EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeries Subject: Re: Command Server Working Mechanisms List [EMAIL PROTECTED] C.AT 06/30/2004 11:01 AM Please respond to MQSeries List Pavel, One technique would be to write a wrapper for the command server. The wrapper uses and extends the PCF formats and monitors the command queue. Any commands that it knows about are handled by the wrapper. Any commands it does not know about are passed to the command server. The wrapper can provide extended services (display and manipulate OAM settings for example) and can also extend the security model. The only tricky part is to edit the amqpcsea binary to make it look at some queue *other than* the command queue. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel Tolkachev Sent: Wednesday, June 30, 2004 10:30 AM To: [EMAIL PROTECTED] Subject: Re: Command Server Working Mechanisms Hello Michael, Thanks for the answer. The answer to your questions is both and more. More is that we have some controlling/monitoring process on Unix and Windows that uses server-side MQI and if we were able to do what command server does based on PCFs, we wouldn't require this yet another process (yes, having it has security implications and also potentially affects resources and complexity and increases the number of moving parts). I feel that using runmqsc is not better (rather, worse), than using command server for our purpose. So I just wanted to know whether or not there is an API that command server (and, for this purpose, runmqsc) use to do their job that our process could use or it is all platform-specific and undocumented. We really want bare bones or the lowest level available for the MQ administration software. Thank you, Pavel Michael Dag [EMAIL PROTECTED]To: [EMAIL PROTECTED] ET.NL cc: Sent by: MQSeriesSubject: Re: Command Server Working Mechanisms List [EMAIL PROTECTED] n.AC.AT 06/29/2004 05:50 PM Please respond to Michael.Dag Pavel, the only 'process' that can create queues, etc... WITHOUT command server running is: runmqsc If you look at the runmqsc.exe for example on Windows, you'll notice it is a very small program... The API that runmqsc uses into QMgr is very obscure and IBM internal as I have understood. Now the important question... why do you not want to run the command server and find something to replace it. Is it educational or are you driven by potential security exposures? Michael -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED] Pavel Tolkachev Verzonden: Tuesday, June 29, 2004 11:25 PM Aan: [EMAIL PROTECTED] Onderwerp: Re: Command Server Working Mechanisms Thanks Tim, We (Monique and myself are working together) are actually not after that book. The book says how to do things when the command server is running; our purpose is to understand if it is possible to write monitoring application that does not require command server to, for example, create a queue, but does it instead of the command server. Is my suspicion correct that the command server works on a low level and there is no cross-platform API it uses to create a queue? Thank you in advance, Pavel Tim Armstrong [EMAIL PROTECTED]To: [EMAIL PROTECTED] YER.COM.AU cc: Sent by: MQSeriesSubject: Re: Command Server Working Mechanisms List [EMAIL PROTECTED] .AT 06/29/2004 05:07 PM Please respond to MQSeries List The manual you are after is Programmable Command Formats and Administration Interface and its not easy. Any given single thing is relatively easy to do but there are an awful lot of things you can do. Regards Tim A -Original Message- From: Monique Diaz [mailto:[EMAIL PROTECTED] Sent: Wednesday, 30 June
Re: Websphere MQ and MDB on Was 5.0 : relation between sessions and concurrent message consumption
Hello Shanu, First, I am not a WAS person but I had a bit of exposure to other AS(es) and JMS. My guess is that the maximum number of messages is the direction to the AS to close a session and create a new session after this many messages has been pushed to the MDB by that session. Remeber that a single instance of an MDB can (and most often supposed to) process multiple messages. Hope this will help, Pavel Shantanu Upadhyaya shantanuupadhyaya@To: [EMAIL PROTECTED] HSBC.CO.INcc: Sent by: MQSeries Subject: Websphere MQ and MDB on Was 5.0 : relation between sessions and Listconcurrent message consumption [EMAIL PROTECTED] AC.AT 06/29/2004 09:27 AM Please respond to MQSeries List Hi ! Forgive me if this is not the right place for this query. :-) I'm having a little problem in figuring out the the Listener Port and related concepts in Was 5.0 ( Wish it was explicity stated instead on trying to figure it out !) Here's my understanding... 1. The Listener Port is a facade for the queue. 2. The Listener Port configuration on WAS Admin console has the following : a)Maximum Sessions : Multiple sessions are provided for load balancing. Info provided on the console : The maximum number of concurrent JMS server sessions used by a listener to process messages, in the range 1 through 2147483647. b)Maximum Messages : This is is used to specify the maximum number of sessions a session can process. Now since an MDB can only process one message at a time, I would assume that the number specified here would be = number of MDB the WAS5.0 server creates. Is this right ? Info provided on the console : The maximum number of messages that the listener can process in one JMS server session, in the range 0 through 2147483647. So according to me, |-Session 1--- Many MDBs | Queue -- Listener Port |-Session 2--- Many MDBs |... |... |_ Session N--- Many MDBs I still feel something is wrong / missing somewhere. Or are Maximum Messages != MDBs nothing to do with MDBs. Or MDB instance cannot be configured in WAS5.0 at all ? (Since WAS does not provide Session Bean cache at all ! ) Thanks ! Shanu Dark Warrior HSBC Software Development (India) Pvt Ltd HSBC Center, Riverside, West Avenue, 25-B Raheja Woods, Kalyani Nagar, Pune 411006. Telephone: +91 20 26683000 Fax: +91 20 26681030 ** This e-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ** -- 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
Re: Command Server Working Mechanisms
Thanks Tim, We (Monique and myself are working together) are actually not after that book. The book says how to do things when the command server is running; our purpose is to understand if it is possible to write monitoring application that does not require command server to, for example, create a queue, but does it instead of the command server. Is my suspicion correct that the command server works on a low level and there is no cross-platform API it uses to create a queue? Thank you in advance, Pavel Tim Armstrong [EMAIL PROTECTED]To: [EMAIL PROTECTED] YER.COM.AU cc: Sent by: MQSeriesSubject: Re: Command Server Working Mechanisms List [EMAIL PROTECTED] .AT 06/29/2004 05:07 PM Please respond to MQSeries List The manual you are after is Programmable Command Formats and Administration Interface and its not easy. Any given single thing is relatively easy to do but there are an awful lot of things you can do. Regards Tim A -Original Message- From: Monique Diaz [mailto:[EMAIL PROTECTED] Sent: Wednesday, 30 June 2004 5:58 AM To: [EMAIL PROTECTED] Subject: Command Server Working Mechanisms Hi, I would like to know the API or mechanisms used by Command Server to perform administrative tasks(eg create a queue) on the Queue Manager. Is there any API that I could use to write my own command server for Unix and / or Windows? Monique This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material. -- 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
Re: So long, and thanks for all the fish!
Hello Bill, Have a nice retirement! You have a very right reminder at the footer of your e-mails -- just for the sake of seeing it I would appreciate your continuing mailing us from time to time :-). Have a blessed day, Pavel Beinert, William To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: OM Subject: So long, and thanks for all the fish! Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 06/28/2004 10:56 AM Please respond to MQSeries List I am retiring next Thursday, and before unsubscribing to the list, I want to express my gratitude and appreciation to all of the people on this list. I cannot imagine what it would have been like to bring MQ into my shop for the first time without the assistance of this group. I hope I have been able to contribute even a tiny bit to repay the enormous and invaluable help that I have received over the past few years. My MQ duties here at Con Ed are being taken over by Tammy Dewey and Leo Melita. I hope you guys will be as hospitable to them as you have been to me. Thanks again and again Bill 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 -- 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
Re: Not directly MQ - Time Syncing your servers
Hello Peter, You may get something better than that on the local network but I doubt for the inter-network synchronization. Also, depending on the real-time clocks implementation, short periodic time error may be in tenths and of course hundredths -- unless you have bought some special hardware for your system clocks on all machines you want to synchronize; in which case, you probably already have some specialized software to synchronize come with the hardware... Pavel Potkay, Peter M (PLC, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Not directly MQ - Time Syncing your servers Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 06/22/2004 05:12 PM Please respond to MQSeries List What do people out there use for syncing up all their clocks on all their servers? We are using Transaction Vision to correlate our transactions. TV reports the time from its sensors down to the millisecond (microsecond on z/OS and UNIX). But if the servers are off in time by tenths or even hundredths of a second, the result are skewed for transactions that zip thru 3 servers in half a second. I get results showing that events on server 3 happened before server 2. And I am not confident on how long the message took to get from 1 to 2, even if the order happens to be correct. Is it realistic to expect better than one second accuracy between servers if you are using time sync software? To the naked eye all the servers look pretty well synced up, but at the millisecond level, they are all over the place. Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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 -- 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
Re: Problems settting up SSL key database on Solaris using gsk6cmd
Hello James, use gsk6cmd -cert -receive ... Also, while awaiting for your Verisign-signed certificate, you can practice in importing certificate by signing your request yourself using gsk6cmd -cert -sign ... and then importing them with -receive. Hope this will help, Pavel James Biddlecombe [EMAIL PROTECTED]To: [EMAIL PROTECTED] SNET.CO.UK cc: Sent by: MQSeriesSubject: Problems settting up SSL key database on Solaris using gsk6cmd List [EMAIL PROTECTED] n.AC.AT 06/07/2004 07:33 PM Please respond to MQSeries List Guys, I'm having terrible problems getting my key database setup and working. I've gone through all the docs I can find and am still unsure of the command I have to run. I need to use the command line gsk2cmd for various reasons in this case. I'm now on my second attempt and the scenario I am trying to get working is queue manager to queue manager between 2 companies via the internet both using signed certificates from Verisgn. Can anyone confirm the correct commands I need to run to set up the database on my Solaris box. I've done the following so far: gsk6cmd -keydb -create -db /var/mqm/qmgrs/QMA/ssl/key.kdb -pw password -type cms -expire 365 -stash gsk6cmd -certreq -create -db /var/mqm/qmgrs/QMA/ssl/key.kdb -pw password -label ibmwebspheremqqma -dn CN= -key_size 1024 -file certreq.csr where CN is the full distinguished name. The certificate is now being signed by Verisign and will be returned to me as cert.cer. However, I'm unsure which command to enter next to read in the signed certificate. Can someone clarify this for me? At this stage I don't have any personal certificates in the database. Is this correct until I read in my signed certificate? Once i have set this up do I need to exchange any certifcates (ftp, etc) with the other queue manager location or is this all done under the covers? Any help would be very much appreciated. Cheers, James. -- 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
Re: many svrconn instances, as many amqcrsta running
Hello Benjamin, T.Rob is right in principle, of course. But I guess, the connections had to go down, anyway, with these tcp settings. Just in case, what was your tcp_keepcnt? And, did you check your new tcp parameters took effect immediately? Also, I am not sure if the change takes effect for the existing connections (never checked that..). What else may have happened is that the applications were actually alive, although idle, in which case you do not have much control.. that's why DoS attacks are so nasty when done by the legitimate apps :-) Pavel Wyatt, T. Rob [EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeries Subject: Re: many svrconn instances, as many amqcrsta running List [EMAIL PROTECTED] C.AT 06/08/2004 11:05 AM Please respond to MQSeries List Benjamin, Using QMgr tuning to bring these channels down addresses only the symptom. Unless you correct the problem at it's root, nothing you do will scale well. The application MUST properly close it's resources and disconnect from the QMgr. If you successfully tune the channels, you will probably get through development and testing but you might not see the real impact until the application is in Production. On the other hand, if you leave your channels as they are now, you will have a convenient way to measure the success of the developers in fixing their code. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: Tuesday, June 08, 2004 10:52 AM To: [EMAIL PROTECTED] Subject: many svrconn instances, as many amqcrsta running Hi, AIX, 5.1, MQ5.3, csd06: we have JMS clients connecting to MQ via client mode. Initially, the maxchannels got reached quickly, and application failed at pretty low stress level. After I raised both MaxChannels and MaxActiveChannels to 400, the test went through pretty well. However, after each test, I see large number of the svrconn channel and the same number of amqcrsta running against the same qmgr. There's no sign they will ever come down, although I set keepAlive=yes and tcp_keepintvl and tcp_keepidle to 10 seconds. What else can be done to bring down these orphaned processes? I saw many postings concerning this or similar problem at mqseries.net , just none has found a solution. Anyone has more idea on this? best regards, Benjamin Zhou Mercedes-Benz USA. x2474 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 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
Re: many svrconn instances, as many amqcrsta running
Hello Benjamin, I tried on AIX 5.2, tcp_keepcnt was there: # no -o tcp_keepcnt tcp_keepcnt = 8 # But now I tried on 5.1 and it failed as you said: /home/ptol$ sudo no -o tcp_keepcnt 0821-057 no: The ioctl SIOCGNETOPT system call failed. Sorry for the confusion. It is probably 8, anyway.. Pavel Benjamin F. ZhouTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: USA.COM Subject: Re: many svrconn instances, as many amqcrsta running Sent by: MQSeries List [EMAIL PROTECTED] n.AC.AT 06/08/2004 01:41 PM Please respond to MQSeries List Hi Pavel, Rob and Peter, thanks for the insight. I did insisted it must be some code not closing connection under certain circumstances, and ran a trace and sent to IBM for analysis. But were told all connections were closed properly, which virtually nullified my insertion to the developers. I'll following your advice to do more research. There seem to be no tcp_keepcnt on AIX, a command no -otcp_keepcnt returned my the following 0821-057 no: The ioctl SIOCGNETOPT system call failed.. again, many thanks. Maybe see you in Las Vegas? Ben Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: many svrconn instances, as many amqcrsta running MQSeries List [EMAIL PROTECTED] en.AC.AT 06/08/2004 12:51 PM Please respond to MQSeries List Hello Benjamin, T.Rob is right in principle, of course. But I guess, the connections had to go down, anyway, with these tcp settings. Just in case, what was your tcp_keepcnt? And, did you check your new tcp parameters took effect immediately? Also, I am not sure if the change takes effect for the existing connections (never checked that..). What else may have happened is that the applications were actually alive, although idle, in which case you do not have much control.. that's why DoS attacks are so nasty when done by the legitimate apps :-) Pavel Wyatt, T. Rob [EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeries Subject: Re: many svrconn instances, as many amqcrsta running List [EMAIL PROTECTED] C.AT 06/08/2004 11:05 AM Please respond to MQSeries List Benjamin, Using QMgr tuning to bring these channels down addresses only the symptom. Unless you correct the problem at it's root, nothing you do will scale well. The application MUST properly close it's resources and disconnect from the QMgr. If you successfully tune the channels, you will probably get through development and testing but you might not see the real impact until the application is in Production. On the other hand, if you leave your channels as they are now, you will have a convenient way to measure the success of the developers in fixing their code. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: Tuesday, June 08, 2004 10:52 AM To: [EMAIL PROTECTED] Subject: many svrconn instances, as many amqcrsta running Hi, AIX, 5.1, MQ5.3, csd06: we have JMS clients connecting to MQ via client mode. Initially, the maxchannels got reached quickly, and application failed at pretty low stress level. After I raised both MaxChannels and MaxActiveChannels to 400, the test went through pretty well. However, after each test, I see large number of the svrconn channel and the same number of amqcrsta running against the same qmgr. There's no sign they will ever come down, although I set keepAlive=yes and tcp_keepintvl and tcp_keepidle to 10 seconds. What else can be done to bring down these orphaned processes? I saw many postings concerning this or similar problem at mqseries.net , just none has found a solution. Anyone has more idea on this? best regards, Benjamin Zhou Mercedes-Benz USA. x2474 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 may contain
Re: SSL, MQClients and Symmetric keys
Hello Peter, 1. I would say yes for all 3, but with the warning (:-)) that getting PublicKeyA will be extermely simple for any moderately dedicated attacker (it is always sent in the certificate by the queue manager at the non-encrypted stage of SSL handshake (actually, in response to Client Hello)). 2. Open SSL (command line) is really well documented. It has a great man and it is available in nice colors here: http://www.openssl.org/docs/apps/openssl.html. From there, follow links for 'x509' and 'ca' subcommands. I have nothing against gsk6cmd except that it is unbearable slow. I have never used that other product (makecert). I am not sure how to make CMS database with openssl or anything other than gsk6cmd (I remember there was CMS format for keydatabases of Netscape, while ago, but I am not sure if it is the same that is used by IBM). 3. I have never read a book for OpenSSL but I suspect it will be mostly devoted to using the library, not the command line -- although it is just my guess. To me, 'the book' about SSL is SSL and TLS: Designing and Building Secure Systems by Eric Rescorla (one of the author of TLS and the Java implementation of SSL/TLS). It is good in being not really tied to any particular implementation (and it does not even oversell you SSL itself, it shows what it is and, most important, what it is not). It does not say anything of using openSSL command line though (you will have to use the link before) but discusses the use of OpenSSL API a little bit. Hope this will help, Pavel Potkay, Peter M (PLC, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Re: SSL, MQClients and Symmetric keys Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 06/03/2004 03:11 PM Please respond to MQSeries List So MQClientA, B and C would have PrivateKey1 (the MQClient Private Key) and PublicKeyA (the MQQueuemanager Public Key). QueueManager1, 2, ..., 99 would have PrivateKeyA (the MQQueueManagerKey Private Key) and PublicKey1 (the MQClient Public Key). Assume that MQClientA, B and C will be the only machines ever to have PrivateKey1, as I will hand deliver them and be in total control. And assume PrivateKeyA will only ever be on the QMs I personally install it on. All machines in question are internal behind the firewall. If the above is true: 1.) Self signed certificates will be adequate. 2.) MQClientX, not having BOTH PublicKeyA AND PrivateKey1 will not be able to connect to any of these QMs over a SVRCONN channel with SSL turned on. That even if they somehow managed to get PublicKeyA OR PrivateKey1 (but not both), they would not be able to connect over a SVRCONN channel with SSL turned on (and SSLClientAuth set to REQUIRED). 3.)To create self signed certs myself, to be my own CA, I have one of 3 methods: openssl, makecert and gsk6cmd. Which is the best, and why? openssl seems to have a lot of fans based on what I have trolled from the web, but there's better/more documentation on how to turn bat guano to gold than on how to use openssl. Same goes for makecert. I ordered the O'Reilly book on openssl today, hopefully the fact that it is 2 years old wont matter. Geez, this SSL stuff has put me in my place. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 02, 2004 5:16 PM To: [EMAIL PROTECTED] Subject: Re: SSL, MQClients and Symmetric keys Hello Peter, Even if you are only interested in securing SVRCONN channels, you will still need a secret on every server (a server is always authenticated in SSL). For clients -- yes, you can use the same private key if distributing it is not a problem in your setup. But remember that both client and server must have public and private keys for recovering secrets during SSL handshake. By the way, I am not sure it is safe to have same keys on both server and client. In this degenerate case RSA key exchange may become vulnerable for some type of attack (not that I knew exactly which, but I would do some googling before using it). Again, PKI with CAs and whatever is written in the books is a pretty convenient thing, specially intended to solve key distribution problem. From my experience, except for one concept there (certificate expiration date) it does not introduce more troubles than it solves. IBM's gsk6cmd tool is kind of slow though. I would recommend using openssl wherever possible and then only import results into CMS databases with gsk6cmd. BTW, does anyone know any other (preferably free :-)) tool than gsk6cmd (iKeycmd) for working with those CMS databases? Hope this will help, Pavel Potkay, Peter M (PLC
Re: SSL, MQClients and Symmetric keys
Hello Peter, 1. Yes. And which sometimes is more difficult that it sounds :-). The book I mentioned has some insights on this subject, too. 2. For example, try this somewhere on any Linux box in a clean directory (or other *nix if openssl is installed and in the path): $ openssl req -x509 -newkey rsa:2048 -keyout ca.private.pem -out ca.cert.pem # answer all questions and remember your passwphrase # this created self-signed root certificate for ca $ openssl req -newkey rsa:1024 -keyout qm.private.pem -out qm.request.pem # answer all questions till Extra attributes (just press Enter on those). remember your other passphrase $ openssl x509 -req -in qm.request.pem -CA ca.cert.pem -CAkey ca.private.pem -CAcreateserial -days 3660 qm.cert.pem $ ls ca.cert.pem ca.private.pem ca.srl qm.cert.pem qm.private.pem qm.request.pem $ Now, you have all certificates you needed for ca and qm. Do same for the client and you are almost done. You will need gsk6cmd to import certificates and keys to CMS database though. That's why the suggestion of Neil about keeping a copy of an empty .kdb database (in CMS format) is worth. For your last question, I thought you wanted a single key! The answer is 'yes', anyway, with these comments: a) QMs must have not just public keys, but certificates, signed with the authority whom client trusts (CA certificate must be in the client's database) b) Client's certificate must be sign by the authority that QMs trust c) you do not use SSLPEER on the channel (i.e. QMs do not authenticate client). If they do authenticate, Client's common name in certificate must match SSLPEER for client to get access. d) I forgot something -- that's for sure.. :-) Hope this will help, Pavel Potkay, Peter M (PLC, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Re: SSL, MQClients and Symmetric keys Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 06/03/2004 04:55 PM Please respond to MQSeries List Pavel, thanks for taking the time to answer these questions for me. 1.) So the important things is that the MQClient peoples keep their Private Key private, which is something that all the SSL docs keep pointing out. 2.)OK, so maybe its well documented, but it sure would be nice to have some examples to follow along with. I learn by doing I guess. I can't even get started - keeps barking at me about a config file missing, yet nowhere that I can find is an example of this config file or what needs to be in it. I am hoping the book will have this. I am trying to set up openssl on a Windows box. Maybe I should just try and commandline it from my Solaris box. 3.) I will have to get the book you mentioned as well. Actually, Amazon recommended I get it when I ordered the openssl one! One last scenario: Based on the set up laid out in the last email: What if MQClientA123, B123 and C123 had PrivateKey123 (this MQClient group's Private Key) and PublicKeyA123 (a second MQQueuemanager Public Key). QueueManager1, 2, ..., 99 would have PrivateKeyA123 (a second MQQueueManagerKey Private Key) and PublicKey123 (the second MQClient's Public Key). In this case, is it true that either MQClient group could connect to either SVRCONN channel, even though they both are protected by SSL?!?! (assuming they both knew the other SVRCONN channel name and what CipherSpec to specify) Is the second MQQueueManager key pair even necessary? -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Thursday, June 03, 2004 3:54 PM To: [EMAIL PROTECTED] Subject: Re: SSL, MQClients and Symmetric keys Hello Peter, 1. I would say yes for all 3, but with the warning (:-)) that getting PublicKeyA will be extermely simple for any moderately dedicated attacker (it is always sent in the certificate by the queue manager at the non-encrypted stage of SSL handshake (actually, in response to Client Hello)). 2. Open SSL (command line) is really well documented. It has a great man and it is available in nice colors here: http://www.openssl.org/docs/apps/openssl.html. From there, follow links for 'x509' and 'ca' subcommands. I have nothing against gsk6cmd except that it is unbearable slow. I have never used that other product (makecert). I am not sure how to make CMS database with openssl or anything other than gsk6cmd (I remember there was CMS format for keydatabases of Netscape, while ago, but I am not sure if it is the same that is used by IBM). 3. I have never read a book for OpenSSL but I suspect it will be mostly devoted to using the library, not the command line -- although it is just my guess. To me, 'the book' about SSL is SSL and TLS: Designing and Building Secure Systems by Eric Rescorla
Re: SSL, MQClients and Symmetric keys
Hello Peter, Even if you are only interested in securing SVRCONN channels, you will still need a secret on every server (a server is always authenticated in SSL). For clients -- yes, you can use the same private key if distributing it is not a problem in your setup. But remember that both client and server must have public and private keys for recovering secrets during SSL handshake. By the way, I am not sure it is safe to have same keys on both server and client. In this degenerate case RSA key exchange may become vulnerable for some type of attack (not that I knew exactly which, but I would do some googling before using it). Again, PKI with CAs and whatever is written in the books is a pretty convenient thing, specially intended to solve key distribution problem. From my experience, except for one concept there (certificate expiration date) it does not introduce more troubles than it solves. IBM's gsk6cmd tool is kind of slow though. I would recommend using openssl wherever possible and then only import results into CMS databases with gsk6cmd. BTW, does anyone know any other (preferably free :-)) tool than gsk6cmd (iKeycmd) for working with those CMS databases? Hope this will help, Pavel Potkay, Peter M (PLC, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Re: SSL, MQClients and Symmetric keys Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 06/02/2004 03:55 PM Please respond to MQSeries List Neil, if I make a self-signed certificate, I assume I will get a Private/Public key pair included, correct? And if so, could I not put the public key half on all my QMs, and keep the private key on my desktop. Then configure the SVRCONN channel to use SSL. Then give the private key to my teammates. So all 6 of us are running the same private key, all QMs (current and future) have the same public key, and the only MQClients that can use this SVRCONN channel will be ones that have this particular private key? -Original Message- From: Neil Casey [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 01, 2004 6:42 PM To: [EMAIL PROTECTED] Subject: Re: SSL, MQClients and Symmetric keys Hi Peter, I've been busy with SSL for the last few weeks as well, and this is my take on your issue. 1. SSL does use symetric keys for encryption. It generates them at session startup, and exchanges them, protected by encryption with the private/public key pair. This gets around the symetric key delivery problem. 2. While self signed certs could be used in your environment, they would be very painful. Every cert needs to be installed in every key store, especially if you want to use sslcauth(required). 3. This is where a CA helps. You generate your certificate signing requests on each host, and get the CA to sign the request. The certificate is then received into the key store for its queue manager (or client) and the public key of the CA is added as a trusted CA cert. The queue managers will then trust any cert signed by this CA where the DN matches the SSLPEER value. 4. You don't need to go out to an external CA like Thawte or Verisign and pay for certs. You can set up a private CA, which can be as simple as installing the OpenSSL (or is it OpenSSH?) package on a linux machine (don't install a network card). Then you can use the commands directly, or set up some scripts to make the syntax easier. 5. If you do it this way, then each key repository only needs to have the personal cert belonging to the queue manager or client, and the CA cert for the signer. You can add new queue managers and clients without having to touch any of the existing key repositories. If you used self signed certs, you would need to cross copy the new cert into every other key repository. 6. Be careful about the default CA certs which are installed into the repository when you create it. I always delete all of these CA certs because I don't plan to use certs signed by them. I can always add them back if I need to later. In your note, you say you want to use the same cert or key on all of your clients/servers. If you build an internal CA, put that into your repository and use it to sign all the certs, then that is in effect what you get. Only the CA cert is in the repository, but you get the trust you want, and you don't have to cross register all the different self-signed certificates. In theory, I think you could also generate one private/public key pair (self signed certificate) and export it. Then import it into the other queue managers/clients with different labels in each location. This would not be a nice thing to do, and really wouldn't help your security much. It means that you have to move your private keys around,
Re: Changing MQXQH on the fly
Hello Roger, I was thinking more in terms of some command-line tool that a visual one with the reason being that last time we had a bit more than 5K of messages to re-route. Manual editing would be slightly painful :-). As for the header fields, only QMgrName and QName were to be changed that time. I am not sure I have enough use cases to define a new feature in any product though -- I was just wondering if there was an existing one that did it by any chance. And I do not know enough to write such program for editing messages in-place myself. If it is not a secret, how would you do it in Visual Edit, by the way? Also, I have another (purely theoretical) question about the case. I thought I understood how MQ worked: sender channel agent is a regular application (or a thread) that is triggered by XMIT queue, takes messages from there and communicates with the agent on the other end; now I am in doubt: how can it get messages from the transmission queue if GET from there is inhibited? Thank you, Pavel Roger Lacroix [EMAIL PROTECTED]To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeries Subject: Re: Changing MQXQH on the fly List [EMAIL PROTECTED] C.AT 05/27/2004 12:14 PM Please respond to MQSeries List Hi Pavel, I was thinking of adding editing ability to MQ Visual Edit's MQXMIT tab. Do you want to just edit the XQH fields (QMgrName QName) or did you want to also edit the follow-on MQMD (the message's original MQMD)?? Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Pavel Tolkachev [EMAIL PROTECTED]: Hello all, We recently had a situation when some messages got stuck on the transmission queue due to the wrong sequence of actions for changing the destination queue manager. We had to delete messages, there were no harm as this was development. I wonder if there is any way or tool to change this header while messages are on the queue to reroute them without going into DLQ business? 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 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
Re: Problem with clearing a queue
Hello Bill, Thanks for the important gotcha. I just looked into command line syntax and it does look promising. I am sure I will find a good use of it. One thing that my Java sample does and Q doesn't though is using SSL connection when asked. So, I think, the two will compliment each other. Pavel Bill Anderson [EMAIL PROTECTED]To: [EMAIL PROTECTED] TA.AERO cc: Sent by: MQSeriesSubject: Re: Problem with clearing a queue List [EMAIL PROTECTED] n.AC.AT 05/27/2004 11:36 AM Please respond to MQSeries List Hi Pavel, I think you will like Q its not extremely user friendly (because its command line driven not a gui), but for folks who don't mind going through the docs, it is a very useful tool. One thing that tripped me up when I first started to use it is that it will connect as a client or a server dynamically, you don't need two different versions of the executable for that. What I discovered is that it attempts to use its server libraries first, and simply fails if it can't find the queue manager name it was given. So, because I run a full server on the work station I use to admin MQ here it started to give me 2058 errors. I was confused at first, and thought I must have fat fingered the queue manager name or something like that. But what it was doing was attempting to connect to a queue manager on my local machine as a server, rather than a remote queue manager as I had intended. It completely ignored the MQSERVER variable I set up to have it do a client connection. So, If you use it from a machine that has MQ installed, and you want to connect to a remote queue manager, you have to tell Q to use the client libraries with a command line flag as you see below. -l mqic32 (for a windows box of course) Its a minor point about the program, but will cause some frustration if you don't know about it. Cheers 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/ Pavel Tolkachev pavel.tolkachev@To: [EMAIL PROTECTED] DB.COM cc: Sent by: MQSeriesSubject: Re: Problem with clearing a queue List [EMAIL PROTECTED] N.AC.AT 05/26/2004 03:44 PM Please respond to MQSeries List Thanks Bill, I will look into it. My sample program has a lot of options, too (20 or so :-)). Unfortunately, I built it with the dependencies on the company's code, otherwise I would have submitted it as a support pack :-(. Pavel Bill Anderson [EMAIL PROTECTED]To: [EMAIL PROTECTED] TA.AERO cc: Sent by: MQSeriesSubject: Re: Problem with clearing a queue List [EMAIL PROTECTED] n.AC.AT 05/26/2004 01:44 PM Please respond to MQSeries List Support Pack MA01 is a much better choice than any of the sample programs such as amqsget. It can connect as a client or server and has enough command line options to make you dizzy. I use it allot, especially to move (or copy) messages from one queue to another. 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/ Pavel Tolkachev pavel.tolkachev@To: [EMAIL PROTECTED] DB.COM cc: Sent by: MQSeriesSubject: Re: Problem with clearing a queue List [EMAIL PROTECTED] N.AC.AT 05/26/2004 01:15 PM Please respond to MQSeries List Hello Gina, I had this problem just today -- looks like it is contagious :-) Stop channels, enable 'get' on the queue and remove all messages. Then restart channels (I also had to reset sender although I am not sure if I had to use ALTER QLOCAL(xmit.queue.name) GET(enabled) FORCE. And you cannot use amqsget because it does not remove truncated messages. I have a program of my own that does it (accepting truncated messages). I am not sure if this is the right way; anyone who knows the recommended way of solving
Re: Changing MQXQH on the fly
I see.. This probably will not work in this case. My problem is: messages are already on the transmission queue and only later we are notified that the destination is not and will not be available and what the new destination will be. Pavel [EMAIL PROTECTED] PMCHASE.COM To: [EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Re: Changing MQXQH on the fly [EMAIL PROTECTED] .AC.AT 05/27/2004 12:18 PM Please respond to MQSeries List Pavel, We do this type of work in a message exit... Pavel Tolkachev pavel.tolkachev@To: [EMAIL PROTECTED] DB.COM cc: Sent by: MQSeriesSubject: Changing MQXQH on the fly List [EMAIL PROTECTED] n.AC.AT 05/27/2004 09:54 AM Please respond to MQSeries List Hello all, We recently had a situation when some messages got stuck on the transmission queue due to the wrong sequence of actions for changing the destination queue manager. We had to delete messages, there were no harm as this was development. I wonder if there is any way or tool to change this header while messages are on the queue to reroute them without going into DLQ business? 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 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 -- 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
Re: Problem with clearing a queue
Thanks Paul, I did not realise that. I was not sure how to specify a channel in -xc, readme is not exactly clear and I assumed I would have to use something like the value MQSERVER env. var. Will try that. Pavel Paul Clarke [EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM cc: Sent by: MQSeriesSubject: Re: Problem with clearing a queue List [EMAIL PROTECTED] n.AC.AT 05/28/2004 07:21 AM Please respond to MQSeries List Hello Bill, Thanks for the important gotcha. I just looked into command line syntax and it does look promising. I am sure I will find a good use of it. One thing that my Java sample does and Q doesn't though is using SSL connection when asked. So, I think, the two will compliment each other. Pavel Pavel, There's nothing to stop you using SSL with Q. Q is a normal MQ client so if you have a client table with an SSL CLNTCONN channel then it will use it. You can specify the channel definition when you run it by using the -xc switch. If you use this then, if you have the right version, it will ask you to specify the SSL values to use for the connection. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley 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
Re: Changing MQXQH on the fly
Thanks Paul, In this case, my plan for this situation would probably be to have ready DLQ handler rules to forward the messages to the other queue / queue manager and allow DLQ for the period of crisis (it is usually not present or put-inhibited in our configurations, as some people on the list could guess from my previous mails :-)). M071will be great to look through the queue before enabling DLQ and make sure there is no stray messages has stuck there. Pavel Paul Clarke [EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM cc: Sent by: MQSeriesSubject: Re: Changing MQXQH on the fly List [EMAIL PROTECTED] n.AC.AT 05/28/2004 08:31 AM Please respond to MQSeries List I see.. This probably will not work in this case. My problem is: messages are already on the transmission queue and only later we are notified that the destination is not and will not be available and what the new destination will be. Pavel Pavel, MQ does not have an 'MQUPDATE' verb or whatever to change the contents of a message. The only way of doing this via the MQI is to get the message and put it back again. You could therrefore have issues to do with ordering. If you are not concerned about this you could have a look at my MO71 suppport pac. This allows you to browse a transmission queue. You can select the messages you want and ask MO71 to either move, copy or delete the messages. In the case of move and copy you specify the target Q and Queue Manager. There's an option to say whether you want to strip any headers from the front of the message. In this case it would apply to the MQXQH but may also apply to the MQDLH if you're browsing the dead letter queue. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley 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
Re: Changing MQXQH on the fly
Thanks Peter!
Yes, yours is a cleaner way than to define DLQ handler, as I planned. I think we will
use this as a plan.
Pavel
Potkay, Peter M
(PLC, IT) To: [EMAIL PROTECTED]
[EMAIL PROTECTED]cc:
RTFORD.COMSubject: Re: Changing MQXQH on the
fly
Sent by: MQSeries
List
[EMAIL PROTECTED]
AC.AT
05/28/2004 09:05 AM
Please respond to
MQSeries List
Resending the below because I sent it a day ago and still have not seen it.
Yes, I am set up to see my own posts. Sorry if it duplicates.
Assume the sending QM is QMA, and the RCVR is QMB. QMA has a XMITQ queue
called QMB, and on that queue you have messages (channel manually stopped?)
destined incorrectly for QMX.
On QMB, define a QMAlias as follows:
DEFINE QREMOTE ('QMX') +
XMITQ(' ') +
RNAME(' ') +
RQMNAME(' ') +
REPLACE
Start the channel. Now any messages that arrive at QMB looking for QMX will
be switched to look for the queue on the local QM (QMB). If you need it to
go to some other QM, and QMB has an XMIT queue to that other QM, just put
that QM name (QMZ) in the RQMNAME of the new QMAlias you are building, like
so:
DEFINE QREMOTE ('QMX') +
XMITQ('XMITQ.TO.QMZ') +
RNAME(' ') +
RQMNAME('QMZ') +
REPLACE
-Original Message-
From: Potkay, Peter M (PLC, IT)
Sent: Thursday, May 27, 2004 10:10 AM
To: 'MQSeries List'
Subject: RE: Changing MQXQH on the fly
Create a QMAlias on the destination QM to change the name from the bad QM to
the real QM.
-Original Message-
From: Pavel Tolkachev [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 27, 2004 9:55 AM
To: [EMAIL PROTECTED]
Subject: Changing MQXQH on the fly
Hello all,
We recently had a situation when some messages got stuck on the transmission
queue due to the wrong sequence of actions for changing the destination
queue manager. We had to delete messages, there were no harm as this was
development. I wonder if there is any way or tool to change this header
while messages are on the queue to reroute them without going into DLQ
business?
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
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
--
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
Changing MQXQH on the fly
Hello all, We recently had a situation when some messages got stuck on the transmission queue due to the wrong sequence of actions for changing the destination queue manager. We had to delete messages, there were no harm as this was development. I wonder if there is any way or tool to change this header while messages are on the queue to reroute them without going into DLQ business? 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
Re: iKeyman GUI and Java
Hello Bill, 2 suggestions: 1. Use the JRE that comes with gsk package (I am not sure if it is there on Linux, but on AIX and Solaris it is). It is 1.3.something but it has whatever keyman needs. Set your PATH and JAVA_HOME to that one. 2. Try gsk6cmd instead of GUI. Hope this will help, Pavel Bill Anderson [EMAIL PROTECTED]To: [EMAIL PROTECTED] TA.AERO cc: Sent by: MQSeriesSubject: iKeyman GUI and Java List [EMAIL PROTECTED] n.AC.AT 05/25/2004 02:11 PM Please respond to MQSeries List I am attempting to set up SSL channels on a Linux box using the iKeyman GUI called gsk6ikm. I started with installing J2sdk.1.4 so I would have the right version of Java, complete with the JCE files needed for SSL. When I fire up the GUI, I get the following error The Java native library was not correctly loaded. You can work only with a pure Java based key database but not a CMS database If you click on OK, the GUI keeps running, but if you pull down the Key Database File menu, CMS of course is not an option. The procedures for setting up a repository on UNIX in the security manual tells you to select CMS. Any ideas out there? Thanks Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive -- 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
Re: Problem with clearing a queue
Hello Gina, I had this problem just today -- looks like it is contagious :-) Stop channels, enable 'get' on the queue and remove all messages. Then restart channels (I also had to reset sender although I am not sure if I had to use ALTER QLOCAL(xmit.queue.name) GET(enabled) FORCE. And you cannot use amqsget because it does not remove truncated messages. I have a program of my own that does it (accepting truncated messages). I am not sure if this is the right way; anyone who knows the recommended way of solving the problem, please let me know (my problem was that the user had to change a downstream queue manager to another one and they made the previous queue manager inavailable first thing :-). So some messages got stuck in the transmission queue with the old XMITQ header). Hope this will help, Pavel [EMAIL PROTECTED] .NET To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: Problem with clearing a queue [EMAIL PROTECTED] n.AC.AT 05/26/2004 11:17 AM Please respond to MQSeries List How about using 'rsvmqtrn' to either commit or back out the UoW?? ---I dont think you can use rsvmqtrn as it is used only if you have a transaction that is indoubt when you are doing a 2-phase commit. clear qlocal(OS4MQSP1) AMQ8143: WebSphere MQ queue not empty. Has any seen this? Any recommendations? ---Gina, as already mentioned, there seems to be a UOW that is indoubt. Did you get any error messages in your error log. Usually you would see something like, the last batch of messages was not sent. And this happens because of the message sequence number. Usually again, with large messages. Since the MCA has to send all of them within a UOW. By the way, did the Channel go down by itself or was it stopped. Did it at any point in time go into retry state. Any Fd's on either system. Cheers Kumar Ken Woloschuk [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 05/25/2004 09:08 AM Please respond to woloschuk To: [EMAIL PROTECTED] cc: Subject: Re: Problem with clearing a queue How about using 'rsvmqtrn' to either commit or back out the UoW?? -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 05:26 To: [EMAIL PROTECTED] Subject: Re: Problem with clearing a queue Gina, Sounds like the channel is Indoubt. Resolve the channel with the BACKOUT option. Then see if you can clear the queue. If this works i think you will need to reset the sequence number before starting the channel back up. Gina McCarthy [EMAIL PROTECTED]To: [EMAIL PROTECTED] .COMcc: Sent by: MQSeriesSubject: Re: Problem with clearing a queue List [EMAIL PROTECTED] n.AC.AT 05/25/2004 07:13 AM Please respond to gimccarthy Bill, Thanks for your response. The reason why I didn't get the 'in use' message is because the channel is down. There are no ipprocs/opprocs. The get/put are both enabled. I even went as far as to change the usage to normal...nothing is working. Regards, Gina -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, May 24, 2004 5:36 PM To: [EMAIL PROTECTED] Subject: Re: Problem with clearing a queue Well, for one thing, if the channel is still running, it has the transmit queue open for exclusive use. That means no other application can open the queue for input (to get messages). If the channel is stopped, It would have disabled gets on the queue when it went down, which has the same effect. You would have to re-enable gets on the queue before you can clear it. That said about xmit queues, I am surprised at the error, I would expect something different, like queue in use or something similar. Anyway, you may want to try ensuring the channel is down (stopped) and then use MQSC commands to re-enable the get attribute on the queue and see if that helps. 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/ Gina McCarthy [EMAIL PROTECTED]To: [EMAIL PROTECTED] .comcc: Sent by: MQSeriesSubject: Problem with clearing a queue List [EMAIL PROTECTED]
Re: Problem with clearing a queue
Thanks Bill, I will look into it. My sample program has a lot of options, too (20 or so :-)). Unfortunately, I built it with the dependencies on the company's code, otherwise I would have submitted it as a support pack :-(. Pavel Bill Anderson [EMAIL PROTECTED]To: [EMAIL PROTECTED] TA.AERO cc: Sent by: MQSeriesSubject: Re: Problem with clearing a queue List [EMAIL PROTECTED] n.AC.AT 05/26/2004 01:44 PM Please respond to MQSeries List Support Pack MA01 is a much better choice than any of the sample programs such as amqsget. It can connect as a client or server and has enough command line options to make you dizzy. I use it allot, especially to move (or copy) messages from one queue to another. 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/ Pavel Tolkachev pavel.tolkachev@To: [EMAIL PROTECTED] DB.COM cc: Sent by: MQSeriesSubject: Re: Problem with clearing a queue List [EMAIL PROTECTED] N.AC.AT 05/26/2004 01:15 PM Please respond to MQSeries List Hello Gina, I had this problem just today -- looks like it is contagious :-) Stop channels, enable 'get' on the queue and remove all messages. Then restart channels (I also had to reset sender although I am not sure if I had to use ALTER QLOCAL(xmit.queue.name) GET(enabled) FORCE. And you cannot use amqsget because it does not remove truncated messages. I have a program of my own that does it (accepting truncated messages). I am not sure if this is the right way; anyone who knows the recommended way of solving the problem, please let me know (my problem was that the user had to change a downstream queue manager to another one and they made the previous queue manager inavailable first thing :-). So some messages got stuck in the transmission queue with the old XMITQ header). Hope this will help, Pavel [EMAIL PROTECTED] .NET To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: Problem with clearing a queue [EMAIL PROTECTED] n.AC.AT 05/26/2004 11:17 AM Please respond to MQSeries List How about using 'rsvmqtrn' to either commit or back out the UoW?? ---I dont think you can use rsvmqtrn as it is used only if you have a transaction that is indoubt when you are doing a 2-phase commit. clear qlocal(OS4MQSP1) AMQ8143: WebSphere MQ queue not empty. Has any seen this? Any recommendations? ---Gina, as already mentioned, there seems to be a UOW that is indoubt. Did you get any error messages in your error log. Usually you would see something like, the last batch of messages was not sent. And this happens because of the message sequence number. Usually again, with large messages. Since the MCA has to send all of them within a UOW. By the way, did the Channel go down by itself or was it stopped. Did it at any point in time go into retry state. Any Fd's on either system. Cheers Kumar Ken Woloschuk [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 05/25/2004 09:08 AM Please respond to woloschuk To: [EMAIL PROTECTED] cc: Subject: Re: Problem with clearing a queue How about using 'rsvmqtrn' to either commit or back out the UoW?? -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 05:26 To: [EMAIL PROTECTED] Subject: Re: Problem with clearing a queue Gina, Sounds like the channel is Indoubt. Resolve the channel with the BACKOUT option. Then see if you can clear the queue. If this works i think you will need to reset the sequence number before starting the channel back up. Gina McCarthy [EMAIL PROTECTED]To: [EMAIL PROTECTED] .COMcc: Sent by: MQSeriesSubject: Re: Problem with clearing a queue List [EMAIL PROTECTED] n.AC.AT 05/25/2004 07:13 AM
Re: SSL Ciphersuites supported by WMQ
Hello Lee, Your 3rd choice should be the most secure and your 1st choice will be the fastest (I would expect CPU load lower in 3 times or more -- but please don't hold me on this) and supposedly less secure (due to the suspected vulnerabilities with RC4 (there were no successful attack known agains 128-bit RC4 though, AFAIK). MD5 is usually considered weaker than SHA1, but there is no known successful attack either and it is less probable and less potentially harmful than against RC4. If you use cryptographic hardware, of course (MQ supports it, AFAIK), all my time estimates are not applicable. Hope this will help, Pavel Lee Wheaton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: SSL Ciphersuites supported by WMQ [EMAIL PROTECTED] n.AC.AT 05/24/2004 06:44 PM Please respond to MQSeries List Hi, We've been looking at the list of SSL Ciphersuites supported by WMQ that have 128+ bit encryption. There are three ciphersuites on the list that meet our criteria: CipherSpec CipherSuite RC4_MD5_US:SSL_RSA_WITH_RC4_128_MD5 RC4_SHA_US:SSL_RSA_WITH_RC4_128_SHA TRIPLE_DES_SHA_US SSL_RSA_WITH_3DES_EDE_CBC_SHA We want to implement SSL on a MQ svrconn channel, and would like to know if there is a particular advantage in using one ciphersuite over another (e.g. best of breed, performance). In addition, we are currently using a SSL cert on our IIS website that has a signature algorithm of MD5RSA. Does anyone know if MD5RSA matches the RC4_MD5_US cipherspec? Any feedback would be appreciated. Thanks. Lee Wheaton MT Bank 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
Re: SSL channels and Self Signed certificates
Hello Neil, I am not sure I remember whether or not you have to restart queue manager, however, it sounds to like your procedure of adding an additional queue manager was not supposed to work (unless you omitted something in your description). Namely, you did not mention you added the certificates of CAs you used for other queue managers' to the new queue manager's key database as trusted certificates. So, your new queue manager might not trust to others. Also, you may want to consider to simplify your procedure by creating a separate CA key database and avoiding the creation of self-signed certificate in the future. This way, you will not have to cross-add CA's certificates to all key datastores, instead just add it to the new database (that is how PKI is supposed to work best AFAIK). Also, because gsk6cmd is a pretty sluggish animal, you may consider spending time once and creating an empty keystore with only you CA certificate in it (I mean, really empty, with all those standard CAs like Verisign removed). Then, for every new queue manager you can copy that keystore and use it as a boilerplate. Hope this will help, Pavel Neil Casey [EMAIL PROTECTED]To: [EMAIL PROTECTED] NAL.COM.AU cc: Sent by: MQSeriesSubject: SSL channels and Self Signed certificates List [EMAIL PROTECTED] n.AC.AT 05/21/2004 02:51 AM Please respond to MQSeries List Hi folks, I am setting up a cluster of machines using SSL channels with self-signed certificates (don't ask). It's all on Solaris, so I am using gsk6ikm and gsk6cmd. My channels are defined with mcatype(thread) and I am using the threaded listener. I initially created certificate stores and personal certificates for my repository systems, and cross added the certs as CA certs into the respective key databases. I set up the queue managers repositories, defined the cluster receivers and cluster senders with the sslpeer values and cipher specs, and everything started up Ok (Hooray!). I now have a cluster with three repos queue managers, using SSL channels I then tried to join a different queue manager into the cluster. I followed the same procedure, create the key database, the self signed cert, export the cert, add it into each of the other systems key dbs as a trusted CA cert. The static cluster sender channel won't start, so the new queue manager can't join the cluster. The manual says that certificate changes are available immediately, but that changes to the key database via alter qmgr may require a restart (if the channels have already been used). I have checked the certficate fingerprints etc, and everything looks Ok, but MQ fails the channel start with AMQ9633: Bad SSL certificate for channel ''. Now to my question: Has anyone tried this sort of thing? Is a queue manager restart required in order to get MQ to start looking at new CA certs? Neil Casey National Australia Bank Southern Star Technology WebSphere MQ Support 1/122 Lewis Rd Wantirna South office. +61 3 9886 2375 (x82375) mobile. +61 414 615 334 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
Re: Problems building MQSeries Perl module on W2K
Hello Tony, One of the problems seems to be related to the unfortunate MQ installation path (in the directory whose name contains spaces, Program Files). Try to go via scripts and check where it comes from (it may also come from registry in which case it may become trickier -- but try to use dos aliases like Progra~1 or whatever.. I do not have an exact answer, you will have to research along these lines). Hope this will help, at least partially, Pavel Bill Anderson [EMAIL PROTECTED]To: [EMAIL PROTECTED] TA.AERO cc: Sent by: MQSeriesSubject: Re: Problems building MQSeries Perl module on W2K List [EMAIL PROTECTED] n.AC.AT 05/19/2004 02:28 PM Please respond to MQSeries List I installed perl for MQ on a windows machine a couple of years ago, and it gave me a great amount of grief also. The problem had to do with the way my compiler was configured, but I don't recall the details there. But I contacted the folks that maintain the perl MQ stuff on CPAN to get the answer to my problem. They responded quick, with very detailed instructions on what I needed to do. I don't understand why they don't include such things in the docs for that module, because the installation on windows is NOT as straight forward as the instructions say. I understand this is not an easy option for lots of folks, and it borders on religious beliefs people have concerning technology, but if you trash your Microsoft stuff and install Linux, the problem will also go away :)~ Sorry, just had to say that 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/ Antony Boggis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: Problems building MQSeries Perl module on W2K [EMAIL PROTECTED] N.AC.AT 05/19/2004 11:21 AM Please respond to MQSeries List First thing... If Perl.exe nmake.exe aren't on your path, as they say on tv make it so. I have successfully built the MQ CPAN Perl stuff on NT. *HOWEVER* there are a couple (and I stress a couple) of bugs. The Perl stuff assumes a Unix environment and makes all sorts of assumptions (expecially regarding the INI files) based on that. So, don't rely on any of the routines that read the error logs - they may (or may not) work. Otherwise the rest of the stuff seems to work. tonyB. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Gurney, Matthew Sent: Monday, May 17, 2004 10:46 AM To: [EMAIL PROTECTED] Subject: Problems building MQSeries Perl module on W2K I am having some problems installing the MQSeries Perl Module on W2K. Perl V5.6.0 seems to be working ok, the samples work. I can't build the mqseries perl module. The instructions state: 1) perl Makefile.PL 2) make 3) make test 4) make install When I do step 1, I get, the following, does this mean there is a problem? D:\MQPerl\MQSeries-1.23perl makefile.pl Unable to find a perl 5 (by these names: D:\Program Files\Perl\bin\Perl.exe miniperl perl perl5 perl5.6.0, in these dirs : D:\mqm\bin D:\mqm\java\bin D:\Program Files\Perl\bin C:\BAB\CMQ20\BIN D:\Program Files\MQSeries\bin D:\Program Files\P erl\bin) Note (probably harmless): No library found for '-lmqicg' Note (probably harmless): No library found for '-lmqic' Note (probably harmless): No library found for '-lmqmcs' Note (probably harmless): No library found for '-lmqmzse' Note (probably harmless): No library found for 'oldnames.lib' Note (probably harmless): No library found for 'kernel32.lib' Note (probably harmless): No library found for 'user32.lib' Note (probably harmless): No library found for 'gdi32.lib' Note (probably harmless): No library found for 'winspool.lib' Note (probably harmless): No library found for 'comdlg32.lib' Note (probably harmless): No library found for 'advapi32.lib' Note (probably harmless): No library found for 'shell32.lib' Note (probably harmless): No library found for 'ole32.lib' Note (probably harmless): No library found for 'oleaut32.lib' Note (probably harmless): No library found for 'netapi32.lib' Note (probably harmless): No library found for 'uuid.lib' Note (probably harmless): No library found for 'wsock32.lib' Note (probably harmless): No library found for 'mpr.lib' Note (probably harmless): No library found for 'winmm.lib' Note (probably harmless): No library
Re: How to ensure an order in messages.
Hello Nguyen, You can, if all of the following is true in addition to the messages being of same priority; 1. Both messages are put using same connection handle. 2. MQPUT calls completed successfully 3. There is no dead letter queue on any queue manager on the way of the message if the queue is remote 4. The queue is not a shared cluster queue. Thanks, Pavel Nguyen DT [EMAIL PROTECTED]To: [EMAIL PROTECTED] FRANCE.COM cc: Sent by: MQSeriesSubject: How to ensure an order in messages. List [EMAIL PROTECTED] .AT 05/17/2004 04:54 AM Please respond to MQSeries List Without using any mechanism , can i be sure that if i put the message in time x , an other in time x+1 , and they use the same priority - An application which process the queue will get x before x+1 ? What is a mecanism to ensure the order ? Thank you very much 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
Re: Java Clients and Security Hole???
Hello Kumar, Client applications ask channel agents to do their job on their behalf. Channel agent's MCAUSER attribute is what matters for the authorization in this case; for more information, see System Administration Guide, Clients and Intercommunication books; to authenticate your client app to the channel, use SSL or a channel security exit. Hope this will help, Pavel mqonnet [EMAIL PROTECTED]To: [EMAIL PROTECTED] E.NET cc: Sent by: MQSeriesSubject: Java Clients and Security Hole??? List [EMAIL PROTECTED] n.AC.AT 05/16/2004 09:06 AM Please respond to MQSeries List Hello Mq'ers, The scenario is like this: System A has MQ Server installed. System B has MQ Client installed. Both are on w2k with MQ 5.3, with or without csd's dont think it matters. I logon to system B with userid FRED who is in the mqm group on System B. I defined a userid/principal on System A named FRED. Did *NOT* assign this userid *any* groups. Just setmqaut'd this userid to accept connection on the queue manager. setmqaut -m QM1 -t qmgr -p FRED +connect. I defined a local queue, TEST on the qmgr on System A. Did *NOT* assign *ANY* authorities to userid FRED to access this queue on System A. Which would mean, userid FRED should be able to connect to qmgr QM1 but should NOT be able to open TEST queue. On System B, i have 2 test scenarios. 1) I run amqsputc TEST QM1. Connects fine, but mqopen fails with 2035 as expected. 2) I run a java MQ client app. Connects, opens, puts, closes and disconnects the queue just fine. This is what i believe is the security hole. And i believe it comes off the statement made in the Clients manual, Part 3, Chapter 7, under Access Control. Which says. For Java client connections, if the client application does not provide a user ID then no client user identification is provided to the server. The above statement is what really bugs me. I see this as a major security hole. And i would believe IBM must have some strong theory for keeping it likewise, which obviously MUST already be know to IBM. Anyone on this forum or anyone from IBM throw some light on this??? To add to all this, i ran a trace on the server system A. Guess what. Amqsputc sends in userid FRED for authentication purposes as expected. But the java client sends in userid EntityName Administrato. I believe the implementation of the above comes from another statement made in the same manual as described above. However, for the clients that use the MQ_USER_ID environment variable to supply the user ID, it is possible that no environment variable is set. In this case, the user ID that started the server-connection channel is used. Just a guess. Any thoughts, anybody. Cheers Kumar (Embedded image moved to file: pic00041.gif) IncrediMail - Email has finally evolved - Click Here -- 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. attachment: pic00041.gif
Re: Connection error
Hello Bobbee, I believe this means that the client machine closes the socket (I guess, preliminary, from the application protocol (MQI over TCP) point of view). Hope this will help, Pavel Robert Broderick [EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM cc: Sent by: MQSeries Subject: Connection error List [EMAIL PROTECTED] .AC.AT 05/10/2004 10:54 AM Please respond to MQSeries List I am getting mucho of the following. Anything I should look at ??. Is this where the client machine just ends the session?? bobbee 05/10/04 09:24:38 AMQ9208: Error on receive from host xx.xx.xx.xxx. (TCP/IP was a client machine) EXPLANATION: An error occurred receiving data from xx.xx.xx.xxx (This was a client machine) over TCP/IP. This may be due to a communications failure. ACTION: The return code from the TCP/IP (read) call was 73 (X'49'). Record these values and tell the systems administrator. #define ECONNRESET 73 /* Connection reset by peer */ _ MSN Toolbar provides one-click access to Hotmail from any Web page FREE download! http://toolbar.msn.com/go/onm00200413ave/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 -- 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
Re: Application seeing 2009 (MQRC_CONNECTION_BROKEN) errors...
Hello My understanding was, neither Miroslav nor Tony are using any channels. Also, wouldn't it be an FDC if this were the case? Pavel Emile Kearns [EMAIL PROTECTED]To: [EMAIL PROTECTED] TEMS.CO.ZAcc: Sent by: MQSeries Subject: Re: Application seeing 2009 (MQRC_CONNECTION_BROKEN) errors... List [EMAIL PROTECTED] AC.AT 05/07/2004 08:19 AM Please respond to MQSeries List My five cents, are you not maybe reaching the maxchannels limits? -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of David C. Partridge Sent: 07 May 2004 01:15 PM To: [EMAIL PROTECTED] Subject: Re: Application seeing 2009 (MQRC_CONNECTION_BROKEN) errors... Another point here. By any chance are you seeing Internal Error FDCs (e.g. too many open files)? If so you should probably review your kernel settings - see the MQ Quick Beginnings manual for Solaris. 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 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 -- 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
Re: Backout of failed a C++ Application
Thanks Peter! Really nice support pack! Thank Paul and Morag for taking time for this elucidative job. The only part of the paper I was not quite comfortable with was that omnipresent define-your-dead-letter-queue recommendation and the stipulation that an application expecting message order guarantees from its queues 'out-of-box' is lazy. Now that the channels are cheaper (thread channels work much better and have less limitations in MQ 5.3) I would at least expect the alternative (have-a-separate-channel-for-each-remote-queue-or-at-least-app) presented as a viable and solid one, not as a marginal trend. Pavel Potkay, Peter M (PLC, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Re: Backout of failed a C++ Application Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 05/01/2004 09:56 AM Please respond to MQSeries List Pavel, It is true Heartbeats only flow during an MQGET with wait for clients. But the HeartBeat Interval comes into play on ALL MQ API calls made by an MQ Client application. Basically, for all calls that an MQ Client makes, the system will use the HBInterval to determine how long to wait for something before assuming the connection is broken and returning 2009. On a MQGET with wait, since there may be a long period of time before something (the message) flows over the channel, MQ pumps Heartbeats (based on the HB setting of the channel). But on all other calls, the result of the call from the MQ Server is expected, and serves as the Heartbeat. The receiver will actually time-out if no data (the message or the result of the call) is received within twice the Heartbeat interval if the negotiated Heartbeat Interval is less than 60 seconds, or 60 seconds beyond the negotiated heartbeat interval if it is greater than or equal to 60 seconds, by default, before assuming there has been a communications failure. I found out the above just this week in Morag's and Paul's doc on channels: http://www-1.ibm.com/support/docview.wss?rs=203uid=swg24006699loc=en_UScs =utf-8lang=en -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Friday, April 30, 2004 11:47 PM To: [EMAIL PROTECTED] Subject: Re: Backout of failed a C++ Application Hello Neil, If this is a TCP client, this is possible (that connection on a server outlives the client app). Try to play with keepalive (I am not sure what is the default timeout on Windows though; on Solaris, it is set machine-wide and the default is sometimes 2 hours). You can try to set HBINT but this will not work unless client crashes while waiting for a message in MQGET -- but it worth to do, anyway for it will make transaction back out faster. Hope this will help, Pavel --- Can anyone explain what should happen if the above application has got a message under syncpoint and then crashes. Logically I know that the message should re-appear on the queue, especially if a disconnect is issued, but I'm wondering how the qmanager knows that the application has died and that the connection handle should be removed from its pool and any uncommitted work backed out. Is it possible that the connection handle survives the unplanned termination of the applciation, and therefore does not release the handle and backout those uncomitted messages? The scenario here is that messages do not appear to be returned to the queue when the app fails. Of course there may be another reason for this, though the app code I have seen does not appear to rollback any messages or dump them on the DLQ. Upon an app restart, there is knowledge of the messages previously conusumed but not yet committed. There is only one instance of the application, we believe. MQ Version is 5.2.1 I believe, platform Windows 2000 or similar. MQ clusters are in place though I'm led to believe that affinities exist and are catered for, as in this case. Any views appreciated. Neil -- 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 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
Re: Backout of failed a C++ Application
Hello Neil, If this is a TCP client, this is possible (that connection on a server outlives the client app). Try to play with keepalive (I am not sure what is the default timeout on Windows though; on Solaris, it is set machine-wide and the default is sometimes 2 hours). You can try to set HBINT but this will not work unless client crashes while waiting for a message in MQGET -- but it worth to do, anyway for it will make transaction back out faster. Hope this will help, Pavel --- Can anyone explain what should happen if the above application has got a message under syncpoint and then crashes. Logically I know that the message should re-appear on the queue, especially if a disconnect is issued, but I'm wondering how the qmanager knows that the application has died and that the connection handle should be removed from its pool and any uncommitted work backed out. Is it possible that the connection handle survives the unplanned termination of the applciation, and therefore does not release the handle and backout those uncomitted messages? The scenario here is that messages do not appear to be returned to the queue when the app fails. Of course there may be another reason for this, though the app code I have seen does not appear to rollback any messages or dump them on the DLQ. Upon an app restart, there is knowledge of the messages previously conusumed but not yet committed. There is only one instance of the application, we believe. MQ Version is 5.2.1 I believe, platform Windows 2000 or similar. MQ clusters are in place though I'm led to believe that affinities exist and are catered for, as in this case. Any views appreciated. Neil -- 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
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
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
Re: WebSphere MQ client recovery
Hello Paul, Usha: I disagree with everyone :-). Or rather, I more like agree to Brian, but I would like to try to answer Usha's questions again, from the beginning: 2. For verifying the data are same, make some CRC32 (or, if the client is really crazy, SHA1) hash of the data and store them on the client site in the log, together with a nice (meaning, hexadecimal) print of message id). Do same on the receiving side and then, after reconciliation with the receiving application do not remove log files before client has signed this off -- or 7 those years has expired (why 7 years -- because you can always justify media and CPU time costs by regulatory requirements to log everything...). 1. 1.1. If you use only MQ API, Paul is right -- there is no principal difference between client and server just the time window during which you may enter in-doubt situation (the term is used here not in specific MQ-channel but in more general transacted sense) is narrower with for server app. 1.2. However, I know people who use XA api (or JTA, in Java) *not* for the purpose of coordinating distributed transaction but for the sole purpose of avoiding an automatically irrecoverable in-doubt state (not with MQ though). For that, they use xa_... calls (in C) or JTA's XAResource methods (in Java), and store Xids persistently on the disk before committing -- and also they record the result of the commit. Then, if commit results are not logged, it is always possible to try to join the last XA transaction and see if it was rolled back or actually committed. To go this way, you will actually need MQ Server or transactional client, as Brian explained. I am not sure you can do it with C application and MQ -- I have never heard of anyone managed to call xa_.. method directly using any MQ C library, but I am pretty sure you can do this with MQ JMS provider (it has some XA... factories from which you can get Connections from which you can get XASessions from which you can get .. UFFF, XAResource). I believe you will have to play with some native libraries actually providing XA interface before you get it working though. I do not really know about pure MQ, i.e. non-JMS Java client. Hope this will help more than confuse, Pavel Paul Clarke [EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM cc: Sent by: MQSeriesSubject: Re: WebSphere MQ client recovery List [EMAIL PROTECTED] n.AC.AT 04/27/2004 04:32 PM Please respond to MQSeries List Brian, I'm afraid I don't agree with your comments Brian. If you're doing just messaging (no databases involved) then the way you would code the application for a client would be exactly the same as for a local application. You do not have to write any special code just because you're running as a client. We have gone to considerable lengths to ensure that the behaviour of an application running as a client is the same as a local app. A client (the free one) is quite at liberty to use transactions (SYNCPOINT verbs) and MQCMIT/MQBACK and using these can ensure that messages are processed once and only once even in times of failure. As I said in my previous note, if databases are involved (ie XA transactions) then you will need the transactional client rather than the free one but again, I would not expect the client version of the application to have any extra code. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Brian S.| | | Crabtree| | | [EMAIL PROTECTED]| | | K.NET | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 27/04/2004 20:36 | | | Please respond to| | | MQSeries List| |-+ | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: WebSphere MQ client recovery | |
Re: SSL and certificate expiry
For the first question, I usually designate 10 years. Pavel Lawrence Coombs [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: Re: SSL and certificate expiry List [EMAIL PROTECTED] n.AC.AT 04/23/2004 12:53 PM Please respond to MQSeries List Anyone care to share the lifetime they assign to a certificate used by a queue manager that has SSL channels? Also, how do you handle certificates expiring when a OS/390 queue manager communicates with many distributed queue managers? 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
Re: Reading messages by JMSCorrelationID
Hello Dennis, You may want to look into JMS selectors. E.g., see http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Session.html#createConsumer(javax.jms.Destination,%20java.lang.String) Hope this will help, Pavel Dennis Bryngelson [EMAIL PROTECTED]To: [EMAIL PROTECTED] RDLIFE.COM cc: Sent by: MQSeries List Subject: Reading messages by JMSCorrelationID [EMAIL PROTECTED] 04/16/2004 11:54 AM Please respond to MQSeries List Good Morning, Does anyone have input on how to read the messages by JMSCorrelationID, I am new to JMS and can't seem to get this to work other than first receiving the message and then reading for the correlation id, for example: TextMessage xxx = (TextMessage)qReciever.receive(); zzz = ((JMSMessage)xxx).getJMDCorrelationId(); Any help or direction will be greatly appreciated! Steve Lashinski Middleware Hartford Life Woodbury: (651)738-4307 Plymouth: (763)765-4002 * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/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 e-mail, 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 -- 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
Re: Reading messages by JMSCorrelationID
Hello Dennis, You can look at http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Session.html#createBrowser(javax.jms.Queue,%20java.lang.String), same page. The second (String) argument of the function is the Selector. For example, selector may be: JMSCorrelationID = 'very-important-garbage-message-321' Make sure that the corr. id is actually a String in your Provider.. Hope this will help, Pavel Dennis Bryngelson [EMAIL PROTECTED]To: [EMAIL PROTECTED] RDLIFE.COM cc: Sent by: MQSeries List Subject: Re: Reading messages by JMSCorrelationID [EMAIL PROTECTED] 04/16/2004 03:02 PM Please respond to MQSeries List Has anyone used the QueueBrowser of JMS to read by correlation ID, if so can you give me some pointers on how to get this to work. Thanks much, Steve Lashinski Middleware Hartford Life Woodbury: (651)738-4307 Plymouth: (763)765-4002 |-+ | | Pavel Tolkachev | | | pavel.tolkachev@| | | DB.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 04/16/2004 11:30 | | | AM | | | Please respond to| | | MQSeries List| | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Reading messages by JMSCorrelationID | --| Hello Dennis, You may want to look into JMS selectors. E.g., see http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Session.html#createConsumer(javax.jms.Destination,%20java.lang.String) Hope this will help, Pavel Dennis Bryngelson [EMAIL PROTECTED]To: [EMAIL PROTECTED] RDLIFE.COM cc: Sent by: MQSeries List Subject: Reading messages by JMSCorrelationID [EMAIL PROTECTED] 04/16/2004 11:54 AM Please respond to MQSeries List Good Morning, Does anyone have input on how to read the messages by JMSCorrelationID, I am new to JMS and can't seem to get this to work other than first receiving the message and then reading for the correlation id, for example: TextMessage xxx = (TextMessage)qReciever.receive(); zzz = ((JMSMessage)xxx).getJMDCorrelationId(); Any help or direction will be greatly appreciated! Steve Lashinski Middleware Hartford Life Woodbury: (651)738-4307 Plymouth: (763)765-4002 * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/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 e-mail, 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 -- 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
Re: MQ Security data in SYSTEM.AUTH.DATA.QUEUE
Hello T.Rob, I do not believe it is possible unless you are root. The way for the process to change its group id is to change the memory in the process header belonging to the kernel (there is no Unix system call for that -- at least I am not aware; setgid() issued by a non-root user will only change to saved or real group id). This can only be done by root, and the way for the process belonging to the regular user to promote to the root is to exec setuid-ed command -- and after exec() there is no way back :-). newgrp is such a setuid-ed trusted command. Of course it is possible for root to change any memory inside another process (risking race condition) and, there are even some system-dependent ways to do it safe: in Solaris, for example, you can write a PCSCRED message to the process's 'ctl' file -- but, again, you have to be root.. You can write a program using such method and clear it with your Unix Administration for installing as a trusted executable -- whether you try to do it or not usually depends on how badly you need it. :-) To be 'safe', such program might, for example, read '/etc/group' file and make sure one of uid's (or just effective uid) of the process actually belongs to the the group you want to change to. Hope this will help, Pavel Wyatt, T. Rob [EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeries Subject: Re: MQ Security data in SYSTEM.AUTH.DATA.QUEUE List [EMAIL PROTECTED] C.AT 04/05/2004 10:31 AM Please respond to MQSeries List Rao, Use the id command to display your currently set active group. This should be the group that is used to make the second entry. Try doing a newgrp to change your active group before creating the queue and see if it makes the second entry in the newly selected group. If you newgrp mqm there should be no second entry. If you create your queues from script files, you cannot simply add a newgrp mqm command to the file. Doing a newgrp always results in a new shell that ignores the rest of the script. If anyone knows of a syntax that allows execution of newgrp from within a script, please let me know! -- T.Rob -Original Message- From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Sunday, April 04, 2004 5:51 PM To: [EMAIL PROTECTED] Subject: MQ Security data in SYSTEM.AUTH.DATA.QUEUE I am trying to analyse the entries in the above queue on SOLARIS platform with MQ V5.3 CSD6. What I am noticing is when I create an object such as local queue, MQ by default, is generating two authorisation entries - one for mqm group and another for one of my other group-ids but not all the groups that I belong to. On this particular box my user-id is connected to three groups - mqm, group1, group2. Where as MQ is creating authorisation entries for mqm and group1 but NOT group2. Where as if I do sudo su - mqm and create an object, then I can see only one authorisation entry for mqm group. Similarly when a solaris administrator logs on as root and create objects, I see only two entries - one for mqm and another for other. Even here the root is associated with more than these two groups. Looks like it is always generating TWO entries - one for mqm and another for one of the associated groups (but not all and in what order it selects - beats me). Appreciate if anybody can throw some light on how it works. Is the behaviour is same on Windows platform (I am still analysing it but at the outset doesn't look like the same). And also appreciate any advise on how to clean up all other entries barring mqm group. I am thinking of unloading these entries in to a txt file, delete unwanted entries and load back. Then the plan is to grant controlled access to the users. Cheers Rao 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. -- 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
Re: AW: Boot problem on Solaris: solved but HOW?
Hello,
Thanks to all who answered!
Hubert, thank you, we have it working as well. What we (Ian and I) could not do is to
reproduce the problem in a normal (not boot-up) mode to understand its root cause.
Tibor, we did not try the early tracing. I am not sure what more information from the
script itself I need. We had a pretty good error message from strmqm complaining about
not being authorized and the error status (not documented, though: 119. Anyone from
IBM?).
Gunter, thanks, yes it was one of the last resort ideas to go and compare all the
environment -- but I think we have never actually done that. We will try it next time
we reboot.
Ian, I am not sure why you did not get messages. We created /var/mqm/init_d.log or
some similar file at the beginning of the start script, changed its ownership to
mqm:mqm and then appended to it the output of all commands, approximately in this
manner:
echo will run strmqm... $logFile
strmqm ... $logFile 21
rc=$?
echo error status $rc $logFile
So we had all the output in the log file.
I will let the list know if I find the answer..
Cheers,
Pavel
Kleinmanns,
HubertTo: [EMAIL PROTECTED]
Hubert.Kleinmanns@cc:
DREGIS.COMSubject: AW: Boot problem on
Solaris: solved but HOW?
Sent by: MQSeries
List
[EMAIL PROTECTED]
AC.AT
04/02/2004 04:34 AM
Please respond to
MQSeries List
Hi Pavel, Ian,
the following script starts my queue manager at boot time on Solaris:
#!/bin/ksh
#
# MQSeries start/stop script
#
case $1 in
start)
echo Starting MQSeries daemons
su - mqm -c /opt/mqm/bin/strmqm TESTQM
su - mqm -c /opt/mqm/bin/strmqcsv TESTQM
;;
stop)
echo Stopping MQSeries daemons
su - mqm -c /opt/mqm/bin/endmqm -i TESTQM
;;
restart)
$0 stop
$0 start
;;
*)
echo Usage: $0 {start|stop|restart}
exit 1
;;
esac
exit 0
On AIX just replace opt by usr. I put this file to the directory
/etc/init.d with name mqm and set up th following links:
# ln -s /etc/init.d/mqm /etc/rc1.d/K18mqm
# ln -s /etc/init.d/mqm /etc/rc2.d/S94mqm
Regards
Hubert
-Ursprungliche Nachricht-
Von: Chan, Ian M [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 2. April 2004 02:19
An: [EMAIL PROTECTED]
Betreff: Re: Boot problem on Solaris: solved but HOW?
Pavel,
I want to know the answer too!
We have the same problem on Sun Solaris and did the same thing to solve it
after upgrading to v5.3 (it works in v5.2 without su mqm). There is even no
error message produced in our case. MQ just not started after reboot. We
have AIX running MQ v5.3 and startup script works OK even without su mqm.
So as mentioned in the FAQ, it only affects Solaris and some Linux.
Cheers,
Ian
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel
Tolkachev
Sent: Friday, 2 April 2004 9:26 AM
To: [EMAIL PROTECTED]
Subject: Boot problem on Solaris: solved but HOW?
Hello,
We had a problem -- with starting MQSeries 5.3 at bootup on Solaris --
actually exactly FAQ problem described in
http://www.developer.ibm.com/tech/faq/results/0,1322,1%253A401%253A411%253A1
0%253Amq,00.html#q10
and we solved it all right as FAQ suggested. What drives me crazy, however,
is that the problem itself could not be reproduced from the regular command
prompt, no matter what command prompt it was. I have sudo root access on the
machine and I tried all the ways of creating the process context similar to
the boot environment -- like
sudo su
sudo su -,
sudo sh,
sudo ksh
sudo ksh, then su -
etc. etc. etc.
We checked euid,egid,uid,gid and everything -- and all that was root and
system (most of the time) and still our startup scripts always worked fine
from the command line -- but not when system were booting (we added our root
in mqm group, that did not help either) -- and the simple trick in the FAQ
does the thing. I thought I knew Unix a little bit -- and now I am not sure
:-( ... Does anybody have an idea what is the root cause of the problem
described in the FAQ entry referred to above and how to reproduce it from
the command prompt? What is that in the environment that is different when
entering runlevel 3?
BTW, the error message we were getting from strmqm was actually different
from the one mentioned in the FAQ -- some error status 119 (not documented
in Sys Adm Guide).
Regards,
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
Re: VAX Security...
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 (See attached file: InterScan_Disclaimer.txt) 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. (See attached file: InterScan_Disclaimer.txt) 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. The following file(s) have been deleted by: Pavel Tolkachev on 4/1/2004 5:38:51 PM InterScan_Disclaimer.txt -- 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
Re: SSL
Hello Morag, The first link (Learn more about SSL) seems to be broken on the page... Have a nice day, Pavel Morag Hughson [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: SSL List [EMAIL PROTECTED] n.AC.AT 03/18/2004 11:32 AM Please respond to MQSeries List And I finally got it on-line. :-) http://www-306.ibm.com/software/integration/wmq/ssl.html Cheers Morag Morag Hughson WebSphere MQ for z/OS Development Telephone: +44 (0) 1962 816900 Internet: [EMAIL PROTECTED] Potkay, Peter M (PLC, IT) [EMAIL PROTECTED] To HARTFORD.COM [EMAIL PROTECTED] Sent by: MQSeries cc List [EMAIL PROTECTED] Subject N.AC.AT Re: SSL 15/03/2004 19:36 Please respond to MQSeries List Found the electronic copy. And since it is only 8K zipped, here it is: -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 12:49 PM To: [EMAIL PROTECTED] Subject: Re: SSL I while back there was link to a doc called How Secure are your channels? by Morag Hughson. I can't find the link, all I have is a paper copy of the doc, which is excellent. It explains how to SSL, and uses a z/OS Qm to AIX QM in the example. Maybe someone out there remebers this, and can post the link again. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 12:23 PM To: [EMAIL PROTECTED] Subject: Re: SSL It's a big topic. Look at the Security Guide 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 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 [attachment SSLIntroMorag.zip deleted by Morag Hughson/UK/IBM] 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
Re: WS-Reliable Messaging
Hello Paul, Thanks for the link -- it is definitely of interest of mine. The specification seems to define not an API but the data model for guaranteed message exchange (disregard the word reliable whose meaning has been long back eroded by many vendors, including some of the authors) and one particular binding for this model (SOAP-based). I do not think it has much to do with the current MQ under-the-hood transport protocols. Regards, Pavel Meekin, Paul [EMAIL PROTECTED]To: [EMAIL PROTECTED] GROUP.COM cc: Sent by: MQSeriesSubject: WS-Reliable Messaging List [EMAIL PROTECTED] n.AC.AT 03/17/2004 05:51 AM Please respond to MQSeries List Hi all, Anyone heard of Web Services Reliable Messaging Protocol and does it have anything to do with MQSeries? From the IBM website (http://www-106.ibm.com/developerworks/webservices/library/ws-rm/): This specification (WS-ReliableMessaging) describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. The updates are based upon the suggestions collected from the WS-ReliableMessaging Feedback Workshop held in July 2003 and the Interoperability Workshop help in October 2003. The protocol is described in this specification in an independent manner allowing it to be implemented using different network transport technologies. To support interoperable Web services, a SOAP binding is defined within this specification. I wonder if it's a JMS-like API that might be able to use MQ as a transport mechanism? Cheers, Paul 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
Re: Locking down MQ files/registry on Windows
Well, I have to disagree here. There is nothing in Windows architecture that would prevent people from doing their jobs without being admins, especially if you scrutinize a set of applications installed on production NT server as well as you do for Unix. I lean to the Rao's point of view: such is a problem of people, organizations and habits. One can always get everyone out of the box if s/he owns it; otherwise to review his or her SLA. It is just that people used to be able to install device drivers (and devices themselves) themselves on their windows boxes, instead of calling SAs -- and expect to have same level of control on servers (absolutely unjustifiably, IMHO. Try to do this with a production AIX box). Technically, NT has much better developed set of permissions and pre-defined policies, inherited from VMS (without much stripping as far as I can say with my very rudimentary memories of that one). Globalizing access accross the enterprise and synchronizing with the enterprise global directory works almost out of box with Active Directory and on Unix it takes a while to get a similar flexibility and security in access control (also depends on which exactly Unix it is). I am no way a Microsoft person; vice versa, I have always been trying to find an alternate way; not in last turn due to the security considerations: being on a sideline means being a less prominent target for a potential attacks to me. I am just trying to be objective to Microsoft's progressin the area: do not use IE or Outlook (who would do, on a server, anyway?) and you are as safe (or unsafe) as on Unix -- and have much better integrated security controls (not all of them free, though). Just my 2c Pavel Wyatt, T. Rob [EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeries Subject: Re: Locking down MQ files/registry on Windows List [EMAIL PROTECTED] C.AT 03/16/2004 08:57 AM Please respond to MQSeries List Rao, I think you are drawing the wrong conclusion. It's not that we have more people administering Windows servers in our organization, rather the architecture of Windows requires more people NOT in the admin team to have admin access in order to perform their jobs. On our Unix servers the application development and support teams generally do not have root but on windows boxes they typically must be local admin. Now if you classify anyone with local admin rights as being an administrator then yes, there are more of them on our Windows servers. But we don't think of it in those terms. We follow a separation-of-duties model where admins, developers and support personnel are supposed to be kept out of each other's domains such that no one person has the ability to modify, install and run Production code. In this model having to give local admin to anyone not in the admin team (such as a developer) is seen as a security risk because it is next to impossible to enforce a separation of duties. So when we are looking to host an application that will move cash around we try real hard to keep it off of Windows servers. And yes you are right that I'm not in Bill's camp although I have yet to put my money where my mouth is - I run a Windows 2000 domain at home. -- T.Rob -Original Message- From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 8:25 PM To: [EMAIL PROTECTED] Subject: Re: Locking down MQ files/registry on Windows Hi Rob I can see from your mail that you are not from Bill's camp (Microsoft). You your self admitting that there are more people supporting Windows servers than Unix servers in your organisation - which means either managing the windows are more complex than managing Unix boxes (don't get stressed on this statement) or Bill is quite good at creating more jobs (as an IT person I LOVE the idea). 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
Re: Locking down MQ files/registry on Windows
BTW, something that may work (but only against really stupid administrators :-) ): REGEDIT4 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System] DisableRegistryTools=dword:0001 Pavel Adiraju, Rao [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CO.NZ cc: Sent by: MQSeriesSubject: Re: Locking down MQ files/registry on Windows List [EMAIL PROTECTED] n.AC.AT 03/15/2004 08:25 PM Please respond to MQSeries List Hi Rob I can see from your mail that you are not from Bill's camp (Microsoft). You your self admitting that there are more people supporting Windows servers than Unix servers in your organisation - which means either managing the windows are more complex than managing Unix boxes (don't get stressed on this statement) or Bill is quite good at creating more jobs (as an IT person I LOVE the idea). In any case, the problem looks like with the people and not with the platform. Anyway I don't want to get in to unrelated (to this MQ forum) debate of WINDOWS versus UNIX bashing. Despite of my 20+ years experience on IBM mainframes (stating this to dispel any perceived allegiance to MS) and quite a number of years of MQ support on all three platforms (Windows, UNIX flavours, and Mainframes) I personally felt monitoring and visualisation tools are much better on Windows. Normally I logon to Microsoft Management Console for WebSphere MQ on my windows to see the health of MQ middleware across the enterprise rather than logging on to Unix or Main-frame boxes as first port of call. The same applies to BMC Patrol console, MQSI and many other tools. Cheers Rao Disclaimer - the above are purely my personal opinions. -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: 15 March 2004 5:08 AM To: [EMAIL PROTECTED] Subject: Re: Locking down MQ files/registry on Windows Rao, We have far fewer people who can log onto our Unix servers as root than we have local admins on any given Windows server. So for us at least, this alone makes it a LOT easier to secure a Unix QMgr. Add in all the inherent problems with Windows user security, viruses and worms, OS stability, throughput and scalability, and Unix boxes start to look a lot more competitive with Windows boxes in terms of total cost of ownership. -- T.Rob 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 -- 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
Re: Strange problem when compiling C on HP-UX
Hello Rick,
To be precise, # must be the first character in line to be recognized as a starting
character of a pre-processor directive :-)
Hope this will help,
Pavel
Roger Lacroix
[EMAIL PROTECTED]To: [EMAIL PROTECTED]
ALWARE.BIZ cc:
Sent by: MQSeries Subject: Re: Strange problem when
compiling C on HP-UX
List
[EMAIL PROTECTED]
C.AT
03/15/2004 04:56 PM
Please respond to
MQSeries List
Wooosh, from my programmer's toolkit comes the very handy and dandy AStyle
C/C++/Java code formatter.
You can download AStyle at (and I give it 10 out of 10 for making my life
easier):
http://astyle.sourceforge.net/
Some people code their programs very strangely (at least to me :) ), so I use
AStyle to get it into a more eye pleasing format.
i.e.
astyle --style=ansi -s3 amqsget0.c
Hope that helps.
Regards,
Roger Lacroix
Capitalware Inc.
http://www.capitalware.biz
Quoting Rick Tsujimoto [EMAIL PROTECTED]:
MQers,
I ran into a strange problem trying to compile amqsget.c on HP-UX 11.11.
The first couple of messages would look like:
(Bundled) cc: amqsget0.c, line 62: error 1000: Unexpected symbol: i.
(Bundled) cc: amqsget0.c, line 62: error 1002: Unexpected character: 'u'.
(Bundled) cc: amqsget0.c, line 62: error 1000: Unexpected symbol: .
(Bundled) cc: amqsget0.c, line 62: error 1000: Unexpected symbol: ..
(Bundled) cc: amqsget0.c, line 62: error 1000: Unexpected symbol: .
I had successfully compiled this program in the middle of last year and
hadn't touched it since then.
I then took a simple program:
#include time.h
#include stddef.h
main()
{
struct tm *ptr;
time_t lt;
char dtstr [20];
time(lt);
ptr=localtime(lt);
memset(dtstr, '\0', sizeof(dtstr));
strftime(dtstr,sizeof(dtstr),%m/%d/%Y %H:%M:%S, ptr);
printf(%s\n,dtstr);
}
and compiled it to see if it was problem with MQ code or C code. This
program compiled successfully.
But, then I made a slight change to it, where I shifted the first statement
(#include time.h) over by 1 character, and tried to compile it and got:
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI
C product; ignored.
(Bundled) cc: rick.c, line 1: error 1000: Unexpected symbol: i.
(Bundled) cc: rick.c, line 1: error 1002: Unexpected character: 'u'.
(Bundled) cc: rick.c, line 1: error 1000: Unexpected symbol: .
(Bundled) cc: rick.c, line 1: error 1000: Unexpected symbol: ..
(Bundled) cc: rick.c, line 1: error 1000: Unexpected symbol: .
(Bundled) cc: rick.c, line 6: error 1000: Unexpected symbol: lt.
(Bundled) cc: rick.c, line 6: error 1588: time_t undefined.
(Bundled) cc: rick.c, line 7: error 1764: declarations as statements
allowed only with ansi_extend option.
(Bundled) cc: rick.c, line 9: error 1588: lt undefined.
(Bundled) cc: rick.c, line 11: error 1588: dtstr undefined.
*** Error exit code 1
I ran a similar test on AIX and the C compiler on AIX didn't care about the
shifted statement.
I could obviously change my code so the #include's start in column 1, but
the MQ #include code has similar code that starts in column 2, e.g.
/usr/include/cmqc.h.
Does anyone know if there's a compiler switch that can be set to correct
this?
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 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
Re: Running trigger monitor under non-mqm account
Just to close this topic: Got it working on my machine -- there were no problems at all and permissions were 0750 -- no problems. It turned out that, my explanations regardless, users did *not* give any proper permissions to queues/objects. Hopefully when they get it right, everything will work in their environment as well as it now works in mine. Have a nice day, Pavel - Forwarded by Pavel Tolkachev/NewYork/DBNA/DeuBa on 03/01/2004 02:11 PM - Pavel Tolkachev To: MQSeries List [EMAIL PROTECTED] 02/27/2004 02:51 cc: PM Subject: Re: Running trigger monitor under non-mqm account Thanks Chris, We are still struggling with the same error. I do not have an access to the box so it takes time to make sure all my (your :-)) recommendations are precisely followed. I will let the list know if I get some previously not mentioned gotchas during the process. Have a nice day, Pavel Chris N Kline [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Running trigger monitor under non-mqm account List [EMAIL PROTECTED] n.AC.AT 02/27/2004 12:55 PM Please respond to MQSeries List Pavel: It's been quite a while since I set it up, but I seem to remember that it required some such treatment. I'm trying to look back now and it appears that the 6755 may not be a requirement afterall. I do know we had to copy the binary and change ownership to the party running the process (they don't have permission to run the copy at /usr/bin). Remember that if you copy the binary, any time you apply a CSD you'll need to recopy that binary since it will likely be updated. We once had a problem with a copied, older version of runmqtrm causing many FDC files because it wasn't updated with the rest of the qmgr. Sorry I can't remember more specifics. * Chris Kline IBM Global Services IBM Certified Websphere MQ Specialist Strategic Middleware Services (56SD) - MQ Series/Vitria Phone: (303) 924-1767 T/L 347-1767 Email: [EMAIL PROTECTED] MQSeries List [EMAIL PROTECTED] wrote on 02/26/2004 01:02:22 PM: Hello Chris, I just realized what you said to its end: you still have those sticky bits set. Why do you need setuid and setgid and what is the ownership of this new file? Is it owned by non-mqm user and group? Is this the requirement to have sticky bits set to have it running? Sorry for too many questions :-). We tried giving plain 0755 or 0555 permissions. Have a nice day, Pavel Chris N Kline [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Running trigger monitor under non-mqm account List [EMAIL PROTECTED] n.AC.AT 02/26/2004 02:04 PM Please respond to MQSeries List You also need to have permissions granted for that user (group) on the process object and init queue (and of course qmgr object). It will work fine then. We use 6755 on permissions for the new trigmon copy when we do that.. * Chris Kline IBM Global Services IBM Certified Websphere MQ Specialist Strategic Middleware Services (56SD) - MQ Series/Vitria Phone: (303) 924-1767 T/L 347-1767 Email: [EMAIL PROTECTED] (Embedded image moved to file: pic05249.gif)Pavel Tolkachev pavel. [EMAIL PROTECTED] Pavel Tolkachev [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] (Embedded image moved to file: pic16519.gif) 02/26/2004 10:25 AM To (Embedded image moved to file: pic31556.gif) [EMAIL PROTECTED] Please respond to (Embedded image moved to file: pic22798.gif) MQSeries List cc (Embedded image moved to file: pic30303.gif) (Embedded image moved to file: pic06224.gif) Subject (Embedded image moved to file: pic11008.gif) Running trigger monitor under non-mqm account (Embedded image moved to file: pic05844.gif) (Embedded image moved to file: pic32609.gif) Hello, Have anyone managed to run trigger monitor on behalf of non-mqm user? On AIX platform, we copied
Re: Running trigger monitor under non-mqm account
Thanks Chris, We are still struggling with the same error. I do not have an access to the box so it takes time to make sure all my (your :-)) recommendations are precisely followed. I will let the list know if I get some previously not mentioned gotchas during the process. Have a nice day, Pavel Chris N Kline [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Running trigger monitor under non-mqm account List [EMAIL PROTECTED] n.AC.AT 02/27/2004 12:55 PM Please respond to MQSeries List Pavel: It's been quite a while since I set it up, but I seem to remember that it required some such treatment. I'm trying to look back now and it appears that the 6755 may not be a requirement afterall. I do know we had to copy the binary and change ownership to the party running the process (they don't have permission to run the copy at /usr/bin). Remember that if you copy the binary, any time you apply a CSD you'll need to recopy that binary since it will likely be updated. We once had a problem with a copied, older version of runmqtrm causing many FDC files because it wasn't updated with the rest of the qmgr. Sorry I can't remember more specifics. * Chris Kline IBM Global Services IBM Certified Websphere MQ Specialist Strategic Middleware Services (56SD) - MQ Series/Vitria Phone: (303) 924-1767 T/L 347-1767 Email: [EMAIL PROTECTED] MQSeries List [EMAIL PROTECTED] wrote on 02/26/2004 01:02:22 PM: Hello Chris, I just realized what you said to its end: you still have those sticky bits set. Why do you need setuid and setgid and what is the ownership of this new file? Is it owned by non-mqm user and group? Is this the requirement to have sticky bits set to have it running? Sorry for too many questions :-). We tried giving plain 0755 or 0555 permissions. Have a nice day, Pavel Chris N Kline [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Running trigger monitor under non-mqm account List [EMAIL PROTECTED] n.AC.AT 02/26/2004 02:04 PM Please respond to MQSeries List You also need to have permissions granted for that user (group) on the process object and init queue (and of course qmgr object). It will work fine then. We use 6755 on permissions for the new trigmon copy when we do that.. * Chris Kline IBM Global Services IBM Certified Websphere MQ Specialist Strategic Middleware Services (56SD) - MQ Series/Vitria Phone: (303) 924-1767 T/L 347-1767 Email: [EMAIL PROTECTED] (Embedded image moved to file: pic05249.gif)Pavel Tolkachev pavel. [EMAIL PROTECTED] Pavel Tolkachev [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] (Embedded image moved to file: pic16519.gif) 02/26/2004 10:25 AM To (Embedded image moved to file: pic31556.gif) [EMAIL PROTECTED] Please respond to (Embedded image moved to file: pic22798.gif) MQSeries List cc (Embedded image moved to file: pic30303.gif) (Embedded image moved to file: pic06224.gif) Subject (Embedded image moved to file: pic11008.gif) Running trigger monitor under non-mqm account (Embedded image moved to file: pic05844.gif) (Embedded image moved to file: pic32609.gif) Hello, Have anyone managed to run trigger monitor on behalf of non-mqm user? On AIX platform, we copied the binary without set-id bits and try to run it # path/to/runmqtrm -q INIT.QUEUE.NAME -m QM.NAME 5724-B41 (C) Copyright IBM Corp. 1994, 2002. ALL RIGHTS RESERVED. WebSphere MQ trigger monitor started. Use of WebSphere MQ trigger monitor not authorized. WebSphere MQ trigger monitor ended. If what I want to do is possible, does the user have to have any other permissions than to the INIT queue? If not, what are our alternatives? Any ideas? 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
Re: Running trigger monitor under non-mqm account
Hello, Thank Chris and Peter very much! All advices make sense to me -- I had to know better! I will try those and return back to the list if I have any further issues. Have a great day, Pavel Chris N Kline [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Running trigger monitor under non-mqm account List [EMAIL PROTECTED] n.AC.AT 02/26/2004 02:04 PM Please respond to MQSeries List You also need to have permissions granted for that user (group) on the process object and init queue (and of course qmgr object). It will work fine then. We use 6755 on permissions for the new trigmon copy when we do that.. * Chris Kline IBM Global Services IBM Certified Websphere MQ Specialist Strategic Middleware Services (56SD) - MQ Series/Vitria Phone: (303) 924-1767 T/L 347-1767 Email: [EMAIL PROTECTED] (Embedded image moved to file: pic27446.gif)Pavel Tolkachev [EMAIL PROTECTED] Pavel Tolkachev [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] (Embedded image moved to file: pic23805.gif) 02/26/2004 10:25 AM To (Embedded image moved to file: pic15890.gif) [EMAIL PROTECTED] Please respond to (Embedded image moved to file: pic06729.gif
Re: Running trigger monitor under non-mqm account
Hello Chris, I just realized what you said to its end: you still have those sticky bits set. Why do you need setuid and setgid and what is the ownership of this new file? Is it owned by non-mqm user and group? Is this the requirement to have sticky bits set to have it running? Sorry for too many questions :-). We tried giving plain 0755 or 0555 permissions. Have a nice day, Pavel Chris N Kline [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Running trigger monitor under non-mqm account List [EMAIL PROTECTED] n.AC.AT 02/26/2004 02:04 PM Please respond to MQSeries List You also need to have permissions granted for that user (group) on the process object and init queue (and of course qmgr object). It will work fine then. We use 6755 on permissions for the new trigmon copy when we do that.. * Chris Kline IBM Global Services IBM Certified Websphere MQ Specialist Strategic Middleware Services (56SD) - MQ Series/Vitria Phone: (303) 924-1767 T/L 347-1767 Email: [EMAIL PROTECTED] (Embedded image moved to file: pic05249.gif)Pavel Tolkachev [EMAIL PROTECTED] Pavel Tolkachev [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] (Embedded image moved to file: pic16519.gif) 02/26/2004 10:25 AM To (Embedded image moved to file: pic31556.gif) [EMAIL PROTECTED] Please respond to (Embedded
Running trigger monitor under non-mqm account
Hello, Have anyone managed to run trigger monitor on behalf of non-mqm user? On AIX platform, we copied the binary without set-id bits and try to run it # path/to/runmqtrm -q INIT.QUEUE.NAME -m QM.NAME 5724-B41 (C) Copyright IBM Corp. 1994, 2002. ALL RIGHTS RESERVED. WebSphere MQ trigger monitor started. Use of WebSphere MQ trigger monitor not authorized. WebSphere MQ trigger monitor ended. If what I want to do is possible, does the user have to have any other permissions than to the INIT queue? If not, what are our alternatives? Any ideas? 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
Re: AW: Re: Performance observations and questions
Hello Enrico, Basically, you are looking at reading Event Monitoring book. To summarize briefly: after events are allowed (see MQSC book for those attributes I mentioned in my previous mail), you will be getting the regular mq messages on SYSTEM.ADMIN.PERFM.EVENT queue. The thread you mentioned would be mostly waiting in MQGET() on this queue, crack the event messages and respond to getting underflow and overflow events accordingly (by requesting publishing thread to suspend or resume publishing). The format of the event messages and examples are all in Event Monitoring book. Hope this will help, Pavel Fichtner Enrico enrico.fichtner@To: [EMAIL PROTECTED] ELAXY.COM cc: Sent by: MQSeriesSubject: AW: Re: Performance observations and questions List [EMAIL PROTECTED] n.AC.AT 02/18/2004 02:49 AM Please respond to MQSeries List Pavel, I have googled the web for a hint on how to use the events in a C++ app - but couldn't find any. The path is clear so far, use *something* in a separate thread that has thread-synchro with the thread that does the actual put, when the event occurs simply let the putting thread run idle (or whatsoever) until the opposite event rises. However, the *something* is the portion that is not clear, is it a API call that blocks until the event occurs - or is it a C++ object (wrapped API) that I have to use? Any hint on this would be extremely helpful. Thanks, Enrico -Ursprüngliche Nachricht- Von: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 17. Februar 2004 01:54 An: [EMAIL PROTECTED] Betreff: Re: Performance observations and questions Enrico, Make sure your application does not check the size of the transmission queue each time before putting the message; otherwise, it may affect the performance, especially if you are interested in highest possible one. An alternative approach (I am not aware of *the* right one) would be to enable relevant events (see QDPHIEV, QDEPHHI queue attributes and QM's PERFMEV) and wait for them in a separate thread.. then stop the publisher. You can use QDPHLOEV to resume publishing in the same manner. Just my 2c Pavel Gurney, Matthew [EMAIL PROTECTED]To: [EMAIL PROTECTED] SFB.COM cc: Sent by: MQSeriesSubject: Re: Performance observations and questions List [EMAIL PROTECTED] n.AC.AT 02/16/2004 08:51 AM Please respond to MQSeries List Enrico, IBM provides performance information and tuning recommendations in the support pacs, this information is not in the manuals. I would recommend you review: http://www-306.ibm.com/software/integration/support/supportpacs/product.html MP6J MP78 In regard to your performance test, I think the reduction in performance when maximum queue depth was increased
Re: Performance observations and questions
Enrico, Make sure your application does not check the size of the transmission queue each time before putting the message; otherwise, it may affect the performance, especially if you are interested in highest possible one. An alternative approach (I am not aware of *the* right one) would be to enable relevant events (see QDPHIEV, QDEPHHI queue attributes and QM's PERFMEV) and wait for them in a separate thread.. then stop the publisher. You can use QDPHLOEV to resume publishing in the same manner. Just my 2c Pavel Gurney, Matthew [EMAIL PROTECTED]To: [EMAIL PROTECTED] SFB.COM cc: Sent by: MQSeriesSubject: Re: Performance observations and questions List [EMAIL PROTECTED] n.AC.AT 02/16/2004 08:51 AM Please respond to MQSeries List Enrico, IBM provides performance information and tuning recommendations in the support pacs, this information is not in the manuals. I would recommend you review: http://www-306.ibm.com/software/integration/support/supportpacs/product.html MP6J MP78 In regard to your performance test, I think the reduction in performance when maximum queue depth was increased was due to you exceeding the QBufferSize for your queues. By default Q's have 64k of memory assigned to them. If the total size of all messages upon the queue exceeds 64k then the extra messages (or perhaps entire q, not sure) are written to disk. Obviously once the disk gets involved your performance reduces dramatically. You can adjust the QBufferSize in your qm.ini up to 1MB (you need to delete and recreate the q after making the qm.ini change). Matt. -Original Message- From: Fichtner Enrico [mailto:[EMAIL PROTECTED] Sent: 16 February 2004 10:06 To: [EMAIL PROTECTED] Subject: Performance observations and questions For a upcoming project we needed some figures on MQSeries throughput to base a design decision on. Throughput is very crucial in this project. On the last weekend I've conducted some tests in this regard. Some of the results I would like to discuss here. Facts: - the tests where conducted on two Intel machines running W2K with MQSeries 5.2, however, the project target platform will be SPARC/Solaris9 - the machines used in this test are a PIV 2.8GH and a 2xPIII 450MH, both 512MB, one has ultra fast SCSI HD's and one has a pretty fast IDE-RAID5 (4x160G) - both machines where connected via 100MB LAN through a switch, which had only the two machines connected to it - message size was 200 byte, I used a string made of repeated numbers of 0 through 9 - queues where not persistent - DOS based test applications are written in C++, using IBM's C++ interface rather than straight C-API - the 'putting' application runs in a loop, checking the depth of the transmission queue (avoiding overflow), if the depth is below a certain level it puts the message into the remote queue, every n successful puts the time is measured (through windows high frequency counter, very high precision) and the average messages per seconds is put on the screen - the 'getting' application runs in a endless loop, with a blocking 'get' on the (receiving) local queue, the same average measuring is implemented as in the 'putting' app Results: - the best throughput was 3200msgs/sec measured with one putting application and one getting application at a maximum queue depth of 5000 on both sides (remote and transmission queue), CPU's on both sides where far below 100% - overall throughput went down when several 'putting' applications where putting to the same queue (of course, taking the sum of all screen outputs) Questions: - what actually limits the throughput? the number of msgs/sec times the size in this case results in the best case to 625kB/sec which is far beyond the practical throughput of the mentioned LAN - is it a correct observation that synchronizing several applications putting into the same queue causes considerably overhead? if so, can this be assumed the same way under SPARC/Solaris9 ? - when the max queue depth is set to a high number (e.g. 50), throughput goes down to a fraction of the max throughput, MQSeries process amqzlaa0.exe 'eats' up a lot of CPU power in this case - it seams like that managing a lot of messages in a queue causes also relatively large overhead - is this correct and how does it translate in generally to SPARC/Solaris9 ? - what are the recommendations for the setup of MQSeries (installation itself, queues, channels,
Re: MQ wrapper to new Java App Server World?
Hello Neil, You mentioned MDB in your question so I assumed you had some application server to run them; if you want to feed MDB directly from your application, you can of course use a single thread (and, hence, a static one). App servers use a pool and that standard JMS-appserver wiring to be able to feed MDBs with messages concurrently. Whether your app needs it or not is certainly up to you to decide. Regards, Pavel Taylor, Neil [EMAIL PROTECTED]To: [EMAIL PROTECTED] EQUEST.COM cc: Sent by: MQSeries Subject: Re: MQ wrapper to new Java App Server World? List [EMAIL PROTECTED] C.AT 02/10/2004 09:07 AM Please respond to MQSeries List Pavel Thanks for your response. I think I can cut the JMS aspect out and just use the base java calls within my API Wrapper. If I just use the get with wait, and keep looping I can then notify the listeners (i.e. the end application) with the message. Get with wait is quite light-weight? Although this doe not fit my API model application initiated receive, it doesn't break it too much to fit to the java model. I saw the wrapper as a static class so not a pooled resource - not that I'm a J2EE or application server expect. Regards Neil -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: 09 February 2004 18:20 To: [EMAIL PROTECTED] Subject: Re: MQ wrapper to new Java App Server World? Hello Neil, To me it sounds as you will have to make your API wrapper your own JMS provider. You will most probably have to implement ConnectionConsumer and Session interfaces from there because this is how J2EE-compliant app servers support MDBs (they supply the implementation of ServerSession and ServerSessionPool and push messages through to Sessions they get from ServerSessions). I am not sure if any of them actually will be able to get messages for MDBs via any other interface. As for the asynchronous model of getting messages, you will probably have to create a special thread on a client side to call onMessage() methods on every registered listener (J2EE compliant app server does it with ServerSession's start() method) and that thread will push all messages through the listeners. This is how, I believe, any JMS Session is implemented (yes, I remember you want to keep JMS out of the loop I just refer to it as an example for implementing your wrapper. Pure MQ API only provides synchronous MQGET to receive messages). Hope this will help, Pavel Taylor, Neil [EMAIL PROTECTED]To: [EMAIL PROTECTED] EQUEST.COM cc: Sent by: MQSeries Subject: Re: MQ wrapper to new Java App Server World? List [EMAIL PROTECTED] C.AT 02/09/2004 11:23 AM Please respond to MQSeries List Thanks Pavel I am trying to keep mqseries and JMS out of the loop. My email below is not as clear as it could be - we have designed the API wrapper already, on the assumption of a receive call being made by the end-application. So we have a receive API call that we would expect an application to call, but Java's model is not to do this, but rather register with a listener and be notified of events. Thereby breaking the model. If anybody has experience in this area then please let me know. Regards Neil -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: 09 February 2004 15:32 To: [EMAIL PROTECTED] Subject: Re: MQ wrapper to new Java App Server World? Hello Neil, I have never tried it with MQ JMS provider, but looking in the doucmentation, it does include its own implementation of ConnectionConsumer (which is exactly the facility intended for an application server to push messages into its MessageListeners, which MDBs are). So I would recommend you to configure your appServer to use MQ as an external JMS provider (see MQ Using Java book for MQ part of the deal) and see if it works. Hope this will help, Pavel Taylor, Neil [EMAIL PROTECTED]To: [EMAIL PROTECTED] EQUEST.COM cc: Sent by: MQSeries Subject: MQ wrapper to new Java App Server World? List [EMAIL PROTECTED] C.AT 02/09/2004 05:23 AM Please respond to MQSeries List Hi I was wondering if anyone had experience of building an MQ wrapper
Re: MQ wrapper to new Java App Server World?
Hello Neil, I have never tried it with MQ JMS provider, but looking in the doucmentation, it does include its own implementation of ConnectionConsumer (which is exactly the facility intended for an application server to push messages into its MessageListeners, which MDBs are). So I would recommend you to configure your appServer to use MQ as an external JMS provider (see MQ Using Java book for MQ part of the deal) and see if it works. Hope this will help, Pavel Taylor, Neil [EMAIL PROTECTED]To: [EMAIL PROTECTED] EQUEST.COM cc: Sent by: MQSeries Subject: MQ wrapper to new Java App Server World? List [EMAIL PROTECTED] C.AT 02/09/2004 05:23 AM Please respond to MQSeries List Hi I was wondering if anyone had experience of building an MQ wrapper, that was then to be implemented in the Java/ EJB world. Where Message Driven Beans are the norm and expect to be event driven. How has this changed the model? For instance we have a receive API call that we use to abstract the MQGet functionality. However, this assumes a polling by the application calling the API. But with the MDB the expected mode is of message arrival waking the application and giving it the message directly. Hence the MQ Wrapper is bypassed. Any views? Regards Neil -- 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
Re: MQ wrapper to new Java App Server World?
Hello Neil, To me it sounds as you will have to make your API wrapper your own JMS provider. You will most probably have to implement ConnectionConsumer and Session interfaces from there because this is how J2EE-compliant app servers support MDBs (they supply the implementation of ServerSession and ServerSessionPool and push messages through to Sessions they get from ServerSessions). I am not sure if any of them actually will be able to get messages for MDBs via any other interface. As for the asynchronous model of getting messages, you will probably have to create a special thread on a client side to call onMessage() methods on every registered listener (J2EE compliant app server does it with ServerSession's start() method) and that thread will push all messages through the listeners. This is how, I believe, any JMS Session is implemented (yes, I remember you want to keep JMS out of the loop I just refer to it as an example for implementing your wrapper. Pure MQ API only provides synchronous MQGET to receive messages). Hope this will help, Pavel Taylor, Neil [EMAIL PROTECTED]To: [EMAIL PROTECTED] EQUEST.COM cc: Sent by: MQSeries Subject: Re: MQ wrapper to new Java App Server World? List [EMAIL PROTECTED] C.AT 02/09/2004 11:23 AM Please respond to MQSeries List Thanks Pavel I am trying to keep mqseries and JMS out of the loop. My email below is not as clear as it could be - we have designed the API wrapper already, on the assumption of a receive call being made by the end-application. So we have a receive API call that we would expect an application to call, but Java's model is not to do this, but rather register with a listener and be notified of events. Thereby breaking the model. If anybody has experience in this area then please let me know. Regards Neil -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: 09 February 2004 15:32 To: [EMAIL PROTECTED] Subject: Re: MQ wrapper to new Java App Server World? Hello Neil, I have never tried it with MQ JMS provider, but looking in the doucmentation, it does include its own implementation of ConnectionConsumer (which is exactly the facility intended for an application server to push messages into its MessageListeners, which MDBs are). So I would recommend you to configure your appServer to use MQ as an external JMS provider (see MQ Using Java book for MQ part of the deal) and see if it works. Hope this will help, Pavel Taylor, Neil [EMAIL PROTECTED]To: [EMAIL PROTECTED] EQUEST.COM cc: Sent by: MQSeries Subject: MQ wrapper to new Java App Server World? List [EMAIL PROTECTED] C.AT 02/09/2004 05:23 AM Please respond to MQSeries List Hi I was wondering if anyone had experience of building an MQ wrapper, that was then to be implemented in the Java/ EJB world. Where Message Driven Beans are the norm and expect to be event driven. How has this changed the model? For instance we have a receive API call that we use to abstract the MQGet functionality. However, this assumes a polling by the application calling the API. But with the MDB the expected mode is of message arrival waking the application and giving it the message directly. Hence the MQ Wrapper is bypassed. Any views? Regards Neil -- 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 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
