How CICS 3270 transactions run under the CICS-WebSphere MQ bridge
A WebSphere® MQ message provides the data needed to run a CICS® 3270 transaction. The CICS transaction runs as if it has a real 3270 terminal, but instead uses one or more WebSphere MQ messages to communicate between the CICS transaction and the WebSphere MQ application.
The CICS-WebSphere MQ bridge uses the CICS Link3270 mechanism to access the CICS transaction. Unlike traditional 3270 emulators, the CICS-WebSphere MQ bridge does not work by replacing the z/OS® Communications Server flows with WebSphere MQ messages. Instead, the message consists of a number of parts called vectors, each of which corresponds to an EXEC CICS request. The application is therefore talking directly to the CICS transaction, rather than through an emulator, using the data used by the transaction (known as application data structures or ADSs).
Figure 1 shows the sequence of actions taken to process a single message to run a CICS 3270 transaction.
- A message, with a request to run a CICS transaction, is put on the request queue.
- The CICS-WebSphere MQ bridge monitor task, which is constantly browsing the queue, recognizes that a ‘start unit of work' message is waiting (CorrelId=MQCI_NEW_SESSION).
- Relevant authentication checks are made, and a CICS 3270 bridge task is started with the appropriate authority, with a particular user ID (depending on the options used to start the bridge monitor).
- The CICS-WebSphere MQ bridge removes the message from the queue and changes task to run a user transaction.
- Vectors in the message provide data to answer all terminal-related input EXEC CICS requests in the transaction.
- Terminal-related output EXEC CICS requests result in output vectors being built.
- The CICS-WebSphere MQ bridge builds all the output vectors into a single message and puts it on the reply-to queue.
- The CICS 3270 bridge task ends. If this flow is the last one in the transaction, the transaction ends. If this message is not the last one, the transaction waits until the next message is received or the specified timeout interval expires.
Multiple CICS transactions
A CICS application often consists of one or more transactions linked together as a pseudoconversation. In general, each transaction is started by the 3270 terminal user entering data onto the screen and pressing an AID key. This model of application can be emulated by a non-CICS application that uses the CICS-WebSphere MQ bridge.
In this model, a message is built for the first transaction, containing information about the transaction, and input vectors. This message is put on the queue. The reply message consists of the output vectors, the name of the next transaction to be run, and a token that is used to represent the pseudoconversation. The WebSphere MQ application builds a new input message, with the transaction name set to the next transaction, and the facility token and remote system ID set to the value returned on the previous message. Vectors for this second transaction are added to the message, and the message is put on the queue. This process is continued until the application ends.
You can include all the WebSphere MQ messages for multiple transactions in the same bridge session, which reduces monitoring overheads and improves performance.
An alternative approach to writing CICS applications is the conversational model. In this model, the original message might not contain all the data to run the transaction. If the transaction issues a request that cannot be answered by any of the vectors in the message, a message is put onto the reply-to queue requesting more data. The WebSphere MQ application gets this message and puts a new message back to the queue with a vector to satisfy the request.