Redpaper - IBM Redbooks

More documents

Recommendations

Info

► Review actual structure sizes regularly and make sure the coupling facility Resource Manager (CFRM) policy is updated to reflected actual usage. Application structure allocations grow with use. ► Confirm that the admin structure is a single point of failure. If a second coupling facility is available then duplexing of the structure should be considered. ► Define the queue manager logs with SHAREOPTIONS(2 3) as in the Job Control Language (JCL) of sample job CSQ4BSDS, because shared queue recovery requires that a queue manager can access the logs of peers within the QSG. ► Define application CFSTRUCT with CFLEVEL(3) and RECOVER YES when using persistent messages (the default is level 2 and NO). ► If using persistent messages, review log sizes prior to migration to shared queues. Data logged is slightly larger, and BACKUP CFSTRUCT copies shared queue messages to the log. Non-persistent messages on a private queue may be logged under some circumstances (for instance, if the message stays on the queue for an extended length of time), but this situation does not occur for non-persistent messages that reside on a shared queue. ► Prevent Hierarchical Storage Manager (HSM) from migrating the queue manager DB2 tables. If the tables are migrated, you may experience startup problems. ► Do not attempt to manually change QSG DB2 tables unless directed by <strong>IBM</strong> support. Even apparently innocuous changes may leave DB2 table information out of sync with the coupling facility or with other tables. ► Allow a QSG for a group listener (using VIPA) and shared channels, which may be useful in providing HA for WebSphere MQ applications. 3.6 The WebSphere Business Integration Message Broker configuration A message broker is created for each of the queue managers described previously. The message broker names are WMQ0BRK and WMQ2BRK, running on MVSM0 and MVSM2 respectively. You can find instructions for creating the broker at: http://publib.boulder.ibm.com/infocenter/wbihelp/index.jsp 26 High Availability z/OS Solutions for WebSphere Business Integration Message Broker V5
3.6.1 Message Broker configuration considerations Some things to consider when configuring the Message Broker are: ► Each Message broker connected to the QSG should run under a different user ID. One of the reasons for this configuration is that the broker tables must be created with unique names in the DB2 data sharing group. The user ID, which is used for variable DB2_TABLE_OWNER in the mqsicompcif file, is prepended to the broker table names to form the fully qualified unique table names. ► If the desired response to a system failure is to use ARM to restart a broker, with its queue manager on another z/OS system in the sysplex, then consider the following: – The UNIX System Services (USS) environment across the sysplex should be configured to use shared HFS. – The broker root directories must not be created under the /var directory. This is because the /var directory resolves to &SYSNAME/var and thus is system specific. System specific HFSs are unmounted when the owning system goes down and are not available to the rest of the sysplex while that system remains down. Instead, create a new directory under the sysplex root and create the broker root directories under this same directory. For example: mkdir /wbimb mkdir /wbimb/WMQ0BRK The root directory for any given broker is now visible to each z/OS system in the sysplex and is not unmounted if its host system goes down. Depending on the number of brokers created, you may also want to create additional HFSs to be mounted at each broker root directory, or one larger HFS at the higher directory, in order to prevent filling up the sysplex root HFS mounted at ‘/’. – When editing the mqsicompcif file, the DB2 group attach name (in this case DFPM) should be used for the DB2_SUBSYSTEM variable rather than specifying a specific DB2 subsystem. This configuration means that the broker can use another DB2 subsystem in the data sharing group to access its tables in the event of failure. – Use of BP0 as the DB2 buffer pool chosen for the broker database is not recommended. Furthermore, to enable the broker to restart on another system in the sysplex the buffer pool selected needs to be active on that system. Use the alter bufferpool command to activate it. If the buffer Chapter 3. Topology and system setup 27
Page 1: High Availability z/OS Solutions fo
Page 4 and 5: Note: Before using this information
Page 6 and 7: 3.7 Automatic Restart Management co
Page 8 and 9: Trademarks The following terms are
Page 10 and 11: From left: Dean, Steve, and Jon Dea
Page 12 and 13: Become a published author Join us f
Page 14 and 15: 1.1 Project overview This paper exp
Page 16 and 17: e compromised while the failing com
Page 18 and 19: Figure 1-2 Test environment topolog
Page 20 and 21: Message Broker is a WebSphere MQ an
Page 22 and 23: 2.1 Considerations when designing f
Page 24 and 25: Table 2-1 Advantages and disadvanta
Page 26 and 27: Advantages Disadvantages Uses the a
Page 28 and 29: In this instance, you should consid
Page 30 and 31: of messages making up a transaction
Page 32 and 33: 20 High Availability z/OS Solutions
Page 34 and 35: 3.1 High Availability configuration
Page 36 and 37: 3.3 The z/OS LPARs There are three
Page 40 and 41: pool is not available, errors occur
Page 42 and 43: 3.7 Automatic Restart Management co
Page 46 and 47: 4.1 Test environment setup As previ
Page 48 and 49: ► In a production environment, yo
Page 50 and 51: The batch jobs provided work for th
Page 52 and 53: IP13 Statistics MVSM0 MVSM2 Total B
Page 58 and 59: z/OS DB2 (DSG) QMGR (QSG) Message B
Page 62 and 63: ARM policy Example A-1 displays the
Page 66 and 67: Using the Web material The addition
Page 70 and 71: How to get IBM Redbooks You can sea
Page 72: U UNIX System Services (USS) enviro

Redpaper - IBM Redbooks

Create successful ePaper yourself

Delete template?

Save as template?