Sending data to the partner transaction

To send data on an APPC basic conversation, an application must format the data into generalized data stream (GDS) records.

A GDS record contains a 16-bit (2-byte) header followed by the application data. The 16 bits of the header consist of the following fields:

Concatenation bit
This is the high-order bit of the first byte of the header. An application program can use it to group records together logically. This bit does not affect the way CICS® processes the records.
LL
This is the rest of the header (15 bits). It specifies the overall length of the data (including the length of the header).
Figure 1 shows the format of GDS records.
Figure 1. Format of GDS records
This figure illustrates the format of a GDS record, which is described in the text.
Up to 32 765 bytes of application data can be accommodated in one GDS record.

Data formatted into GDS records can be transmitted by the GDS SEND command. This command is valid only in send state (state 2).

Because a simple GDS SEND keeps the conversation in send state (state 2), you can issue a number of successive sends. You need not issue a GDS SEND for every record to be sent; you can send partial or multiple records at a time. However, make sure that the last logical record is complete when you use the INVITE, LAST, or CONFIRM options, and before you issue a syncpoint request.

Figure 2 is an example of the use of GDS SEND commands.
Figure 2. An example of the use of GDS SEND commands.
The data to be sent consists of four logical records:
  1. A GDS SEND command is used to transmit the whole of record 1, and the first portion of record 2.
  2. A GDS SEND command is used to transmit the second portion of record 2.
  3. A GDS SEND command is used to transmit the remaining portion of record 2, the whole of record 3, and the first portion of record 4.
  4. A GDS SEND INVITE WAIT command is used to transmit the remaining portion of record 4.
This figure shows how GDS SEND commands are used to transmit partial and multiple logical records.
This flexibility also allows you to use separate GDS SEND commands for the GDS header and the application data—a useful technique to avoid shifting data into storage contiguous with its GDS header. The program fragment in Figure 3 uses this technique.
Figure 3. Sending data on an APPC basic conversation
* ...
LA R5,L'SENDHDR+LEN'SENDDATA Compute LL value
STH R5,SENDHDR Place length in LL
LA R5,L'SENDHDR Length of GDS header
ST R5,SENDLEN into send length field
EXEC CICS GDS SEND FROM(SENDHDR) FLENGTH(SENDLEN) *
CONVID(WCONVID) RETCODE(WRETC) *
STATE(WSTATE) CONVDATA(WCDB)
*
* ... Check outcome of the SEND
* ...
LA R5,L'SENDDATA Length of application data
ST R5,SENDLEN into send length field
EXEC CICS GDS SEND FROM(SENDDATA) FLENGTH(SENDLEN) *
CONVID(WCONVID) RETCODE(WRETC) *
STATE(WSTATE) CONVDATA(WCDB)
*
* ... Check outcome of the SEND
* ...
EXEC CICS GDS SEND INVITE WAIT *
CONVID(WCONVID) RETCODE(WRETC) *
STATE(WSTATE) CONVDATA(WCDB)
*
* ... Check outcome of last command
* ...
*
WSTATE DS F
WRETC DS XL6
WCDB DS 0CL24
COPY DFHCDBLK
WCONVID DS CL4
SENDDATA DS CL100
SENDLEN DS F
SENDHDR DS H
* ...

The records from a simple GDS SEND command are initially stored in a local CICS buffer which is “flushed” either when this buffer is full or when the transaction requests transmission. The transaction can request transmission either by using a GDS WAIT command or by using the WAIT option on the GDS SEND command. The reason transmission is deferred is to reduce the number of calls to the network. However, the application should use GDS WAIT if the partner transaction requires the data to continue processing.