IBM MQ processes unique to IBM MQ for HPE NonStop V8.1
Several new process types have been added to IBM® MQ to provide NonStop specific functionality.
Cache Manager Supervisor:
amqcchsv) has the following tasks:
- On demand, start any of the other NonStop specific process types documented in this topic. If any of these processes fails for whatever reason, the cache manager supervisor restarts it automatically.
- At queue manager end, stop all potentially remaining processes. If certain processes of a queue manager fail (for example, the execution controller EC), typically a takeover to the backup instance running on a different CPU is initiated. To ensure consistency, it is important that no processes of the previous primary instance are running at that point. The cache manager supervisor takes care of that.
The cache manager (executable
amqcache) stores non-persistent messages in main
memory. You can configure multiple instances of this process with logical names, and can assign
different queues to use different instances of the cache manager for scalability. If there are large
queues with non-persistent messages, memory consumption of the cache manager can become large. If
large memory consumption of the cache manager is observed, use runmqsc to view
the current depth of queues, to see which queues might cause that. As the cache manager is a 64-bit
process, its memory use can go up to 12 GB (the default setting for 64-bit processes on
Due to the nature of the
amqcache process, resource consumption (CPU and memory)
might be significant.
If the cache manager fails, all non-persistent messages held by this instance are lost. Under
general IBM MQ rules, non-persistent messages are not
guaranteed. When the cache manager is restarted (which is done automatically), it immediately starts
storing new non-persistent messages. At that point, the queue manager still knows about the lost
non-persistent messages. If the application tries to retrieve one of those messages, for example,
the first one on a queue, it receives an MQ error (2208 MQRC_FILE_SYSTEM_ERROR). The queue manager
then forgets about that lost message. The application must be prepared to receive as many of these
errors as there are lost messages due to the
amqcache failure. After these errors
have been received, the application will start receiving normal non-persistent messages again. So a
failure of the
amqcache process from an application perspective will mean a certain
number of recognized errors and then continued business.
If required, you can suppress 2208 MQRC_FILE_SYSTEM_ERROR messages. You can specify that MQGET does not return this error, but instead returns the next available message or a different error than 2208 (for example, 2033 MQRC_NO_MSG_AVAILABLE).
To suppress error 2208 on MQGET, set the property
in the tool
class QueuePattern; object myBigQueuePattern; set pattern myBigQu*; set IgnoreNPMsgLossErrorOnMQGET T;
myBigQueuePattern is a name of a QueuePattern, and
myBigQu* is a pattern matching queue names.
F restores the default
Any changes only take in effect after a queue manager restart.
amqconfg process keeps a cache of certain configuration settings made using
runnscnf (see Configuring IBM MQ for details), and
provides that to the queue manager. It is a restartable process, so if it fails it will be restarted
and rebuild the cache. No outage should be observed.
The setsignal manager process
amqssmgr) is involved in all activity regarding the MQGET SET SIGNAL
feature. You can configure multiple instances of this process with logical names and can assign
different queues to use different instances for scalability. The process can optionally be
configured to run as a process pair.
$RECEIVE, indicating that MQGET can be called and will get a message. If no interprocess message appears on
$RECEIVE, the application might wait forever. For this reason it is important to run
amqssmgras a checkpointing NonStop process pair. Even if the primary instance fails (for example, due to a CPU outage) the backup instance is still able to notify applications of the event, and so trigger continuation of business. Depending on your application, you should in addition use application timeouts so that even in outage situations applications never become completely unresponsive.
The consistency manager,
amqcnmgr, is started together with the queue manager,
but is only used in situations where a takeover from primary to backup occurs. In that case,
amqcnmgr ensures that the knowledge of the running queue manager regarding open
interactions becomes consistent over time.
For example, assume that Application A starts a TMF transaction and then does an
MQPUT operation that completes without error, the TMF transaction is not yet ended.
Application B (which might be a queue manager internal application like a channel agent) has an
MQGET for that queue outstanding. At that point of time, the queue manager fails
and the backup takes over. The
MQGET of application B will fail, application B will
reconnect to the backup instance of the queue manager, reopen the queue, and reissue the
MQGET. Because the
MQPUT transaction of application A is not yet
finished, the backup instance does not know anything about the message put by A, the corresponding
records in the Enscribe file are still locked by the transaction. When now A ends the transaction,
the queue manager must get notification about the
MQPUT done by A, so that it can
present the message to B. When B does the
MQOPEN of the queue, the
amqcnmgr process is involved and its task is to inform the queue manager about the
outcome and the consequences of any outstanding transactions.
amqcnmgr process could be started on a different CPU than the
queue manager, but this does not make much sense. In normal operations, the
amqcnmgr process does not do any work at all, and even in takeover situations it is
only involved for a short time. Resource consumption is not an issue.
Guardian Bindings Agent:
Each application connecting to the queue manager also connects to an agent doing the queue
manager related work for that application. Depending on the kind of bindings used, different types
of agents are used. When using shared bindings, the agent used is
process of this kind is usually always started with the queue manager, because this kind of
connection is used by all internal components of the queue manager.
For isolated bindings, the corresponding agent executable is
isolated bindings are not recommended on NonStop, you will typically never see this process.
For Guardian bindings, the corresponding agent is
amqzlga0. Since Guardian
bindings are available only on NonStop, this process is only available on NonStop. The
amqzlga0 agent is always threaded; non-threaded agents are not supported with IBM MQ V8 on NonStop.
amqzlga0 agent is able to handle up to 10 concurrent connections. If the
application uses more concurrent connections, IBM MQ
automatically starts more instances of the amqzlga0 process. If your application uses many
concurrent IBM MQ connections, you will see many
amqzlga0 instances. These processes do the main IBM MQ work, so they use significant CPU resources.
amqzlga0 instances must run on the queue manager CPU. Although applications
amqzlga0 using Guardian interprocess messages, and so can run on
any CPU, the
amqzlga0 instances use shared memory with other IBM MQ processes, and so must run on the queue manager CPU