Verbs and Built-in Functions › &APPC SEND_DATA

&APPC SEND_DATA

&APPC SEND_DATA sends a single data record to the remote conversation partner.

This verb has the following format:

&APPC{ SEND_DATA | SEND }
     [ ID=id ]
     [ MDO=mdoname [ MAP=mapname ] |
       VARS=var | VARS=(var1, var2, ..., varn ) |
       VARS=prefix* [ RANGE=(start,end) ] ]
     [ CONT={ YES | NO } ]

Operands:

SEND_DATA

Indicates this is a conversation request to send data to the remote conversation partner.

ID=id

Specifies the conversation identifier (as first returned by the system variable &ZAPPCID after successful allocation) that references a particular conversation. If this parameter is omitted, the current (last referenced, or only) conversation is assumed.

MDO=mdoname [ MAP=mapname ] | VARS=var |
VARS=( var1,var2,...,varn ) | VARS=prefix* [ RANGE=(start,end) ]

Specifies the name of the MDO (which is an element or field) or variables to be sent as application data on this send request. The named MDO item is extracted and sent as a contiguous byte stream as the data for this send operation.

MAP=mapname nominates the map name to be sent to the remote end. If omitted, but the MDO operand is used, then the fully qualified element (or field) name derived from Mapping Services Mapping Support is assumed as the map name. If omitted, and the VARS operand is used, then MAP=$NCL is assumed (as described for VARS=). No map name is sent if the remote application does not support data mapping. Map names is up to 64 characters long. Valid Mapping Services map names can consist of up to 8 name segments, each of up to 12 characters, and each separated by a period.

The VARS= operand is used to provide the list of NCL variables to be passed to the transaction processor in the remote end for this send operation (the usual NCL VARS definitions apply). If the remote conversation partner supports data mapping, and no map name is supplied, MAP=$NCL is assumed, and the data sent is formatted as a series of vectors, one per token referenced. If some other map name is used, or the conversation partner does not support data mapping, then all tokens are concatenated together to form the data contents to be sent to the other end.

CONT={ YES | NO }

Applies to OPERTYPE=GDS conversations only, and indicates whether the current GDS variable is to be continued with the next send. If CONT=NO is specified (or defaulted), the current send is the last or only logical record sent for the GDS variable. CONT=YES indicates that the continuation bit is to be set in the current logical record.

Example: &APPC SEND_DATA

SEND_DATA VARS=DATA

Return Codes:

The return codes are as follows:

0

Request successful

4

Request unsuccessful

8

Remote program error

12

State check

16

Request or conversation error

&ZFDBK is also set, plus all APPC system variables.

State Transition:

The SEND_DATA request can only be issued from send state. No state changes occur as a result of this request.

Note:

This request does not necessarily result in any actual transmission taking place as data is normally buffered within the system until some trigger condition results in session transmission becoming necessary. The FLUSH request is used to ensure data transmission if required.

Relationship to LU6.2 Verb Set:

• &APPC SEND_DATA is equivalent to the LU6.2 verb MC_SEND_DATA.
• The &APPC SEND_DATA operands of VARS and MDO are used in place of the LU6.2 verb SEND_DATA options DATA and LENGTH.
• The &APPC SEND_DATA operand MAP=mapname is equivalent to the LU6.2 verb SEND_DATA option MAP(YES(mapname)).
• The FMH_DATA parameter of the LU6.2 verb SEND_DATA is not supported by &APPC.

More information:

&APPC Return Code Information

&RETCODE and &ZFDBK