WebSphere MQ For iSeries Best Practices Guide

By Jonathan Rumsey IBM Hursley E-mail: jrumsey@uk.ibm.com Date: 31st May 2006
Copyright IBM Corp., 2006

WebSphere MQ for iSeries Best Practice Guide

Version 1.2

WebSphere MQ for iSeries Best Practice Guide ........................................................ 2 1 Introduction ....................................................................................................... 3 2 WebSphere MQ maintenance and software rollout............................................. 4 2.1 Software maintenance ................................................................................ 4 2.2 Managing rollouts ...................................................................................... 5 3 General housekeeping........................................................................................ 6 3.1 Creating and changing objects.................................................................... 6 3.2 Journal housekeeping................................................................................. 6 3.3 Shared memory cleanup............................................................................. 6 3.4 Queue manager shutdown .......................................................................... 7 3.5 12-Step / Cold Start procedure ................................................................... 7 3.6 Backups ..................................................................................................... 8 3.6.1 Data ................................................................................................... 8 3.6.2 Object definitions ............................................................................... 9 3.7 Multiple queue managers ........................................................................... 9 3.8 Daylight saving time ................................................................................ 10 3.8.1 Spring time change........................................................................... 10 3.8.2 Autumn or fall time change .............................................................. 10 4 Performance .................................................................................................... 12 4.1 Journal receiver location .......................................................................... 12 4.2 Journal receiver switching........................................................................ 12 4.3 Restart time.............................................................................................. 13 4.4 Channel process pooling .......................................................................... 13 4.5 IFS Type 2 ............................................................................................... 14 5 Availability...................................................................................................... 15 5.1 High Availability (HA) clustering ............................................................ 15 5.1.1 Remote mirroring............................................................................. 15 5.1.2 Backup queue managers ................................................................... 15 5.2 High Availability features ........................................................................ 16 5.2.1 WebSphere MQ clustering ............................................................... 16 5.2.2 Client Channel table ......................................................................... 17 5.3 Network topology .................................................................................... 17 5.4 Hardware assistance................................................................................. 18 6 Conclusion ...................................................................................................... 18

Table of Contents

1 Introduction
This document is intended for people who manage WebSphere MQ 5.3 or 6.0 software on iSeries machines. It has been written for both novice and expert users of WebSphere MQ and encapsulates general best practice information that has been collated by the IBM development and service teams from customer installations. It is divided into four main sections: WebSphere MQ maintenance and software rollout, General housekeeping, Performance, and Availability. This guide should be used in conjunction with, and not as a replacement to, the WebSphere MQ publications. Full details of the WebSphere MQ administration and programming interfaces are available in these publications; the latest editions of all books can be downloaded from the WebSphere MQ Web site .

WebSphere MQ for iSeries Best Practice Guide

Page 3 of 18

2 WebSphere MQ maintenance and software rollout 2.1 Software maintenance

You should ensure that you keep current with maintenance. Preventative maintenance for WebSphere MQ is delivered by distributing Fix packs (formerly known as CSDs) to customers as Final PTFs and corrective maintenance is carried out via iSeries Test Fix delivery. A Fix pack contains a number of cumulative fixes; these PTFs are usually made available every 3 months. The entire set of PTFs can be ordered using a single marker PTF. A Test Fix is an OS/400 specific method of delivery. It lets a customer use the Load PTF (LODPTF) and Apply PTF (APYPTF) CL commands to apply the fix, and the remove PTF (RMVPTF) CL command to remove it. A Test Fix (unlike a PTF) is not the final delivery vehicle for the fix. The final fix is delivered in the Fix pack. Test Fixes cannot be superseded by another PTF (all Test Fixes need to be applied on top of the last Fix pack), so there is a requirement to remove a Test Fix before applying a new Fix pack or another Test Fix that fixes the same object. Producing Test Fixes that cannot supersede other Test Fixes, allows WebSphere MQ Service to target individual fixes to specific customers because there are no dependencies that force a Test Fix to drag in fixes devised for other customers. This process is consistent with the other WebSphere MQ platforms on the common code base (though the fixes are packaged differently). It allows emergency fixes to be delivered quickly, in a format that allows customers to use standard PTF commands to apply, remove, and track these fixes, and allows IBM to target individual fixes to specific customers. You should not need to apply every Fix pack on the day it is issued, but you should be aware of what has been released. It is a good idea to check the list of APARs that have been included in each PTF. Expect that at least one of the APARs could show up in your system unless you upgrade. Plan to install PTFs on a test machine, and then migrate to production systems. If a high impact pervasive problem arises in-between the release of WebSphere MQ Fix packs, as with other iSeries products, the service team will release a set of HIPER (High Impact PERvasive) PTFs so a fix can be provided to all customers before the next Fix pack is released. You should ensure that you are current with both WebSphere MQ and other iSeries HIPER PTFs. Regularly review the Preventive Service Planning (PSP) information that is available online to iSeries customers and which lists all new important PTFs that have been released on the iSeries for each supported version of the operating system. It also lists any PTFs that are known to be defective and should not be applied to your system. New full versions of WebSphere MQ have generally been released every 18-24 months, with an overlap of service of approximately 12-15 months, but sometimes for a longer period. When a new release arrives make early plans to upgrade to it. It is advisable to schedule your upgrade before service has been withdrawn for the older version.

