Re: MQSeries configuration products
Try MQSoftware's Qpasa > -Original Message- > From: MQSeries List [SMTP:[EMAIL PROTECTED] On Behalf Of Egner, Dan > Sent: Monday, March 08, 2004 10:00 AM > To: [EMAIL PROTECTED] > Subject: Re: MQSeries configuration products > > I work for BMC Software. > > PATROL for WebSphere MQ allows you to stage changes. > > PATROL for WebSphere MQ Administration Guide Version 4.1 > > http://documents.bmc.com/supportu/documents/79/42/27942/27942.pdf > > It is described in chapter 5 called > > Managing Change in the WebSphere MQ Environment with the Administrative > Console > > When I want to reach a BMC salesperson I call 713-918-1371, which gets you > to a sales assistance department. > > Dan Egner > BMC Software, Inc > Houston, TX > > -Original Message- > From: John M Hammond [mailto:[EMAIL PROTECTED] > Sent: Friday, March 05, 2004 3:26 PM > To: [EMAIL PROTECTED] > Subject: MQSeries configuration products > > > I would like to replace my enterprise's existing MQSeries configuration > product due to some problems we've been experiencing. > > The killer feature our current product has is the ability to maintain a > database of definitions which is entirely separate from our live system. > We use this 'Update actual from defined' feature extensively to prepare our > system updates ahead of time and then roll them out to production in > regular maintenance windows. > > I have looked through "the usual suspects" so far as MQ configuration tools > goes, but have found that they all apply changes to the system immediately. > Does anyone know of a product that will allow me to stage updates to my > queue managers? For us, this is essential, and any application that does > not have this ability has to be discounted out of hand. > > Any info at all would be appreciated. > Thanks, > John > > John M Hammond > HSBC Technology Services (USA) > Data Center - Middleware > (630) 521-4339 > > Instructions for managing your mailing list 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 *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** Instructions for managing your mailing list 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 with Veritas on Sun Solaris
WE are running qmgrs under same scenario on A & B side of active/active configuration. No problems. [Lane, Bob (Exchange)] -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Kulbir S. ThindSent: Monday, December 22, 2003 11:45 AMTo: [EMAIL PROTECTED]Subject: MQ with Veritas on Sun Solaris Hi, We are doing the initial system design for our messaging solution. We plan currently to run a production environment consisting of a pair of Sun Unix servers in a high availability configuration using Veritas agents for failover management. The file systems are stored on a storage array network (SAN) visible to both servers. We are thinking of running MQ/ WBIMB on one of the servers and MQ/Oracle/Custom reporting apps on the other server. The links between the servers are: (1) messaging via MQ series from one to the other (2) ODBC calls from WBIMB to Oracle for data lookup and storage. The question is, has anyone experience of running this type of configuration with Veritas and set it up so that should server A fail then all the processes failover to server B and if server B fails then all the processes failover to server A ? Are there any problems with running MQSeries on both servers ? Thanks in advance, Kulbir. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. ***
Re: How do you test a MQSeries recovery plan
How are you Don If your client is connected to a qmgr hosting a cluster q then there will be no round robin. You would have to PUT to another qmgr that does not host a cluster q. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Don Murray Sent: Wednesday, November 19, 2003 9:36 AM To: [EMAIL PROTECTED] Subject: Re: How do you test a MQSeries recovery plan Good morning or afternoon as whatever the case may be. I'm running in to a problem with MQ cluster load balancing with-out an exit. We have 10 applications on various servers connecting to a cluster (XXX_CL1). All applications are connected calling the MQ Client to one of the 3 servers and puts to a queue that is clustered on all 3 servers. 3 different qmgrs, 3 different servers, created 3 identical queues (clustered with-in the same cluster), on 3 full repositories; Default Bind is Not Fixed. Cluster senders and receivers are running between all qmgrs. All queues and clustered queues are seen through all the qmgrs. When putting messages via a client channel the messages go to one queue only and not in a round robin as specked? There is no qmgr specified in the put as the messages should resolve to the next qmgr in the cluster work load list. With that in mind, would this issue be caused by the set MQSERVER environment variable that is being used? If so how do I get around this? What am I missing? Donald S. Murray MQSeries Engineer Desk- 201-369-8624 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** Instructions for managing your mailing list 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: Linear Logging Performance Tuning - Unix
MAtt I will tell you of an experience we had with EMC. You know that IBM recommends separation of Qmgr data & logs. Well, our engineering group had told us that this was not necessary with EMC due to caching and dual rotating controllers etc. When we were testing with MQ 53 on high performance Linux intel box we had some pretty miserable and incosistent results. So we decided to put the data & logs on separate LUNs of EMC. The performance numbers went way way up and were consistent. We found on Solaris that the testing on separate LUNs did not make as big a difference but this was old hardware sun box. -Original Message- From: Gurney, Matthew [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 04, 2003 3:16 AM To: [EMAIL PROTECTED] Subject: Linear Logging Performance Tuning - Unix > MQ 5.2 CSD7 > Solaris 5.8 > > I am trying to understand more about the parameters for linear logging, and what affects they have on Queue Manager performance. > > If you wanted to maximise Queue manager performance, what logging parameters would you choose in a situation where you have the following criteria: > * effectively unlimited disk space - a job runs every hour to delete unneeded log files, and we never come close to filling our quota of space > * hi performance SAN (EMC) > * linear logging > * queue Managers doing millions of messages per day > * all messages are persistent > * average message size 4k > * did not want to add any additional risk of message loss/data corruption ( I include this because I don't want to consider the LogWriteIntegrity Setting) > > LogPrimaryFiles= 62 <- this is a tricky one because for linear logging it's affect is not as obvious as for circular logging, I am going to suggest 62. > LogSecondaryFiles=1 < - again, this is a tricky on because for liner logging it's affect is not as obvious as for circular logging, I am going to suggest 1. > I have chosen 62 and 1 because the maximum number of log files is supposed to be 63. I am not sure if MQ will accept 63 and 0, does anyone know? > LogFilePages=16384 <- I think this is a real "tuning" parameter, ie it may not be best to have the maximum value, which means maximum log file size, for Solaris the maximum value here is 16384. I am going to suggest going for 16384 anyway. > LogType=LINEAR > LogBufferPages=512 <- I think this should be as large as possible, so I have gone for the max of 512 > > In summary I am suggesting going for the maximum value for all of the logging tuning parameters. I don't really know for sure if this is the best thing to do. Can anyone improve on my suggestions? > Does anyone have any input on this, or links to relevant documentation / support pacs / tuning guides? > As always any input is much appreciated. > Thanks, > Matt. > > == This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. == Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** Instructions for managing your mailing list 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: No. of MQ Connections
For starters - to get the number of client connections you could try: netstat -an |grep 1414 This is assuming the listener is running on 1414 Bob -Original Message- From: Ganapathy, Sundari (Cognizant) [mailto:GSundari@;CHN.COGNIZANT.COM] Sent: Tuesday, October 29, 2002 4:38 AM To: [EMAIL PROTECTED] Subject: No. of MQ Connections Hi, Could someone tell me how we can capture the number of open MQ connections at any point of time in the server ? The scenario is something like this : There is a request and a response queue. The client, when logging on to the application, creates 10 MQ connections which is running on the server, The client places request messages in the request queue using the 10 client connections. The server creates 4 MQ connections. So as and when the number of clients increase the number of connections also increase, depending on the client settings. The server is running on AIX. To check whether the connections are properly created and closed, it is needed to check the open connections. Any help is appreciated. TiA Sundari * Work : +91 44 811 3063 Extn 2253 Vnet: 42253 * Home : +91 44 654 4396 * Mobile: +91 98401 50853 .. Think Big. Think Differently. Challenge conventional wisdom. Think long term. - Dhirubhai Ambani *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** Instructions for managing your mailing list 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: SAVEQMGR
Is command server running? -Original Message- From: Jason Reckelhoff [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 15, 2002 11:23 AM To: [EMAIL PROTECTED] Subject: SAVEQMGR When running the SAVEQMGR on the queue manager, it starts and says Requesting attributes of the queue manager... Then it just quits. Put a pause after the batch file that runs the executable, and it just goes to the pause without scrolling through the definitions or creating the files with the definitions in it. Any ideas on this one? It has worked previously but now it doesn't run. Have recreated batch file and download the updated SAVEQMGR.EXE file as well. Jason Reckelhoff Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** Instructions for managing your mailing list 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: client connect to OS/390 MQ 5.2
> We are exploring connecting as MQ clients directly to an OS/390 5.2 > qmgr. We know that there are issues re: security but our concerns are > more with performance. Has anyone had any issues with performance when > connecting as clients? > > Thanks in advance > > Bob > > > > > > > Instructions for managing your mailing list 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: client connect to OS/390 MQ 5.2
We are exploring connecting as MQ clients directly to an OS/390 5.2 qmgr. We know that there are issues re: security but our concerns are more with performance. Has anyone had any issues with performance when connecting as clients? Thanks in advance Bob Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive