Running the basic installation verification program

After you have installed and customized IBM® MQ, you 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

CSQ4IVP1 is a batch application that connects to your 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:
  1. 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, you need to restart it so that these definitions can take effect.
  2. 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 you want to use, the four-character IBM MQ queue manager name, and the destination for the job output.

  3. Update RACF® to allow CSQ4IVP1 to access its resources if IBM MQ security is active.

    To run CSQ4IVP1 when IBM MQ security is enabled, you need a RACF user ID with authority to access the objects. For details of defining resources to RACF, see Setting 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.

    Figure 1. RACF commands for CSQ4IVP1
    
    RDEFINE MQCMDS CSQ1.DISPLAY.PROCESS
    PERMIT CSQ1.DISPLAY.PROCESS CLASS(MQCMDS) ID(TS101) ACCESS(READ)
    
    RDEFINE MQQUEUE CSQ1.SYSTEM.COMMAND.INPUT
    PERMIT CSQ1.SYSTEM.COMMAND.INPUT CLASS(MQQUEUE) ID(TS101) ACCESS(UPDATE)
    
    RDEFINE MQQUEUE CSQ1.SYSTEM.COMMAND.REPLY.MODEL
    PERMIT CSQ1.SYSTEM.COMMAND.REPLY.MODEL CLASS(MQQUEUE) ID(TS101) ACCESS(UPDATE)
    
    RDEFINE MQQUEUE CSQ1.CSQ4IVP1.**
    PERMIT CSQ1.CSQ4IVP1.** CLASS(MQQUEUE) ID(TS101) ACCESS(UPDATE)
    
    RDEFINE MQCONN CSQ1.BATCH
    PERMIT CSQ1.BATCH CLASS(MQCONN) ID(TS101) ACCESS(READ)
    

Running CSQ4IVP1

When you have completed these steps, start your queue manager. If the queue manager is already running and you have changed CSQINP2, you 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 your installation.

Checking 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 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:
  1. Issue an MQOPEN call, specifying the queue manager name, to open the queue manager object.
  2. Issue an MQINQ call to find out the name of the system-command input queue.
  3. Issue an MQINQ call to find out about various queue manager event switches.
  4. 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
  1. Open a dynamic queue.
  2. MQPUT a message with an expiry interval set.
  3. Wait for the message to expire.
  4. Attempt to MQGET the expired message.
  5. MQCLOSE the queue.
Stage 9
  1. Open a dynamic queue.
  2. MQPUT a message.
  3. Issue MQCMIT to commit the current unit of work.
  4. MQGET the message.
  5. Issue MQBACK to backout the message.
  6. MQGET the same message and ensure that the backout count is set to 1.
  7. Issue MQCLOSE to close the queue.
Stage 10
Disconnect from the queue manager using MQDISC .
After running the IVP, you 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.

Figure 2. Sample report from CSQ4IVP1

DATE : 2005.035                 IBM MQ for z/OS - V6            PAGE : 0001
INSTALLATION VERIFICATION PROGRAM
PARAMETERS ACCEPTED. PROGRAM WILL CONNECT TO : CSQ1
,OBJECT QUALIFER : CSQ4IVP1
INSTALLATION VERIFICATION BEGINS :
STAGE 01 COMPLETE. COMPCODE : 0000 REASON CODE : 0000
STAGE 02 INFO: QMGR EVENT SWITCH IS OFF FOR BRIDGE EVENTS
STAGE 02 INFO: QMGR EVENT SWITCH IS EXCP FOR CHANNEL EVENTS
STAGE 02 INFO: QMGR EVENT SWITCH IS OFF FOR SSL EVENTS
STAGE 02 INFO: QMGR EVENT SWITCH IS OFF FOR INHIBITED EVENTS
STAGE 02 INFO: QMGR EVENT SWITCH IS OFF FOR LOCAL EVENTS
STAGE 02 INFO: QMGR EVENT SWITCH IS OFF FOR PERFORMENCE EVENTS
STAGE 02 INFO: QMGR EVENT SWITCH IS OFF FOR REMOTE EVENTS
STAGE 02 INFO: QMGR EVENT SWITCH IS OFF FOR START/STOP EVENTS
STAGE 02 COMPLETE. COMPCODE : 0000 REASON CODE : 0000 SYSTEM.COMMAND.INPUT
STAGE 03 COMPLETE. COMPCODE : 0000 REASON CODE : 0000
STAGE 04 COMPLETE. COMPCODE : 0000 REASON CODE : 0000 CSQ4IVP1.BAB9810EFEAC8980
STAGE 05 COMPLETE. COMPCODE : 0000 REASON CODE : 0000
STAGE 06 COMPLETE. COMPCODE : 0000 REASON CODE : 0000
STAGE 07 COMPLETE. COMPCODE : 0000 REASON CODE : 0000
STAGE 08 COMPLETE. COMPCODE : 0000 REASON CODE : 0000 CSQ4IVP1.BAB9810F0070E645
STAGE 09 COMPLETE. COMPCODE : 0000 REASON CODE : 0000 CSQ4IVP1.BAB9812BA8706803
STAGE 10 COMPLETE. COMPCODE : 0000 REASON CODE : 0000
>>>>>>>>>>   END OF REPORT   <<<<<<<<<<