Re: Highest MQ volumes [Deutsche Boerse Systems:Virus checked]
Hello, Using clustering (multiple instances of the same queue on different queue managers) will spread the messages among different queuemanager, which is fine in this case. but if one queuemanager fails, the unprocessed messages which are currently in his instance of the cluster queue will not be processed until the queuemanager is up again. using a shared queue, the messages will be processed by the application connected to the other queuemanagers. using clustering (maybe with customers involved) may not be possible too. because of these high amount of messages i would not use triggering every, i would use long running transactions without triggering, or with triggering "first" and stay running. Regards, Stefan "Adiraju, Rao" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 14.04.2004 01:15 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject: Re: Highest MQ volumes [Deutsche Boerse Systems:Virus checked] . Greg Have you considered using "Clustering" rather than "shared queuing" for load distribution. Even in shared concept, there are no guarantees that messages are processed in sequence and you have to move the shared queue, associated logs to Coupling facility and also mandates DB2. Even it puts some extra coding/discipline (restrictions may be a better word) in the way application are designed/coded. Dead letter queues can't be shared and hence they have stay out of the coupling facility. Which means added complexity of recovery/restoring queue managers in case of failures (you need the specific queue manager resources such as logs and as well as coupling facility resources and logs). Secondly for a high volume system like yours, why do you want trigger for EVERY. Instead you should consider long running CICS transaction(s). Cheers Rao -Original Message- From: Mabrito, Greg [mailto:[EMAIL PROTECTED] Sent: 14 April 2004 9:21 AM To: [EMAIL PROTECTED] Subject: Highest MQ volumes We are looking at replacing some applications that use APPC(LU6.2) to talk to CICS with MQ(IP based) and the CICS adapter(CKTI) on zOS. We will be sending a request message to a shared queue owned by 4 qmgrs that will be serviced by multiple CICS trans and could reply with up to 4 messages back to the replyToQueueManager. We will be triggering on every message for CKTI, we are not sure if we are going to share the initiation queue yet. We are expecting up to 1 million 300 byte sized requests with up to a 4 million 300K replies within a 24 hour period. This would become our highest volume MQ application. I want to know what types of production volumes we are seeing out there in MQ land and who is the highest. Any advice or gotchas that you can through my way in a similar setup? # of messages in 24 hours for a single queue (is it shared?) # of messages in 24 hours for a combination of high volume queues under one qmgr average size of the message Have fun, but be honest, Thanks, Greg Mabrito I/T Systems Programmer IMS and MQ Software Support (210) 913-3985 IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive --Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen.Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bittesofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet.The information contained in this message is confidential or protected bylaw. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited.
Re: Highest MQ volumes
We will be sharing the initq based on the excerpt below if we go with triggering. We are exploring the idea of writing a CICS receiver/router instead of triggering, possibly using the queue service interval events to handle workload. Thanks for all of the contributions. -Greg Source: WebSphere MQ in a z/OS Parallel Sysplex Environment Scenario # 1 Short-running transactions For conventional short-running transactions, each processing a single message, specifying TRIGTYPE=EVERY is recommended. For each message put on to the application queue, a single trigger message is generated that will cause CKTI to start a new instance of the ECHO transaction by issuing the EXEC CICS START command. We also decided to control the workload distribution of ECHO by using two instances of CKTI, one on each CICS transaction server. In this scenario, the two CKTIs will share the trigger messages, resulting in a fairly even distribution of workload across the two CICS regions. Note: For TRIGTYPE=EVERY, the initiation queue must also be shared. This will ensure that only one trigger message is generated for each application message. If non-shared initiation queues are used, each CKTI will receive a trigger for the same message. Two ECHO transactions will be started but there is only one message. One of the ECHO transactions will terminate without being able to find a message. This unnecessary overhead can be avoided by simply ensuring the initiation queue is shared. The ECHO transaction was designed to process single messages. The triggering method TRIGTYPE=EVERY was successfully used to distribute and process transactions across the two CICS regions in our application environment. Important: The only issue with TRIGTYPE=EVERY is that if an application abends, the message will be put back on the queue, but a trigger message is not regenerated. Application processes need to be put in place to ensure that this message is reprocessed appropriately. If the contents of the message itself are causing the abend, there are processes for "poisoned" messages that can be used. These processes are described in Chapter 5, "Handling program errors", in the WebSphere MQ Application Programming Guide, SC34-6064. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Jeff A Tressler Sent: Friday, April 16, 2004 8:04 AM To: [EMAIL PROTECTED] Subject: Re: Highest MQ volumes >Brian S. Crabtree >WBI Consultant > Thanks Brian, it is good to learn new stuff, that is why this list is so good. >1-3 million msgs per day is not a huge volume especially >for z/OS - an old NT box could handle it > It was not the 1 million messages a day that I was worried about, especially since they were nonpersistent. We have scoped our high end Windows NT systems to run 3 million persistent messages per day. It was the trigger on EVERY. Best case that will trigger 11 times per second assuming an evenly distributed message traffic. Considering peaks, seems this could be even higher and realistically even to the hundreds of triggers a second. Just worried since I know many new developers see trigger on EVERY and get very excited and wanted to make sure there was not a better solution. Jeff Tressler Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Highest MQ volumes
>Brian S. Crabtree >WBI Consultant > Thanks Brian, it is good to learn new stuff, that is why this list is so good. >1-3 million msgs per day is not a huge volume especially >for z/OS - an old NT box could handle it > It was not the 1 million messages a day that I was worried about, especially since they were nonpersistent. We have scoped our high end Windows NT systems to run 3 million persistent messages per day. It was the trigger on EVERY. Best case that will trigger 11 times per second assuming an evenly distributed message traffic. Considering peaks, seems this could be even higher and realistically even to the hundreds of triggers a second. Just worried since I know many new developers see trigger on EVERY and get very excited and wanted to make sure there was not a better solution. Jeff Tressler Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Highest MQ volumes [Deutsche Boerse Systems:Virus checked]
Greg, just to answer the init queue question. if you trigger every, only one trigger message is generated. one queuemanager of the qsg is selected to create this trigger message. now - if you use a shared init queue, any trigger monitor can read the trigger message and start the transaction. if you use local init queues, only the trigger monitor of the selected queuemanager can read the trigger message. now - if this queuemanager fails, no one of the other trigger monitors do know that there was a trigger message and that an application transaction has to be started. thats why they recommend to use a shared init queue, but you can also run with local init queues if you (your system management or application design) can handle this specific transaction. the number of trigger messages will not vary for trigger every and shared or local init queue. if you use trigger first, and you have xx local init queues, xx trigger messages are generated, one for every init queue (assuming they all match the trigger conditions). if you have a shared init queue triggering first, also xx trigger messages are generated, but now it is possible that a fast ckti gets two trigger messages, and a slow ckit gets none. i would try to avoid the overhead of triggering every. either trigger first and stay running, or trigger first and start multiple transactions, or start the proper amount of transactions by automation, cics plt or whatever you prefer. regards, stefan --Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen.Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bittesofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet.The information contained in this message is confidential or protected bylaw. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited.
Re: Highest MQ volumes
Jeff 1-3 million msgs per day is not a huge volume especially for z/OS - an old NT box could handle it 30 Persistent/300 non-persistent are good figures for design use - depending on hardware and application Message rates are more dependent on hardware and application than any MQ contribution. In CICS world an input queue is monitored by CKTI - triggering on first as you said - a good design is to have a CICS director or queue browser to read the message and invoke the appropriate CICS transaction - a helper transaction then handles the reply message(s) The CICS director doesnt need to wait for the transaction to complete it just goes on to the next message and can be throttled if throughput is too high - CICS transactions overloading the system There are several options for handling high message rates - add more directors, have more input queues etc - z/OS is flexible so having Shared Queue Groups and multiple CICS regions spreads the workload So the CICS design looks very similar to a distributed system design Brian S. Crabtree WBI Consultant - Original Message - From: "Jeff A Tressler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 15, 2004 8:31 AM Subject: Re: Highest MQ volumes > >We are triggering on every, to process the messages > >in parallel using CKTI instead of writing a separate > >CICS listener to process in this fashion. CICS will > >preload the module after the first couple of triggers > >to increase performance for loading. If we triggered > >on first, messages would process serially, not fast > >enough. > > > Just curious but 1 million requests per 24 hours, even > if distributed evenly is 11 requests per second. 11 > requests every second of every day. Not to mention you > will probably experience peaks much higher than this. > > I don't know much about CICS I work in the UNIX and > Windows world but seems just the overhead of processing > that many requests would be a waste of resources. > > Could you not trigger on first and just spawn enough > threads to handle processing? Or when you brought the > region up preload enough modules to handle the load and > skip the triggering? > > 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: Highest MQ volumes
>We are triggering on every, to process the messages >in parallel using CKTI instead of writing a separate >CICS listener to process in this fashion. CICS will >preload the module after the first couple of triggers >to increase performance for loading. If we triggered >on first, messages would process serially, not fast >enough. > Just curious but 1 million requests per 24 hours, even if distributed evenly is 11 requests per second. 11 requests every second of every day. Not to mention you will probably experience peaks much higher than this. I don't know much about CICS I work in the UNIX and Windows world but seems just the overhead of processing that many requests would be a waste of resources. Could you not trigger on first and just spawn enough threads to handle processing? Or when you brought the region up preload enough modules to handle the load and skip the triggering? 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: Highest MQ volumes
Greg I can't boast that volumes but I can throw my experiences in similar exercise which may be of help to you: 1) If you are using EVERY, you have to have SHARED initiation queue (no choice there). System Administration guide clearly say otherwise it might loose the trigger messages. You have a choice if it is FIRST and DEPTH but not EVERY. 2) Luckily by Sharing the initiation queue, you are at the maximum generating 1 million trigger messages 3) Still don't understand the rational of using CKTI and firing one transaction for every message. CKTI is doing nothing but constantly polling the initiation queue. So if you could replace the CKTI with home grown product that does the polling on the base queue itself, you will be saving 1 million trigger message generations. And if necessary this home grown program can fire off one transaction for message like CKTI. Whichever way you do, as long as you are running one transaction per message you should be aware of the following down stream effects (if you haven't all ready factored in). In APPC, all these 1 million transactions must be running under various transaction codes. Where as with this architecture, all these 1 million transactions will hit with a "single" transaction code (and most probably under a single userid). You need to tune this transaction class, such that it can cope up with that many parallel executions. After this concurrent limit, CICS stacks up the outstanding requests and there is a limit (again customisable) even for this stack. After which CICS tends to loose the subsequent starts without any errors. Starting transaction gets a successful EXEC CICS START command but CICS lost those requests, after crossing the stacking limit. So you need to make this transaction limits as BIG as possible. Being a single transaction code and single user it is running under, you need to look in to your CICS - DB2 attachments for this transaction/plan entry. You should allow maximum thread concurrency etc.. Regarding Security, audit, accounting & charge back you will have lots of fun and unfortunately I don't have any clear solutions to provide. At the outset, it looks like to exciting - have fun. Cheers Rao -Original Message- From: Mabrito, Greg [mailto:[EMAIL PROTECTED] Sent: 15 April 2004 6:10 AM To: [EMAIL PROTECTED] Subject: Re: Highest MQ volumes We are anticipating 1 million messages in (requests) and up to 4 million messages out (replies) but more like 2.3 million messages (replies) out on average within a 24 hour period. This would be a new record for message rates (in and out) for us. Is anyone actually reaching these numbers in production? Is anyone going higher? I am not looking for a white paper or a Redbook calculation. Is anyone monitoring on a high volume day and want to share their volume? Here is your chance for bragging rights. The input queue is clustered and we were going to use clustered channels initially. We plan to later go to shared channels. We are triggering on every, to process the messages in parallel using CKTI instead of writing a separate CICS listener to process in this fashion. CICS will preload the module after the first couple of triggers to increase performance for loading. If we triggered on first, messages would process serially, not fast enough. Messages will be non persistent. I think we allocated 2GB in the coupling facility. DB2 is already on the system where this will run so that isn't a problem. Processing order is not a factor. If the shared queue is triggered how many trigger messages will be created? If I make the initiation queue shared will this reduce the amount of trigger messages? Thanks, -Greg -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tim Armstrong Sent: Tuesday, April 13, 2004 5:01 PM To: [EMAIL PROTECTED] Subject: Re: Highest MQ volumes A simple calculation gives 12x300byte message per second in and 48x300kbyte messages out. That's assuming even distribution which just isn't going to happen so looking at your performance data for the existing app what are maximum and minimum number of messages you are anticipating? As for gotchas. How much headroom do you have in your coupling facility? Especially if your CICS regions stall. Or are all shutdown although I'm guessing this is unlikely. Are the messages persistent or non-persistent? Why are you intending to use trigger every? Regards Tim A -Original Message- From: Mabrito, Greg [mailto:[EMAIL PROTECTED] Sent: Wednesday, 14 April 2004 7:21 AM To: [EMAIL PROTECTED] Subject: Highest MQ volumes We are looking at replacing some applications that use APPC(LU6.2) to talk to CICS with MQ(IP based) and the CICS adapter(CKTI) on zOS. We will be sending a request message to a shared queue owned by 4 qmgrs that will be serviced by multiple CICS trans and could reply with up to 4 messages back to th
Re: Highest MQ volumes
We are anticipating 1 million messages in (requests) and up to 4 million messages out (replies) but more like 2.3 million messages (replies) out on average within a 24 hour period. This would be a new record for message rates (in and out) for us. Is anyone actually reaching these numbers in production? Is anyone going higher? I am not looking for a white paper or a Redbook calculation. Is anyone monitoring on a high volume day and want to share their volume? Here is your chance for bragging rights. The input queue is clustered and we were going to use clustered channels initially. We plan to later go to shared channels. We are triggering on every, to process the messages in parallel using CKTI instead of writing a separate CICS listener to process in this fashion. CICS will preload the module after the first couple of triggers to increase performance for loading. If we triggered on first, messages would process serially, not fast enough. Messages will be non persistent. I think we allocated 2GB in the coupling facility. DB2 is already on the system where this will run so that isn't a problem. Processing order is not a factor. If the shared queue is triggered how many trigger messages will be created? If I make the initiation queue shared will this reduce the amount of trigger messages? Thanks, -Greg -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tim Armstrong Sent: Tuesday, April 13, 2004 5:01 PM To: [EMAIL PROTECTED] Subject: Re: Highest MQ volumes A simple calculation gives 12x300byte message per second in and 48x300kbyte messages out. That's assuming even distribution which just isn't going to happen so looking at your performance data for the existing app what are maximum and minimum number of messages you are anticipating? As for gotchas. How much headroom do you have in your coupling facility? Especially if your CICS regions stall. Or are all shutdown although I'm guessing this is unlikely. Are the messages persistent or non-persistent? Why are you intending to use trigger every? Regards Tim A -Original Message- From: Mabrito, Greg [mailto:[EMAIL PROTECTED] Sent: Wednesday, 14 April 2004 7:21 AM To: [EMAIL PROTECTED] Subject: Highest MQ volumes We are looking at replacing some applications that use APPC(LU6.2) to talk to CICS with MQ(IP based) and the CICS adapter(CKTI) on zOS. We will be sending a request message to a shared queue owned by 4 qmgrs that will be serviced by multiple CICS trans and could reply with up to 4 messages back to the replyToQueueManager. We will be triggering on every message for CKTI, we are not sure if we are going to share the initiation queue yet. We are expecting up to 1 million 300 byte sized requests with up to a 4 million 300K replies within a 24 hour period. This would become our highest volume MQ application. I want to know what types of production volumes we are seeing out there in MQ land and who is the highest. Any advice or gotchas that you can through my way in a similar setup? # of messages in 24 hours for a single queue (is it shared?) # of messages in 24 hours for a combination of high volume queues under one qmgr average size of the message Have fun, but be honest, Thanks, Greg Mabrito I/T Systems Programmer IMS and MQ Software Support (210) 913-3985 IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. 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: Highest MQ volumes
Greg Have you considered using "Clustering" rather than "shared queuing" for load distribution. Even in shared concept, there are no guarantees that messages are processed in sequence and you have to move the shared queue, associated logs to Coupling facility and also mandates DB2. Even it puts some extra coding/discipline (restrictions may be a better word) in the way application are designed/coded. Dead letter queues can't be shared and hence they have stay out of the coupling facility. Which means added complexity of recovery/restoring queue managers in case of failures (you need the specific queue manager resources such as logs and as well as coupling facility resources and logs). Secondly for a high volume system like yours, why do you want trigger for EVERY. Instead you should consider long running CICS transaction(s). Cheers Rao -Original Message- From: Mabrito, Greg [mailto:[EMAIL PROTECTED] Sent: 14 April 2004 9:21 AM To: [EMAIL PROTECTED] Subject: Highest MQ volumes We are looking at replacing some applications that use APPC(LU6.2) to talk to CICS with MQ(IP based) and the CICS adapter(CKTI) on zOS. We will be sending a request message to a shared queue owned by 4 qmgrs that will be serviced by multiple CICS trans and could reply with up to 4 messages back to the replyToQueueManager. We will be triggering on every message for CKTI, we are not sure if we are going to share the initiation queue yet. We are expecting up to 1 million 300 byte sized requests with up to a 4 million 300K replies within a 24 hour period. This would become our highest volume MQ application. I want to know what types of production volumes we are seeing out there in MQ land and who is the highest. Any advice or gotchas that you can through my way in a similar setup? # of messages in 24 hours for a single queue (is it shared?) # of messages in 24 hours for a combination of high volume queues under one qmgr average size of the message Have fun, but be honest, Thanks, Greg Mabrito I/T Systems Programmer IMS and MQ Software Support (210) 913-3985 IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Highest MQ volumes
Hi Greg, I have seen similar types of volume going through CICS regions, although with smaller messages sizes. However, we didn't trigger the transactions. For all the high volume transaction types, we run multiple copies of permanent CICS tasks, and use monitoring to alarm if they ever fail (they basically never do). The tasks complete dealing with one message, syncpoint, and then loop back for a new message. The main difficulty is getting the developers to eliminate all storage and handle leaks. CICS programmers tend to be lazy because the expect CICS to clean up at EOT, which is normally every transaction. The main problem with this approach is that statistics collection doesn't happen unless you change the collection parameters to base it on syncpoint instead of transaction end. Use long running transactions with MQGET(WAIT) means that you avoid triggering and transaction startup costs. You also get to accurately control the maximum concurrency. If you want to get fancy, you can implement monitors which start and stop copies of your transactions based on load. We still use triggering for low volume transactions (< 1 every few seconds). Neil Casey National Australia Bank Southern Star Technology WebSphere MQ Support 1/122 Lewis Rd Wantirna South office. +61 3 9886 2375 (x82375) mobile. +61 414 615 334 "Mabrito, Greg" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] A.COM> cc: Sent by: MQSeries Subject: Highest MQ volumes List <[EMAIL PROTECTED] n.AC.AT> 14/04/2004 07:20 Please respond to MQSeries List We are looking at replacing some applications that use APPC(LU6.2) to talk to CICS with MQ(IP based) and the CICS adapter(CKTI) on zOS. We will be sending a request message to a shared queue owned by 4 qmgrs that will be serviced by multiple CICS trans and could reply with up to 4 messages back to the replyToQueueManager. We will be triggering on every message for CKTI, we are not sure if we are going to share the initiation queue yet. We are expecting up to 1 million 300 byte sized requests with up to a 4 million 300K replies within a 24 hour period. This would become our highest volume MQ application. I want to know what types of production volumes we are seeing out there in MQ land and who is the highest. Any advice or gotchas that you can through my way in a similar setup? # of messages in 24 hours for a single queue (is it shared?) # of messages in 24 hours for a combination of high volume queues under one qmgr average size of the message Have fun, but be honest, Thanks, Greg Mabrito I/T Systems Programmer IMS and MQ Software Support (210) 913-3985 IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. 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: Highest MQ volumes
A simple calculation gives 12x300byte message per second in and 48x300kbyte messages out. That's assuming even distribution which just isn't going to happen so looking at your performance data for the existing app what are maximum and minimum number of messages you are anticipating? As for gotchas. How much headroom do you have in your coupling facility? Especially if your CICS regions stall. Or are all shutdown although I'm guessing this is unlikely. Are the messages persistent or non-persistent? Why are you intending to use trigger every? Regards Tim A -Original Message- From: Mabrito, Greg [mailto:[EMAIL PROTECTED] Sent: Wednesday, 14 April 2004 7:21 AM To: [EMAIL PROTECTED] Subject: Highest MQ volumes We are looking at replacing some applications that use APPC(LU6.2) to talk to CICS with MQ(IP based) and the CICS adapter(CKTI) on zOS. We will be sending a request message to a shared queue owned by 4 qmgrs that will be serviced by multiple CICS trans and could reply with up to 4 messages back to the replyToQueueManager. We will be triggering on every message for CKTI, we are not sure if we are going to share the initiation queue yet. We are expecting up to 1 million 300 byte sized requests with up to a 4 million 300K replies within a 24 hour period. This would become our highest volume MQ application. I want to know what types of production volumes we are seeing out there in MQ land and who is the highest. Any advice or gotchas that you can through my way in a similar setup? # of messages in 24 hours for a single queue (is it shared?) # of messages in 24 hours for a combination of high volume queues under one qmgr average size of the message Have fun, but be honest, Thanks, Greg Mabrito I/T Systems Programmer IMS and MQ Software Support (210) 913-3985 IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. 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.
Highest MQ volumes
We are looking at replacing some applications that use APPC(LU6.2) to talk to CICS with MQ(IP based) and the CICS adapter(CKTI) on zOS. We will be sending a request message to a shared queue owned by 4 qmgrs that will be serviced by multiple CICS trans and could reply with up to 4 messages back to the replyToQueueManager. We will be triggering on every message for CKTI, we are not sure if we are going to share the initiation queue yet. We are expecting up to 1 million 300 byte sized requests with up to a 4 million 300K replies within a 24 hour period. This would become our highest volume MQ application. I want to know what types of production volumes we are seeing out there in MQ land and who is the highest. Any advice or gotchas that you can through my way in a similar setup? # of messages in 24 hours for a single queue (is it shared?) # of messages in 24 hours for a combination of high volume queues under one qmgr average size of the message Have fun, but be honest, Thanks, Greg Mabrito I/T Systems Programmer IMS and MQ Software Support (210) 913-3985 IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. 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
