|
|
|
|
Basic conversations are generally used by service TPs. Service TPs are programs that provide services to other local programs. They are more complex than mapped conversations but provide an experienced LU 6.2 programmer with a greater degree of control over the transmission and handling of data. This section summarizes the characteristics of basic conversations where they differ from mapped conversations.
In a basic conversation, data is sent in the form of logical records. A logical record is a record that has the general data stream (GDS) syntax described in this section. For more information about GDS syntax, refer to the IBM publication SNA Formats.
The sending TP must format the data into logical records, and the receiving TP must decode the logical records into usable data. A TP can send multiple logical records with a single SEND_DATA verb, or it can send a single logical record in multiple parts (called segments) with multiple SEND_DATA verbs. A TP can receive multiple logical records with a single receive verb (RECEIVE_AND_WAIT, RECEIVE_IMMEDIATE, or RECEIVE_AND_POST), or it can receive a single logical record in multiple parts with multiple receive verbs.
If a logical record is a single record, it consists of the following fields:
A 2-byte record length (LL) field
A 2-byte GDS identifier (ID) field (for example, 0x12FF identifies the data as application data)
A data field that can range in length from 0-32,763 bytes
The first four bytes are called the LLID.
If a logical record has multiple parts, the first part has the same format as a single record, and all subsequent parts consist of the following fields:
A 2-byte record length (LL) field
A data field that can range in length from 0-32,765 bytes
The hexadecimal value for the LL field includes the two bytes for the LL field (and the two bytes for the ID field, if it is present). For example, a single part GDS with no zero bytes of data has a value of 0x0004 for its LL field. The LL field must be in high-low format, rather than byte-swapped format. For example, a length of 230 bytes is represented as 0x00E6, rather than 0xE600.
Bit 0 of byte 0 of the LL (the most significant bit) is used to indicate length continuation (segmentation). The following example shows ten bytes of data (each data byte has the value DD) split into three GDS segments. The first and second segments each contain four bytes of data, and the last segment contains two bytes of data.
8008 12FF DDDD DDDD 8006 DDDD DDDD 0004 DDDD
The following values for the LL field are not valid (except when sending a PS header as described in Sending PS Headers in Logical Records):
0x0000
0x0001
0x8000
0x8001
In a mapped conversation, the sending TP sends one data record at a time, and the receiving TP receives one data record at a time. No record conversion is required of the TPs.
If the conversation's synchronization level is
An LL field of 0x0001 indicates that the data is
a PS Header; the sending application must specify an LL field of
0x0001 instead of specifying the length of the data field, and the
receiving application must interpret the data as a PS Header if it receives
an LL field of 0x0001. If the conversation's synchronization
level is not
(In a mapped conversation, the application does not have access to the LL fields. Instead, it uses the data_type parameter on a MC_SEND_DATA verb to indicate that the data being sent is in the form of a PS Header, or interprets the what_rcvd parameter of a MC_RECEIVE verb to determine that the received data is in the form of a PS Header.)
In a basic conversation, a TP can indicate whether an error or abend (abnormal program termination) was caused by a service TP or by a program using the service TP. This enables two communicating service TPs to distinguish between errors they may have caused and errors that may have been caused by the programs they serve.
In case of an error or abend in a basic conversation, a TP can send an error message, in the form of a general data stream (GDS) error log variable, to the local log and to the partner LU.
In a basic conversation, a TP can indicate whether an abend was caused by a timeout or by a critical error.
|
|
|
 |
|