Last part of a series of posts on working with IBM WebSphere MQ from Windows PowerShell

Over my last four posts, I’ve given an introduction to how to use Windows PowerShell to administer WebSphere MQ, using SupportPac MO74.

For my final post in this series, I want to look at some more advanced uses of PowerShell, focusing on things that cannot be done easily with runmqsc or WebSphere MQ Explorer.

The last four posts have covered the cmdlet basics : New-WMQ, Get-WMQ and Set-WMQ. Where things get interesting is in combining them through the use of the object pipeline.

Let’s start with some imaginary scenarios for a WMQ sys-admin. Simplistic, but they should suffice for purposes of demonstration.

“Some of the queues used by the sales team are getting a bit full. Can you increase the amount of space in them?”

To clarify:
“by the sales team” means queues with names beginning with “SALES.”
“a bit full” means queues that are ten messages away from their maximum message depth
“increase” means double the existing maximum message depth

With some use of the pipeline, we can do this in a single line which will check all queue managers on our system.

PS C:\> Get-WMQQueue | Where {$_.QueueType -eq "Local" -and $_.CurrentDepth -gt ($_.MaximumDepth - 10)}
| foreach {Set-WMQQueue $_ -MaximumDepth ($_.MaximumDepth * 2)}

The command gets all queues, then filters them so only queues with a current depth greater than ten less than their maximum depth go into the pipeline. Each of the objects in the pipeline is then passed to a Set-WMQQueue command to modify the maximum depth property - using the current maximum depth property to start with.

This means that each Set-WMQQueue command can be setting the max depth of each queue to a different value. The ForEach cmdlet allows for more sophisticated modifications than a static command like 

Set-WMQQueue -MaximumDepth 100

“We’re starting to see errors with the channels on a queue manager. What has changed with them since last week, when they were working fine?

When you reach a known good point, you can save object definitions to CSV file: 

PS C:\> Get-WMQChannel -QmgrName MyQm | Export-Csv mychans.csv

Then, at a later date when you need to see what has changed: 

PS C:\> Compare-Object (Import-Csv mychans.csv) (Get-WMQChannel -QmgrName MyQm) -Property Name, ChannelType, ConnectionName, TransmissionQueueName, ...

This command is explicitly specifying the attributes to consider when making a comparison. It might be easier to use Get-Member -MemberType Properties to get all of them more easily.

“I need to verify my SSL configuration.”

To start with, why not check that your SSL key repository files are in the right place? 

PS C:\> Get-WMQQueueManager | Select Name, @{e={ ( $_.SSLKeyRepository + ".kdb") | Test-Path };n='Key repository present'}, @{e={ ( $_.SSLKeyRepository + ".kdb" ) | Test-Path };n='Stash file present'}

Name                           Key repository present        Stash file present
----                           ----------------------        ------------------
NEW                    ...                      False                     False
qmgr1fish              ...                       True                      True
TESTQM                 ...                      False                     False
TESTQM2                ...                       True                      True

PS C:\>

“We need to check our transmission queues.”

We can check that all of our channels have transmission queue name properties which refer to an actual local queue, which has Usage set to ‘Transmission Queue’, and is put enabled. 

PS C:\> Get-WMQChannel -QmgrName qmgr1test | Where {$_.Name -notlike "SYSTEM.*" } | Select Name, TransmissionQueueName, @{e={ (Get-WMQQueue -qmgrname qmgr1test -Name ($_.TransmissionQueueName) | Where {$_.Usage -eq "Transmission" -and $_.InhibitPut -eq "Allowed"}) -ne $null }; n='Valid transmission queue'}

Name                    TransmissionQueueName         Valid transmission queue
----                    ---------------------         ------------------------
broken                  nonexistent                                      False
qmgr1test.qmgr2test     xmit_queue                                        True

PS C:\>

A command-line ‘Healthcheck’?

It should be possible to write such PowerShell commands that implement all of the functions in the WebSphere MQ Explorer ‘Tests’ plugin (introduced in v6.0.2.0).

These could be grouped together and saved into functions - making it easier to run them repeatedly as needed. The functions could include comparing the output with the output from previous known-good runs and/or emailing it to a sys-admin. The execution of these could even be scheduled to run regularly.

Over time, it should be possible to build up a toolbox of scripts that can thoroughly but quickly check all of your queue managers.

What’s next?

The aim of this series of posts was to demonstrate the benefits of using PowerShell over traditional runmqsc scripting.

For more examples, there is a “Cookbook for ‘PowerShell for WebSphere MQ’” - which contains dozens of worked examples for using PowerShell with your queue managers. Download the MO74 zip file and you will find the powershellcookbook.pdf included.

I hope that readers will be able to take this further and think of more ways to use PowerShell - I’ve set up a forum where more command examples can be shared. As I think of more examples (or try porting more tests from the WMQ Explorer ‘Tests’ plugin), I will post them there.

What do you think?

What do you think about this? Feedback on the SupportPac or the potential of PowerShell administration for WebSphere MQ, is very welcome. If you have any questions, I’d also be happy to try and answer them.