MQ

This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.

A z/OS Queue manager has a number of things which are configured in the started task JCL. This includes the location of the MQ code libraries, provided in the STEPLIB of the JCL, and where your page sets and bootstrap data sets live. You can also run commands at start-up of the queue manager by configuring those in the started task JCL.

To make it easier to clone a started task when a new queue manager is added, one trick is to use JCL substitutions. For example, all your BSDS and page set datasets are likely named with a high level qualifier that includes the queue manager name. For example, in my queue manager JCL, I have the following two sections:-

//******************************************************************
//* BOOTSTRAP DATA SETS                                            *
//******************************************************************
//BSDS1     DD DSN=MQDATA.&QMGR..BSDS01,DISP=SHR                    
//BSDS2     DD DSN=MQDATA.&QMGR..BSDS02,DISP=SHR                    
//*                                                                 

//******************************************************************
//* PAGE SET DATA SETS                                             *
//******************************************************************
//CSQP0000  DD DSN=MQDATA.&QMGR..PSID00,DISP=SHR                    
//CSQP0001  DD DSN=MQDATA.&QMGR..PSID01,DISP=SHR                    
//CSQP0002  DD DSN=MQDATA.&QMGR..PSID02,DISP=SHR                    
//CSQP0003  DD DSN=MQDATA.&QMGR..PSID03,DISP=SHR                    
//CSQP0004  DD DSN=MQDATA.&QMGR..PSID04,DISP=SHR                    
//*                                                                 

I also have a number of tailored CSQINP2 scripts that are specific to a queue manager, so they use the same high level qualifier with the &QMGR. substitution.

The value of &QMGR. is set in one place at the start of my JCL on the PROC statement.

 
//         PROC QMGR=MQG1                          
//PROCSTEP EXEC PGM=CSQYASCP,REGION=0M,MEMLIMIT=2G
 

JCL substitutions can be handy for other things too. In the past I've had to use the &SYSNAME. substitution to include a different member when certain libraries were in a different location depending which LPAR you ran the queue manager on. Then we sorted that out by adding them to LINKLST so we didn't need them anymore.
However, in this post I want to introduce you to something that can allow you to further tailor your queue manager started task JCL. The ENVPARM parameter on a START QMGR command.

 
.                                           .-PARM(CSQZPARM)----.   
>>-START QMGR-+---------------------------+-+-------------------+-><
.             '-ENVPARM(jcl-substitution)-' '-PARM(member-name)-'   
 

START QMGR command syntax

This ENVPARM parameter allows you to pass in more values for substitution in your started task JCL. The possibilities are endless with what you can do with this. I'm going to illustrate it with an example that allows you to choose whether to start the CHINIT at queue manager start up or not.

To begin with you need to create two small script files suitable to be in your queue manager's CSQINP2 concatenation. The two files will have similar names, in my example they are called STACHINY and STACHINN (short for "Start CHINIT Yes" and "Start CHINIT No"). One script file will contain the START CHINIT command and the other will not contain anything of consequence. In this second file I always put some comments to make it clear what the file does. Remember these comments are also seen in the output written to the CSQOUT2 DD card. Here's what my two files will look like.

 
**************************************************************
* Ensure the CHINIT is automatically started upon QMgr start *
**************************************************************
START CHINIT
 

Contents of STACHINY script file

 
**************************************************************
* CHINIT is deliberately NOT started upon QMgr start up      *
**************************************************************
 

Contents of STACHINN script file

Now, you edit the CSQINP2 concatenation to include the following line:-

//      DD DSN=MQDATA.&QMGR..USERDEFS(STACHIN&CHI.),DISP=SHR
 

And edit the PROC to include the default value. Normally I do want my CHINIT to be automatically started, so my default value is Y so that script file STACHINY is run.

 
//         PROC QMGR=MQG1,CHI=Y                          
//PROCSTEP EXEC PGM=CSQYASCP,REGION=0M,MEMLIMIT=2G
 

Now when I start the queue manager I can choose not to start the CHINIT by issuing the following command.

 SDSF DA GEM1     GEM1     PAG  0  CPU   0
COMMAND INPUT ===> /%MQG1 START QMGR ENVPARM('CHI=N')
 PREFIX=* DEST=(ALL) OWNER=* SYSNAME=

This might be useful for DR setups where you don't want any external connectivity to be kicked off.

The above example serves as a single illustration to show how ENVPARM works, but there are many different uses for it. It's probably most useful in development and test, and of course DR, since in production things are much less likely to change, and so there is less requirement for any easy way to change things.