| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Starting Transactions in CICS |
« View previous topic :: View next topic » |
| Author |
Message
|
| shlomoe |
 Posted: Thu Nov 01, 2007 6:14 am Post subject: Starting Transactions in CICS |
 |
|
Newbie
Joined: 11 Mar 2003
Posts: 7
|
Environment:
Z/OS 1.7
WMQ V6
CICS/TS 2.3
Starting Transactions in CICS:
In order to start transactions in CICS (request/reply model) we use a home written CICS/MQ bridge.
This bridge is a "long running" task working in a CICS TOR.
The bridge is working in the following way:
It MQGET(browse next) from a WMQ local queue of requests
and does an "exec cics start tranid('xxxx') from(data)".
The request is a message consists of CIH + application data, part of the CIH is the tranid to start.
The data passed in the "exec cics start from" command contains the queue name to get the message from,and the messageid.
So when the new born transaction starts running in one of the CICS AOR'S it will first
"exec cics retrieve this data" MQGET the message using MQGET(destructive), perform the business logic and reply the client over WMQ as well.
This model works fine most of the time,
but sometimes during a peak of workload
this long running transaction(the cics/mq bridge) tends to skip some messages (probably because they are not commited yet).
It means that once in a while we dont issue the "exec cics start"
as required.
Our request messages are longer then 32k so we can't MQGET(destructive) and pass the whole message in the "from area".
I would appreciate your opinion about this matter, is there any modification to the above described model or a different "safer" model we can use??
Regards,
SHLOMO. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Nov 01, 2007 6:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well, an uncommitted message shouldn't be "skipped". it should be read by the first GET that occurs after it's committed - assuming that GET is eligible to receive the message.
You are using standard design practices to read the first message off the queue, and loop until you get a 2033, right?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 01, 2007 2:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| It MQGET(browse next) from a WMQ local queue of requests |
Working as designed. If the message was not in a getable state it will not be included in the browse list and you can obviously not get it with (browse next) even if it has become available since... 
This is why browsing is a waste of time. Just get the next available message!
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Nov 02, 2007 12:41 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You could issue the MQGET, first obtaining storage to hold the message, and pass a pointer (in the commarea) to this storage area where you have placed the message.
The transaction can read this storage (and then free it). |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Fri Nov 02, 2007 2:35 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Destructively get the message,
Store the message in a CICS container
Start your transaction
Transaction retrieves message from container.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| rtsujimoto |
| Posted: Fri Nov 02, 2007 6:05 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004
Posts: 119
Location: Lake Success, NY
|
| Bob, what happens if the message is critical and the app in the AOR abends? The message can't be rolled-back at this point, so we've lost the integrity aspect of MQ processing. Granted, the TOR-AOR relationship raises complexities, but if we pass the message off to another system and it's integrity must be maintained, then we have to do it in a manner that allows for it's recoverability. I think the design mistake is involving the TOR in the first place. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Fri Nov 02, 2007 6:34 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Have a look at the container support in CICS BTS, you can define that a transaction and its containers are recoverable.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| amisinai |
| Posted: Tue Nov 06, 2007 10:40 am Post subject: |
|
|
Novice
Joined: 17 Aug 2007
Posts: 10
Location: Israel
|
Hi Shlomo,
There's another model I've heard of, but never used.
For each request, you can put 2 messages, with the same message id, one for the mq bridge with the transaction code, and the other containing the applicational data in another queue for the transaction.
The mq bridge will get all the messages in the queue a start the transaction while passing it the message id. The transaction gets it's message from the other queue according to the message id.
Personaly I hate this model (because of the 2 messages per 1 request), but I've heard it works very well in several installations...
Regards,
Avichai |
|
| Back to top |
|
|
| shlomoe |
| Posted: Thu Nov 08, 2007 12:31 am Post subject: |
|
|
Newbie
Joined: 11 Mar 2003
Posts: 7
|
First of all i like to thank you all for your advise, its certainly gave us new ideas how to deal
with the our "browse problem".
We would like to share our thoughts of two different solutions we came up with,
and hear your professional opinions about them:
A comment first: TOR-AORS environment is a must for us since we use CICSPLEX/SM to distribute workloads,
and the peer-to-peer method (a pool of AORS, but started transactions will mostly work locally)
doesn’t suit us so we have to stick to traditional "HUB" model(TOR-AORS).
1. First solution: our bridge will stop browsing the request queue every xxx seconds open the queue again,
and start browsing from the beginning so that messages that were skipped will be browsed now.
(will "exec cics start" only if the backout count is 0),
(quite similar to the answer we got from "amisinai".....)
2. Second solution: The clients will divide the request message, the "CIH" itself will be put to queue A and the rest of
data will be put on queue B,both puts with the same msgid and in the same UOW, the bridge will destructively get messages
from queue A, and then "exec cics start tran(aaaa) from(data)".
The new transaction that will start in one of the AORS will first retrieve the data send to it in the "FROM" area
then it will get the relevant message from queue B.
Best Regards,TIA. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
