Update to the MQ/CICS Properties sample code –

One of the most useful SupportPacs for MQ on z/OS was a Message Broker (now IIB) SupportPac called IP13. It contained a couple of very useful utilities that allowed queue to be loaded, CPU tracked, etc. This SupportPac was removed at some point, we don’t know exactly when, but we had a number of TechNotes and lab exercises that used the tools provided by IP13. In particular a program called OEMPUTX.
Colin Piace was gracious enough to add the OEMPUT program into SupportPac MP1B (note no X on this newer version). There are some slight differences between this version and the older implementation, so we have begun altering the TechNotes and lab exercises we deliver to use this new OEMPUT version.
The first of these is the sample COBOL CICS/MQ program that applies a message property to messages as they are copied from one queue to another. It can be found here:

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS5189 
The MP1B SupportPac can be found here:

http://www.ibm.com/support/docview.wss?rs=171&uid=swg24005907&loc=en_US&cs=utf-8&lang=en

Other COBOL CICS/MQ samples that the Washington Systems Center has provided include:

QPU2 and QSU2 – Topics with embedded blanks
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS4852

The Wise MQ for z/OS Administrator – Defining a request and reply queue

In discussing what an MQ administrator has to know and consider as part of the day to day job at IBM it became apparent that there are many clearly defined steps, and some where the wise and experienced admin has to think about many issues outside just using the ISPF panels, MQ Explorer, or runmqsc to simply define an object or two.  There are some decisions that have the potential for being rules driven.  But it seems to me, and to others I have spoken with, that there are many decisions that cannot be as easily quantified, and depend on the administrator’s knowledge of the environment, the application owner, and the applications themselves.  In addition, even some things, which have the potential for being rules driven, would require a substantial effort into creating feedback and tracking that are not currently in the MQ today.

This is also much more of a challenge for shared resources, which MQ almost invariably is.  That is the queue managers own and manage queues, connections, and messages for many applications.  This is the typical usage model for MQ on z/OS, and in the case of UNIX and Linux, ever increasing usage model.  It will also be the model for the MQ appliance.

I am sure I have missed some things that need to be considered, especially on the distributed side.  But I hope to use this as the starting point for a ‘wise MQ administrator’ series that I hope will be useful to others in the future.

So, as an example – assume an MQ administrator that controls queue managers on multiple platforms; received a request for adding a pair of queues for a request/reply scenario for a new mobile hosted interface into an existing CICS transaction.  The flow of the messages would look like this:

Request/Reply MQ message flow sample
Request/Reply MQ message flow sample

 

Some of the decision making process would include, but certainly not be limited to:

1) Naming standards

Does the requesting application and/or the serving application have a naming standard in place?

If so, do the suggested names meet the standard?

If the suggested names meet the standard, go to 2.

If not,

Alter the suggested names to fit the standard and inform the requester of the ‘approved’ name once the queue creation is complete. Note that this may require application changes, if the application developers have been allowed to provision objects themselves during initial development phases. Go to 2.

Or, Reject the request with suggestions for names that will fit with the standards.

Or, create alias queues for the suggested names that will be used by the application, and approved names for the real queues.  Note that this may impact the security requirements. Go to 2.

Or, if there is no standard for the queue names.

Create a standard naming convention for the application queues based on patterns currently in use or based on the application’s requested names.  Note that security needs to be considered, so if there suggestions are something like REQUEST.whatever and REPLY.whatever they will not work with security profiles.  This step may require interaction between the application team(s), the security admins (for each platform the integration goes thru) and the MQ admin.  Remember that the security model on z/OS is very different from the distributed platforms.

Note the creation of new standard can be as simple as checking with a couple of people, or it can require negotiation between the teams.  While this step should have been done in the application design phase, it is often not considered until it is necessary to define resources.

Or, there are standards in place but they are very different for the different platforms and application components.  This typically requires queue alias definitions to be added, in addition to the base resources.

2) Where will the objects reside?

In this scenario, the request queue ultimately must reside on a z/OS queue manager, and the reply queue must ultimately reside on the Linux on Intel queue manager.   So the administrator must define the basic queues, but may have to define other objects as well.

Step 1 – Identify the CICS regions that host the transaction (service).  This requires working with the CICS administrator to identify the target region(s) and get feedback about the workload and availability characteristics.

Step 2 – Identify the queue manager(s) associated with the CICS region(s) hosting the transaction.

If the CICS region(s) is (are) not connected to a queue manager, then the creation task list just expanded to include connecting the CICS region(s) to MQ.  This will require the assistance of the CICS administrator.

Step 3 – Identify the queue manager(s) on Linux on Intel that will host the mobile connections and reply queue(s).

 

3)  Connectivity

Step 1 –  Do the identified queue managers already exist in a cluster?

If yes, the fewest definitions required are:

The request queue and any aliases on z/OS, including cluster membership

The reply queue and any aliases on Linux on Intel, including cluster membership

Proceed to the next set of considerations

Step 2 –  Do the queue managers already have channels defined?

If yes, the definitions required include:

On the z/OS queue manager:

The request queue

The reply queue remote definition using the existing transmission queue

On the Linux on Intel queue manager:

