Re: Buffer pool storage
Yes, it's in the MSTR and it's above the line private storage. There should be plenty of that to go around :) John M Hammond Data Center - Middleware (630) 521-4339 Ronald Weinger [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Sent by: MQSeries Subject: Buffer pool storage List [EMAIL PROTECTED] .AT 05/10/2004 09:45 AM Please respond to MQSeries List Does anyone know where in z/OS the bufferpool storage is allocated? Is is within the MQ Master address space? The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete 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
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
Re: MQCIH Data conversion
David, When we send a request up to the mainframe with a CIH, the reply comes back with one. We need to keep the CIH because we use different CKPB tranids for different applications. From the sound of the other replies it looks like we might just have to roll our own. Gr. John John M Hammond Data Center: Middleware Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 David C. Partridge [EMAIL PROTECTED] To:[EMAIL PROTECTED] EUR.COM cc: Sent by: MQSeries Subject: Re: MQCIH Data conversion List [EMAIL PROTECTED] .AT 10/07/2003 09:02 AM Please respond to MQSeries List As far as I know the MQCIH is only used by the CICS bridge code on 390, and the only reason that its a supported format on the other platforms is so that they can SEND messages to a 390 system running the CICS bridge. So, why do you want or need to convert an MQCIH to local encoding and character set representation on the distributed platform? Is this a broker related thing? Cheers, Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of John M Hammond Sent: 07 October 2003 13:32 To: [EMAIL PROTECTED] Subject: MQCIH Data conversion I just discovered (to my astonishment) that IBM does not support data conversion on the MQCIH on distributed platforms. We're raising a request to get this corrected but that will clearly take time. Is anyone aware of a Vendor product that can do the necessary conversion (on Solaris specifically). I'm also looking into building my own data conversion exit, but was hoping to find something ready to go without me doing much work :-) We currently use CONVERT(YES) on our sender channels out of the mainframe, but want to move away from it. Thanks, John John M Hammond Data Center: Middleware Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Instructions for managing your mailing list 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
MQCIH Data conversion
I just discovered (to my astonishment) that IBM does not support data conversion on the MQCIH on distributed platforms. We're raising a request to get this corrected but that will clearly take time. Is anyone aware of a Vendor product that can do the necessary conversion (on Solaris specifically). I'm also looking into building my own data conversion exit, but was hoping to find something ready to go without me doing much work :-) We currently use CONVERT(YES) on our sender channels out of the mainframe, but want to move away from it. Thanks, John John M Hammond Data Center: Middleware Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Instructions for managing your mailing list 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 question - (SYSTEM.CLUSTER.REPOSITORY.QUEUE)
I'm not IBM but I used to be The SYSTEM.CLUSTER.REPOSITORY.QUEUE queue contains everything MQ needs to know in order to manage clusters successfully. There will always be at least one message on it. The top 'RFQR' message contains information relating to the local queue manager and is usually filled with blanks. This message is always there, even when you are not using cluster objects. Subsequent messages relate to specific cluster objects that exists within a cluster. As you define new objects you'll see the depth of the queue increase. Occasionally MQ will rewrite the entire queue and compact the data and thus reduce the number of messages. You might have a couple of hundred messages on the queue one, day and then 3 messages on it the next - this is normal! The formats of these messages are all internal and (I can say from experience) are fairly complicated. I would not recommend anybody attempting to decode them. I was also strongly discourage anybody from tampering with the messages on this queue. I updated the queue manually many times in testing support tools and the results were not pretty at the best of times. In short: - Messages on the queue are normal - Don't touch them :-) John John M Hammond Data Center: Middleware Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Wood, Dan [EMAIL PROTECTED] To:[EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Re: Cluster question - (SYSTEM.CLUSTER.REPOSITORY.QUEUE) [EMAIL PROTECTED] .AT 09/08/2003 08:58 AM Please respond to MQSeries List Shows how far behind I am with my listserv messages. DONT DELETE ANYTHING and DON'T ASK QUESTIONS! I'm surprised IBM didn't respond to your question... Dan L Wood AIT - Enterprise Application Integration [EMAIL PROTECTED] 319-896-6985 -Original Message- From: Mike Davidson [SMTP:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 7:17 AM To: [EMAIL PROTECTED] Subject: Re: Cluster question - (SYSTEM.CLUSTER.REPOSITORY.QUEUE) Neil, Thanks for the response. I agree with you that the SYSTEM.CLUSTER.REPOSITORY.QUEUE is not the place to be poking around. I was just curious as to why initially this queue has a couple of base messages in there. If this is normal, I'm cool with it. Mike Davidson TSYS MQ Tech Support [EMAIL PROTECTED] Neil Casey [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 08/05/2003 07:56 PM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:Re: Cluster question - (SYSTEM.CLUSTER.REPOSITORY.QUEUE) Mike, you're a brave man. The SYSTEM.CLUSTER.REPOSITORY.QUEUE is where MQ saves away any information which relates to clusters. Some of it is easily rebuilt, and some of it is pretty critical, especially if your queue manager is a full repository. You should always expect to find messages on this queue if anything relating to clusters has been defined. These messages are not something that I would be deleting personally (unless directed by IBM support - I have had that happen once at v2.1 on zOS). MQ5.3 now has substantially more ability to manage the cluster repository than earlier versions, with extensions to the cluster commands. I would never want to play with the repository directly. It's asking for trouble. I can't answer the question of what the specific messages represent. We had a similar discussion recently about transmission headers on channels, and got the answer from IBM that internal messages formats are internal (and private) for a reason. If the formats are known, someone will depend on them, and then when IBM change them to privide new function or to fix a problem, someone elses code breaks. This makes IBM look bad, even though the third party is at fault for relying on a non-documented interface. Regards, Neil Casey. |-+ | | Mike Davidson| | | [EMAIL PROTECTED]| | | M | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | n.AC.AT | | || | || | | 06/08/2003 03:40 | | | Please respond to| | | MQSeries List| | || |-+ - -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Cluster
John M Hammond/US/Household is out of the office.
I will be out of the office starting 02/08/2003 and will not return until 02/17/2003. I will have limited access to my email. Please contact Bozena Kalita with any ugent issues. Instructions for managing your mailing list 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: Mainframe Security
Almost! The client attach facility 'ignores' the RESLEVEL of the MCAUSER id. It honours the RESLEVEL of the CHINIT userid. If the CHINIT has ALTER to RESLEVEL no checking of clients will be done. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Miller, Dennis [EMAIL PROTECTED] To:[EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Re: Mainframe Security [EMAIL PROTECTED] .AT 01/10/2003 10:52 AM Please respond to MQSeries List To paraphrase, you're saying that the client attach feature basically ignores RESLEVEL. That's what I didn't understand. I do now. Thanks. -Original Message- From: John M Hammond [SMTP:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:21 PM To: [EMAIL PROTECTED] Subject: Re: Mainframe Security Dennis, The problem I'm having is not to do with the actual userid being used for the security checks. The problem is that when a user has RESLEVEL access, their MQ authority is different when they are connected as a client when compared to them connected as batch. It sounds like there is no easy way around that problem :-( I'll just have to make updates to the RACF profiles and grant explicit access to all of the queues (I'll probably revoke the RESLEVEL access at the same time). John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Miller, Dennis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Re: Mainframe Security [EMAIL PROTECTED] .AT 01/09/2003 10:57 AM Please respond to MQSeries List What version of the client are you using? I think about V5.1 they made a change so that the userid BOB at the client is used for the attachment to the qmgr if you set MCAUSER to blanks. -Original Message- From: John M Hammond [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 12:46 PM To: [EMAIL PROTECTED] Subject: Re: Mainframe Security I have a userid, say BOB. BOB has ALTER access to the ssid.RESLEVEL profile, so after BOB's (batch) connect, BOB can access any queues without needing to be granted access to any more profiles (with the exception of the csqorexx and csqutil queues). This is cool, because BOB is often debugging problems and needs to look at the data in queues. This allows him to do so without the burden of defining explicit access to all of the profiles in the MQQUEUE class. If BOB connects as a client, then he does not have this access to queues. I presume this is because the adapter within the CHINIT is managing the connection to the queue manager and there is no real connect done BOBs behalf. I could grant RESLEVEL access to the CHINIT userid to get around this, but this would affect all MQ access through the chinit which is bad. I'm looking for a way to allow BOB to client connect and access all queues without needing to grant access to every profile in the MQQUEUE class. In ACF2 it is possible to define a generic rule that allows BOB to access anything, but I can't find a way of doing the same through RACF. At the end of the day, I'm just being lazy and trying to give my administrators access to all of the data without needing to define the access manually in the profiles. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Miller, Dennis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Re: Mainframe Security [EMAIL PROTECTED] .AT 01/08/2003 01:29 PM Please respond to MQSeries List What do you mean by RESLEVEL does not extend to connected clients? -Original Message- From: John M Hammond [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 9:18 AM To: [EMAIL PROTECTED] Subject: Mainframe Security I think I know the answer to this, but I'll ask anyway. My MQ admin RACF group has been given RESLEVEL
Re: Mainframe Security
Morag, That's exactly what I thought I was going to end up doing. I was just hoping there was a clever trick to help me avoid step 4. Thanks, John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Morag Hughson [EMAIL PROTECTED] To:[EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Re: Mainframe Security [EMAIL PROTECTED] .AT 01/09/2003 04:27 AM Please respond to MQSeries List John, The path of least resistance is probably to do the following. 1) Create a server-conn channel that only your lazy administrators are going to use (only way to be sure of this is to write a security exit or use SSL however, so this bit is not so lazy!) 2) Set PUTAUT to ONLYMCA 3) Set the MCAUserID to FRED 4) Give FRED access to all resources required. There is no easy way to set up security over clients, which is a good thing - you don't want any Tom, Bob or Fred accessing your resources, but this way means anyone using this client channel, regardless of their user ID can access what FRED has access to and saves you some work in granting access to many other user IDs. Cheers Morag Morag Hughson WebSphere MQ for z/OS Development Internet: [EMAIL PROTECTED] John M Hammond jmhammond@HOUSEHTo: [EMAIL PROTECTED] OLD.COM cc: Sent by: MQSeriesSubject: Re: Mainframe Security List MQSERIES@AKH-WIE N.AC.AT 08/01/2003 20:46 Please respond to MQSeries List I have a userid, say BOB. BOB has ALTER access to the ssid.RESLEVEL profile, so after BOB's (batch) connect, BOB can access any queues without needing to be granted access to any more profiles (with the exception of the csqorexx and csqutil queues). This is cool, because BOB is often debugging problems and needs to look at the data in queues. This allows him to do so without the burden of defining explicit access to all of the profiles in the MQQUEUE class. If BOB connects as a client, then he does not have this access to queues. I presume this is because the adapter within the CHINIT is managing the connection to the queue manager and there is no real connect done BOBs behalf. I could grant RESLEVEL access to the CHINIT userid to get around this, but this would affect all MQ access through the chinit which is bad. I'm looking for a way to allow BOB to client connect and access all queues without needing to grant access to every profile in the MQQUEUE class. In ACF2 it is possible to define a generic rule that allows BOB to access anything, but I can't find a way of doing the same through RACF. At the end of the day, I'm just being lazy and trying to give my administrators access to all of the data without needing to define the access manually in the profiles. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Miller, Dennis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Re: Mainframe Security [EMAIL PROTECTED] .AT 01/08/2003 01:29 PM Please respond to MQSeries List What do you mean by RESLEVEL does not extend to connected clients? -Original Message- From: John M Hammond [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 9:18 AM To: [EMAIL PROTECTED] Subject: Mainframe Security I think I know the answer to this, but I'll ask anyway. My MQ admin RACF group has been given RESLEVEL access. This was done to ensure we can always access queues, as well as making the RACF definitions somewhat cleaner. This is working very well for us. Now a few of the group have started using MO71 to access mainframe queues, and are having problems as RESLEVEL access doesn't extend to connected clients. Is there a clever trick I can use to give a user access to all queues when connected as a client? I'm not going to give RESLEVEL access to the CHINIT address space as this will affect everybody, but I also don't want to go through all the queue profiles and give access to the group if I can help it. Is there a RACF option that could allow this? (I know I had done something similar in the past with ACF2) Any suggestions appreciated
Re: Mainframe Security
Dennis, The problem I'm having is not to do with the actual userid being used for the security checks. The problem is that when a user has RESLEVEL access, their MQ authority is different when they are connected as a client when compared to them connected as batch. It sounds like there is no easy way around that problem :-( I'll just have to make updates to the RACF profiles and grant explicit access to all of the queues (I'll probably revoke the RESLEVEL access at the same time). John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Miller, Dennis [EMAIL PROTECTED] To:[EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Re: Mainframe Security [EMAIL PROTECTED] .AT 01/09/2003 10:57 AM Please respond to MQSeries List What version of the client are you using? I think about V5.1 they made a change so that the userid BOB at the client is used for the attachment to the qmgr if you set MCAUSER to blanks. -Original Message- From: John M Hammond [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 12:46 PM To: [EMAIL PROTECTED] Subject: Re: Mainframe Security I have a userid, say BOB. BOB has ALTER access to the ssid.RESLEVEL profile, so after BOB's (batch) connect, BOB can access any queues without needing to be granted access to any more profiles (with the exception of the csqorexx and csqutil queues). This is cool, because BOB is often debugging problems and needs to look at the data in queues. This allows him to do so without the burden of defining explicit access to all of the profiles in the MQQUEUE class. If BOB connects as a client, then he does not have this access to queues. I presume this is because the adapter within the CHINIT is managing the connection to the queue manager and there is no real connect done BOBs behalf. I could grant RESLEVEL access to the CHINIT userid to get around this, but this would affect all MQ access through the chinit which is bad. I'm looking for a way to allow BOB to client connect and access all queues without needing to grant access to every profile in the MQQUEUE class. In ACF2 it is possible to define a generic rule that allows BOB to access anything, but I can't find a way of doing the same through RACF. At the end of the day, I'm just being lazy and trying to give my administrators access to all of the data without needing to define the access manually in the profiles. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Miller, Dennis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Re: Mainframe Security [EMAIL PROTECTED] .AT 01/08/2003 01:29 PM Please respond to MQSeries List What do you mean by RESLEVEL does not extend to connected clients? -Original Message- From: John M Hammond [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 9:18 AM To: [EMAIL PROTECTED] Subject: Mainframe Security I think I know the answer to this, but I'll ask anyway. My MQ admin RACF group has been given RESLEVEL access. This was done to ensure we can always access queues, as well as making the RACF definitions somewhat cleaner. This is working very well for us. Now a few of the group have started using MO71 to access mainframe queues, and are having problems as RESLEVEL access doesn't extend to connected clients. Is there a clever trick I can use to give a user access to all queues when connected as a client? I'm not going to give RESLEVEL access to the CHINIT address space as this will affect everybody, but I also don't want to go through all the queue profiles and give access to the group if I can help it. Is there a RACF option that could allow this? (I know I had done something similar in the past with ACF2) Any suggestions appreciated, John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Instructions for managing your mailing list 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
Re: Clustered Difficulties - Repository Manager.
What maintenance level is the OS/390 MQ at? This sounds like an old problem - have a look on IBMLINK. If it's only 6 months old and you installed the latest CUM tape 6 months ago I would have thought you'd be okay. If you are at a recent maintenance level for MQ, then you should probably take this up with IBM. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Andrew Gardner [EMAIL PROTECTED]To:[EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: Clustered Difficulties - Repository Manager. [EMAIL PROTECTED] .AT 11/27/2002 05:22 AM Please respond to MQSeries List Hi all, A client's cluster consists of 4 x Back-end AIX servers and 2 x OS/390 LPARS. The AIX servers are running MQSeries V5.2 CSD4 and on OS390 it MQSeries V2.1. They are all part of the same cluster and which was set up some time ago (maybe 6 months) and left idle until the client was ready to use it. Both OS/390 systems host repositories and one of the AIX systems does as well. At some stage, one of the clustered OS390 MQSeries is having trouble synchronising its repository with the rest of the cluster, leaving behind a bit of a mess: Now some of the SYSTEM Queues look like this: Name Depth Get In Put Out SYSTEM.ADMIN.CHANNEL.EVENT 0Y 1 Y 0 SYSTEM.ADMIN.PERFM.EVENT 0Y 1 Y 0 SYSTEM.ADMIN.QMGR.EVENT2Y 1 Y 0 SYSTEM.CHANNEL.COMMAND 0Y 0 Y 0 SYSTEM.CHANNEL.INITQ 0Y 1 Y 0 SYSTEM.CHANNEL.REPLY.INFO 4Y 0 Y 0 SYSTEM.CHANNEL.SEQNO 1Y 0 Y 0 SYSTEM.CHANNEL.SYNCQ 63 Y 5 Y 5 SYSTEM.CLUSTER.COMMAND.QUEUE 159 N 0 Y 0 SYSTEM.CLUSTER.REPOSITORY.QUEUE2Y 0 Y 0 SYSTEM.CLUSTER.TRANSMIT.QUEUE 11 Y 3 Y 3 SYSTEM.COMMAND.INPUT 0Y 1 Y 2 Now the Qmgr is complaining that it is unable to GET from SYSTEM.CLUSTER.COMMAND.QUEUE which is correct since it's not GET enabled for some reason. On making this GET enabled, the MQSeries log is showing these messages: (with my annotations) +CSQX038E MQH7 CSQXCRPS Unable to put message to SYSTEM.COMMAND.INPUT, MQCC=2 MQRC=2030 [Message too big for Queue] +CSQX449I MQH7 CSQXREPO Repository manager restarted +CSQX514E MQH7 CSQXREPO Channel TO.MQCNPRD6 is active +CSQX514E MQH7 CSQXREPO Channel TO.MQH4 is active +CSQX038E MQH7 CSQXREPO Unable to put message to SYSTEM.CLUSTER.TRANSMIT.QUEUE, MQCC=2 MQRC=2013 [Expiry field in the message descriptor MQMD is not valid on MQPUT(1)] +CSQX411I MQH7 CSQXREPO Repository manager stopped Any suggestions on how to recover this repository Qmgr ? ps. this is an old and PRODUCTION qmgr, so only gentle suggestions please ! regards, Andrew Instructions for managing your mailing list 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: Repository queue
T.Rob, As Stefan said, the queue format is not described in any external documentation - even with the documentation its a chore to look through! If you are looking to gain a better understanding of the underlying structure to your cluster, the distributed platforms have a utility 'amqrfdm' that prints out the information in a queue manager's local repository (the data on the queue is simply a hardened version of that information). If you're on 390 then you can take a dump of the channel initiator address space and run the IBM supplied dump formatter on it to retrieve the same information. I would also reiterate what Stefan said. Don't start deleting things from the SYSTEM.CLUSTER.* queues, bad times will surely follow ;-) Have fun! John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Wyatt, T. Rob t.rob.wyatt@BANKOFAM To:[EMAIL PROTECTED] ERICA.COM cc: Sent by: MQSeries Subject: Repository queue List [EMAIL PROTECTED] .AT 11/07/2002 02:12 PM Please respond to MQSeries List Are there any docs (official or otherwise) for the Repository Queue message formats? The cluster utilities pack seems to manipulate these queues directly, as does MQ Explorer. Various people on the list have also mentioned direct manipulation of these messages for cluster management so I'm guessing some of you have already broken ground on this. We have a cluster caged up in our lab and I'd like to perform some experiments on it. 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
Solaris SVRCONN Channel Initiation
Hi All, I'm looking into a problem involving long waits on a SVRCONN channel. I'm comparing a TCP packet trace and an MQ trace of the channel process and I have a question about how the process is initiated. In the packet trace I see the socket open and the first few MQ exchanges. The first MQ data I see is data coming up from the client, and contains the channel name. The response back to the client contains the channel and queue manager name. So far so good! What I find strange is that the amqcrsta trace does not seem to receive that first packet of data from the client. It's first TCP activity is the send of the response. I am wondering what initiation layer is in the middle of this that manages to consume the first packet of MQ data and pass the correct connection information on to the channel process? It sounds to me like the behaviour you might expect from the listener, but we are using inetd. If I saw both packets of data in the MQ trace then I'd quite happily blame inetd or Solaris for simply being slow to schedule the process. The reason this concerns me is that there is a 4 second delay between the inbound packet and the outbound packet which I can't explain (amqcrsta runs for less than 1 second). If anyone has any suggestions I'd be happy to hear them. Hopefully it's something basic I'm missing (I'm fairly new to Solaris). Thanks, John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Instructions for managing your mailing list 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: Recovery procedure for Clustered Queue Managers
Leon, I didn't keep your original email, but in the scenario you describe below there shouldn't be a problem with messages stuck on the SYSTEM.CLUSTER.TRANSMIT.QUEUE. When the system comes up on the new hardware, it is effectively the same queue manager and therefore all outbound communications should be able to continue. Inbound channels will not start because of the IP address change, but altering your cluster receiver channel and adding the new connection name should sort that out. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Leon Grey To:[EMAIL PROTECTED] [EMAIL PROTECTED] cc: UKSubject:Recovery procedure for Clustered Queue Managers Sent by: MQSeries List MQSERIES@AKH-Wie n.AC.AT 07/02/2002 07:30 AM Please respond to MQSeries List Thanks Ferenc for the reply. Yes, a Hardware Cluster of some sort will ressolve this problem. We have opted against using Hardware Clustering. I want to identify a way of alleviating the risk of loss of data when a hardware failure occurs on a cluster qm node. At present we will have the queue manager variables [/qmgrs and /logs] on a shared RAIDed drive, so that the queue manager can be brought up on a different hardware when failure occurs. Within a clustered environment I forsee several problems with doing this. The biggest is the IP address of the newly regenerated cluster queue manager and its expected ip address in the repository. Given this scenario, and the one described in the original email, what can i do to free up the messages that could potentially be marooned on the SYSTEM.CLUSTER.TRANSMIT.QUEUE. All comments are appreciated. Leon __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com Instructions for managing your mailing list 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: Clustering and changing qmgrs.
Bill, I probably should have explained a little further Cluster queue managers communicate using the UUID to uniquely identify specific queue managers. If you were to simply delete the old queue manager and recreate the new one they will have different UUIDs and therefore cluster communications will become problematic. I know there have been some fixes in this area to allow for better handling of this situation, but personally I wouldn't take the chance. If I was trying to replace a cluster queue manager with another of the same name I would always completely remove the queue manager before introducing it's replacement. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Conklin, To:[EMAIL PROTECTED] William cc: [EMAIL PROTECTED] Subject:Re: Clustering and changing qmgrs. RG Sent by: MQSeries List MQSERIES@AKH-Wie n.AC.AT 06/24/2002 04:43 PM Please respond to MQSeries List John, Thanks John, let me clarify something. When the process is complete there will not be duplicate names. The current production system will be replaced with a new production system with the same name. The only difference is connection name. Thanks Bill C. -Original Message- From: John M Hammond [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 4:28 PM To: [EMAIL PROTECTED] Subject: Re: Clustering and changing qmgrs. Bill, If I were you I would remove the first queue manager from the cluster by following the instructions in the Queue Manager Clusters manual. I would then check a few of my non-repository queue managers and make sure the queue manager has disappeared from them. Only when I was sure the original had gone would I add the new one. This is assuming you currently have two (or more) repositories. Trying to have the two with the same name going at the same time is only going to cause you headaches. Good luck! John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Conklin, To: [EMAIL PROTECTED] William cc: [EMAIL PROTECTED] Subject:Clustering and changing qmgrs. RG Sent by: MQSeries List MQSERIES@AKH-Wie n.AC.AT 06/24/2002 03:59 PM Please respond to MQSeries List Hi All, I have to replace a production repository NT queue manager with a new one with the same name, the only difference is the connection name. Can I just suspend/resume the qmgr and change the connection name in the production environment to match the new environment? Or should I completely delete the current qmgr, channel defs. etc, and then add the new qmgr from scratch? 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 Instructions for managing your mailing list 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: Problem in MQDISC SOC-4 Abend
Shailesh, You cannot connect to the same queue manager twice from the same thread. You're second MQCONN will have returned MQRC_ALREADY_CONNECTED. If you need to be connected to two queue managers from one program, you will have to have two different queue managers. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 shailesh To:[EMAIL PROTECTED] bhaskaran cc: shailesh_mqserie Subject:Re: Problem in MQDISC SOC-4 Abend [EMAIL PROTECTED] Sent by: MQSeries List MQSERIES@AKH-Wie n.AC.AT 05/30/2002 01:58 PM Please respond to MQSeries List Hi!, I am using two different HCONN variables one with name HCONN-PUT and another with HCONN-GET. After doing get I see that both HCONN-PUT and HCONN-GET have exactly the same values. I am doing MQCONN using HCONN-GET to connect to QMA and MQCONN using HCONN-PUT to connect to QMB. For testing purpose I have kept both QMA and QMB name same i,e both Get and Put queue manager names are same. I was wondering if from the same program if I issue MQCONN twice to the same queue manager, will I get the same value for the connection handles and if I disconnect using one connection handle will the other be also destroyed. I can guess that whenever I am closing the first connection handle say HCONN-GET, it somehow marks HCONN-PUT also closed.I can't understand why it is happening. Is it because I am connecting to same queue manager (with two different calls) using HCONN-GET and HCONN-PUT. Thanks Shailesh --- John M Hammond [EMAIL PROTECTED] wrote: Shailesh, You need to disconnect from both queue managers. Check your program and look at what you are doing with the variables you are storing your HConns in. You have 2 separate HConns and need 2 separate variables to store them in (if you want to be connected to both queue managers simultaneously). My guess is that you are corrupting the HConn somehow. The HConn is just a storage address, so if you corrupt it MQ will end up referencing bad addresses and 0C4's are likely. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 shailesh To: [EMAIL PROTECTED] bhaskaran cc: shailesh_mqserie Subject:Problem in MQDISC SOC-4 Abend [EMAIL PROTECTED] Sent by: MQSeries List MQSERIES@AKH-Wie n.AC.AT 05/30/2002 11:51 AM Please respond to MQSeries List Hi! All, I am facing a strange problem. I am running a batch application in which I am connecting to one queue manager say QMA and opening the queue to MQGET the message and also connecting to another queue manager say QMB and opening another queue to MQPUT the message read from the previous queue. Everything goes fine, At the end,I am disconnecting from QMA and QMB. The disconnect from first queue manager QMA goes fine but when it performs the para to disconnect from queue manager QMB, I get a SOC4 abend. I tried to do reverse also i,e first disconnecting from QMB (which goes fine) and then QMA again I get SOC4. I am using different connection handle to connect to two different queue manager. Can any one think of why it might be happening? Does disconnecting from any one queue manager is enough? Thanks Shailesh __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com Instructions for managing your mailing list 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 __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com Instructions for managing your mailing list 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
Queue Manager Clusters References
Hi there, I'm putting together a white paper on MQSeries clustering for my company, and would like to include some references to people already using them in production. I know (from my time in the MQ change team) that a great number of people are running clusters successfully in production, and I understand the issues surrounding clustering. What I'm looking for is something to say, Look, company x has been running with clustering for n years now and this is what they think. The kind of information I would like is along the lines of: How long have you been running, what level of MQ are you on, what platforms are involved, was it worth it? If anyone wold be willing to divulge a few details, please drop me an email. Thanks, John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