WebSphere MQ for iSeries Best Practice Guide

Page 4 of 18

It takes time to test applications and roll the product into production systems and lastminute upgrades can run into problems if this testing is not done. We know that some sites take several months to implement a replacement version, as they go through the tiers of testing. Problems need to be found early so that you have time to fix these problems before the final end of service deadline. The latest version of WebSphere MQ for iSeries at the time of writing (May 2006) is V6.0. This release contains many functional enhancements over V5.3. It also contains fixes to all the relevant, known defects that were included in the V5.3 PTFs available before V6.0 shipped. Future fixes made to V5.3 will also be included in V6.0 PTFs where appropriate. You can see the WebSphere MQ Support, Service summary for OS/400 for a summary of the problems fixed in each PTF. This page also shows the end of service date for each version of WebSphere MQ.

2.2 Managing rollouts

All application and system software should be fully tested, using production workloads and configurations, on separate machines or partitions. Many customers have a multi-tier approach, covering development, system testing, production testing, and real production systems. Programs and configurations are moved between these environments using locally defined practices. A fundamental rule is that no changes should be made without change control and audit trail mechanisms. Do not go into production without properly testing your systems. This normally means having a spare machine of equivalent processing power that can run workloads similar to that of the production system. The machines should also, of course, use identical levels and versions of all software. While we cannot make specific recommendations, we know that any successful enterprise will have implemented a staged rollout process, testing at each stage to ensure quality and service requirements are met. Testing needs to cover not just basic application function but also performance, capacity and disaster recovery scenarios. A self-contained, repeatable, regression test suite that is enhanced as necessary will contribute significantly to a successful rollout. Logical partitions can be used for some tests, as these can simulate testing on separate machines. Any recommendations in this document that refer to machines can equally be applied to separate partitions. The only difference is that the CPU cycles of a machine can be shared between the partitions, so for example you cannot accurately test the peak performance of a dedicated machine.

WebSphere MQ for iSeries Best Practice Guide

Page 5 of 18

3 General housekeeping
3.1 Creating and changing objects
It is good practice when creating queue manager objects, to put the object creation commands into an MQSC script or CL command program. If you always create WebSphere MQ objects programmatically then you have a record of the queue manager definitions that allows you to very quickly rebuild an entire queue manager. When changing WebSphere MQ objects, change the definition of the object in the program and rerun the program rather than changing the object directly.

3.2 Journal housekeeping

On iSeries, WebSphere MQ periodically issues messages AMQ7460 and AMQ7462 to indicate which journals are no longer needed for crash or media recovery. In WebSphere MQ 6.0 this information is now also available via the DSPMQMSTS CL command, via the DISPLAY QMSTATUS MQSC command and programmatically through the MQAI/PCF MQCMD_INQUIRE_Q_MGR_STATUS interface. Older journal receivers should be deleted or archived once they are not needed by WebSphere MQ to recover storage and to reduce the number of journal receivers that MQ needs to read. Ideally, this should be done by an automated task that runs regularly, the frequency of which should be dependent on the number of journal receivers used each day. For a discussion and sample program showing how to automate the Housekeeping of journal receivers, see the article, Automating Journal Management in WebSphere MQ for iSeries.

3.3 Shared memory cleanup

