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 17 shows the format of GDS records.

Figure 17. 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 18 is an example of the use of GDS SEND commands.

Figure 18. 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 19 uses this technique.

Figure 19. 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 SEND INVITE WAIT

*         ...
*
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.

Switching from sending to receiving data

To switch from sending to receiving records, use a GDS SEND INVITE command with the WAIT or CONFIRM option. This switches the conversation from send state (state 2) to receive state (state 5). An example of a GDS SEND INVITE WAIT command can be seen in Figure 19. Figure 25 illustrates the response-testing sequence.

For further information on the CONFIRM option, see How to synchronize conversations using CONFIRM commands.

[[ Contents Previous Page | Next Page Index ]]