Re: Continuous forwarding of priority queue to a non-priority queue
Hello T.Rob, Thank you and Rick for the insights on triggering. My plan was to trigger on MQTT_FIRST and then serve the queue continuously in a loop. If the downstream queue becomes full (let us say, its MAXDEPTH is 10 messages), then my application would wait for it to have, say, 5 free slots and then continue forwarding. While it would wait, arriving messages would be piling on the first QUEUE in the order according to their priority, so that they would go to the FIFO queue in this order, too). Would this work as I think it should (i.e., obey the priority, except for maybe last 10 messages) or am I missing something here? My understanding is that, even if my application were working from PRIORITY queue, and the processing were really fast, the messages would have been processed in a FIFO order, not according to the priority (say, if the CURDEPTH of the queue is always 1 or 0). As I said in the previous e-mail, the reason for using triggering would be to avoid the administration hassle for my own continuously running application (a daemon). After reading the doc, I got a doubt on how reliable triggering really is. If, for some reason, the triggered application crashes without calling MQCLOSE (for the sake of example, let us say it is killed with kill -9, on Unix), and the message arrives to the application queue before the crash but after the last issued MQGET, would the trigger message be sent and the triggered application re-started or the message will stuck until the next message arrives? Thank you, Pavel "Wyatt, T.rob" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeries Subject: Re: Continuous forwarding of priority queue to a non-priority queue List <[EMAIL PROTECTED] C.AT> 08/06/2004 10:19 AM Please respond to MQSeries List Pavel, If I understand you correctly, you would deliver the messages first to a queue with MSGDLVSQ(PRIORITY) which triggers a job to them move the messages to a FIFO queue. The only problem I can see with that is that, unless the triggered job is r e a l s l o w, or unless you trigger on depth, the messages still arrive in the FIFO queue in the same order they arrived on the PRIORITY queue. This is because the QMgr can't sort the messages by priority unless they are allowed to first build in the queue. You didn't mention whether your app would trigger on depth or not so maybe you considered this already. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel Tolkachev Sent: Thursday, August 05, 2004 12:16 PM To: [EMAIL PROTECTED] Subject: Continuous forwarding of priority queue to a non-priority queue Hello all, One of my clients has a requirement to my application, which by its design and specification cannot properly process the queue where prioritized messages can be put, to process messages in accordance with their priorities. I figured out that the most rational way to meet it would be to just let MQ to prioritize the messages in some queue with MSGDLVSQ(PRIORITY) and transactionally forward all messages to an additional queue with MSGDLVSQ(FIFO) from where my application could then work. For performance reasons I think it is probably better for this new forwarding application to be server application. For the administration convenience and robustness, I think it might better be a triggered process rather than a standalone daemon. I need help with two questions: 1. Does my solution outlined above make sense? Especially -- what are pros and contras and gotchas for making it a triggered process (I have never written one before)? 2. Isn't there something around ready, like a service pack for doing this type of work? One requirement I feel I will have to consider is that the second queue must not be deep, otherwise, if the downstream process takes too long, the messages of different original priority will pile up in the secondary queue and the client will not be sastisfied with how we actually obey that original priority. So, the solution must properly process the "destination queue is full" condition. Thank you, Pavel Paul Clarke <[EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM> cc: Sent by: MQSeriesSubject: Re: downloading MO71 support pac List <[EMAIL PROTECTED] n.AC.AT> 07/22/2004 09:29 AM Please respond to MQSeries List
Re: Continuous forwarding of priority queue to a non-priority queue
Pavel, If I understand you correctly, you would deliver the messages first to a queue with MSGDLVSQ(PRIORITY) which triggers a job to them move the messages to a FIFO queue. The only problem I can see with that is that, unless the triggered job is r e a l s l o w, or unless you trigger on depth, the messages still arrive in the FIFO queue in the same order they arrived on the PRIORITY queue. This is because the QMgr can't sort the messages by priority unless they are allowed to first build in the queue. You didn't mention whether your app would trigger on depth or not so maybe you considered this already. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel Tolkachev Sent: Thursday, August 05, 2004 12:16 PM To: [EMAIL PROTECTED] Subject: Continuous forwarding of priority queue to a non-priority queue Hello all, One of my clients has a requirement to my application, which by its design and specification cannot properly process the queue where prioritized messages can be put, to process messages in accordance with their priorities. I figured out that the most rational way to meet it would be to just let MQ to prioritize the messages in some queue with MSGDLVSQ(PRIORITY) and transactionally forward all messages to an additional queue with MSGDLVSQ(FIFO) from where my application could then work. For performance reasons I think it is probably better for this new forwarding application to be server application. For the administration convenience and robustness, I think it might better be a triggered process rather than a standalone daemon. I need help with two questions: 1. Does my solution outlined above make sense? Especially -- what are pros and contras and gotchas for making it a triggered process (I have never written one before)? 2. Isn't there something around ready, like a service pack for doing this type of work? One requirement I feel I will have to consider is that the second queue must not be deep, otherwise, if the downstream process takes too long, the messages of different original priority will pile up in the secondary queue and the client will not be sastisfied with how we actually obey that original priority. So, the solution must properly process the "destination queue is full" condition. Thank you, Pavel Paul Clarke <[EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM> cc: Sent by: MQSeriesSubject: Re: downloading MO71 support pac List <[EMAIL PROTECTED] n.AC.AT> 07/22/2004 09:29 AM Please respond to MQSeries List Dan, Is it possible you're using the old webpage. The SupportPacs have been re-arranged recently. I've just tried it from http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg24000142&loc=en_US&cs=utf-8&lang=en and it seems to work fine for me. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley "Capodicci, Dan (GE Commercial Finance)" To <[EMAIL PROTECTED] [EMAIL PROTECTED] .COM> cc Sent by: MQSeries List Subject <[EMAIL PROTECTED] downloading MO71 support pac N.AC.AT> 20/07/2004 15:00 Please respond to MQSeries List Hi After having read so many positive things recently about the MO71 support pac, I decided to download it and take a look. But of course, it is never that easy :) As I am trying to download it by clicking on the link, I get the license acceptance window which I respond to "accept", then I get a "Not Authorized" page ?!?!?!?!?!??!?!? I have only done this about a million times over the years (although it has been a while since the last) and never had this happen. Has something changed that I missed?!? Any clues about what I can do to download this support pac?!?!? Thanks Dan 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 -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the
Re: Continuous forwarding of priority queue to a non-priority queue
Pavel, I'm not entirely sure I understand this priority vs. FIFO delivery dilemma, so I'll just skip to the questions. 1. If you choose to trigger the forwarding application, it certainly is a reasonable choice. 2. But, given the second question, the restriction of forwarding messages due to a "queue full" condition sort of works against the way a triggered application works. The triggered application is responsible for draining the messages and, if it fails to do so, you may run the risk of falling into a trigger loop. Your application could test the QDEPTH of the second queue and decide if there's room to forward some messages. But, in this circumstance, I would think a standalone application that polled the first queue would make more sense. Pavel Tolkachev To Sent by: MQSeries [EMAIL PROTECTED] List cc <[EMAIL PROTECTED] n.AC.AT> Subject Continuous forwarding of priority queue to a non-priority queue 08/05/2004 12:16 PM Please respond to MQSeries List <[EMAIL PROTECTED] n.AC.AT> Hello all, One of my clients has a requirement to my application, which by its design and specification cannot properly process the queue where prioritized messages can be put, to process messages in accordance with their priorities. I figured out that the most rational way to meet it would be to just let MQ to prioritize the messages in some queue with MSGDLVSQ(PRIORITY) and transactionally forward all messages to an additional queue with MSGDLVSQ(FIFO) from where my application could then work. For performance reasons I think it is probably better for this new forwarding application to be server application. For the administration convenience and robustness, I think it might better be a triggered process rather than a standalone daemon. I need help with two questions: 1. Does my solution outlined above make sense? Especially -- what are pros and contras and gotchas for making it a triggered process (I have never written one before)? 2. Isn't there something around ready, like a service pack for doing this type of work? One requirement I feel I will have to consider is that the second queue must not be deep, otherwise, if the downstream process takes too long, the messages of different original priority will pile up in the secondary queue and the client will not be sastisfied with how we actually obey that original priority. So, the solution must properly process the "destination queue is full" condition. Thank you, Pavel Paul Clarke <[EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM> cc: Sent by: MQSeriesSubject: Re: downloading MO71 support pac List <[EMAIL PROTECTED] n.AC.AT> 07/22/2004 09:29 AM Please respond to MQSeries List Dan, Is it possible you're using the old webpage. The SupportPacs have been re-arranged recently. I've just tried it from http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg24000142&loc=en_US&cs=utf-8&lang=en and it seems to work fine for me. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley "Capodicci, Dan (GE Commercial Finance)" To <[EMAIL PROTECTED] [EMAIL PROTECTED] .COM> cc Sent by: MQSeries List Subject <[EMAIL PROTECTED] downloading MO71 support pac N.AC.AT> 20/07/2004 15:00 Please respond to MQSeries List Hi After having read so many positive things recently about the MO71 support pac, I decided to download it and take a look. But of course, it is never that easy :) As I am trying to download it by clicking on the link, I get the license acceptance window which I respond to "accept", then I get a "Not Authorized" page ?!?!?!?!?!??!?!? I have only done this about a million times over the years (although it has been a while since the last) and never had this happen. Has something changed that I missed?!? Any clues about what I can do to download this support pac?!?!? Thanks Dan Instructions fo
Continuous forwarding of priority queue to a non-priority queue
Hello all, One of my clients has a requirement to my application, which by its design and specification cannot properly process the queue where prioritized messages can be put, to process messages in accordance with their priorities. I figured out that the most rational way to meet it would be to just let MQ to prioritize the messages in some queue with MSGDLVSQ(PRIORITY) and transactionally forward all messages to an additional queue with MSGDLVSQ(FIFO) from where my application could then work. For performance reasons I think it is probably better for this new forwarding application to be server application. For the administration convenience and robustness, I think it might better be a triggered process rather than a standalone daemon. I need help with two questions: 1. Does my solution outlined above make sense? Especially -- what are pros and contras and gotchas for making it a triggered process (I have never written one before)? 2. Isn't there something around ready, like a service pack for doing this type of work? One requirement I feel I will have to consider is that the second queue must not be deep, otherwise, if the downstream process takes too long, the messages of different original priority will pile up in the secondary queue and the client will not be sastisfied with how we actually obey that original priority. So, the solution must properly process the "destination queue is full" condition. Thank you, Pavel Paul Clarke <[EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM> cc: Sent by: MQSeriesSubject: Re: downloading MO71 support pac List <[EMAIL PROTECTED] n.AC.AT> 07/22/2004 09:29 AM Please respond to MQSeries List Dan, Is it possible you're using the old webpage. The SupportPacs have been re-arranged recently. I've just tried it from http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg24000142&loc=en_US&cs=utf-8&lang=en and it seems to work fine for me. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley "Capodicci, Dan (GE Commercial Finance)" To <[EMAIL PROTECTED] [EMAIL PROTECTED] .COM> cc Sent by: MQSeries List Subject <[EMAIL PROTECTED] downloading MO71 support pac N.AC.AT> 20/07/2004 15:00 Please respond to MQSeries List Hi After having read so many positive things recently about the MO71 support pac, I decided to download it and take a look. But of course, it is never that easy :) As I am trying to download it by clicking on the link, I get the license acceptance window which I respond to "accept", then I get a "Not Authorized" page ?!?!?!?!?!??!?!? I have only done this about a million times over the years (although it has been a while since the last) and never had this happen. Has something changed that I missed?!? Any clues about what I can do to download this support pac?!?!? Thanks Dan 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 -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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: IMS BRIDGE Queues and MQMD-PRIORITY
Peter, Elegant solutions are possible on the IMS side too. An existing IMS queue can be reordered readily, though exit code written in assembler, C, or PL/I is sometimes required. A licensed IBM program product called IMS Queue Control Facility for z/Os V1R2 would have to be available, and I don't know whether ETSD at the Hartford has it installed. This product also makes ISPF-based browsing facilities for IMS queues available, and they would be helpful in sorting out what is happening on the IMS side of your application. To read about QCF you can download a copy of the IBM publication IMS Queue Control Facility for z/OS User's Guide, SC26-9685-02 from the IBM publications website. John Gilmore SystemCraft LLC - Original Message - From: Doug Jenkins Sent: 05 February, 2003 14:15 To: [EMAIL PROTECTED] Subject: Re: IMS BRIDGE Queues and MQMD-PRIORITY Would adding more MPR's at 6am allow faster handing of the requests?Doug "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] TFORD.COM> Subject: IMS BRIDGE Queues and MQMD-PRIORITY 02/05/2003 09:11 AM Please respond to MQSeries ListAn IMS bridge queue is GET disabled from 2AM to 6AM, since the IMS Onlinesare not up and running. For these four hours, the web application isaccepting requests and sending the asynchronous messages to the Bridgequeue. The Web application knows if it is between 2 AM and 6 AM, and willnot wait for a reply but instead will put up a splash screen saying anemailwill be sent to them the next morning with their reply.So at 6 AM, we have hundreds of request messages queued up on the bridgequeue. As soon as the IMS onlines come back up, the queue is enabled andthemessages flow into the OTMA. However, all these hundreds of messages takesome time to process. If a user at the web front end sends in a request at6:01 AM, they will wait for a reply, since the onlines are now up. Buttheirrequest is now stuck behind all the previous night's messages.How do I insure that the messages sent after 6 AM get prioritized to beprocessed before the previous night's messages? I would like to avoidcreating a separate request queue to be used by the application between 2and 6 AM. So I thought I might have the front end app set the priority ofthe messages sent outside of 2-6 AM to be higher than the ones sent between2 and 6.Would this work? What if the queue is enabled at 6 AM with 100 messages ofPRIORITY zero. These messages will all "instantly" flow into the IMS queue,where they get queued up on the IMS queue, right? Does the MQMD-Prioritygetcarried over and used somehow in the IMS queue as well? So that when aPRIORITY 9 message comes in, it goes straight into the IMS queue, and thento the head of the IMS queue? Or is it stuck at the back of the IMS queue,because MQMD-Priority is not translated into IMS?Or will the messages stay queued up on the MQ bridge queue when the queueisenabled, going into OTMA one at a time, and as such the arriving messageswill be put to the head of the MQ queue because of their priority?Peter PotkayIBM MQSeries Certified Specialist, Developer[EMAIL PROTECTED]X 77906This communication, including attachments, is for the exclusive use ofaddressee and may contain proprietary, confidential or privilegedinformation. If you are not the intended recipient, any use, copying,disclosure, dissemination or distribution is strictly prohibited. Ifyou are not the intended recipient, please notify the senderimmediately by return email and delete this communication and destroy allcopies.Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archiveInstructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: IMS BRIDGE Queues and MQMD-PRIORITY
Would adding more MPR's at 6am allow faster handing of the requests? Doug "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] Subject: IMS BRIDGE Queues and MQMD-PRIORITY 02/05/2003 09:11 AM Please respond to MQSeries List An IMS bridge queue is GET disabled from 2AM to 6AM, since the IMS Onlines are not up and running. For these four hours, the web application is accepting requests and sending the asynchronous messages to the Bridge queue. The Web application knows if it is between 2 AM and 6 AM, and will not wait for a reply but instead will put up a splash screen saying an email will be sent to them the next morning with their reply. So at 6 AM, we have hundreds of request messages queued up on the bridge queue. As soon as the IMS onlines come back up, the queue is enabled and the messages flow into the OTMA. However, all these hundreds of messages take some time to process. If a user at the web front end sends in a request at 6:01 AM, they will wait for a reply, since the onlines are now up. But their request is now stuck behind all the previous night's messages. How do I insure that the messages sent after 6 AM get prioritized to be processed before the previous night's messages? I would like to avoid creating a separate request queue to be used by the application between 2 and 6 AM. So I thought I might have the front end app set the priority of the messages sent outside of 2-6 AM to be higher than the ones sent between 2 and 6. Would this work? What if the queue is enabled at 6 AM with 100 messages of PRIORITY zero. These messages will all "instantly" flow into the IMS queue, where they get queued up on the IMS queue, right? Does the MQMD-Priority get carried over and used somehow in the IMS queue as well? So that when a PRIORITY 9 message comes in, it goes straight into the IMS queue, and then to the head of the IMS queue? Or is it stuck at the back of the IMS queue, because MQMD-Priority is not translated into IMS? Or will the messages stay queued up on the MQ bridge queue when the queue is enabled, going into OTMA one at a time, and as such the arriving messages will be put to the head of the MQ queue because of their priority? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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: IMS BRIDGE Queues and MQMD-PRIORITY
Peter, The MQMD-Priority is used by MQ to decide the order in which to send messages to IMS; they are all queued at the same priority within IMS. I'm not aware of any priority system on the IMS message queue; even if it exists, the MQ-IMS Bridge does not take advantage of it. I suspect your best approach to this would be to extend the "you will get your response later" period to allow the backlog to be processed before expecting the normal response period! Whether this is acceptable or not probably depends on how long the backlog takes to process. Regards John J 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
IMS BRIDGE Queues and MQMD-PRIORITY
An IMS bridge queue is GET disabled from 2AM to 6AM, since the IMS Onlines are not up and running. For these four hours, the web application is accepting requests and sending the asynchronous messages to the Bridge queue. The Web application knows if it is between 2 AM and 6 AM, and will not wait for a reply but instead will put up a splash screen saying an email will be sent to them the next morning with their reply. So at 6 AM, we have hundreds of request messages queued up on the bridge queue. As soon as the IMS onlines come back up, the queue is enabled and the messages flow into the OTMA. However, all these hundreds of messages take some time to process. If a user at the web front end sends in a request at 6:01 AM, they will wait for a reply, since the onlines are now up. But their request is now stuck behind all the previous night's messages. How do I insure that the messages sent after 6 AM get prioritized to be processed before the previous night's messages? I would like to avoid creating a separate request queue to be used by the application between 2 and 6 AM. So I thought I might have the front end app set the priority of the messages sent outside of 2-6 AM to be higher than the ones sent between 2 and 6. Would this work? What if the queue is enabled at 6 AM with 100 messages of PRIORITY zero. These messages will all "instantly" flow into the IMS queue, where they get queued up on the IMS queue, right? Does the MQMD-Priority get carried over and used somehow in the IMS queue as well? So that when a PRIORITY 9 message comes in, it goes straight into the IMS queue, and then to the head of the IMS queue? Or is it stuck at the back of the IMS queue, because MQMD-Priority is not translated into IMS? Or will the messages stay queued up on the MQ bridge queue when the queue is enabled, going into OTMA one at a time, and as such the arriving messages will be put to the head of the MQ queue because of their priority? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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: Priority
Simple way to look at it. MQ provides services to CICS so if CICS is running at a higher priority then it keep pre-empting its service provider. Regards Tim A "Mauro, Samuel" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] EXTRON.COM> cc: Sent by: MQSeries List Subject: Re: Priority <[EMAIL PROTECTED] > 23/11/2002 03:11 Please respond to MQSeries List If the MQ regions and CICS regions are 'talking' to each other, I always run them in the same service class(es). (ONLPRD for Production, etc.) Thanks. Sam. Sam Mauro Bell Helicopter Textron Voice (817) 280-3215 Fax(817) 278-3215 Pager (817) 227-4063 -Original Message- From: Williams, Dave (Systems Management) [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 9:43 AM To: [EMAIL PROTECTED] Subject: Priority Folks? At what priority do you run your OS/390 MQ compared to your CICS regions? I'm not at all sure it's important, but wanted to poll the list to see what you're coding. Thanks! Dave W. 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: Priority
We run the MQ at a higher priority than the CICS regions, but below the IMS and DB2. Glen Shubert [EMAIL PROTECTED] Associate Director MQSeries Technical Support IBM Certified Specialist - MQSeries IBM Certified Solutions Expert - MQSeries (706) 641-3708 "Williams, Dave (Systems Management)" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 11/22/2002 10:42 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Priority Folks… At what priority do you run your OS/390 MQ compared to your CICS regions? I'm not at all sure it's important, but wanted to poll the list to see what you're coding. Thanks! Dave W.
Re: Priority
If the MQ regions and CICS regions are 'talking' to each other, I always run them in the same service class(es). (ONLPRD for Production, etc.) Thanks. Sam.Sam MauroBell Helicopter TextronVoice (817) 280-3215Fax (817) 278-3215Pager (817) 227-4063 -Original Message-From: Williams, Dave (Systems Management) [mailto:[EMAIL PROTECTED]]Sent: Friday, November 22, 2002 9:43 AMTo: [EMAIL PROTECTED]Subject: Priority Folks… At what priority do you run your OS/390 MQ compared to your CICS regions? I’m not at all sure it’s important, but wanted to poll the list to see what you’re coding. Thanks! Dave W.
Priority
Folks… At what priority do you run your OS/390 MQ compared to your CICS regions? I’m not at all sure it’s important, but wanted to poll the list to see what you’re coding. Thanks! Dave W.
