Server applications

Server applications

Here is an outline of the MQI server application model:
 Initialize/Connect
  .
 Open queue for input shared
  .
 Get message from WebSphere MQ queue
  .
 Do while Get does not fail
      .
     If expected message received
       Process the message
     Else
       Process unexpected message
     End if
      .
     Commit
      .
     Get next message from WebSphere MQ queue
      .
 End do
 .
 Close queue/Disconnect
 .
END
Sample program CSQ4ICB3 shows the implementation, in C/370™, of a BMP using this model. The program establishes communication with IMS™ first, and then with WebSphere MQ:
main()
----
    Call InitIMS
    If IMS initialization successful
       Call InitMQM
       If WebSphere MQ initialization successful
          Call ProcessRequests
          Call EndMQM
       End-if
    End-if
 
Return
The IMS initialization determines whether the program has been called as a message-driven or a batch-oriented BMP and controls WebSphere MQ queue manager connection and queue handles accordingly:
InitIMS
-------
Get the IO, Alternate and Database PCBs
Set MessageOriented to true
 
Call ctdli to handle status codes rather than abend
If call is successful (status code is zero)
   While status code is zero
      Call ctdli to get next message from IMS message queue
      If message received
         Do nothing
         Else if no IOPBC
            Set MessageOriented to false
            Initialize error message
            Build 'Started as batch oriented BMP' message
            Call ReportCallError to output the message
         End-if
         Else if response is not 'no message available'
            Initialize error message
            Build 'GU failed' message
                Call ReportCallError to output the message
                Set return code to error
         End-if
      End-if
   End-while
Else
   Initialize error message
   Build 'INIT failed' message
   Call ReportCallError to output the message
   Set return code to error
End-if
 
Return to calling function
The WebSphere MQ initialization connects to the queue manager and opens the queues. In a message-driven BMP this is called after each IMS syncpoint is taken; in a batch-oriented BMP, this is called only during program startup:
InitMQM
-------
    Connect to the queue manager
    If connect is successful
       Initialize variables for the open call
       Open the request queue
       If open is not successful
          Initialize error message
          Build 'open failed' message
          Call ReportCallError to output the message
          Set return code to error
       End-if
    Else
       Initialize error message
       Build 'connect failed' message
       Call ReportCallError to output the message
       Set return code to error
    End-if
 
    Return to calling function
The implementation of the server model in an MPP is influenced by the fact that the MPP processes a single unit of work per invocation. This is because, when a syncpoint (GU) is taken, the connection and queue handles are closed and the next IMS message is delivered. This limitation can be partially overcome by one of the following:
Processing many messages within a single unit-of-work
This involves:

Reading a message
Processing the required updates
Putting the reply
in a loop until all messages have been processed or until a set maximum number of messages has been processed, at which time a syncpoint is taken.
Only certain types of application (for example, a simple database update or inquiry) can be approached in this way. Although the MQI reply messages can be put with the authority of the originator of the MQI message being handled, the security implications of any IMS resource updates need to be addressed carefully.
Processing one message per invocation of the MPP and ensuring multiple scheduling of the MPP to process all available messages.
Use the WebSphere MQ IMS trigger monitor program (CSQQTRMN) to schedule the MPP transaction when there are messages on the WebSphere MQ queue and no applications serving it.
If trigger monitor starts the MPP, the queue manager name and queue name are passed to the program, as shown in the following COBOL code extract:
      * Data definition extract
       01  WS-INPUT-MSG.
           05 IN-LL1                  PIC S9(3) COMP.
           05 IN-ZZ1                  PIC S9(3) COMP.
           05 WS-STRINGPARM           PIC X(1000).
       01  TRIGGER-MESSAGE.
           COPY CMQTMC2L.
      *
      * Code extract
       GU-IOPCB SECTION.
           MOVE SPACES TO WS-STRINGPARM.
           CALL 'CBLTDLI' USING GU,
                                IOPCB,
                                WS-INPUT-MSG.
           IF IOPCB-STATUS = SPACES
               MOVE WS-STRINGPARM TO MQTMC.
      *    ELSE handle error
      *
      * Now use the queue manager and queue names passed
           DISPLAY 'MQTMC-QMGRNAME          ='
                   MQTMC-QMGRNAME OF MQTMC '='.
           DISPLAY 'MQTMC-QNAME             ='
                   MQTMC-QNAME    OF MQTMC '='.
The server model, which is expected to be a long running task, is better supported in a batch processing region, although the BMP cannot be triggered using CSQQTRMN.

Parent topic:
MQI calls in IMS applications

fg15840_