News

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

IBM Adds PowerShell Support for WebSphere MQ

Posted by Jonathan Allen on Dec 17, 2007

Sections: Development
Topics: Websphere ,; IBM ,; Application Servers ,; Companies ,; Artifacts & Tools ,; Java ,; Languages ,; .NET ,; Tools ,; Programming ,; Agile ,; PowerShell

PowerShell is starting to gain acceptance with major players. IBM has announced that WebSphere MQ can now be managed using PowerShell. WebSphere objects such as Channels, Listeners, Queues, and Services can be created, examined, and modified from the command line. IBM's WMQ blog has posted a series on how to perform these actions.

In talking about IBM's announcement, Jeffrey Snover also revealed some more of PowerShell's origins and inspiration.

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.