If you do not supply the -i, -p, and -q parameters, you must specify the -n parameter.
Specify the -c parameter with caution; it has the effect of canceling deployment requests. Use this option only if the affected brokers will respond to the outstanding requests. If a broker subsequently processes a deployment request that has been cancelled, the Configuration Manager ignores the response, and is therefore no longer synchronized with the broker.
You can set this parameter to a value in the range 1 - 2 145 336 164. If you do not provide a timeoutValue value, or you set a value less than 1 or greater than 2 145 336 164 is specified, an error is returned.
Set this parameter to a value greater
than the sum of the configuration timeouts that you specified for the broker,
the ConfigurationChangeTimeout and the InternalConfigurationTimeout parameters,
if you want to ensure that a response is received within the timeoutValue period.
If you set a smaller value, the response returned might indicate that the
state of the deploy request is unknown.
You can specify objects of all types, but if you specify an ambiguous object name (for example, "top", when both "top.dictionary" and "top.cmf" are deployed to the same execution group), the entire command fails with the message BIP1089. In these circumstances, you must specify the fully qualified name of the objects to remove; for example, "top.dictionary:top.cmf".
mqsideploy -n cm1.configmgr -m -w 600
mqsideploy -i localhost -p 1414 -q QMNAME -m -w 600
Note that you can use the i, p, and q parameters in the following examples instead of the -n parameter.
mqsideploy -n cm1.configmgr -t -m -w 600
mqsideploy -n cm1.configmgr -b broker1 -e default -a mybar.bar -m -w 600
mqsideploy -n cm1.configmgr -b broker1 -w 900
mqsideploy –n cm1.configmgr –b B1 –e default –d top.cmf:bar.dictionary
mqsideploy -n cm1.configmgr -c -w 900