z/OS MQSeries Queue Manager Administration Tool Via MQClient Running on Windows

This command line tool gives runmqsc-style access to mainframe queue managers from a Windows platform.

I've written it in ANSI C where possible so that it could be compiled on any platform (although it might need a little modification). It works by making an MQClient connection and opening the SYSTEM.COMMAND.INPUT queue. It then creates a dynamic queue modeled on the SYSTEM.COMMAND.REPLY.MODEL for responses.

Then, after command line parsing is done, MQSC commands are sent up to the mainframe which, as long as the command server is running and there is sufficient authority, will throw back a number of responses that I lightly parse (basically to get rid of extra spaces and other extraneous material) and then display results back to the user.

You can maintain connections to various mainframes and switch between them easily (unlike on the mainframe panels). To use it from the command line, type McbOSMQSC; then you're given an interactive prompt.

Before connecting to a queue manager, you need to set your user ID for authentication on the command server. To do this, type:

user <mainframeuserid>

Then, to connect to a mainframe queue manager, use:

con <userdefinedname> <connectionname> [srvconchannel]

You can ommit srvconchannel if it is SERVERCON. Userdefinedname is a unique reference to the conection, so you can refer to it. You now can use normal MQSC commands including: alter, clear, define, and so forth. If you have more than one connection, you can switch between them by using:

  • sw <userdefinedname> to switch a named connection or
  • sw on its own to switch to the next connection or
  • swp on its own to switch to the previous connection

You also can use the transmission queue feature of MQ to connect to mainframes that don't have a server connection channel but have a server link from another mainframe queue manager that does. To do this, switch to a mainframe queue manager that has a server link to the remote queue manager and then type:

conr <userdefinedname> <xmitq>

To quit, type:


You can put multiple commands on the same line by seperating them with a semi-colon:

dis qmgr; dis qlocal(*); dis qr(*)

You can also create aliases that expand to other command(s).

alias aliasname <command> [+ <command2>]

Then, you would refer to the alias by enclosing it in < and >. For example:

alias displayall dis qmgr + dis qlocal(*) + dis qr(*)

Use like this:


Aliases also can expand to other aliases but I don't check for circular references, so be careful not to get stuck in an infinite loop. You can process the contents of a file by using:

file <filename>

For example, you might use this to set up aliases and other commands upfront. Parameters passed after McbOSMQSC when the utility is started will be also be treat as files. For a list of all local commands, type:


MQSeries errors can be looked up by using:

error <errorno>

Providing the attached file containing the reasons codes (Reasons.txt) is located in the same directory as the utility. I've added a piping featue so you can take the results from the command server and call subsequent commands for each response. For example, if I wanted to determine what channel and connection name a remote queue definition used, I might typically have to:

  • Look up the queue to find the XMITQ queue name.
  • Look up the process name from the XMITQ queue name to get the process.
  • Look up the userdata from the process to determine the name of the channel.
  • Look up the channel and obtain the connection name.

This might become a pain if you need to do this for more than one queue. By using pipes, this could be achieved in the utility, as follows:

dis qr(MYQUEUES*) xmitq | echo Queue: {QUEUE} ; dis q({XMITQ}) |
   dis process({PROCESS}) | dis channel({USERDATA}) |
   echo ConnectionName: {CONNAME}

Broken down, the code means the following:

  • dis qr(MYQUEUES*) xmitq |
    Talks to the mainframe command server to ensure the XMITQ attribute is returned for all queues which match the wildcard MYQUEUES*. The pipe '|' at the end of sequence means that the results of the command are sent to the next.
  • echo Queue: {QUEUE} ;
    Display the QUEUE attribute from each of the above responses (the attribute is specified by placing the attribute name in braces "{ and }"—this isn't case sensitive).
  • dis q({XMITQ}) |
    Talk to the mainframe for each of the above responses and obtain the xmit queues for each above response (again, the attribute specified by using braces). The results of this command are then piped on to the next.
  • dis process({PROCESS}) | Talk to the mainframe command server to obtain each process for each of the above nested responses, pipe the results of this command on again...
  • dis channel({USERDATA}) |
    Talk to the mainframe command server and obtain each channel for the above responses, pipe the command on again.
  • echo ConnectionName: {CONNAME}
    Display the connection name.



  • Martyn Brown looking for work

    Posted by Fazer1000 on 10/19/2007 08:32am

    I'm currently looking for a position which allows me to program from home. Alternatively, I'm contemplating a new challenge and lifestyle change with a permanent/contracting position in a nice warm country other than the UK (any serious offer considered). Please contact me if you would like to see my CV. Techical skills below... C/C++ (10+ years), C#/.NET, COM/ATL, STL, MFC/wxWidgets, IBM MQSeries (6+ years) (including MQI/Admin), Windows NT (10+ years) (including RPC/Services/GUI development/ TCP/IP/ multithreading/etc), Visual Basic/VBA, UNIX daemons (ANSI C), x86 Assembler (inline/MASM), Cryptography, SQL Server, Microsoft Access V2 (5 years), Java.

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • IBM Worklight is a mobile application development platform that lets you extend your business to mobile devices. It is designed to provide an open, comprehensive platform to build, run and manage HTML5, hybrid and native mobile apps.

  • New IT trends to support worker mobility — such as VDI and BYOD — are quickly gaining interest and adoption. But just as with any new trend, there are concerns and pitfalls to avoid.  Download this paper to learn the most important considerations to keep in mind for your VDI project.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds