* when installing MQ Server, do install MQ Client also. It is very useful to connect to remote sites.
* naming convention (MD00, GG24-4469 and MD04)
See Intercommunication manual for suggested naming conventions
o queue name max length = 48 chars (all MQ objects, except ...)
o channel name max length = 20 chars
* use ReplyToQ/ReplyToQMgr fields
* use REPLY type in response message
* use triggering if possible. Use TRIGGER FIRST. TRIGGER EVERY only if needed. Avoid TRIGGER DEPTH.
* do not use persistence if possible
* copy Message_Id into Correl_Id field to correlate response to request
* request a Report if your message is rejected or expires.
* know the default queue manager and verify it exists - used by runmqsc -w
* MQ & clustering :
o define a Qmgr to be exclusively FR1 and another Qmgr to be FR2
o use 2 (and no more) Full Repositories
o make sure both FRs have a Cluster Sender Channel to the other FR
* MQ under HACMP :
o use virtual IP in "IPADDR( )" at listener definition
o use separated disks for Data & Log - better performance
o if cluster is used, place FR's on HACMP machines
* MQ for MB :
o increase LOG size, as default MQ log for Windows is not enough to deploy a 500KB bar file
o increase CM 2 BK channel message length; otherwise flows wont be deployed. Easiest way is: immediately after creating the queue manager, ALTER the MAXMSGL attribute of SYSTEM.DEFAULT.LOCAL.QUEUE, SYSTEM.DEF.SENDER, SYSTEM.DEF.RECEIVER, SYSTEM.DEF.CLUSSDR, and SYSTEM.DEF.CLUSRCVR. Even better: have a script to create queue managers for MB that does log size and MAXMSGL automatically.
* naming convention (MD00, GG24-4469 and MD04)
See Intercommunication manual for suggested naming conventions
o queue name max length = 48 chars (all MQ objects, except ...)
o channel name max length = 20 chars
* use ReplyToQ/ReplyToQMgr fields
* use REPLY type in response message
* use triggering if possible. Use TRIGGER FIRST. TRIGGER EVERY only if needed. Avoid TRIGGER DEPTH.
* do not use persistence if possible
* copy Message_Id into Correl_Id field to correlate response to request
* request a Report if your message is rejected or expires.
* know the default queue manager and verify it exists - used by runmqsc -w
* MQ & clustering :
o define a Qmgr to be exclusively FR1 and another Qmgr to be FR2
o use 2 (and no more) Full Repositories
o make sure both FRs have a Cluster Sender Channel to the other FR
* MQ under HACMP :
o use virtual IP in "IPADDR( )" at listener definition
o use separated disks for Data & Log - better performance
o if cluster is used, place FR's on HACMP machines
* MQ for MB :
o increase LOG size, as default MQ log for Windows is not enough to deploy a 500KB bar file
o increase CM 2 BK channel message length; otherwise flows wont be deployed. Easiest way is: immediately after creating the queue manager, ALTER the MAXMSGL attribute of SYSTEM.DEFAULT.LOCAL.QUEUE, SYSTEM.DEF.SENDER, SYSTEM.DEF.RECEIVER, SYSTEM.DEF.CLUSSDR, and SYSTEM.DEF.CLUSRCVR. Even better: have a script to create queue managers for MB that does log size and MAXMSGL automatically.
I know that you wrote this article in a hurry long time ago. But could you please rewrite it? It contains many valuable information but some abbreviations and the shorthand makes it very difficult to understand and read.
ReplyDeletePlease consider this...