Personally I'd go with one queue manager per lpar requiring MQ's
facilities, supporting both shared and non-shared queues. Aside from the
63k upper limit on messages I'd be looking at expected message lifetime as
the other major criteria for deciding on whether or not a queue should be
shared or not. Given the finite resources in your coupling facility I'd
start slowly picking the best candidates for sharing a couple at a time.
Select your highest throughput request/reply pairs of queues and test
thoroughly in your Test/Dev lpars before moving to production also
gathering response time statistics and any decrease in utilisation of
TCPIP, DASD subsystem etc.. If queue sharing is truly effective for you
then you can consider upgrading your coupling facility.
Regards
Tim A
"Perfetto, Ed"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
INC.COM> cc:
Sent by: MQSeries Subject: Shared and non-shared ques on
a single que manager?
List
<[EMAIL PROTECTED]
N.AC.AT>
04/04/2003 05:26
Please respond to
MQSeries List
New subscriber here!!
Can you or can you not have shared and non-shared ques on a single que
manager?
We're trying to overcome the 63K limits in a sysplex environment and have
decided to have multiple que managers, some shared(<63K) and others
not(>63K).
Thanks,
Ed.
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