Customers have occasionally experienced problems starting a queue manager that have lead to them clearing out the shared memory and semaphore related files that are found in the IFS file system. The manual deletion of these files is not recommended. The existence of these files provides a placeholder to ensure that WebSphere MQ does not attempt to create new shared resources with the same key as existing shared resources. Manually deleting these files can orphan inter process communication (IPC) objects such as shared memory and semaphores, which may result in unexpected behaviour of WebSphere MQ. In V5.3 and later releases, shared memory can be safely purged for a single queue manager by specifying a queue manager name on the command: ENDMQM MQMNAME(queuemanager) ENDCCTJOB(*YES)

WebSphere MQ for iSeries Best Practice Guide

Page 6 of 18

3.4 Queue manager shutdown

Customers have found that they occasionally have trouble shutting down their queue managers on busy systems within a reasonable period of time. Often this is related to the time required to end a large numbers of channel jobs connected into the queue manager. The recommended way to quiesce a queue manager is to use the End Message Queue Manager (ENDMQM) command with ENDCCTJOB(*YES) to end connected jobs, listeners etc. In WebSphere MQ 5.3, the ENDCCTJOB(*YES) option forces the queue manager to record media images (with an implicit RCDMQMIMG) before it is shut down. The implicit RCDMQMIMG can take some time. Specifying RCDMQMIMG(*NO) at WebSphere MQ 6.0 prevents this step occurring and so can greatly reduce the time it takes to end a queue manager at the expense that it may mean that media recovery of a damaged object may take longer to perform. To speed up the ENDMQM OPTION(*IMMED) ENDCCTJOB(*YES) you can first issue an ENDMQM OPTION(*CTRLD). This command returns immediately and flags the queue manager as ending. Issuing this initial controlled end of the queue manager at WebSphere MQ 5.3 will prevent the implicit RCDMQMIMG. The ENDCCTJOB(*YES) will still run, ending the queue manager immediately and shut down any jobs connected to the queue manager. If you bypass the RCDMQMIMG on ENDMQM then you should consider issuing a manual RCDMQMIMG command when the queue manager restarts to ensure you have media images of your queue manager objects readily available in the latest journal receivers. Splitting queue managers may also help to alleviate this problem by distributing the channel jobs between the queue managers (Section 3.7).

3.5 12-Step / Cold Start procedure

In the past, some customers have experienced problems starting their WebSphere MQ queue managers on iSeries. These problems have manifested themselves as failures in the Start Message Queue Manager (STRMQM) command, or as apparent hangs while running STRMQM (in fact this is more likely to be STRMQM running extremely slowly, a problem which has now been resolved). To recover from these problems, the queue manager is often restarted using a procedure referred to as the 12-step or cold start procedure. This procedure involves deleting the existing AMQAJRN journal and associated journal receivers for the queue manager, and creating new empty journals and journal receivers.

WebSphere MQ for iSeries Best Practice Guide

Page 7 of 18

Performing a cold start is not best practice. When WebSphere MQ journal receivers that are still required by the queue manager are deleted it must be understood that messages can be lost or duplicated. Normal queue manager start-up processing involves reconciling the data in the AMQAJRN journal with the data in the IFS queue files. When a queue manager is restarted using the cold start procedure, there is no journal data to replay, so WebSphere MQ cannot perform its normal start-up processing. The start-up reconciliation is required by WebSphere MQ to guarantee integrity. One of the key reasons this is required is because WebSphere MQ uses a technique called write-ahead logging. This means that whenever WebSphere MQ puts or gets persistent messages, the put or get is recorded in two ways: 1. With a forced disk write to the AMQAJRN Journal, meaning that WebSphere MQ waits for OS/400 or i5/OS to confirm that the disk has been physically updated. 2. With a lazy write to the queue, WebSphere MQ caches some data in memory, and writes some data to the IFS queue file with an OS/400 unforced write. The unforced write will be stored in operating system buffers and written to disk at the operating system's convenience. The journal data on disk is therefore the master copy of WebSphere MQ data. In normal circumstances when WebSphere MQ is shut down and restarted, STRMQM processing ensures that the data in the queue files is brought up to date with the data in the journals. If a queue manager or system terminates abnormally, then information about messages and transactions may exist in the journal, but not in the IFS. Deleting the journal receivers as part of a cold start deletes the only copy of these messages and transactions. By using the cold start procedure (by deleting the journals and bypassing any STRMQM reconciliation) could lead to loss, duplication, or corruption of data. Because the data in the journal receivers is so important to the recovery of MQ data, we strongly recommend that the journal receivers are stored on RAID protected disk, and that the cold start is avoided wherever possible.

