Note that in this section and the following sections, designation S41 refers to the Alfaskop System 41 complete with all of its components.
)
(
(
(
(~J Remote Operation - SNA/SDLC 13
The following sessions must be established between the host system and the S41 in order for information to be exchanged:
• SSCP-PU (access method - S41 physical unit (PU))
• SSCP-SLU (access method - S41 SLU)
• PLU-SLU (host program - S41 SLU)
Moreover, a session must be established between SSCP-PLU (access method - host program). The third type of session listed above is fre-quently referred to as the LU-LU session. PLU means primary logical unit and SLU means secondary logical unit.
The above sessions are discussed in the sections which follow. These sections also present the SNA commands that establish and terminate the sessions and explain how the sessions are established and terminated. The section headed Command Description presents the SN A commands in considerable detail.
SSCP-PU Session
The physical connection to the host must be establish~d before the SSCP-PU session is established. The SSCP-PU session must be the first session that is established between the S41 and the host system. When the S41 is activated by the network operator, the SSCP issues the Activate Physical Unit (ACTPU) command to the communication processor.
Moreover, a predefined SSCP start procedure can request the activation of specific communication processors.
The network operator can deactivate the S41 and terminate the SSCP-PU session. Then the SSCP issues the Deactivate Physical Unit (DACTPU) command when all SSCP-LU sessions for the communication processor in question have been terminated. The SSCP-PU session is considered ter-minated when the S41 sends a positive response to the DACTPU com-mand.
SSCP-SLU Session
After the SSCP-PU session has been established, an activate command can be issued to the SSCP calling for the establishment of the SSCP-SLU session. An Activate Logical Unit (ACTLU) command is issued by the SSCP for the proper SLUes) in the S41.
The SSCP-SLV session must be established before the LV-LV session is established.
The SSCP-SLU session is terminated when a Deactivate Logical Unit (DACTLU) command is sent to the associated SLU. The SSCP-SLU ses\sion is terminated when the S41 sends a positive response to the DACTLU command.
14 Remote Operation - SNA/SDLC [~)
PLV -SLV (LV -L V) Session
Fig. 5 presents the command flow sequence that is needed to establish an L U -L U session. Generalized nomenclature is used in this illustration. In this example, it is assumed that none of the sessions have been active between the S41 and the host. The SSCP issues the ACTPU command to establish the SSCP-PU session (A in illustration). Then, ACTLV com-mands (B) are sent to establish the SSCP-LV sessions. The host applica-tion can establish the SSCP-PL U session at any time prior to logon.
Host System S41
Host SSCP
® ACTPU (SSCP-PU) Physical
Application (Access Unit
I I
Program Method) Display
ACTLU or
Fig. 5. Establishing a session with an S41
The display terminal operator (C) can initiate the LV-LV session (charac-ter coded logon) or the host application program can initiate it (using a session request, an SNA Bind (F) command is sent to the SLU.
The S41 LV checks the session parameters in the Bind command and (if they are approved) permits the session to be established. This is accomp-lished by sending a positive response (G) to the Bind command. However, in the event that the session parameters cannot be approved, or if power to the device is not turned on, the S41 L U rejects the Bind command. This is accomplished by sending a negative response which indicates the reason for rejection. The table of Bind parameters in Appendix 5 presents the Bind parameters that can be specified for an S41 session. The host pro-gram can issue the Start Data Traffic command after the Bind command has been approved. This will permit data traffic to start flowing for the session.
)
)
(
(
(
(
[~l Remote Operation - SNA/SDLC 15
If the LV-LV session is a type 1 session or type 3 session, it must be initiated by the PLU. However, if it is a type 2 session, it can be initiated by either the PLV or the SLV.
Termination of an LV-LV Session
An LV-LV session can be terminated by having the PLV request that the SSCP close the session. After this request has been issued, the SSCP forwards the V nbind command to the secondary L U, thus terminating the LV-LU session.
The terminal operator can terminate a type 2 session in two ways:
a) by notifying the PLV participating in the session that termination is desired, whereupon the PLV terminates the session; or
b) by changing over from the LU-LU session to an SSCP-SLU session by depressing the SYREQ key and then entering a logoff message. If this logoff message is conditional, the logoff request is sent to the PL V by the SSCP. If the logoff message is unconditional, an Unbind command is issued for the PL V.
The session can be closed by having the PL V issue a Shutdown command.
When the PLU issues the Shutdown command, the S41 replies with the Shutdown Complete command after any outstanding operation has been completed, providing that there are no unclosed brackets.
Profiles and Usage Fields
Several parameters are sent to the S41 together with the ACTPU, ACTLU and Bind commands. These parameters specify operations within the sessions and they are presented in Appendix 5.
The resources and functional capabilities of a physical or logical unit (e.g.
the capability to handle commands) which are to be used in a session are grouped in profiles. The profiles are assigned numbers so that they can easily be specified in the parameters. Other parts of the parameters which are used to further qualify or select functions are called usage fields. The profiles and the usage fields are related to the sublayers where the various functions are supported.
For operation of the presentation services sublayer, the PS profile and usage field specify the following (among other things)
" LV Type
" Screen (or buffer) size
,
.
16
Headers
Remote Operation - SNA/SDLC [~l
For operation of the data flow control sublayer, the FM (function man-agement) profile and usage field specify the following (among other things)
• Supported DFC commands
• Request and response modes
• Chaining and bracket rules
• Forms of responses
• Data flow protocol
For operation of the transmission control sublayer, the TS (transmission subsystem) profile and usage field specify the following (among other things)
• RU size
• Pacing
It Sequence numbering
It Supported SC commands
Each segment sent to or from the S41 is provided with a 6-byte TH. Each request and each response sent to or from the S41 is provided with a 3-byte RH, which is sent in the first segment if the RU is segmented. In the following description, some bits define unused fields or are not used. Bits which are not used are handled by the S41 as follows
• They are not checked on reception
• They are sent in a response just as they were received in the associated request
• They are set to zero in a request
Transmission Header (TH)
The format of the TH and an explanation of its contents appear in Fig. 6.
The addresses of the displays or printers (each device is represented by an L U) and the address of the PU of the communication processor are listed in Table 1. These addresses appear in DAF for outbound segments and in OAF for inbound segments. The SSCP in the host is identified using address 0 in OAF for outbound segments and in DAF for inbound seg-ments.
(
FID MPJ= ~ Destination Origin Address Sequence Number Field (SNF) .. ~ FI Unused field Address Field (DAF) Field (OAF) ... I - - - -__ .~
Fig. 6. Transmission header format
Each request sent during normal flow in an L U -L U session must be provided with a sequence number. The sequence number is initialized to zero (after the Start Data Traffic command) and is incremented by one before a new request is sent. Two individual sequence numbers are used:
one for outbound flow requests and one for inbound flow requests. All segments of one request have the same sequence number. Each request in a chain has its own sequence number. The sequence number for a re-sponse must be the same as the number used for the associated request.
Each request sent during expedited flow or in sessions other than LU-LU sessions is assigned an identifier number rather than a sequence number.
Any number can be used as an identifier.
Table 1. Device addressing for Alfaskop System 41 terminals
Device Device Address Field Number Bits: 7 6 5'432 1 0
"Note: IBM designates the most significant bit (Bit No.7) as No. O.
**Unused address.
18 Remote Operation - SNA/SDLC [~I
Request/response Header (RH)
Byte No.
Both the request header and the response header contain these bytes, but the meanings of some bits differ. Figs. 7 and 8 present the meanings of all bits in the request header and response header respectively.
o 2
RU F
~ ~ I ~ ~ ~
cat. I I I 1 2 I
I I I I I I I I I I I I I I
pi
~ ~ g I
I I I I I I I I I