Triggering in the client environment

Triggering is explained in detail in the WebSphere MQ Application Programming Guide.

Messages sent by WebSphere MQ applications running on WebSphere MQ clients contribute to triggering in exactly the same way as any other messages, and they can be used to trigger programs on the server. The trigger monitor and the application to be started must be on the same system.

The default characteristics of the triggered queue are the same as those in the server environment. In particular, if no MQPMO syncpoint control options are specified in a client application putting messages to a triggered queue that is local to a z/OS queue manager, the messages are put within a unit of work. If the triggering condition is then met, the trigger message is put on the initiation queue within the same unit of work and cannot be retrieved by the trigger monitor until the unit of work ends. The process that is to be triggered is not started until the unit of work ends.

 

Process definition

You must define the process definition on the server, because this is associated with the queue that has triggering set on.

The process object defines what is to be triggered. If the client and server are not running on the same platform, any processes started by the trigger monitor must define ApplType, otherwise the server takes its default definitions (that is, the type of application that is normally associated with the server machine) and causes a failure.

For example, if the trigger monitor is running on a Windows NT client and wants to send a request to an OS/2 Warp server, MQAT_WINDOWS_NT must be defined otherwise OS/2 Warp uses its default definitions (that is, MQAT_OS2) and the process fails.

For a list of application types, see the WebSphere MQ Application Programming Reference manual.

 

MQSeries client for Windows 95

The MQSeries client for Windows 95 runs in 32-bit mode. It is also possible to run the client for Windows 3.1 in 16-bit mode on a Windows 95 platform. If a trigger monitor is running on a Windows 95 client you must make sure that you define the correct ApplType:

MQAT_WINDOWS
Windows 3.1 client or 16-bit Windows application.

MQAT_WINDOWS_NT
Windows client or 32-bit Windows application.

 

Trigger monitor

The trigger monitor provided by non-z/OS WebSphere MQ products runs in the client environments for Compaq OpenVMS Alpha, OS/2 Warp, UNIX systems, Windows, Windows 3.1, and Windows 95. To run the trigger monitor, issue the command: 

runmqtmc [-m QMgrName] [-q InitQ]

The default initiation queue is SYSTEM.DEFAULT.INITIATION.QUEUE on the default queue manager. This is where the trigger monitor looks for trigger messages. It then calls programs for the appropriate trigger messages. This trigger monitor supports the default application type and is the same as runmqtrm except that it links the client libraries.

The command string, built by the trigger monitor, is as follows:

  1. The ApplicId from the relevant process definition. Name of the program to run, as it would be entered on the command line.

  2. The MQTMC2 structure, enclosed in quotes, as got from the initiation queue. A command string is invoked that has this string, exactly as provided, in quotes in order that the system command will accept it as one parameter.

  3. The EnvrData from the relevant process definition.

The trigger monitor does not look to see if there is another message on the initiation queue until the completion of the application it has just started. If the application has a lot of processing to do, this might mean that the trigger monitor cannot keep up with the number of trigger messages arriving. There are two ways to deal with this:

  1. Have more trigger monitors running

    If you choose to have more trigger monitors running, you can control the maximum number of applications that can run at any one time.

  2. Run the started applications in the background

    If you choose to run applications in the background, WebSphere MQ imposes no restriction on the number of applications that can run.

To run the started application in the background on an OS/2 Warp system, within the ApplicId field prefix the name of your application with a start command; for example, start amqsinq /B.

To run the started application in the background on a UNIX system, put an & (ampersand) at the end of the EnvrData of the process definition.

 

CICS applications (non-z/OS)

A non-z/OS CICS application program that issues an MQCONN or MQCONNX call must be defined to CEDA as RESIDENT. To make the resident code as small as possible, you can link to a separate program to issue the MQCONN or MQCONNX call.

If the MQSERVER environment variable is used to define the client connection, it must be specified in the CICSENV.CMD file.

WebSphere MQ applications can be run in an WebSphere MQ server environment or on an WebSphere MQ client without changing code. However, in an WebSphere MQ server environment, CICS can act as syncpoint coordinator, and you use EXEC CICS SYNCPOINT and EXEC CICS SYNCPOINT ROLLBACK rather than MQCMIT and MQBACK. If a CICS application is simply relinked as a client, syncpoint support is lost. MQCMIT and MQBACK must be used for the application running on an WebSphere MQ client.

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.