PowerShell is Microsoft’s new command line. Released last year, it introduced a number of enhancements over the traditional Windows Command Prompt, including a novel object-oriented approach.
I won’t go into the background about PowerShell – if you’re interested, a quick search will turn up masses of information, everything from detailed guides to the first impressions of obscure bloggers!
One of the more interesting features is the ability to access the .NET API – directly from the command line. So I thought it would be interesting to point out that with PowerShell, the .NET bindings available for WebSphere MQ means that you can interact with queue managers from the command line.
It means that pretty much anything that you could do with WMQ from a .NET application can now be done from the command line.
For example, putting a message to a queue on a local queue manager…
The first (and only tricky) thing you need to do is load the WebSphere MQ DLL into PowerShell:
[System.Reflection.Assembly]::LoadFrom("C:\\Program Files\\IBM\\WebSphere MQ\\bin\\amqmdnet.dll")
If you do this right, it prints out an entry showing the registered DLL.
From then on, it’s much like typical C# programming, with slightly different syntax for object constructors:
$qmgr = new-object IBM.WMQ.MQQueueManager("DALES_QMGR") $queue = $qmgr.AccessQueue("QUEUE_1", 49) $mymessage = new-object IBM.WMQ.MQMessage $mymessage.WriteUTF("Hello Dale. I was sent from the PowerShell") $queue.Put($mymessage)
(The more observant of you might notice that I cheated slightly – using ’49’ for the queue’s open options. This was made up from: MQOO_INPUT_AS_Q_DEF (0x00000001), MQOO_OUTPUT (0x00000010), and MQOO_INQUIRE (0x00000020). I’m sure that there is a way to get these constants in the Shell as well, but at first glance I haven’t spotted how.)
You could then get the message back, like this:
$my2ndmessage = new-object IBM.WMQ.MQMessage $queue.Get($my2ndmessage) $msgstring = $my2ndmessage.ReadUTF() echo $msgstring
I’ve kept to the smallest API calls to keep the example as simple as possible. But you could make them as complicated as you want. For example, you could add get-options so that the MQGET call blocks until a message arrives, giving you something like this:
[System.Reflection.Assembly]::LoadFrom("C:\\Program Files\\IBM\\WebSphere MQ\\bin\\amqmdnet.dll") $qmgr = new-object IBM.WMQ.MQQueueManager("DALES_QMGR") $queue = $qmgr.AccessQueue("QUEUE_1", 49) $mymessage = new-object IBM.WMQ.MQMessage $mygetoptions = new-object IBM.WMQ.MQGetMessageOptions $mygetoptions.Options = 1 $mygetoptions.WaitInterval = -1 $queue.Get($mymessage, $mygetoptions)
And the last
Get call will block until a message is available on the queue.
When a message arrives, the call completes and a prompt appears on the next line, letting you display the message as before:
(As before, I’ve cheated again with the constants, using 1 to indicate a get option with wait, and 1 to indicate an unlimited wait.)
This opens up the chance for some very powerful scripting in WebSphere MQ environments, without needing applications that need compiling and so on. For simple tasks, it could be a useful alternative to writing applications that need re-compiling after changes.
I’m not sure if there will be a big demand for this, but I thought it was pretty cool anyway! 🙂