3.6 Backups
Two methods to consider when planning a backup and recovery strategy for WebSphere MQ are the data backup and object definition backup. These methods are complementary, and most enterprises successfully implement a combination of these two techniques.

3.6.1 Data
It is necessary to quiesce a queue manager before fully backing up its IFS and journal data, you can however, take a backup of just the journal data while the queue manager is running. If the backed up journal data is restored then it is possible to fully recover a queue manager and its IFS data.
WebSphere MQ for iSeries Best Practice Guide Page 8 of 18

It is a good idea to perform a full backup of the WebSphere MQ libraries and IFS directories occasionally (for example, when the queue manager is quiesced to apply maintenance). Journal backups can be taken more frequently, for example, daily or weekly.

3.6.2 Object definitions

Journal data backups will let you recover object definitions and messages up to the last backup, but if you are using WebSphere MQ for non-persistent messaging, then it is simpler to just backup your WebSphere MQ queue manager definitions. This lets you quickly recreate a copy of a queue manager without requiring the messages and transactions to be restored. SupportPac - MS03 saves the queue manager definitions as MQSC commands that can be replayed to recreate the objects. The SupportPac can be downloaded from: http://www.ibm.com/software/integration/support/supportpacs/individual/ms03.html MS03 does not save or restore the queue managers authority records, but a utility program (AMQOAMD) ships with WebSphere MQ for this purpose. Calling AMQOAMD with the -s flag will dump the authority records in the form of GRTMQMAUT commands that can be replayed to recreate the authority records. So to dump the authority commands to a file the following approach can be used:
OVRDBF FILE(STDOUT) TOFILE(&OUTLIB/&OUTFILE) MBR(&OUTMEMB) CALL AMQOAMD PARM('-m' &MQMNAME '-s') DLTOVR FILE(STDOUT)

MS03 and AMQOAMD provide a quick and lightweight way of backing up and restoring a queue managers definitions from one machine to another, or even between queue managers on a single machine. The alternative to using MS03 is using one of the third-party system management tools that hold queue manager configurations in a central repository.

3.7 Multiple queue managers

Prior to V5.1, WebSphere MQ on iSeries only supported a single queue manager per machine, and so, many disparate applications were forced to share a single queue manager. Despite the introduction of multiple queue manager support in v5.1, many customers are still using one queue manager for all their applications. Sharing a single queue manager between applications in this way can lead to some problems that can be alleviated by allocating individual queue managers to applications. Changing a WebSphere MQ topology from a shared queue manager to multiple queue managers can involve changes to applications, and so is not a trivial undertaking. The following advantages and disadvantages should be reviewed when considering how your applications are distributed over queue managers.

WebSphere MQ for iSeries Best Practice Guide

Page 9 of 18

Advantages of a single queue manager: Low overhead - There is a fixed minimum overhead associated with a queue manager. Dependent on the version, each queue manager can start between five and eleven jobs before any applications connect. The fewer queue managers, the fewer system resources are used. Management - An increase to the number of queue managers may increase the management tasks that need to be performed. Running each queue manager in a separate subsystem is a good strategy to simplify queue manager maintenance if multiple queue managers are used.

Advantages of multiple queue managers: Failure impact - A single queue manager is a single point of failure for all applications. Multiple queue managers can reduce the impact of a failure to only the application(s) or location(s) being served by that queue manager. Scalability - On a single queue manager system, one high volume application can adversely affect the performance of all other applications using the queue manager. Having multiple queue managers gives scope for greater throughput on a queue manager by queue manager basis. For example, if the performance of a queue manager is suffering because of a bottleneck when writing to the journals it is possible to move the journals for that queue manager to a dedicated disk. WebSphere MQ 6.0 allows you to allocate storage for queue manager journal data to a specific auxiliary storage pool. Availability planning Multiple queue managers can simplify planning for high availability. It allows individual queue managers and applications to be considered as a single failover unit that can be failed over to another machine without affecting services for other applications.

3.8 Daylight saving time

Changing the system clock to account for daylight savings time causes problems for WebSphere MQ on iSeries if a queue manager is active because WebSphere MQ uses timestamps based on the system clock to access data in the queue managers journal entries. If the system clock changes while WebSphere MQ is running, then WebSphere MQ can fail to access journal data correctly and may prevent queue manager start-up. It is therefore necessary to quiesce WebSphere MQ before changing the system clock.

3.8.1 Spring time change

When the clocks go forward one hour in the spring, WebSphere MQ can just be shut down for the time it takes to adjust the clock. The queue manager can be restarted immediately after changing the clock and UTC offset.

3.8.2 Autumn or fall time change

When the clocks go backward in the autumn or fall, you cannot restart the queue manager immediately after changing the clock backwards. If you do so, WebSphere MQ could write duplicate timestamps to the journal. You should ensure that

WebSphere MQ for iSeries Best Practice Guide

Page 10 of 18

WebSphere MQ is stopped for an hour either before, or after the time change and UTC offset update, to avoid the problems associated with setting the system clock backward by an hour. In environments where downtime must be minimized, an enforced outage of one hour may not be acceptable. IBM is investigating a solution to this problem, but until a solution is available the only alternative to quiescing the queue manager for an hour is to perform a controlled cold start of the system (see section 3.5 for a discussion of the Cold Start). A controlled cold start is one where all queues are emptied of any persistent messages and the queue manager is cleanly shut down. The queue manager journal data can then be deleted per the cold start procedure. This eliminates the risk of losing messages, but it still deletes all media recovery information. You will not be able to recover damaged objects without media recovery information, so you should ensure that you have backed up your object definitions prior to attempting this (see section 3.6.2). Your IBM service representative will be able provide details of the cold start procedure should it be required.

WebSphere MQ for iSeries Best Practice Guide

Page 11 of 18

4 Performance
4.1 Journal receiver location
The critical path for performance of persistent messages is usually the update of the WebSphere MQ log files (journals on iSeries), these updates should ideally be isolated using operating system facilities so that they are written using dedicated disk heads. This is achieved by putting the Queue Manager AMQAJRN and its receivers into a separate Auxiliary Storage Pools, this facility is provided as an option when creating your queue manager at WebSphere MQ 6.0.

4.2 Journal receiver switching

