Running the basic installation verification program
After you have installed and customized IBM MQ, we can use the supplied installation verification program, CSQ4IVP1, to confirm that IBM MQ is operational.
The basic installation verification program is a batch assembler IVP that verifies the base IBM MQ without using the C, COBOL, or CICS samples.
The Batch Assembler IVP is link-edited by SMP/E and the load modules are shipped in library thlqual.SCSQLOAD.
After you have completed both the SMP/E APPLY step and the customization steps, run the Batch Assembler IVP.
See these sections for further details:- Overview of the CSQ4IVP1 application
- Preparing to run CSQ4IVP1
- Running CSQ4IVP1
- Check the results of CSQ4IVP1
Overview of the CSQ4IVP1 application
CSQ4IVP1 is a batch application that connects to the IBM MQ subsystem and performs these basic functions:- Issues IBM MQ calls
- Communicates with the command server
- Verifies that triggering is active
- Generates and deletes a dynamic queue
- Verifies message expiry processing
- Verifies message commit processing
Preparing to run CSQ4IVP1
Before you run CSQ4IVP1:- Check that the IVP entries are in the CSQINP2 data set concatenation in the queue manager startup program. The IVP entries are supplied in member thlqual.SCSQPROC(CSQ4IVPQ). If not, add the definitions supplied in thlqual.SCSQPROC(CSQ4IVPQ) to your CSQINP2 concatenation. If the queue manager is currently running, we need to restart it so that these definitions can take effect.
- The sample JCL, CSQ4IVPR, required to run the installation verification program is in library
thlqual.SCSQPROC.
Customize the CSQ4IVPR JCL with the high-level qualifier for the IBM MQ libraries, the national language we want to use, the four-character IBM MQ queue manager name, and the destination for the job output.
-
Update RACF to allow CSQ4IVP1 to access its resources if IBM MQ security is active.
To run CSQ4IVP1 when IBM MQ security is enabled, we need a RACF user ID with authority to access the objects. For details of defining resources to RACF, see Set up security on z/OS . The user ID that runs the IVP must have the following access authority:
Authority Profile Class READ ssid.DISPLAY.PROCESS MQCMDS UPDATE ssid.SYSTEM.COMMAND.INPUT MQQUEUE UPDATE ssid.SYSTEM.COMMAND.REPLY.MODEL MQQUEUE UPDATE ssid.CSQ4IVP1.** MQQUEUE READ ssid.BATCH MQCONN These requirements assume that all IBM MQ security is active. The RACF commands to activate IBM MQ security are shown in Figure 1. This example assumes that the queue manager name is CSQ1 and that the user ID of the person running sample CSQ4IVP1 is TS101.
Running CSQ4IVP1
When you have completed these steps, start your queue manager. If the queue manager is already running and you have changed CSQINP2, we must stop the queue manager and restart it.
The IVP runs as a batch job. Customize the job card to meet the submission requirements of our installation.
Check the results of CSQ4IVP1
The IVP is split into 10 stages; each stage must complete with a zero completion code before the next stage is run. The IVP generates a report, listing:- The name of queue manager that is being connected to.
- A one-line message showing the completion code and the reason code returned from each stage.
- A one-line informational message where appropriate.
A sample report is provided in Figure 2
For an explanation of the completion and reason codes, see the IBM MQ for z/OS messages, completion, and reason codes.
Some stages have more than one IBM MQ call and, in the event of failure, a message is issued indicating the specific IBM MQ call that returned the failure. Also, for some stages the IVP puts explanatory and diagnostic information into a comment field.
The IVP job requests exclusive control of certain queue manager objects and therefore should be single threaded through the system. However, there is no limit to the number of times the IVP can be run against your queue manager.
The functions performed by each stage are:
- Stage 1
- Connect to the queue manager by issuing the MQCONN API call.
- Stage 2
- Determine the name of the system-command input queue used by the command server to retrieve
request messages. This queue receives display requests from Stage 5. To do this, the sequence of
calls is:
- Issue an MQOPEN call, specifying the queue manager name, to open the queue manager object.
- Issue an MQINQ call to find out the name of the system-command input queue.
- Issue an MQINQ call to find out about various queue manager event switches.
- Issue an MQCLOSE call to close the queue manager object.
On successful completion of this stage, the name of the system-command input queue is displayed in the comment field.
- Stage 3
- Open an initiation queue using an MQOPEN call.
This queue is opened at this stage in anticipation of a trigger message, which arrives as a result of the command server replying to the request from Stage 5. The queue must be opened for input to meet the triggering criteria.
- Stage 4
- Create a permanent dynamic queue using the CSQ4IVP1.MODEL queue as a model. The dynamic queue
has the same attributes as the model from which it was created. This means that when the replies
from the command server request in Stage 5 are written to this queue, a trigger message is written
to the initiation queue opened in Stage 3.
Upon successful completion of this stage, the name of the permanent dynamic queue is indicated in the comment field.
- Stage 5
- Issue an MQPUT1 request to the command server command queue.
A message of type MQMT_REQUEST is written to the system-command input queue requesting a display of process CSQ4IVP1. The message descriptor for the message specifies the permanent dynamic queue created in Stage 4 as the reply-to queue for the command server's response.
- Stage 6
- Issue an MQGET request from the initiation queue. At this stage, a GET WAIT with an interval of 1 minute is issued against the initiation queue opened in Stage 3. The message returned is expected to be the trigger message generated by the command server's response messages being written to the reply-to queue.
- Stage 7
- Delete the permanent dynamic queue created in Stage 4. As the queue still has messages on it, the MQCO_PURGE_DELETE option is used.
- Stage 8
-
- Open a dynamic queue.
- MQPUT a message with an expiry interval set.
- Wait for the message to expire.
- Attempt to MQGET the expired message.
- MQCLOSE the queue.
- Stage 9
-
- Open a dynamic queue.
- MQPUT a message.
- Issue MQCMIT to commit the current unit of work.
- MQGET the message.
- Issue MQBACK to backout the message.
- MQGET the same message and ensure that the backout count is set to 1.
- Issue MQCLOSE to close the queue.
- Stage 10
- Disconnect from the queue manager using MQDISC.
After running the IVP, we can delete any objects that you no longer require.
If the IVP does not run successfully, try each step manually to find out which function is failing.
Parent topic: Testing a queue manager on z/OS