Data necessary to run the transaction is provided in the WebSphere MQ message. The CICS transaction runs as if it has a real 3270 terminal, but instead uses one or more MQ messages to communicate between the CICS transaction and the WebSphere MQ application
Unlike traditional 3270 emulators, the bridge does not work by replacing the VTAM 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. Therefore the application is talking directly to the CICS transaction, rather than through an emulator, using the actual data used by the transaction (known as application data structures or ADSs).
Figure 17 shows the sequence of actions taken to process a single message to run a CICS 3270 transaction.
The following takes each step in turn, and explains what takes place:
For CICS Transaction Server 2.2 and later this uses the CICS Link3270 mechanism. For earlier releases it uses the CICS START BREXIT mechanism. The MQ-CICS 3270 bridge is not supported on CICS Transaction Server V1.2 and earlier.
A traditional CICS application usually 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 WebSphere MQ application. A message is built for the first transaction, containing information about the transaction, and input vectors. This 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 put on the queue. This process is continued until the application ends.
When using CICS releases prior to CICS TS 2.2 the first message for each transaction must be a new session message. When using CICS TS 2.2 or later, it is possible to include all of the WebSphere MQ messages for multiple transactions within 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.
For more information, see the WebSphere MQ Application Programming Guide, the WebSphere MQ Application Programming Reference, and the CICS Internet and External Interfaces Guide.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csqsat0394 |