Re: amqpcsea is not running
Start the command server... strmqcsv YourQMName Don't see how that would effect new connections not being starting though -Original Message- From: Jeff A Tressler [mailto:[EMAIL PROTECTED] Sent: Friday, July 02, 2004 12:12 PM To: [EMAIL PROTECTED] Subject: amqpcsea is not running The Command Server (amqpcsea) is not running but all other processes are running. Applications and channels already connected are working but no new connections or applications can start. Is there some way to bring amqpcsea back up without stopping the queue manager? This is HP-UX and since amqpcsea is down I cannot run 'runmqsc'. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Problems with authorities on Solaris
Title: Message You didn't give any of the PASS or SET authorities. Is the app trying to open the queue with the options to set or pass context info? -Original Message-From: Haggkvist, Andreas [mailto:[EMAIL PROTECTED]Sent: Wednesday, June 30, 2004 9:12 AMTo: [EMAIL PROTECTED]Subject: Problems with authorities on Solaris Hi, we are running MQ 5.3 CSD06 on Solaris 8. Currently we have an issue with access to a specific queue. We have set authorities using this command: setmqaut -m -t queue -n ETSB*.** -g eai +browse +inq +get +put +dsp +chg However when one of our applications tries to put a message to a queue called ETSB_EDIFACT_INBOUND they get RC=2035. On windows (using the same version of MQ) I can see in one of the MQ logfiles what rights is missing when you get RC=2035, but not on Solaris. Has anybody any ideas? Regards Andreas This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: JAVA app can't see clustered queues
Brendan, I assumed JMS when I read your post. If its plain JAVA, then Roger's advice is the way to go: http://www.mqseries.net/phpBB2/viewtopic.php?t=16213 -Original Message-From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]Sent: Tuesday, June 29, 2004 11:03 AMTo: [EMAIL PROTECTED]Subject: Re: JAVA app can't see clustered queues You probably have the QMANAGER property of the queue object filled in. The manual says that that is the name of the QM you are connected to. The manual is WRONG. That property maps to the MQOD_ObjectQmngrName field. So, if you are connected to QM1, and QM2 and QM3 are the only QMs that have the queue in question, and you have QM1 in QMANAGER, the underlying MQ code is trying to put the message to the queue on QM1, which does not exist. Blank out QMANAGER, and the message will round robin between QM2 and QM3. Or if you need to put the message specifically to QM2 or QM3, stick that in QMANAGER. I dealt with this before: http://www.mqseries.net/phpBB2/viewtopic.php?t=12350&highlight= -Original Message-From: Brendan Drummond [mailto:[EMAIL PROTECTED]Sent: Tuesday, June 29, 2004 10:45 AMTo: [EMAIL PROTECTED]Subject: JAVA app can't see clustered queues Hi, We're having a few problems when a JAVA application is trying to put messages to a clustered queue which exists on 2 (remote) full repository boxes. If we specify the clustered queue in the connection configuration, we receive the 2085 error code. I have also tried creating a local Alias queue that has the clustered queue as the base queue howver we get the 2082 error code. If we put to a normal local queue, this works ok. The queue manager we are putting messages on to is part of the cluster and an amqsput works for both of the scenarios above. Any ideas...? Brendan DrummondMiddleware Support EnergisDirect Dial: +44 (0) 118 919 2443Switchboard: +44 (0) 20 7206 http://www.energis.com At Energis we want our customers to succeed. That's why we really welcomeyour views on how we can improve our performance. If you have any comments,good or bad, please let us know by following this link to our feedback form: http://www.energis.com/contact/feedback.aspThis e-mail is sent by Energis Communications Limited and its contents areconfidential and may be legally privileged. This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: JAVA app can't see clustered queues
You probably have the QMANAGER property of the queue object filled in. The manual says that that is the name of the QM you are connected to. The manual is WRONG. That property maps to the MQOD_ObjectQmngrName field. So, if you are connected to QM1, and QM2 and QM3 are the only QMs that have the queue in question, and you have QM1 in QMANAGER, the underlying MQ code is trying to put the message to the queue on QM1, which does not exist. Blank out QMANAGER, and the message will round robin between QM2 and QM3. Or if you need to put the message specifically to QM2 or QM3, stick that in QMANAGER. I dealt with this before: http://www.mqseries.net/phpBB2/viewtopic.php?t=12350&highlight= -Original Message-From: Brendan Drummond [mailto:[EMAIL PROTECTED]Sent: Tuesday, June 29, 2004 10:45 AMTo: [EMAIL PROTECTED]Subject: JAVA app can't see clustered queues Hi, We're having a few problems when a JAVA application is trying to put messages to a clustered queue which exists on 2 (remote) full repository boxes. If we specify the clustered queue in the connection configuration, we receive the 2085 error code. I have also tried creating a local Alias queue that has the clustered queue as the base queue howver we get the 2082 error code. If we put to a normal local queue, this works ok. The queue manager we are putting messages on to is part of the cluster and an amqsput works for both of the scenarios above. Any ideas...? Brendan DrummondMiddleware Support EnergisDirect Dial: +44 (0) 118 919 2443Switchboard: +44 (0) 20 7206 http://www.energis.com At Energis we want our customers to succeed. That's why we really welcomeyour views on how we can improve our performance. If you have any comments,good or bad, please let us know by following this link to our feedback form: http://www.energis.com/contact/feedback.aspThis e-mail is sent by Energis Communications Limited and its contents areconfidential and may be legally privileged. This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: trigger monitor as Windows service not working.
Don't know what exactly is causing your problem, but you may want to consider using the MA7K support pac to run your Trigger Monitor as a robust service. MA7K is widely known for its use with client trigger monitors, but it will also work with local trigger monitors. This guy had a similar problem, http://www.mqseries.net/phpBB2/viewtopic.php?t=15772&highlight=ma7k but no resolution as of yet. Maybe reading the discussion will give you some ideas? -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, June 28, 2004 3:32 PM To: [EMAIL PROTECTED] Subject: trigger monitor as Windows service not working. I experienced the same problem two years back with version 5.1. Eventually, I resort to using runmqtrm at comnand line to trigger applications. But now, with 5.3 CSD07, it is still not working. I defined queue, setup trigger, defined process, and specified initq. It works fine with runmqtrm at command line, but with trigger monitor service, nothing happens when a msg arrives at the queue. Would anyone mind sharing some insight? thanks, Benjamin F. Zhou Mercedes-Benz USA x.2474 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ Clustering Channel Table Question
Yes, this will work. When you kick off the bat file, it will pop open a dos window, and the environment variables you set in that dos window will only apply to that dos window. Any apps running on the system will still get the variable you set at the system level, and if you open up app #3 in another dos window, you can set even different variables for that without effecting the first. I do it all the time. -Original Message- From: G Kowalski [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 10:28 AM To: [EMAIL PROTECTED] Subject: MQ Clustering Channel Table Question We have two apps (both are VBScript, asp, Active X) running on the same Win2000 server running MQ Client V5.3. We are currently performing some automatic fail-over tests where an app will connect to a primary queue manager, but if this queue manager is down, a connection will be automatically made to a secondary queue manager. So we are no longer specifying a 'hard-coded' queue manager name in the app and a new channel table accomodates for the blank queue manager name in order to get to the primary and secondary queue manager. We have implemented this MQ Clustering/automatic fail-over strategy on other applications already, but this is the first time we are dealing with two applications running on the same server that need to get to two distinct pairs of queue managers (internal vs. DMZ). So here is my question... Can two or more applications running on the same MQ Client machine use a unique channel table? In other words, can the first app use the default channel table amqchchl.tab and the second app use another channel table like amqchchl2.tab? It appears that a second channel table can be used by an application by setting environment variables via a command script file (.cmd). This is from the MQ Clients manual... WebSphere MQ uses default values for those variables that you have not set. Using environment variables, you can update your system profile to make a permanent change, issue the command from the command line to make a change for this session only, or, if you want one or more variables to have a particular value dependent on the application that is running, add commands to a command script file used by the application. This seems to infer that the second application could invoke a script to set the environment variables... SET MQCHLLIB=C:\Program Files\IBM\WebSphere MQ SET MQCHLTAB=amqchchl2.tab My concern is this will just override the default channel table value of amqchchl.tab and the first application will end up using amqchchl2.tab also. More specific questions... Has anyone implemented this? Do both applications need to set MQCHLTAB? How do you call the .cmd file? Or is this the wrong approach? Thanks, Glenn Kowalski United Stationers _ Get fast, reliable Internet access with MSN 9 Dial-up now 3 months FREE! http://join.msn.click-url.com/go/onm00200361ave/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 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
Not directly MQ - Time Syncing your servers
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
Re: Windows 2000 Server and CSD07 problem
Fun is, huh? Go to sysinternal.com, and download listdlls.exe. It is a lifesaver. Then follow the below steps. Process Explorer is also found at sysinternals. This has always worked, and I have dealt with CSD upgrades on 5.3 about 50 times. Ya know, this was never such an issue at 5.2.1.why did 5.3 make it so bad. 1.Put the listdlls.exe into a folder on the server, like maybe E:\Programs\IBM\MQSeries\MQSupportTools. 2.CD into that directory from the dos prompt. 3.Run the executable, and pipe the output into a text file. Here is a sample of what you would type assuming you placed the executable file as in step 1: E:\Programs\IBM\MQSeries\MQSupportTools\listdlls.exe >DLLOutput.txt 4.Open DLLOutput.txt and do a search on "MQ". Scroll up to see what .exe is using this MQ dll. 5.Stop the application that is using the MQ dll and you should be all set. If you do not recognize what this .exe is, use Process Explorer (procexp.exe). You can find the exe in there, and it will tell you what app it is. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 22, 2004 5:05 PM To: [EMAIL PROTECTED] Subject: Re: Windows 2000 Server and CSD07 problem Hi, Of your list of files, besides IBM MQSeries, we have Windows Management Instrumentation and stopping it did not help. Regards, Roger Lacroix Quoting "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>: > Roger, I am gonna guess this is just more typical MQ locked files, and > nothing specific to CSD07. Try the following, I wrote this up for my team > because we constantly deal with this: > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > When applying a CSD, no MQSeries dlls can be held by any programs. This step > will insure that all MQSeries dlls are released. > a. Go to Services and stop the IBM MQSeries Service. Wait a minute or > so, and if still present after 1 minute, right click on the MQServices Icon > in the Task bar to stop WebSphere MQ and again to hide the icon. Give it > (amqsvc.exe) a minute to drop out of the Task Manager after hiding it. > b. The services listed in Appendix A should also be stopped when trying > to install the CSD. They have all been known to hold onto MQ dlls. > > Appendix A > Windows Services That Use MQSeries Files > The following is a list of services that typically run on Windows Servers at > The Hartford. All have been know to interfere with MQSeries Installs / > Upgrades due to the fact that they use MQSeries dlls. If MQSeries dlls are > in use, MQ will not allow you to upgrade MQ. > > Use this as a checklist to know which Services you shut off, so that you can > restore them all back to their prior state upon completion of your MQSeries > work on this server. > > 1. BGS_SDService Manual or Automatic > 2. BMC SoftwareManual or Automatic > 3. CPQHostsManual or Automatic > 4. Compaq EcoTools Manual or Automatic > 5. Compaq Versioning Control Manual or Automatic > 6. IBM MQSeriesManual or Automatic > 7. IBM MQSI Broker Manual or Automatic > 8. IBM MQSI Configuration Manager Manual or Automatic > 9. Norton Anti Virus Manual or Automatic > 10. Performance Data Log ServiceManual or Automatic > 11. QPASA (all three components)Manual or Automatic > 12. SMV Collector Manual or Automatic > 13. Tivoli Manual or Automatic > 14. Windows Management Instrumentation Manual or Automatic > 15. BMC is also known to hang onto to MQ Files, but it is not a service. > You may need to manually kill it using procexp.exe. BMC is not always > present, so you may not want to bother looking for this unless the CSD > install cries about locked files even after stopping all of the above. Use > listdlls.exe to see what is holding an MQSeries file; use procexp.exe to > kill it if you can't find it in Task Manager or Services. > > > > > > > -Original Message- > From: Roger Lacroix [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 22, 2004 3:58 PM > To: [EMAIL PROTECTED] > Subject: Windows 2000 Server and CSD07 problem > > > Help please, > > Box: > Windows 2000 Server SP4 (dual CPU) > > Today I installed WMQ v5.3 with CSD01 using Terminal Services (to D: drive > of > server) and the install went fine (I copied the CD to a local drive then did >
Re: Windows 2000 Server and CSD07 problem
Roger, I am gonna guess this is just more typical MQ locked files, and nothing specific to CSD07. Try the following, I wrote this up for my team because we constantly deal with this: >> When applying a CSD, no MQSeries dlls can be held by any programs. This step will insure that all MQSeries dlls are released. a. Go to Services and stop the IBM MQSeries Service. Wait a minute or so, and if still present after 1 minute, right click on the MQServices Icon in the Task bar to stop WebSphere MQ and again to hide the icon. Give it (amqsvc.exe) a minute to drop out of the Task Manager after hiding it. b. The services listed in Appendix A should also be stopped when trying to install the CSD. They have all been known to hold onto MQ dlls. Appendix A Windows Services That Use MQSeries Files The following is a list of services that typically run on Windows Servers at The Hartford. All have been know to interfere with MQSeries Installs / Upgrades due to the fact that they use MQSeries dlls. If MQSeries dlls are in use, MQ will not allow you to upgrade MQ. Use this as a checklist to know which Services you shut off, so that you can restore them all back to their prior state upon completion of your MQSeries work on this server. 1. BGS_SDService Manual or Automatic 2. BMC SoftwareManual or Automatic 3. CPQHostsManual or Automatic 4. Compaq EcoTools Manual or Automatic 5. Compaq Versioning Control Manual or Automatic 6. IBM MQSeriesManual or Automatic 7. IBM MQSI Broker Manual or Automatic 8. IBM MQSI Configuration Manager Manual or Automatic 9. Norton Anti Virus Manual or Automatic 10. Performance Data Log ServiceManual or Automatic 11. QPASA (all three components)Manual or Automatic 12. SMV Collector Manual or Automatic 13. Tivoli Manual or Automatic 14. Windows Management Instrumentation Manual or Automatic 15. BMC is also known to hang onto to MQ Files, but it is not a service. You may need to manually kill it using procexp.exe. BMC is not always present, so you may not want to bother looking for this unless the CSD install cries about locked files even after stopping all of the above. Use listdlls.exe to see what is holding an MQSeries file; use procexp.exe to kill it if you can't find it in Task Manager or Services. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 22, 2004 3:58 PM To: [EMAIL PROTECTED] Subject: Windows 2000 Server and CSD07 problem Help please, Box: Windows 2000 Server SP4 (dual CPU) Today I installed WMQ v5.3 with CSD01 using Terminal Services (to D: drive of server) and the install went fine (I copied the CD to a local drive then did the install from it). As I said, everything went fine and I reboot the server. After the reboot, I downloaded CSD07. First I stopped the MQ Services and clicked 'Hide the icon'. Check Task Manager for any AMQ*** or RUNMQ*** tasks and there were none. Under Terminal Services launched the CSD07 (U200212A.exe) and goes fine until it gets to'Checking files; please wait' (the 2nd time). Then I get the following error: 'IBM WebSphere MQ files are in use. Stop activity and retry. (AMQ4757)' I have rebooted the server 2 twice now, stopped services, checked the Task Manager and I don't see anything MQ related running. I have NOT even defined a queue manager yet on this server!! Could it be a problem with Terminal Services?? Or is CSD07 like CSD06 where it wasn't fully baked by IBM? Anyone have an idea or comment? Regards, Roger lacroix Capitalware Inc. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ Rollback
Steve, your testing is backed up by the manuals. For distributed platforms: If an application disconnects (MQDISC) while a global unit of work is still active, the unit of work is committed. If, however, the application terminates without disconnecting, the unit of work is rolled back as the application is deemed to have terminated abnormally. You also asked: "If so, can anyone think of any reasons why the MQGET might not be > rolled back when the application ends." Yes, on Z/os it would be different. >From the App Prog Guide: Except on z/OS batch with RRS, if a program issues the MQDISC call while there are uncommitted requests, an implicit syncpoint occurs. If the program ends abnormally, an implicit backout occurs. On z/OS, an implicit syncpoint occurs if the program ends normally without first calling MQDISC. . . . If a CICS application issues the MQDISC call, no implicit syncpoint is taken. If the application closes down normally, any open queues are closed and an implicit commit occurs. If the application closes down abnormally, any open queues are closed and an implicit backout occurs. -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Friday, June 11, 2004 8:53 AM To: [EMAIL PROTECTED] Subject: Re: MQ Rollback Steve, In general I would always suggest that applications explicitly issue MQBACK or MQCMIT call since there are slight differences in behaviour on different platforms. However, what you say is true. An MQDISC will implicitly commit the transaction if possible. It is described in the Usage Notes of the Application Programming Reference, a. If the application issues the MQDISC call before ending: For a queue-manager-coordinated unit of work, the queue manager issues the MQCMIT call on behalf of the application. The unit of work is committed if possible, and backed out if not. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley MQSeries List <[EMAIL PROTECTED]> wrote on 11/06/2004 11:08:29: > A client has a problem where his MQ application is failing but he > says the MQ updates are not rolling back. I'm sure he's got > something wrong in his code but before I berate him I just want to > confirm my understanding and ask if there are any known issues. > > If an application (WIN2K) gets a message using MQGMO_SYNCPOINT and > then issues a MQDISC (but no preceding MQCMIT) the MQGET is > committed. If on the other hand it just ends normally but does not > issue a MQCMIT or MQDISC) the MQGET is rolled back. > > I've tried this using the API Exerciser in First Steps and it seems > to confirm this. > > 1) Is this correct ? > 2) If the Win2K application runs as a Windows service does it still > work the same ? > > If so, can anyone think of any reasons why the MQGET might not be > rolled back when the application ends. > > TIA > > Steve. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Remote queue error when changing parameters
Bill, you can try using the FORCE option on the ALTER command. What this means is that the app(s) that have that remote queue open are now going to get a 2041 MQRC_OBJECT_CHANGED error. If they are coded well, they will MQCLOSE, and reMQOPEN, thus picking up your changes. You have no way of knowing this, but it is an option short of stopping all the apps or rebooting. -Original Message- From: Conklin, William [mailto:[EMAIL PROTECTED] Sent: Thursday, June 10, 2004 9:51 AM To: [EMAIL PROTECTED] Subject: Remote queue error when changing parameters Hi All, Is there a way to find out who has an "open" to a remote queue similar to a local queue using display qstatus? I want to change the name of the Remote Queue Manager and Xmit queue but when I try to I get the following error: 4004: MQRCCF_OBJECT_OPEN. I can certainly make the change at reboot time or stopping all the apps on the server but that seems like overkill because this is a production server. I stopped the channels associated with the remote queue with the same results. Any assistance would be greatly appreciated. Thanks Bill C. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: many svrconn instances, as many amqcrsta running
Benjamin, we have been dealing with this as well. Below is a copy of an email I have from our programmers. So far for this application, the problem seems solved. JMS absolutely hammers MQ. We have Transaction Vision showing us all the calls that a QM is handling, and the amount of calls that a JMS app, specifically one that uses MDBs, is ridiculous. Constantly opening the QM to do INQs, MQGETs with only a 5000 wait, over and over. Multiply this by several JMS apps. And all of them want a pool of connections. JMS apps are quickly diminishing the benefit of the MQ Concentrator model. We have max connections set to 1500, and have hit it twice because of all these connection pools. Hopefully the fix mentioned below will alleviate the connection problem somewhat. As far as the QM being to handle the barrage of MQ API calls, it amazes me the QM is performing as well as it does. Windows 2000 on top of everything else! quote>>> If it helps, my research has found that large number of connection type problems with MQ and Weblogic are fairly common. The problem stems from how IBM MQ implements some JMS functionality is different than what Bea considers "normal". In JMS there are two basic Objects - a Connection Object, and a Session object. The Session object is obtained from a Connection object. Under IBM's implementation, every single session object gets a physical connection back to MQ. According to bea this is because IBM's connections are not thread safe so their implementation requires individual connections per session. In other words if a Java application has 1 connection and 20 associated sessions, with IBM drivers you get 20 physical connections (and file descriptors used) while with some other vendors JMS implementations you would have 1 physical connection. Because bea programmers were not thinking session=physical connection, in cases of restart they were not closing sessions - I think they were simply creating new ones. This led to cases in weblogic where sessions and the associated physical connections became orphaned. Only a complete shutdown of weblogic frees these resources. This problem has happened on multiple versions of weblogic, and the latest service pack (Weblogics 6.1 SP6) adresses these issues (they call close on the sessions). end quote -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] 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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: SSL, MQClients and Symmetric keys
Pavel,Neil When I first started thinking about this, I was only thinking of the one client group talking to all the QMs, and kinda thought that 1 private self signed cert for all QMs would be fine. Now that I expand the idea that any /all of these QMs may now need to SSL with another MQClient group, another QM from another company, or even each other, I wonder, since a QM can only have 1 private cert, is this now a bad idea? 1.) Will QMA and QMB be able to SSL each other if they both have the same keys? 2.) If QMC (my QM) now all of the sudden needs to talk to QMX (outside company), and QMC is already running the self-signed cert, that's not such a hot idea. QMC would need a cert signed by an outside CA, and I would then to uninstall my private self signed cert, install the new private cert from the outside CA, and then have to export the new public key to any and all clients/QMs that SSL with QMC. I guess with a little careful planning I can insure the EdgeQM (QMC) from day 1 has a real cert from an outside CA. 3.) I went through the manuals, and couldn't really find anywhere where it said a QM can only have 1 private cert. But I guess it makes sense. A QM's personal private cert is its "signature" of who it is. It can have many of these in its store, but you can assign one and only one at a particular time for that QM. Meanwhile the QM's store will contain many CA certs (signer certs?), to be used in authenticating incoming certs from other QMs and/or Clients. Is what I laid out in this step all true? 4.) So when this thread started, I was going to give each of the 100 QMs the same cert, so that each of my MQClients would only need the one same public key (from the QM side) on their side. What would you guys do in light of the above points? Same cert for all QMs, or make 100 unique certs for each QM, and then assign 100 public keys to each MQ client (THAT sames very tedious). (It is highly unlikley that all my internal QMs will need to SSL each other, but it is very likley that I will have a second MQClient group coming soon that will need a separate SSL connection to all the QMs, and I will have 1 dedicated QM that will SSL with outside companies). -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Thursday, June 03, 2004 6:47 PM To: [EMAIL PROTECTED] Subject: 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 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.COM>Subject: 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
Re: SSL, MQClients and Symmetric keys
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 (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.COM>Subject: 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 g
Re: Messages stuck in the XMIT queue
Well, there is one other thing that I can think of, which I am dealing with
right now, and that is "ghost" messages on the XMITQ. The depth shows >0,
but there is no message there to browse, and the channel is sending 1000s of
messages an hour all along.
The fact that you can look at the MQXQH makes me believe your problem is
slightly different (I couldn't see any evidence at all of any message in my
case). But maybe its related?
Here is the link to the APAR (IC40975). I am installing it to the PROD
environment SAT night. So far so good in the test environments.
http://www-306.ibm.com/ibmlink/link2/sis/sisPage.jsp?applJsp=documentBrowse.
jsp&docNumber=IC40975&searchArg=IC40975&navItem=sis.jsp
-Original Message-
From: Warren Betty [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 3:03 PM
To: [EMAIL PROTECTED]
Subject: Re: Messages stuck in the XMIT queue
Peter,
Thanks for your quick response and suggestions.
They are all checked.
Cheers,
David
"Potkay, Peter M
(PLC, IT)" To:
[EMAIL PROTECTED]
<[EMAIL PROTECTED]cc:
RTFORD.COM>Subject: Re: Messages
stuck in the XMIT queue
Sent by: MQSeries
List
<[EMAIL PROTECTED]
AC.AT>
06/03/2004 11:36 AM
Please respond to
MQSeries List
!
Please let us know what you find.
What if the sending side has no DLQ, the XMITQ can take a message 10 MEG
long, but the channel can only accept 4 MEG. Usually the sending MCA would
dump the message to the sender's DLQ. I wonder what would happen if there
was no DLQ on the sender side? Would the channel stay running? Would other
messages be able to get by, or would the big message cork the flow? Not
sure. Just typing out loud...
Maybe you can eliminate this possibility by checking the sizes of the
message, the XMITQ and the channel, as well as verifying that you do have a
DLQ on the sender side.
-Original Message-
From: Warren Betty [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 2:17 PM
To: [EMAIL PROTECTED]
Subject: Re: Messages stuck in the XMIT queue
However the channel is up and running and this problem occurs on the z/os
platform.
I already check the MSTR and CHIN and there is no error messages.
Stop/start the channel will not fix the problem since it causes MSTR to
crash with 6C6.
I already open a PMR with IBM with SEV 2.
We are at WMQ 5.3.1 and z/os 1.3
David
"Potkay, Peter M
(PLC, IT)" To:
[EMAIL PROTECTED]
<[EMAIL PROTECTED]cc:
RTFORD.COM>Subject: Re: Messages
stuck in the XMIT queue
Sent by: MQSeries
List
<[EMAIL PROTECTED]
AC.AT>
06/03/2004 10:38 AM
Please respond to
MQSeries List
Channel cannot get itself running for whatever reason.
What do the AMQERROR logs say on both ends for this channel?
-Original Message-
From: Warren Betty [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 1:05 PM
To: [EMAIL PROTECTED]
Subject: Messages stuck in the XMIT queue
Hi, All,
What are the possible reasons that might cause messages stuck in the
transmission queue?
I check the MQXQH and it looks OK.
Thanks for your help.
David King
American Honda Motors
Instructions for managing your mailing list 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
Instructions for managing your mailing list 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
Re: SSL, MQClients and Symmetric keys
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, IT)" To:
[EMAIL PROTECTED]
<[EMAIL PROTECTED]cc:
RTFORD.COM>Subject: 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'
Re: Messages stuck in the XMIT queue
!
Please let us know what you find.
What if the sending side has no DLQ, the XMITQ can take a message 10 MEG
long, but the channel can only accept 4 MEG. Usually the sending MCA would
dump the message to the sender's DLQ. I wonder what would happen if there
was no DLQ on the sender side? Would the channel stay running? Would other
messages be able to get by, or would the big message cork the flow? Not
sure. Just typing out loud...
Maybe you can eliminate this possibility by checking the sizes of the
message, the XMITQ and the channel, as well as verifying that you do have a
DLQ on the sender side.
-Original Message-
From: Warren Betty [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 2:17 PM
To: [EMAIL PROTECTED]
Subject: Re: Messages stuck in the XMIT queue
However the channel is up and running and this problem occurs on the z/os
platform.
I already check the MSTR and CHIN and there is no error messages.
Stop/start the channel will not fix the problem since it causes MSTR to
crash with 6C6.
I already open a PMR with IBM with SEV 2.
We are at WMQ 5.3.1 and z/os 1.3
David
"Potkay, Peter M
(PLC, IT)" To:
[EMAIL PROTECTED]
<[EMAIL PROTECTED]cc:
RTFORD.COM>Subject: Re: Messages
stuck in the XMIT queue
Sent by: MQSeries
List
<[EMAIL PROTECTED]
AC.AT>
06/03/2004 10:38 AM
Please respond to
MQSeries List
Channel cannot get itself running for whatever reason.
What do the AMQERROR logs say on both ends for this channel?
-Original Message-
From: Warren Betty [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 1:05 PM
To: [EMAIL PROTECTED]
Subject: Messages stuck in the XMIT queue
Hi, All,
What are the possible reasons that might cause messages stuck in the
transmission queue?
I check the MQXQH and it looks OK.
Thanks for your help.
David King
American Honda Motors
Instructions for managing your mailing list 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
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Messages stuck in the XMIT queue
Channel cannot get itself running for whatever reason. What do the AMQERROR logs say on both ends for this channel? -Original Message- From: Warren Betty [mailto:[EMAIL PROTECTED] Sent: Thursday, June 03, 2004 1:05 PM To: [EMAIL PROTECTED] Subject: Messages stuck in the XMIT queue Hi, All, What are the possible reasons that might cause messages stuck in the transmission queue? I check the MQXQH and it looks OK. Thanks for your help. David King American Honda Motors Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: SSL, MQClients and Symmetric keys
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, and they are stored in multiple places, which is not goodness. Going with an internal signer works very nicely. When you get to using SSL with 3rd parties, you will need to explore external CAs, because both you and the other party need to have certificates signed by someone that you both trust. This will present a problem, as any queue manager can only present one certificate. It can't present different certificates to different channel partners. This means that when you have queue managers with certs signed by an external CA, you will need to have that CAs signer cert in the key repository of your local admin clients. Regards, 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 |-+------> | | "Potkay, Peter M | | | (PLC, IT)" | | | <[EMAIL PROTECTED]| | | RTFORD.COM>| | | Sent by: MQSeries | | | List | | | <[EMAIL PROTECTED]| | | AC.AT> | | | | | | | | | 02/06/2004 06:29 | | | Please respond to | | | MQSeries List | |-+--> >--- ---| | | | To: [EMAIL PROTECTED] | |
Re: FW: TEMPDYN Vs PREDEFINED
Typically, a responder app will use the same Persistence Attribute for the reply message that they saw in the request message. But it is entirely up to them. They can code whatever they want, and you have no control over it. If this is an issue, use predefined queues, or use Permanent Dynamic Queues, which will accept Persistent messages. But they need to be specifically deleted by an app with sufficient authority (usually the app that created it), otherwise you will find yourself with thousands of queues that are not being used. -Original Message-From: Khedr, Hossam (Genworth) [mailto:[EMAIL PROTECTED]Sent: Tuesday, June 01, 2004 4:26 PMTo: [EMAIL PROTECTED]Subject: Re: FW: TEMPDYN Vs PREDEFINED Hi Peter, I found the Persistence : 1 in the message received on the defined queue. Can I control that as a requester application, or should be done by the responder app? Thanks [Khedr, Hossam (GEI, MORT)] -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Potkay, Peter M (PLC, IT)Sent: Tuesday, June 01, 2004 2:44 PMTo: [EMAIL PROTECTED]Subject: Re: FW: TEMPDYN Vs PREDEFINED Or he is trying to put a persistent message to the temp dyn queue, which will fail, but would have worked going to the manually defined queue. -Original Message-From: Anthony G Allison [mailto:[EMAIL PROTECTED]Sent: Tuesday, June 01, 2004 12:58 PMTo: [EMAIL PROTECTED]Subject: Re: FW: TEMPDYN Vs PREDEFINEDHossam, Before you put your request message to the queue you must populate the MQMD REPLYTOQ field with the queue name from the MQOD of the temp dynamic queue. This should resolve the problem. Anthony Allison Certified MQ Specialist Certified MQ Developer Certified MQ Solutions ProviderCSC 1001 G StreetSuite 800WDC, 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. "Khedr, Hossam (Genworth)" @GENWORTH.COM> Sent by: MQSeries List 06/01/2004 12:24 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: FW: TEMPDYN Vs PREDEFINED> Hi All,> I using a JMS program to send a request and wait for the response on a replyToQueue. When I created the replyToQueue using runmqsc and DEFINE command, I end up getting the response with no problem. When I tried to dynamically create a Temporary replyToQueue using the JMS createTemporaryQueue() , all reply messages end up in the DEAD.LETTER.QUEUE. Any explanation or solutions would be very appreciated. > Thanks,> Hossam Khedr> GEMICO Canada> > > Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archiveThis 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.
SSL, MQClients and Symmetric keys
As my first attempt at SSL, I want to implement SSL on MO71, so that only my 6 teammates and myself can connect to all our QMs over the dedicated SVRCONN channel I have set up for MO71. So basically I want to implement SSL for a client application that might connect to any one of a 100 QMs (Windows / Solaris / HP-UX / z/OS), and only 6 Windows desktops will ever run this client app. I need your opinions if this design is valid. Having read a ton of stuff on SSL over the past 2 weeks, and getting an SSL tutorial completed where I have 2 QMs running with SSL on the channels between them, I am still nowhere near comfortable with this SSL stuff. (Was it Albert Einstein that said "If you can't explain something so your grandmother understands it, YOU don't understand it." Right now, Grams has no clue what I'm babbling about!) The biggest problem for me is the whole concept of getting certificates. Since the certificates for the QMs and the clients will be personally installed by me on all machines, and all the machines are internal, I don't really need to go to a CA to get certificates do I? A self signed certificate will work just fine, no? And taking it a step further, couldn't I just avoid certificates completely and just use a symmetric key? How do I get a symmetric key? Seems the only certificates I see (self signed or not) are for Public / Private key pairs. I am thinking "Wouldn't it be easy to create a symmetric key called XYZ, install XYZ on all the servers and the 6 desktops, and tell the QM or the client to use that symmetric key?" Or do I have to create a certificate, assign it to the QM, and give the public part of it to the clients (our desktops running MO71)? I want a solution where I can use the same key (or certificate) on all my QMs and MQ clients connecting to those QMs. And as I add more QMs in the future, I can just add this same key (or certificate) to them. I'll tackle SSL with outside un-trusted parties after I get this down (and the need arises.) 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
Re: FW: TEMPDYN Vs PREDEFINED
Or he is trying to put a persistent message to the temp dyn queue, which will fail, but would have worked going to the manually defined queue. -Original Message-From: Anthony G Allison [mailto:[EMAIL PROTECTED]Sent: Tuesday, June 01, 2004 12:58 PMTo: [EMAIL PROTECTED]Subject: Re: FW: TEMPDYN Vs PREDEFINEDHossam, Before you put your request message to the queue you must populate the MQMD REPLYTOQ field with the queue name from the MQOD of the temp dynamic queue. This should resolve the problem. Anthony Allison Certified MQ Specialist Certified MQ Developer Certified MQ Solutions ProviderCSC 1001 G StreetSuite 800WDC, 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. "Khedr, Hossam (Genworth)" @GENWORTH.COM> Sent by: MQSeries List 06/01/2004 12:24 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: FW: TEMPDYN Vs PREDEFINED> Hi All,> I using a JMS program to send a request and wait for the response on a replyToQueue. When I created the replyToQueue using runmqsc and DEFINE command, I end up getting the response with no problem. When I tried to dynamically create a Temporary replyToQueue using the JMS createTemporaryQueue() , all reply messages end up in the DEAD.LETTER.QUEUE. Any explanation or solutions would be very appreciated. > Thanks,> Hossam Khedr> GEMICO Canada> > > Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: 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.
Re: MQ Version 5.3.1 and SSL
Title: MQ Version 5.3.1 and SSL It does not matter that that parameter is set to Y, unless you typed something in SSLCIPH. From the MQSC Manual : SSLCIPH(string) If the SSLCIPH parameter is blank, no attempt is made to use SSL on the channel. SSLCAUTH The parameter is used only for channels with SSLCIPH specified. If SSLCIPH is blank, the data is ignored and no error message is issued. -Original Message-From: Yeske, Judy [mailto:[EMAIL PROTECTED]Sent: Friday, May 28, 2004 2:40 PMTo: [EMAIL PROTECTED]Subject: MQ Version 5.3.1 and SSL Hello and Happy Friday, Today I upgraded to Websphere MQ for z/OS Version 5.3.1 (was at Version 2.1). I noticed that my RECEIVER Channels have SSL certificate required set to Y. As of now, we are not planning on using SSL. Question - what did I do for this to be set to Y ? Was it because I defined SYSTEM.DEFAULT.AUTHINFO.CRLLDAP ? I'm getting message: GLD0128A The SSL certificate sent by the client or the server certificate in TSOJKEY2 is not valid. I need to have an understanding as to what I did with my install to cause this to happen. Appreciate your help ! Thanks, Judy Yeske This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: 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
Re: Changing MQXQH on the fly
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
Re: CPU Usage in a cluster environment.
Huh, well that contradicts what I said, doesn't it? What is the MessageRetryInterval and MessageRetryCount on the CLUSRCVR in question? Maybe if these #s are very small, the CLUSRCVR channel very quickly puts the message to the DLQ, and then the CLUSSNDR can send the next one, so it is running? And maybe because the CLUSRCVR is dumpimg to the DLQ instead of the real queue, it is showing PAUSED? I don't really like that answer. Besides if that was happening, I would think your DLQs would be filling (what is their depth?), and the SCTQ would be going down. I really would have expected the CLUSSNDR to be RETRYING if its partner CLUSRCVR is PAUSED. Thats the way it always worked with regular SNDR / RCVRs. Maybe clusters are different? -Original Message- From: Antony Boggis [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 26, 2004 3:13 PM To: [EMAIL PROTECTED] Subject: Re: CPU Usage in a cluster environment. Peter, Well, here's some outputs from runmqsc: I have duplicated the scenario (using amqsblst to load up the queues). The receiving queues are full and the local cluster transmit queue is "backed up": Firstly the state of one of the receiving systems (CLUSTER2B.AR1.MANAGER): dis ql(AR1IP1) curdepth maxdepth 3 : dis ql(AR1IP1) curdepth maxdepth AMQ8409: Display Queue details. QUEUE(AR1IP1) MAXDEPTH(2000) CURDEPTH(2000) The manually defined channels: dis chl(TO*) 4 : dis chl(TO*) AMQ8414: Display Channel details. CHANNEL(TO.AR1) CHLTYPE(CLUSRCVR) AMQ8414: Display Channel details. CHANNEL(TO.AS1) CHLTYPE(CLUSSDR) Their status (including auto-defined channels): dis chs(TO*) 5 : dis chs(TO*) AMQ8417: Display Channel Status details. CHANNEL(TO.AR1) XMITQ( ) CONNAME(192.168.227.46) CURRENT CHLTYPE(CLUSRCVR) STATUS(PAUSED) RQMNAME(CLUSTER2B.AS2.MANAGER) AMQ8417: Display Channel Status details. CHANNEL(TO.AS2) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) CONNAME(192.168.227.46(1414)) CURRENT CHLTYPE(CLUSSDR)STATUS(RUNNING) RQMNAME(CLUSTER2B.AS2.MANAGER) AMQ8417: Display Channel Status details. CHANNEL(TO.AR1) XMITQ( ) CONNAME(192.168.227.45) CURRENT CHLTYPE(CLUSRCVR) STATUS(PAUSED) RQMNAME(CLUSTER2B.AS1.MANAGER) AMQ8417: Display Channel Status details. CHANNEL(TO.AR2) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) CONNAME(192.168.227.43(1414)) CURRENT CHLTYPE(CLUSSDR)STATUS(RUNNING) RQMNAME(CLUSTER2B.AR2.MANAGER) AMQ8417: Display Channel Status details. CHANNEL(TO.AS1) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) CONNAME(192.168.227.45(1414)) CURRENT CHLTYPE(CLUSSDR)STATUS(RUNNING) RQMNAME(CLUSTER2B.AS1.MANAGER) AMQ8417: Display Channel Status details. CHANNEL(TO.AR1) XMITQ( ) CONNAME(192.168.227.43) CURRENT CHLTYPE(CLUSRCVR) STATUS(RUNNING) RQMNAME(CLUSTER2B.AR2.MANAGER) Now, looking at one of the sending queue managers (CLUSTER2B.AS1.MANAGER): The xmitq: dis ql(SYSTEM.CLUSTER.TRANSMIT.QUEUE) curdepth 1 : dis ql(SYSTEM.CLUSTER.TRANSMIT.QUEUE) curdepth AMQ8409: Display Queue details. QUEUE(SYSTEM.CLUSTER.TRANSMIT.QUEUE)CURDEPTH(998350) The manually defined cluster channels: dis chl(TO*) 2 : dis chl(TO*) AMQ8414: Display Channel details. CHANNEL(TO.AR1) CHLTYPE(CLUSSDR) AMQ8414: Display Channel details. CHANNEL(TO.AS1) CHLTYPE(CLUSRCVR) And their status: dis chs(TO*) 3 : dis chs(TO*) AMQ8417: Display Channel Status details. CHANNEL(TO.AS2) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) CONNAME(192.168.227.46(1414)) CURRENT CHLTYPE(CLUSSDR)STATUS(RUNNING) RQMNAME(CLUSTER2B.AS2.MANAGER) AMQ8417: Display Channel Status details. CHANNEL(TO.AR1) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) CONNAME(192.168.227.42(1414)) CURRENT CHLTYPE(CLUSSDR)STATUS(RUNNING) RQMNAME(CLUSTER2B.AR1.MANAGER) AMQ8417: Display Channel Status details. CHANNEL(TO.AS1) XMITQ( ) CONNAME(192.168.227.42) CURRENT CHLTYPE(CLUSRCVR) STATUS(RUNNING) RQMNAME(CLUSTER2B.AR1.MANAGER) AMQ8417: Display Channel Status details. CHANNEL(TO.AR2) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) CONNAME(192.168.227.43(1414)) CURRENT CHLTYPE(CLUSSDR)STATUS(RUNNING) RQMNAME(CLUSTER2B.AR2.MANAGER) I'm not sure if this picture is what you are describing or not. tonyB. -Original Message- From: MQSeries List on behalf of Potkay, Peter M (PLC, IT) Sent: Wed 26/05/2004 3:45 PM To: [EMAIL PROTECTED] Subject: Re: CPU
Re: Hidden mystery
Sorry to ask the obvious. You did right click on the queue and select REFRESH before you selected PROPERTIES, right? -Original Message- From: Dawson, John [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 8:18 AM To: [EMAIL PROTECTED] Subject: Re: Hidden mystery Bobbee is correct. I have altered the base queue name of an alias queue through a MQAI program. I then checked the queue through the MQExplorer and it did not show the update. I then used runmqsc to verify the change and runmqsc showed the change. Still after a period of time the MQExplorer did not show the update. John -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 7:05 AM To: [EMAIL PROTECTED] Subject:Re: Hidden mystery I have seen instances where MQExplorer has reported things in error but I don't recall it ever not reporting an object not being there or being there when it wasn't. Pauls suggestions are good. BUT! always go with runmqsc to be sure. bobbee >From: Paul Clarke <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Hidden mystery >Date: Tue, 25 May 2004 11:14:08 +0100 > >Bharath, > >Q1. I'm not aware of the ability to 'hide' objects from certain users. You >can, of course, prevent users from using certain objects. > >Q2. I can think of no way MQ Explorer can define objects that are not know >to the Solaris machine. I think it far more likely that > >a) You have actually defined then on a diffeernt machine that you thought >you had > >or > >b) When looking for these objects you are not taking into account case >sensitivity. > > >It would be interesting to use another remote administrator, say my MO71 >support pac, to see whether the objects are visible to it. > >Cheers, >P. > >Paul G Clarke >WebSphere MQ Development >IBM Hursley > > > > >|-+> >| | Bharath Ram | >| | Srinivasan | >| | <[EMAIL PROTECTED]| >| | ARIS.CO.IN> | >| | Sent by: MQSeries| >| | List | >| | <[EMAIL PROTECTED]| >| | N.AC.AT> | >| || >| || >| | 25/05/2004 09:14 | >| | Please respond to| >| | MQSeries List| >|-+> > > >--- ---| > | > | > | To: [EMAIL PROTECTED] > | > | cc: > | > | Subject: Hidden mystery > | > | > | > | > | > > >--- ---| > > > > >Folks, > > >Q1: Is there some way to hide MQ objects (say a queue or channel) for a >particular set of users? If yes, how? > > >Q2: > > >Scenario - I am using IBM's MQ Explorer(v 5.2.1) in Windows to >browse/define/modify objects in my Solaris box. There are some >objects/processes which I created/modified using MQ Explorer. But I was >perplexed when I ran a display command for that Process directly in the >Solaris box - "It said that the object was not found". > > >But the same process kept working with my application at that time. My >question - Why is the Solaris box where the MQ is hosted not able to >identify its own objects? Is the MQ Explore hiding something? > > >Thanks in advance for your valuable inputs. > > >Cheers, > > >Bharath > > > > > > > > > InterScan_Disclaimer.txt has been removed from this note on May 25 >2004 by Paul Clarke > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and ma
Re: SNDR channel INITIALIZING after QM bounce
Tibor, I only see one entry in the SYNCQ for the problem channel. And that entry looks OK, as far as I can tell, the only difference being in the MQMD of that message, where the putting application for the bad channel is amqpcsea.exe, instead of runmqchl.exe. On IBM's site, this problem describes our scenario: http://www-1.ibm.com/support/docview.wss?rs=0&q1=IY29028&uid=swg1IY29028&loc=en_US&cs=utf-8&lang= but it says it was fixed in CSD06 on 5.2 This next link says the problem has apparently resurfaces in 5.3, and again CSD06 will fix it. This problem directly referances the above one and says the 2 are similiar: http://www-1.ibm.com/support/docview.wss?rs=0&q1=IC39552&uid=swg1IC39552&loc=en_US&cs=utf-8&lang= (Thanks JasonE for these links). I don't know if we are going to take an outage to apply a CSD just for this relativily minor problem. Maybe I will just delete and recreate the channel. But reading those above links, it looks like if the delete / recreate fixes it, there is no guarantee it won't happen again until CSD06 is applied. -Original Message-From: Tibor [mailto:[EMAIL PROTECTED]Sent: Tuesday, May 25, 2004 2:18 AMTo: [EMAIL PROTECTED]Subject: Re: SNDR channel INITIALIZING after QM bounce Peter, I suspect a garbage in SYNCQ because I've already seen similar. There was 2 entry for 1 channel and only way for starting channel after deleting and re-defining. Wrong entries disappeared by command 'DELETE CHANNEL' from the sync queue. Hope this helps, Tibor > All machines in question are Windows 2000. MQ 5.3 CSD4. Being Windows boxes, > you know what that means - monthly security patches with reboots! Yay > These regular server reboots have surfaced the following issue in 2 of my 4 > environments. I have a channel which needs to be up pretty much all the > time, so I have the DISCINT set to 30. And the channel speed is set to > fast (probably not relevant). This channel goes from QM1 to QM2, and it has > a partner going from QM2 to QM1. The channels perform as expected when the > QMs are running. > When the QMs get bounced, this channel (which was running when the QM went > down) comes up ready for more message in all 4 environments from QM1 to QM2, > and from QM2 to QM1 in the LAB and in PROD. But in DEV and QA, the > QM2.QM1.FAST channel always comes up as initializing, and stays that way > until I manually start it. > All the servers and MQ versions are identical. > All the channels are defined identically (really, they are). > The only difference I can see is when I browse the SYSTEM.CHANNEL.SYNCQ. On > the problem channels, the corresponding message in the SYNCQ looks like it > was put by AMQPCSEA.EXE. But for all the SNDR channels that don't come up > INITIALIZING (they trigger normally), the corresponding message in the SYNCQ > was put by runmqchl.exe. The last 100 bytes of each message in the SYNCQ is > all garbled, so I can't tell what it means or if there is a difference > between the "good" channels and the "bad" channels. > Any idea why these channels keep coming up in INITIALIZING mode, and then > why they are stuck in INITIALIZING mode until I issue START? > In the error log on the sending side, I see the following, until I manually > restart the channel. A weird error, since the channel is most definitely > there, just stuck in INITIALIZING. > 05/20/2004 20:25:38 > AMQ9002: Channel program started. > EXPLANATION: > Channel program 'QM2.QM1.FS' started. > ACTION: > None. > > --- > 05/20/2004 20:25:38 > AMQ9519: Channel 'QM2.QM1.FS' not found. > EXPLANATION: > The requested operation failed because the program could not find a > definition > of channel 'QM2.QM1.FS'. > ACTION: > Check that the name is specified correctly and the channel > definition is > available. > - amqrccca.c : 452 > > 05/20/2004 20:25:38 > AMQ: Channel program ended abnormally. > EXPLANATION: > Channel program 'QM2.QM1.FS' ended abnormally. > ACTION: > Look at previous error messages for channel program 'QM2.QM1.FS' in > the error files to determine the cause of the failure. > - amqrccca.c : 776 > > Peter Potkay > MQSeries Specialist > The Hartford Financial Services > [EMAIL PROT
Re: CPU Usage in a cluster environment.
When you say the CLUSSNDR channel was running, were you looking at the manually defined CLUSSNDR, or the AutoDefined CLUSSNDR? The manual one may have been running, but it was not being used to send any messges. The AutoDefined CLUSSNDR is the one that was (attempting) to do the work. If the CLUSSRCVR was paused, then the partner CLUSSNDR (the auto defined one) must have been retrying. If a channel is retrying, that knocks it down a couple of notches inside the Cluster WorkLoad Algorithim. If there were multiple QMs hosting the destination queue, and all the AutoDefined CLUSSNDRs to them were RETRYING, then the algorithim would be spinning on all these messages trying all the alternate paths over and over. Were any messages going to the DLQ on the target QMs? I would think that after the CLUSSRCVR went through its MessageRetryCount x MessageRetryInterval, it would put one message to the DLQ, before repeating the process on the next message it got. -Original Message-From: Antony Boggis [mailto:[EMAIL PROTECTED]Sent: Tuesday, May 25, 2004 12:11 PMTo: [EMAIL PROTECTED]Subject: Re: CPU Usage in a cluster environment. Yes, the "backed up" system was the qmgr with >5,000,000 messages on the cluster xmit q. I would not expect any "rerouting" to happen since the queue managers were "alive" and reachable. There was just no room for any more messages. No amount of re-routing would have changed that. What I thought interesting is that both the cluster sender channel instances from this system to the remote systems (where the dest q was full) were in a Running state, but the partner cluster receiver channels were Paused. However, your point about the cluster workload exit being called for every message every time a channel retry interval passes may be a clue. The system is now "cleared", but I will try some more testing again soon. Paul Clarke also suggested running a trace. A good point. I shall try that also. tonyB. From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Tuesday, May 25, 2004 12:15 AMTo: [EMAIL PROTECTED]Subject: Re: CPU Usage in a cluster environment. [Deutsche Boerse Systems:Virus checked] Antony, if the "backed up" system is the Queuemanager with the many messages in the SYSTEM.CLUSTER.TRANSMIT.QUEUE then the "cluster rerouting" may cause the cpu usage. If there are messages on the SYSTEM.CUSTER.TRANSMIT.QUEUE and the chosen destination (channel) is in retry, then MQ will try at every retry interval of the channel to find an alternate route to the destination queue. This is done by reading the message from the SYSTEM.CLUSTER.XMIT.QUEUE, followed by a put to the target queue. this will drive the cluster workload mechanism and make MQ chose a new destination (if any). Unfortunately, if there is only one destination, then this is just a waste of cpu and log space (if messages are persistent). I do not know if this is really the reason, because i do not know what amqzlaa0_nd is doing, so this is just a guess... Regards, Stefan Antony Boggis <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 24.05.2004 21:32 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject: CPU Usage in a cluster environment. [Deutsche Boerse Systems:Virus checked] .Environment: Solaris 5.8 (24 CPUs, 98Gb RAM), WMQ 5.3 CSD05.I have a cluster of 4 queue managers. This past weekend we were running some tests sending volumes of messages. After a period of time we had some application issues (not MQ) on two of the receiving queue managers. Eventually several local queues filled and, as expected the cluster receiver channal on those queue managers went into a PAUSED state and messages (to the tune of > 500,000) have piled up on the sending system's SYSTEM.CLUSTER.TRANSMIT.QUEUE. This all comes as no surprise and I'd expect to hear you all say "working as designed".My question is this... on the "backed up" system, which to all intents and purposes, is now idle (no applications are sending messages), why is my CPU usage (process: amqzlaa0_nd) pretty much maxing out one of the systems CPU's (>4% CPU usage on this 24 CPU box)? 'top' shows a CPU time for amqzlaa0_nd of 41.5H.The sending system is actually showing the cluster sender channels as RUNNING, but the receiving end is showing a status of PAUSED.Regards,Antony Boggis. --Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen.Wenn Sie nicht der beabsichtigte Empfaenger sind,
SNDR channel INITIALIZING after QM bounce
All machines in question are Windows 2000. MQ 5.3 CSD4. Being Windows boxes, you know what that means - monthly security patches with reboots! Yay These regular server reboots have surfaced the following issue in 2 of my 4 environments. I have a channel which needs to be up pretty much all the time, so I have the DISCINT set to 30. And the channel speed is set to fast (probably not relevant). This channel goes from QM1 to QM2, and it has a partner going from QM2 to QM1. The channels perform as expected when the QMs are running. When the QMs get bounced, this channel (which was running when the QM went down) comes up ready for more message in all 4 environments from QM1 to QM2, and from QM2 to QM1 in the LAB and in PROD. But in DEV and QA, the QM2.QM1.FAST channel always comes up as initializing, and stays that way until I manually start it. All the servers and MQ versions are identical. All the channels are defined identically (really, they are). The only difference I can see is when I browse the SYSTEM.CHANNEL.SYNCQ. On the problem channels, the corresponding message in the SYNCQ looks like it was put by AMQPCSEA.EXE. But for all the SNDR channels that don't come up INITIALIZING (they trigger normally), the corresponding message in the SYNCQ was put by runmqchl.exe. The last 100 bytes of each message in the SYNCQ is all garbled, so I can't tell what it means or if there is a difference between the "good" channels and the "bad" channels. Any idea why these channels keep coming up in INITIALIZING mode, and then why they are stuck in INITIALIZING mode until I issue START? In the error log on the sending side, I see the following, until I manually restart the channel. A weird error, since the channel is most definitely there, just stuck in INITIALIZING. 05/20/2004 20:25:38 AMQ9002: Channel program started. EXPLANATION: Channel program 'QM2.QM1.FS' started. ACTION: None. --- 05/20/2004 20:25:38 AMQ9519: Channel 'QM2.QM1.FS' not found. EXPLANATION: The requested operation failed because the program could not find a definition of channel 'QM2.QM1.FS'. ACTION: Check that the name is specified correctly and the channel definition is available. - amqrccca.c : 452 05/20/2004 20:25:38 AMQ: Channel program ended abnormally. EXPLANATION: Channel program 'QM2.QM1.FS' ended abnormally. ACTION: Look at previous error messages for channel program 'QM2.QM1.FS' in the error files to determine the cause of the failure. - amqrccca.c : 776 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
Re: Message Out of Order
Yes, MQ can guarantee message order without using grouping, or getting funky with sequence #s in The CorrelID field. You just gotta follow the rules. Its an IBM FAQ: http://www.developer.ibm.com/tech/faq/individual?oid=1:401:416:158:25280 And the same info is also explained in the Intercommunication manual. -Original Message- From: Lynn Nelson [mailto:[EMAIL PROTECTED] Sent: Friday, May 21, 2004 11:26 AM To: [EMAIL PROTECTED] Subject: Re: Message Out of Order Krishan, It is my understanding (and experience) that MQ does not guarantee that messages will be delivered in the same order in which they were sent. There are many possible reasons that the order may change (which other people have just detailed in recent postings). The only way to guarantee that an application receives the messages in the same order in which they were sent is to use message grouping. We use that all the time and it works fine, although watch out for clustering (for which you need a little workaround). Lynn -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Krishan Agarwal Sent: Friday, May 21, 2004 9:08 AM To: [EMAIL PROTECTED] Subject: Message Out of Order Hi, I am having a sitituation where I am putting messages say A, B, and C on remote queues. My application log and MQMD puttime stamp (on the remote queue) shows that these three messages were put in order i.e A,B,C but they appear on the remote queue as B,C,A. This is causing the remote application to hang because it expects the messages to be in order. All these three messages were put within a time period of 0.5 secs. All the messages has default (0) priority. The local defination of remote queue, transmit queue and the remote queue has default priority (0). We are not sure what could be the probable reason for this or how could we avoid the similar occurance in the future. Any help from the group will be great.. Regards, Krishan Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Rejoing the cluster after forceremoved.
Title: Rejoing the cluster after forceremoved. Yes, issue the REFRESH command. -Original Message-From: Jose, Prince [mailto:[EMAIL PROTECTED]Sent: Friday, May 21, 2004 8:45 AMTo: [EMAIL PROTECTED]Subject: Rejoing the cluster after forceremoved. Hello! I have forceremoved a queue manager from a cluster using RESET command. Can I add this queue manager back to the cluster before the 90 days?? Thanks, Prince This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: Listeners
http://www.developer.ibm.com/tech/faq/individual?oid=1:401:416:127:81789 A good link on the diff between the 2. -Original Message- From: Gunter Jeschawitz [mailto:[EMAIL PROTECTED] Sent: Monday, May 17, 2004 2:27 PM To: [EMAIL PROTECTED] Subject: Re: SV: Listeners On UNIX systems, you can use inetd or runmqlsr, on windows, you should use runmqlsr only if you know what you do, maybe to test something. If unsure, use Websphere MQ Explorer or amqmdain to configure and/or start the listener, otherwise you'll use the interactive user. Am Di, den 18.05.2004 schrieb MQ News um 13:15: > Hi Gunilla! > > As far as I know for AIX you have to use inetd.conf and for Windows > you have to use runmqlsr. > > Regards Jessica > -Ursprungligt meddelande- > Från: MQSeries List [mailto:[EMAIL PROTECTED] > Lindberg, Gunilla > Skickat: den 12 maj 2004 09:21 > Till: [EMAIL PROTECTED] > Ämne: Listeners > > > > Hi! > > Does anybody know the advantages, disadvantages in using > inetd.conf verses runmqlsr? > > Regards Gunilla Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: CLUSTER PROBLEM
You did it backwards. It should be this RESET CLUSTER(Y) QMNAME(X) ACTION(FORCEREMOVE) QUEUES(YES) The cluster attribute says which cluster do you want purge of the bad data. The QM attribute is what QM you want to force out. -Original Message- From: Teofils F. Turlais [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 18, 2004 2:36 PM To: [EMAIL PROTECTED] Subject: CLUSTER PROBLEM I just did the RESET CLUSTER(X) QMNAME(Y) ACTION(FORCEREMOVE) QUEUES(YES) with no result. I should have told you before that I wanted to replace Y with a clone YY which has the same cluster queue name in the same clsuter. Now I have two queues with the same name hosted by 2 different queue managers. And have deleted these queues from queue managers Y and YY but they both still appear in the repository queue manager of the cluster. I did the above command from the cluster repository queue manager for both Y and YY with no change. T.F. Turlais Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Removing cluster queues
On a Full Repository QM in ClusterY, issue the following command: RESET CLUSTER(ClusterY) ACTION(FORCEREMOVE) QMNAME(X) QUEUES(YES) You didn't say you used QUEUES(YES), which will cause the queues from X to be deleted in ClusterY. -Original Message- From: Teofils F. Turlais [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 18, 2004 1:54 PM To: [EMAIL PROTECTED] Subject: Removing cluster queues I have set up 5 clusters each of which shares a common queue manager. This queue manager (X) has 5 receiver channels for each of the clusters and the queue manager itself is defined in a clusterlist. I had to delete reference to queue manager X from one of the clusters. So I deleted cluster Y from the cluster list and reset that cluster I was trying to clean up. The problem is that the cluster queue in X still apperars in the repository of cluster Y. I have stopped and deleted the receiver and sender channels to queue manager X from cluster repository manager Y, also in the other direction. But the cluster queue of queue manager X is still in the repository of cluster Y queue manager. I then deleted that queue from queue manager X and did a RESET clluster in cluster Y again, but the queue still remains. How do I get rid of this queue from cluster Y? Any suggestions? Thanks T.F. Turlais Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: getting rid of messages that I do not want to process
Maybe something better, but what about: Just pass the "bad" message along as normal, but set the Expiry to zero, so it Expires as soon as it hits the next queue. Since it is going to a real queue with MQGET activity looking for "good" messages, the expired messages will be cleaned up always. -Original Message- From: Capodicci, Dan (GE Commercial Finance) [mailto:[EMAIL PROTECTED] Sent: Thursday, May 13, 2004 4:37 PM To: [EMAIL PROTECTED] Subject: getting rid of messages that I do not want to process Hi all... I have run into something which seems easy enough but I have not had this requirement before and am not really sure how to go about this. Hopefully, there is something pretty easy to do and I am just not seeing it. I am developing a pretty basic message flow in WMQI (or whatever the correct current name is :) v2.1 and depending upon a value in the data I either want to process the message (lots of stuff in here that I have done before) or not. The question I have is if I read my "decision" field and this is not a message that I want to proceed, how do I cleanly stop the process there?!? I know I can setup a situation where I can use a branching statement and then have it routed to my "catch" queue but then I need to setup some process for cleaning that up. I was wondering if there is a way to simply say "if the message is this, proceed, if not drop it":) Thanks in advance! 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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: VB with ActiveX - Get-Wait is not working
Ruzi, what does "not working" mean? The MQGET ends immediately with a 2033, as if there was no wait interval specified? Or does it end with some other RC? -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 8:19 AM To: [EMAIL PROTECTED] Subject: VB with ActiveX - Get-Wait is not working Hi, One of our VB developers (on W2K/MQ 5.3) has pointed out that GET with Wait was not working. He says he sets MQGMO_WAIT for the MQGMO options, and MQGMO_WAITINTERVAL =3. I suggested setting the Wait-interval to even a bigger number to see if he would notice any difference -- it did not make any diff. I tested the "Get with Wait" in the sample VB program that comes with MQ, and it works. So, I think the problem has something to do with with ActiveX. Any ideas? Your input would be much appreciated. Best regards, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: NPMSPEED
Don is correct. The lower value is always chosen, in this case NORMAL is considered lower. You can also prove this to yourself by setting the combination that you want, starting the channel, and then doing a channel status. It will show you what the channel is running as. -Original Message- From: Thomas, Don [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 11, 2004 1:48 PM To: [EMAIL PROTECTED] Subject: Re: NPMSPEED If I'm not mistaken, whenever channel parameters are negotiated and there is a difference in parameters, the lower value is adopted, in your example NPMSPEED(NORMAL). 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 Wyatt, T. Rob Sent: Tuesday, May 11, 2004 1:11 PM To: [EMAIL PROTECTED] Subject: NPMSPEED Quick question... Concerning NPMSPEED, the Intercommunication manual states that "Note: If the other end of the channel does not support the option, the channel runs at normal speed." What about if the other end *supports* the option but is set to NPMSPEED(NORMAL)? Do both sides need to specify NPMSPEED(FAST) to make the channel fast or is it sufficient for either side to specify FAST? Thanks -- T.Rob Instructions for managing your mailing list 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
Re: CSD 6
Mike, this comes up so often that I wrote up a doc for my team. Below is a copy of the relevant section: The next step starts the CSD (Fix Pack) installation 21. When applying a CSD, no MQSeries dlls can be held by any programs. This step will insure that all MQSeries dlls are released. a. Go to Services and stop the IBM MQSeries Service. Wait a minute or so, and if still present after 1 minute, right click on the MQServices Icon in the Task bar to stop WebSphere MQ and again to hide the icon. Give it (amqsvc.exe) a minute to drop out of the Task Manager after hiding it. b. The services listed in Appendix A should also be stopped when trying to install the CSD. They have all been known to hold onto MQ dlls. Appendix A Windows Services That Use MQSeries Files The following is a list of services that typically run on Windows Servers at The Hartford. All have been know to interfere with MQSeries Installs / Upgrades due to the fact that they use MQSeries dlls. If MQSeries dlls are in use, MQ will not allow you to upgrade MQ. Use this as a checklist to know which Services you shut off, so that you can restore them all back to their prior state upon completion of your MQSeries work on this server. 1. BGS_SDService Manual or Automatic 2. BMC SoftwareManual or Automatic 3. CPQHostsManual or Automatic 4. Compaq EcoTools Manual or Automatic 5. Compaq Versioning Control Manual or Automatic 6. IBM MQSeriesManual or Automatic 7. IBM MQSI Broker Manual or Automatic 8. IBM MQSI Configuration Manager Manual or Automatic 9. Norton Anti Virus Manual or Automatic 10. Performance Data Log ServiceManual or Automatic 11. QPASA (all three components)Manual or Automatic 12. SMV Collector Manual or Automatic 13. Tivoli Manual or Automatic 14. Windows Management Instrumentation Manual or Automatic 15. BMC is also known to hang onto to MQ Files, but it is not a service. You may need to manually kill it using procexp.exe. BMC is not always present, so you may not want to bother looking for this unless the CSD install cries about locked files even after stopping all of the above. Use listdlls.exe to see what is holding an MQSeries file; use procexp.exe to kill it if you can't find it in Task Manager or Services. -Original Message- From: Ward, Mike S [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 8:39 AM To: [EMAIL PROTECTED] Subject: CSD 6 Hi all, I am trying to apply csd 6 to a 5.3 install on windows 2000. The install waits for all MQ applications and processes to complete. Then it says checking files please wait. Then it stalls and says Websphere MQ files are in use. Stop activity and retry. The message is AMQ4757. Can anyone help? I can't find any MQ running except the csd. Thanks. Mike S. Ward Jr. A.V.P. Information Technology Security Service Federal Credit Union (210)476-4600 [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Application seeing 2009 (MQRC_CONNECTION_BROKEN) errors...
bindings mode, so no channels used. -Original Message- From: Emile Kearns [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 8:20 AM To: [EMAIL PROTECTED] Subject: Re: Application seeing 2009 (MQRC_CONNECTION_BROKEN) errors... 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 communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Application seeing 2009 (MQRC_CONNECTION_BROKEN) errors...
http://www.mqseries.net/phpBB2/viewtopic.php?t=10678&start=15 This posting has the same problem, but alas, no solution. But maybe it will give you some ideas of what to look for. He is also running in bindings mode despite the fact that the title of the post has the word "client" in it. -Original Message- From: Vaic, Miroslav (GE Consumer Finance, consultant) [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 8:16 AM To: [EMAIL PROTECTED] Subject: Re: Application seeing 2009 (MQRC_CONNECTION_BROKEN) errors... Thank you for the ideas. I would like to point out that there are no errors and no FDCs reported - neither at system or qmgr level. This is quite strange. MQ are running well, but the applications get error 2009. Miroslav. - Miroslav Vaic Project UFO - Universal Front-End Interfaces Team Telefon +420 224 442 080 GSM: +420 602 215 470 E-mail: [EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of David C. Partridge Sent: Friday, May 07, 2004 1: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 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: SYSTEM.DEFAULT.INITIATION.QUEUE Question
OK. You kept mentioning a transmit queue backing up, and I though maybe your channel was having problems triggering. You were probably starting the app in the foreground, right? The generation of a trigger message to the INIT queue and the consumption of the trigger message by the trigger monitor are not tied together 100%. Unfortunately, the manuals don't get into this at all. What I have found is that if you satisfy trigger conditions (be it first or every) you will get the trigger message to the init queue. The trigger monitor will in turn process that trigger message for App1 *if App1 is not already running in the foreground*. For example, trigger every, and put one message to start up the app, but does run in the foreground for some time. Drop another message. Trigger conditions are satisfied, the trigger message goes to the init queue, and stays there. The TM will not process it until you kill the first instance of the app, or it ends on its own accord. The same scenario can happen with OnFirst (as message land after the TriggerInterval expires). But if the app is triggered into the background, the TM will be happy to spawn off multiple apps as more messages arrive, and thus keep the init queue clean. -Original Message- From: R. Dirk Tolson [mailto:[EMAIL PROTECTED] Sent: Thursday, May 06, 2004 3:06 PM To: [EMAIL PROTECTED] Subject: Re: SYSTEM.DEFAULT.INITIATION.QUEUE Question No. When a message arrives in the triggered queue MIRROR, the triggered program reads all available messages and puts them to two different queues, one on a different qmgr. Triggering was set to every on the MIRROR queue, even though the triggered application would read all of the current messages. All these trigger messages were filling up the SYSTEM.DEFAULT.INITIATION.QUEUE. If multiple instances of the triggered application were contending for the same resources this may be what seems to hang everything up. I have changed the trigger type to first and this seems to have addressed the problem. MQSeries List <[EMAIL PROTECTED]> wrote on 05/06/2004 01:19:32 PM: > What is the app that is to be triggered? The channel? > > > > -Original Message- > From: R. Dirk Tolson [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 06, 2004 12:24 PM > To: [EMAIL PROTECTED] > Subject: Re: SYSTEM.DEFAULT.INITIATION.QUEUE Question > > > You are right, it is trigger every. I was using the mirrorq program to > duplicate > messages and it is written for trigger every. I guess I will rewrite it > for > trigger first. > > I thought this problem had fixed itself when I get everything caught up > last night, > but I am seeing the same behavior today. The XMIT queue on MVS has 4654 > messages on it, and I cannot even connect to the Unix qmgr (MQ Explorer > reports > it is unavailable for connection.) > > Looking at the log: > > 05/06/04 11:53:14 > AMQ7305: Trigger message could not be put on an initiation queue. > > EXPLANATION: > The attempt to put a trigger message on queue > SYSTEM.DEFAULT.INITIATION.QUEUE > on queue manager SQ13 failed with reason code 2053. The message will be > put on > the dead-letter queue. > ACTION: > Ensure that the initiation queue is available, and operational. > > runmqsc connects, but nothing will run. So I guess I wll need to recycle > it again. > This requires that I do endmqm -p, otherwise you wait for hours (days?) > > Is it just the volume of trigger messages? > > > > > Trigger first or trigger every? If the latter, I suggest that you > change > > your app design to use trigger first and suck all messages from the > > triggered queues. > > > > Dave > > > >> From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of R. > Dirk > >> Tolson > >> Sent: 06 May 2004 01:39 > >> To: [EMAIL PROTECTED] > >> Subject: SYSTEM.DEFAULT.INITIATION.QUEUE Question > >> > >> > >> > >> I have a new message flow that is confusing me. > >> > >> The source is MQ 2.1 on MVS. Persistent messages > >> are routed to MQ 5.3 on Solaris. Occaisonally an event > >> occurs that throws a monkey wrench in things. > >> > >> Today MVS went down and the system had to be IPLed. > >> For some reason a larger than normal number of messages > >> were sitting in the XMIT queue, 24000. On the Unix side > >> the messages were handled until the > >> SYSTEM.DEFAULT.INITIATION.QUEUE reached its > >> maximum depth of 1000, then everything stopped. By > >> starting and stopping the qmgr I could force another 1000 > >> or so messages to be processed until the > >> SYSTEM.DEFAULT.INITIATION.QUEUE reached its max > >> depth again. > >> > >> My main question is what is happening? When the init queue > >> is full some kind of events seem to stop. I guess I could just > >> bump the maximum depth of the init queue up to some ridiculous > >> number, but that doesn't feel right. > >> > >> I seem to be missing a key principle here. Can anybody clue me in? > >> > >> Instructions for managing your mailing list subscription are provided > in > >> the Listse
Re: SYSTEM.DEFAULT.INITIATION.QUEUE Question
What is the app that is to be triggered? The channel? -Original Message- From: R. Dirk Tolson [mailto:[EMAIL PROTECTED] Sent: Thursday, May 06, 2004 12:24 PM To: [EMAIL PROTECTED] Subject: Re: SYSTEM.DEFAULT.INITIATION.QUEUE Question You are right, it is trigger every. I was using the mirrorq program to duplicate messages and it is written for trigger every. I guess I will rewrite it for trigger first. I thought this problem had fixed itself when I get everything caught up last night, but I am seeing the same behavior today. The XMIT queue on MVS has 4654 messages on it, and I cannot even connect to the Unix qmgr (MQ Explorer reports it is unavailable for connection.) Looking at the log: 05/06/04 11:53:14 AMQ7305: Trigger message could not be put on an initiation queue. EXPLANATION: The attempt to put a trigger message on queue SYSTEM.DEFAULT.INITIATION.QUEUE on queue manager SQ13 failed with reason code 2053. The message will be put on the dead-letter queue. ACTION: Ensure that the initiation queue is available, and operational. runmqsc connects, but nothing will run. So I guess I wll need to recycle it again. This requires that I do endmqm -p, otherwise you wait for hours (days?) Is it just the volume of trigger messages? > > Trigger first or trigger every? If the latter, I suggest that you change > your app design to use trigger first and suck all messages from the > triggered queues. > > Dave > >> From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of R. Dirk >> Tolson >> Sent: 06 May 2004 01:39 >> To: [EMAIL PROTECTED] >> Subject: SYSTEM.DEFAULT.INITIATION.QUEUE Question >> >> >> >> I have a new message flow that is confusing me. >> >> The source is MQ 2.1 on MVS. Persistent messages >> are routed to MQ 5.3 on Solaris. Occaisonally an event >> occurs that throws a monkey wrench in things. >> >> Today MVS went down and the system had to be IPLed. >> For some reason a larger than normal number of messages >> were sitting in the XMIT queue, 24000. On the Unix side >> the messages were handled until the >> SYSTEM.DEFAULT.INITIATION.QUEUE reached its >> maximum depth of 1000, then everything stopped. By >> starting and stopping the qmgr I could force another 1000 >> or so messages to be processed until the >> SYSTEM.DEFAULT.INITIATION.QUEUE reached its max >> depth again. >> >> My main question is what is happening? When the init queue >> is full some kind of events seem to stop. I guess I could just >> bump the maximum depth of the init queue up to some ridiculous >> number, but that doesn't feel right. >> >> I seem to be missing a key principle here. Can anybody clue me in? >> >> Instructions for managing your mailing list 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
Re: Max no. of qmgrs
"they get to connect to the default (and probably incorrect one)." That's pessimistic! But probably true, thanks to Murphy. Maybe I'm just lucky, but I have dozens and dozens of QMs, all the default, all with their default XMIT queue turned on to point to the Hub QM, and have no problems. The only place I don't do default QMs is inside Microsoft Hardware Clusters. And the only place I don't do Default XMIT queues is inside MQ clusters or on the HUB QMs. By using default QMs, applications have one less thing to worry about as they migrate their code. Apps connecting in Bindings mode can go from DEV to QA to PROD without any coding changes or config file changes at all. By using default XMIT queues, every time I add a spoke QM I do not have to go to every other spoke QM and create yet another QM Alais. And the DLQ on the Hubs act as a convenient dumping ground for lost messages. I suppose if you are forced to have multiple QMs per server (what was the original question again? :-)) maybe a default is not a good idea. And if you do not use a hub / spoke design, then the default XMIT queues may not work as well for you either. It all depends There is a time and place for everything. -Original Message- From: John Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 12:27 PM To: [EMAIL PROTECTED] Subject: Re: Max no. of qmgrs I would not recommend using default queue managers. Its fine if you have only 1 QM, but I don't think that's realistic (certainly not in my environment). It goes against the IBM support pack recommendations and I ignored this piece of advise and am now paying for it because if applications don't specify a queue manager name, they get to connect to the default (and probably incorrect one). If you have multiple environments on the same box (e.g. both Dev and SysTest on the same host) I would recommend 1 QM for each environment. If MQ had schema names like DB2 and Oracle (I think this is the corect term) I might go with 1 QM with multiple schemas containing the same queue definitions. However, MQ doesn't so I recommend multiple queue managers with the same queue names rather than differently named queues for different environments on the same QM (we tried this also and that didn't work as people "promoted" their code from one environment to the next without changing their config files containing the queue names). As for names, I would recommend the following structure: APPNAME.DIRECTION.TRANSACTION_NAME For example APP1.INB.XYZ001B for APP1 reading XYZ001B type messages and APP1.OUT.ABC998T for APP1 writing ABC998T type messages You could make the transaction name meaningful if you require (we do - i.e. PLACE_CUSTOMER_ORDER). You can then use remote queue to deliver messages to destination applications: APP1.OUT.ABC998T -> APP2.INB.ABC998T And also use alias queues to deliver messages onto common input queues APP2.INB.ABC997T -> APP2.INB.ABC_TRANS APP2.INB.ABC998T -> APP2.INB.ABC_TRANS This allows you to use wildcard authorities, but keep the inbound and outbound ones separate: Setmqaut -m MYQM -n APP2.INB.** -t queue +get +inq etc... You might also want to add a grouping code somewhere in the structure: APP1.OUT.PHASE1.ABC998T or APP1.PHASE1.OUT.ABC998T etc. Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 04 May 2004 16:17 To: [EMAIL PROTECTED] Subject: Re: Max no. of qmgrs Have 1 QM on this server. Make it the default. Have all your apps code a blank QM on the MQCONN call, so they connect to the one and only QM. Name your queues by the app: WS.APP1.REQ WS.APP1.REPLY . . . . WS.APP99.REQ WS.APP99.REPLY Now you can run wild card security commands easily. And each app has its own set of queues. I assume this is one AIX box for PRODUCTION. You would have another AIX box for QA? And another for DEV? If yes, this allows you to repeat the above on each server. As you apps migrate from DEV to QA to PROD, there are ZERO coding changes required, and dozens (hundreds?) of apps can play nice on one QM in each environment. -Original Message- From: W Samuel [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 11:01 AM To: [EMAIL PROTECTED] Subject: Re: Max no. of qmgrs Hello, Thanks David, Peter for your replies. In our landscape we have around 6 to 7 queue managers running on separate Unix systems. Now, the plan is to move all these qmgrs to a single AIX server This has advantages of lower license costs. Our team;s task is to arrive at the specs for such a server. And the solution should be scalable to have more queue managers ... Any pointers as to how we go about this? Is this is a reasonable proposition ? Thanks WS --- "David C. Partridge" <[EMAIL PROTECTED]> wrote: > There probably is such a limit, and this will > primarily b
Re: Max no. of qmgrs
" In the past two years, my unplanned outages have been so low it makes me want to throw a party. " I hope you didn't have plans this weekend! You know you just jinxed yourself! But the point is well made. When have you ever heard of 1 QM crapping out on a server, while the other QMs are fine, and then patting yourself on the back saying "Whew, good thing I put those queues on QMB, since QMA is dead!"? I never have. QMs are amazing animals capable of coordinating tremendous amounts of work. Unless you are dealing with an app that does huge persistent messaging within syncpoint, AND you are prepared to give that 1 QM a separate physical Hard drive for its logs only, I can't see the reason why from a technical standpoint you would want to split queues between QMs, versus putting them all on one QM. In my opinion, the more QMs you have, the more things there are to go wrong, and more things to monitor. More command servers, more listeners, more repository managers, etc. For the people that say they need to separate apps, why stop there? Just have 1 queue only on every queue manager, and have 1 queue manager only on every server. And only 1 server per building... If you are at a point where there is to much work/queues for a single QM for whatever reason, I don't think adding a second QM on the same server will help. It still has to deal with the same hardware restrictions that are giving #1 a problem. -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 11:54 AM To: [EMAIL PROTECTED] Subject: Re: Max no. of qmgrs I currently host 3 production queue managers on one AIX box, and if marketing does its job, I may soon add one more. If I had my way, two of those queue mangers would become one. that is because even though they do provide different services, they are both for the same industry. Plus one of them is rather "dinky" that is to say it has one client connection and four customer queues (two of them are alias definitions). I would love to host those queues and connections on another existing queue manager to conserve resources, and simplify my monitoring and admin tasks. The reason we don't do that is largely political. Operations feels very strongly that the services need to be separate. And because that is the way things were done before I started here two years ago, they won that argument. Fine with me really, I don't have a huge problem with it. I do understand operations point of view. If I host two separate services on one queue manager and then loose that queue manager, I just lost two services not one. My counter point is that we have fairly robust redundancy via HACMP. In the past two years, my unplanned outages have been so low it makes me want to throw a party. So why be paranoid about combining multiple services on one queue manager? The few outages we have had were tied to system resources being stretched to far. Duh, we are running multiple queue managers on box. There is no clear cut answer to your problem, but if it is possible to host multiple services on one queue manager, I say go for it. 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/ W Samuel <[EMAIL PROTECTED]To: [EMAIL PROTECTED] CO.UK> cc: Sent by: MQSeriesSubject: Re: Max no. of qmgrs List <[EMAIL PROTECTED] N.AC.AT> 05/04/2004 11:01 AM Please respond to MQSeries List Hello, Thanks David, Peter for your replies. In our landscape we have around 6 to 7 queue managers running on separate Unix systems. Now, the plan is to move all these qmgrs to a single AIX server This has advantages of lower license costs. Our team;s task is to arrive at the specs for such a server. And the solution should be scalable to have more queue managers ... Any pointers as to how we go about this? Is this is a reasonable proposition ? Thanks WS --- "David C. Partridge" <[EMAIL PROTECTED]> wrote: > There probably is such a limit, and this will > primarily be determined by > disk space, and shared resources such as semaphores > and open file limits and > the like. > > However the return question I have is how many are > you contemplating, and > why do you want to host many QMs on the same box? > > Far better to have a few QMs with '000s of queues > than many QMs with a few > queues each. > > Dave > > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of W > Samuel > Sent: 04 May 2004 14:52 > To: [EMAIL PROTECTED] > Subject: Max no. of qmgrs > > > Hello, > > Is there a limit on the max number of queue managers > that can run on a single host ? >
Re: Max no. of qmgrs
Have 1 QM on this server. Make it the default. Have all your apps code a blank QM on the MQCONN call, so they connect to the one and only QM. Name your queues by the app: WS.APP1.REQ WS.APP1.REPLY . . . . WS.APP99.REQ WS.APP99.REPLY Now you can run wild card security commands easily. And each app has its own set of queues. I assume this is one AIX box for PRODUCTION. You would have another AIX box for QA? And another for DEV? If yes, this allows you to repeat the above on each server. As you apps migrate from DEV to QA to PROD, there are ZERO coding changes required, and dozens (hundreds?) of apps can play nice on one QM in each environment. -Original Message- From: W Samuel [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 11:01 AM To: [EMAIL PROTECTED] Subject: Re: Max no. of qmgrs Hello, Thanks David, Peter for your replies. In our landscape we have around 6 to 7 queue managers running on separate Unix systems. Now, the plan is to move all these qmgrs to a single AIX server This has advantages of lower license costs. Our team;s task is to arrive at the specs for such a server. And the solution should be scalable to have more queue managers ... Any pointers as to how we go about this? Is this is a reasonable proposition ? Thanks WS --- "David C. Partridge" <[EMAIL PROTECTED]> wrote: > There probably is such a limit, and this will > primarily be determined by > disk space, and shared resources such as semaphores > and open file limits and > the like. > > However the return question I have is how many are > you contemplating, and > why do you want to host many QMs on the same box? > > Far better to have a few QMs with '000s of queues > than many QMs with a few > queues each. > > Dave > > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of W > Samuel > Sent: 04 May 2004 14:52 > To: [EMAIL PROTECTED] > Subject: Max no. of qmgrs > > > Hello, > > Is there a limit on the max number of queue managers > that can run on a single host ? > > > Regards > WS > > > > > > > > > Yahoo! Messenger - Communicate instantly..."Ping" > your friends today! Download Messenger Now > http://uk.messenger.yahoo.com/download/index.html > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Max no. of qmgrs
http://www.mqseries.net/phpBB2/viewtopic.php?p=59406&highlight=#59406 But you should be asking yourself "Do I really need all these QMs? Wouldn't the design be better to have 100 queues on 1 QM instead of 1 queue on a 100 QMs?" -Original Message- From: W Samuel [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 9:52 AM To: [EMAIL PROTECTED] Subject: Max no. of qmgrs Hello, Is there a limit on the max number of queue managers that can run on a single host ? Regards WS Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Backout of failed a C++ Application
Yes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, May 03, 2004 3:18 AM To: [EMAIL PROTECTED] Subject: Re: Backout of failed a C++ Application Peter, Is the heartbeat interval measured in seconds ?? Sid -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Saturday, 1 May 2004 11:56 PM To: [EMAIL PROTECTED] Subject: Re: Backout of failed a C++ Application 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=203&uid=swg24006699&loc=en_US&cs =utf-8&lang=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 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 Instructions for managing your mailing list 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 a
Re: Backout of failed a C++ Application
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=203&uid=swg24006699&loc=en_US&cs =utf-8&lang=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 prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Setmqaut on v5.1
Sid, are you trying these commands on a 5.1 system, or a 5.3 system? At 5.1, the wild cards will not work. Only at 5.3. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, April 30, 2004 6:27 PM To: [EMAIL PROTECTED] Subject: Re: Setmqaut on v5.1 Yep..tried that one!...no luck Sid -Original Message- From: Nick Dilauro [mailto:[EMAIL PROTECTED] Sent: Saturday, 1 May 2004 3:17 AM To: [EMAIL PROTECTED] Subject: Re: Setmqaut on v5.1 Did you try TST.** ? I believe TST.* will only work for TST.XXX and not for TST.XXX.YYY. Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 30, 2004 12:07 AM To: [EMAIL PROTECTED] Subject: Setmqaut on v5.1 Howdy all (again), I am in the process of migrating an old v5.1 server to v5.3 on a new platform. As part of the process I have moved a copy of the queue managers over to the new Win2K machine and they work ok, but I am having security nightmares prior to upgrading the MQ to v5.3 When I try: Setmqaut -m QML_MQM -t q -n TST.* -g MQCLIENTS +put -get +inq +browse I get AMQ7085: Object TST.*, type q not found I have thousands of queues which are named: TST.abc01 TST.abc01.data TST.abc02 TST.abc02.data I have tried variations on -g and -p using groups and principals, I have also tried TST.*.* and every vriant I can think of. The manual (SC34-6068-00) System Administration Guide says you can use wildcards!! (page 308)... But it doesn't work! What am I doing wrong ? Sid Young Instructions for managing your mailing list 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 communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Message Tracking
I think there is a lot of good stuff already in the product to insure that the program knows what happened to its message(syncpoints, report messages, etc). IF the programmers only take time to learn it, understand it, implement it, and act upon it. An MQAdmins job seems to be to prove MQ works and to understanding all the connecting apps. I would bet there would be a lot more cases of missing DB2 inserts if the goal was for JMS to call a DB2 insert which sent the row to another DB2 table on another server that then transformed that into an Oracle insert that then inserted it on a SQL server in East Hoboken. Oh, and it needed its row updated back in LA on the original DB in under 2 seconds with the result of all this. And if MQ was just doing an MQPUT to a local queue and that's it, there would be no problems. Man, who calls and yells at AT&T that the phone system has crashed when the person you are calling is not home to answer the phone? -Original Message- From: James Kingdon [mailto:[EMAIL PROTECTED] Sent: Friday, April 30, 2004 9:31 AM To: [EMAIL PROTECTED] Subject: Re: Message Tracking I'd be interested to hear what the most common scenarios are that lead to developers believing that MQ lost their message, particularly when using the JMS API. As has been mentioned in this thread, this isn't the sort of complaint that you hear raised against ftp or databases, but does seem to occur with reasonable frequency with messaging. This might indicate that our APIs aren't as good, or that the underlying paradigm is more complex, but in either case suggests that we could do more to support developers facing the question "where's my message?". I can think of a few obvious things that crop up on a regular basis: not starting the JMS Connection sending a message under transaction and not committing incorrectly formed message selectors remote client connections performing receives outside of syncpoint using message expiry publishing messages before creating the subscriber sending the message somewhere other than where it was supposed to go another application left running that consumes from the same destination With the added power of the MQI there are plenty of additional problems that can arise, like forgetting to clear messageID and correlationID fields when reusing the MQMD, and we haven't yet got to problems of multi-queue manager routing or adding a transformation engine to the mix. So, let me know what sort of things trip up your developers (or yourselves - I think I've done *all* of the above at sometime or other) and I'll push for features that will hopefully make it easier to support and work with our products. It would be best if you send problems, not suggestions for solutions - I'm not sure what the IP implications would be for the latter, and I wouldn't want good ideas to be delayed from getting into the product because of legal concerns. No promises, no time-scales, but rest assured we're listening. Regards, James. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: IMS Adapter
When the IMS bridge receives a nonzero IMS-OTMA sense code, the IMS bridge converts the sense code from hexadecimal to decimal, adds the value MQFB_IMS_ERROR (300), and places the result in the Feedback field of the reply message. This results in the feedback code having a value in the range MQFB_IMS_FIRST (301) through MQFB_IMS_LAST (399) when an IMS-OTMA error has occurred. You have to subtract MQFB_ERROR from that value (300), which gives you the OTMA sense code. Chapter 4 of the OTMA Guide and reference (available at http://www-3.ibm.com/software/data/ims/shelf/v6pdf2/OTMA_V6.pdf) contains a list of OTMA sense codes and their cause. You should also see a message CSQ2001I in the SYSOUT of your MSTR started task that gives you additional information. Here are some common codes I have seen: 291 = MQFB_DATA_LENGTH_ZERO Data length zero. A segment length was zero in the application data of the message. 292 = MQFB_DATA_LENGTH_NEGATIVE Data length negative. A segment length was negative in the application data of the message. 293 = MQFB_DATA_LENGTH_TOO_BIG Data length too big. A segment length was too big in the application data of the message. 294 = MQFB_BUFFER_OVERFLOW Buffer overflow. The value of one of the length fields would cause the data to overflow the message buffer. 295 = MQFB_LENGTH_OFF_BY_ONE Length in error by one. The value of one of the length fields was one byte too short. 296 = MQFB_IIH_ERROR MQIIH structure not valid or missing. The Format field in MQMD specifies MQFMT_IMS, but the message does not begin with a valid MQIIH structure. 298 = MQFB_NOT_AUTHORIZED_FOR_IMS Userid not authorized for use in IMS. The user ID contained in the message descriptor MQMD, or the password contained in the Authenticator field in the MQIIH structure, failed the validation performed by the IMS bridge. As a result the message was not passed to IMS. 300 = MQFB_IMS_ERROR Unexpected error returned by IMS. An unexpected error was returned by IMS. Consult the MQSeries error log on the system on which the IMS bridge resides for more information about the error. . 301 = MQFB_IMS_FIRST Lowest value for IMS-generated feedback. 325 = VALID TCODE STOPPED Although a valid TCODE was specified, the TCODE in question has been stopped in IMS. 326 = INVALID TCODE The TCODE specified in the IIH header is not a valid TCODE. 399 = MQFB_IMS_LAST Highest value for IMS-generated feedback. -Original Message- From: Dick Killian [mailto:[EMAIL PROTECTED] Sent: Friday, April 30, 2004 9:25 AM To: [EMAIL PROTECTED] Subject: IMS Adapter I have inherited MQSeries Adapter for IMS. I am somewhat familiar with MQ but not IMS. A programmer is getting a feedback code of 335. Does anyone know where to look up these codes? It doesn't seem to be in MQ Messages and Codes? MQSeries v5.2, IMS v7, OS/390 v2.10 _ Regards, Dick Killian Energy East Utility Shared Services Information Technology Mainframe Systems Software (585) 771-6049 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Extended Transactional Client & WLS
Pavel, we have done this with WL 6.1 and JMS. Been in production for about 3 months. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 10:00 PM To: [EMAIL PROTECTED] Subject: 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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ clustering experience
Don't even consider this unless you are 5.3. Clustering is much improved at this level. Check out this doc, which is "MD05: MQSeries - Design considerations for large Clusters": http://www-1.ibm.com/support/docview.wss?rs=203&q1=mA1J&uid=swg24006367&loc=en_US&cs=utf-8&lang=en And this one, which is "MP7A: WebSphere MQ for Windows V5.3 - Performance tuning for large clusters": http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg24006424&loc=en_US&cs=utf-8&lang=en Don't cluster just so you can say you are clustered. You don't need workload balancing, one of the major benifits of clustering. The other benifit is reduce administration. Your design basically says its the enterprise QMs talking only with the distributed QMs. Well the more enterpise QMs you have, assuming each one has to talk to each distributed QM, the more savings you will have as far as defing channels and XMIT queues. And more savings still if the enterprise QMs need to talk to each other as well. And the more queues you have, the less work their will be proportianalty for building all those remote queue defs. I suppose the apps could always MQOPEN the queue/QM, so their would be no need for remote defs... A lot of clustering magic is still undocemented and under the covers. IF something goes wrong, it is a lot easier to try and fix regular old distributed channels than clustering. But, it is getting more stable with every release and there is more documentation as time goes by. Get yourself a copy of the advanced clustering session from last year's conferance, which contains good stuff found nowhere else. Or better yet, go to this year's conferance and attend all the clustering sessions. -Original Message-From: Mike Davidson [mailto:[EMAIL PROTECTED]Sent: Friday, April 30, 2004 7:04 AMTo: [EMAIL PROTECTED]Subject: Re: MQ clustering experienceYour concerns that the "workload balancing" benefits of clustering might not apply to your situation are valid. However, another (rather valuable) benefit to implementing MQ clustering in such an environment as yours with many qmgrs is the reduction in object definitions to maintain. There are, of course, other considerations that need to be accounted for - such as your mention of certain qmgrs not having a need for channels to other qmgrs. That's fine in clustering - if the qmgrs don't need to talk, then MQ won't create the auto-defined senders. But, on the flip-side, if they ever do need to talk MQ will dynamically create them as needed. It sounds like you may even want to set up a couple of clusters - grouping qmgrs together depending on business process, environment, geography, etc. The mention of multiple clusters sometimes makes folks cringe, but it might suit your situation - you'll have to decide for yourself. This is the kind of thread that could go on for a while. I know that there are many more things that could be said about your concerns, and the things I've mentioned are some basic (yet important) considerations, but that's the first thing that came to mind about your scenario.I hope this helps. Mike DavidsonTSYS MQ Tech Support[EMAIL PROTECTED] "[EMAIL PROTECTED]" Sent by: MQSeries List <[EMAIL PROTECTED]> 04/30/2004 12:11 AM Please respond to "[EMAIL PROTECTED]" To: [EMAIL PROTECTED] cc: Subject: MQ clustering experienceHello Everyone, I am working at a shop that is revamping it's use of MQ. To date, my personal experience supporting MQ has not included using clustering. A proposal is under consideration to deploy hundreds of MQ servers as one cluster. This would include a handful of enterprise side QMGRs (including a few on z/OS) with the majority of QMGRs being widely dispersed. There is currently no need for the dispersed QMGRs to connect to each other so channels would exist between the enterprise QMGRs and the individual, dispersed QMGRs. Each dispersed QMGR would essentially be a clone of one another ... meaning something in the MQ object names on each QMGR would be unique but the number, type and attributes of the MQ objects from one QMGR to another would be uniform. There is also no use of client connections currently under consideration. The topology of the QMGRs will leave little, or no, opportunity to employ workload distribution. The enter prise side QMGRs will regularly be used to deliver messages to all of the dispersed QMGRs. While I crack the manuals and review the list's archives to learn more specifics about clustering benefits and pitfalls, I would appreciate hearing from others with experience using clustering, especially larger clusters. If the proposal is adopted, with what am I likely to be confronted? Will the single cluster transmit queue on each enterprise QMGR adequately ser
Re: Removing a dead server from an MQ cluster
As long as MQ1 is a Full Repository, yes.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 29, 2004 10:33 PM
To: [EMAIL PROTECTED]
Subject: Removing a dead server from an MQ cluster
Howdy all,
I have a server (MQ2) that has been disconnected (forceably) from a cluster
and physically removed and will not be replaced. The existing queue manager
(MQ1) on the other server still thinks it is present. Can I issue a reset
cluster command on MQ1 as shown below safely:
Reset cluster('MQCLUSTER') QMNAME('MQ2') ACTION(FORCEREMOVE) QUEUES(YES)
Thanks
Sid
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all copies.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Message Tracking
I'm gonna go with the info in the Glossary, since I have heard the same definitions from: My IBM rep The IBM Tech Conferance 2 Vendors that use these Exits That link you posted is the only place that contradicts that. Go figure. That link is not dated anywhere that I can see, maybe its just old, before the terms were ironed out Anyway, are you gonna market this little exit at Capitalware? Where will you store all the data? Will there be a GUI to correlate it all? :-) This is slowly evolving into a reinventing of Bristol's Transaction Vision. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 5:07 PM To: [EMAIL PROTECTED] Subject: Re: Message Tracking Hi, That is what I thought, but when IBM publicly posts information that differs, you have to wonder which is correct. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>: > Roger, I don't exactly agree with the link. I have always known an API exit > as existing on Distributed platforms, and the API Crossing Exit being the > exact same thing on the mainframe but for CICS only. > > > See the following quote from the MQ Glossary and Bibliography Manual: > > API exit. > A user-written program that monitors or > modifies the function of an MQI call. For each MQI call > issued by an application, the API exit is invoked before > the queue manager starts to process the call and again > after the queue manager has completed processing the > call. The API exit can inspect and modify any of the > parameters on the MQI call. The API exit is not > supported on WebSphere MQ for z/OS. > > > API-crossing exit. > A user written program that is > similar in concept to an API exit. It is supported only > by WebSphere MQ for z/OS and for CICS applications > only. > > -Original Message- > From: Roger Lacroix [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 29, 2004 12:02 PM > To: [EMAIL PROTECTED] > Subject: Re: Message Tracking > > > All, > > I'll correct myself. :)) > > 'Api Crossing Exit' is the 'Api Exit' that I am referring to. Here is a > quick > explanation about it from IBM: > http://www.mqug.org.uk/anonftp/021131%20-%20MQUTIL.pdf > > > Regards, > Roger Lacroix > 416-566-7307 > Capitalware Inc. > http://www.capitalware.biz > > > Quoting Roger Lacroix <[EMAIL PROTECTED]>: > > > Hi, > > > > Am I not sure but I believe 'Api Crossing Exit' is mainframe only. > (Anyone!) > > > > Although, 'Api Crossing Exit' could be the 'Api Exit' that I am referring > to. > > Is it available on distributed platforms and configure at a queue manager > > level > > (and not channel attribute)? > > > > > > Regards, > > Roger Lacroix > > Capitalware Inc. > > http://www.capitalware.biz > > > > > > Quoting [EMAIL PROTECTED]: > > > > > Roger, > > > > > > > > > The api crossing exit which comes with WMQ addresses most of your > concerns. > > > Have you looked at it ? > > > > > > > > > > > > > > > > > > > > > "Bullock, Rebecca > > > (CSC)" To: > > > [EMAIL PROTECTED] > > > <[EMAIL PROTECTED]cc: > > > >Subject: Re: Message > > Tracking > > > Sent by: MQSeries > > > List > > > <[EMAIL PROTECTED] > > > n.AC.AT> > > > > > > > > > 04/29/2004 08:49 > > > AM > > > Please respond to > > > MQSeries List > > > > > > > > > > > > > > > > > > > > > Roger, the only thing I have to say is to agree that you want to include > at > > > least part of the actual message data. That way, if the programmer has > the > > > wrong msgid or correlid or even ends up with duplicates (if, for > example, > > > he > > > doesn't clear these fields before his next put), you stand a chance of > > > finding the actual message based on the data itself. > > > > > > > > > > > > -Original Message- > > > From: Roger Lacroix [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, April 28, 2004 1
Re: Message Tracking
Roger, I don't exactly agree with the link. I have always known an API exit as existing on Distributed platforms, and the API Crossing Exit being the exact same thing on the mainframe but for CICS only. See the following quote from the MQ Glossary and Bibliography Manual: API exit. A user-written program that monitors or modifies the function of an MQI call. For each MQI call issued by an application, the API exit is invoked before the queue manager starts to process the call and again after the queue manager has completed processing the call. The API exit can inspect and modify any of the parameters on the MQI call. The API exit is not supported on WebSphere MQ for z/OS. API-crossing exit. A user written program that is similar in concept to an API exit. It is supported only by WebSphere MQ for z/OS and for CICS applications only. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 12:02 PM To: [EMAIL PROTECTED] Subject: Re: Message Tracking All, I'll correct myself. :)) 'Api Crossing Exit' is the 'Api Exit' that I am referring to. Here is a quick explanation about it from IBM: http://www.mqug.org.uk/anonftp/021131%20-%20MQUTIL.pdf Regards, Roger Lacroix 416-566-7307 Capitalware Inc. http://www.capitalware.biz Quoting Roger Lacroix <[EMAIL PROTECTED]>: > Hi, > > Am I not sure but I believe 'Api Crossing Exit' is mainframe only. (Anyone!) > > Although, 'Api Crossing Exit' could be the 'Api Exit' that I am referring to. > Is it available on distributed platforms and configure at a queue manager > level > (and not channel attribute)? > > > Regards, > Roger Lacroix > Capitalware Inc. > http://www.capitalware.biz > > > Quoting [EMAIL PROTECTED]: > > > Roger, > > > > > > The api crossing exit which comes with WMQ addresses most of your concerns. > > Have you looked at it ? > > > > > > > > > > > > > > "Bullock, Rebecca > > (CSC)" To: > > [EMAIL PROTECTED] > > <[EMAIL PROTECTED]cc: > > >Subject: Re: Message > Tracking > > Sent by: MQSeries > > List > > <[EMAIL PROTECTED] > > n.AC.AT> > > > > > > 04/29/2004 08:49 > > AM > > Please respond to > > MQSeries List > > > > > > > > > > > > > > Roger, the only thing I have to say is to agree that you want to include at > > least part of the actual message data. That way, if the programmer has the > > wrong msgid or correlid or even ends up with duplicates (if, for example, > > he > > doesn't clear these fields before his next put), you stand a chance of > > finding the actual message based on the data itself. > > > > > > > > -Original Message- > > From: Roger Lacroix [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 28, 2004 11:48 PM > > To: [EMAIL PROTECTED] > > Subject: Message Tracking > > > > > > All, > > > > I have tried to talk my current client into buying a message tracking > > product > > but of course they say they don't have the money!?!?! > > > > The problem is that the client has a lot of MQ development going on with a > > lot > > of newbie MQ/Java developers. And of course the newbie developers keep > > telling > > me that MQ lost their messages. This of course is driving me nuts!!! > > > > So I figured that I would create an API Exit to log the following: > > - Queue Name > > - Date / Time > > - MsgID > > - CorrelID > > - GroupID > > > > >From a tracking point of view, I don't think logging the message data is > > important but what other fields of the MQMD should be logged?? > > > > I figure I would use Perl or Java to summarize or correlate the information > > in > > the log file. Of course, the script would cross search between MsgID, > > CorrelID > > & GroupID for matches. > > > > Any comments - thoughts about this. > > > > Regards, > > Roger Lacroix > > > > Instructions for managing your mailing list subscription are provided in > > the Listserv General Users Guide available at http://www.lsoft.com > > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > > > > > ** > > This e-mail and any files transmitted with it may contain privileged or > > confidential information. It is solely for use by the individual for whom > > it is intended, even if addressed incorrectly. If you received this e-mail > > in error, please notify the sender; do not disclose, copy, distribute, or > > take any action in reliance on the contents of this information; and delete > > it from your system. Any other use of this e-mail is prohibited. Thank you > > for your compliance. > > > > Instructions for managing your mailing list subscription are provided in > > the Listserv General Users Guide available at http:/
Re: Using runmqtmc on Solaris
We use the client trigger monitor on Windows and Solaris. Also, a trigger monitor never sends messages. It only does MQGETs from the INIT queue. Well, OK, I suppose if it has to put a trigger message to the DLQ it is doing a PUT. But other than that, a TM never sends messages. -Original Message- From: Ed Rutkowski [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 10:28 AM To: [EMAIL PROTECTED] Subject: Using runmqtmc on Solaris We are running our MQ software on Solaris 8. Yesterday I discovered that several applications are using the runmqtmc (client trigger monitor) executable to send messages from the client to the server. The problem is that according to the WMQ 5.3 System Guide this is only available on AIX. We have no AIX servers. Has anyone else used runmqtmc successfully on Solaris? Are there gotchas I need to look out for? We are upgrading our clients from 5.2 to 5.3 (our servers are already 5.3) and I am especially worried this may fail once we upgrade. Ed Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Adding to Clusters
Your problem is exactly described as the second symptom (pg 110) in the TroubleShooting section of the Cluster manual. Basically, it says fix the channel definition, and wait a retry cycle for it to fix itself. If that doesn't fix it, let us know. There is a manual way to get around this, but it is multistep and probably overkill if the above method will work. -Original Message-From: Gina McCarthy [mailto:[EMAIL PROTECTED]Sent: Thursday, April 29, 2004 10:24 AMTo: 'Potkay, Peter M (PLC, IT)'; [EMAIL PROTECTED]Subject: RE: Adding to Clusters Thank you Peter! On QM3: Is the TO.QM3 channel clustered? The CLUSRCVR (TO.QM3) did not specify the cluster. I added it and restarted the CLUSSDR (TO.QM3) on QM2. Is TO.QM3 defined properly (hostname(port))? Yes, as a matter of fact. They're all started. Is the TO.QM2 channel clustered? Yes Are the queues you defined clustered? Yes. On QM1 or QM2, what happens if you issue DIS CLUSQMGR(*)? Does it show QM3? No. ;-( On QM1, it shows QM1 and QM2 only. On QM2, it shows: dis clusqmgr(*) 1 : dis clusqmgr(*) AMQ8441: Display Cluster Queue Manager details. <- QM2 CLUSQMGR(AIXMQST1) CLUSTER(NATEST) CHANNEL(TO.AIXMQST1) AMQ8441: Display Cluster Queue Manager details. <- QM1 CLUSQMGR(MQ1T) CLUSTER(NATEST) CHANNEL(TO.MQ1T) AMQ8441: Display Cluster Queue Manager details. <-- QM3 CLUSQMGR(SYSTEM.TEMPQMGR.usmlio02.arrow.com(1414)) CLUSTER(NATEST) CHANNEL(TO.OS4MQST1) OK...this is the problem. When I originally created the CLUSRCVR on QM3, I put the wrong port of 1414 when it should have been 1415. How can I delete thisor can I??? Thanks! Gina -----Original Message-----From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]Sent: Thursday, April 29, 2004 9:57 AMTo: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]Subject: RE: Adding to Clusters You seem to have all the needed definitions. (By the way, the CLUSSNDR you manually made from QM2 to QM3 is not needed. MQ Cluster Magic will auto define that one when it needs it, and won't even use the one you made.) On QM3: Is the TO.QM3 channel clustered? Is TO.QM3 defined properly (hostname(port))? Is the TO.QM2 channel clustered? Are the queues you defined clustered? On QM1 or QM2, what happens if you issue DIS CLUSQMGR(*)? Does it show QM3? The refresh command is not available on QM2 or QM1, since they are full repositories. However, issuing it on QM3 is supposed to push out all of QM3's data to the Full Repositories. Is the channel from QM3 to QM2 running? -Original Message-From: Gina McCarthy [mailto:[EMAIL PROTECTED]Sent: Thursday, April 29, 2004 9:21 AMTo: [EMAIL PROTECTED]Subject: Adding to Clusters I currently have 2 queue managers (QM1 and QM2), which are both full repositories in cluster NATEST. I need to add another queue manager (QM3). I've attached it to QM2: On QM2, I've defined a CLUSSDR (TO.QM3) and a CLUSRCVR (TO.QM2). I then added queues on QM3 to the cluster. My problemI cannot see that these queues exist on QM2. I've refreshed the cluster on QM2 (with repos) and on QM3. What am I missing? Regards, Gina McCarthy Sr Systems Programmer MQSeries/CICS Arrow Electronics, Inc. 50 Marcus Drive Melville, NY 11747 (631) 847-5440 [EMAIL PROTECTED] This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: Adding to Clusters
You seem to have all the needed definitions. (By the way, the CLUSSNDR you manually made from QM2 to QM3 is not needed. MQ Cluster Magic will auto define that one when it needs it, and won't even use the one you made.) On QM3: Is the TO.QM3 channel clustered? Is TO.QM3 defined properly (hostname(port))? Is the TO.QM2 channel clustered? Are the queues you defined clustered? On QM1 or QM2, what happens if you issue DIS CLUSQMGR(*)? Does it show QM3? The refresh command is not available on QM2 or QM1, since they are full repositories. However, issuing it on QM3 is supposed to push out all of QM3's data to the Full Repositories. Is the channel from QM3 to QM2 running? -Original Message-From: Gina McCarthy [mailto:[EMAIL PROTECTED]Sent: Thursday, April 29, 2004 9:21 AMTo: [EMAIL PROTECTED]Subject: Adding to Clusters I currently have 2 queue managers (QM1 and QM2), which are both full repositories in cluster NATEST. I need to add another queue manager (QM3). I've attached it to QM2: On QM2, I've defined a CLUSSDR (TO.QM3) and a CLUSRCVR (TO.QM2). I then added queues on QM3 to the cluster. My problemI cannot see that these queues exist on QM2. I've refreshed the cluster on QM2 (with repos) and on QM3. What am I missing? Regards, Gina McCarthy Sr Systems Programmer MQSeries/CICS Arrow Electronics, Inc. 50 Marcus Drive Melville, NY 11747 (631) 847-5440 [EMAIL PROTECTED] This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: TCP error
Maybe your apps: MQCONN MQOPEN MQPUT or MQGET end (without a MQCLOSE of the queue or MQDISC from the QM). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 7:23 AM To: [EMAIL PROTECTED] Subject: Re: TCP error right...so why are my 1000 clients (MQ v5.1 NT4/win2k/XP) doing it every 3 seconds Sid -Original Message- From: Emile Kearns [mailto:[EMAIL PROTECTED] Sent: Wednesday, 28 April 2004 7:41 PM To: [EMAIL PROTECTED] Subject: Re: TCP error 10054 WSAECONNRESET -- Connection reset by peer. This occurs when an established connection is shut down for some reason by the remote computer From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 28 April 2004 10:30 AM To: [EMAIL PROTECTED] Subject: TCP error Howdy all, I have an NT4 server running MQ v5.1 that constantly generates recv call errors in the event log error number 10054. Errors are occuring every 3 seconds on average. Does anyone know how to fix this with the version I currently have ? Sid Young Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, this message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Setting up MO71
Title: Migrating MQSeries to another server That is the hostname of the Unix Server. If the QM is listening on a port other than 1414, append it on to the end, like so: UNIXSERVERNAME(1415) -Original Message-From: Schaeffer Dave [mailto:[EMAIL PROTECTED]Sent: Friday, April 23, 2004 3:17 PMTo: [EMAIL PROTECTED]Subject: Setting up MO71 I'm in the process of trying to setup MO71. The MQ server is on a Unix box so I'm using a client connection, the application wants me to enter a "Connection Name", what is it looking for? I'm feeling very dense with this setup. Dave Schaeffer This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: WebSphere MQ clients
Its probably buried in the License agreement none of us read and all of us just click OK when it comes time to download/install. -Original Message- From: Usha Suryadevara [mailto:[EMAIL PROTECTED] Sent: Thursday, April 22, 2004 2:22 PM To: [EMAIL PROTECTED] Subject: Re: WebSphere MQ clients Thanks Hossam, that was my assumption too, but at this point my company needs a proof, a written statement or something. Is anybody aware of something like that ? Thanks Usha At 02:03 PM 4/22/2004 -0400, you wrote: >I remember back during my IBM MQ training, the IBM instructor said, you >can use as much clients as you want. If I'm wrong , Then I'm in big trouble :-) >regards, >Hossam > >-Original Message- >From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Usha >Suryadevara >Sent: Thursday, April 22, 2004 1:44 PM >To: [EMAIL PROTECTED] >Subject: WebSphere MQ clients > > >Hello all, > >Do we need a special license for WebSphere MQ Clients ? > >Isn't WebSphere MQ client by itself available for free download ? > >In other words is it legal for me to buy one license for WebSphere and then >bundle the MQ client installation in my "product client application >installation". I do not think so, but i couldn't find any information >online, maybe i didn't search enough. It would be great if somebody can >help me through this question. > >Thanks in advance. >Usha > >Instructions for managing your mailing list 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 communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: amqiclen question
Where do you guys put amqiclen or mqipcrm.sh? I was thinking of putting it at the head of my startup scripts as well as the end of the shutdown scripts. If the server / QM crashes and the shutdown script never runs, there is a chance that there will be leftover shared memory and segments that may interfere with the QM coming back up. Or is this overkill? -Original Message- From: Rick Tsujimoto [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 10:53 AM To: [EMAIL PROTECTED] Subject: Re: amqiclen question Bill, It's been around for awhile, but never seemed to made to the admin manual: Here is item RTA000170159 concerning your inquiry: Source..: PDDBR PDDBR Last updated: 20010724 Abstract: AMQICLEN HANG HUNG CLEANUP SHMEM SEMAPHORES CHKMQIPC USERS: ALL USERS with MQSeries HPUX HP PROBLEM SUMMARY: Cust wants to discuss methods for cleaning up shared memory and semaphores particularly in their shutdown scripts where they have to bring down a queue manager manually by killing off processes. In 5.1 they have been using a script developed by Hursley called chkmqipc because they could use it to clean up ipc resources from one queue manager on a machine where another queue manager was still running (without having to end that other queue manager). In 5.2 we had suggested they used the utility supplied with the product called amqiclen. Cust is having problems trying to use it. SOLUTION: If there is no documentation, then the utility is probably in the 'unsupported' category, i.e. it is intended for use by MQ support and has been issued so it is already installed should support require it for any purpose. It is not really intended for customer use. There are other 5.2 utilities like this, for authorizations, cluster and channel debugging. It is not necessary to clear IPC resources if MQ is ended normally, nor at 5.2 should it be necessary if MQ is ended abnormally or abruptly. CHKMQIPC should indeed continue to work at 5.2. However either 5.2 or PB may be cleaning up IPC stuff so chkmqipc has no work to do. The command line for amqiclen is: amqiclen -v -c -m qmgr_name < /var/mqm/mqs.ini . -v => verbose -c => check only (does not ipcrm anything) -m => only to clean up named queue manager . returns: 0 => OK 2 => One or more connected process(es) >2 => unexpected error Note: if the input redirection is omitted, the < /var/mqm/mqs.ini, then amqiclen will 'hang' waiting for input. Once cust used the correct syntax for the amqiclen command it did work as desired. Bill Anderson <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ITA.AERO>cc: Sent by: Subject: Re: amqiclen question MQSeries List <[EMAIL PROTECTED] en.AC.AT> 04/15/2004 09:16 AM Please respond to MQSeries List We are an AIX shop, but I use mqipcrm, which is a fairly simple "K shell" script. I run it every time I bring a qmgr down with out bouncing the machine. I believe It was written by an IBM support person, and the are the ones that gave it to me a year ago or so. It takes no flags at all, and seems to work fine. I have never heard of amqiclen, perhaps I should consider taking a look at it? Cheers Rick Tsujimoto <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COM>cc: Sent by: MQSeries List Subject: amqiclen question <[EMAIL PROTECTED]> 04/14/2004 02:59 PM Please respond to MQSeries List I've used amqiclen for HP-UX, but on AIX there seems to be a different set of switches. What switches should be set to routinely get rid of any shared memory segments and semaphores when MQ is brought down? Instructions for managing your mailing list 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 communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information.
Re: problems with mq 5.2 on OS/390
Don't know about your problem, but we have been at 5.3 for over a year with zero problems. How are you going to "see" more 5.3 on z/OS? -Original Message-From: mqteam [mailto:[EMAIL PROTECTED]Sent: Wednesday, April 21, 2004 10:24 AMTo: [EMAIL PROTECTED]Subject: problems with mq 5.2 on OS/390 Hello All, I am upgrading MQSeries on OS/390 from version 2.1 to 5.2 (I rather see more 5.3 on Z/OS before I upgrade to it) We are running MQSeries 5.2 with the latest tapes sent to us by IBM. We have OS/390 2.10 We are not migrating; we created new BSDS, log and pagesets. When trying to start the queue manager we get reason 00E80100. To save time I must state, the queue manager finds the parameter file just fine, it reads the BSDS file at least to state timestamp and RBA ranges Then comes the dump... Cheers Didi This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: FW: Channel Connection name resolution
On Windows, you can open the QM under MQServices thru the GUI, and right click the Channel Initiator to stop it. -Original Message- From: Mabrito, Greg [mailto:[EMAIL PROTECTED] Sent: Monday, April 19, 2004 5:45 PM To: [EMAIL PROTECTED] Subject: Re: FW: Channel Connection name resolution If you end up needing to stop the channel initiator in the future on a distributed platform, get inhibit the SYSTEM.CHANNEL.INITQ (most commonly). Intercommunications guide: However, if you need to stop a channel initiator but not the queue manager, you should inhibit the queue that the initiator queue is reading from. To do this, you disable the GET attribute of the initiation queue. To restart the channel initiator, simply use the runmqchi command. The consequences of stopping a channel initiator are: If you stop the only channel initiator running, no channels that you have attempted to start will be retried. If you have more than one channel initiator running, channels that have a transmission queue configured with this initiation queue are not automatically started. However, those channels configured for connection retries will continue to be retried. -Greg -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Adiraju, Rao Sent: Monday, April 19, 2004 3:59 PM To: [EMAIL PROTECTED] Subject: Re: FW: Channel Connection name resolution Paul - no worries - "horror" is used in more of a colloquial sense. I am trying to understand the rational behind it. According to the logic I have learnt, anything that started should be able to stopped. But I guess IBM must have there own logic for giving it on only one platform and don't even mention, how to close it, on other platforms. Obviously these two logics don't match. Cheers Rao Ps: anyway my original problem was due to TTL interval and once I have reduced it, MQ is automatically detecting the new IP address. So I don't need to bother about Stopping and Starting the initiator. -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: 19 April 2004 10:01 PM To: [EMAIL PROTECTED] Subject: Re: FW: Channel Connection name resolution >Hi Jim >To my horror I can't find a command to stop/terminate/end the channel >initiator (may be it's due to my Monday syndrome or there is no such >facility) for non-z/OS platforms. I can kill the process, if that is >what is >called recycling. There one MQSC command called STOP CHINIT but that >say valid only for z/OS platform. Intercommunication guide talks about stopping >the channel initiator but doesn't tell how >Am I missing something here. >Cheers >Rao Rao, I'm a little surprised that having no stop channel initiator command would cause you horror but I'm afraid there isn't one. As with many MQ applications you can cause the application to end just by inhibiting the queue for GET. In this case, you probably just need to inhibit SYSTEM.CHANNEL.INITQ. 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 communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Queue Alias usage
But if the user is doing MQGETs, and gets a 2033, because the bogus queue is empty, they may not complain, because a 2033 may not be a show stopper. Meanwhile the real base queue might have messages. I would GET and PUT inhibit the alias queue. Then turn on the INHIBIT events for the QM, and watch the event queue. If something shows up, you know you are effecting someone. Not exactly what you wanted, but maybe easier than just deleting the queue and then having to recreate it. Either way that app gets an error (2085 or 2016), but it saves you a little work when they do complain, and you can fix it before they complain if you get the event message. -Original Message- From: Thomas, Don [mailto:[EMAIL PROTECTED] Sent: Friday, April 16, 2004 9:43 AM To: [EMAIL PROTECTED] Subject: Re: Queue Alias usage A crude yet simple approach would be to point the aliases to another local queue and wait to see if anyone complains. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Adiraju, Rao Sent: Thursday, April 15, 2004 10:18 PM To: [EMAIL PROTECTED] Subject: Re: Queue Alias usage In all three platforms - Windows, Solaris and Os/390. Thanks for OS/390 suggestions. Cheers Rao -Original Message- From: Christopher Warneke [mailto:[EMAIL PROTECTED] Sent: 16 April 2004 2:16 PM To: [EMAIL PROTECTED] Subject: Re: Queue Alias usage What platform are you trying to determine this on? The m/f logs will tell you what was accessed and when, as will racf if you audit security. Maybe the smf type126 records will have info that you can use. look at support pack mo12 to review the logs. Chris --- "Adiraju, Rao" <[EMAIL PROTECTED]> wrote: > Fellas > > Is there any way to see whether a Queue Alias is being used by the > applications and when it has been LAST accessed. I am not talking > about "Qstatus type(handle)". > > I am embarking on cleaning up our MQ resources and there are few > dangling Queue Aliases which I am planning to delete. > > I need to absolutely make sure no one is using these. Other than > asking each and every application, are there any commands I can run to > find out whether they are used since the creation and when it was > accessed last. > > 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. > __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: File to Queue Utility
http://www.capitalware.biz/ -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 3:48 PM To: [EMAIL PROTECTED] Subject: File to Queue Utility I looked on MQSeries.net but could not find a simular utility. I thought there was one at www.capitalware.net but that site name brings up another site. Does someone knoe the capitalware sith spelling AND are there any other file-to-queue utilities out there. I need one that will let me play with the MQMD settings on the outgoing message. The incoming file will contain non-text data so the utility has to have to handle this. bobbee _ 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 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
big-endian and little-endian
Kinda interesting, especially that last paragraph!
-Original Message-
From: Whatis.com [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 10:46 AM
To: Whatis.com
Subject: Word-of-the-Day: big-endian and little-endian
THE WHATIS.COM WORD-OF-THE-DAY
April 15, 2004
big-endian and little-endian
_
SPONSORED BY: Info Quest - Last chance to win!
Our daily Info Quest feature ends today -- this is your last chance
to win a Microsoft wireless keyboard and mouse. Good luck!
http://whatis.techtarget.com/content/0,290959,sid9_gci954359,00.html?track=N
L-34&ad=480640
__
TODAY'S WORD: big-endian and little-endian
See our complete definition with hyperlinks at
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci211659,00.html
?track=NL-34&ad=480640
Big-endian and little-endian are terms that describe the order in
which a sequence of bytes are stored in computer memory. Big-endian
is an order in which the "big end" (most significant value in the
sequence) is stored first (at the lowest storage address).
Little-endian is an order in which the "little end" (least
significant value in the sequence) is stored first. For example, in a
big-endian computer, the two bytes required for the hexadecimal
number 4F52 would be stored as 4F52 in storage (if 4F is stored at
storage address 1000, for example, 52 will be at address 1001). In a
little-endian system, it would be stored as 524F (52 at address 1000,
4F at 1001).
IBM's 370 mainframes, most RISC-based computers, and Motorola
microprocessors use the big-endian approach. TCP/IP also uses the
big-endian approach (and thus big-endian is sometimes called network
order). For people who use languages that read left-to-right, this
seems like the natural way to think of a storing a string of
characters or numbers - in the same order you expect to see it
presented to you. Many of us would thus think of big-endian as
storing something in forward fashion, just as we read.
On the other hand, Intel processors (CPUs) and DEC Alphas and at
least some programs that run on them are little-endian. An argument
for little-endian order is that as you increase a numeric value, you
may need to add digits to the left (a higher non-exponential number
has more digits). Thus, an addition of two numbers often requires
moving all the digits of a big-endian ordered number in storage,
moving everything to the right. In a number stored in little-endian
fashion, the least significant bytes can stay where they are and new
digits can be added to the right at a higher address. This means that
some computer operations may be simpler and faster to perform.
Language compilers such as that of Java or FORTRAN have to know which
way the object code they develop is going to be stored. Converters
can be used to change one kind of endian to the other when necessary.
Note that within both big-endian and little-endian byte orders, the
bits within each byte are big-endian. That is, there is no attempt to
be big- or little-endian about the entire bit stream represented by a
given number of stored bytes. For example, whether hexadecimal 4F is
put in storage first or last with other bytes in a given storage
address range, the bit order within the byte will be:
0100
It is possible to be big-endian or little-endian about the bit order,
but CPUs and programs are almost always designed for a big-endian bit
order. In data transmission, however, it is possible to have either
bit order.
Eric Raymond observes that Internet domain name addresses and e-mail
addresses are little-endian. For example, a big-endian version of our
domain name address would be:
com.whatis.www
Big-endian and little-endian derive from Jonathan Swift's Gulliver's
Travels in which the Big Endians were a political faction that broke
their eggs at the large end ("the primitive way") and rebelled
against the Lilliputian King who required his subjects (the Little
Endians) to break their eggs at the small end.
__
RELATED TERMS:
byte
http://whatis.techtarget.com/definition/0,,sid9_gci211721,00.html?track=NL-3
4&ad=480640
hexadecimal
http://whatis.techtarget.com/definition/0,,sid9_gci212247,00.html?track=NL-3
4&ad=480640
RISC
http://search400.techtarget.com/sDefinition/0,,sid3_gci214266,00.html?track=
NL-34&ad=480640
TCP/IP
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci214173,00.html
?track=NL-34&ad=480640
processor
http://whatis.techtarget.com/definition/0,,sid9_gci212833,00.html?track=NL-3
4&ad=480640
compiler
http://searchwin2000.techtarget.com/sDefinition/0,,sid1_gci211824,00.html?tr
ack=NL-34&ad=480640
__
SELECTED LINKS:
James Curran has written a paper, "Little Endian vs. Big Endian."
http://www.noveltheory.com/techpapers/endian.asp
Lee Jaffe's award-winning site on Jonathan Swift includes a
dictionary of Swiftian terms. Here's the entry for
"Big-Endian/Little-Endian" .
http://www.jaffebros.com/lee/gulliver/dict/b.html#big
MACV Windows Client: Is it CSD6 or CSD5?
Someone posted a similar question a little while ago with no answer. http://www-1.ibm.com/support/docview.wss?uid=swg24006105&rs=260 This webpage says: DETAILS Category: 3 Released: 07Aug02 Last Updated: 08April04 Current Version: 5.3.0.6 NEW IN THIS RELEASE The following changes have been made in this release (5.3.0.6): » This includes WebSphere MQ V5.3 fixpack CSD06 (PTF U200202) But the memo.ptf file says 5.3 CSD05. Is it 6 or 5? 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
Re: Windows 2003 and WebSphere MQ v5.3 Problem
http://www.mqseries.net/phpBB2/viewtopic.php?t=14129 CSD06 for Windows needs a patch. -Original Message- From: Jeff A Tressler [mailto:[EMAIL PROTECTED] Sent: Friday, April 09, 2004 9:49 AM To: [EMAIL PROTECTED] Subject: Windows 2003 and WebSphere MQ v5.3 Problem Hi everybody As the most knowledgeable person at our company concerning MQSeries, I get asked about MQ problems even when it concerns the remote systems we communicate with via MQSeries. I am the expert so why don't I know what is wrong with the remote system. blah blah blah Anyway, we can load WebSphere MQ v5.3 on Windows 2003 and it works fine. The installation on the remote systems, under control of another company, did not go as well. They cannot create queue managers from the GUI, MQ Explorer. They cannot get the command server started via the GUI. Once the queue manager was created via the command line, they could activate a listener via the GUI but no channels could start and would return a queue manager unavailable error. Even if we start the command server via the command line, the GUI still does not work. It seems if we do anything to the queue manager using MQ Explorer it hoses the queue manager. Dozens of FDC files were created each day they attempted to do anything via the GUI. Internal MQSeries errors throughout the error logs when they do anything via the GUI. If they do everything with the command line everything seems to work. I worry that the above indicates some fundamental problem that only is being masked by doing things via the command line. I expect at some point the fundamental problem to reassert itself even though we are avoiding the GUI. The only difference I can tell is their system is using CSD06 and our system is using CSC04. Has anyone heard about possible problems with CSD06. I have asked them to call the problem into IBM but suspect they will not be doing so anytime soon since things seem to be working. Thanks for all the help. Jeff Tressler Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: QPasa! - client connections
No the QPASA agent runs locally to the QM, and communicates with the DBs without using MQ. But it does put to the command server at the Queue Managers where it is running. -Original Message- From: Pat O'Dowd [mailto:[EMAIL PROTECTED] Sent: Thursday, April 08, 2004 7:46 AM To: [EMAIL PROTECTED] Subject: QPasa! - client connections Before acting on this e-mail or opening any attachment, you are advised to read the disclaimer at the end of this mail. Hi, Does QPasa! use client connections to do any of its processing? Does it use the command server? (I am looking to eliminate/prevent client connections on a queue manager.) Thanks in advance, Pat ** This e-mail is intended solely for the addressee and is strictly confidential. If you are not the addressee, please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead please e-mail it back to the sender and delete the message from your computer. E-mail transmission cannot be guaranteed to be secure or error free and The Co-operative Bank accepts no liability for changes made to this e-mail (and any attachments) after it was sent or for viruses arising as a result of this e-mail transmission. Any unauthorised reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message is strictly prohibited. The Co-operative Bank reserves the right to intercept any e - mails or other communication for permitted purposes in accordance with the current legislation which you send to, or receive from, any of the employees or agents of the Bank via Bank telecommunication systems. By so corresponding you also give your consent to the Bank monitoring and recording of any correspondence using these systems. The Co-operative Bank p.l.c. is registered in England and Wales, number 990937. The registered office is at PO Box 101, 1, Balloon Street, Manchester, M60 4EP. ** Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Clearing Expiry Messages
Jeff wrote: "If the Correl Id does not match, MQ DOES NOT do a Expiry check." Actually, it does, and the Expired message will go away. But keep in mind the thought of Indexed queues on the MF, which will prevent every message being searched from top to bottom when doing an MQGET, even for a specific ID. -Original Message- From: Jeff A Tressler [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 4:59 PM To: [EMAIL PROTECTED] Subject: Re: Clearing Expiry Messages >Set an Expiry just above your Wait Interval >is valid, but keep in mind that your queues >will be cleared almost immediately of any >orphaned messages as subsequent gets execute. > This is what I understand in general, here is the specifics of my issue and how I understand the issue. Our application reads by Correl Id. I assume the read checks each message sequentially in the queue to see if there is a matching Correl Id. If the Correl Id does not match, MQ DOES NOT do a Expiry check. This is my assumption, I assume that it only does an expiry check when it actually reads the message (GET or BROWSE). If the Correl Id does not match the id supplied by the application then the message does not get deleted. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Clearing Expiry Messages
Set an Expiry just above your Wait Interval is valid, but keep in mind that your queues will be cleared almost immediately of any orphaned messages as subsequent gets execute. This may be what you want. Personally, I prefer to set the Expiry a bit longer. This way when I look at a queue, I can see the orphans there and maybe determine a pattern. Usually 3 days is what I set. If you see 20 orphans a day, and every day 20 of them occur between noon and 1, you got something to go on. If you set Expiry to a really low value, your queues would be empty always and you would not have this hint. True, if the application is written such that it reports 2033s, you have that as your record, but many times they don't. They just issue the inquiry again. That's why I like the 3 day Expiry. If you are worried about the queue getting to deep with orphans after three days, you probably got some other major problems if your apps are generating that many orphans. Since the queue is searched top to bottom, old Expired orphan messages will be "touched" as apps do an MQGET, even if it is for a specific CorrelID or Message ID. The app has to touch them to see if the ID matches, at which point they will be discarded if they are Expired. No worries here, no need to set up a separate process. Your regular real app will keep the queue flushed. -Original Message- From: Jeff A Tressler [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 3:17 PM To: [EMAIL PROTECTED] Subject: Clearing Expiry Messages Our developers ran across some documentation on expiration and have began to implement their design to use this feature. The are sending a questions to a remote queue manager and expect a response in a timely manner. If they do not receive the response the application continues on. Since they are reading the response based on Correl Id, if the application does not get a response in a timely manner no one will every read that message. Thus they want the message to expire. 1) What is a good expiration to have on the message? - Double the expected response time, if the expected response is 15 seconds, place an expiration time of 30 seconds. 60 second response time is 120 second expiration. - Expected Response time + X. If the expected response time is 15 seconds, add 10 seconds for a 25 second expiry. If the expected response is 60 seconds, set an expiration of 70 seconds. 2) I know the message is not really deleted when the expiration time is reached but when something touches the message the expiration is checked and if the message has expired it is removed from the queue. Since the application reads based on Correl Id, it is most certain that no application will touch the message once it reaches it expiration time. Do I do something as simple as schedule amqsbcg to run against the queue and pipe the output to /dev/null? This assumes all messages are less than 32K. Basically I believe I need to have a process that browses the queue periodically to clean up all the expired messages. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Question On MQMD
Sounds like you have some application data to pass around. Application data belongs in the message buffer. There is no other field in the MQMD for this, other than the 32 bytes in the ApplicationIDData field (which by the way can't bet set by JMS apps). -Original Message- From: Mittal, Gaurav [mailto:[EMAIL PROTECTED] Sent: Friday, April 02, 2004 2:18 PM To: [EMAIL PROTECTED] Subject: Question On MQMD According to MQ documents, 'Application Identity Data' field can be used by apps to set information, if required. By default this field allows only 32 characters, is there a way to increase the size of this field?? Or is there any other header property which can be used to set information upto 100 characters? We are using 5.3csd5 queue manager version and our apps are using mqi api's for java. Any help is appreciated. Thanks Gaurav Mittal ___ EAI Consultant Wipro Technologies (612)-291-4551 (W) Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: WebSphere MQSeries 5.3 for Windows
uh-huh, but read the read me http://www-306.ibm.com/software/integration/mqfamily/platforms/supported/wsm q_for_winnt2000_5_3.html -Original Message- From: Jamie Tracey [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 4:19 PM To: [EMAIL PROTECTED] Subject: WebSphere MQSeries 5.3 for Windows Can someone tell me if this version will run on a Windows 2003 platform please? regards Jamie. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: 2 sender channels, 1 rcvr channel
And then you are forced to run all your instances with the same security settings and other settings like DISINT and what not. If thats what you want, cool. But if you need different levels from different senders, you will be stuck. -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 11:23 AM To: [EMAIL PROTECTED] Subject: Re: 2 sender channels, 1 rcvr channel You'll get multiple instances of the receiver channel and both will run simultaneously. -- T.Rob -Original Message- From: Web Sphere [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 8:36 AM To: [EMAIL PROTECTED] Subject: 2 sender channels, 1 rcvr channel Hi everyone, I'm pretty sure the below will not work but would like to confirm if anyone's tried this ? 3 Qmgrs : QMA, QMB and QMC QMA communicates with QMC and QMB communicates with QMC Only one receiver channel exists on QMC. Corresponding sender channels exist on QMA and QMB Awaiting your replies Thanks WS ___ WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards www.yahoo.co.uk/internetcafes Instructions for managing your mailing list 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
Re: MQ Bible??
There is no one book, just all the manuals collectively. If I had to pick one to give to someone that knew the basics of MQ, but needed to know how it all worked together, then I would choose the Intercommunication Manual. If you have clusters, you would supplement it with the Cluster Manual as well. But you really need to also read the MQSC book, and the two Application Programming Manuals, as well as the System Admin Guide. -Original Message- From: Mark D. Hansen [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 9:09 AM To: [EMAIL PROTECTED] Subject: MQ Bible?? Is there an "MQ Bible" that I can read to get grounded in all the basics of MQ, especially listeners, channels, connections, clusters, etc. ??? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Managing remote queue managers with RUNMQSC
Title: Managing remote queue managers with RUNMQSC Use the MO71 support pac. It allows you to open up a runmqsc window into any QM from your desktop. Very Cool. -Original Message-From: Antony Boggis [mailto:[EMAIL PROTECTED]Sent: Friday, March 26, 2004 3:00 PMTo: [EMAIL PROTECTED]Subject: Managing remote queue managers with RUNMQSC I know it's possible to manage queue managers remotely using the "runmqsc" command processor. However, this (according to the docs) requires that transmission queues and queue manager aliases to the remote qmgrs be defined. What I can't find any mention of in the docs is whether this approach to remote management can be used to manage queue managers that belong to a cluster. Has anyone tried managing cluster queue managers from a single cluster member? Is it possible? Regards, tonyB. This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: endmqlsr after endmqm
Just STOP the channels. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Friday, March 26, 2004 1:52 PM To: [EMAIL PROTECTED] Subject: Re: endmqlsr after endmqm Just gave it some thought.. One way to achieve that (meaning -- the maintenance mode, without bringing down listener) must be to prohibit anyone to connect to QM, with setmqaut.. Another should be to set MCAUSER in all channels to someone who cannot connect (like nobody). Also, is it so bad just to kill listener process? Pavel "Bullock, Rebecca (CSC)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: >Subject: Re: endmqlsr after endmqm Sent by: MQSeries List <[EMAIL PROTECTED] n.AC.AT> 03/26/2004 12:53 PM Please respond to MQSeries List Hi, Ian. No, I don't have the answer, but I wanted to interject another reason one might want to end the listener but not the queue manager. In some circumstances, one might wish to perform some maintenance-type work on the queue manager but not have users connecting, only allowing access through applications/programs local to the MQ server (such as runmqsc). While you can ask that users not connect (ha!), the chances are that they still will. Being able to end the listener would preclude that. I've sometimes wondered about the requirement to end the qmgr, too.. -Original Message- From: Chan, Ian M [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 10:26 PM To: [EMAIL PROTECTED] Subject: endmqlsr after endmqm Hi all, This is not a problem question. However, I am really curious to know why. Before MQ v5.3, I use UNIX listener rather than the MQ listener. Now with the upgrade to v5.3, I started to use MQ listener. Logically thinking, I start the qmgr and then the mq listener and end the listener before ending the qmgr. However, the endmqlsr command cannot be issued while qmgr is active (you will get AMQ9596 error). I have to endmqm first and then endmqlsr. On the Windows platform, I got the same AMQ9596 error if I issue endmqlsr from the Command Prompt while the qmgr is active . However I can end listener from the MQ services while the qmgr is active. Anyone know why endmqlsr cannot be issued while qmgr is active ? To me it is logical to stop listener first and then the qmgr. Besides, what is the difference between using endmqlsr from command prompt and the stop listener from MQ services in the Windows platform? Regards, Ian ** 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. -- 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
Re: Channel conversion
Convert on channel is a leftover from the days one it was quite common for a QM that does support conversion to be sending to a QM that did not. In that case the receiving app could not convert, and the message had to arrive already converted. If both QMs support conversion, force the apps to issue the MQGET with Convert, and don't even let them know that the channel can do it. -Original Message- From: Glen Larson [mailto:[EMAIL PROTECTED] Sent: Friday, March 26, 2004 10:59 AM To: [EMAIL PROTECTED] Subject: Re: Channel conversion Kulbir, We use MSG conversion in the applications only.(MQGET w/Convert option specified) 1) If you use channel conversion and you cross multiple channels you open yourself up for multiple conversions of a MSG, if it traverses multiple qmgrs with multiple CCSIDs The sender does not know where the MSG will end, while the receiver, knows where it originated. 2.) and the biggest reason, if you convert on the channel. the conversion must be done before the MSG can be transmitted, single threading MSG conversion & thus slowing down the transmission of msgs. if you do it at get, then the conversion only impacts the current application. Since, multiple applications can be running concurrently, you are multi-threading the MSG conversion. 3) if the application mixes string and non-string data in their messages, then the MCA needs to be made aware of the differences Vs just the receiving application. If the format changes, this can cause problems doing MSG conversion, further impacting the transmission of data. 4) if for some reason in the future different applications on the platforms need to use different code pages. (say maybe one with and one without the Euro sign) you now start to add more complexity to the channel conversion. rule of thumb, as mentioned in the manual, do conversion when you get, unless for some reason you can not. Glen Larson Zurich North America "Kulbir S. Thind" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 03/26/2004 09:25:28 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Channel conversion All, Hopefully this should be a pretty straight forward query. We are going to have various applications connected to our messaging broker. The Messaging Broker will be based on Sun Solaris and have WMQ v5.3 CSD6 installed. The applications will be hosted on various operating systems ranging including OS/400, OpenVMS, Z/OS, Windows, HP-UX, AIX and will host various versions (i.e. 2.2 on OpenVMS and 5.0 on other platforms). We want to use channel conversion and want to specify channel conversion on the sending channel from these machines to the messaging broker, is there a problem with this? I wouldn't have thought that this would be a problem, however we have seen the following in the Help for MQ Explorer: x Convert message (CONVERT) Application message data is usually converted by the receiving application. However, if the remote queue manager is on a platform that does not support data conversion, use this channel attribute to specify that the message should be converted into the format required by the receiving system before transmission. This attribute applies only to sender, cluster-sender, server, and cluster-receiver channels and does not apply to WebSphere MQ for z/OS with CICS or MQSeries for Windows. The possible values are 'yes' and 'no'. If you specify 'yes', the application data in the message is converted before sending if you have specified one of the appropriate built-in format names (see "Application data conversion" in the WebSphere MQ Application Programming Guide). If you specify 'no', the application data in the message is not converted before sending. x Would anyone like to comment on restrictions of using channel conversion on sender and server channels? Thanks in advance, Kulbir. *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. 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 communication, including attachments, is for t
Re: Formatting production logs [Deutsche Boerse Systems:Virus che cked]
z/OS only though for Configuration Events. I hope the next version of MQ gives us this for Distributed. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Sent: Friday, March 26, 2004 9:36 AMTo: [EMAIL PROTECTED]Subject: Re: Formatting production logs [Deutsche Boerse Systems:Virus checked] The configuration event may help,... ?!? SYSTEM.ADMIN.CONFIG.EVENT Regards, Stefan Ruzi R <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 26.03.2004 13:46 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject: Re: Formatting production logs [Deutsche Boerse Systems:Virus checked] .in this case, what SYSTEM.ADMIN.QMGR.EVENT will recordis the incident of an MQGET call from a queue that isGET-Inhibited. It will not record who inhibited it.So, I don't think it is going to be much of a help toRao.Regards,Ruzi--- "Potkay, Peter M (PLC, IT)"<[EMAIL PROTECTED]> wrote:> Turn on Inhibit Events at the Queue Manager level.> Turn off temporarily the other Queue Manager Events.> Make the SYSTEM.ADMIN.QMGR.EVENT default persistence> equal to Persistent.>>>> Now monitor your SYSTEM.ADMIN.QMGR.EVENT queue for a> depth of greater than> 0.>> The next time someone Get Inhibits that queue, you> will know about it and> who did it, without messing with the logs. It will> record their treachory> without alerting them that the Event Queue was> updated, so you can blindside> them the next day with evidence in hand!>>>>> -Original Message-> From: Adiraju, Rao [mailto:[EMAIL PROTECTED]> Sent: Thursday, March 25, 2004 5:49 PM> To: [EMAIL PROTECTED]> Subject: Formatting production logs>>>> Fellows>> I have two areas, where I appreciate some help:>> 1) Formatting the logs ->> In one of our production queue managers,> something fishy is going on and> I need to format the log to see who is exactly doing> the changes. I know> roughly what time the change is done and hence I can> nail down my log file> number(s) that are active around that time. The> trouble I am having is with> the "dmpmqlog" utility. I can't run it unless the> Queue manager is down> which I can't shutdown that easily.>> Is there any other utility, where I can format a> given log file Say, I> want to see the formatted report of S0003980.LOG>> 2) The problem I am trying to figure it out is as> follows - we have the MQ -> publish and subscribe support pack in place but not> used by any> applications. Some how SYSTEM.BROKER.ADMIN.STREAM> and> SYSTEM.BROKER.DEFAULT.STREAM queues are getting> changed to GET disabled and> then back to enabled. BMC Patrol is raising warning> alarms saying when it> is polling these queues it is finding them in GET> disabled state. I checked> with applications users and unix administrators and> no one knows any process> / application doing this. When I look at these> queues, some time later, the> alter date on these queues shows current date and> time (every day these are> being altered by some process) and GETs are enabled.> I am hoping that there> will be some log entries to track which application> / user-id is doing these> disabling and enabling. Hence my first question, on> how to format these> logs without shutting down the queue manager.>>> Thanks in advance>> 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 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 inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive--Diese E-Mail enthaelt vertrauliche oder recht
Re: Formatting production logs
Sorry, I am wrong about Events helping you Rao. It will only fire off an event when an app tries to get from on Inhibited queue, And then it only tells you what that app was. It has no info for who inhibited the queue. :-( -Original Message- From: Potkay, Peter M (PLC, IT) Sent: Friday, March 26, 2004 9:11 AM To: 'MQSeries List' Subject: RE: Formatting production logs It will give him the Application Name and Application Type, as well as exactly when it happened, which may be enough. But yes, as Ruzi pointed out, there will not be an actual User ID. Event data QMgrName Description: Name of the queue manager generating the event. Identifier: MQCA_Q_MGR_NAME. Datatype: MQCFST. Maximum length: MQ_Q_MGR_NAME_LENGTH. Returned: Always. QName Description: Queue name from object descriptor (MQOD). Identifier: MQCA_Q_NAME. Datatype: MQCFST. Maximum length: MQ_Q_NAME_LENGTH. Returned: Always. ApplType Description: Type of application that issued the get. Identifier: MQIA_APPL_TYPE. Datatype: MQCFIN. Returned: Always. ApplName Description: Name of the application that issued the get. Identifier: MQCACF_APPL_NAME. Datatype: MQCFST. Maximum length: MQ_APPL_NAME_LENGTH. Returned: Always. Note: If the application is a server for clients, the ApplType and ApplName parameters identify the server, not the client. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 26, 2004 7:46 AM To: [EMAIL PROTECTED] Subject: Re: Formatting production logs in this case, what SYSTEM.ADMIN.QMGR.EVENT will record is the incident of an MQGET call from a queue that is GET-Inhibited. It will not record who inhibited it. So, I don't think it is going to be much of a help to Rao. Regards, Ruzi --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > Turn on Inhibit Events at the Queue Manager level. > Turn off temporarily the other Queue Manager Events. > Make the SYSTEM.ADMIN.QMGR.EVENT default persistence > equal to Persistent. > > > > Now monitor your SYSTEM.ADMIN.QMGR.EVENT queue for a > depth of greater than > 0. > > The next time someone Get Inhibits that queue, you > will know about it and > who did it, without messing with the logs. It will > record their treachory > without alerting them that the Event Queue was > updated, so you can blindside > them the next day with evidence in hand! > > > > > -Original Message- > From: Adiraju, Rao [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 25, 2004 5:49 PM > To: [EMAIL PROTECTED] > Subject: Formatting production logs > > > > Fellows > > I have two areas, where I appreciate some help: > > 1) Formatting the logs - > >In one of our production queue managers, > something fishy is going on and > I need to format the log to see who is exactly doing > the changes. I know > roughly what time the change is done and hence I can > nail down my log file > number(s) that are active around that time. The > trouble I am having is with > the "dmpmqlog" utility. I can't run it unless the > Queue manager is down > which I can't shutdown that easily. > > Is there any other utility, where I can format a > given log file Say, I > want to see the formatted report of S0003980.LOG > > 2) The problem I am trying to figure it out is as > follows - we have the MQ - > publish and subscribe support pack in place but not > used by any > applications. Some how SYSTEM.BROKER.ADMIN.STREAM > and > SYSTEM.BROKER.DEFAULT.STREAM queues are getting > changed to GET disabled and > then back to enabled. BMC Patrol is raising warning > alarms saying when it > is polling these queues it is finding them in GET > disabled state. I checked > with applications users and unix administrators and > no one knows any process > / application doing this. When I look at these > queues, some time later, the > alter date on these queues shows current date and > time (every day these are > being altered by some process) and GETs are enabled. > I am hoping that there > will be some log entries to track which application > / user-id is doing these > disabling and enabling. Hence my first question, on > how to format these > logs without shutting down the queue manager. > > > Thanks in advance > > 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 communication, including attachments, is for > the exclusive use of > addressee and may conta
Re: Formatting production logs
Title: Formatting production logs Turn on Inhibit Events at the Queue Manager level. Turn off temporarily the other Queue Manager Events. Make the SYSTEM.ADMIN.QMGR.EVENT default persistence equal to Persistent. Now monitor your SYSTEM.ADMIN.QMGR.EVENT queue for a depth of greater than 0. The next time someone Get Inhibits that queue, you will know about it and who did it, without messing with the logs. It will record their treachory without alerting them that the Event Queue was updated, so you can blindside them the next day with evidence in hand! -Original Message-From: Adiraju, Rao [mailto:[EMAIL PROTECTED]Sent: Thursday, March 25, 2004 5:49 PMTo: [EMAIL PROTECTED]Subject: Formatting production logs Fellows I have two areas, where I appreciate some help: 1) Formatting the logs - In one of our production queue managers, something fishy is going on and I need to format the log to see who is exactly doing the changes. I know roughly what time the change is done and hence I can nail down my log file number(s) that are active around that time. The trouble I am having is with the "dmpmqlog" utility. I can't run it unless the Queue manager is down which I can't shutdown that easily. Is there any other utility, where I can format a given log file Say, I want to see the formatted report of S0003980.LOG 2) The problem I am trying to figure it out is as follows - we have the MQ - publish and subscribe support pack in place but not used by any applications. Some how SYSTEM.BROKER.ADMIN.STREAM and SYSTEM.BROKER.DEFAULT.STREAM queues are getting changed to GET disabled and then back to enabled. BMC Patrol is raising warning alarms saying when it is polling these queues it is finding them in GET disabled state. I checked with applications users and unix administrators and no one knows any process / application doing this. When I look at these queues, some time later, the alter date on these queues shows current date and time (every day these are being altered by some process) and GETs are enabled. I am hoping that there will be some log entries to track which application / user-id is doing these disabling and enabling. Hence my first question, on how to format these logs without shutting down the queue manager. Thanks in advance 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 communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: BlockIP logic incorrect ??
Seeing that you are giving it away for free, and since you are not claiming it will make any body parts bigger, I would not consider it spam if you let us know when new versions come out. -Original Message- From: Jxrgen Pedersen [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 2:01 PM To: [EMAIL PROTECTED] Subject: Re: BlockIP logic incorrect ?? well, thats no big deal, it's just a new version of the source... The rework have saved me a lot of work, to enhance it even more ;o) The biggest problem can be the search engines/spiders, which will find this version 2.0 of the program, so newbies will download the source instead of the maintained version. So maybe I should send a mail here and on www.MQSeries.Net when there are new versions released ? Personally I think of such mails as spam, your oppinion wanted here :o) I'm quite happy that Sid did a redesign, I'm shure that the version soon vill be available from my website. I just have to run it thru my testcases to see if it work, I shure it works ;o) When I look a year back, and see how BlockIP have changed, and the requirements, from just a simple conname filtering program to what it is today. I see that it gives www.mrmq.dk a lot of traffic, so it have been a great success, and it know that the z/OS version of the original exit have been used for design base in some vendor packages. The language used here might offend some persons.. Politeness please here :-o Kind regards Jxrgen www.mrmq.dk the author of BlockIP >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: BlockIP logic incorrect ?? >Date: Thu, 25 Mar 2004 06:59:55 -0600 > >Actually Sid, you just released it. :-0 > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Thursday, March 25, 2004 6:59 AM >To: [EMAIL PROTECTED] >Subject: Re: BlockIP logic incorrect ?? > > > > > >G'Day Jxrgen, > >Well I went a bit overboard with the additional functionality and after >studying your code I decided to do a complete re-write... I figured you >would be pissed at me so I have not yet released it but essentially I split >out all the code into a modular form so that the main block of logic is no >longer a big bloatted mess. > >I have also made a fundamental change to the logic of the exit so that it >denied everything and if criterior failed it exited with the SUPPRESS flag >already set. So if you pass everything that needs to be done then you set >OK >as the LAST step. > >The original code did a lot of duplication in checking and was not very >modular so when I tried to add the logging functionality I needed I found >it >very difficult with the original structure. > >Basically each group of checks now has it's own method/function call. So >there is Pattern checking, CON= checking (you already had that one in a >function), SSL checking, UserId, MqmUsers ids and a method to process the >file and a method to process an array of options (which means the options >could be in a file or in the exit data field. > >It is now easier to add additional options and the code to handle them. the >code is not yet finished but I have attached todays effort, if you don't >want it thats fine, I'll keep it in house for my own use. > > >Sid > > >-Original Message- >From: Jxrgen Pedersen [mailto:[EMAIL PROTECTED] >Sent: Thursday, 25 March 2004 5:46 PM >To: [EMAIL PROTECTED] >Subject: Re: BlockIP logic incorrect ?? > > >Hi, Sid & Co. > >I'll look into it, but it should, match up both conname and userid before >accepting the connection and allow evt. the change of MCAUSER. > >Have you a debug sysprint (with the -d; option), pls. send for >investigation. > >Kind regards > >Jxrgen > >www.mrmq.dk >the author of BlockIP > > > > > > >From: [EMAIL PROTECTED] > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: BlockIP logic incorrect ?? > >Date: Thu, 25 Mar 2004 10:31:16 +1000 > > > > > >G'Day all, > > > >Has anyone tested the CON= commands in the latest version of BlockIP2.c >?? > > > >I get odd results when the host IP I am on is different to the pattern to > >match on, it seams that the user id is matched but the IP is ignored... >not > >quite what I would have expected which is if the IP matchs AND the user > >matchs then set the MCA to > > > > > >Any thoughts anyone ?? > > > > > >Sid Young > >QML Pathology > >_ >Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS and WMQ Cluster Workload Balancing
Your JMS queue object allows you to specify both a Queue name and a Queue Manager Name. The Queue name is obviously the MQ Queue. No surprises there. But the QMANAGER property is not for what Queue Manager you want to conect to, but rather it maps to the MQOD_ObjectQueueManager field. In any MQ app, JMS or not, if your fill in the ObjectQueueManager field with the name of a specific queue manager, your are telling MQ that the queue must be found on that queue manager. I bet your JMS Queue object incorrectly specifies the QMANGER property. Blank it out, and you'll be good to go. -Original Message-From: Sudheer Kumar [mailto:[EMAIL PROTECTED]Sent: Wednesday, March 24, 2004 9:51 PMTo: [EMAIL PROTECTED]Subject: Re: JMS and WMQ Cluster Workload Balancing Have you checked the queue properties...make sure that the bindings mode is set to "Not Fixed" instead of "On Open"... also check the queue open options used in the application... -Sudheer -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Ross StephensSent: Wednesday, March 24, 2004 6:09 PMTo: [EMAIL PROTECTED]Subject: JMS and WMQ Cluster Workload Balancing I'm using JMS against two identically named cluster queues, but all messages end up on one queue only. Does anyone know how to get the messages to share across the queues within the JMS API? Ross Stephens +61 (2) 9410 9930 +61 (419) 494 489 [EMAIL PROTECTED] www.mqis.com.au This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: Queues from non-cluster members...
Title: RE: Re: Queues from non-cluster members... Yes. -Original Message-From: Antony Boggis [mailto:[EMAIL PROTECTED]Sent: Tuesday, March 23, 2004 7:07 PMTo: [EMAIL PROTECTED]Subject: Re: Queues from non-cluster members... Even though neither of the repositories show the old queue manager when I do a "dis clusqmgr(*)" ?tonyB.-Original Message-From: MQSeries List on behalf of Potkay, Peter M (PLC, IT)Sent: Tue 3/23/2004 3:45 PMTo: [EMAIL PROTECTED]Subject: Re: Queues from non-cluster members...Use the RESET command to force a QM out of a cluster.RESET CLUSTER(yourclustername) QMID(thebadQMID) ACTION(FORCEREMOVE)QUEUES(YES)Issue it once from one of your Full Repositories.-Original Message-From: Antony Boggis [mailto:[EMAIL PROTECTED]]Sent: Tuesday, March 23, 2004 6:26 PMTo: [EMAIL PROTECTED]Subject: Queues from non-cluster members...I have a queue manager that has been removed from a cluster using thecorrect procedure (suspend, set channel attrs, stop channels...). I stillhave queues on other cluster members (even after having refreshed thecluster) from this (now, non-existant) queue manager showing up:dis clusqmgr(*) qmid 10 : dis clusqmgr(*) qmidAMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AR1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AR1) QMID(CLUSTER3B.AR1.MANAGER_2004-01-07_10.56.23)AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS1) QMID(CLUSTER3B.AS1.MANAGER_2004-01-07_11.01.47)AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS1C.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS1C) QMID(CLUSTER3B.AS1C.MANAGER_2004-01-07_11.02.22)AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS2.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS2) QMID(CLUSTER3B.AS2.MANAGER_2004-02-11_17.42.37)AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS2C.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS2C) QMID(CLUSTER3B.AS2C.MANAGER_2004-02-11_17.42.52)AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.DFMC1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.DFMC1) QMID(CLUSTER3B.DFMC1.MANAGER_2004-03-17_11.03.56)AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.TXN.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.TXN) QMID(CLUSTER3B.TXN.MANAGER_2004-02-04_12.20.33)AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(VISA_BMON_QMGR) CLUSTER(CLUSTER3B) CHANNEL(TO.VISA_BMON_QMGR) QMID(VISA_BMON_QMGR_2004-01-15_08.24.56)anddis qcluster(AR1.IN) all 9 : dis qcluster(AR1.IN) allAMQ8409: Display Queue details. DESCR(Queue in which AR1 will put XU messages) CLUSTER(CLUSTER3B) QUEUE(AR1.IN) CLUSQMGR(FT01.PDFMC.MANAGER) QMID(FT01.PDFMC.MANAGER_2004-02-17_10.38.48) CLUSDATE(2004-03-23) CLUSTIME(15.02.33) ALTDATE(2004-02-17) ALTTIME(10.50.43) CLUSQT(QLOCAL) TYPE(QCLUSTER) PUT(ENABLED) DEFPRTY(0) DEFPSIST(NO) DEFBIND(NOTFIXED)AMQ8409: Display Queue details. DESCR(Input queue for AR1) CLUSTER(CLUSTER3B) QUEUE(AR1.IN) CLUSQMGR(CLUSTER3B.DFMC1.MANAGER) QMID(CLUSTER3B.DFMC1.MANAGER_2004-03-17_11.03.56) CLUSDATE(2004-03-23) CLUSTIME(15.02.27) ALTDATE(2004-03-23) ALTTIME(14.47.40) CLUSQT(QLOCAL) TYPE(QCLUSTER) PUT(ENABLED) DEFPRTY(0) DEFPSIST(NO) DEFBIND(NOTFIXED)This is after doing a refresh (on all cluster members even).Regards,tonyB.Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archiveThis communication, including attachments, is for the exclusive use ofaddressee and may contain proprietary, confidential or privilegedinformation. If you are not the intended recipient, any use, copying,disclosure, dissemination or distribution is strictly prohibited. Ifyou are not the intended recipient, please notify the senderimmediately by return email and delete this communication and destroy all copies.Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Queues from non-cluster members...
Use the RESET command to force a QM out of a cluster. RESET CLUSTER(yourclustername) QMID(thebadQMID) ACTION(FORCEREMOVE) QUEUES(YES) Issue it once from one of your Full Repositories. -Original Message- From: Antony Boggis [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 6:26 PM To: [EMAIL PROTECTED] Subject: Queues from non-cluster members... I have a queue manager that has been removed from a cluster using the correct procedure (suspend, set channel attrs, stop channels...). I still have queues on other cluster members (even after having refreshed the cluster) from this (now, non-existant) queue manager showing up: dis clusqmgr(*) qmid 10 : dis clusqmgr(*) qmid AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AR1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AR1) QMID(CLUSTER3B.AR1.MANAGER_2004-01-07_10.56.23) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS1) QMID(CLUSTER3B.AS1.MANAGER_2004-01-07_11.01.47) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS1C.MANAGER)CLUSTER(CLUSTER3B) CHANNEL(TO.AS1C) QMID(CLUSTER3B.AS1C.MANAGER_2004-01-07_11.02.22) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS2.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.AS2) QMID(CLUSTER3B.AS2.MANAGER_2004-02-11_17.42.37) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.AS2C.MANAGER)CLUSTER(CLUSTER3B) CHANNEL(TO.AS2C) QMID(CLUSTER3B.AS2C.MANAGER_2004-02-11_17.42.52) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.DFMC1.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.DFMC1) QMID(CLUSTER3B.DFMC1.MANAGER_2004-03-17_11.03.56) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(CLUSTER3B.TXN.MANAGER) CLUSTER(CLUSTER3B) CHANNEL(TO.TXN) QMID(CLUSTER3B.TXN.MANAGER_2004-02-04_12.20.33) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(VISA_BMON_QMGR)CLUSTER(CLUSTER3B) CHANNEL(TO.VISA_BMON_QMGR) QMID(VISA_BMON_QMGR_2004-01-15_08.24.56) and dis qcluster(AR1.IN) all 9 : dis qcluster(AR1.IN) all AMQ8409: Display Queue details. DESCR(Queue in which AR1 will put XU messages) CLUSTER(CLUSTER3B) QUEUE(AR1.IN) CLUSQMGR(FT01.PDFMC.MANAGER) QMID(FT01.PDFMC.MANAGER_2004-02-17_10.38.48) CLUSDATE(2004-03-23)CLUSTIME(15.02.33) ALTDATE(2004-02-17) ALTTIME(10.50.43) CLUSQT(QLOCAL) TYPE(QCLUSTER) PUT(ENABLED)DEFPRTY(0) DEFPSIST(NO)DEFBIND(NOTFIXED) AMQ8409: Display Queue details. DESCR(Input queue for AR1) CLUSTER(CLUSTER3B) QUEUE(AR1.IN) CLUSQMGR(CLUSTER3B.DFMC1.MANAGER) QMID(CLUSTER3B.DFMC1.MANAGER_2004-03-17_11.03.56) CLUSDATE(2004-03-23)CLUSTIME(15.02.27) ALTDATE(2004-03-23) ALTTIME(14.47.40) CLUSQT(QLOCAL) TYPE(QCLUSTER) PUT(ENABLED)DEFPRTY(0) DEFPSIST(NO)DEFBIND(NOTFIXED) This is after doing a refresh (on all cluster members even). Regards, tonyB. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Use channel exits or not?
Is this something that you will need always from this point forward, or is this a one time deal just to get an idea? If all you want to know is how long name resolution takes place on the MQ Hub this one time, I would do the following: Do this off hours. Create a new channel into the Hub, and a new channel out of the hub. STOP the channel into the Hub. Preload the XMIT queue feeding the channel into the Hub with 100,000 persistent messages of an average size for your shop. Record the time and start the channel. When the last message finally resolves thru the hub and the depth hits 100,000 on the other side, record the time. Subtract the 2 times, and divide by 100,000. Your answer is the average time that a message took to get through the hub. Sorry if I keep shying away from answering your exit questions. One I don't know the first thing about exits, and 2, if there is a simple, not so glamorous way to get an answer, why not? :-) -Original Message-From: Kulbir S. Thind [mailto:[EMAIL PROTECTED]Sent: Tuesday, March 23, 2004 12:51 PMTo: [EMAIL PROTECTED]Subject: Re: Use channel exits or not?Gentlemen, A few points: The timings are captured on the hub and there is only a single hub so we shouldn't have any issues. We want to use circular logs as they are easier to maintain. By "shared channel exit" I'm suggesting that we have a channel exit created and make a physical copy of it for each channel instance that we have. Is this approach going to give us better performance and be safer? Does it require more resources rather than having a single channel exit (i.e. dll) that is used by all channel instances?Cheers, Kulbir. "Rick Tsujimoto" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 23-Mar-2004 15:04 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: Use channel exits or not?If the timings are captured on different boxes, and the machine clocks arenot synchronized, then you could have some interesting results."David C.Partridge" To: [EMAIL PROTECTED]<[EMAIL PROTECTED] cc:RIMEUR.COM> Subject: Re: Use channel exits or not?Sent by: MQSeriesList<[EMAIL PROTECTED].AC.AT> 03/23/2004 08:23AMPlease respond toMQSeries List Additional comments:Acquire the storage for you structure at MQXR_INIT time, and store thepointer in MQCXP.ExitUserArea.Make sure that you release the storage and clear the pointer at MQXR_TERMtime.Do whatever processing you need at MQXR_MSG time (you'll probably want toknow whether the message is inbound or outbound on the channel - look atMQCD.ChannelType to determine what type of channel this is.DaveInstructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archiveInstructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: 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.
Re: Use channel exits or not?
Application connects to QMSpoke1. QMSpoke1 hosts a RemoteQueueA, pointing at RemoteQueueB, which lives on QMHub. RemoteQueueB on QMHub points back at LocalQueue1 on SpokeQM1. Application connects to QMSpoke1, and Opens RemoteQueueA for putting, and opens LocalQueue1 for getting. Put a message into RemoteQueueA. Record the time. Application immediatly MQGets from LocalQueue1. Record the time. Subtract the two times, and you have the amount of time a message takes to get thru the hub. Yes it includes time spent on the channels, but that is relevant. Put both QMs on the same box, and have your channels already running to eliminate these variables as much as possible. Do the test again by changing RemoteQueueA to point right to LocalQueue1 to see what a difference there is if you eliminate the channel/HUB hops. -Original Message-From: Kulbir S. Thind [mailto:[EMAIL PROTECTED]Sent: Monday, March 22, 2004 2:00 PMTo: [EMAIL PROTECTED]Subject: Use channel exits or not?Hi, We are planning on having a hub and spoke architecture that will see 100's of applications connect into the WBI MB hub we will implement. We have a requirement to be able to determine the amount of time that the messages have spent in the hub. We thought we would do this by implementing some auditing functionality using channel exits to copy the messages to another destinations as it arrives and as it leaves. We have had some worrying comments regarding using channel exits for this purpose, these comments are: this will degrade channel performance an error in the exit could cause message lossThe alternatives to this approach are as follows: Use a message get MQ exit Use a stand-alone program Add a metrics node into the message flow.The main problems with the above approach are that they will not give us a true indication of the amount of time the messages have spent in a hub. My other concerns are that the alternative approaches will not provide better performance than using channel exits. Would anyone like to comment on this? Cheers, Kulbir. 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.
How to configure the WaitInterval for MDBs
When an MDB is watching a queue, I suspect that it is simply issuing MQGETs with the WaitInterval set. Is this true? If so, is that WaitInterval configurable? If yes, what would be the drawback be to setting it to a high value, like an hour? The reason I ask is that we are rolling out Transaction Vision, which is going to capture all MQ API calls. I am afraid that if I install it on a queue manager that hosts queues being watched by MDBs, I will be seeing tons of 2033s if the MDBs WaitInterval is small. Does an MDB actually do anything in between issuing MQGETs, or does it simply reissue the MQGET in a tight loop? Is there any good doc on MDBs and how they play with WebSphere MQ? All the manuals I have looked at don't even acknowledge their existence. 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
Re: Messages stuck in cluster transmit queue
Nope. But with many inquiry messages in the mix, whose to say they just didn't reissue the query and never report the first message not coming back? -Original Message- From: Thomas, Don [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 3:35 PM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in cluster transmit queue I guess the question boils down to: Has anyone been reporting messages going missing? Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (PLC, IT) Sent: Tuesday, March 16, 2004 3:07 PM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in cluster transmit queue ??? There is nothing to do. You cant browse the message. If you bounce the channel, its still there. If you stop the channel, you cant clear the queue. If you try and resolve the channel with either a commit or back out, it does nothing. There are no outstanding units of work. Who knows if its even a real message? -Original Message- From: Awerbuch, David [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in cluster transmit queue Peter, Once you get messages stuck in your XMIT queues, what do you have to do to get them to flow again? I can't imagine you just leave them there until they start to flow again on their own, that makes no sense and would not work for most business environments where message content is of a timely (read that as 'immediate') nature. Dave A. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 2:39 PM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in cluster transmit queue Messages stuck on CLUSTER TRANSMIT queues is a problem that has been kicking around for a while. There are a few post on mqseries.net about this. If you go to www.mqseries.net, and do a search on "TRANSMIT" and or "STUCK", while pointing your search at the Cluster forum, you'll get a few hits. I'd post a solution common to them all, but there doesn't see to be one, other than upgrade. Yet I am at 5.3 CSD04, and 2 of my queue managers get messages stuck in their XMIT queues for days at a time. Weird. Annoying. -Original Message- From: Lovett, Alan J [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 12:24 PM To: [EMAIL PROTECTED] Subject: Messages stuck in cluster transmit queue Hi, We have a problem on our systems that I hope someone might be kind enough to respond to. We are well stuck! We have an up till now stable system where central servers on OS/390 write persistent messages across a set of remote Windows queue managers. All the systems are 5.2. The target queues are clustered aliases, one per remote, each uniquely named, and resolving to a local queue. The situation as I write is that significant numbers of messages are stuck on one of the z/OS systems SYSTEM.CLUSTER.TRANSMIT.QUEUE. The cluster channel is running, the cluster has been refreshed at both ends, no in-doubt is reported. The source can open the target queue, the channel (both ends) reports a 'SAVED' status.and yes, I did say please! My suspicion is that the size of the unit of work exceeds the receiving system's capacity, but we did redefine the system some months ago, to increase the logs well in excess of what we believe to be demanded of it. We are hounding our user to get some figures from them. Can anyone suggest what might be causing the problem, or how to increase our understanding of it? Many thanks in advance of your charity. Regards, Alan *** Credit Lyonnais This e-mail contains confidential information or information belonging to Credit Lyonnais and is intended solely for the addressees. The unauthorized disclosure, use, dissemination or copying (either whole or partial) of this e-mail, or any information it contains, is prohibited. E-mails are susceptible to alteration and their integrity cannot be guaranteed. Credit Lyonnais shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Credit Lyonnais in the Americas: Credit Lyonnais Bank New York Branch, Credit Lyonnais Americas Services Inc., Credit Lyonnais Rouse (USA) Ltd., and Credit Lyonnais Securities (USA) Inc. *** Credit Lyonnais Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and m
Re: Messages stuck in cluster transmit queue
??? There is nothing to do. You cant browse the message. If you bounce the channel, its still there. If you stop the channel, you cant clear the queue. If you try and resolve the channel with either a commit or back out, it does nothing. There are no outstanding units of work. Who knows if its even a real message? -Original Message- From: Awerbuch, David [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in cluster transmit queue Peter, Once you get messages stuck in your XMIT queues, what do you have to do to get them to flow again? I can't imagine you just leave them there until they start to flow again on their own, that makes no sense and would not work for most business environments where message content is of a timely (read that as 'immediate') nature. Dave A. -Original Message----- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 2:39 PM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in cluster transmit queue Messages stuck on CLUSTER TRANSMIT queues is a problem that has been kicking around for a while. There are a few post on mqseries.net about this. If you go to www.mqseries.net, and do a search on "TRANSMIT" and or "STUCK", while pointing your search at the Cluster forum, you'll get a few hits. I'd post a solution common to them all, but there doesn't see to be one, other than upgrade. Yet I am at 5.3 CSD04, and 2 of my queue managers get messages stuck in their XMIT queues for days at a time. Weird. Annoying. -Original Message- From: Lovett, Alan J [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 12:24 PM To: [EMAIL PROTECTED] Subject: Messages stuck in cluster transmit queue Hi, We have a problem on our systems that I hope someone might be kind enough to respond to. We are well stuck! We have an up till now stable system where central servers on OS/390 write persistent messages across a set of remote Windows queue managers. All the systems are 5.2. The target queues are clustered aliases, one per remote, each uniquely named, and resolving to a local queue. The situation as I write is that significant numbers of messages are stuck on one of the z/OS systems SYSTEM.CLUSTER.TRANSMIT.QUEUE. The cluster channel is running, the cluster has been refreshed at both ends, no in-doubt is reported. The source can open the target queue, the channel (both ends) reports a 'SAVED' status.and yes, I did say please! My suspicion is that the size of the unit of work exceeds the receiving system's capacity, but we did redefine the system some months ago, to increase the logs well in excess of what we believe to be demanded of it. We are hounding our user to get some figures from them. Can anyone suggest what might be causing the problem, or how to increase our understanding of it? Many thanks in advance of your charity. Regards, Alan *** Credit Lyonnais This e-mail contains confidential information or information belonging to Credit Lyonnais and is intended solely for the addressees. The unauthorized disclosure, use, dissemination or copying (either whole or partial) of this e-mail, or any information it contains, is prohibited. E-mails are susceptible to alteration and their integrity cannot be guaranteed. Credit Lyonnais shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Credit Lyonnais in the Americas: Credit Lyonnais Bank New York Branch, Credit Lyonnais Americas Services Inc., Credit Lyonnais Rouse (USA) Ltd., and Credit Lyonnais Securities (USA) Inc. *** Credit Lyonnais Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Messages stuck in cluster transmit queue
Messages stuck on CLUSTER TRANSMIT queues is a problem that has been kicking around for a while. There are a few post on mqseries.net about this. If you go to www.mqseries.net, and do a search on "TRANSMIT" and or "STUCK", while pointing your search at the Cluster forum, you'll get a few hits. I'd post a solution common to them all, but there doesn't see to be one, other than upgrade. Yet I am at 5.3 CSD04, and 2 of my queue managers get messages stuck in their XMIT queues for days at a time. Weird. Annoying. -Original Message- From: Lovett, Alan J [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 12:24 PM To: [EMAIL PROTECTED] Subject: Messages stuck in cluster transmit queue Hi, We have a problem on our systems that I hope someone might be kind enough to respond to. We are well stuck! We have an up till now stable system where central servers on OS/390 write persistent messages across a set of remote Windows queue managers. All the systems are 5.2. The target queues are clustered aliases, one per remote, each uniquely named, and resolving to a local queue. The situation as I write is that significant numbers of messages are stuck on one of the z/OS systems SYSTEM.CLUSTER.TRANSMIT.QUEUE. The cluster channel is running, the cluster has been refreshed at both ends, no in-doubt is reported. The source can open the target queue, the channel (both ends) reports a 'SAVED' status.and yes, I did say please! My suspicion is that the size of the unit of work exceeds the receiving system's capacity, but we did redefine the system some months ago, to increase the logs well in excess of what we believe to be demanded of it. We are hounding our user to get some figures from them. Can anyone suggest what might be causing the problem, or how to increase our understanding of it? Many thanks in advance of your charity. Regards, Alan Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Authorization Question
Just a guess, did you try to use the -remove switch? setmqaut -m QM1 -t q -n your.queue.name -remove -p theIDyouWantToBoot -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 11:12 AM To: [EMAIL PROTECTED] Subject: Authorization Question I'm attempting to use generic profiles on our 5.3 distributed queue managers. It's an overdue feature that should significantly simplify our security model. But for our existing queues, there's a problem. It looks like there's no way to remove a group from a queue's access list. If you do a setmqaut with "-all" the group in question is still on the list, but with *no* access. We want MQSeries to go up the authorization hierarchy to the generic profile, but since the group is still on the access list it won't. I know that deleting and redefining the queue gives it a fresh start, but I'd rather not go through that if I can help it. Can I? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Request / Reply
Jeff wrote: "I cannot use remote queues or alias since the destination queue is the same name for all five sites, so how do I set things up so it resolves correctly." Sounds like you already did. If there is a XMIT queue named exactly like the ReplyToQueueManager, MQ name resolution will place the message there and deliver it to the correct QM. -Original Message- From: Jeff A Tressler [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 3:28 PM To: [EMAIL PROTECTED] Subject: Request / Reply I understand the theory of Request/Reply with respect to ReplyToQueue and ReplyToQueueManager. But how do I set this up to actually work. We have 5 systems sending to a single server. All connection use Sender./Receiver channels so no client connections. I believe I set up a transmission queue for each of the five sites. The name of the transmission queues are the same as the name of the destination queue managers. What I believe will happen is the application copies the ReplyToQeue and ReplyToQueueManager from the message that arrives to the ReplyToQeue and ReplyToQueueManager of the Reply message. It sets the MessageType to MQMT_REPLY ... And here is where I get lost. They need to open a queue but the ReplyToQueue does not exist on the server, only a transmission queue named for the destination queue manager. Do I use MQPUT1 and hope MQSeries resolves the open to the correct transmission queue? I cannot use remote queues or alias since the destination queue is the same name for all five sites, so how do I set things up so it resolves correctly. Jeff Tressler Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: COA COD
COA will be used when you want to Confirm On Arrival your message to the destination queue. In other words, you will get a report message when the original request message arrives at the destination queue. COD will Confirm On Delivery, meaning you get the report message when some application does an MQGET on your request message. You can specify both together. "and how can I get them in a different queue from my replyToQ." You can't, which is lame. I opened up a request for IBM to maybe create a secondary Reply2Q / QM field for Reports. They said no. ??? So your application has to handle both application replies, AND reports. -Original Message- From: Khedr, Hossam (GEI, MORT) [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 1:22 PM To: [EMAIL PROTECTED] Subject: COA COD Hi all, Can you guys put some light on the use of COA / COD reports. In another way, what would I use them for, and how can I get them in a different queue from my replyToQ. Thanks, Hossam Khedr GE Mortgage Insurance Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ Channel Production Issue
Title: Message No, these are different animals completely. They are not going to effect your original problem at all. Please take a look at the Intercommunication Manual: http://publibfp.boulder.ibm.com/epubs/html/csqzae08/csqzae08tfrm.htm Chapter 6. Rather then me rehashing the manual, take a look here and let me know if you have more specific questions for these 2 parameters. Basically, the higher you make BATCHINT, the longer your channel will hold back messages before committing them at the receiving side (but is saves CPU cycles on a per message basis, since you are not constantly committing). I use 0 for my BATCHINT, since I value speed of overall messaging more. The higher the BATCHINT value is the more important BATCHHB is. I have mine at zero as well, since I don't have open batches for long periods of time. -Original Message-From: Woodcox, Janice Engle (DIS) [mailto:[EMAIL PROTECTED]Sent: Monday, March 15, 2004 12:20 PMTo: [EMAIL PROTECTED]Subject: MQ Channel Production Issue Hi Peter. Thank you very *much* for your explanation and suggestions of settings for the "disconnect and heartbeat interval". We are changing and testing this week. Would it also be adviseable to change the "batch interval and batch heartbeat interval" to the same values? meaning:Disconnect interval . . . . : 300Heartbeat interval . . . . : 30 Batch interval . . . . . . : 300Batch heartbeat interval . : 30 === Janice (Engle) Woodcox === Department of Information Services / Computer Services Divisions/390 Customer Technical Support Help Desk Phone: 360-753-2454 Direct Line: 360-902-3102 [EMAIL PROTECTED] Group Web Site: http://sww.wa.gov/dis/csd_ctss/ = -Original Message-From: Yeske, Judy [mailto:[EMAIL PROTECTED]Sent: Friday, March 12, 2004 9:13 AMTo: [EMAIL PROTECTED]Subject: Re: MQ Channel Production Issue Thanks again Peter ! In our development system, we were able to recreate the problem. I then revised the ADOPTMCA parm from NO to YES. We reran our test, way too cool! The NT Server sender channel went from retrying to running (without manual intervention of having to drop the socket). The channel was adopted, the original socket was gone and a new socket was created. This is perfect, thank you again !! Judy -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT)Sent: Friday, March 12, 2004 11:08 AMTo: [EMAIL PROTECTED]Subject: Re: MQ Channel Production Issue I have never dealt with AIX, but I have for NT and the mainframe. From a channel perspective and AdoptNewMCA, KeepAlive, Heartbeats, and DISCINT, I would consider AIX and NT identical, as they are both considered "distributed" platforms. Maybe some one with AIX experience will contradict this, but I don't think so. -Original Message-From: Yeske, Judy [mailto:[EMAIL PROTECTED]Sent: Friday, March 12, 2004 10:03 AMTo: [EMAIL PROTECTED]Subject: Re: MQ Channel Production Issue Peter, Thank you very much, this is extremely helpful. We are attemtping to recreate our problem on development nodes. We're using an AIX box, connecting to my Mainframe MQ. We've attempted several disconnects (restarting MQ on the AIX, breaking the network connection). For every test between the AIX and the mainframe, the mainframe channel is ending abnormally and then restarting - no hung sockets. In Production, when this occurs between the NT server and the mainframe, the mainframe channel remains active and we have a hung socket. We're in the process of getting an NT development server. In the meantime, I have a question. In Janice's note below, she mentions problems with NT Server. I'm a total mainframe person, what is the difference between an AIX box and an NT server and how does MQ differ between the two ? Thanks, Judy -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT)Sent: Wednesday, March 10, 2004 8:27 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Channel Production Issue When the SNDR goes away, the RCVR is left twiddling its thumbs, waiting for the SNDR channel to send it something, anything. If heartbeats are turned on, the HBs will flow back and forth at regular intervals, when no real MQ application messages are flowing. Both ends of the channel know when to expect the next heartbeat, and if they don't get it, they assume a network outage, and thus gracefully end the channel and p
Re: Deleting SYSTEM queues on DMZ MQ Server
http://www.mqseries.net/phpBB2/viewtopic.php?t=13935&highlight= See this post, where the conversation turns to clusters spanning a DMZ. -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 9:53 AM To: [EMAIL PROTECTED] Subject: Re: Deleting SYSTEM queues on DMZ MQ Server Sid, You'll want to keep the SYSTEM.* queues that are not defaults. The only reason we deleted the default queues was to require fully-specified definitions for any new objects. The intent was not to increase security as much as it was to slow down an intruder so (s)he spends more time on the box and leaves a bigger footprint. But this is only useful when intrusion detection monitoring and strict auditing is in place. And a cluster in the DMZ is a whole other animal. Hopefully you have set up a DMZ gateway cluster that separates the namespaces of your internal cluster and that of the third party. -- T.Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 5:47 AM To: [EMAIL PROTECTED] Subject: Deleting SYSTEM queues on DMZ MQ Server G'Day all, Sometime ago, someone wrote about how they secured their DMZ homed MQ servers by deleting SYSTEM queues amongs other things, could anyone tell me what would be the minimum queues to keep the server running and reduce comprimises in a clustered queue manager. Also, I stil need a command server for PCF messages so this might complicate things. Sid Young QML Pathology Instructions for managing your mailing list 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
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
