MQ & MB @ Unix

Log as root and use smit. Select the required smit window using the following sequence:

MQ for AIX v6.0, "Quick Beginnings", GC34-6478-00, page 11 [25/72]

AIX :

Guindous :

Solución :

url - the errors are due to a defect in the ISMP version

Requisits :

• AIX 5.3 TL5 SP2 ("oslevel -r")

System Requirements for WebSphere Message Broker V6.1 for AIX

Agafar odbc64.ini :

Adaptar odbc64.ini :

Edit .profile :

Engegar :

Aturar i llistar :

The installation directory for the MQ product code is /opt/mqm. Working data is stored in /var/mqm. You cannot change these locations.

You can also create separate file systems for your log data /var/mqm/log and error files /var/mqm/errors. If possible, store log files on a different physical disk from the MQ queues /var/mqm.

AMQCAC07.pdf = MQ for HP-UX v 6.0 Quick Beginnings

Si volem posar cada Queue Manager en un disc diferent, per agafar un queue manager des una màquina diferent, llavors hem de crear /var/mqm/qmgrs/<nom>/ abans de cridar crtmqm. Aquesta funció crearà /var/mqm/qmgrs/<nom>.000/, que hem de moure al lloc adient abans esmentat, a la vegada que corregim /var/mqm/mqs.ini

Como usuario "root", editar el fichero /etc/sysctl.conf y comprobar la existencia de los valores abajo indicados. Esos valores son valores mínimos, asi que si el fichero contiene un valor superior, este debe prevalecer. También se puede verificar la lista de valores mediante el comando /etc/sysctl -a

ECI I-006 : instalación en Z (64).

Top

WLB permite que el servicio para nuevas transacciones continue despues de una falla en uno de los brokers pero los mensajes que se hallan encolados en el queue manager que ha fallado permancen perdidos hasta que se restature el servicio del queue manager y del broker. Aqui es donde HA sirve para restaturar el servicio en forma automatica y lo mas pronto posible.

Que pasa si ...

• falla QM2 ?
• falla MB2 ?

(1) unos pocos mensajes quedan atrapados en las colas de QM2, pero los mensajes futuros iran sin problema a QM1 y MB1.

(2) los mensajes seguirán repartiendose entre QM1 y QM2. Si MB2 no los trata, se acumularán en Q1.

HACMP = High Availability Cluster Multi-Processing

An HA cluster is a collection of nodes and resources (such as disks and networks) which cooperate to provide high availability of services running within the cluster.

This SupportPac includes a monitor for WMQ, which will allow the HA product to monitor the health of the queue manager and initiate recovery actions that you configure, including the ability to restart the queue manager locally or move it to an alternate system.

We will use commands like

• hacrtmqm / hadltmqm
• halinkmqm

url MC91 - high availability for MQ on Unix.
url IC91 - high availability for MB on distributed platforms.

Tinc :

• \\MQ\SupportPacks\MC91\mc91.pdf [***]
• \\WS-BI-MB\HACMP\SG24-6328 = "Highly Available WebSphere Business Integration Solutions"
• \\MQ\BOOKS\Linux\MQ_5.3_HA_installation_under_Linux.pdf or (HTML format) \\MQ\HA

Online : part 1, part 2.

Great Resources list.

Step 1. Configure the HA Cluster

Step 2. Configure the shared disks

For performance, it is recommended that a queue manager uses separate filesystems for logs and data.

Mount points must all be owned by the mqm user.

You will need the following filesystems:

Per node:
/var on internal disks - this is a standard filesystem or directory which will already exist. You only need one of these per node regardless of the number of queue managers that the node may host. It is important that all queue managers that may run on this node use one filesystem for some of their internal control information and the example scripts designate /var/mqm for this purpose. With the suggested configuration, not much WMQ data is stored in /var, so it should not need to be extended. The filesystem layout from the previous step can be simplified if you know you are only going to have a single queue manager on a node, which fails over to a standby machine. For such a configuration, you can continue to use the /var/mqm and /var/mqm/log filesystems. However, this layout will not make it simple to extend if you later change your mind, and want to have an active/active system.

Per queue manager:

• /MQHA/<qmgr>/data/ on shared disks - this is where the queue manager data directory will reside.
• /MQHA/<qmgr>/log/ on shared disks - this is where the queue manager recovery logs will reside.

MC91.pdf, v7, page 15, 14/46

