BIPDPLY is used to run mqsideploy, and on z/OS the command does this from JAVA bindings; see Usage note.
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 there is no possibility that 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 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 -i cm_name -p port -q cm_qm -l -mthe command attempts to run the mqsideploy command using WebSphere MQ Java client code, which is not allowed on z/OS. Connecting to the local Configuration Manager with the parameters -i and -p forces the command into a local mode, and the following error occurs:
BIP1046E: Unable to connect with the Configuration Manager's queue manager
2012 0x000007dc MQRC_ENVIRONMENT_ERROR
2298 0x000008fa MQRC_FUNCTION_NOT_SUPPORTED
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