You should download the MQ error codes PDF file from IBM. I think you are biting on a false error. Check your logs for times when your big process isn't running, to see if you can find 2033 return codes at those times, since, if I'm reading things right, you may get 2033 once your trigger process has nothing more to read on the queue.
Otherwise, I'd check to see if something else was failing to complete, maybe the queue manager (or whatever) on your front end system is reporting some failure when trying to put messages on the remote queue (aka the local queue on the mainframe). To quote IBM (and since I don't completely know how to paraphrase it): MQRC_NO_MSG_AVAILABLE An MQGET call was issued, but there is no message on the queue satisfying the selection criteria specified in MQMD (the MsgId and CorrelId fields), and in MQGMO (the Options and MatchOptions fields). Either the MQGMO_WAIT option was not specified, or the time interval specified by the WaitInterval field in MQGMO has expired. This reason is also returned for an MQGET call for browse, when the end of the queue has been reached. This reason code can also be returned by the mqGetBag and mqExecute calls. mqGetBag is similar to MQGET. For the mqExecute call, the completion code can be either MQCC_WARNING or MQCC_FAILED: - If the completion code is MQCC_WARNING, some response messages were received during the specified wait interval, but not all. The response bag contains system-generated nested bags for the messages that were received. - If the completion code is MQCC_FAILED, no response messages were received during the specified wait interval. Corrective action: If this is an expected condition, no corrective action is required. If this is an unexpected condition, check that: - The message was put on the queue successfully. - The unit of work (if any) used for the MQPUT or MQPUT1 call was committed successfully. -----Original Message----- From: Kinzler, Raymond C [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 9:27 AM To: [EMAIL PROTECTED] Subject: A novice question 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 This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. 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
