Update (13/12/2007): The contents of this post have since been largely superseded by the release of PowerShell cmdlets for WebSphere MQ.
A better way to do filtering
A follow-on post from WebSphere MQ scripting using PowerShell - part 2
In hindsight, my approach to filtering was too restrictive (filtering by name only). Instead, it would be better for the function to just return queue objects, and let the user use the built-in functions to filter on them as they want.
Display objects…
- Choose which attributes you want to be outputted
- Apply filters - return queues whose parameter(s) match certain filters (supporting complex queries with AND and OR)
- Sort by a parameter
And do this for local or remote queue managers.
I’m leaving Display-WMQQueues as it is, and have started a new function - Get-WMQQueues - to do this.
This is much much better:
PS-WMQ DALE > Get-WMQQueues | Select Name, CurrentDepth
Name CurrentDepth
---- ------------
SYSTEM.ADMIN.ACCOUNTING.QUEUE 0
SYSTEM.ADMIN.ACTIVITY.QUEUE 0
SYSTEM.ADMIN.CHANNEL.EVENT 0
SYSTEM.ADMIN.COMMAND.QUEUE 0
SYSTEM.ADMIN.LOGGER.EVENT 0
SYSTEM.ADMIN.PERFM.EVENT 0
SYSTEM.ADMIN.QMGR.EVENT 1
SYSTEM.ADMIN.STATISTICS.QUEUE 0
SYSTEM.ADMIN.TRACE.ROUTE.QUEUE 0
SYSTEM.AUTH.DATA.QUEUE 54
SYSTEM.CHANNEL.INITQ 0
SYSTEM.CHANNEL.SYNCQ 0
SYSTEM.CICS.INITIATION.QUEUE 0
SYSTEM.CLUSTER.COMMAND.QUEUE 0
SYSTEM.CLUSTER.REPOSITORY.QUEUE 1
SYSTEM.CLUSTER.TRANSMIT.QUEUE 0
SYSTEM.DEAD.LETTER.QUEUE 0
SYSTEM.DEFAULT.INITIATION.QUEUE 0
SYSTEM.DEFAULT.LOCAL.QUEUE 0
SYSTEM.PENDING.DATA.QUEUE 0
TINY_QUEUE 12
.
PS-WMQ DALE > Get-WMQQueues | Select Name, CurrentDepth | Where { $_.CurrentDepth -gt 0 }
Name CurrentDepth
---- ------------
SYSTEM.ADMIN.QMGR.EVENT 1
SYSTEM.AUTH.DATA.QUEUE 54
SYSTEM.CLUSTER.REPOSITORY.QUEUE 1
TINY_QUEUE 12
.
PS-WMQ DALE > Get-WMQQueues | Select Name, CurrentDepth | Where { ($_.CurrentDepth -gt 0) -and ($_.Name -like "*CLUSTER*") }
Name CurrentDepth
---- ------------
SYSTEM.CLUSTER.REPOSITORY.QUEUE 1
.
You don’t need to compare against static values in your filters, either - for example:
PS-WMQ DALE > Get-WMQQueues | Select Name, CurrentDepth, DepthHighLimit | Where { $_.CurrentDepth -gt $_.DepthHighLimit }
Name CurrentDepth DepthHighLimit
---- ------------ --------------
TINY_QUEUE 12 10
Any feedback on this new function would be gratefully received.
The code is below (note that it needs the code from yesterday’s post to work)
#
# Get queue objects from the queue manager
#
function Get-WMQQueues
{
# display details of any WMQ errors encountered in this function
Trap [IBM.WMQ.MQException]
{
Write-Error ("WMQ Exception: CC=" + $_.Exception.CompletionCode + " RC=" + $_.Exception.ReasonCode)
continue
}
# if we have a connection to a queue manager...
if ($Global:psWMQQmgrHandle -ne $null)
{
$qNames = Get-WMQQueueNames
foreach ($queuename in $qNames)
{
$nextQueue = $Global:psWMQQmgrHandle.AccessQueue($queuename.Trim(),
[IBM.WMQ.MQC]::MQOO_INQUIRE)
Write-Output $nextQueue
}
}
else
{
Write-Host "Not connected to a queue manager"
}
}

5 comments
Comments feed for this article
May 1, 2007 at 4:00 pm
jefflowrey
I’ve always found the Perl modules to provide a more than sufficient set of functionality for most MQ scripting tasks.
Of course, this has two caveats: 1) that you know Perl, and 2) that, if you want to do stuff on Windows, you can compile the modules to run on Windows (it’s a lot easier on Unix than on Windows).
On the flip side, the scripts are immediately portable between Windows and Unix.
Then there’s the usual value proposition of writing scripts instead of buying and implementing a professional solution…
May 2, 2007 at 3:20 pm
Dale Lane
@jefflowrey
Thanks very much for your comment, and for raising an interesting point about the many ways to interact with WebSphere MQ.
In my opinion, your first caveat is really the key point - that is, the best tool for someone is often the one that they know and like the best. Particularly when talking about something like WebSphere MQ where it is often a part of a larger solution, the ideal approach to administration is one which fits neatly with how you administer everything else around it.
I’ve read a number of articles recently which pitch a vision of Windows sys-admins using PowerShell for nearly everything - being the core part of their toolkit that brings all their tasks together. I don’t know if this is going to happen, but if it does then I imagine that those users will want WMQ to play nicely in this space.
So I wouldn’t advocate moving to PowerShell solely for WMQ scripting. Rather I wanted to highlight that, if you are a Windows sys-admin moving to using PowerShell for user management, resource monitoring, server configuration et al., then you can include your WebSphere MQ work alongside all of this - even mixing all of this within single commands.
July 3, 2007 at 9:12 pm
Brent Morris
Thank you for the use of Power Shell and the managed DLL. I have been want to explorer the 2 Technologies. Your review is outstanding.
September 5, 2007 at 2:08 pm
learning something new » Blog Archive » Writing PowerShell cmdlets
[...] of PowerShell means you can run any .NET API at the Shell. In fact, this is what I did when I first played with PowerShell using the WebSphere MQ .NET API. It’s a nice quick way to get started (assuming you know .NET!) without having to learn much [...]
October 22, 2007 at 12:30 am
learning something new » Blog Archive » An introduction to Windows PowerShell
[...] be good to address some of the misunderstandings I had about PowerShell when I wrote about it before. In the presentation, I will be giving an introduction to Windows PowerShell - what [...]