Re: Clustering Question
Title: Message Hi Tony, Have you considered adding clustered aliases to your TEST.QUEUE's, e.g. PARTICULAR.TEST.QUEUE. That way your consumers canget their messages from a single queue, even when the producer wanted a particular destination. It also gives you the option of scaling up a location or region's resources by having multiple aliases with the same name. You also get the opportunity of naming the aliases with qualifiers that are meaningful in business terms, rather than MQ admin terms. It is also clean JMS. Alan -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T RobSent: 29 November 2004 17:29To: [EMAIL PROTECTED]Subject: Re: Clustering Question Funny but we just had this conversation in our team meeting today except it was about JMS and Pub/Sub. My colleague was explaining that JMS requires a one-to-one correspondence between JNDI managed objects and potential destinations.So a cluster queue defined in JNDIis known to JMS as a single destination, no matter how many instances of the queue exist. OR...you can have a different JNDI object for each combination of QMgr/Queue, even though the queues all have the same name. What you cannot do, apparently, is open a JNDI object and dynamically specify the QMgr part of the destination because "QMgr" is an MQ constructis not part of the JMS spec. So if my colleague is correct (and we are still pretty new to JMS over here so I'll be the first to admit this may be a much deeper issue), you either need to create a separateJNDI object for each possible destination queue, or use a solution that is not pure JMS. I'll be interested to see if anyone else has a solution that works within JMS and does not require all the JNDI objectsbecause it might help us with our Pub/Sub problem. -- T.Rob -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Bender, AlanSent: Monday, November 29, 2004 11:44 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question Sorry, I made a poor assumption, I should know better. We may do it differently than Tony has in mind. Our online app is on the WAS server and we always connect to the same QMGR with JMS. Then based on customer number, or some other factor that determines where an order is filled we send the Queue messages to the correct queue. It is at that point we require a unique queue name as any reference to the receiving queue manager name in the message header will, no can but will, cause the 2085 error message. I don't understand your reference to round robining as the original question asked about sending a message to a unique queue. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (ISD, IT)Sent: Monday, November 29, 2004 10:24 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question You should use the QMGR name attribute of the queue object, and populate it with the name of a QM in the cluster that does host the queue. If you choose a QM that does not have the queue, you will get the 2085. If you populate it with the local QM name, you lose round robining if the local QM hosts that queue, or 2085 if it does not. You don't need to make different q names on all your clustered QMs. -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Bender, AlanSent: Monday, November 29, 2004 11:17 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question Tony, We have an application running with the same component versions. You must remember that in a cluster containing multiple copies of the same Queue name the cluster will load balance. We have also noted that with the JMS client connection if the QMGR name is used in the JMS configuration we get the dreaded 2085 error code MQRC_UNKNOWN_OBJECT_NAME. What we have done is to append the Queue name with the, in our case, division number. (example: TEST.QUEUE.012). That way you have a unique queue. This may seem simplistic but it does work. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony.AllisonSent: Monday, November 29, 2004 9:53 AMTo: [EMAIL PROTECTED]Subject: Clustering Question Good morning everyone... I think I am having a brain meltdown Here is what we are trying to accomplish. Components:1. WAS 5.1 2. Websphere MQ 5.3.0.8 1370 queue managers in single cluster. WAS application running with client connection to central queue manager needs to send a single message to one queue manager in the
Re: Using gsk6cmd to create certificates and key ring files on AI X
Bill, That statement does create concerns! Given that gsk6cmd and gsk6man share the same code I translate the statement as meaning little. In the interval between about a year ago and some unknown point in the future, we use gsk6cmd successfully on AIX. In my experience, rely upon JAVA_HOME to point to the Java run-time installed with MQ (/usr/mqm/ssl/jre). Attempting to set up your own class path leads to madness. We use openSSL on a Windows system to cut the PKCS12 file. We import these into a copy of our empty model key repository. When you create one with gsk6cmd, it populates it with popular CA certificates, which we most definitely don't want - we need full control of the CA. Deleting them all is then a once only activity. You might find it useful to trawl the web for general stuff about gsk6cmd. You will notice that there is a history of problems getting that first key repository created. Once past that the problems get easier. Also the AIX documentation of gsk6cmd is somewhat more forthcoming than MQ's. What are your messages? Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Anderson Sent: 22 November 2004 20:06 To: [EMAIL PROTECTED] Subject: Using gsk6cmd to create certificates and key ring files on AIX I have been struggling with setting up SSL on an AIX server running AIX 5.2 and WMQ5.3 CSD07. The IBM security manual only walks you through procedures for using the gsk6ikm which only works with a server that is X-compatible (so you can see the GUI of course). It goes on to say, and I quote, WebSphere MQ does not support the gsk6cmd command. gsk6cmd is the command line version of the ikeyman tool used to create key repositories and certificates. has anyone had success using gsk6cmd on AIX? I have tried, but get various errors depending on how I set up the environment and what command line options I use with the tool. Thanks Bill Anderson SITA Atlanta, GA Standard Messaging Engineering WebSphere MQ Service Owner 770-303-3503 (office) 404-915-3190 (cell) This e-mail contains information which is SITA - Company Confidential All sita.int addresses have changed to sita.aero [EMAIL PROTECTED] http://www.mconnect.aero/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Receiver channel parameters mrrty and mrtmr
Many thanks for the excellent Reponses to my enquiry. 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
Receiver channel parameters mrrty and mrtmr
Hi, We have been asked to justify our decision to let receiving channel message retry count and interval parameters (mrrty and mrtmr) take their default values. These allow (non z/OS) MQ to retry message put failures up to 10 times, one second apart, before writing the message to the dead letter queue. For the obvious reasons (no such queue, expired temporary dynamic queue), there seems little point to the retries, and reasonable concern over possible backlogs following a transient hold-up, e.g. network hitch. To the question - Is anyone aware of sound reasons for keeping the default values as they are? Is there a reasonably common condition that causes a temporary inability to deliver valid messages, that is overcome via the retries? I find myself wondering about MQ internal checkpointing, or lock activity type stuff. My thanks to all who take the time to read this, especially if they share their experience with us all. 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
Re: Receiver channel parameters mrrty and mrtmr
Paul, Why such reticence? It answers the question splendidly. The description in the command manual is somewhat light, but Intercommunication is much more detailed. The message retry parameters act like a flood plain when a message consumer is over-loaded, giving it a chance to catch up without a failure by backing up messages in the channel. So the default values make sense, don't impact hard failures and therefore shouldn't be switched off. Many Thanks Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: 17 November 2004 10:18 To: [EMAIL PROTECTED] Subject: Re: Receiver channel parameters mrrty and mrtmr Alan, I'm not sure it answers your question but you seem to indicate that the mesage is retried regardless of the failure. This isn't true, there are only a small number of errors which are considered transitory (and therefore retryable). From memory these are MQRC_PUT_INHIBITED MQRC_RESOURCE_PROBLEM MQRC_STORAGE_NOT_AVAILABLE MQRC_Q_SPACE_NOT_AVAILABLE MQRC_Q_FULL So, in the case you cite where the queue does not exist we would not try and retry and the message would be immediately dumped to the DLQ. Cheers, P. Paul G Clarke WebSphere Messaging Clients IBM Hursley MQSeries List [EMAIL PROTECTED] wrote on 17/11/2004 09:33:37: Hi, We have been asked to justify our decision to let receiving channel message retry count and interval parameters (mrrty and mrtmr) take their default values. These allow (non z/OS) MQ to retry message put failures up to 10 times, one second apart, before writing the message to the dead letter queue. For the obvious reasons (no such queue, expired temporary dynamic queue), there seems little point to the retries, and reasonable concern over possible backlogs following a transient hold-up, e.g. network hitch. To the question - Is anyone aware of sound reasons for keeping the default values as they are? Is there a reasonably common condition that causes a temporary inability to deliver valid messages, that is overcome via the retries? I find myself wondering about MQ internal checkpointing, or lock activity type stuff. My thanks to all who take the time to read this, especially if they share their experience with us all. 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 Instructions for managing your mailing list 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
MQSC client - MO72 Problem (indirect queue manager management)
Hi Paul, Can I report a problem? I find that the facility in mo71 that allows one to manage a queue manager via an intermediary doesn't seem to work in mqsc. Here are the messages, both from a Windows client: --- AIX via AIX from Windows E:\Our Documents\Affinity\Sandpit\spells\mqscTestmqsc -g -m TMQ001 Error connecting to 'TMQ001' RC(2058) QMgr name error. MQSC Ended z/OS via z/OS from Windows -- E:\Our Documents\Affinity\Sandpit\spells\mqscTestmqsc -g -m SMQ2 No reply queue specified Connected to Queue Manager 'SMQ2' SMQ2dis qmgr Error putting to SYSTEM.COMMAND.INPUT RC(2027) Missing reply queue. MQSC Ended --- Both work fine from mqmonntp.exe (MO71) with the same config file. For your edification, I have attached the config file. The facility for indirect queue manager admin is very useful for managing outlying queue managers, not directly addressable over IP from the core systems. I am creating a system (Perl scripts) with the objective of giving us centralized programmable admin. It would be of real use to us to have this facility in mqsc. Is that enough information to whet your appetite? Again, many thanks for your much appreciated sterling efforts. Alan Lovett EDS UK MQMON.CFG Description: Binary data
Re: MQ SupportPack MO02 Compression Exit on Client Channels
Rick and Bill, Many thanks for your responses. I agree with you recommendation (unprompted you agreed with mine!) - use a server because it reduces the message traffic, and gives the channel initiator an opportunity to optimise (i.e. re-block) that traffic when it marshals it over the wire, and it allows _some_ opportunity for tuning. If compressing the client messages doesn't do the business, that is the way we'll go. Cheers, Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Tsujimoto Sent: 05 October 2004 19:06 To: [EMAIL PROTECTED] Subject: Re: MQ SupportPack MO02 Compression Exit on Client Channels Bill, That sounds reasonable, except if there's an app design constraint, e.g. committing DB updates with MQPUTs. Hey Alan, wanna pony up for a server license? MQ-SERIES [EMAIL PROTECTED] CA.COMTo Sent by: MQSeries [EMAIL PROTECTED] List cc [EMAIL PROTECTED] n.AC.AT Subject Re: MQ SupportPack MO02 Compression Exit on Client Channels 10/05/2004 01:51 PM Please respond to MQSeries List [EMAIL PROTECTED] n.AC.AT Rick, I've been resistant about using the client over WAN at my shop. With the Client, every API call causes traffic between the client and the server. (you can see this when watching the status of the client svrconn channel). For each MQI call you have to wait for a round trip communication. Ex. Conn, open, put, close. This would cause 4 round trip communications between client and server. The put would be the big one, including the data for the message. If you use server to server communication over the WAN then there would be (for the most part) one round trip communication, which would be the message itself. What we do is set up HUB servers, where the clients talk over the LAN to the server, and then go server to server over the WAN. MO02 could help however between the servers, depending upon the data and how well it'll compress. anyway, hope that helps Bill [EMAIL PROTECTED] 10/5/2004 11:23:30 AM Rick, Thank you for responding. Indeed, compression might not be a solution. The problem arises because the s/390 is being re-sited, changing the client connections from a happy high capacity LAN to a slower and sadder WAN. The change has pushed up response times beyond the pain threshold. A number of other avenues are being investigated, but the compression exit scores high on 'can we try it and see today?' criteria. My hope is that my request about MO02 clients throws up any gotcha's others wish to share. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Tsujimoto Sent: 05 October 2004 15:59 To: [EMAIL PROTECTED] Subject: Re: MQ SupportPack MO02 Compression Exit on Client Channels Alan, What sort of network problems are you experiencing? Compressing the data may not be a solution. Lovett, Alan J [EMAIL PROTECTED] COM To Sent by: MQSeries [EMAIL PROTECTED] List cc [EMAIL PROTECTED] n.AC.AT Subject MQ SupportPack MO02 Compression Exit on Client Channels 10/05/2004 10:44 AM Please respond to MQSeries List [EMAIL PROTECTED] n.AC.AT Hi, We have a network problem between AIX clients talking to S/390 servers. We are considering using the MO02 compression exit on the server/client connection channels, to reduce network traffic. Does anyone else do this? Any problems we should be aware of? Many thanks for any replies. 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 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available
Re: MQ Trigger Monitor - Load Balancing?
Hi, For the first part, no, MQ can't distribute the workload, but CICSPLEX can. The trigger message gets picked up by whichever CKTI instance MQGETs it first, which in turn initiates a CICS transaction. CICSPLEX will then schedule the CICS transaction to a CICS system, according to its configuration. The second: not as such, but to an equivalent outcome - If one CICS system is dead, only the other system's CKTI is active, so it gets the trigger message. All the above assume that both CICS systems' CKTI's monitor the same MQ initiation queue, and that the MQ and CICS systems are hosted by the same Sysplex member. To get one stage smarter, if your systems are Sysplex'ed, you could consider sharing the initiation and application queue. In this case, a message could be serviced by any CICS system in the plex. However, only consider this after thorough analysis of volumes, message length etc., so as to not break your coupling facility. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of MQA Sent: 05 October 2004 18:12 To: [EMAIL PROTECTED] Subject: MQ Trigger Monitor - Load Balancing? Dear MQA, We are studying on sharing of a single queue manager by multiple CICS regions. If we use CICS trigger monitor (i.e. CTKI), can the trigger monitor distribute workload equally among the two CICS regions? If otherwise, which component (MQ, CICS or else) can govern the workload distribution. Besides, if one of the CICS regions fails, can all the incoming messages be distributed to the remaining one for processing. TIA. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
MQ SupportPack MO02 Compression Exit on Client Channels
Hi, We have a network problem between AIX clients talking to S/390 servers. We are considering using the MO02 compression exit on the server/client connection channels, to reduce network traffic. Does anyone else do this? Any problems we should be aware of? Many thanks for any replies. 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
Re: MQ SupportPack MO02 Compression Exit on Client Channels
Rick, Thank you for responding. Indeed, compression might not be a solution. The problem arises because the s/390 is being re-sited, changing the client connections from a happy high capacity LAN to a slower and sadder WAN. The change has pushed up response times beyond the pain threshold. A number of other avenues are being investigated, but the compression exit scores high on 'can we try it and see today?' criteria. My hope is that my request about MO02 clients throws up any gotcha's others wish to share. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Tsujimoto Sent: 05 October 2004 15:59 To: [EMAIL PROTECTED] Subject: Re: MQ SupportPack MO02 Compression Exit on Client Channels Alan, What sort of network problems are you experiencing? Compressing the data may not be a solution. Lovett, Alan J [EMAIL PROTECTED] COM To Sent by: MQSeries [EMAIL PROTECTED] List cc [EMAIL PROTECTED] n.AC.AT Subject MQ SupportPack MO02 Compression Exit on Client Channels 10/05/2004 10:44 AM Please respond to MQSeries List [EMAIL PROTECTED] n.AC.AT Hi, We have a network problem between AIX clients talking to S/390 servers. We are considering using the MO02 compression exit on the server/client connection channels, to reduce network traffic. Does anyone else do this? Any problems we should be aware of? Many thanks for any replies. 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 Instructions for managing your mailing list 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: MQSC client - MO72
Thanks again Paul. For us, versions for AIX Solaris would be _very_ much appreciated. Cheers, Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: 21 September 2004 16:05 To: [EMAIL PROTECTED] Subject: Re: MQSC client - MO72 Thanks T.Rob, glad to be of service. I forgot to mention in my previous append that since this is a command line program I can generate a version for other platforms than just windows. Does anyone have a need for a version on a unix etc ? Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley MQSeries List [EMAIL PROTECTED] wrote on 21/09/2004 14:34:27: Thanks, Paul! This will be very useful. I wasn't surprised by the numbering though - I figured all along they had reserved a block of Support Pac numbers just for you. ;-) -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Paul Clarke Sent: Tuesday, September 21, 2004 9:01 AM To: [EMAIL PROTECTED] Subject: MQSC client - MO72 As promised, here's a notification that my new SupportPac which allows you to effectively run an MQSC program but as a client into a remote server is live. The SupportPac number is MO72 which is kinda odd cos MO71 is another one of mine I wrote 7 years ago. Here's the link, http://www-1.ibm.com/support/docview.wss? rs=203uid=swg24007769loc=en_UScs=utf-8lang=en 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 Instructions for managing your mailing list 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: MQ Administrator (mo71)
A thought - is your _Windows_ id defined on the Unix System as an MQ admin, i.e. in group mqm? Alan L -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Robert Broderick Sent: 14 September 2004 13:12 To: [EMAIL PROTECTED] Subject: Re: MQ Administrator (mo71) When you click on the CLIENT box what do you have in CONNECTION NAME. You mentioned it as Network Names: 10.68.1.63 (1414) ( this is the ip/port the unix mq ) but not down where you were explaining what was in the Client POP-UP box (ie .on Client configured pop up: I typed SYSTEM.ADMIN.SVRCONN, it always say: please enter a valid value for ...). Also do you have access through the SYSTEM.ADMIN.SVRCONN with the UserId you are running. (This will be the next issue you may (?) hit. bobbee From: Zhang, Yan [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: MQ Administrator (mo71) Date: Mon, 13 Sep 2004 13:20:31 -0400 I try to use the MQ Administrator to manage the queue manager on unix box. I don't have a local queue manager, I would like to set up using the client option. Here is my configuration on the screen: 1. Queue Manager : QM_COVMSG1 ( this is the queue manager on the unix box) 2. QM group: empty 3. Network Names: 10.68.1.63 (1414) ( this is the ip/port the unix mq ) 4. Via QM (empty, as I don't want to use a local q mgr ) 5. Reply Queue: SYSTEM.DEFAULT.MODEL.QUEUE 6. Command Queue: SYSTEM.ADMIN.COMMAND.QUEUE 7.Server queue: (empty) 8.Client : checked 9. on Client configured pop up: I typed SYSTEM.ADMIN.SVRCONN, it always say: please enter a valid value for ... And my q mgr's command server is running. It always give me Error connecting via client to 'QM_COVMSG1' RC(2059) QMgr not available. I have a java program which can connect/put/retrieve messages from the same desk top to the same unix box just fine. Would you please help me out? Thanks you very much! Yan The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/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
WMQ SSL and Microsoft Clusters (MSCS not MQ!)
Hi, Here is something we have bumped into when deploying WMQ SSL onto MSCS clustered Windows servers. We started by deploying our PKCS 12 files to a key repository on a none-shared volume (the default sslkeyr - 'c:\Program Files\IBM\WebSphere MQ\qmgrs\qm\ssl\key'). That worked fine, we then failed over in the cluster and had to re-do the deploy to the backup's local volume. This worked fine too, and subsequent fail-overs worked a treat. So far, so good, but we then made the mistake of trying to be clever... We wanted to deploy the PKI stuff on the active system in such a way that would be picked up upon fail-over, without the hassle of a fail-over. The obvious approach was to locate the key store on a shared volume, i.e. sslkeyr of e:\WebSphere MQ\qmgrs\qm\ssl\key'. We tried that, and deployed the PKI - OK on the active server. We then failed over and tried our SSL channels... oops - no certificate assigned to the queue manager. It would work on the 'backup' system if we wiped the key store and then re-deployed our PKI files, but would then fail when we reverted to the original. The key store has some sort of relationship with the local system - the registry perhaps? Can anyone recommend a technique for sharing a key store across an MSCS cluster without failing over? Many thanks in advance for any suggestions / comments. In the meantime, we have reverted to using local key stores and deploying by install+failover+install - more work but it works! 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
Re: SSL on z/OS and RACF
Hi, Sorry, no direct experience with RACF generated CA sign requests. We have, however, successfully imported PKCS12 files from an OpenSSL environment (on Windows). Is that path open to you? Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Waldenburger, Barbara Sent: 27 April 2004 14:39 To: [EMAIL PROTECTED] Subject: SSL on z/OS and RACF Hi, we are struggling to test MQ with SSL on z/OS with RACF as security server. We have generated an certificate request via RACDCERT command with operand GENREQ. The request is sent to the CA to sign the certificate, but the CA rejects it saying invalid format; the tool used is OPENSSL. With openssl req -text -noauth -in (request) we see, that the certificate request contains no attributes. Does anybody know how to set the attributes on z/OS with RACF? We cannot find any documentation on this. Has anybody running MQ with SSL on z/OS? Any help is greatly appreciated. Barbara Instructions for managing your mailing list 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: SSL and certificate expiry
Hi, I can't (won't!) answer the first question, beyond that root certificates should last an order of magnitude longer than end-users. If you have a number of queue managers, managing them with self-signed certificates can become a nightmare. To add/renew one certificate would then require you to change every connected queue manager's key repository. The best way forward is to introduce a Certificate Authority. It is well worth putting in the effort to become familiar with PKI. OpenSSL (www.openssl.org) is a good open resource for playing with PKI/SSL. You can then introduce a CA and its root PKI certificate. Each key repository then needs its queue managers key pair and certificate plus a copy of the root certificate. With a CA, adding a queue manager, or replacing an end-user certificate, involves changes to only its key repository. Other queue managers will accept the new certificate, because it has been signed by the CA. When the CA time is up (or at least 6 months before), you will need to create a new CA, and distribute its root certificate across all the participating queue managers. Once they all know about the new CA, you can then begin replacing queue manager keys certificates, one at a time. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence Coombs Sent: 23 April 2004 17:54 To: [EMAIL PROTECTED] Subject: Re: SSL and certificate expiry Anyone care to share the lifetime they assign to a certificate used by a queue manager that has SSL channels? Also, how do you handle certificates expiring when a OS/390 queue manager communicates with many distributed queue managers? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: TCP/IP errors
Hi, Obviously, I don't know your system, but on ours whenever we get odd IP errors, the word 'Firewall' springs to mind. Another point, can other clients connect? IMHO, the first test for a client connection should be (unless the server is z/OS) over localhost, using env vars and the simplest program possible, i.e. amqsputc. Then move out to a remote box, again using env vars and amqsputc. You then know for sure that the client channel works. You can then start layering on channel connection tables, JMS, SSL or whatever. Regards, Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Bharath Ram Srinivasan Sent: 23 March 2004 09:53 To: [EMAIL PROTECTED] Subject: TCP/IP errors Hi, We have an issue with one of our NT Boxes. We are running WMQ 5.3 in this machine. Our Client is trying to connect to this machine through his sender channel. Although the listener and queue mgrs at my end are up running, the msg doesn't reach me. The MQ error log at sender end suggests that this might be a TCP/IP error or the listener must be down. But I am pretty sure that the listeners are up. How do I resolve this TCP/IP error? Alternately, if I decide to give up this Port (assuming it had some trouble) and allocate a new port for communication how could I make sure that this port would work before making the MQ connectivity change. Please help me out with this. Best Regards, Bharath Instructions for managing your mailing list 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
Hi, First of all, many thanks to all who responded. It is always good to know that you are not alone! As regards our problem, we now know for certain that the messages were non-persistent. They all disappeared following a scheduled re-start of the system! Our developers are hurriedly changing their code to force persistence. I have re-discovered the MS0G SupportPack (http://www-3.ibm.com/software/ts/mqseries/txppacs/ms0g.html). It promises to be very useful. It should provide the insight we need when (if?) the problem re-appears. I can hardly wait ;-) 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
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
Re: Fish outa water
A few points: 1) The client server feature on S/390 is indeed chargeable. 2) Client programs can (and should!) do their stuff inside a recoverable unit of work. So synchronisation shouldn't be a problem, or at least no more than with local bindings. 3) The assertions on security leave out the possibility of altering objects with MQI commands, which can be sent over sender/receiver channels. If that is a problem, you have a problem regardless of the connection type. Regards, Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt, T. Rob Sent: 30 January 2004 21:59 To: [EMAIL PROTECTED] Subject: Re: Fish outa water Jerry, There are several JMS providers in addition to WMQ but none, that I know of anyway, that will pull WMQ messages out of the mainframe. Now, the manager in question may be referring to the ability of WMQ JMS to run over a client connection to connect to the mainframe. This would in fact be free for the Solaris machine but I'm not sure if the Mainframe client connect feature is a licensed component. Someone else on the list is sure to answer that one. In any case, migration to a client when you've already invested in the MQ Server is questionable. The client introduces a few new issues you will need to deal with. First of all, you will be using a synchronous connection to talk with an agent at the QMgr which then talks to MQ. If the connection breaks in between issuance of an API call (GET, PUT, COMMIT, etc.) you have no way of knowing whether the call was successful or not. To deal with this, your application needs to have some way of recovering state after a broken connection. The other issue is security. A server-to-server channel will never do anything other than deliver messages. A client-to-server channel has the ability to alter WMQ objects and, in its default configuration, send PCF messages to the MQ command server. To secure the channel, you will need to use SSL or a channel exit and set the MCAUSER at the mainframe side. It seems like this is a lot of effort to go through in order to save a few thousand dollars on an application that, based on your email, isn't broken. -- T.Rob -Original Message- From: Cergol, Jerry [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 3:19 PM To: [EMAIL PROTECTED] Subject: Fish outa water I've been running WMQ for z/OS 5.3 on my IBM Mainframe and sending relatively medium-size and moderately frequent persistent messages outbound to a Sun Solaris running WMQ 5.3. The Sun Solaris manager wants to jetison WMQ altogether because it is expensive relative to its utilization. He mentioned a publish/subscribe type architecture what would use Java Messaging Services on the Sun/Solaris to pull data over from z/OS WMQ. I've been implementing and maintaining WMQ on both the mainframe and the Sun but, being strictly limited to dealing with IBM z/OS components, I have no clue as to where to start to get a handle on the requirements for a JMS-WMQ design. Can anyone point me at a manual or reference as a starting point? Thanks in advance. Jerry Cergol Cleveland Clinic Foundation IBM Mainframe System Support -- Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. 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 Instructions for managing your mailing list 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 Getting and Putting!
Dream on Herbert, but avoid dreaming about locks, and guaranteed _once_ only delivery! Regards, Alan Alan Lovett [mailto: [EMAIL PROTECTED] * +44 (01253) 6 88311 Mob.* +44 (07768) 210500 Fax * +44 (01253) 6 88156 E* [EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: 29 January 2004 08:01 To: [EMAIL PROTECTED] Subject: AW: Cluster Getting and Putting! Hi Alan, I agree, it is just an idea, how shared queues may eventually be realized in the far future on a system other than S/390. I know, that nothing similar to a coupling facility exists at the moment for AIX or other Unix boxes. Concurrent cluster means only, that disks may be shared between to or more boxes and are accessible at the same time (using raw devices, not file systems I think). Using such disk space instead of shared memory (shared between several servers) would be not very fast, but maybe it could work (let me have a dream ;-) ). To my mind, the main advantage of clustering is the simplifying of MQ administration. That means, you need not to define remote queues or every channel connection manually - clustering takes over these actions. Load balancing and fail-over are more or less side-effects, but not to compare with workload management on mainframes and fail-over mechanisms like SYSPLEX or HACMP. But the tracing of message flow becomes not easier at all by using MQ clustering. Regards Hubert -Ursprungliche Nachricht- Von: Lovett, Alan J [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 28. Januar 2004 14:20 An: [EMAIL PROTECTED] Betreff: Re: Cluster Getting and Putting! Hi, Neither am I, but s/390 queue sharing relies on its coupling facility (a mix of shared memory, custom hardware and layers of fancy software) to host the queues and manage the locks. As far as I am aware, HACMP 'only' shares disk arrays and network connections. Don't expect queue sharing on AIX without some mechanism for shared memory. In the future, anything might happen, but queue sharing on non-s390 platforms is _very_ unlikely in the forseeable future (IMHO). Regards, Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: 28 January 2004 10:48 To: [EMAIL PROTECTED] Subject: AW: Cluster Getting and Putting! Hi Sid, I am not an IBMer, but what you mean is what I know as shared queues. They are available since MQ 5.2 - unfortunately only on mainframes. You need something like memory or disks, shared to several systems. Maybe concurrent cluster on HACMP could be a solution (sometime in the future)? Regards Hubert -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 28. Januar 2004 07:13 An: [EMAIL PROTECTED] Betreff: Cluster Getting and Putting! Howdy All, This question is really only directed to members of the list who are with IBM. If putting to a cluster is global and gets are local, is it likely to change in the future so that gets are global if only one instance of a cluster queue exists in the cluster? Sid Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list 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: T-Rex distributed systems
Hi Dave, If your queue managers are defined in queue sharing groups, your MQCONN can be to the group name (e.g. M000). It doesn't matter if your application doesn't use any shared queues. Connecting to the group automatically connects you to the local queue manager. Jobs can thus run on any member of the sysplex. However, if you aren't into QSG's, other solutions are likely to be easier. Regards, Alan -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Adiraju, RaoSent: 29 January 2004 21:41To: [EMAIL PROTECTED]Subject: Re: T-Rex distributed systems Luckily on z/OS only batch jobs/applications need to establish theconnections to the Queue Managers (in CICS it's done at the CICS region level) and hence the need to know the QMGR name. This as suggested earlier, can be driven by a Dataset / Loadmodule or DB2 table. The sites thatI have worked in the past are either put their QMGR names in a DB2 table (DB2 subsystem switching is done at the JCL level anyway) or put in a QSAM file and every MQ program is supposed to read a file using a standard DD name that provides the QMGR name. When the code gets migrated through SCLM phases, it used to pick up the appropriate subsystem or QSAM qualifiers for the environment. Regarding security, it was controlled by RACF / ACF2. Because most of the sites I have worked, batch user-ids in production are different from other environments including stress testing. Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 10:05 AMTo: [EMAIL PROTECTED]Subject: Re: T-Rex distributed systems I must not be explaining this right our production QMGR's are on another pair of ZOS images and are called P001 and P002 our test machine has 2 cloned QMGR's that replicate production on a different pair of ZOS images D001 and D002 our development brainstorming test QMGR's are on the same pair of test machine QMGR's and they are called M001 and M002 SYSPlex Distributor will put the iteration on one of the pairs (M001 or M002) the program has to determine on which ZOS image it is running to do the MQCONNDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark. A large group of professionals built the Titanic-- Rick Tsujimoto [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 01/29/2004 02:15 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:Re: T-Rex distributed systemsDave,Two things:1. The apps should probably be getting the queue manager name form someexternal source, e.g. file, table, etc.2. Test apps that attempt to connect to prod queue managers should probablybe stopped by your security system, e.g. RACF, ACF2, ... Dave Adam [EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM cc: Sent by: Subject: Re: T-Rex distributed systems MQSeries List [EMAIL PROTECTED] en.AC.AT 01/29/2004 02:51 PM Please respond to MQSeries Listthe issue is with the playground M00n QMGR'sif they fail to identify the M, then they will be in the clones ofproductionDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark.A large group of professionals built the Titanic-- Rick Tsujimoto [EMAIL PROTECTED] To: Sent by: MQSeries List [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Subject: Re: T-Rex distributed systems 01/29/2004 01:30 PM Please respond to MQSeries ListIf you simply want to connect to the default QMGR on each LPAR, you couldgenrate the load module that defines the default queue manager and add thatlibrary to the application's STEPLIB. Dave Adam [EMAIL PROTECTED] To:[EMAIL PROTECTED] ERVALU.COM cc: Sent by: Subject: Re: T-Rexdistributed systems MQSeries List [EMAIL PROTECTED] en.AC.AT 01/29/2004 02:19 PM Please respond to MQSeries Listhere would be a simplistic view of the 2 LPAR'sLPAR D001 D002QMGR's (1)
Re: Cluster Getting and Putting!
Hi, Neither am I, but s/390 queue sharing relies on its coupling facility (a mix of shared memory, custom hardware and layers of fancy software) to host the queues and manage the locks. As far as I am aware, HACMP 'only' shares disk arrays and network connections. Don't expect queue sharing on AIX without some mechanism for shared memory. In the future, anything might happen, but queue sharing on non-s390 platforms is _very_ unlikely in the forseeable future (IMHO). Regards, Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: 28 January 2004 10:48 To: [EMAIL PROTECTED] Subject: AW: Cluster Getting and Putting! Hi Sid, I am not an IBMer, but what you mean is what I know as shared queues. They are available since MQ 5.2 - unfortunately only on mainframes. You need something like memory or disks, shared to several systems. Maybe concurrent cluster on HACMP could be a solution (sometime in the future)? Regards Hubert -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 28. Januar 2004 07:13 An: [EMAIL PROTECTED] Betreff: Cluster Getting and Putting! Howdy All, This question is really only directed to members of the list who are with IBM. If putting to a cluster is global and gets are local, is it likely to change in the future so that gets are global if only one instance of a cluster queue exists in the cluster? Sid Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Is WMQ SSL Bleeding Edge?
Hi, We administer a non-trivial number of WMQ queue managers, across a mixture of z/OS, Unix Windows platforms. We are contemplating using WMQ SSL to secure the (intranet) WMQ traffic. We would be grateful for feedback from its users, concerning their confidence in it. Do people think it ready for extensive / exclusive use? Many thanks, in anticipation of your replies. Regards, Alan Lovett Instructions for managing your mailing list 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: Support for MQ5.2
Title: Support for MQ5.2 Not confirm, but I do share that interpretation of the statements on www.ibm.com. Regards, Alan Lovett -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Voges, P. (Pieter)Sent: 26 November 2003 04:52To: [EMAIL PROTECTED]Subject: Support for MQ5.2 The question of support for different MQ releases and the dates on which it is dropped have been asked so many times that I will be surprised if anybody responds to this. The problem is that the dates I get from IBM locally, the dates I see on IBM's international website and the dates people mention on this list differs. As I am working for a major bank in South Africa and are tasked to insure that we are always running on a supported version I really need some clear answers on this. According to my latest info support for 5.2 on the distributed platforms end on December 31, 2003 and on OS/390 the date is April 30, 2004. Can anybody confirm this PLEASE... Thank you Pieter Voges MQ Support Nedcor Limited Tel: (011) 881 4410 Sel: 083 6455 300 E-mail: [EMAIL PROTECTED] http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter This email and any accompanying attachments may contain confidential and proprietary information. This information is private and protected by law and, accordingly, if you are not the intended recipient, you are requested to delete this entire communication immediately and are notified that any disclosure, copying or distribution of or taking any action based on this information is prohibited. Emails cannot be guaranteed to be secure or free of errors or viruses. The sender does not accept any liability or responsibility for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interference with any of the information contained in this email or for its incorrect delivery or non-delivery for whatsoever reason or for its effect on any electronic device of the recipient. If verification of this email or any attachment is required, please request a hard-copy version.
