Writing applications using CICS Basic Mapping Support

 

If your application does not use maps you do not need to read this section; go to Programming CICS transactions in the distributed environment

CICS Basic Mapping Support (BMS) provides a way for CICS applications to support a number of different terminal types. When the application issues EXEC CICS SEND MAP, BMS merges terminal-specific control data with the application data to produce a 3270 data stream that can be displayed at the terminal. When the application issues EXEC CICS RECEIVE MAP, application data is extracted from an inbound 3270 data stream and returned to the application.

A BMS map for a CICS application is created by assembling a set of BMS macros that define the characteristics of fields that are required for the display. One of the outputs from map assembly is a copybook that maps the display fields to an ADS. The CICS application must include the copybook in its data definitions so that it can address the fields in the map symbolically. The application data in a SEND MAP, and expected by a RECEIVE MAP, is mapped directly to the ADS in the copybook.

When the transaction runs under the CICS bridge, EXEC CICS SEND MAP and EXEC CICS RECEIVE MAP commands generate SEND MAP and RECEIVE MAP vectors in outbound messages. Instead of a 3270 data stream, these vectors contain ADSs equivalent to those used by the CICS application to address fields in the map.

The format of the ADS is unique for each map. It is described by a copybook created as part of map generation. Without this copybook it is difficult to interpret the data. Usually WebSphere MQ applications include the BMS copybooks so that they can create RECEIVE MAP data, and interpret SEND MAP data. However, we can write an application without the specific BMS copybooks. The format of the data is described by a structure known as the ADS descriptor (ADSD). The ADSD is added to the end of a SEND MAP vector, and it describes the format of the ADS in the vector. The ADSD contents include the names, positions, and lengths of the fields in the ADS. An ADSD can also be sent on a RECEIVE MAP request. We can use this in conversational applications to tell the WebSphere MQ application the structure of the ADS requested by the CICS application. The WebSphere MQ application can then build a RECEIVE MAP vector with this ADS, and send it as a new request.

As an application programmer, we can choose whether you want to interpret vector data in messages using the ADS, the ADSD, or the ADSDL (long form of the application data structure descriptor). In order to interpret the ADS directly, include the copybook from map assembly in your WebSphere MQ bridge application. If you want to do this, but you do not have access to the copybook or map, re-create the map with the CICS utility DFHBMSUP; this requires CICS Transaction Server 1.2 or later.

If you want to interpret the ADS indirectly through the ADSD or ADSDL, for example if you are creating a generic application that will handle all maps, you do not need to include the copybook in your bridge application. Instead we need to send control information to the bridge that tells it to include the ADSD or ADSDL in outbound SEND MAP and RECEIVE MAP request vectors as required.

If your application must run in the distributed environment, include an ADSDL in outbound SEND MAP vectors. WebSphere MQ can then convert data in the outbound message.

We can specify any of the following options by setting appropriate values in field MQCIH.ADSDescriptor in inbound messages:

We can add MQCADSD_* values together to include the long form of the application data structure descriptor in both SEND MAP and RECEIVE MAP vectors: 

 MQCIH.ADSDescriptor = MQCADSD_SEND + MQCADSD_RECV + MQCADSD_MSGFORMAT
In this case, the SEND MAP vector also includes an ADS in long form.

 

Parent topic:

Using CICS transactions with the bridge


fg15600_