Ray,
Does the Cobol program consume the message that lands on the Transaction
queue? Or, does just (somehow) figures out which DATA queue is involved
and then starts an instance of VMS-MQ, so that it can process the message
on the Transaction queue?
"Kinzler,
Raymond C" To: [EMAIL PROTECTED]
<RaymondCKinzler cc:
@EATON.COM> Subject: Re: A novice question
Sent by:
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
02/11/2004 11:15
AM
Please respond
to MQSeries List
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
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
