| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Connectivity options for MQ & CICS |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjcarretero |
 Posted: Tue Dec 18, 2007 1:02 am Post subject: Connectivity options for MQ & CICS |
 |
|
Voyager
Joined: 13 Oct 2003
Posts: 88
|
Hi all,
First, I am totally new to mainframe architectures. I have experience with MQ in open systems.
In open systems, triggering is an appropriate option when you have low volume. When you have high volume, the correct strategy is polling.
Is there an equivalence on mainframes? What is the difference between using triggering ang the CICS Bridge?. If I have a transactions written in Natural language should I take a different approach?.
TIA
Felipe |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Dec 18, 2007 1:35 am Post subject: Re: Connectivity options for MQ & CICS |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjcarretero wrote: |
| First, I am totally new to mainframe architectures. I have experience with MQ in open systems. |
This won't get you too far. There are significant differences between the implementation of MQ on z/OS and open systems. I urge you to invest some time with the z/OS manuals.
| fjcarretero wrote: |
| In open systems, triggering is an appropriate option when you have low volume. When you have high volume, the correct strategy is polling. |
I'd disagree. The correct strategy is always triggering, it's a question of how many instances you trigger. This is a good example of the difference between z/OS and open systems, as a CICS transaction is perhaps the only instance where trigger type EVERY can be a good solution (properly implemented of course!!)
| fjcarretero wrote: |
| Is there an equivalence on mainframes? |
Yes - there are trigger monitors supplied for CICS and batch.
| fjcarretero wrote: |
| What is the difference between using triggering ang the CICS Bridge?. |
2 different technologies for 2 different solutions. RTM which explains it better than I could (even if there was space in this post!)
| fjcarretero wrote: |
| If I have a transactions written in Natural language should I take a different approach?. |
Abandon it and rewrite it in a proper language? Natural? I've not heard of that in years! You do mean the Adabas product don't you? Is it still going?
(Suddenly I feel like I have hair again - sliding back in time......)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Dec 18, 2007 3:37 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Don't Poll, Never Poll, Do not Poll....
Use a long-running task using MQGET with WAIT. Loop back for the next message after processing each one. Use multiple tasks for scalability.
This makes a proper event driven design with no latency and miminal overhead.
Polling introduces latency and overhead.
Triggering is NOT correct for high volumes, as it introduces extra gets and puts (to the initiation queue). Also it causes programs to be constantly started and stopped instead of remaining in memory and processing messages as they arrive (MQGET with WAIT).
So, triggering for intermittent arrival of messages (don't want to waste resources waiting for messages). Long running GET WAITs for frequent arrival of messages (don't want trigger overheads). Polling - generally never but I suppose scheduled jobs once a day is OK. |
|
| Back to top |
|
|
| fjcarretero |
| Posted: Tue Dec 18, 2007 4:52 am Post subject: |
|
|
Voyager
Joined: 13 Oct 2003
Posts: 88
|
Thank for the responses.
I agree Natural/Adabas is far from being the perfect environment!!
Do you know if the performance MQ for Natural API is good? I'm thinking if it is a good idea to write the module that reads the messages from the queue in Natural.
Cheers.
Felipe |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Dec 18, 2007 6:35 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I don't think the language matters, the underlying MQI (API) calls are the same anyway.
Good practice with MQI calls is what matters, eg
Don't connect to the QM or open a queue for each message.
Reconnect automatically (15 sec pause) if the QM connection breaks.
Use MQGET with WAIT instead of "polling" for next message.
Use MQGET with CONVERT to ensure cross-platform compatible.
Specify SYNCPOINT options explicitly.
Set MQMD.Format to MQSTR (in most cases) for MQPUTs
Make sure MQMD.CCSID matches the data codepage when MQPUTing.
Handle recoverable MQI return codes properly (2033,2016,2119,2080 etc)
Report all other "fatal" MQI codes and restart after a pause or terminate.
Here are my favourite 10 commandments:
1. Setting correct MQMD fields on MQPUT, in particular Format (MQSTR), message data to match the CCSID, Persistence, Expiry (if non-persistent)
2. Correct use of MQGET options, in particular SYNCPOINT, CONVERT, WAIT, FAIL_IF_QUIESCING.
3. Appropriate use of MQCONN and MQDISC, in particular number of and re-use of connection handles.
4. Appropriate use of MQOPEN and MQCLOSE, in particular keeping queues open where possible.
5. Unit of work control, including backout count inspection and use of backout re-queue queues.
6. Ability to handle queue manager shutdown, failover and restart situations without manual intervention.
7. Appropriate mode of MQI calls (ie not excessive "polling" or inappropriate triggering).
8. Ability to handle large message volumes without problems (appropriate thread management, scalability).
9. Confirmation that MQ and MQI configuration information is not hard-coded in the application.
10. The application handles common MQI return codes and logs any "unexpected" ones. |
|
| Back to top |
|
|
| fjcarretero |
| Posted: Tue Dec 18, 2007 7:34 am Post subject: |
|
|
Voyager
Joined: 13 Oct 2003
Posts: 88
|
|
| Back to top |
|
|
| cschneid |
| Posted: Tue Dec 18, 2007 9:27 am Post subject: |
|
|
Novice
Joined: 22 Mar 2005
Posts: 13
|
| I suggest you look at the MA1K SupportPac and see if there is something you can use. |
|
| 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
|
|
|
|
