Automate the provisioning of IBM MQ objects

Samples are supplied to automate the provisioning of queue managers and local queues.

Automate the provisioning or de-provisioning of IBM MQ queue managers and perform actions against the provisioned queue managers

Each workflow performs one or more steps. Comments in the workflows explain the function performed by each step. Some of the steps just request data input, while some steps submit JCL, invoke REXX execs, Shell scripts, or issue REST API calls to accomplish the stated function.

Refer to each step for the exact name of the JCL or REXX exec files. The workflows and associated JCL or REXX exec files reference variables that are declared in one or more variable XML files. For more details, see Workflow variable declaration files.

deprovision, startQMgr, and stopQMgr can be performed as actions against a provisioned IBM MQ for z/OS queue manager.

Automate the provisioning or de-provisioning of IBM MQ local queues and perform actions against the provisioned queues

1. The Put Queue action allows you to enter some message data and put one or more messages onto a queue. If more than one message is to be placed onto a queue during a given request, the same message data is used.
2. The loadQueue.xml and offloadQueue.xml workflows invoke the executable module, CSQUDMSG in the SCSQLOAD library, with an alias of QLOAD. This is equivalent to the dmpmqmsg utility available with IBM MQ for Multiplatforms. Therefore messages loaded from a data set onto a queue, or from a queue onto a data set, are expected to be in the dmpmqmsg format.

   Sample JCL is also provided as member CSQ4QLOD in SCSQPROC.

   The easiest way to try out the loadQueue and offloadQueue actions is to do the following:
   1. Issue putQueue a few times to put some messages on to a queue.
   2. Use offloadQueue to offload the messages from the queue on to a data set.
   3. If required, issue clearQueue to remove all messages from the queue.
   4. Use loadQueue to load the messages from a data set onto the same or a different queue.

   If we are interested in the dmpmqmsg format, we can browse the contents of the data set, once you have issued an Offload request.

3. We can perform displayQueue, deleteQueue, putQueue, getQueue, loadQueue, offloadQueue, and clearQueue as actions against a provisioned IBM MQ for z/OS local queue. For further details about actions and action files, refer to the z/OSMF Programming Guide.
4. All action related workflows are deleted by default. The reason for this is to minimize the need for users to cleanup workflows.

   The problem with this however is that where an action results in some output. For example, the displayQueue and getQueue actions both produce output.

   The output cannot be seen since the related workflow is deleted as soon as the action has been performed. So, if you drive the workflow actions from the z/OS WUI, set the cleanAfterComplete flag to false on the <workflow> tag for each action whose output we want to see.

   For example, to see the output of displayQueue, set the flag as follows:

   <action name="displayQueue">
     <workflow cleanAfterComplete="false">
     ...
   
     ...
     </workflow>
   </action>
   

   However, this means that you then have to manually clean up action related workflows.

Each sample z/OSMF workflow performs one or more steps. Comments in the workflows explain the function performed by each step. Some of the steps just request data input while some steps submit JCL and others invoke REXX execs to accomplish the stated function.

Refer to each step for the exact name of the JCL or REXX exec files. The workflows and associated JCL or REXX exec files reference variables that are declared in one or more Workflow variable declaration files.

Related concepts

• Limitations