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

The cache manager supervisor process (executable amqcchsv) has the following tasks:
  1. 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.
  2. 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.
CPU consumption of this process is usually extremely small.

Cache Manager: amqcache

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 NonStop).

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 IgnoreNPMsgLossErrorOnMQGET in the tool runnscnf:

class QueuePattern;
object myBigQueuePattern;
set pattern myBigQu*;
set IgnoreNPMsgLossErrorOnMQGET T;

where myBigQueuePattern is a name of a QueuePattern, and myBigQu* is a pattern matching queue names.

Setting IgnoreNPMsgLossErrorOnMQGET to F restores the default behavior.

Any changes only take in effect after a queue manager restart.

Config Manager: amqconfg

The 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.

Setsignal Manager: amqssmgr

The setsignal manager process (executable 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.

Note: An application using the MQGET SET SIGNAL feature typically waits for messages on $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 amqssmgr as 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.
Due to the nature of the process, resource consumption (CPU and memory) might be significant.

Consistency Manager: amqcnmgr

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.

Technically, the 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: amqzlga0

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 amqzlaa0. A 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 amqzlsa0. As 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.

Each 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.

All amqzlga0 instances must run on the queue manager CPU. Although applications communicate with 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 only.