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:
Figure 17 shows the format of GDS records.
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.
The data to be sent consists of four 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.
* ...
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.
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 ]]