SSCP Session Characteristics

For SNA type 2.1 nodes, the SSCP session uses FM (function management) profile 0 and TS (transmission service) profile 1. This combination of profiles gives the following session characteristics:

• The primary and secondary half-sessions both use immediate request mode.
• The primary and secondary half-sessions both use immediate response mode.
• Only definite-response single RU chains are allowed.
• The maximum RU size is limited to 256 bytes.
• DFC RUs are not supported.
• Pacing is not supported.
• Identifiers are used (rather than sequence numbers) on the normal flows.

This implies that the SSCP connection has the following characteristics:

• All Data messages have the ACKRQD (acknowledgment required) field set.
• All Data messages have the BCI (begin chain indicator) and ECI (end chain indicator) application flags set.
• Status-Control messages do not flow on the connection.
• Status-Session messages from the local node to the application only report changes in the activation state of the session.
• The chaining, bracket, confirmation, and recovery protocols (described in The PLU Connection) do not apply.

Using the SSCP connection, the application can send and receive Data messages corresponding to FMD NS (function management data network services) (session services) requests and FMD data requests. Examples of FMD NS (session services) requests are:

• INIT-SELF: Requests from the secondary to the host SSCP requesting that the SSCP assist in the initiation of a session to the host PLU, effectively requesting a BIND (see Opening the PLU Connection).
• TERM-SELF: Requests from the secondary to the host SSCP requesting that the PLU-SLU session be terminated with an UNBIND (see Closing the PLU Connection).
• Character-coded requests: Requests such as logon, logoff, or test commands from the secondary display, or a logon prompt from the host application.
• NOTIFY: Requests used by the secondary to notify the host SSCP that a device is available after a BIND was rejected with sense code 0x0845; for example, where a device emulator supports logical power-off.

The local node sends a NOTIFY request to the SSCP on behalf of the LU whenever the application's SSCP connection state changes while the LU is active. A NOTIFY (vector key 0x0C with byte 5 set to 0x03), which can act as secondary LU, is sent in the following cases:

• When an Open(SSCP) Request is received when the LU is already active.
• When an ACTLU request is accepted when the SSCP connection is already opened.

A NOTIFY (vector key 0x0C with byte 5 set to 0x01), which cannot currently act as secondary LU, is sent in the following cases:

• When an ACTLU is received when the SSCP connection is not open.
• When a Close(SSCP) Request is received when the PLU session is not bound.
• When an UNBIND request is received when the SSCP connection is not open.
• In addition, the long response including the NOTIFY vector is used to ACTLU requests.

These NOTIFY messages can be used by the host in conjunction with the negative response 0x0845 that the local node gives to a BIND received when the SSCP connection is not open (see Opening the PLU Connection).