Keith,
in short you have described the shortcommings of trigger type every.
if you change to trigger first, and run your current transaction, what you
would get is a single transaction for each message. but the transactions
would be effectively single threaded, and you have the possiblily of a
single message causing a trigger loop if it can not be removed by your
application.
What you probably want, is something known as a System Initiation Layer.
What you need to do is trigger first your SIL.
This application then browses your queue (with a getwait), and starts a
transaction for each message on the queue. Store the transid to be
started in one of the fields passed in the trigger message
Since you want to associate a transaction with a message, you probably
want to pass the correlid and msgid to the application program, so it
knows which message to process.
You also want to add some logic to put messages that are not being
processed into a backout queue.
And since you are starting the transactions, you probably don't want to
run them with the CICS System Userid. Instead use an application
userid, or possibly get the userid from the message header and us it to
start the transaction.
If you use the useid from the msgheader, you'll want to check with RACF
(ACF2 or TopSecret) to verify the user has the authority to run the
transaction.
You may also want to check the TRANCLASS of the transaction to prevent
it from overloading CICS with work. IE. issue a CICS DELAY if it is
already at MAXTRANCLASS, or if the QUEUEd number is close to the
PURGEThreshold.
These are the most common things that have been discussed here.
glen larson
Zurich North America
"Keith A. Hessong" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 09/19/2002
02:03:23 PM
Please respond to MQSeries List <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Running MSMQ on Server Side to MQSeries on Mainframe Side using
a Bridge Design Question
I am currently trying to design a new application for MQ running MSMQ on
the Server Side
and MQSeries on the Mainframe Side using a Bridge to communicate in
between.
Let's say that I am writing queue records on the Server side to an MQSERIES
queue on the Mainframe Side.
Let's say the queue that I am writing to is a Local Queue called
XX_XXXXXX.TEST whose Trigger Type is EVERY
and whose Trigger Set is Yes which points to a process which kicks off a
transaction called ABCD in CICS.
Transaction ABCD points to program KKKK001 which does an MQGET for only one
record and returns processing
to CICS. The Local Queue also has PERMIT SHARED ACCESS = YES and DEFAULT
SHARE OPTION = SHARED.
I want to run with a TRIGGER TYPE of EVERY so that we can run multiple ABCD
transactions at the same time.
We are planning on TCLASSING transaction ABCD in CICS.
Let's say that the SERVER SIDE writes 5 records to the LOCAL QUEUE but
transaction ABCD is disabled in CICS
and transaction ABCD is triggered 5 times because of EVERY and the 5
records remain on the LOCAL QUEUE. The
next thing I know my CICS region comes down and comes back up with
transaction ABCD reenabled.
My problem is how do I get the 5 records that remained on the LOCAL QUEUE
off of the LOCAL QUEUE when my
CICS region comes back up. I have been told that I must leave the Trigger
Type to EVERY for processing purposes for
the LOCAL QUEUE in question. I have been told that I can for a short while
modify the Trigger Type to FIRST on the LOCAL
QUEUE to get the records off and convert it back to EVERY. I know that I
could write a PLT program to set the Trigger Type
to FIRST. This would cause transaction ABCD to run and get the 5 records
off of the queue because program KKKK001 would have
logic in it to check for TRIGGER TYPE = FIRST and if so loop on the MQGET
until running out of records and than I would set the Trigger Type back to
EVERY. Program KKKK001 would only do one MQGET and return to CICS if the
Trigger Type = EVERY.
I presented this as a possible solution and was told what if the records
are left on the queue at the end of the previous business
day what will happen. I was told that this probably wouldn't work because
my company is expecting a lot of records to be
sitting out on this local queue when the system comes back up and setting
the Trigger Type to FIRST in the PLT could cause
transaction ABCD to run forever because of the MQGET loop. This would get
the 5 remaining records off of the queue but
the volume of new records waiting on the LOCAL QUEUE might not allow me to
get the TRIGGER TYPE = EVERY back very
quickly and thus doesn't allow us to run multiple transactions ABCD at the
same time while the TRIGGER TYPE = FIRST.
They also didn't like the above solution because you would have duplicate
code in one program. One set of code to process
only one MQGET and another set of code to process an MQGET loop.
I had also thought about writing the 5 remaining records to another queue
using a BATCH JOB while the CICS region is down
at night and have the new local queue run with a Trigger Type = FIRST
triggering transaction called EFGH. This would allow the
five remaining transactions to run when the CICS region came back up as
well as giving us the capability to process the new queue
members on the old LOCAL QUEUE using EVERY and being able to run multiple
ABCD's at the same time. I was told they
didn't like this solution because we would have more than one CICS program
processing code for the same queue which means
double maintenance if something needs to be changed.
Anybody have any ideas concerning this situation at hand?
Thanks,
Keith
******************* PLEASE NOTE *******************
This E-Mail/telefax message and any documents accompanying this
transmission may contain privileged and/or confidential information and is
intended solely for the addressee(s) named above. If you are not the
intended addressee/recipient, you are hereby notified that any use of,
disclosure, copying, distribution, or reliance on the contents of this
E-Mail/telefax information is strictly prohibited and may result in legal
action against you. Please reply to the sender advising of the error in
transmission and immediately delete/destroy the message and any
accompanying documents. 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
