The Request sample programs demonstrate client/server processing. The samples are the clients that put request messages on a target server queue that is processed by a server program. They wait for the server program to put a reply message on a reply-to queue.
The Request samples put a series of request messages on target server queue using the MQPUT call. These messages specify the local queue, SYSTEM.SAMPLE.REPLY as the reply-to queue, which can be a local or remote queue. The programs wait for reply messages, then display them. Replies are sent only if the target server queue is being processed by a server application, or if an application is triggered for that purpose (the Inquire, Set, and Echo sample programs are designed to be triggered). The C sample waits 1 minute (the COBOL sample waits 5 minutes), for the first reply to arrive (to allow time for a server application to be triggered), and 15 seconds for subsequent replies, but both samples can end without getting any replies. See Features demonstrated in the sample programs for the names of the Request sample programs.
The C version of the program takes 2 parameters:
If a queue manager is not specified, it will connect to the default one. For example, enter one of the following:
amqsreq myqueue qmanagername
amqsreqc myqueue qmanagername
amq0req0 myqueue
where myqueue is the name of the target server queue, and qmanagername is the queue manager that owns myqueue.
If you omit the qmanagername, when running the C sample, it will assume that the default queue manager owns the queue.
The COBOL version does not have any parameters. It connects to the default queue manager and when you run it you are prompted:
Please enter the name of the target server queue
The program takes its input from StdIn and adds each line to the target server queue, taking each line of text as the content of a request message. The program ends when a null line is read.
The C program creates messages by taking data from stdin (the keyboard) with a blank time terminating input. The program takes up to three parameters: the name of the target queue (required), the queue manager name (optional), and the reply-to queue name (optional). If no queue manager name is specified, the default queue manager is used. If no reply-to queue is specified, the SYSTEM.SAMPLE.REPLY queue is used.
Here is an example of how to call the C sample program, specifying the reply-to queue, but letting the queue manager default:
CALL PGM(QMQM/AMQSREQ4) PARM('SYSTEM.SAMPLE.LOCAL' '' 'SYSTEM.SAMPLE.REPLY')
The COBOL program creates messages by accepting data from the keyboard. To start the program, call the program and specify the name of your target queue as a parameter. The program accepts input from the keyboard into a buffer and creates a request message for each line of text. The program stops when you enter a blank line at the keyboard.
If the sample is used with triggering and one of the Inquire, Set, or Echo sample programs, the line of input must be the queue name of the queue that you want the triggered program to access.
To run the samples using triggering:
The sample queues available to you to use as the target server queue for the request sample to put messages are:
These queues have a trigger type of FIRST, so if there are already messages on the queues before you run the Request sample, server applications are not triggered by the messages you send.
This means that the trigger monitor is ready when the request sample sends a message.
Figure 35 demonstrates how the Request and Inquire samples can be used together.
Figure 35. Request and Inquire samples using triggering
In Figure 35 the Request sample puts messages on to the target server queue, SYSTEM.SAMPLE.INQ, and the Inquire sample queries the queue, MYQUEUE. Alternatively, you can use one of the sample queues defined when you ran amqscos0.tst, or any other queue you have defined, for the Inquire sample.
To run the Request and Inquire samples, using triggering:
RUNMQTRM -m qmanagername -q SYSTEM.SAMPLE.TRIGGER
amqsreq SYSTEM.SAMPLE.INQ
For example, if the trigger monitor is running on a Windows systems client and wants to send a request to an OS/2 server, MQAT_WINDOWS_NT must be defined otherwise OS/2 uses its default definitions (that is, MQAT_OS2) and the process fails.
For a list of application types, see WebSphere MQ Application Programming Reference.
MYQUEUE
If you wish, you can use more than one queue. In this case, you enter the names of the other queues at step 4.
For more information on triggering see Chapter 14, Starting WebSphere MQ applications using triggers.
OS/400
To try the samples using triggering on OS/400, start the sample trigger server, AMQSERV4, in one job, then start AMQSREQ4 in another. This means that the trigger server is ready when the Request sample program sends a message.
Notes:
You could put your request messages on these sample server queues:
A flow chart for the SYSTEM.SAMPLE.ECHO program is shown in Figure 36. Using the example data file the command to issue the C program request to this server is:
CALL PGM(QMQMSAMP/AMQSREQ4) PARM('QMQMSAMP/AMQSDATA(ECHO)')
If you want to attempt further examples, you can try the following variations:
CALL PGM(QMQMSAMP/AMQSREQ4) PARM('QMQMSAMP/AMQSDATA(INQ)') CALL PGM(QMQMSAMP/AMQSREQ4) PARM('QMQMSAMP/AMQSDATA(SET)')
These sample queues also have a trigger type of FIRST.
The program opens the target server queue so that it can put messages. It uses the MQOPEN call with the MQOO_OUTPUT option. If it cannot open the queue, the program displays an error message containing the reason code returned by the MQOPEN call.
The program then opens the reply-to queue called SYSTEM.SAMPLE.REPLY so that it can get reply messages. For this, the program uses the MQOPEN call with the MQOO_INPUT_EXCLUSIVE option. If it cannot open the queue, the program displays an error message containing the reason code returned by the MQOPEN call.
For each line of input, the program then reads the text into a buffer and uses the MQPUT call to create a request message containing the text of that line. On this call the program uses the MQRO_EXCEPTION_WITH_DATA report option to request that any report messages sent about the request message will include the first 100 bytes of the message data. The program continues until either it reaches the end of the input or the MQPUT call fails.
The program then uses the MQGET call to remove reply messages from the queue, and displays the data contained in the replies. The MQGET call uses the MQGMO_WAIT, MQGMO_CONVERT, and MQGMO_ACCEPT_TRUNCATED options. The WaitInterval is 5 minutes in the COBOL version, and 1 minute in the C version, for the first reply (to allow time for a server application to be triggered), and 15 seconds for subsequent replies. The program waits for these periods if there is no message on the queue. If no message arrives before this interval expires, the call fails and returns the MQRC_NO_MSG_AVAILABLE reason code. The call also uses the MQGMO_ACCEPT_TRUNCATED_MSG option, so messages longer than the declared buffer size are truncated.
The program demonstrates how you must clear the MsgId and CorrelId fields of the MQMD structure after each MQGET call because the call sets these fields to the values contained in the message it retrieves. Clearing these fields means that successive MQGET calls retrieve messages in the order in which the messages are held in the queue.
The program continues until either the MQGET call returns the MQRC_NO_MSG_AVAILABLE reason code or the MQGET call fails. If the call fails, the program displays an error message that contains the reason code.
The program then closes both the target server queue and the reply-to queue using the MQCLOSE call.
Figure 36. Sample OS/400 Client/Server (Echo) program flowchart