That won't necessarily work in our case. The web is waiting for a response back. The system that is doing this is mimicking an on-line system. They want a response back to them within 30 seconds.
I am looking closely at this system I inherited and I am starting to understand more. The program we call the driver does not loop through all the records in a trigger queue until it is empty--it processes one record at a time and stops. I think it is increasing the CICS load by making CICS fire it off for each record in the trigger queue. If there is an increased amount of activity, the burst may possibly cause a back-up that will take a little while to drain and cause a time-out on the web side. >From what I see, the messages do not expire and are processed by the mainframe but the responses that are going back to the web are ignored because they are beyond the 30 second limit. I am going to make this driver loop until the queue is empty and see what that buys us. -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kerry Swemmer Sent: Friday, May 28, 2004 4:12 AM To: [EMAIL PROTECTED] Subject: Re: Is there a way to do this? Hi Raymond, We get the trigger monitor kick off a NATURAL batch job. Cheers, > Kerry Swemmer > T-Systems South Africa (Pty) Ltd > Database Administrator > Computing and Desktop Services > Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa > Postal Address: PO Box 671, East London, 5200 > Phone: +27 (43) 706 2549 > Fax: +27 (43) 706 2085 > Mobile: +27 (83) 657 4151 > E-mail: [EMAIL PROTECTED] > Internet: www.t-systems.co.za -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kinzler, Raymond C Sent: 27 May 2004 21:51 To: [EMAIL PROTECTED] Subject: Re: Is there a way to do this? I agree this is a case where I should be kicking off a NATURAL program but...I have no idea how to do it! What do I need to do to have the trigger queue run a NATURAL program? Don't I need to get into the NATURAL environment? This is probably a really east thing to do but I am just green--especially at MQ. All I know about MQ is what I read here and one (old!) manual I have... -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: Thursday, May 27, 2004 1:47 PM To: [EMAIL PROTECTED] Subject: Re: Is there a way to do this? This is a design where you want your SIL to run in Natural, not COBOL. In other words: 1. triggered transaction invokes natural program 2. natural program (SIL) processes queue, looping unitl no more messages 3. for each request (in the simple case, a single message), natural program invokes a service program to satisfy the request. 4. If parallelism is required to get enough throughput, the natural SIL spawns more instances of itself by "echoing" the original trigger message back to the initq. Regards -----Original Message----- From: Kinzler, Raymond C [mailto:[EMAIL PROTECTED] Sent: Thursday, May 27, 2004 4:14 AM To: [EMAIL PROTECTED] Subject: Is there a way to do this? Hello, We have an application on the web that uses MQ Series to maintain our NATURAL/ADABAS application on the mainframe. We currently have a trigger queue on the mainframe that executes a CICS transaction that kicks off a COBOL program that logs into NATURAL, passes data to the stack, and kicks off a NATURAL program. The COBOL program is such that it has to logon and logoff of NATURAL for every transaction. This is a heavily used system and we feel the excessive logons/logoffs are causing a bottleneck of sorts. And there is a business requirement that a response be received on the web side within 30 elapsed seconds. We are missing this goal on occasion and would like to make some improvements. The user id/password for each of these transactions is ALWAYS the same--no matter what user submits the transaction. Because this is the case, we thought there may be a way to always be logged on and, thus, eliminate excessive logons/logoffs. We found that there were over 75,000 logons/logoffs via the CICS transaction this past Monday. We also experienced a ton of slowdowns (for a multitude of reasons including the fact that we are reaching the upper limits of the current box). We will be getting a new box with loads of horsepower within four months but we need to see if we can improve performance between now and then. Any suggestions are welcome!! Thanks, Raymond C. Kinzler, Jr. ADABAS DBA Eaton Electrical Moon Township, PA 15108 Tel: 412-893-4463 (Adnet 227-4463) Fax: 412-893-2156 Cell: 412-716-3368 [EMAIL PROTECTED] www.EatonElectrical.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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 Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, this message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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
