WBIMB Manual Windows Removal
Anybody have the procedure for MANUALLY removing a 5.0 Broker from a WINDOWS box. bobbee _ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx Instructions for managing your mailing list 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 w/ Message Affinity
There is an option on the MQOPEN call that enables affinity. I think you would benefit from reading about the MQOO_BIND_ON_OPEN option in the App Dev manual. Also look at the section Reviewing applications for message affinities in the Queue Mangers manual. Tony Psaltis, Architect Business Solutions Center / Strategic Planning Center Westfield Group One Park Circle PO Box 5001 Westfield Center, OH 44251-5001 www.westfieldgrp.com Jim Ford [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 04:54 PM Please respond to MQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject ' Clustering w/ Message Affinity We don't use clustering at our site, but are considering it for a couple of high volume applications. Some of these applications, though, use correlation ID to match messages on two different queues. To be more specific, a binary message is put to Q1 under syncpoint. A second message is put to Q2. The second message's correlation ID is set to the first message's message ID. Then a commit is done. The getting app gets the message from Q1, and gets the correlated message from Q2 and processes them. This works fine. But this design requires that both messages have to be delivered to the same target queue manager. How can we guarantee that if we use clustering? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This electronic message transmission contains information from a member company of Westfield Group which is privileged, confidential or otherwise the exclusive property of the intended recipient or that member company of Westfield Group. This information is intended for the use of the individual or entity that is the intended recipient. If you are not the designated recipient, please be aware that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this electronic transmission in error, please notify us by telephone at 1.800.243.0210, extension 2153, or by electronic e-mail ([EMAIL PROTECTED]) and promptly destroy the original transmission.
Re: Clustering w/ Message Affinity
I'll take a look at MQOO-BIND_ON_OPEN. That sounds like it fits the bill. The application is used to store BLOBs on an EMC Centera device, which provides long term cheap storage for archival purposes. We use two separate messages because one is binary data (pdfs, Word docs, tif images), and the other is the metadata describing the BLOB. Tim Armstrong [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 06:25 PM Please respond to MQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: Clustering w/ Message Affinity Sorry forgot to mention that I was assuming MQOO_BIND_ON_OPEN which causes all messages for any one MQOPEN to be sent to the same queue manager. If however this is a long running app then it's off to a workload exit as Neil suggested. Then of course there is the option to move it to z/OS and use queue sharing groups but I kinda get the feeling that one is a bit too extreme. Anyway you look at it clustering when you have message affinity is painful. If there is true affinity between the messages and they are not too large could they be combined into a single message? Just curious about the original decision to have multiple messages coming from the same app. Regards Tim A -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Tuesday, 5 October 2004 8:55 AM To: [EMAIL PROTECTED] Subject: Re: Clustering w/ Message Affinity But whether we put to one or two queues, we have the same issue, right? The messages may be delivered to different queue managers if we cluster. I'm not optimistic that this problem can be solved in a way to make clustering worthwhile. What we gain by having redundant queue managers we give up in complexity. And I'm thinking that Unix and the hardware it runs on are more reliable than our applications. Tim Armstrong [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 05:35 PM Please respond to MQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: Clustering w/ Message Affinity Maybe rewrite the App so it puts both messages to the same queue as follows. Putting App Msg1 MsgId=None(so new MsgId gets generated) Correlid=0x0102030405 or some other unique value - dont use a character string as MsgId's and CorrelId's do not get translated which can cause platform dependcy issues. Msg2 MsgId=None CorrelId=Msg1.MsgId Getting App Get Msg1 by using MsgId=None(to select any MsgId) and CorrelId=0x0102030405 Get Msg2 by using MsgId=None and CorrelId=Msg1.MsgId Kind of a generic solution to different type of messages on the same queue. Also permits Msg3,4,5 etc. with CorrelId=Msg1.MsgID where Msg1 is a control message and the number of other messages is unknown till run time. Let us know which route you choose. I'm afraid there's likely to be pain which ever way you go. Even the above can have problems in that the queue will need to be indexed to get reasonable performance if there are a large number of messages on the queue at any one time, which of course has an overhead of its own :( Regards Tim A -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Tuesday, 5 October 2004 8:09 AM To: [EMAIL PROTECTED] Subject: Re: Clustering w/ Message Affinity I guess that'll work, but it's quite a bit messier than we were hoping for. Potkay, Peter M (ISD, IT) [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 04:34 PM Please respond to MQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: Clustering w/ Message Affinity dang, you are right. Forgot about that. Well, your app will need to maintain a list of available QMs, pick one randomly, and specify the name on the MQOD for the MQOPEN for both queues. You could maintain an MQ Namelist of all these QMs, so the app wouldn't have to change as you add / remove QMs. At least you will get the benefit of reduced Administration for queues and channels. -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 5:23 PM To: [EMAIL PROTECTED] Subject: Re: Clustering w/ Message Affinity Can you get a COA if you haven't commited? It seems like there isn't an A to C until after you commit. Potkay, Peter M (ISD, IT) [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 04:01 PM Please respond to MQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: Clustering w/ Message Affinity You could MQOPEN Q1, put message1 with a COA, read the COA to see what QM got Message1, and then MQOPEN Q2 specifying the QM where the COA came from, put message2 then commit both and close both queues. Now both messages will always be on Q1 / Q2 on the same QM. But you will get a random QM each time. -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 4:55 PM To:
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
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
Certify for AIX 5.3
Anybody know when IBM will certify WAS ND, MQSeries and WBI for AIX 5.3 ? Thanks Francois van der Merwe Instructions for managing your mailing list 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: Authorization for changing user id between AIX and z/OS
Marty, Thank you. Granting the mqdev setid permission on the qmgr object did the trick. Thanks to everyone else who responded too...Lee R. Lee Eshleman AES/PHEAA - IT Tech Services (717) 720-2936 marty [EMAIL PROTECTED] NK.NETTo Sent by: MQSeries [EMAIL PROTECTED] List cc [EMAIL PROTECTED] n.AC.AT Subject Re: Authorization for changing user id between AIX and z/OS 10/04/2004 04:19 PM Please respond to MQSeries List [EMAIL PROTECTED] n.AC.AT setid is included in allmqi. Not sure I was clear - I'm asking if you gave setid permission on the qmgr *object* itself. e.g. setmqaut -m aix_qmgr_name -t qmgr -g mqdev +setid Have you refreshed security since any related group changes? Lee Eshleman wrote: Marty, Not explicitly but if setid is included when you grant allmqi authority then mqdev does have setid authority...Lee R. Lee Eshleman AES/PHEAA - IT Tech Services (717) 720-2936 marty [EMAIL PROTECTED] NK.NETTo Sent by: MQSeries [EMAIL PROTECTED] List cc [EMAIL PROTECTED] n.AC.AT Subject Re: Authorization for changing user id between AIX and z/OS 10/04/2004 02:50 PM Please respond to MQSeries List [EMAIL PROTECTED] n.AC.AT Lee, Did you give the group 'mqdev' setid permissions on the AIX qmgr? You need to set it there as a sort of global permission, as well as each for queue that needs it set. hth, marty Lee Eshleman wrote: Instructions for managing your mailing list 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 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
Re: MQ SupportPack MO02 Compression Exit on Client Channels
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
VMS MQClient Channel tab location and name configuration
When resolving the location of the mq client channel tab file on a VMS host, which environment variables are relevant? The Clients manual states: MQCHLTAB - This specifies the name of the file containing the client channel definition table. On VM/ESA: GLOBALV SELECT CENV SETLP MQCHLTAB filename But what about MQCHLLIB, is this relevant on the VMS platform? How, as in what format, do I specify the security exit location in the channel definition? eg if it was a unix mq client I might specify the exit location as /opt/mqm/myexits/secexit.so(Verify), what notation would I use to explicitly locate a security exit for a VMS client? These questions relate to a VMS host making a mq client connection to a Solaris host running MQServer. Thanks, Matt. == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
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 at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
PS Adapter Log and PS Adapter Error Message
There was a short thread recently between Peter and Bobbee concerning the ReplyToQueue for the PS Adapter. I chimed in with a question about whether, if an error occurs with the Component Interface, the PS Adapter includes that CI error in the message sent to the FAULTQ. Collective experience said no. I understand the error is sent to the respective adapter log file though. My question: Does anyone know how to correlate (data-wise, ie msg_id...) the log file entry with the PS Adapter FAULTQ Message? Thanks, -Patrick. Instructions for managing your mailing list 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 w/ Message Affinity
Title: Message Jim, Why don't you design the message so that it has both data components in it (string and binary data)and use a workload exit to have multiple instances running or across a cluster, or even dimpler just have multiple clients trigger off the one queue so that the load is more scalable. Sid -Original Message-From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Wednesday, 6 October 2004 5:35 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering w/ Message AffinityThanks to both of you for looking at this. I read up on MQOO_BIND_ON_OPEN, and it appears that it will let me keep the messages together as long as they are messages on the same queue. Correct? Our design, though, has two correlated messages, each on a different queue. The reason we have two messages is because one is string format, and one is binary. The reason we used two queues instead of one is that it's simpler programming. Plus this is a high volume application, and the messages do on occasion pile up on the queues. Since the target queue manager runs on Solaris, there's no indexing available and we were worried that if we had all of this on a single queue we'd have performance problems as depth increased. I was hoping that our first stab at clustering wouldn't require noteworthy application changes, nor a workload exit. I suppose that we could just change the sending application to use a single queue with MQOO_BIND_ON_OPEN, and then have a simple "router" application on the back end that split the messages to the pair of local queues. That would let the back end application work without change. But these are very big persistent messages; the binary message can be as large as 20 meg. I hate to do all that unnecessary work and unecessary logging, so I'm not optimistic that we want to pursue clustering for this, I guess. Neil Casey [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 06:18 PM Please respond toMQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: Clustering w/ Message Affinity Actually Jim, you can set up Tim's solution so that the messages are alwaysrouted together. If your application specifies MQOO_BIND_ON_OPEN, then theroute selection is made when the queue is opened, not when the message isPUT. This means that your application should open the queue, put the 2 (ormore) messages, and then commit and close the queue. All the messages willbe sent to the same instance. Next time you open the queue (in a newtransaction) the IBM code or your workload balancing exit can choose a newdestination instance.When considering whether clustering to multiple servers is worthwhile, youneed to think about more than just reliability. Although the unix systemsare reliable, there are times when you want to shut them down (hardware orOS maintenance, application software upgrades, site power outages etc etc).Clustering also allows you to incrementally add capability to your servercluster. When you need to add processing capacity, you don't have toupgrade you E10K to an E15K, with all the associated extra costs. You canjust go out an buy a new V880 and add that on, so you get horizontalscalability for your app, which is generally a very good thing. (Note, Ihave used Sun systems as an example, but of course it applies to Intel,Sun, RS6000 or whatever equally).Regards,Neil CaseyNational Australia BankSouthern Star TechnologyWebSphere MQ Support1/122 Lewis Rd Wantirna Southoffice. +61 3 9886 2375 (x82375)mobile. +61 414 615 334 Jim Ford [EMAIL PROTECTED] M To Sent by: MQSeries [EMAIL PROTECTED] List cc [EMAIL PROTECTED] n.AC.AT Subject Re: Clustering w/ Message Affinity 05/10/2004 08:55 Please respond to MQSeries List [EMAIL PROTECTED] n.AC.ATBut whether we put to one or two queues, we have the same issue, right? Themessages may be delivered to different queue managers if we cluster.I'm not optimistic that this problem can be solved in a way to makeclustering worthwhile. What we gain by having redundant queue managers wegive up in complexity. And I'm thinking that Unix and the hardware it runson are more reliable than our applications.Tim Armstrong[EMAIL PROTECTED]Sent by: MQSeries List To[EMAIL PROTECTED] [EMAIL PROTECTED] .ac.at
Re: Clustering w/ Message Affinity
Then maybe one message. Meta-data first and blob second. Unfortunately MQOO_BIND_ON_OPEN only works for the queue being opened so it still doesn't solve the two queues problem you are currently facing. Regards Tim A -Original Message-From: Jim Ford [mailto:[EMAIL PROTECTED]Sent: Wednesday, 6 October 2004 12:17 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering w/ Message AffinityI'll take a look at MQOO-BIND_ON_OPEN. That sounds like it fits the bill. The application is used to store BLOBs on an EMC Centera device, which provides long term cheap storage for archival purposes. We use two separate messages because one is binary data (pdfs, Word docs, tif images), and the other is the metadata describing the BLOB. Tim Armstrong [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 06:25 PM Please respond toMQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: Clustering w/ Message Affinity Sorry forgot to mention that I was assuming MQOO_BIND_ON_OPEN which causes all messages for any one MQOPEN to be sent to the same queue manager. If however this is a long running app then it's off to a workload exit as Neil suggested. Then of course there is the option to move it to z/OS and use queue sharing groups but I kinda get the feeling that one is a bit too extreme. Anyway you look at it clustering when you have message affinity is painful. If there is true affinity between the messages and they are not too large could they be combined into a single message? Just curious about the original decision to have multiple messages coming from the same app. Regards Tim A -Original Message-From: Jim Ford [mailto:[EMAIL PROTECTED]Sent: Tuesday, 5 October 2004 8:55 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering w/ Message AffinityBut whether we put to one or two queues, we have the same issue, right? The messages may be delivered to different queue managers if we cluster. I'm not optimistic that this problem can be solved in a way to make clustering worthwhile. What we gain by having redundant queue managers we give up in complexity. And I'm thinking that Unix and the hardware it runs on are more reliable than our applications. Tim Armstrong [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 05:35 PM Please respond toMQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: Clustering w/ Message Affinity Maybe rewrite the App so it puts both messages to the same queue as follows. Putting App Msg1 MsgId=None(so new MsgId gets generated) Correlid=0x0102030405 or some other unique value - dont use a character string as MsgId's and CorrelId's do not get translated which can cause platform dependcy issues. Msg2 MsgId=None CorrelId=Msg1.MsgId Getting App Get Msg1 by using MsgId=None(to select any MsgId) and CorrelId=0x0102030405 Get Msg2 by using MsgId=None and CorrelId=Msg1.MsgId Kind of a generic solution to different type of messages on the same queue. Also permits Msg3,4,5 etc. with CorrelId=Msg1.MsgID where Msg1 is a control message and the number of other messages is unknown till run time. Let us know which route you choose. I'm afraid there's likely to be pain which ever way you go. Even the above can have problems in that the queue will need to be indexed to get reasonable performance if there are a large number of messages on the queue at any one time, which of course has an overhead of its own :( Regards Tim A -Original Message-From: Jim Ford [mailto:[EMAIL PROTECTED]Sent: Tuesday, 5 October 2004 8:09 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering w/ Message AffinityI guess that'll work, but it's quite a bit messier than we were hoping for. "Potkay, Peter M (ISD, IT)" [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 04:34 PM Please respond toMQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc
Re: Clustering w/ Message Affinity
Title: Message If you combine binary and text data in a single message you may have to write your own data conversion exit if you plan to cross platforms. Scott -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tim ArmstrongSent: Tuesday, October 05, 2004 7:01 PMTo: [EMAIL PROTECTED]Subject: Re: Clustering w/ Message Affinity Then maybe one message. Meta-data first and blob second. Unfortunately MQOO_BIND_ON_OPEN only works for the queue being opened so it still doesn't solve the two queues problem you are currently facing. Regards Tim A -Original Message-From: Jim Ford [mailto:[EMAIL PROTECTED]Sent: Wednesday, 6 October 2004 12:17 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering w/ Message AffinityI'll take a look at MQOO-BIND_ON_OPEN. That sounds like it fits the bill. The application is used to store BLOBs on an EMC Centera device, which provides long term cheap storage for archival purposes. We use two separate messages because one is binary data (pdfs, Word docs, tif images), and the other is the metadata describing the BLOB. Tim Armstrong [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 06:25 PM Please respond toMQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: Clustering w/ Message Affinity Sorry forgot to mention that I was assuming MQOO_BIND_ON_OPEN which causes all messages for any one MQOPEN to be sent to the same queue manager. If however this is a long running app then it's off to a workload exit as Neil suggested. Then of course there is the option to move it to z/OS and use queue sharing groups but I kinda get the feeling that one is a bit too extreme. Anyway you look at it clustering when you have message affinity is painful. If there is true affinity between the messages and they are not too large could they be combined into a single message? Just curious about the original decision to have multiple messages coming from the same app. Regards Tim A -Original Message-From: Jim Ford [mailto:[EMAIL PROTECTED]Sent: Tuesday, 5 October 2004 8:55 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering w/ Message AffinityBut whether we put to one or two queues, we have the same issue, right? The messages may be delivered to different queue managers if we cluster. I'm not optimistic that this problem can be solved in a way to make clustering worthwhile. What we gain by having redundant queue managers we give up in complexity. And I'm thinking that Unix and the hardware it runs on are more reliable than our applications. Tim Armstrong [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 05:35 PM Please respond toMQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: Clustering w/ Message Affinity Maybe rewrite the App so it puts both messages to the same queue as follows. Putting App Msg1 MsgId=None(so new MsgId gets generated) Correlid=0x0102030405 or some other unique value - dont use a character string as MsgId's and CorrelId's do not get translated which can cause platform dependcy issues. Msg2 MsgId=None CorrelId=Msg1.MsgId Getting App Get Msg1 by using MsgId=None(to select any MsgId) and CorrelId=0x0102030405 Get Msg2 by using MsgId=None and CorrelId=Msg1.MsgId Kind of a generic solution to different type of messages on the same queue. Also permits Msg3,4,5 etc. with CorrelId=Msg1.MsgID where Msg1 is a control message and the number of other messages is unknown till run time. Let us know which route you choose. I'm afraid there's likely to be pain which ever way you go. Even the above can have problems in that the queue will need to be indexed to get reasonable performance if there are a large number of messages on the queue at any one time, which of course has an overhead of its own :( Regards Tim A
Re: Clustering w/ Message Affinity
Title: Message Ooops missed the obvious. Different messages same queue as per previous email. As for your concern about indexing unless you are talking about many thousands of messages being backed up you shouldn't experience serious overheads. Regards Tim A -Original Message-From: Scott Gray [mailto:[EMAIL PROTECTED]Sent: Wednesday, 6 October 2004 9:14 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering w/ Message Affinity If you combine binary and text data in a single message you may have to write your own data conversion exit if you plan to cross platforms. Scott -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tim ArmstrongSent: Tuesday, October 05, 2004 7:01 PMTo: [EMAIL PROTECTED]Subject: Re: Clustering w/ Message Affinity Then maybe one message. Meta-data first and blob second. Unfortunately MQOO_BIND_ON_OPEN only works for the queue being opened so it still doesn't solve the two queues problem you are currently facing. Regards Tim A -Original Message-From: Jim Ford [mailto:[EMAIL PROTECTED]Sent: Wednesday, 6 October 2004 12:17 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering w/ Message AffinityI'll take a look at MQOO-BIND_ON_OPEN. That sounds like it fits the bill. The application is used to store BLOBs on an EMC Centera device, which provides long term cheap storage for archival purposes. We use two separate messages because one is binary data (pdfs, Word docs, tif images), and the other is the metadata describing the BLOB. Tim Armstrong [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 06:25 PM Please respond toMQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: Clustering w/ Message Affinity Sorry forgot to mention that I was assuming MQOO_BIND_ON_OPEN which causes all messages for any one MQOPEN to be sent to the same queue manager. If however this is a long running app then it's off to a workload exit as Neil suggested. Then of course there is the option to move it to z/OS and use queue sharing groups but I kinda get the feeling that one is a bit too extreme. Anyway you look at it clustering when you have message affinity is painful. If there is true affinity between the messages and they are not too large could they be combined into a single message? Just curious about the original decision to have multiple messages coming from the same app. Regards Tim A -Original Message-From: Jim Ford [mailto:[EMAIL PROTECTED]Sent: Tuesday, 5 October 2004 8:55 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering w/ Message AffinityBut whether we put to one or two queues, we have the same issue, right? The messages may be delivered to different queue managers if we cluster. I'm not optimistic that this problem can be solved in a way to make clustering worthwhile. What we gain by having redundant queue managers we give up in complexity. And I'm thinking that Unix and the hardware it runs on are more reliable than our applications. Tim Armstrong [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 10/04/2004 05:35 PM Please respond toMQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: Clustering w/ Message Affinity Maybe rewrite the App so it puts both messages to the same queue as follows. Putting App Msg1 MsgId=None(so new MsgId gets generated) Correlid=0x0102030405 or some other unique value - dont use a character string as MsgId's and CorrelId's do not get translated which can cause platform dependcy issues. Msg2 MsgId=None CorrelId=Msg1.MsgId Getting App Get Msg1 by using MsgId=None(to select any MsgId) and CorrelId=0x0102030405 Get Msg2 by using MsgId=None
Re: Clustering w/ Message Affinity
FWIW, I've found an MQRFH2 header a useful place to store metadata while the payload can be binary. Since the name/value info is user-defined, extensible, and converted by a qmgr as necessary it could be of use in this scenario. i.e. it can be of great use when you wish to send textual meta-data and binary data in the same message. We've used MQRFH2 headers with much success in transporting compressed file data as messages. We send all sorts of metadata about the file along with the binary payload - it's original name, file type, source system, length, requested destination, digest info, etc. The receiving app uses the metadata to help it verify content and write the file to it's destination. HTH, and as always YMMV :-) marty Scott Gray wrote: If you combine binary and text data in a single message you may have to write your own data conversion exit if you plan to cross platforms. Scott Instructions for managing your mailing list 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 w/ Message Affinity
Nifty idea indeed. Need to clear the blockage about RFH2's being MQSI centric. Regards Tim A -Original Message- From: marty [mailto:[EMAIL PROTECTED] Sent: Wednesday, 6 October 2004 10:34 AM To: [EMAIL PROTECTED] Subject: Re: Clustering w/ Message Affinity FWIW, I've found an MQRFH2 header a useful place to store metadata while the payload can be binary. Since the name/value info is user-defined, extensible, and converted by a qmgr as necessary it could be of use in this scenario. i.e. it can be of great use when you wish to send textual meta-data and binary data in the same message. We've used MQRFH2 headers with much success in transporting compressed file data as messages. We send all sorts of metadata about the file along with the binary payload - it's original name, file type, source system, length, requested destination, digest info, etc. The receiving app uses the metadata to help it verify content and write the file to it's destination. HTH, and as always YMMV :-) marty Scott Gray wrote: If you combine binary and text data in a single message you may have to write your own data conversion exit if you plan to cross platforms. Scott Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Yet another nuisance. Standard Bank's mailmarshal.
Anybody else getting mailmarshal messages from Standard Bank in South Africa? This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material. Instructions for managing your mailing list 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: Yet another nuisance. Standard Bank's mailmarshal.
Yep Fitted nicely in the deleted items bin. -Original Message- From: Tim Armstrong [mailto:[EMAIL PROTECTED] Sent: Wednesday, 6 October 2004 12:16 PM To: [EMAIL PROTECTED] Subject: Yet another nuisance. Standard Bank's mailmarshal. Anybody else getting mailmarshal messages from Standard Bank in South Africa? This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material. Instructions for managing your mailing list 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
