MQSeries.net :: View topic - MQSeries

babu_murugesan · Posted: Wed Nov 22, 2006 2:11 pm Post subject:

Hi All,

I have few questions about the MQSeries- CICS design. Can you please answer for these questions.

Assume:
Up to 2000 concurrent users to be supported.
MQ listener program written in COBOL, started by CICS when message arrives in an initiation queue.

1. Single request queue vs. multiple queues:
Will a single request queue cause any performance bottleneck ?
Would having a different request queue for each type of message (ultimately up to approx. 1000, but initially about 150) cause problems for CICS i.e. having multiple trigger monitor running using up CICS resources ?

2. Message reading:
Our current messaging system via APPC on LU6.2 receives the message in chunks dynamically allocating memory to store it as required.
It looks as if with MQ we read the entire message at once. This means that we will have to statically allocate the maximum possible amount of memory required for a message in our MQ listener program. (The MQ listener is triggered from the initiation queue for every new message).
This means that every CICS transaction will have lots of potentially redundant memory allocated for it, for the duration of the MQ listener transaction.
At what sort of maximum message size would this become a problem ?

One possible way around this would be to have different types of message written to different request queues and inquire on the queue before we read the message to get the maximum message length for that queue. Memory would then be allocated dynamically for that maximum size.
Is this a viable solution ?

Alternatively, if we read a message then discover it is too long for our receiving variable, we could allocate more memory then try and read it again. Is there any guarantee that we can re-read the same message ? Can it be â€˜lockedâ€™ to prevent another process reading it (without performance implications?)

3. Message processing
We will be dealing exclusively with on-line transaction requests and have therefore decided to trigger the MQ listener every time a new request is received.
This will just read one request from the queue and have one attempt at processing it within any one invocation of the MQ listener.
Is this the best approach to adopt for on line request or should we have a program runs continually, monitoring the queue for messages and dispatching them ?

The MQ listener will simply be reading a message off a queue then starting another CICS transaction to process it. The only other scenario it is dealing with is the â€˜poison messageâ€™ one where we end up trying to process the same message more than once, this is being dealt with via the backout threshold that MQ keeps.
Are there any other scenarios that should be dealt with ?

4.Transaction id, userid :
We do not want all the transactions to run under the same CICS default non-terminal transid and userid.
The only way we can think of changing this is to start the correct transaction id under the userâ€™s userid (passed in the message header).
This involves setting up all the users as surrogates of the default userid in RACF.
CICS will do an authorisation check to RACF for each transaction â€“ does this have any performance implications ?
Is there a better way of achieving this ?

5.MQ setup :
In our test and development environments there are many CICS reqions.
Would you normally have one instance of MQ running per CICS region, or one MQ to cover many CICS regions ?
If the later is the case we would need to have some environment specific part to each queue name â€“ this would need to be derivable at run time to avoid having to change the code (or configuration tables) as we promote through different environments.

6.Security :
The stateless, asynchronous messaging approach seems inherently less secure than
the stateful, session based way we currently employ.
What sort of security needs to be employed to ensure the system is at least as secure as at the moment ?

7.CICS Design - How would MQ work with CICS (TOR/AOR), MQ and CICS Work Load manager integration?

Please let me know your valuable comments .

Thanks,
Babu M