Overview

Skill Level: Intermediate

For a large application, data transfer between different servers is a common thing. In this recipe the characteristics of the MQ communication on iServer is introduced, and the key things for application of applying MQ are discussed.

Ingredients

1 iServer

2 Installed MQ

3 Basic MQ commands on iServer

Step-by-step

  1. WebSphere MQ summary

    WebSphere MQ middleware is IBM product and it can be installed on any of IBM servers: zServer, Pserver, iServer and xServer.  MQ middleware has the mechanism of data integrity in it, so applications do not need to check data validity and integrity. MQ is applied in the scenario where large data block or data file is transferred and less or no interactions between two servers are needed. This is the general architecture of MQ middleware:

    aaa-1

    In an installed MQ system there are some queues for management purpose. Applications do not need to access them. And even developers do not need to configure them ‚Äď MQ administrators work them. But developers need to design the queues where their application data is transmitted.

     

  2. MQ configuration

    On iServer, command WRKMQMQ is used to create/delete/maintain an MQ. This command integrates a lot of functions.

     aaa2

    Usually any organization has control of MQ authority, especially for creating/deleting/updating MQ and Queue manager. So you need to have appropriate authority before you do these things.

    Usually one server is configured with one queue manager. All the MQ queues in this server are governed by this queue manage. In the above screen shot, if type is *LCL, this means the queue is local queue. If type is *RMT, this is remote queue. Remote queue means a local queue in the counterpart server and we want to send data to it. The remote queue needs to be linked to a transmit queue, so the data can be sent out.

    Also, when a new queue is created, the parameter Maximum number of messages should be sufficient. Or when the maximum number is reached, the new coming-in messages will be automatically put into the DEAD LETTER QUEUE.  Therefore, the dead letter queue should be monitored when MQ is applied.

  3. MQ applications

    The best practice for developing MQ application is to separate the business logic with the MQ operations. This implies business logic and MQ operations are managed in different components.  Thus the MQ operation components can be reused by other components.

     aaa3

    The above diagram describes the process applying MQ.  On Server 1 we assume 3 applications access the same MQ queue. On server 2 there is a message monitor program to checking if there is a coming-in message. And the monitor program relays the message to the application program if a message exists. Then the application program returns the process result to server 1 by sending a message to a MQ queue.  This is a little complex application scenario.  Usually we do not have that complexity: on Server 1 there is only one application using MQ queue. On Server 2 there is no message monitor. An application program retrieve message by scheduling. And even there is no reply but just sending data in one direction.

  4. MQ APIs

    MQ middleware provides some APIs. Application program apply MQ by calling these APIs. These APIs are defined in MQ user manual.  From the below APIs we can see that the most APIs are same for sending data and receiving data. The only difference is that sending data needs API MQPUT, while getting data needs API MQGET.  When we send or get data via MQ, we need to apply all the 5 APIs sequentially in the left column or the right column to complete one operation on an MQ queue.

     aaa5

    There are a lot of parameters used in MQ APIs. In every API, there is completion code and Reason code. Completion code is used to show if the API call is complete. Reason code is to show the error reason if the API call fails. Get message options are used to show what operations are taken when getting a message. For an example, when reading a message, if there is not a message, it we wait; if we want to read first or next message etc. Put message options are used to show that operations are taken when sending a message. We often use the combination of the options of MQGET or the combination of the options of MQPUT.

    We list some frequently used parameters here.

    Completion Codes

    MQCC_OK    

    MQCC_WARNING

    MQCC_FAILED

    MQCC_UNKNOWN

    Reason Codes

    MQRC_BUFFER_ERROR

    MQRC_BUFFER_LENGTH_ERROR

    MQRC_DATA_LENGTH_ERROR

    MQRC_HANDLE_NOT_AVAILABLE

    MQRC_HCONN_ERROR        

    MQRC_HOBJ_ERROR         

    MQRC_MSG_TYPE_ERROR      

    MQRC_MSG_TOO_BIG_FOR_Q   

    MQRC_MSG_TOO_BIG_FOR_Q_MGR

    MQRC_NO_MSG_AVAILABLE

    QRC_NOT_OPEN_FOR_BROWSE

    QRC_NOT_OPEN_FOR_INPUT 

    QRC_NOT_OPEN_FOR_INQUIRE

    QRC_NOT_OPEN_FOR_OUTPUT

    MQRC_PUT_INHIBITED

    MQRC_Q_TYPE_ERROR

    Open Options

    MQOO_INPUT_SHARED  

    MQOO_INPUT_EXCLUSIVE

    MQOO_BROWSE        

    MQOO_OUTPUT        

    MQOO_FAIL_IF_QUIESCING

    Get Message Options

    MQGMO_WAIT            

    MQGMO_NO_WAIT         

    MQGMO_FAIL_IF_QUIESCING

    MQGMO_BROWSE_FIRST

    MQGMO_BROWSE_NEXT

    MQGMO_LOCK 

    MQGMO_UNLOCK

    MQGMO_ALL_MSGS_AVAILABLE

    MQGMO_NONE

    Put Message Options

    MQPMO_NEW_MSG_ID  

    MQPMO_NEW_CORREL_ID

    MQPMO_FAIL_IF_QUIESCING

    MQPMO_NONE

Join The Discussion