From 3270 legacy to 3270 bridge - an example

 

This section illustrates the differences in the data flows that take place when a CICS 3270 transaction interacts with a 3270 terminal, and a CICS bridge application.

In this example, the transaction has an identifier of BAAA. It uses BMS maps, which allow the transaction to be adapted easily to run under the CICS bridge.

In the legacy environment, the transaction is started by entering its name at the CICS 3270 terminal and pressing Enter. Logic in the transaction causes it to issue EXEC CICS SEND MAP the first time that it is invoked in a pseudoconversation, and then to terminate by issuing EXEC CICS RETURN TRANSID(BAAA).

The user enters values into fields in the map that is displayed at the terminal, and then presses an AID key. Logic in the transaction the second time that it is invoked causes it to issue EXEC CICS RECEIVE MAP to receive the map. It updates certain fields in the map by changing values in its own application data structure, and then issues EXEC CICS SEND MAP to redisplay the map at the user's terminal.

The user can then update fields in the redisplayed map, and start the RECEIVE MAP - SEND MAP cycle again. The logic can be illustrated like this (where EC represent EXEC CICS):

Terminal user                                       3270 Transaction
BAAA <ENTER>           -------------------→         <Initial start>
                                                    <business logic>
                     ←-------------------          EC SEND MAP FROM(ads)
                                                    EC RETURN TRANSID(BAAA)

Update fields 
<ENTER>                -------------------→         EC RECEIVE MAP INTO(ads)
                                                    <business logic>
                      ←-------------------          EC SEND MAP
                                                    EC RETURN TRANSID(BAAA)
Update fields
<ENTER>                -------------------→         EC RECEIVE MAP
                                                   ⋮
When the transaction runs in the bridge environment, the physical terminal is replaced by an application. The logic of the 3270 transaction is unchanged, and the application data that it receives is the same, but the data that flows, and the means by which it is transmitted, are different. Instead of a 3270 data stream, a WebSphere MQ message is used that contains an MQCIH structure (a CICS Information Header), a bridge vector structure, and optionally a representation of the application data structure.

Including these objects in the message depends on the direction in which the message flows (inbound to the bridge or outbound from the bridge), the sequence of the message in the exchange, and whether an application data structure descriptor has been requested by setting the appropriate value in a field in the MQCIH.

The section Exact emulation - no optimization shows the flows that take place when the above scheme is emulated exactly. There is scope for optimization by including more than one vector in inbound messages, as shown in the section Improved emulation, with optimization.

It is assumed that MQCIH.ADSDescriptor is set to:

MQCADSD_SEND + MQCADSD_RECV + MQCADSD_MSGFORMAT 
so application data structure descriptors in long form are appended to both outbound and inbound application data structures during the exchange of messages.

For clarity, the details of messaging are omitted here. For a description of the queuing model used by the CICS bridge, see theWebSphere MQ for z/OS Concepts and Planning Guide.

 

Parent topic:

3270 applications


fg15680_