Creating the WMQ Connection server connection channel
Following the installation of the TrueSight Middleware and Transaction Monitor (TMTM) product, you may create the TrueSight Middleware Administrator (TSMA) WMQ Connection for a queue manager for any queue manager that exists in the TMTM object respository.
You may also create a WMQ Connection whenever a new queue manager is discovered and added to the TMTM object repository. This occurs after distribution and installation of an agent or creation of a new queue manager on a machine with an existing agent.
You create a WMQ Connection so that you can perform WebSphere MQ Administration of that queue manager. See Working with queue managers, queues, and channels.
Before deciding on the method to use to create the server connection channel WMQ connection, review this topic to familiarize yourself with the channel options and methods available to you.
Connection channel options
A queue manager in TSMA is represented as a WMQ Connection, which contains the necessary information to connect to the queue manager as a client. TMTM can assist in creating the WMQ Connections as agent and WebSphere MQ extension packages are deployed and configured or immediately after an upgrade for existing installations. The following configurations are supported:
TMTM monitoring with local agent
In this setup, TSMA uses its own server connection channel to connect to the queue manager and you can set up channel authentication. TMTM has a local bindings connection to the queue manager.
TMTM agentless monitoring with separate channels
In this setup, TSMA uses its own server connection channel to connect to the queue manager and you can set up channel authentication. TMTM has a local bindings connection to the queue manager.
TMTM agentless monitoring with shared channel
In this setup, each connection to the queue manager uses its own server connection channel, which enables you to restrict connections to those from Host A or Host B, respectively.
Because each channel can specify different authentication, BMC recommends this configuration when TMTM uses an agentless configuration on the queue manager host server.
Multi-instance queue managers
IBM defines multi-instance queue managers as instances of the same queue manager configured on different servers. One instance of the queue manager is defined as the active instance and another instance is defined as the standby instance. All instances of a multi-instance queue manager can be identified by the same queue manager identifier, or qmid.
There are two ways to multi-instance queue managers can be handled in TMTM. The first is to have an agent and extension for each queue manager instance. In this case, each queue manager instance of the same name will exist under a different agent in the TMTM hierarchy. If you are using an agentless configuration, the connection string may be specified such that the WebSphere MQ extension connects to the active queue manager instance. In this case, there is a single agent and queue manager hierarchy representing all the queue manager instances.
By default, TMTM will collate by queue manager identifier and create a single TSMA WMQ Connection representing all the queue manager instances. When this occurs the name of the WMQ Connection is the queue manager identifier and the connection string consists of all known host names and TSMA will connect to the active queue manager instance. You can override this behavior by setting the collate_by_qmid=false keyword under the [Admin] stanza in services.cfg. When doing so, the WMQ Connection will be created using the standard convention of the agent name concatenated with the queue manager name separated by an underscore. Each WMQ Connection represents a single queue manager instance and therefore will only successfully connect if it is the active instance.
Listener port determination and channel definitions
Each queue manager that TSMA manages requires a channel listener, server connection channel and channel authentication records. When TMTM creates the TSMA WMQ Connection it can also create the channel listener, server connection channel and channel authentication records based on the inputs provided to a policy action, dialog or mqtool utility. If the replace option is specified, any existing listeners and channels are stopped and deleted prior to being recreated. Corresponding channel authority records are also removed.
A channel listener specifies the TCP port to which TSMA will connect to as a MQ client. This port must be exclusively used by a single queue manager. If a specific port is specified it is assumed a channel listener already exists and specifies that port. On z/OS this is the only option allowed. You would also use this option when using an external listener such as inetd or runmqlsr. An alternative is to specify a range of ports to try. However, prior to using a port from the port range, if a TCP listener already exists then that port is used. If other queue managers exist, listeners from accessible queue managers are examined and any of those ports are excluded from the port range specified. Additionally, a port scan is performed and if any ports are found to be listening, those ports are also excluded. If any ports remain, the first one available remaining in the range is used and a listener with the name TSMA.LISTENER is created. Using a port range is recommended for policies or when using mqtool options that match multiple queue managers on the same agent machine since an exclusive port must be determined. A port scan does not work if a firewall exists between the services and the queue manager and it is recommended you specify a port if the port range selected may have other ports that are listening for connections to other applications.
A channel is created with the name specified. You should consider company naming standards when choosing a name. Channel authority records are set for this channel. Any channel authority records with wildcards that apply to multiple channel are not altered. If a user is specified, the channel authority records for the created channel are defined to allow access only to that user from the TSMA host machine by default. If no user is specified the channel authority records for the created channel are defined to allow access only from the TSMA host machine by default. If you specify an ip address input, it overrides the default of the TSMA host machine. Make sure you include the TSMA host IP address in the IP address input. Note this field may contain the same values as the channel authority record allows so it can be a wildcarded IP address.
The queue manager is altered via an API that uses PCF or by a single mqsc script. When using a mqsc script you may specify additional channel values as a single string when specifying the inputs. For example, you might specify the channel description or set some additional security settings. If additional security settings are specified you may need to manually make corresponding changes to the TSMA WMQ Connection.
If you do not wish TMTM to modify your queue manager you can use mqtool to define the mqsc script that would be applied. You can then modify as required and apply the mqsc script yourself either using mqtool or runmqsc. For details about these and other mqtool commands, see Managing integration with TrueSight Middleware Administrator.
If you alter the channel definitions directly, make sure to change your policy action to not replace existing definitions so the channel is not accidentally reverted back to its original settings. Additionally, if using mqtool or the dialog, do not select the checkbox to replace the definition.
Supported methods to define the server connection channel and TSMA WMQ Connection
The following table describes the methods, and the benefits of each method, that you can use to configure the connection.
| Method | Benefit |
|---|---|
| Setting up a policy to create the WMQ Connection server connection | This method enables you to apply the action to many queue managers at once and consistently again as new queue managers are created. MQ objects are created automatically. BMC recommends this method. |
| Setting up the WMQ Connection server connection channel from the Management Console | This method enables you to create the WMQ Connection for a single queue manager. This option is useful for troubleshooting or in a smaller development or test environment. |
| Using the mqtool utility to create the WMQ Connection server connection channel | Similar to using policies, this method enables you to apply the action to many queue managers at once. However, you can choose to apply the mqsc script used to alter the MQ objects to create the server conn channel manually or via the tool. |
Synchronization
TMTM may periodically synchronize with TSMA and will add or remove TSMA WMQ Connections to correspond with the queue managers that exist in the TMTM object repository. By default, synchronization is enabled and occurs every five minutes. See Managing integration with TrueSight Middleware Administrator with the CLI v8.1 to change the synchronization interval. An interval of 0 will disable synchronization. A TSMA WMQ Connection will only be created if inputs have been defined by one of the methods above. However, if the server connection channel has not yet been created it will not do so, and one of the methods above should be used. You may notice a WMQ Connection in this state if it fails when you test the connection from within the TSMA console or the Object Repository tab of the TMTM Management Console.
Obtaining information about your MQ environment
You can use the following commands in the mqtool utility to display some MQ information that is useful for defining the server conn channel. For details about these and other mqtool commands, see Managing integration with TrueSight Middleware Administrator.
-
--list-listeners -
--list-srvrconn-channels -
--list-chlauth --list-qm-authrec
Comments
Log in or register to comment.