Some customers have encountered performance problems when WebSphere MQ journal receivers switch. This is because when a receiver switch happens, WebSphere MQ uses a lock to protect data while it builds an in-memory image of the journal receiver chain. In extreme cases WebSphere MQ can appear to hang while the AMQALMPX job builds this image. This problem has been resolved in WebSphere MQ 5.3 via Fix pack and in WebSphere MQ 6.0 and thus the following advice applies only to prior releases of the product. In WebSphere MQ releases prior to 5.3 (CSD#6) there is a direct relationship between the amount of journal data that is stored on the system and the amount of time WebSphere MQ takes to perform a journal switch, so it pays to remove redundant receivers as described in section 3.2. You can reduce the number of times you switch journals by using a small number of large journal receivers as opposed to a large number of small journal receivers. The optimum size for journal receivers depends on workload and the amount of persistent data passing through the queue manager. You can avoid journal receiver switches during busy periods by making the journal receivers large enough to contain a full days data. At close of day, journal receivers should be switched manually with CHGJRN *GEN to ensure a new receiver is used the next day. You can define the size of the journal receivers for a queue manager in WebSphere MQ 6.0 via a parameter on the CRTMQM command. On previous releases you can change the size of a queue manager journal receiver by creating a new receiver with the desired size, and attaching it to the journal. All subsequent receivers will be created with the new size. Use the following commands to do this.
CRTJRNRCV JRNRCV(QMGRLIB/AMQAnnnnnn) THRESHOLD(NEW_SIZE) TEXT('MQM local journal receiver') AUT(*EXCLUDE) CHGOBJOWN OBJ(QMGRLIB/AMQAnnnnnn) OBJTYPE(*JRNRCV) + NEWOWN(QMQM) CHGJRN JRN(QMGRLIB/AMQAJRN) JRNRCV(QMGRLIB/AMQAnnnnnn)

WebSphere MQ for iSeries Best Practice Guide

Page 12 of 18

where QMGRLIB is the name of your queue manager library, AMQAnnnnnn is the name of the next journal receiver in sequence, and NEW_ SIZE is the new receiver size.

4.3 Restart time

If a queue manager is not ended with the normal ENDMQM command, STRMQM will take longer than if the queue manager was shut down normally. The queue manager restart time after an abnormal shutdown is heavily dependent on the amount of work needed to replay and recover and resolve transactions that were in-flight when the queue manager shut down. If queue data files are found to be corrupt when replaying transactions, then the queue files must also be recovered from media image. Queues are recovered from the last recorded media image, and all operations (put/get) are replayed from the journals into this queue. To reduce restart time: Make sure that applications check for fail if quiescing when using MQGET, and roll back their Units of Work. Where possible, write your applications so that units of work are short lived. Use the RCDMQMIMG command regularly to update the media recovery images for queues. This will reduce the amount of data replayed if the queue files become corrupt. Ideally you should record the media image of a queue when the queue depth is low to reduce the amount of information that needs to be stored in the journals.

4.4 Channel process pooling

As previously mentioned, the channel process-pooling feature first introduced in WebSphere MQ V5.3 lets channels run as threads within a pool of processes. By default each pooling job can run up to 60 channel threads, which significantly reduces the number of active jobs in the system. Channel process pooling is the default behaviour for queue managers created in WebSphere MQ V5.3 or later releases. You can turn on the channel process pooling feature for queue managers which were originally migrated from previous releases by adding the ThreadedListener=YES value to the Channels stanza in the qm.ini file. For example:
Channels: ThreadedListener=YES

Important: If you use Channel process pooling you must ensure that all channel exits are thread-safe, as you would need to do so with any threaded MCAs.

WebSphere MQ for iSeries Best Practice Guide

Page 13 of 18

4.5 IFS Type 2

As WebSphere MQ uses the IFS extensively you may want to consider converting your file system to use IFS Type 2 directories to improve performance and reliability.

WebSphere MQ for iSeries Best Practice Guide

Page 14 of 18

5 Availability
5.1 High Availability (HA) clustering
High Availability (HA) clustering is a general term for systems where a service is automatically restarted, perhaps on a different box, when a failure is discovered. WebSphere MQ provides technology for integrating with HA frameworks where the WebSphere MQ data and journals are stored on a disk that can be accessed by more than one machine (not necessarily simultaneously). When a machine fails, the disk is switched to the other machine and the queue manager is restarted. There will be a short delay while the takeover occurs, queue managers outside the HA cluster will automatically reconnect as channel retry kicks in, and no persistent messages are lost. OS/400 V5R2 introduced the ability to place libraries onto disks that can be switched between two machines (Independent Auxiliary Storage Pools or IASPs). This makes it possible to develop an HA clustering solution for WebSphere MQ. IBM have provided a SupportPac that shows how to configure OS/400 HA clusters with WebSphere MQ.

5.1.1 Remote mirroring

Without a shared disk, and therefore without a standard HA integration facility, an alternative approach to restarting a queue manager on a second machine is to mirror the contents of the disks holding WebSphere MQ data and logs. Provided the mirror is precisely synchronized with the original data, then this exactly has the same availability characteristics as an HA cluster. If, however, the mirror is an asynchronous process, there is a possibility that journal entries written by the queue manager might not have been copied before the failure, and therefore that the rebuilt queue manager image can have missed updates. This could result in lost or duplicated messages. There are several vendor products that work using a combination of mirroring disk files and extracting data out of WebSphere MQ journals. Any true mirror is likely to introduce a performance impact, as any forced update (flush) to the disk is going to have to be written to the mirrored system before the queue manager can continue. This performance hit may or may not be acceptable, depending on customer requirements; we would recommend running a production-level workload to ensure performance is adequate and data replication is complete.

5.1.2 Backup queue managers

WebSphere MQ 6.0 introduced an alternative feature to using a vendor product to mirror a queue manager. This feature allows you to periodically update the backup with journal data and then activate it in a disaster recovery scenario. To create a backup queue manager, the primary queue manager IFS and library are saved and restored to a backup system. The backup queue manager is then designated as such by starting the queue manager with the STRMQM REPLAY(*YES)

WebSphere MQ for iSeries Best Practice Guide

Page 15 of 18

command which informs the queue manager to just replay the journal data to update the IFS, rather than perform a full queue manager startup. Periodically new journal receivers are copied from the primary queue manager to the backup and replayed using STRMQM REPLAY(*YES) command. At this stage the backup cannot yet be started proper, but if the primary queue manager fails the backup queue manager can then be activated using STRMQM ACTIVATE(*YES). Using the backup queue manager feature does not impact performance of the primary queue manager as would occur in remote mirroring and in most scenarios it is faster to start a backup rather than a mirrored queue manager. This solution may not be acceptable if loss of some messages is unacceptable, as the backup queue manager may not be completely up to date with the same configuration and message data to that of the primary queue manager.

5.2 High Availability features

WebSphere MQ includes a number of features that let applications become more resilient to queue manager or hardware failures. We consider two in more detail here: WebSphere MQ queue manager clusters, and the client channel table. Both queue manager clustering and client channel table reconnection techniques assume that any one of the queue managers in the cluster / table is capable of delivering the service that the client needs. By duplicating services on all queue managers, you eliminate single points of failure.

5.2.1 WebSphere MQ clustering

WebSphere MQ clustering provides two main benefits: reduced administration and workload distribution (WLM). The default WLM algorithm routes each inbound message to one of the available queue managers that contains the target named queue. If a queue manager is not currently running, then the messages are sent elsewhere; if no queue manager is running that hosts the named queue, the messages remain on the originating system until a server queue manager is restarted. The WLM algorithm can be tailored by a workload manager exit program by any release of WebSphere MQ that supports clustering or via various channel and queue parameters such as rank, priority and weighting which were introduced in WebSphere MQ 6.0. This approach allows new work to be injected into the cluster, even when some of the server machines are not running. However messages which have been sent to a queue manager, which subsequently fails, cannot be processed until the queue manager restarts. These messages are often called marooned. A WebSphere MQ cluster is especially effective if there are no affinities between individual messages enabling them to be processed in any sequence. Affinities can be maintained if the application is written to use options in the MQI, but this has to be a conscious decision based on the business requirements.

WebSphere MQ for iSeries Best Practice Guide

Page 16 of 18

Many customers are using WebSphere MQ clustering successfully in large configurations; it is our normal recommendation for managing a set of queue managers that need to share workload. More information about Clustering can be found in these online WebSphere MQ manuals.

5.2.2 Client Channel table

Available previously on other platforms, the Client Connection Table was introduced in WebSphere MQ V5.3 for iSeries as a way of building more resilient client applications without clustering. The Client Channel table is created by the iSeries server queue manager and contains a list of Client Connection (*CLTCN) channels that have been created on the server. The table allows client applications to select the queue manager they connect to at run time via a list. If the client uses a wildcard in the queue manager name on the MQCONN, the client code will pick the first available queue manager from the preconfigured Client Channel table. If the connection to the queue manager subsequently fails for any reason, the client can be programmed to detect the failure and attempt the connection again. The client code will pick the next available queue manager from the Client Channel table. In this way, the client application can recover from server failures.

5.3 Network topology

There are times when it is appropriate to share workload between multiple systems even when a single machine could theoretically handle the entire capacity. The decision to partition the workload here is often made for geographic or organizational reasons. For example, it might be appropriate to have work executed in a regional center instead of sending it all to a central location. There are no fixed rules about business-driven partitioning, however you need to consider the availability (including bandwidth) of networks between processing centers and the amount of inter-server messaging. Using WebSphere MQ clustering, perhaps with a custom-written workload exit or with the new features introduced in WebSphere MQ 6.0 would be a good way to direct messages to the nearest available server. Designing an efficient queue manager and network topology is something that requires an analysis of the expected message traffic patterns. This activity needs to consider the other material in this document to ensure good availability and performance of all of the queue managers in the network, avoiding single failure points and bottlenecks.

WebSphere MQ for iSeries Best Practice Guide

Page 17 of 18

5.4 Hardware assistance

There are a number of hardware technologies that can improve the availability of a WebSphere MQ system. These include Uninterruptible Power Supplies and RAID technologies for disks. Use of these facilities is transparent to WebSphere MQ, but should be considered as part of the planning process when ordering machine configurations.

6 Conclusion
This article discussed some of the best practices that will help you to get the most out of WebSphere MQ on iSeries. These practices will help you keep your system up to date, safely backed up, available, and performing well. WebSphere MQ is a versatile product that is used in many environments and that makes it difficult to describe procedures that will cover every eventuality. If you have a best practice that is not covered here, the authors would be interested to hear about it.
IBM and WebSphere are trademarks or registered trademarks of IBM Corporation in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others. IBM copyright and trademark information

WebSphere MQ for iSeries Best Practice Guide

Page 18 of 18