Backup Queue Manager
Creating a backup queue manager ======================== 1. Create a backup queue manager for the existing queue manager using the control command crtmqm. The backup queue manager requires the following: * To have the same attributes as the existing queue manager, for example the queue manager name, the logging type, and the log file size. * To be on the same platform as the existing queue manager. * To be at an equal, or higher, code level than the existing queue manager. 2. Take copies of all the existing queue manager’s data and log file directories, including all subdirectories, as described in Backing up queue manager data. 3. Overwrite the backup queue manager's data and log file directories, including all subdirectories, with the copies taken from the existing queue manager. 4. Execute the following control command on the backup queue manager: strmqm -r BackupQMName This flags the queue manager as a backup queue manager within WebSphere® MQ, and replays all the copied log extents to bring the backup queue manager in step with the existing queue manager. Starting a backup queue manager ======================= 1. Execute the following control command to activate the backup queue manager: strmqm -a BackupQMName The backup queue manager is activated. Now active, the backup queue manager can no longer be updated.
2. Execute the following control command to start the backup queue manager: strmqm BackupQMName 3. Restart all channels Note: stop the existing Qmgr using endmqm -w, before copying the qmgr date to backup qmgr
MQSeries Triggering Questions
What is Triggering? Ans: Web Sphere MQ enables you to start an application automatically when certain conditions on a queue are met. For example, you might want to start an application when the number of messages on a queue reaches a specified number. This facility is called triggering How many ways of Triggering? EVERY: A trigger event occurs every time that a message arrives on the application queue. Use this type of trigger if you want a serving program to process only one message, then end. FIRST: A trigger event occurs only when the number of messages on the application queue changes from zero to one. Use this type of trigger if you want a serving program to start when the first message arrives on a queue, continue until there are no more messages to process, then end. DEPTH: A trigger event occurs only when the number of
messages on the application queue reaches the value of the TriggerDepth attribute.
What are the Trigger types available Explain? a. Application triggering b. Channel Triggering a) In the case of application triggering the components are Application queue: This is the message queue associated with an application Process: A process definition defines the application to be used to process messages from the application queue. Initiation queue: The queue manager moitors the application queue. If the trigger type of the application queue is set to Every then whenever a message is put to the application queue, the q manager looks into the process definition and puts a message having the application name and other details to the initiation queue Trigger monitor: The trigger monitor gets the trigger message from the initiation queue and starts the program specified. b) For channel triggering the transmission queue is monitored and when messages are put in the transmission queue, the q manager puts a message in the channel initiation queue. The channel initiator is the program which monitors the initiation queue and starts the sender MCA. For the message to reach the target queue, the channel listener has to be running in the target queue manager Channel Triggering Conditions: · Trigger ON
· Trigger type(first every depth) · Trigger data(channel name which is to be fired) · Initiation queue(SYSTEM.CHANNEL.INITQ)
Channel Triggering Background process: 1. The local queue manager places a message from an application or from a message channel agent (MCA) on the transmission queue. 2. When the triggering conditions are fulfilled, the local queue manager places a trigger message on the initiation queue. 3. The long-running channel initiator program monitors the initiation queue, and retrieves messages as they appear. 4. The channel initiator processes the trigger messages according to information contained in them. This information may include the channel name, in which case the corresponding MCA is started. 5. The channel listener running in the target q mgr starts the receiving MCA Application Triggering Conditions: * Trigger ON * Trigger type (first every depth)
* Initiation queue (SYSTEM.DEFAULT.INITIATION.QUEUE our own defined local queue) * Process (NOTEPAD) DEFINE QLOCAL (LQ) TRIGGER TRIGTYPE (EVERY) INITQ (IQ) PROCESS (NOTEPAD). DEFINE PROCESS (NOTEPAD) APPLICID (NOTEPAD.EXE) APPLTYPE (WINDOWS) Runmqtrm –m QM1 –q IQ BACKGROUND PROCESS:1. When ever the message comes to triggered local queue, queue manager will fire trigger message with information called trigger type and the process definition (application which is to be triggered) in to the initiation queue (IQ) (our own queue). 2. At the initiation queue a long running time program called trigger monitor will be watching (monitoring) the initiation queue. 3. Whenever the trigger message occurs in the initiation the trigger monitor will pick the information and starts the application which is defined in the process. What is a Trigger monitor? A trigger monitor is a continuously - running program that serves one or more initiation queues. When a trigger message arrives on an initiation queue, the trigger monitor retrieves the message. The trigger monitor uses the
information in the trigger message. It issues a command to start the corresponding application/channel command used for the running trigger monitor On Server side: runmqtrm -m QMName -q Initiation QueueName On Client side: runmqtmc -m QMName -q Initiation QueueName
Queue Manager Clusters and MQ Clustering
=> CLUSTERING Clustering is a way to logically group WebSphere MQ queue managers - reduced system administration due to fewer channel, remote queue, and transmission queue definitions - increased availability and workload balancing. => Basic Cluster setup > Step-1 Determine which queue manager should hold full repositories A full repository contains a complete set of information about every queue manager and object in the cluster You will need at least one, preferably two
> Step-2 Alter the queue manager definitions to add repository definitions ALTER QMGR REPOS(cluster_name) > Step-3 Define the CLUSRCVR channels Every queue manager in the cluster needs a CLUSRCVR with a conname pointing to itself. DEFINE CHANNEL(channel_name) CHLTYPE(CLUSRCVR) TRTYPE(TCP) CONNAME(‘my_ip_name_or_address(port)’) CLUSTER(cluster_name) > Step-4 Define the CLUSSDR channels Define one CLUSSDR to a full repository queue manager. The channel name must match that of the CLUSRCVR on the full repository DO NOT define a CLUSSDR to point to a partial repository. DEFINE CHANNEL(channel_name) CHLTYPE(CLUSSDR) TRPTYP(TCP) CONNAME(‘remote_ip_name_or_address(port)’) CLUSTER(cluster_name) > Step-5 Define a cluster queue DEFINE QLOCAL(qname) CLUSTER(cluster_name) Other queue managers in the cluster can send message to it without making remote-queue definitions for it. Only the local queue manager can read messages from an instance of the cluster queue You can use a sample program to test putting messages to clustered queues
=> Cluster Commands DISPLAY QMGR REPOS REPOSNL QMID AMQ8408: Display Queue Manager details. QMNAME(QM1) QMID(QM1_2005-07-12_17.14.38) REPOS(QMCLUS)REPOSNL( ) QMID is an internally generated unique name that consists of the queue manager name plus the time the queue manager was created DISPLAY CLUSQMGR(*) ALL Display cluster Queue manager details dis chstatus(*) all Display channel status details DISPLAY QCLUSTER(*) ALL It displays information about clustered queues only. A cluster queue will not be displayed on a partial repository until an application has opened it. DISPLAY QUEUE(*) CLUSINFO This command displays information about queues with TYPE(QCLUSTER) => Work load balancing When a cluster contains more than one instance of the same queue, workload balancing determines the best queue manager to route a message to - At its simplest, workload management results in a roundrobin effect MQ V6 has additional parameters that can be used to influence the results of the algorithm.
- Queues: CLWLPRTY, CLWLRANK, CLWLUSEQ - Queue Managers: CLWLUSEQ, CLWLMRUC - Channels: CLWLPRTY, CLWLRANK, CLWLWGHT, NETPRTY For workload balancing to occur: - open the queue with the MQOO_BIND_NOT_FIXED open option - open with the default MQOO_BIND_AS_Q_DEF and with DEFBIND(NOTFIXED) set in the queue definition - Leave MQMD.ObjectQMgrName blank to allow the queue manager to chose the queue instance - To force the message to a specific instance of the clustered queue, specify that queue manager’s name in ObjectQmgrName => Namelists in clusters - A queue manager may be a member of more than one cluster. List those clusters in a NAMELIST. - You can alter a full repository QMGR to use REPOSNL(namelist) rather than REPOS. - For channels and queues, you can specify CLUSNL(namelist) rather than specifying the CLUSTER parameter. => REFRESH CLUSTER - REFRESH CLUSTER removes and rebuilds locally held information about a cluster. - REFRESH CLUSTER(clustername) REPOS(NO) - REFRESH CLUSTER(clustername) REPOS(YES), also refreshes information about full repository queue managers and may not be issued from a full repository. - REFRESH CLUSTER(*)
=> RESET CLUSTER RESET CLUSTER is issued from a full repository queue manager. It forcibly removes a queue manager or specific QMID from a cluster. - RESET CLUSTER(clustername) QMNAME(qmname) ACTION(FORCEREMOVE) QUEUES(NO) - RESET CLUSTER(clustername) QMID(qmid) ACTION(FORCEREMOVE) QUEUES(NO) => Troubleshooting - Is the repository manager still running? Check the AMQERRxx.log or CHIN joblog. - Are channels able to run in both directions? Display CLUSQMGR and CHSTATUS information. - Are the SYSTEM.CLUSTER.* queues enabled? Issue DISPLAY QUEUE(SYSTEM.C*) ALL - Are there messages on SYSTEM.CLUSTER.COMMAND.QUEUE or SYSTEM.CLUSTER.TRANSMIT.QUEUE? - Are there duplicate QMIDs for a given QMGR? Issue DISPLAY CLUSQMG(*) QMID. - DISPLAY CLUSQMGR may show CLUSQMGR names starting with SYSTEM.TEMP. The queue manager has not received all necessary information from the full repository. Work Load Balancing in MQ
I believe you already had set up the cluster. Just try the following to understand the concept 1. Now create a ClusterQ on all the Queue Managers in a Cluser with same name
2. Now put a message on one of the queue managers and try to get the same message from other queue managers. you can GET message from a queue manager to which you are connected. example: ====== QM1,2,3,4 - Queuemanagers WLMQ - cluster queue on all 4 qms PUT message on WLMQ of QM1 connect to QM2 GET message from WLMQ of QM2 try the same for QM3,4 While putting messages: -----------------------------------
DEFBIND Specifies the binding to be used when the application specifies MQOO_BIND_AS_Q_DEF on the MQOPEN call, and the queue is a cluster queue. DEFINE QL(test) DEFBIND(OPEN) DEFINE QL(test) DEFBIND(NOTFIXED)) If bind on open (OPEN) is specified, multiple messages addressed to the name of this queue objectsent using the same object handle (a single MQOPEN) are delivered to the
same queue manager within a cluster. Otherwise, if bind not fixed (NOTFIXED) is specified, workload balancing occurs independently for each message sent. In MQopen call of amqsput/get program,if you see the open option consists of a definition called "MQOO_BIND_AS_Q_DEF" which is the default option, which means open the queue with the option as defined in the attribute DEFBIND If the attribute is NOTFIXED,then MQOPEN call will open the queue in BIND_NOT_FIXED mode.If it is OPEN,then MQOPEN call will open the queue in MQOO_BIND_ON_OPEN mode So to make Load Balancing happen, you need to put messages with "BIND_NOT_FIXED".
MQ Autherizations
MQseries provides authorizations(permissions) for the users in two levels 1. Qmanager level 2. Object level MQMgroup:- This group is automatically created by MQseries after installation. It also creates one user (MUSR_MQADMIN) The users should belong to MQM group so that they can
have all the permissions to administer MQ series.
COMMANDS TO SET AUTHORIZATIONS Setmqaut:- this command is used to set the authorizations. Syntax:- setmqaut[-m qmgrname] [-n objname] –t objtype [p principal /-g group] [-s service component ]
Dspmqaut :-to display the authorizations which are set to the queue manager. Syntax:-dspmqaut[-M qmgrname] [-n objname ] –t objtype [p principal/ -g group ] [-s service component] Dspmqaut –m QM1 –t qmgr –p XX(new user) The entity XX have the following authorizations for object QM1 • Inq • Connect • Altusr • Crt • Dlt • Chg • Dsp • Setid • Setall Object level :Syntax:Setmqaut –m QM1 –n LQ –t queue –pXX +put Dspmqaut –m QM1 –n LQ –t queue –p XX The setmqaut command completed successfully Semqaut –m QM1 –n(20.30) –t channel –pXX +allmqi Runmqsc QM1 Starting MQSC for queue manager 1
• REFRESH CLUSTER • REFRESH SECURITY(generally we refresh security) Result: web sphere security cache refreshed MQ Migration
MQ Migration ======== Migrating queue managers is generally a simple process, because WebSphere MQ is designed to automatically migrate objects and messages, and support mixed version clusters. However, when planning the migration of a cluster, you need to consider a number of issues, which are described below. Forward migration involves upgrading an existing queue manager to a later version and is supported on all platforms. You may wish to forward migrate in order to take advantage of new features or because the old version is nearing its endof-service date. Testing ---------It is important when making any system changes to test the changes in a test or QA environment before rolling out the changes in production, especially when migrating software from one version to another. Ideally, an identical migration plan would be executed in both test and production to maximise the chance of finding potential problems in test rather than production. In practice, test and production environments are unlikely to be architected or configured identically or to have the same workloads, so it is unlikely that the migration steps carried out in test will exactly match those carried out in production. Whether the plans and environments for test and production differ or not, it is
always possible to find problems when migrating the production cluster queue managers Plan ----When creating the migration plan, you need to consider general queue manager migration issues, clustering specifics, wider system architecture, and change control policies. Document and test the plan before migrating production queue managers. Here is an example of a basic migration plan for a cluster queue manager: 1. Suspend queue manager from the cluster. * Issue SUSPEND CLUSTER * Monitor traffic to the suspended queue manager. The cluster workload algorithm can choose a suspended queue manager if there are no other valid destinations available or an application has affinity with a particular queue manager. 2. Save a record of all cluster objects known by this queue manager. This data will be used after migration to check that objects have been migrated successfully. * Issue DISPLAY CLUSQMGR(*) to view cluster queue managers. * Issue DISPLAY QC(*) to view cluster queues. 3. Save a record of the full repositories view of the cluster objects owned by this queue manager. This data will be used after migration to check that objects have been migrated successfully. * Issue DISPLAY CLUSQMGR on the full repositories. * Issue DISPLAY QC(*) WHERE(CLUSQMGR EQ ) on the full repositories. 4. Stop queue manager. 5. Take a backup of the queue manager.
6. Install the new version of WebSphere MQ. 7. Restart queue manager. 8. Ensure that all cluster objects have been migrated successfully. * Issue DISPLAY CLUSQMGR(*) to view cluster queue managers and check output against the data saved before migration. * Issue DISPLAY QC(*) to view cluster queues and check output against the data saved before migration. 9. Ensure that the queue manager is communicating with the full repositories correctly. Check that cluster channels to full repositories can start. 10. Ensure that the full repositories still know about the migrated cluster queue manager and its cluster queues. * Issue DISPLAY CLUSQMGR on the full repositories and check output against the data saved before migration. * Issue DISPLAY QC(*) WHERE(CLUSQMGR EQ ) on the full repositories and check output against the data saved before migration. 11. Test that applications on other queue managers can put messages to the migrated cluster queue manager's queues. 12. Test that applications on the migrated queue manager can put messages to the other cluster queue manager's queues. 13. Resume the queue manager. * Issue RESUME CLUSTER 14. Closely monitor the queue manager and applications in the cluster for a period of time.
Backout plan ---------------A backout plan should be documented before migrating. It should detail what constitutes a successful migration, the conditions that trigger the backout procedure, and the backout procedure itself. The procedure could involve removing or suspending the queue manager from the cluster, backwards migrating, or keeping the queue manager offline until an external issue is resolved. Queue Manager Alias
Queue Manager Aliases enable you to refer to queue managers by more than one name. Queue manager alias definitions apply when an application that opens a queue to put a message, specifies the queue name and the queue manager name. Queue manager alias definitions have three uses: * When sending messages, remapping the queue manager name * When sending messages, altering or specifying the transmission queue * When receiving messages, determining whether the local queue manager is the intended destination for those messages.
Queue-manager aliases, which are created using a remotequeue definition with a blank RNAME, have four uses: Remapping the queue-manager name when sending messages
A queue-manager alias can be used to remap the queuemanager name specified in an MQOPEN call to another queue-manager. This can be a cluster queue manager. For example, a queue manager might have the queue-manager alias definition: DEFINE QREMOTE(YORK) RNAME(' ') RQMNAME(CLUSQM) This defines YORK as a queue-manager name that can be used as an alias for the queue manager called CLUSQM. When an application on the queue manager that made this definition puts a message to queue manager YORK, the local queue manager resolves the name to CLUSQM. If the local queue manager is not called CLUSQM, it puts the message on the cluster transmission queue to be moved to CLUSQM, and changes the transmission header to say CLUSQM instead of YORK. Note: This does not mean that all queue managers in the cluster resolve the name YORK to CLUSQM. The definition applies only on the queue manager that makes it. To advertise the alias to the whole cluster, you need to add the CLUSTER attribute to the remote-queue definition. Then messages from other queue managers that were destined for YORK are sent to the queue manager with the alias definition and the alias is resolved. Altering or specifying the transmission queue when sending messages
This method of aliasing can be used to join a cluster to a non-cluster system. For example, for queue managers in the cluster ITALY to communicate with the queue manager called PALERMO, which is outside the cluster, one of the
queue managers in the cluster must act as a gateway. From this queue manager, issue the command: DEFINE QREMOTE(ROME) RNAME(' ') RQMNAME(PALERMO) XMITQ(X) CLUSTER(ITALY) This is a queue-manager alias definition, which defines and advertises ROME as a queue manager over which messages from any queue manager in the cluster ITALY can multi-hop to reach their destination at PALERMO. Any message put to a queue opened with the queue-manager name set to ROME in the open handle, is sent to the gateway queue manager, where the queue manager alias definition was made. Once there, it is put on the transmission queue X and moved by conventional, non-cluster channels to the queue manager PALERMO. The choice of the name ROME in this example is not significant. The values for QREMOTE and RQMNAME could both be the same. Determining the destination when receiving messages When a queue manager receives a message, it looks in the transmission header to see the name of the destination queue and queue manager. If it has a queue-manager alias definition with the same name as the queue manager referenced, it substitutes the RQMNAME from its definition for the queue manager name in the transmission header.
There are two reasons for using a queue-manager alias in this way: To direct messages to another queue manager •
To alter the queue manager name to be the same as the local queue manager •
Using a queue manager as a gateway into the cluster. This enables workload balancing for messages coming from outside the cluster.
Suppose you have a queue called EDINBURGH on more than one queue manager in the cluster, and you want the clustering mechanism to balance the workload for messages coming to that queue from outside the cluster. A queue manager from outside the cluster needs a transmit queue and sender channel to one queue manager in the cluster, which is called a gateway queue manager. To take advantage of the default workload balancing mechanism, the gateway queue manager must not contain an instance of the EDINBURGH queue.