The reply queue

The request queue remote definition using the existing transmission queue

If no, the definitions required include:

On the z/OS queue manager:

The request queue

The transmission queue to the Linux on Intel queue manager

The reply queue remote definition using the new transmission queue

The sender channel to the Linux on Intel queue manager

The receiver channel from the Linux on Intel queue manager

On the Linux on Intel queue manager:

The reply queue

The transmission queue to the z/OS queue manager

The request queue remote definition using the new transmission queue

The sender channel to the z/OS queue manager

The receiver channel from the z/OS queue manager

 

4) Is triggering the CICS transaction required?

If no, proceed to # 5

Yes, the transaction is expected to be triggered:

What is the triggering scheme?

If First, the make sure the application is reading until end of queue and issuing a get-wait for a reasonable period of time.

If Every, make sure the applications understand the cost of this style of processing.

Is the CICS region already hosting triggered transactions?

If no, then on z/OS:

Define an initiation queue to be used by the CICS region

Define the MQ process that will be used, which includes the name of the transaction that will be triggered.

Create an instance of the CICS trigger monitor (CKTI transaction), pointing to the initiation queue.

Update the queue definition with the triggering information.

5) Queue and message characteristics gathering:

This includes anticipated workload information, along with availability requirements that can affect physical location of the queues.    This is an area where experience with the applications and application owners along with knowledge of the existing message volumes, peaks, SLAs, environment limitations, etc. feed back into the administrator’s decisions on queue placement.  Other requirements for both high and continuous availability must also be considered.

As an example, if the applications group consistently under-estimates their volume and capacity requirements, a wise administrator would typically add more than the standard reserve capacity.  If this is an entirely new application, he will probably double the estimates and assume their peak times will coincide with another top-tier application’s peak.  He may choose to set up special resource pools on z/OS to host the queues to isolate the new workload from existing work.  He may even conclude that the anticipated workload will not fit in current queue managers (on either platform) and must be hosted on new ones.

The information required for this includes:

Message size – Min, max, and average.

Message rates – Are there anticipated peak times?  How spiky is the workload?

What is the anticipated growth rate?

Maximum Message Depth –

How many uncommitted messages will be held before they are committed?

Are there requirements to hold messages for a period of time in the event of an emergency?

Are there service level agreements on the response time or QoS for the messages?

Message persistence – should the queue definition specify persistence as the default?

Message expiration – will the application be taking advantage of this feature?

Are there serialization requirements or can multiple instances to the serving transaction be deployed?

What type of transaction is being executed – inquiry only, or an update?

Availability requirements

Does the Linux on Intel queue manager need to be multi instance?

Does the z/OS queue manager need to be in a queue sharing group?  Does the request queue need to be shared?

Security requirements –

Does the request queue need to be put inhibited for applications on the z/OS queue manager?

If yes, then alias queue definitions are required to provide the granular security.

If this is an extension of an existing application, are there rules in place to protect the queues based on the existing naming scheme?

If not, then security decisions need to be made and, typically, rules developed on both platforms to protect the MQ objects.

 

6)  Queue Sharing Group considerations for queue definitions

If there are very high message availability requirements, placing the request queue on the coupling facility is necessary.  The wise administrator will need to think about the following:

  1. Is there sufficient capacity in an existing Coupling Facility structure and the links to the CFs based on the volume and peak estimates?
    1. If no, then a new structure must be added. This will include:
      1. Defining the structure to a CF with available storage, typically done by the z/OS Sysprog.
      2. Determining the offload type (DB2 or SMDS) and rules.
    2. Am I adding a new queue manager to the Queue Sharing group to support the workload?
      1. If yes, then the MQ admin and z/OS Sysprog need to think about:
        1. If the queue manager on a new LPAR or one that has not been connected to the SYSPLEX before? If so there are a number of new objects that must be defined in the ‘plex.
        2. Additional space may be needed in the MQ Admin structure to support an additional queue manager.

 

7) Private queue (on z/OS) considerations for queue definitions

If the z/OS defined queues can be private, then the MQ administrator needs to consider the following:

  1. Is there sufficient capacity in an existing bufferpool and pageset to accommodate the anticipated workload without impacting existing high priority workload?
    1. If no, then a new bufferpool and pageset are necessary.
      1. Is there enough virtual storage to allocate a new bufferpool? Review the storage messages (CSQY220I messages).
      2. If not, then the queue manager may need to be upgraded to V8 or this may require a new queue manager.
  • If there is storage available:
    1. Create the DEFINE BUFFPOOL command to be added into the CSQINP1 input to queue manager startup
    2. Define and format the pageset
    3. Create the DEFINE STGCLASS command to be added into the CSQINP2 input to queue manager startup
  1. Set the queue definition to use the storage class identified with the bufferpool and pageset identified.
  2. Please note for high volume applications, the request queue and the transmission queue used for the reply should be in different bufferpools.

 

Starting again

After an interlude from the world of blogging about MQ for z/OS performance, it is time to start again. I am going to repost my article on the wise MQ Administrator defining a request and reply queue. I hope it helps people.

As time goes on, I will expand on the theme of wise administration especially as more companies are looking to automate more administration tasks.