| Author |
Message
|
| cicsprog |
 Posted: Tue May 11, 2004 7:40 am Post subject: Yikes-New 60 msgs a second MQ Application-Config Question |
 |
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
I have 12 existing MVS MQM’s with several CLUSTERS in each (using a NAMELIST for Full-Repos MQM’s). Two are Full-Repos and others are Partial-Repos. There are many non-MVS MQM’s connecting into these CLUSTER’s as Partial-Repos. On MVS MQM’s, I have one CLUSTER Receiver channel for each MQM and CLUSTER Senders to connect Partial’s to Full’s. The two Full-Repos have CLUSTER Sender’s to connect the CLUSTER’s.
I have a new high volume application coming in – 60 messages a second going out of the MVS MQM’s to two Windows MQM’s. They want to use CLUSTERing and their messages will be Persistent.
So on MVS:
TO.MQnn.00 ç=== CLUSTER Receivers
TO.MQnn.00 ç=== CLUSTER Senders
SYSTEM.CLUSTER.TRANSMIT.QUEUE
My question is: Is there any advantage to setting up separate CLUSTER Sender and Receivers for this high volume CLUSTER? For example:
TO.MQnn.01 ç=== New CLUSTER Receivers
TO.MQnn.01 ç=== New CLUSTER Senders
SYSTEM.CLUSTER.TRANSMIT.QUEUE
I have real concerns about Windows handling 60 messages a second and should a problem occur, my SYSTEM.CLUSTER.TRANSMIT.QUEUE stacking up with messages. Maybe a separate PAGESET for SYSTEM.CLUSTER.TRANSMIT.QUEUE?
Can you create a separate SYSTEM.CLUSTER.TRANSMIT.QUEUE for this high volume CLUSTER? |
|
| Back to top |
|
 |
| offshore |
| Posted: Tue May 11, 2004 8:57 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
CICSPROG,
I don't think creating another cluster sender channel will help you out in this circumstance.
Reguardless of how many cluster sender channels you define if TCP/IP (I'm assuming you're using TCP/IP) goes belly up the message will accumulate up on the SYSTEM.CLUSTER.TRANSMIT.QUEUE.
The only way I see a benefit is if the additional cluster sender channel defined are using a different protocol such as LU 6.2. If TCP went down, then its possible that the LU 6.2 defined channel could start up and continue passing messages.
As for the page_data set. How big is it now? What PSID/STGCLASS is the SYSTEM.CLUSTER.TRANSMIT.QUEUE defined to?
1.]Find out what queue(s) are assigned to a specific stgclass
DIS QUEUE(queue_name or "*" for all queues) STGCLASS
2.]Once you find out what stgclass the queue is assigned to, check the page_dataset/bufferpool information
DIS USAGE PSID(*)
The Restart Extents & Expand Counts are the fields of concern on this panel.
If the restart extends are high, then you will want to either:
1.] Make that particular VSAM PSID larger.
2.] Create different STGCLASSes (16 is the max) and PSID's (99 is the max) and distribute the queues among the newly created STGCLASSes.
If the Expand Count is high, then you need to increase the bufferpool sizes for that particular page_dataset.
To see all STGCLASS and what PSID they're assigned to the, issue the DIS STGCLASS(*) PSID(*).
HTH |
|
| Back to top |
|
|
| cicsprog |
| Posted: Tue May 11, 2004 9:46 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Thanks for that reply. Opps forgot to mention the TCP part.
I am aware of all the other things you mentioned but appreciate that info regardless.
Maybe its time to isolate SYSTEM.CLUSTER.TRANSMIT.QUEUE on its own pageset? Seems as if that XMITQ is a single point of failure for all CLUSTERs in the MQM. One rogue CLUSTER app could stop all other CLUSTERs apps out bound msgs should the PAGESET fill. |
|
| Back to top |
|
|
| JLRowe |
| Posted: Tue May 11, 2004 1:31 pm Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
| Enable channel pipelining to get more throughput over the channels. |
|
| Back to top |
|
|
| TonyD |
| Posted: Tue May 11, 2004 2:37 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
| Separate to the cluster queue and channel considerations make sure that the MQ logging subsystems on the participants are able to cope, particularly if the messages are largish. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Tue May 11, 2004 3:49 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
ETR'd IBM....can't create a second instance of SYSTEM.CLUSTER.TRANSMIT.QUEUE....that was NOT a surprise (maybe we need a customer enhancement?). Anyway, they recommended isolating pageset also.
Average msg size is 18k. This app will have a unique CLUSTER name for sure. Not familiar with pipelining...I'll do some reading.
Since we don't Centralize MQ admin, the distributed guys scare the heck out of me. Sorry Mr. Gates....my message through-put MVS to Windows will bury you (didn't Premier Khrushchev say that).
Keep any ideas comin....I'm very scared of MVS to Windows at 60 messages a second. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue May 11, 2004 7:10 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| cicsprog |
| Posted: Wed May 12, 2004 3:11 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
"And do the message reaaallly need to be persistent?"
I always ask the app folks that also. These messages are the result of an IMS order entry system where some of Database data now lives on Windows. So as orders are taken/revised these messages oneway flow to that database.
I once had the time to keep up with all of MQ doc...but regretably I am now lone support for 60 MVS MQM's and now have WAS for z/OS config and support. WAS is not for the faint of heart. I have no life anymore. |
|
| Back to top |
|
|
|
|