1. Create the volume group that will be used for this queue manager's data and log files.
2. Create the /MQHA/<qmgr>/data/ and /MQHA/<qmgr>/log/ filesystems using the volume group created above.
3. For each node in turn, import the volume group, vary it on, ensure that the filesystems can be mounted, unmount the filesystems and varyoff the volume group.

Step 3. Create the Queue Manager

1. Select a node on which to perform the following actions
2. Ensure the queue manager's filesystems are mounted on the selected node.
3. Create the queue manager on this node, using the hacrtmqm script
4. Start the queue manager manually, using the strmqm command
5. Create any queues and channels
6. Test the queue manager
7. End the queue manager manually, using endmqm
8. On the other nodes, which may takeover the queue manager, run the halinkmqm script

Step 4. Configure the movable resources

The queue manager has been created and the standby/takeover nodes have been updated. You now need to define a resource or service group which will contain the queue manager and all its associated resources. The resource group can be either cascading or rotating. Whichever you choose, remember that the resource group will use the IP address as the service label. This is the address which clients and channels will use to connect to the queue manager.

1. Create a resource group and select the type as discussed above.
2. Configure the resource group in the usual way adding the service IP label, volume group and filesystem resources to the resource group.
3. Synchronise the cluster resources.
4. Start HACMP on each cluster node in turn and ensure that the cluster stabilizes, that the respective volume groups are varied on by each node and that the filesystems are mounted correctly.

Step 5. Configure the Application Server or Agent

The queue manager is represented within the resource group by an application server or agent. The SupportPac includes example server start and stop methods which allow the HA products to start and end a queue manager, in response to cluster commands or cluster events. For HACMP the hamqm_start, hqmam_stop and hamqm_applmon programs are ksh scripts.

1. Define an application server which will start and stop the queue manager. The start and stop scripts contained in the SupportPac may be used unmodified, or may be used as a basis from which you can develop customized scripts. The examples are called hamqm_start and hamqm_stop.
2. Add the application server to the resource group definition created in the previous step.
3. Optionally, create a user exit in /MQHA/bin/rc.local
4. Synchronise the cluster configuration.
5. Test that the system can start and stop the queue manager, by bringing the resource group online and offline.

Step 6. Configure an Application Monitor

To benefit from queue manager monitoring you must define an Application Monitor. If you created the queue manager using hacrtmqm then one of these will have been created for you, in the /MQHA/bin directory, and is called hamqm_applmon.$qmgr.

1. To enable queue manager monitoring, define a custom application monitor for the Application Server created in Step 5, providing the name of the monitor script and tell HACMP how frequently to invoke it. Set the stabilisation interval to 10 seconds.
2. To configure for local restarts, specify the Restart Count and Restart Interval.
3. Synchronise the cluster resources.
4. Test the operation of the application monitoring, and in particular verify that the local restart capability is working as configured.

When the "stop" scripts are called, part of the processing is to forcefully kill all of the processes associated with the queue manager if they do not stop properly. In previous versions of the HA SupportPacs, the list of processes was hardcoded in the stop or restart scripts. For this version, the list of processes is in an external file called hamqproc.

Step 7. Removal of Queue Manager from Cluster

Should you decide to remove the queue manager from the cluster, it is sufficient to remove the application server (and application monitor, if configured) from the HA configuration. You may also decide to delete the resource group. This does not destroy the queue manager, which will continue to function normally, but under manual control.

1. Delete the application monitor, if configured (HACMP/ES only)
2. Delete the application server
3. Remove the filesystem, service label and volume group resources from the resource group.
4. Synchronise the cluster resources configuration.

Step 8. Deletion of Queue Manager

If you decide to delete the queue manager, then you should first remove it from the cluster configuration, as described in the previous step. Then, to delete the QM, perform the following actions.

1. Make sure the queue manager is stopped, by issuing the endmqm command.
2. On the node which currently has the queue manager's shared disks and has the queue manager's filesystems mounted, run the hadltmqm script provided in the SupportPac.
3. You can now destroy the filesystems /MQHA/<qmgr>/data and /MQHA/<qmgr>/log.
4. You can also destroy the volume group.
5. On each of the other nodes in the cluster,
   1. Run the hadltmqm command as above, which will clean up the subdirectories related to the queue manager.
   2. Manually remove the queue manager stanza from the /var/mqm/mqs.ini file.

The queue manager has now been completely removed from the cluster and the nodes.

Communications Applications and Services + HACMP for AIX

