Bitesize Blogging: MQ V8 - Client MQSC
63SV_Jonathan_Rumsey 11000063SV Comments (3) Visits (2033)
Another in the series of bitesize blog posts about features in MQ V8. Check out the whole series here.
Have you ever tried configuring an MQ client connection beyond the very basic settings of a channel name and connection name, such as calling a channel exit or adding SSL ? If so you'll probably be familiar with the client channel table, or AMQCLCHL.TAB file and you'll probably also know that any changes to this file need to be made at the queue manager end and then copied out to clients.
How about remotely administering a queue manager using MQSC commands rather than the MQ Explorer GUI - there are some great Cat 3 support pacs and 3rd party offerings that offer this type of feature, but should the MQ product be able to offer this out of the box ?
With MQ V8, runmqsc is now capable of running in two new modes offering the flexibility of managing a client channel table, on a client system. Not only can you configure a client connection to a queue manager from the client end, but you can now also use that connection to remotely administer the queue manager on any MQ V8 client platform.
New MQSC 'modes' (non-connected and client)
The runmqsc binary has moved from the MQ server installation fileset to the MQ runtime installation fileset, in practical terms this means you get runmqsc whether you are installing an MQ server or just an MQ client.
Various new command line parameters have been added to runmqsc in MQ v8;
Starting off with -n, non-connected mode... this command line flag indicates that runmqsc should not connect to a queue manager but instead manage its client-channel table. The -n is an exlusive flag, that is it must be specified on its own as the only command line flag to put runmqsc into non-connected mode.
In non-connected mode only a subset of the full MQSC command dictionary is allowed - that is commands that manage the contents of a client channel table, namely ALTE
The commands issued in this mode operate on the local client channel table, the location and name of the client channel table are taken from the MQCHLLIB and MQCHLTAB environment variables or defaulted to the product installation directory and AMQCLCHL.TAB if omitted.
Client connection mode
The second new mode is client connection mode, or -c. Under the hood this mode of runmqsc works in the same way as 'queued' mode where MQSC commands are put as PCF messages onto the remote queue managers command server queue, the command server parses and executes the MQSC command string and responses are received on a temporary dynamic queue.
The client connect mode uses the usual sequence of environment variables and ini files to locate client channel details to connect to a queue manager, e.g. MQSERVER, MQCHLLIB, MQCHLTAB, mqclient.ini.
Here is an example of client runmqsc connecting over client channel SYST
You are not limited to remote administration of distributed queue managers, you can also connect runmqsc to a z/OS queue manager too. You don't have to use the MQ Explorer for out of the box remote queue manager administration - sabre-toothed MQ administrators can flex their MQSC skills via the two new MQSC modes.
One more thing...
You may have also noticed that runmqsc also supports a -u command line parameter, this can be used with any mode of MQSC that connects to a queue manager. It allows you to pass a username (and then prompts for a password) for authentication purposes when connecting to a queue manager.
If you have created a new MQ v8 queue manager then your default CONNAUTH settings are going to require that client connections that request an administrative id, provide an operating system userid and password for authentication. This command line parameter may come in useful should you be using an 'mqm' type user to perform remote administration.