Abbydale Systems LLC - Defining MQ Channels

As ever, you use this free code at your own risk.

Feel free to use the free software on this site but please honor the copyright.

This page is discusses how to define MQ objects on a z/OS systems in order to establish channel triggering but the same principles apply to all WebSphereMQ platforms. To use the definitions on other platforms you will need to use the RUNMQSC program for executing the commands.

The intent of this page is to provide the definitions required to establish a triggered sender and receiver channel pairs between two queue managers and to give a simple 'round trip' mechanism to prove the definitions have worked successfully.

This page will assume that TCP/IP is the network protocol in use but the principal applies to other network protocols.

The definitions that will be given are fairly basic, it is up to you to ensure that you follow your site standards for things like security (MCAUSER) etc.

Why Trigger Channels?

Regardless of how you start channels, the simple fact remains that they must get started in order for messages to flow across them.

In a large WebSphereMQ network, automating the startup of channels becomes almost essential. Without using triggered channels, a significant effort in custom automation may be required. Given that WebSphereMQ may be running across many different platforms this may involve the use of several automation products to automate the starting of channels.

Coordinating this automation may also be a substantial undertaking.

Contrast this with triggered channels. Channel initiators exist on most WebSphereMQ platforms and the definitions to control their execution are common to most WebSphereMQ platforms.

Finally, and perhaps most significantly there is no custom coding required to implement triggering channels.

Customizing the Sample Code

The sample code is provided with a REXX Exec (named CUSTOM) that will customize the supplied JCL with your values.

The JCL dataset is distributed in TSO Transmitted format and comprises of 6 members. These members are:

	Member	Description
	ASLINS01	This is an ISPF Prepped panel used by member CUSTOM to allow the user to enter the values for the JCL members to use for the relevant names. This member can be deleted once the JCL is customized.

	CUSTOM	This is the customization EXEC. It changes the supplied JCL to use your site values. This EXEC can be skipped, but then manual editing of the supplied members will be needed. This member can be deleted once the JCL has been customized.

	DEFCHAN	This the JCL for actually defining the required WebSphereMQ objects for creating triggered channel pairs. It is actually 2 jobs but if the two Queue Managers are running on the same z/OS image it can be run as a two step job. The definitions created here can also be separated to run on 2 different LPARS to create the channel pairs. If one end of the channel pair is on a different platform the definitions can cut and pasted onto that platform and then piped into RUNMQSC and the objects will be created.

	DEFQUES	This job is an optional job, however, it can be used to create the required 'test' queues to prove the connections between the queue managers is functioning correctly. Similar to the DEFCHAN job this member is 2 jobs and can be run it the same manner as the DEFCHAN jobs.

	ECHO	This JCL will execute the supplied, free QECHO program. QECHO simply reads a message from the input queue and writes that same message back to the reply queue. More details on the QECHO program can be found here.

	PUT	This JCL will execute the supplied, free QPUT program. QPUT will simply read cards from the SYSIN stream and put them onto a Queue. It will then wait for a reply. More details on the QPUT program can be found here.

Theoretically you only need to examine and change the DEFCHAN member to establish two way channel communication between two Queue Managers. Indeed, you can even just copy the WebSpehereMQ Object definitions and they should work.

Important Reminders

Remember that the case of the Objects matter with WebSphereMQ. If a name consists of upper and lower case letters, then they must exactly match in the definitions for both ends.
The Process definition in these jobs is platform specific. In other words it is for z/OS only, however, the good news is that on other platforms it is not as picky on what you name the process.
The supplied CUSTOM Rexx exec will overwrite the distributed members so if you want to keep the original members we recommend taking a backup before running CUSTOM.
On z/OS Queue Manager names are limited to 4 characters in length and should be in upper case.
The CUSTOM exec allows for more than 4 characters simply so that you can define a name for a different platform.

Installation

This feature comprises of 2 datasets. One simply contains the two programs QECHO and QUEPUT that are needed if you want to run the ECHO and PUT JCL members. The other contains the JCL members detailed above.

If you don't want to run the ECHO or PUT jobs then you do not need to download the load library.

	Link	Description
	DEFCHAN XMI File	This is the link to the DEFCHAN JCL dataset in TSO TRANSMIT (XMIT) format.

	QECHO & QUEPUT Loadlib XMI File	This is the link to the load library dataset in TSO TRANSMIT (XMIT) format that contains the 2 programs, QECHO & QUEPUT. These are used by the ECHO & PUT respectively.

As both these files are TSO TRANSMIT files they should be transferred to the z/OS system using a file transfer program. The files must be transferred as BINARY files. They should also be transferred as fixed blocked, 80 byte files.

Once the files are on z/OS they will have to be received. To do this you use the TSO RECEIVE command. Please refer to the IBM RECEIVE command for details on the use of this TSO command.

Once the DEFCHAN JCL file has been RECEIVED you can execute the CUSTOM exec by entering:

TSO ex 'your.received.dataset.name(CUSTOM)'

This will display the following screen:

ASLINS01 Screen

From this panel you fill in the appropriate site values and press enter.

The remaining job members should then be customized to your site standards.

Disclaimer

This material has been used successfully by Abbydale Systems LLC. and to the best of our knowledge this material and any system(s) of which it is a part are operational as of the service level or date stated in the body of this material (if so stated). However, NO warranty is given or implied as to the accuracy of this material or any related material or systems, and no responsibility is assumed for any effect or modification directly or indirectly caused by the use of this material.

It is the responsibility of any user of this material to evaluate its usefulness to the user's environment.

Abbydale Systems LLC. does not guarantee to keep this or any related material current, nor does it guarantee to provide any corrections or extensions described by any users of this material or any corrections or extensions made in the future by Abbydale Systems LLC. itself.

If you need any support or assistance with any of the code on this site
or
if you would like to contact us, please click here

Follow us on Facebook

Last modified : Wednesday 26th of April 2023

Why Trigger Channels?

Customizing the Sample Code

Member

Description

Important Reminders

Installation

Link

Description

Disclaimer