Channel States in MQ

Below are the different states of MQ channels:

STARTING
A request has been made to start the channel but the channel has
not yet begun processing. A channel is in this state if it is waiting
to become active.
BINDING
Channel is performing channel negotiation and is not yet ready to
transfer messages.
INITIALIZING
The channel initiator is attempting to start a channel. This is valid
only on AIX, HP OpenVMS, HP-UX, Linux, i5/OS, Solaris,
Windows, and z/OS. On z/OS, this is displayed as INITIALIZI.
RUNNING
The channel is either transferring messages at this moment, or is
waiting for messages to arrive on the transmission queue so that
they can be transferred.
STOPPING
Channel is stopping or a close request has been received.
RETRYING
A previous attempt to establish a connection has failed. The MCA
will reattempt connection after the specified time interval.
PAUSED
The channel is waiting for the message-retry interval to complete
before retrying an MQPUT operation.
STOPPED
This state can be caused by one of the following:
1. Channel manually stopped
A user has entered a stop channel command against this
channel.
2. Retry limit reached
The MCA has reached the limit of retry attempts at establishing
a connection. No further attempt will be made to establish a
connection automatically.
A channel in this state can be restarted only by issuing the START
CHANNEL command, or starting the MCA program in an
operating-system dependent manner.
REQUESTING
A local requester channel is requesting services from a remote
MCA.

MQ Important Paths

Unix:
Data/working : /var/mqm  

Installation : /opt/mqm (Linux, Solaris, HP-UX)
   /usr/mqm(AIX)

Errors:

MQ errors:
/var/mqm/errors

Queue manager errors:Unix : /var/mqm/qmgrs/<qmgr name>/errors
/var/mqm/qmgrs/QM1/errors

Transation Logs:
/var/mqm/log
/var/mqm/log/<qmgr name>/active

MQ Recovery scenarios

Disk drive failures

You might have problems with a disk drive containing either the queue manager data, the log, or both. Problems can include data loss or corruption. The three cases differ only in the part of the data that survives, if any.

In all cases first check the directory structure for any damage and, if necessary, repair such damage. If you lose queue manager data, the queue manager directory structure might have been damaged. If so, re-create the directory tree manually before you restart the queue manager.

Having checked for structural damage, there are a number of things you can do, depending on the type of logging that you use. 

 Where there is major damage to the directory structure or any damage to the log, remove all the old files back to the queue_manager level, including the configuration files, the log, and the queue manager directory, restore the last backup, and restart the queue manager. 

For linear logging with media recovery, ensure that the directory structure is intact and restart the queue manager. If the queue manager does not restart, restore a backup. If the queue manager restarts, check, using MQSC commands such as DISPLAY QUEUE, whether any other objects have been damaged. Recover those you find, using the rcrmqobj command. For example: 

rcrmqobj -m queue_manager -t all * 

where queue_manager is the queue manager being recovered. -t all * indicates that all objects of any type (except channels) are to be recovered. If only one or two objects have been reported as damaged, you can specify those objects by name and type here. 

For linear logging with media recovery and with an undamaged log, you might be able to restore a backup of the queue manager data leaving the existing log files and log control file unchanged. Starting the queue manager applies the changes from the log to bring the queue manager back to its state when the failure occurred. 

This method relies on two things: 

1.      You must restore the checkpoint file as part of the queue manager data. This file contains the information determining how much of the data in the log must be applied to give a consistent queue manager. 

2.      You must have the oldest log file required to start the queue manager at the time of the backup, and all subsequent log files, available in the log file directory. 

If this is not possible, restore a backup of both the queue manager data and the log, both of which were taken at the same time. 

For circular logging, restore the queue manager from the latest backup that you have. Once you have restored the backup, restart the queue manager and check as above for damaged objects. However, because you do not have media recovery, you must find other ways of re-creating the damaged objects. 

Damaged queue manager object

If the queue manager object has been reported as damaged during normal operation, the queue manager performs a preemptive shutdown. There are two ways of recovering in these circumstances, depending on the type of logging you use:

For linear logging only, manually delete the file containing the damaged object and restart the queue manager. (You can use the dspmqfls command to determine the real, file-system name of the damaged object.) Media recovery of the damaged object is automatic. 

 For circular or linear logging, restore the last backup of the queue manager data and log and restart the queue manager.

Damaged single object

If a single object is reported as damaged during normal operation: 

For linear logging, re-create the object from its media image.

For circular logging, we do not support re-creating a single object.

Automatic media recovery failure

If a local queue required for queue manager startup with a linear log is damaged, and the automatic media recovery fails, restore the last backup of the queue manager data and log and restart the queue manager.