• Initialization and Standard Configuration
  • Configuration Assistants
  • Verify and Synchronize HACMP Configuration
  • HACMP Cluster test Tool
  • Display HACMP Configuration
• Extended Configuration
• System Management (C-SPOC)
• Problem Determination Tools
  • HACMP Verification
  • View Current State (SMUX Peer Daemon = clsmuxpdES)
  • HACMP Log Viewing and Management
  • HACMP Trace facility
  • HACMP Error Notification

• Comprobar requeriments (sobretot, filesystem extern)
• Instalar
• Configurar - IP/Listener real/servei MQ/Oracle
• Veure el estat del HACMP
• Commutació manual
• Commutació forçada
  A convenient way to provoke queue manager failures is to identify the Execution Controller process, called AMQZXMA0, associated with the queue manager, and kill it.

  MC91.pdf

  *** Produccion *** [wbrkadm@cmqb131]:/home/wbrkadm > dspmq QMNAME(MQCFGPRD) STATUS(Running) QMNAME(MQPRD01) STATUS(Running) *** Produccion *** [wbrkadm@cmqb131]:/home/wbrkadm > ps -ef | grep amqzx mqm 196680 1 0 Sep 26 - 0:05 amqzxma0 -m MQPRD01 mqm 217102 1 0 Sep 26 - 0:02 amqzxma0 -m MQCFGPRD *** Produccion (2) *** [wbrkadm@cmqb132]:/home/wbrkadm > dspmq QMNAME(MQCFGPRD) STATUS(Ended normally) QMNAME(MQPRD01) STATUS(Ended normally) [root@cmqb131]:~> kill -9 196680 *** Produccion *** [wbrkadm@cmqb131 ]:/home/wbrkadm > dspmq QMNAME(MQCFGPRD) STATUS(Running) QMNAME(MQPRD01) STATUS(Ended unexpectedly)

MQ Clusters reduce administration and provide load balancing of messages across instances of cluster queues. They also offer higher availability than a single queue manager, because following a failure of a queue manager, messaging applications can still access surviving instances of a cluster queue. However, MQ Clusters alone do not provide automatic detection of queue manager failure and automatic triggering of queue manager restart or failover. HA clusters provide these features. The two types of cluster can be used together to good effect.

Applying maintenance
All nodes in a cluster should normally be running exactly the same levels of the WMQ software. Sometimes however it is necessary to apply updates, such as for service fixes. This is best done by means of a "rolling upgrade".
The principle of a rolling upgrade is to apply the new software to each node in turn, while continuing the WMQ service on other nodes. Assuming a two-node active/active cluster, the steps are

1. Select one machine to upgrade first
2. At a suitable time, when the moving of a queue manager will not cause a serious disruption to service, manually force a migration of the active queue manager to its partner node
3. On the machine that is now running both queue managers, disable the failover capabilities for the queue managers.
4. Upgrade the software on the machine that is not running any queue managers
5. Re-enable failover, and move both queue managers across to the newly upgraded machine
6. Disable failover again
7. Upgrade the original box
8. Re-enable failover
9. When it will cause least disruption, move one of the queue managers across to balance the workload

Migration from WMQ V5.3 to WMQ V6
The internal implementation of WMQ V6 has changed from WMQ V5.3 in that it uses additional subdirectories for its IPC keys. A tool is provided with this SupportPac to assist in migrating queue managers created with WMQ V5.3 and its corresponding version of the hacrtmqm script. The hamigmqm script (which is in the common subdirectory of the tar file) can be used even with a currently-running V5.3 queue manager as it creates new files but does not modify any existing files. The procedure described above can be used for migration of WMQ V5.3 to WMQ V6 with this additional step before the first one:

• For all queue managers defined on each node, even if that queue manager is not currently active on this node, run the hamigmqm script. If the queue manager is not active, you might see some errors from the script as it tries to link from the queue manager directories, but these errors can be ignored.

MC91.pdf

Solution : remove "lost+found" directory prior launching "crtmqm".

Top

A complete file looks like this :

qmgr configuration files, qm.ini

How to verify the size of the buffer of a Persistent queue:

This installation procedure uses the pkgadd program, enabling you to choose which components you want to install.

The installation directory for the WebSphere MQ product code is /opt/mqm. Working data is stored in /var/mqm. You cannot change these.

Any (client) error is logged in /var/mqm/errors/AMQERR01.LOG

