Rick, Call me Ray. :-)
The VMS-MQ program is written in NATURAL and it is the one receiving the 2033 errors when it attempts to read the trigger queue. I have no idea about using expiry. I assume that is a parameter passed when the java program originally PUT the message. Or is it a setting on the QLOCAL queues? BUT...you may have something with CICS being the problem. We have run into that situation in the past. Correct me is I am wrong but if I run a process under CICS and it is a hog, CICS may hang onto it until it is finished, right? Even though I am reading records from an MQ queue and writing them to an ADABAS file. I do not know CICS very well but I do know there are no EXEC CICS involved after VMS-MQ is invoked. Arrrghhhhh!!! -----Original Message----- From: Rick Tsujimoto [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 10:32 AM To: [EMAIL PROTECTED] Subject: Re: A novice question Raymond, We run a similar type of application, e.g. order system accessed by customers on the web, which in turn, sends the request to our m/f via MQ, and processes the order on CICS. We use IDMS for our DBMS. If the CICS application receives a large order, it can easily monopolize CICS because its processing does not involve any EXEC CICS commands that allows CICS to dispatch other tasks. In addition, heavy DB processing can cause other CICS tasks to hang until the processing is complete. In effect, these sort of CICS applications tend to behave like a batch program when it has a lot of orders to process. But, I'm confused by your statement that "we are getting 2033 errors every time we try to read other transaction (trigger) queues". Is it the Cobol program that's getting the 2033, or the VMS-MQ program, or the Natural program? Also, are you using expiry for the message your put to your "transaction queue"? "Kinzler, Raymond C" To: [EMAIL PROTECTED] <RaymondCKinzler cc: @EATON.COM> Subject: A novice question Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 02/11/2004 09:26 AM Please respond to MQSeries List Hello, I am NOT the MQ administrator for our company but I cannot seem to get a good answer to my question, so I thought I would sign up for this discussion group and hopefully get some answer. First, here is how I understand we use MQ Series in our shop: We re-wrote a fairly comprehensive on-line system that was written in NATURAL/ADABAS on the mainframe and put a web front end on it. All of the business logic remains on the back end written in NATURAL/ADABAS. These subsystems include things like Order Entry, Returns, etc. Our distributors access it over the web (doh!) and are using it quite heavily now. The screens are quite simple and there are never more than about 10-15 rows on a screen that need to be passed back-and-forth from the web to the mainframe. We wrote it to mimic an on-line system, obviously. The web creates data records for each 'row' on the screen. It PUTs them on what we call the DATA QUEUE which is NOT triggered. Once all of the records are on it, the web will PUT another record on what we call a TRANSACTION QUEUE which IS a triggered queue. This is where I get all weirded out. Somehow, this information is sitting on their respective queues on a Unix box. This information somehow gets over to the mainframe and I am not exactly sure of everything that happens to do this. But when a record arrives on the corresponding TRANSACTION queue on the mainframe, it triggers a CICS transaction that kicks off a COBOL program to determine the queue that has the record and then kicks off another CICS transaction to start an instance of NATURAL and run a program (called VMS-MQ) that will read the TRANSACTION record. Within the TRANSACTION record, the web includes the NATURAL program it wants to use to process the DATA records. VMS-MQ will do the following: 1.) Open the transaction queue 2.) Read the transaction queue 3.) Close the transaction queue (so another instance of VMS-MQ can be initiated just in case another transaction record arrives on the same transaction queue before the processing of the current transaction is complete) 4.) Kick off the passed NATURAL program which will, in turn, exhaust the data record from the data queue and, if needed, PUT data records to the DATA REPLY queue (which passes information back to the web application) 5.) Control returns to VMS-MQ which will then PUT a record to the TRANSACTION REPLY queue 6.) Then all open queues are closed. Somehow, again, the information on the REPLY queues gets sent back to the Unix box and the web application recognizes the TRANSACTION REPLY message and exhausts the DATA REPLY messages. (Again, we write all the data messages and then the transaction message to ensure we stay in sync.) The web starts a timer as soon as it writes the TRANSACTION REQUEST message. It waits up to 30 seconds for the corresponding TRANSACTION REPLY to come back. If it does not appear within 30 seconds, the web will abend and display a screen that says it has timed out. However, that does not mean the business logic hasn't been performed or won't be performed; it just means the mainframe didn't respond in a timely manner. ----- I hope I explained that well enough. Everything worked hunky-dory. We had a problem for a while where many messages were arriving on the same set of queues and we were processing them in a single-thread manner. We found that if we close the transaction (trigger) queue as soon as we extract a message, another instance of our extract program (VMS-MQ) will be kicked off and start another process even while the first one is running. Good. Good. Everything is working exactly like we want it to work. However, somebody recently came up with a new application they want to include on the web front-end. They want to be able to parse an Excel file that contains roughly 8,000-10,000 rows on a normal basis using this method. They pass 500 rows at a time which corresponds to 500 data request messages and one transaction request (trigger) message. They pass this through to the mainframe and all the mainframe does is read the records and post them to an ADABAS file--no auditing occurs during the initial load of the file. When the mainframe is done, it passes ONE data reply message back and the web passes the next 500 data request messages with another transaction (trigger) message. Here is the problem: When this process starts, it takes over. It has its own set of queues that are shared by no other application. But when it runs, it gets to the point that things seem like they are getting, well, clogged. Eventually, nothing else runs. But the strange thing is that we are getting 2033 errors every time we try to read other transaction (trigger) queues. It is almost like MQ said it sent a message to the mainframe but the message died on it's way to the mainframe and by the time the mainframe reads the transaction (trigger) queue, there is nothing there. Does this sound normal? Did I explain it enough to make a guess? Here is what I know about the trigger queue: 1.) It is trigger first 2.) Trigger depth is 1 3.) Index type is none 4.) Message delivery is FIFO Again, there is probably more you need to know but all I can see are the QLOCAL queues on the mainframe. Any opinions 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