PowerShell to WebSphere MQ. Thoughts on an Authentic Voice of Interoperability at Microsoft

We’re on the record as being fans of Jeffrey Snover, the architect and driving force behind Microsoft PowerShell– a scripting and automation technology that now sits behind the management front ends of all products in the Windows Server family. PowerShell is the command line for admins that Windows always lacked, the missing link that would have persuaded hardcore ops people that Microsoft was serious about management.

Jeffrey has been on RedMonkTV before. Indeed its about time we had him back.

The other day on twitter Dale Lane, an IBM employee, said something interesting.

heard nothing about my PowerShell library for WMQ in many months, then two people contact me about it in one day! strange 🙂

I decided to follow up, which led me to this IBM documentation and SupportPac, which allows you to manage WebSphereMQ events from PowerShell. So far so good.

But it was in reading Jeffrey on the subject of PowerShell to MQ that reminded me just how important this authentic voice of interoperability is to Microsoft. People like Jeffrey are why Microsoft Server products have come so far in the last couple of years.

Let me be quick to so that they did a very good job on their cmdlets in terms of using the naming guidelines.  I can’t tell you how thrilled I am at the great job they did.  That said, I’m not at all surprised.

A lot of people are quick to say how much PowerShell looked to Unix for inspiration.  That is true and we have a deep respect and admiration for that community and that body of work.  That said, for some reason people don’t pick up on my statements about how influential the AS400 CL and VMS DCL models where in the conceptual model for PowerShell.

Both AS400 CL and VMS/DCL were hardcore about consistent naming.  This is one of the reasons why operators love those systems.  You invest in learning the naming and then it is consistent and easy to remember.  Both system did parsing instead of the individual commands which ensures syntactic consistency. The UNIX model is one where the pipeline is an undifferentiated bytestream and commands in the pipeline consume individually determine when and how to consume that data.  PowerShell rejected that model and replaced it with a model much more in aligned with IBM’s traditional RECORD orientation (yup – think CARD DECKS!).  We say that PowerShell is “object based”.  That is more true than false and is about as accurate as you can get with 2 words but the reality is that the object in the pipeline and the arguments on the command line combine to create a RECORD.  The engine then determines how to bind that Record to the cmdlet parameters and then we call ProcessRecord() method.

The bottom line here is that this industry has a long line of superstar engineers and we all benefit from their excellent work.  Hats off the UNIX engineers!  Hats off the the VMS engineers!  Hats off the IBM engineers!

Very well said sir. Anyway, here is a script for restarting IBM’s DB2 database from PowerShell. Dale Lane also wrote something on the subject of DB2 and Powershell, but his blog appears to be down at the moment.

The point I am making is that improvement doesn’t come from thinking everyone else sucks, it often comes from realising that others knew what they were doing. Standing on the shoulders of giants and all that. True innovators of course acknowledge their sources. I have had my share of fights over the years with Microsoft on the the subject of interoperability, but its important to acknowledge the massive progress they have made in enterprise capabilities.

disclosure: Microsoft Servers and Tools Business is a client.

The picture above was just too good not to use. It originally came from Tom’s Hardware. Sorry guys please let me know if you’d prefer me not to use it.