If you cannot install the product code in this file system (for example, if it is too small to contain the product), you can do one of the following:

1. Create a new file system and mount it as /opt/mqm.
2. Create a new directory anywhere on your machine, and create a symbolic link from /opt/mqm to this new directory.

For example:

Creating a file system for the working data :
Before you install WebSphere MQ for Solaris, create and mount a file system called /var/mqm. Use a partition strategy with a separate volume for the WebSphere MQ data.

Al servidor, donar

• crtmqm -q -u DLQ saturn.queue.manager
• strmqm
• runmqsc
• define qlocal(queue1)
• define channel(channel1) chltype(svrconn) trptype(tcp) mcauser('mqm')
• end
• runmqlsr -t tcp &

Al Client, donar

• ping servidor
• to create a client-connection channel, set the MQSERVER environment variable as follows:
  ksh : export MQSERVER=CHANNEL1/TCP/'server-address(port)' sh : MQSERVER=CHANNEL1/TCP/'server-address(port)' export MQSERVER bask : export MQSERVER='CHANNEL1/TCP/server-hostname(port)'
• change into the /opt/mqm/samp/bin directory, which contains the sample programs.
• ./amqsputc QUEUE1 saturn.queue.manager
• ./amqsgetc QUEUE1 saturn.queue.manager

WebSphere MQ for Solaris, Quick Beginnings, Version 5.3, capitol 5. GC34-6075-02

SPARC 32-bit, C, client

SPARC 32-bit, C, server

Chapter 24, "Building your application on Solaris", Application Programing Guide, MQ v 6.0, SC34-6595-01.

AIX [lope] :

See "how to compile a user-exit"

Pagina 351, Application Programing Guide, MQ v 6.0, SC34-6595-01.

AIX, HACMP, Websphere MQ, Websphere MQ SupportPac MC91, WMB and DB2 should already be installed, using the normal procedures onto internal disks on each of the nodes.

HA for MB, IC91.pdf, page 12 [13/79]

The hamqsicreatebroker command will create the broker and will ensure that its directories are arranged to allow for HA operation.

On any other nodes in the resource group's nodelist (i.e. excluding the one on which you just created the broker) the hamqsiaddbrokerstandby command will create the information required for a cluster node to act as a standby for the broker.

• set the environment variable EXTSHM=ON

  url

• {qm.ini} DefaultBindType=ISOLATED

  url

In AIX, startup of software is controlled by /etc/inittab script so you must add an entry like:

rc.oracle :

rc.mqm :

In order to run an ordenated stop script you must create the /etc/rc.shutdown file, that is read by the shutdown process every time the AIX is rebooted. One problem with /etc/rc.shutdown is that checks for the error code in every execution of the scripts, that is, if the script runs and returns error then shutdown operation will halt. You must review the error condition, and once solved, issue the shutdown again.

Top

Excelent url

The mqconfig script analyzes your system and compares its settings to the IBM recommended values for WebSphere MQ 7.5, 7.1 or 7.0. It displays the results of this comparison in an easy to read format, along with a PASS, WARN, or FAIL grade for each setting. The mqconfig script does not make any modifications to your systems.

Get mqconfig-old for MQ v6 !

MQ v8 details

Few parameters control Inter-Process Communication (IPC) semaphore and shared memory resources used by WebSphere MQ.

Top

Veure CURDEPTH continuament :

on dis_depth.tst té

Tinc un bon repositori !

Top

To stop a queue manager running under MQ for UNIX systems :

• Find the process IDs of the queue manager programs that are still running using the ps command.
  For example, if the queue manager is called QMNAME, use the following command:
  ps -ef | grep QMNAME
• End any queue manager processes that are still running. Use the kill command, specifying the process IDs discovered using the ps command.
• End the processes in the following order :

Note: processes that fail to stop can be ended using kill -9. If you stop the queue manager manually, FFSTs might be taken, and FDC files placed in /var/mqm/errors. Do not regard this as a defect in the queue manager.

The queue manager should restart normally, even after you have stopped it using this method.

URL (sys admin guide)

Top

• MB 6.1 for AIX reqs
• This article describes AIX commands to investigate hardware and AIX
• AIX Info Center - bucket_sizing_factor.
• P550Q specs

• MustGather: No response (hang) or performance degradation on AIX data to gather.

• Configuring and tuning WebSphere MQ for performance on Windows and UNIX : For performance choose circular logging ...

• Problem Determination Across Multiple WebSphere Products on AIX Platform