Object types

Authentication information objects

An authentication information object provides the definitions required to perform certificate revocation checking.

The queue manager authentication information object forms part of IBM MQ support for Transport Layer Security (TLS). It provides the definitions needed to check for revoked certificates. Certification Authorities revoke certificates that can no longer be trusted.

You can use the MQSC command DEFINE AUTHINFO to define an authentication information object. For more information about the attributes of authentication information objects, see DEFINE AUTHINFO.

For an overview of TLS, and the use of the authentication information objects, see Transport Layer Security (TLS) concepts and TLS security protocols in IBM MQ.

Channels

Channels are objects that provide a communication path from one queue manager to another.

See Channels for more information.

Communication information objects

IBM MQ Multicast offers low latency, high fanout, reliable multicast messaging. A communication information (COMMINFO) object is needed to use Multicast transmission.

See IBM MQ Multicast for more information.

A COMMINFO object is an IBM MQ object that contains the attributes associated with multicast transmission. For more information about these attributes, see DEFINE COMMINFO. For more information about creating a COMMINFO object, see Getting started with multicast.

Listeners

Listeners are processes that accept network requests from other queue managers, or client applications, and start associated channels.

Listener processes can be started using the runmqlsr control command.

Listener objects are IBM MQ objects that allow you to manage the starting and stopping of listener processes from within the scope of a queue manager. By defining attributes of a listener object you do the following:

• Configure the listener process.
• Specify whether the listener process automatically starts and stops when the queue manager starts and stops.

Important: Listener objects are not supported on IBM MQ for z/OS®. For more information about how IBM MQ for z/OS implements listening, by using the channel initiator, see The channel initiator on z/OS.

Namelists

A namelist is an IBM MQ object that contains a list of cluster names, queue names or authentication information object names. In a cluster, it can be used to identify a list of clusters for which the queue manager holds the repositories.

A namelist is an IBM MQ object that contains a list of other IBM MQ objects. Typically, namelists are used by applications such as trigger monitors, where they are used to identify a group of queues. The advantage of using a namelist is that it is maintained independently of applications; it can be updated without stopping any of the applications that use it. Also, if one application fails, the namelist is not affected and other applications can continue using it.

Name lists are also used with queue manager clusters to maintain a list of clusters referred to by more than one IBM MQ object.

You can define and modify namelists by using the MQSC commands DEFINE NAMELIST and ALTER NAMELIST .

Note: Alternatively, on z/OS, you can use the IBM MQ for z/OS operations and control panels

Programs can use the MQI to find out which queues are included in these namelists. The organization of the namelists is the responsibility of the application designer and system administrator.

For a list of namelist attributes available to use, see Attributes for namelists,

Process definitions

Process definition objects allow applications to be started without the need for operator intervention by defining the attributes of the application for use by the queue manager.

The process definition object defines an application that starts in response to a trigger event on an IBM MQ queue manager. The process definition attributes include the application ID, the application type, and data specific to the application. For more information, see Initiation queues in Queues used for specific purposes by IBM MQ.

To allow an application to be started without the need for operator intervention, as described in Starting IBM MQ applications using triggers, the attributes of the application must be known to the queue manager. These attributes are defined in a process definition object.

The ProcessName attribute is fixed when the object is created. However, you can change other attributes by using the IBM MQ commands.

Note: Alternatively, on z/OS, you can use the IBM MQ for z/OS operations and control panels.

You can inquire about the values of all the attributes by using MQINQ - Inquire object attributes.

For a list of process definition attributes available to use, see Attributes for process definitions.

Queues

An IBM MQ queue is a named object on which applications can put messages, and from which applications can get messages.

See Queues for more information.

Queue managers

IBM MQ queue managers provide queuing services to applications, and manages the queues that belong to them.

See Queue managers for more information.

Services

Service objects are a way of defining programs to be run when a queue manager starts or stops.

Programs can be one of the following types:

Servers

A server is a service object that has the parameter SERVTYPE specified as SERVER. A server service object is the definition of a program that will be executed when a specified queue manager is started. Only one instance of a server process can be executed concurrently. While running, the status of a server process can be monitored using the MQSC command, DISPLAY SVSTATUS. Typically server service objects are definitions of programs such as dead letter handlers or trigger monitors, however the programs that can be run are not limited to those supplied with IBM MQ. Additionally, a server service object can be defined to include a command that will be run when the specified queue manager is shut down to end the program.

Commands

A command is a service object that has the parameter SERVTYPE specified as COMMAND. A command service object is the definition of a program that will be executed when a specified queue manager is started or stopped. Multiple instances of a command process can be executed concurrently. Command service objects differ from server service objects in that once the program is executed the queue manager will not monitor the program. Typically command service objects are definitions of programs that are short lived and will perform a specific task such as starting one, or more, other tasks.

Important: Service objects are not supported on IBM MQ for z/OS.

For more information see Working with services.

Storage classes

A storage class maps one or more queues to a page set.

This means that messages for that queue are stored (subject to buffering) on that page set.

Storage classes are supported only on IBM MQ for z/OS.

For further information about storage classes, see Planning your IBM MQ environment on z/OS.

Topic objects

A topic object is an IBM MQ object that allows you to assign specific, non-default attributes to topics.

A topic is defined by an application publishing or subscribing to a particular topic string. A topic string can specify a hierarchy of topics by separating them with a forward slash character (/). This can be visualized by a topic tree. For example, if an application publishes to the topic strings /Sport/American Football and /Sport/Soccer, a topic tree is created that has a parent node Sport with two children, American Football, and Soccer.

Topics inherit their attributes from the first parent administrative node found in their topic tree. If there are no administrative topic nodes in a particular topic tree, then all topics inherit their attributes from the base topic object, SYSTEM.BASE.TOPIC.

You can create a topic object at any node in a topic tree by specifying that node's topic string in the TOPICSTR attribute of the topic object. You can also define other attributes for the administrative topic node. For more information about these attributes, see The MQSC commands, or Automating administration using PCF commands. Each topic object, by default, inherits its attributes from its closest parent administrative topic node.

Topic objects can also be used to hide the full topic tree from application developers. If a topic object named FOOTBALL.US is created for the topic /Sport/American Football, an application can publish or subscribe to the object named FOOTBALL.US instead of the string /Sport/American Football with the same result.

If you enter a #, +, /, or * character within a topic string on a topic object, the character is treated as a normal character within the string, and is considered to be part of the topic string associated with a topic object.

For more information about topic objects, see Publish/subscribe messaging.