MQSeries::Command - OO interface to the Programmable Commands
use MQSeries; use MQSeries::Command; # # Simplest usage # my $qmgr_obj = MQSeries::QueueManager-> new(QueueManager => 'some.queue.manager'); my $command = MQSeries::Command->new(QueueManager => $qmgr_obj); or die("Unable to instantiate command object\n"); # # To use MQ v6 features (PCF for z/OS, Filter commands, # InquireConnection) # my $command = MQSeries::Command->new(QueueManager => $qmgr_obj, CommandVersion => MQSeries::MQCFH_VERSION_3); or die("Unable to instantiate command object\n"); # # Inquire XXX Names returns object names, # all other Inquire XX commands return hash references # @qnames = $command->InquireQueueNames() or die "Unable to list queue names\n"; foreach my $qname ( @qnames ) { $attr = $command->InquireQueue ( QName => $qname, QAttrs => [qw( OpenInputCount OpenOutputCount CurrentQDepth )], ) or die "InquireQueue: " . MQReasonToText($command->Reason()) . "\n"; print "QName = $qname\n"; foreach my $key ( sort keys %$attr ) { print "\t$key => $attr->{$key}\n"; } } # # Filter commands (requires MQ v6 and CommandVersion 3) # Like other Inquire XXX commands (excpet Inquire XXX Names), # this returns a list of hash references, not obejct names. # my @full_queues = $command-> InquireQueueStatus('FilterCommand' => "CurrentQDepth > 10000"); my @ip_conns = $command-> InquireConnection('FilterCommand' => "ConnectionName like '144.44.*'"); # # High-level wrapper method: CreateObject # $command->CreateObject ( Attrs => { QName => 'FOO.BAR.REQUEST', QType => 'Local', MaxQDepth => '50000', MaxMsgLength => '20000', } ) || die "CreateObject: " . MQReasonToText($command->Reason()) . "\n"; $command->CreateObject ( Clear => 1, Attrs => { QName => 'FOO.BAR.REPLY', QType => 'Remote', RemoteQName => 'FOO.BAR.REPLY', RemoteQMgrName => 'SAT1', } ) || die "CreateObject: " . MQReasonToText($command->Reason()) . "\n";
The MQSeries::Command class implements an interface to the Programmable Command Format messages documented in the:
"WebSphere MQ Programmable Command Formats and Administration Interface"
section of the MQSeries documentation. In particular, this document will primarily explain how to interpret the above documentation, and thus use this particular implementation in perl. Please read and understand the following sections of the above document:
Programmable Command Formats Chapter . Definitions of the Programmable Command Formats Chapter . Structures used for commands and responses
This interface also supports the text-based MQSC format messages used by the queue manager of some platforms, particularly MVS. Using the same interface, either PCF or MQSC command server can be queried, with the results translated into the same format for responses as well. Note that there are limits to how transparent this is (see MQSC NOTES), but the code tries quite hard to hide as many of the differences as possible.
Before we discuss the specific arguments and return values of each of the methods supported by the MQSeries::Command module, we must explain how the keys and values used by the interface were chosen, as this will allow the developer to understand how to take advantage of the very complete documentation provided by IBM (which will not be reproduced here).
For each command documented in 'Definitions of the Programmable Command Formats' (there is a specific page listing all of the commands, grouped by type), there is a corresponding method in this class. For example, there is a method named 'InquireQueueManager', for the obvious (I hope) PCF command.
All of these methods take a hash of key/value pairs as an argument, with the keys being those defined in the documentation for each command. When writing C code to produce PCF messages, the parameter names are macros, such as:
MQIACF_Q_MGR_ATTRS
to specify a list of queue manager attributes. Rather than use these names directly, the key strings are taken from the IBM documentation. In this example, the string used for this key is:
QMgrAttrs
The values depend on the structure type of the parameter. If the structure is a string (MQCFST), byte string (MQBACF) or an integer (MQCFIN) then the value of the key is simply a scalar string or integer in perl. If it either a string list (MQCFSL) or an integer list (MQCFIL), then the value of the key is an array reference (see the InquireQueueManager example in the SYNOPSIS) of scalar strings or integers.
Most of the individual methods map to underlying commands which do not return any data. For all of these, the return value is simply Boolean; true or false. That is, the command either worked or failed.
Only the methods associated with those commands documented as producing data responses:
Escape Inquire AuthInfo Inquire AuthInfo Names Inquire Authority Records Inquire Authority Service Inquire Channel Inquire Channel Initiator Inquire Channel Listener Inquire Channel Listener Status Inquire Channel Names Inquire Channel Status Inquire Cluster Queue Manager Inquire Connection Inquire Entiry Authority Inquire Group Inquire Log Inquire Namelist Inquire Namelist Names Inquire Process Inquire Process Names Inquire Queue Inquire Queue Manager Inquire Queue Manager Status Inquire Queue Names Inquire Queue Status Inquire Service Inquire Service Status Inquire Subscription Inquire Subscription Status Inquire System Inquire Topic Inquire Topic Status Reset Queue Statistics
plus the following equivalents for MQSC
Inquire CFStruc Inquire CFStruc Status Inquire Usage Inquire Security Inquire StorageClass
return interesting information. Most of these will return an array of hash references, one for each object matching the query criteria. For example. The specific keys are documented in the section of the IBM documentation which discusses the "Data responses to commands", on the summary page "PCF commands and responses in groups". If you have read the IBM documentation as requested above, you should have found this page.
Note that in an array context, the entire list is returned, but in a scalar context, only the first item in the list is returned.
Some of these commands, however, have a simplified return value. All of the below:
Inquire AuthInfo Names Inquire CFStruct Names Inquire Channel Names Inquire Namelist Names Inquire Process Names Inquire Queue Names Inquire StorageClass Names Inquire Topic Names
simply return an array of strings, containing the names which matched the query criteria.
The arguments to the constructor are a hash, with the following key/value pairs:
Key Value === ===== QueueManager String or MQSeries::QueueManager object ProxyQueueManager String or MQSeries::QueueManager object RealQueueManager String ReplyToQ String or MQSeries::Queue object CommandQueueName String CommandQueue MQSeries::Queue object CommandVersion Numeric (1 or 3) DynamicQName String ModelQName String Type String ("PCF" or "MQSC") Expiry Numeric Wait Numeric ReplyToQMgr String Carp CODE Reference StrictMapping Boolean
This argument specifies the queue manager to which commands are to be sent.
If the 'ProxyQueueManager' argument is specified, this should be the name of the target queue manager.
If the 'ProxyQueueManager' argument is not specified, this can either be an MQSeries::QueueManager object, or the name of the Queue Manager. Specifying the queue manager name is deprecated and may stop working in a future release.
MQSeries::QueueManager
The 'QueueManager' argument can be omitted, in which case the "default queue manager" is assumed.
The name of the queue manager to which to MQCONN(), and submit messages on the QueueManagers behalf. This is to be used if a direct connection to the QueueManager is not possible, for example MVS queue managers with support for direct client access.
The messages will be put to what is assumed to be a remote queue definition which routes to the command queue on the desired QueueManager.
In order to specify the "default" queue manager as the ProxyQueueManager, an empty string must be explicitly given.
If a remote queue manager is controlled through a proxy, by having the QueueManager parameter specify the proxy and the CommandQueueName an object descriptor, then by default any output will print the queue manager name incorrectly. The RealQueueManager parameter specifies the name used for display purposes.
QueueManager
CommandQueueName
RealQueueManager
The ReplyToQ can be opened by the application, and the MQSeries::Queue object passed in to the MQSeries::Command constructor, if so desired, os, a fixed queue name can be given. This is a somewhat advanced usage of the API, since the default behavior of opening a temporary dynamic queue under the covers is usually prefered, and much simpler.
The responses are retrieved from the reply queue using gets by CorrelId, so there should be no issue with using a pre-defined, shared queue for this, if so desired.
This specifies the queue to which the command messages will be put. The defaults are usually reasonable, and depend on the command message Type (PCF or MQSC).
PCF => SYSTEM.ADMIN.COMMAND.QUEUE MQSC => SYSTEM.COMMAND.INPUT
If the ProxyQueueManager has been specified, then we assume the messages are being written to a remote queue definition, and the defaults are then:
PCF => SYSTEM.ADMIN.COMMAND.QUEUE."QueueManager" MQSC => SYSTEM.COMMAND.INPUT."QueueManager"
See "MQSC NOTES" for some examples of how to use this in practice.
Alternatively, the CommandQueue parameter can be used.
CommandQueue
For complex set-ups, where a remote queue manager is managed by the name of the command queue does not fit the standard scheme, the command queue can be opened manually and specified in the MQSeries::Command constructor as the CommandQueue parameter.
The CommandQueue parameter must be combined with the RealQueueManager parameter. In the example below, a mainframe queue manager CSQ1 is managed from the queue manager UNIXQM with a non-standard queue name:
CSQ1
UNIXQM
$queue = MQSeries::Queue::-> new('QueueManager' => 'UNIXQM', 'Queue' => 'REMOTE.FOR.COMMANDQ.ON.CSQ1', 'Mode' => 'output', ) || die "Cannot open queue"; $cmd = MQSeries::Command::-> new('ProxyQueueManager' => 'UNIXQM', # Also ReplyToQMgr 'RealQueueManager' => 'CSQ1', # Displayed in messages 'Type' => "MQSC", 'CommandQueue' => $queue, ) || die "Cannot create command";
If both queue managers run MQ v6, then PCF commands can be used to communicate with MQ on z/OS. The above example would be changed as follows to use PCF commands:
$cmd = MQSeries::Command::-> new('ProxyQueueManager' => 'UNIXQM', # Also ReplyToQMgr 'RealQueueManager' => 'CSQ1', # Displayed in messages 'Type' => 'PCF', 'CommandVersion' => MQSeries::MQCFH_VERSION_3, 'CommandQueue' => $queue, ) || die "Cannot create command";
This mechanism can also be used when the command queue needs to be opened with special options. This is typically combined with a call to the MsgDesc method:
MsgDesc
my $queue = MQSeries::Queue::-> new('QueueManager' => 'UNIXQM', 'Queue' => 'SYSTEM.ADMIN.COMMAND.QUEUE', 'Options' => (MQSeries::MQOO_FAIL_IF_QUIESCING | MQSeries::MQOO_OUTPUT | MQSeries::MQOO_SET_IDENTITY_CONTEXT, ), ) || die "Cannot open queue"; $cmd = MQSeries::Command::-> new('RealQueueManager' => 'UNIXQM', 'Type' => 'PCF', 'CommandQueue' => $queue, ) || die "Cannot create command"; $cmd->MsgDesc('ApplIdentityData' => "MyData", 'UserIdentifier' => "mqm", );
This argument is introduced mainly to support the new PCF commands in MQ v6 (such as FilterCommand filter options) and to use PCF with QueueManagers on OS/390. It indicates the required PCF Command Version (MQCFH_CURRENT_VERSION) and Type. This is an optional argument and Version "1" is used as default. If a value '3' or higher is specified, then the Command Type "MQCFT_COMMAND_XR" will be used and also the version is set to "MQCFH_CURRENT_VERSION". Any value less then 3 will be ignored and the defaults are used (MQCFT_COMMAND and default version).
This argument indicates whether the command server on the QueueManager supports either PCF or MQSC messages. The default is PCF. See the section "MQSC NOTES" for the Ugly Truth about the MQSC support.
This value is used as the MQMD.Expiry field on all requests sent to the command server. The value is passed to the MQSeries::Message constructor, and should specify the time in tenths of a second. The default is 600, or 60 seconds.
A symbolic value ending on 's' for seconds or 'm' for minutes may also be specified, e.g. the symbolic value '45s' will have the same meaning as the number 450.
This value is used as the Wait argument to the MQSeries::Queue->Get() method call made against the ReplyToQ (a dynamic reply queue). and should be a time specified in milliseconds. The default is 60000, or 60 seconds.
A symbolic value ending on 's' for seconds or 'm' for minutes may also be specified, e.g. the symbolic value '45s' will have the same meaning as the number 45000.
NOTE: Both the Expiry and Wait defaults may be too slow for heavily loaded queue managers. Tune them appropriately.
The ReplyToQMgr normally defaults to the QueueManager, but it can be overridden, perhaps as a means of specifying an alternate return path over a specific channel. For example, the author uses special channels for SYSTEM related traffic, over which we forward MQSeries events from one queue manager to another, and also over which we wish the command server queries to flow.
The "default" path between QMA and QMB flows over a channel called QMA.QMB, but this traffic is application data, not administrative system data. The system queries flow over QMA.QMB.SYSTEM, and we need to ensure that replies to queries follow a similar reverse path. Specifying the ReplyToQMgr as "QMB.SYSTEM" accomplishes this.
This key specifies a code reference to a routine to replace all of the carp() calls in the API, allowing the user of the API to trap and handle all of the error message generated internally, or simply redirect how they get logged.
For example, one might want everything to be logged via syslog:
sub MyLogger { my ($message) = @_; foreach my $line (split(/\n+/, $message)) { syslog("err", $line); } }
Then, one tells the object to use this routine:
my $command = MQSeries::Command->new( QueueManager => 'some.queue.manager', Carp => \&MyLogger, ) or die("Unable to connect to queue manager.\n");
The default, as one might guess, is Carp::carp();
If this argument has a true value, then strict mapping of PCF parameters and values will be enforced. Normally, if you feed a bogus string into the API, it will attempt to map it to the underlying PCF macro value, and if the mapping fails, it will quietly forgive you, and ignore the parameter. Enabling this feature will cause the translation of an encoded PCF message into the data structure for a Response, or the translation of a Request into an encoded PCF message, to fail if any of the mappings fail.
Usually, the command server will generate errors if you feed bogus data into the API. but that will only occur after the data has been encoded and sent to the command server. This feature will allow you to detect this error before the data is ever sent.
This method will return the MQI CompCode for the most recent MQI call made by the API.
This method will return the MQI Reason for the most recent MQI call made by the API.
This method will return different strings depending on whether the command is MQSC or PCF. For MQSC, the command server sends back some text explaining the reason code, and for PCF, we simply call MQReasonToText on the reason code and return that instead.
MQSC sends back far less information encoded into the reason than PCF does, and the interesting information is usually found in the ReasonText. Therefore, this method should be used when raising exceptions, in order to get the most descriptive explanation for any given error.
Normally, the data of interest is returned from the method in question, but the individual responses are available via this method. This returns a list of MQSeries::Command::Response objects, one for each individual message recieved.
This method will return a list of parameters structures from all of the responses messages sent back which were not error responses. Some errors will send back responses with parameters, and these could easily be confused with real data (until you start looking at the actual data, of course).
This method will return a list of parameters structures from all of the responses messages sent back which were error responses. If a command fails, the Reason() will usually tell you enough about the cause of the failure, but if the reason is MQRCCF_CFIN_PARM_ID_ERROR, then the parameters in the error message will indicate which Parameter key was invalid.
In some cases, it is useful or necessary to override specific MQMD fields in outgoing request messages. Examples include manually changeing the Persistence field, or changing the message identity or origin context. The MsgDesc method allows you to do so:
$cmd->MsgDesc('Persistence' => 0);
or
$cmd->MsgDesc('ApplIdentityData' => "MyData", 'UserIdentifier' => "mqm", );
Note that setting the message identity or origin context requires you to open the command queue with the relevant open options; see the description of the CommandQueue parameter to new.
new
Note that the ReplyToQ, ReplyToQMgr and Expiry fields for the request message descriptor can be specified in the constructor new. The MsgDesc method is intended for the more obscure options.
ReplyToQ
ReplyToQMgr
Expiry
This is a generic "wrapper" method for creating any generic MQSeries object. The arguments to this method are a hash, with the following key/value pairs:
Key Value === ===== Attrs HASH reference Verify Boolean Clear Boolean Quiet Boolean Force Boolean Callback CODE reference
The key/value pairs in the Attrs argument are passed directly to the corresponding CreateQueue(), CreateChannel(), or CreateProcess() method. However, there is more to this than just creating the object. For clarity, this discussion will use creation of a queue as an example.
First, InquireQueue is called to see if the object already exists. If it does not exist, then the object is simply created, with the specified attributes.
If it does exist, and the QType matches, then the actual object attributes are compared against those passed to the CreateObject method, and if they match, then no action is taken, and the object is not modified.
If it does exist, but of a different QType, then the existing object is deleted, and the new object created as requested.
The idea here is to match the modification of the object conditional on the need for modifying the object. If the same CreateObject method call, with the same arguments, is called twice, then the second method invocation should be a noop, as far as the actual MQSeries object is concerned.
As discussed above, this is a HASH reference, whose key/value pairs are used to determine what type of object is being created or updated, and those key/value pairs are passed as-is to the appropriate Create* method call for the specified MQSeries object type.
If this key has a true value, then no changes will actually be implemented. They will merely be reported via test messages on stdout.
CreateObject is by default rather chatty about what it is doing, but all of the messages, other than errors, can be suppressed if this key has a true value.
Normally, when a Local queue is being replaced with another QType (eg. Remote or Alias), then the Local queue is not cleared before being deleted. If there are messages on the queue, this will cause an error. If the queue needs to be cleared, then this key must be passed with a true value.
This is a seperate option due to the inherit danger of destroying data accidentally. If you really want to clear the queues before recreating them as another QType, you will have to be explicitl about it.
This option will be passed to the Change* method, if the object already exists and is of type Queue, forcing changes to be applied to objects which are currently in use. It is ignored for the other object types. Note that this should not be passed as a key to the Attrs hash, since this is not really an object attribute.
If Force is given as an Attrs key, and the underlying Create* method is called, since the object does not already exist, then the command server will return an error.
This optional argument allows you to provide an object comparison subroutine, instead of relying on the built-in function. This is virtually never required, unless your request contains some 'meta' attributes that translate to multiple or different MQSeries attributes.
The Callback parameter must be a reference to a subroutine that receives three parameters: a reference to the requested attributes, a reference to the attributes found in the object, and a reference to a subroutine that compares two single attribute values. The return value from the subroutine must be a reference to a hash with those attribute names and values that actually should be changed.
Callback
Please see the source code of MQSeries::Command, specifically the _CompareAttributes method, for the default callback. Any callback you provide must behave in a similar way.
MQSeries::Command
_CompareAttributes
This section is NOT intended to replace the IBM "MQSeries Programmable System Management" documentation, and it merely serves to document the specific keys and values used by the perl implementation of the API.
In all cases, the keys which can be passed to the command are identical to the strings found in the documentation. However, some of the values also have more convenient string mapping as well, as these are not easily intuited by reading IBMs docs, thus these are clarified here.
The IBM docs list the possible values for each key as a list of MQSeries C macros (eg. MQCHT_SENDER), and if given, these will be respected. It will be faster to use the strings given, since these map directly to the actual macro values via a hash lookup, rather than a function call (all of the various C macros are implemented as function calls via an AUTOLOAD). Also, the author finds the replacement strings far more readable. YMMV.
For each key shown, the format of value is one of the following:
The value given must be a scalar value, interpretable as a text string.
The value must be an ARRAY reference of scalar values, all of which must be interpretable as strings.
NOTE: Some of the parameters (for example, the MsgExit parameter for the various Channel commands) can take either a string or string list. In this case, the API will be forgiving, and try to determine what you meant automatically. If you pass a reference, it will create a string list parameter, and if you pass a plain scalar, it will create a string.
ANOTHER NOTE: if you pass a simple scalar string where a string list is explicitly required (as opposed to optional), then the API will create a list of one string for you.
The value given must be a scalar value, interpretable as an integer. In some cases, a table will show a mapping from more readable text strings to the macros documented in the IBM manuals.
The value must be an ARRAY reference of scalar values, all of which must be interpretable as integers. As with the integer format, in some cases, a table will show a mapping from more readable text strings to the macros documented in the IBM manuals.
The value given need only be 0 or 1. This was done for some of the integer types which are documented to take a pair of macros, whose values were simply zero or one, and when the true/false nature of the key was considered to be intiuitive. For example, "DataConversion" is either on (true) or off (false).
Note: List of keys are not documented anymore to avoid needless redundancy. Please refer to the IBM documentation for the names and values of keys.
Change AuthInfo Copy AuthInfo Create AuthInfo Delete AuthInfo Inquire AuthInfo Inquire AuthInfo Names
Delete Authority Records Inquire Authority Records Set Authority Record
Change Channel Change Channel Listener Copy Channel Copy Channel Listener Create Channel Create Channel Listener Delete Channel Delete Channel Listener Inquire Channel Inquire Channel Initiator Inquire Channel Listener Inquire Channel Listener Status Inquire Channel Names Inquire Channel Status Ping Channel Reset Channel Resolve Channel Start Channel Start Channel Initiator Start Channel Listener Stop Channel Stop Channel Initiator Stop Channel Listener
Change CFStruc Create CFStruc Delete CFStruc Inquire CFStruc Inquire CFStruc Names
Inquire Cluster Queue Manager Refresh Cluster Reset Cluster Resume Queue Manager Cluster Suspend Queue Manager Cluster
Inquire Connection Stop Connection
Change Namelist Copy Namelist Create Namelist Delete Namelist Inquire Namelist Inquire Namelist Names
Change Process Copy Process Create Process Delete Process Inquire Process Inquire ProcessNames
Change Queue Clear Queue Copy Queue Create Queue Delete Queue Inquire Queue Inquire Queue Names Move Queue Reset Queue Statistics
The InquireQueueStatus command does not behave like the other queue commands. Please refer to IBM documentation for complete details.
InquireQueueStatus
For a request, the following keys are supported:
QName StatusType OpenType QStatusAttrs
The output of the InquireQueueStatus is dependent on the StatusType specified.
StatusType
Change Queue Manager Inquire Queue Manager Inquire Queue Manager Status Ping Queue Manager RefreshQueueManager ResetQueueManager ResumeQueueManager SuspendQueueManager
ChangeSecurity InquireSecurity RefreshSecurity ReverifySecurity
Change Service Copy Service Create Service Delete Service Inquire Service Inquire Service Status Start Service Stop Service
Change StorageClass Create StorageClass Delete StorageClass Inquire StorageClass Inquire StorageClass Names
Change Subscription Copy Subscription Create Subscription Delete Subscription Inquire Subscription Inquire Subscription Status
Inquire Group Inquire Log Inquire System Inquire Usage Set Log Set System
Change Topic Clear Topic String Copy Topic Create Topic Delete Topic Inquire Topic Inquire Topic Names Inquire Topic Status
This command is not really part of a grouping, so its all by itself here.
The following keys have special value mappings:
Key Macro === ===== MQSC MQET_MQSC
There are several commands which return data. The return value of the actual command methods depends on the specific command. All of the "Inquire*Names" commands return a list of the actual names returned, which greatly simplifies the parsing of the return value.
For example:
@qnames = $command->InquireQueueNames( QName => 'FOO.*' );
will result in @qnames containing a list of strings of all of the queue names starting with FOO.
The rest of the commands return a list of Parameters HASH references, extracted from each of the messages sent back from the command server. In a scalar context, only the first Parameters HASH reference is returned. Refer to the "RETURN VALUES" section for the list of commands.
@queues = $command->InquireQueue( QName => 'FOO.*', QAttrs => 'All' );
will result in @queues containing a list of HASH references, each of which has key/value pairs for the attributes of one of the queues starting with FOO.
The keys in the Parameters HASH references are mapped from the numeric macro values back into the same strings described above for simplifying the input Parameters.
However, there are a few keys in the responses which are not supported as keys in the inquiry. In general, the return values are left unmolested.
For PCF requests to MQ v6 and above, filter commands can be used to have the queue manager filter out only objects of interest. For example, you can inquire for queues with a certain maximum message length, for connections from specific IP addresses, or for queue status with a minimum queue depth.
Filters require that the command object is created with CommandVersion 3, i.e.
$command = MQSeries::Command::-> new('QueueManager' => 'SOME.QUEUE.MANAGER', 'Type' => 'PCF', 'CommandVersion' => MQSeries::MQCFH_VERSION_3);
Following that, most Inquire commands accept an optional FilterCommand parameter that specifies an attribute to filter on, a comparison operator, and a value. (See the IBM documentation for which Inquire commands support filters.)
The filter can be specified in pseudo-SQL syntax, e.g. :
@queues = $command-> InquireQueue('FilterCommand' => "QName like 'SYSTEM.PE*'"); @queues = $command-> InquireQueue('FilterCommand' => "MaxQDepth > 10000");
Alternatively, if the value used contains quotes, or if the filter is constructed dynamically, the filter can be specified as a hash reference:
@queues = $command-> InquireQueue('FilterCommand' => { Parameter => 'MaxQDepth', Operator => '>', Value => 100_000, });
The supported filter parameters (field names) are almost any field returned by the Inquire command (see the IBM documentation for details). The supported value can be an integer, string, string wildcard (a value ending on a '*'), or (for enumerated types) the constant name as returned by the Inquire command. For example, for an enumerated type, to query for alias queues that have a rmote queue as their base type:
@queues = $command-> InquireQueue('FilterCommand' => "BaseType == Remote");
The operators supported depend on the parameter type. All types support equal (==) and unequal (<>, !=); numeric types also support the numeric comparators (<, >, <=, >=); string types support 'like' and 'not like' with a wildcard value ending on '*'; integer list types support 'contains' and 'excludes'; and string list types support 'contains', 'excludes', 'contains_gen' and 'excludes_gen', where the latter to values perform a wildcard comparison. The examples below illustrate supported usage.
BaseType == Local BaseType <> Local BytesSent > 10000 CurrentQDepth > 10000 Msgs <= 100 ConnectionName like '144.14.*' BaseQName not like 'SYSTEM.*' HeaderCompression contains 'gzip' HeaderCompression excludes 'gzip'
Note that the filter is not evaluated as a perl expression. The MQSeries::Command class parses the expression into a parameter, operator and value; then converts the value to the appropriate type (a value lookup for enumerated types, a conversion to integer for numbers, and conversion to string for strings). In other words, the expected amount of DWIM is in place.
MQSeries(3), MQSeries::Queue(3), MQSeries::Message(3), MQSeries::Command::Request(3), MQSeries::Command::Response(3)
In addition, the MQSeries documentation is the primary source of documentation for the commands and their arguments, especially the following sections.
For MQSeries 5.2 and before, this is:
"MQSeries Programmable System Management" Part 2. Programmable Command Formats Chapter 8. Definitions of the Programmable Command Formats Chapter 9. Structures used for commands and responses
For WebSphere MQ 5.3, this is:
"WebSphere MQ Programmable Command Formats and Administration Interface" Part 1. Programmable Command Formats Chapter 4. Definitions of the Programmable Command Formats Chapter 5. Structures used for commands and responses
For WebSphere MQ 6.0 and 7.0, this is:
Same as 5.3 except the Chapter numbers. In 6.0 doc they are Chapter 3 and 4.
To install MQSeries, copy and paste the appropriate command in to your terminal.
cpanm
cpanm MQSeries
CPAN shell
perl -MCPAN -e shell install MQSeries
For more information on module installation, please visit the detailed CPAN module installation guide.