3270 transaction, illustration" /> Running CICS 3270 transactions

 

Running CICS 3270 transactions

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:

  1. A message, with a request to run a CICS transaction, is put on the request queue.

  2. The CICS bridge monitor task, which is constantly browsing the queue, recognizes that a 'start unit of work' message is waiting (CorrelId=MQCI_NEW_SESSION).

  3. Relevant authentication checks are made, and a CICS 3270 bridge task is started with the appropriate authority, with a particular userid (depending on the options used to start the bridge monitor).

  4. The WebSphere MQ-CICS bridge removes the message from the queue and changes task to run a user transaction

  5. Vectors in the message provide data to answer all terminal-related input EXEC CICS requests in the transaction.

  6. Terminal-related output EXEC CICS requests result in output vectors being built.

  7. The WebSphere MQ-CICS bridge builds all the output vectors into a single message and puts this on the reply-to queue.

  8. The CICS 3270 bridge task ends. If this is the last flow in the transaction then the transaction ends, if it is not the last message, the transaction waits until the next message is received or the specified timeout interval expires.

Note:
The WebSphere MQ CICS bridge is a WebSphere MQ supplied CICS exit associated with the bridge transaction.

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.

Figure 17. Components and data flow to run a CICS 3270 transaction

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.