No provision is included in CCITT recommendations to allow bisynchronous (BSC) 3270 terminals to communicate through an X.25 network, however a large number of these terminals are in use. So in 1980/81 GTE Telenet, Transcanada Telephone, Tymnet and Comtan Developed the 3270 Display System Protocol (DSP). A PAD (packet assemller-disassembler) connected to a BSC 3270 type device communicates over the packet switched network with another PAD connected to a host computer. The protocol defines the communication between the two PADs, it is carried above the X.25 level 3 layer and so it could be called a level 4 protocol although it is not compatible with the OSI Transport layer.
1 - BSC 3270 related protocols
Host Terminal
Protocol PSS Protocol
Convertor ............... Convertor
Host ---------- . . ---------
Computer | | . . | | 3270
------- | | . . | | ---------
| | | | . . | | | |
| | | | . . | | | |
|HOST +-| PAD +----. PACKET .-----| PAD +--- CU |
| | | | . SWITCHING . | | | |
+-------| +----------| ................. +---------| +---------|
|
| --
+-| \--
| +-----|
| --
+-| \--
| +-----|
| --
+-| \--
+-----|
<--------------3270 control stream ------------------------>
<----DSP -------------------------->
<-- BSC ---><----X.25 -------------------------><-- BSC -->
I have further information on the following,
IBM-BSC.TXT Binary Synchronous Communications
IBM-DSP.TXT Display System Protocol
IBM-DS.TXT 3270 Datastream
IBM-SNA.TXT Systems network Architecture
IBM-GTE.TXT Telenet 3010 PAD
IBM-PAR.TXT Telenet 3010 Parameters
IBM-TRI.TXT Information on the 3270 BSC Trial
IBM-PLAN.TXT Information on BT use of IBM protocols
see also following documents:
DSP2
DSP and SNA
2 - introduction
The DSP protocol is designed to make efficient use of the X.25 network, therefore BSC polling is not carried over the network, this would be inefficient and expensive, instead the terminal PAD "appears" as a host computer to the 3270 CU providing all the BSC polling and storing the messages locally. Also the host PAD "appears" as a terminal, the two PADs then communicate using DATA packets so that the users do not need to know a packet switching network is being used. Both control information and data is sent in DATA packets, but control information is distinguished by sending it between the two PADs in DATA packets with the Q bit set to one.
3 - Fixed class configuration (Conection Request Mode 1)
Since the host can be connected to many Control Units (CU) and each control
unit can be connected to many devices, different configurations are possible.
The simplest method is called a fixed class configuration and is is identified
in the CALL REQUEST packet by setting the Connection Request Mode (CRM) to 1,
in this mode the host addresses the Control Units and the devices as if they
were connected locally, no translation is done by the PADs, either the devices
could be connected over the same X.25 call or each device could have its own
logical channel. This method is less flexible in that control units at different
sites cannot connect to the same host and the same control unit cannot be connected
to many hosts.
Hos ---------- ---------
Computer | | | | 3270
------- | | | | ------- -------
| | | | | | | | | |
| | | HOST | PSS | TERMINAL| | | | |
|HOST +-| PAD |.........| PAD +---| CU 40 +---| CU C1 |
| | | | | | | | | |
+-------| +----------| +---------| +-------| +-------|
. | |
. | -- | --
. +-| \-- +-| \--
| +-----| | +-----|
............................. 4040 C140
. ------- ------- . | -- | --
. | | | | . +-| \-- +-| \--
. | | | | . | +-----| | +-----|
40C1 C1C1
..| CU 40 +---| CU C1 | . | -- | --
. | | | | . +-| \-- +-| \--
. +-------| +-------| . +-----| +-----|
40C2 C1C2
. | | .
. | -- | -- .
. +-| \-- +-| \-- .
. | +-----| | +-----| .
4040 C140
. | -- | -- . Configuration Table
. +-| \-- +-| \-- . exact replica of control unit
. | +-----| | +-----| . configuration
40C1 C1C1
. | -- | -- .
. +-| \-- +-| \-- .
. +-----| +-----| .
40C2 C1C2
.............................
Fixed Line Configuration
4 - Non-fixed Lines
This allows calls from terminals that are configured differently than the
configuration table in tost PAD, two types can be used:
Specific calls (Connection Request Mode 2)
A specific call is a call to a logical device that will only accept calls
from physical devices that correctly specify the logical device's address. This
is usually done for security reasons.
Non-specific calls (Connection Request Mode 3)
A non-specific call is a call in which no specific logical device is requested. When a non-specific call is received, the host PAD will assign one non-specific device from the pool to handle the call. The call will only be rejected if all non-specific devices on the line are busy.
5 - Making the Call
Either the Host end PAD or the terminal end PAD can establish the X.25 connection.
The call user data field of the all request packet must be set correctly to
specify information about the call, this will be validated by the PAD at the
distant end and if and if it is not valid it will clear the call.
Call Request Packet - User Data Field
Byte Bit
0 1 2 3 4 5 6 7
----------------------------------------------------------------
0 | Protocol ID 56=Host initiated 57=Remote terminal initiated |
---------------------------------------------------------------
1 | Source CUA (Source Control Unit Address) |
----------------------------------------------------------------
2 | Source DVA (Source Device Address) |
----------------------------------------------------------------
3 | CR | SM | TT | EA | Device Format size | DP |
|follow |Single/|Transp |EBCDIC/| No of chrs |Display/|
|on data|multipl|Text |ASCII | |Printer |
----------------------------------------------------------------
4 | reserved |att ptr|colour | character set |
----------------------------------------------------------------
5 | Connection request mode (CRM) | |
| | CRM=1 | CRM=2 | CRM=3 | CRM=4 |
----------------------------------------------------------------
6 | Destination |-- Application Identifier --- | 00 |
----------
| Designators |Destination controller| 00 |
| (n Bytes) | Destination device |
----------------------
| | additional|
5+n | | 4 Bytes |
----------------------------------------------------------------
6+n | |
| Reserved (m Bytes) |
. | |
15 | |
+----------------------------------------------------------------|
Abbreviations in call request packet
Value | Description | |
CR | 0=all information for call | 1=further information for session |
establishment is contained in the | establishment is contained in a | |
user data field of the call | CIRCUIT REQUEST message | |
request packet. | ||
SM | 0=single user circuit request | 1=multiple user circuit request |
TT | 0=request is for a 3270 device | 1=request is for a 3270 device |
that does not support transparent | that supports transparent text | |
text | ||
EA | 0=request is for an EBCDIC device | 1= request is for an ASCII device |
Device =000 480 characters | ||
Format =001 960 characters | ||
Size =010 1920 characters | ||
=011 2560 characters | ||
=100 3440 characters | ||
DP | 0=call setup for a display device | 1=call setup for a printer device |
att pntr | 0=device has no attached printer | 1=device has an attached printer |
colour | 0=device does not support colour | 1=device supports colour (extended attributes) |
char set=000 | none | |
char set=001 | APL capability | |
char set=010 | text capability | |
char set=011 | APL and text capability | |
CRM | Connection Request Mode | |
=1 Fixed caass CRM - The controller and device addresses are | ||
the same as the physical terminal configuration. Therefore | ||
the destination CU and device is the same as the source CU | ||
and device. | ||
=2 Specific call CRM - The terminal PAD provides the | ||
destination terminal address to the host that will be used | ||
for the session. | ||
=3 Non-Specific class CRM - The host PAD provides the | ||
destination terminal address at call setup time. This the | ||
address that is assigned to the terminal for the session. ie | ||
if one device is busy then the next device can be allocated | ||
(contention) | ||
=4 Associated Device CRM - This CRM is used to associate the | ||
terminal requesting another device connection with that | ||
device. It provides the host PAD with the necessary | ||
information so both the connection requesting and the | ||
requested devices can be associated to the same controller | ||
unit and application at the host. | ||
destination Depends on CRM - data defining the PAD to PAD mapping
designators relationship
6 - Data Transfer
All information is sent through the network in DATA packets. Data sent by
the terminal (usually in response to a poll) is defined as a RESPONSE. Data
sent by the Host (usually on a select) is defined as a COMMAND. T data messages
have the Q-bit=0 to distinguish them from control messages.
The M-bit is set when the length of a message is longer than the data field
in the X.25 packet being used to indicate that the data is being continued in
the next packet.
On the BSC side of the PAD the RESPONSES and COMMANDS are acknowledged when received. Note that the acknowledgement is sent before the other PAD has transmitted the RESPONSE or COMMAND to the host or terminal respectivly. The pre-acknowledgement of RESPONSES and COMMANDS decouples the host operation from the terminal operation. Operation in decoupled mode makes the transmission through the network transparent to the host or terminal. However, the decoupled operation aay complicate error recovery.
7 - Host to Terminal Data Transfer (COMMANDS)
A command message is a sequence of X.25 data packets (Q=0) linked together
via the More data bit convention (M-bit). The first packet contains the COMMAND
header.
COMMAND message Q bit=0
0 1 2 3 4 5 6 7
-----------------------------------------------------------------
0 | 0 | user circuit number |
-----------------------------------------------------------------
1 | LCM | ACK XPR | 0 | 0 | 0 | 0 | 0 |
|limited |expecte|contain| | | | | |
|conversa| |transpa| | | | | |
|response| |line | | | | | |
|expected| | code | | | | | |
-----------------------------------------------------------------
2 | sequence number |
-----------------------------------------------------------------
3 | ESC |
-----------------------------------------------------------------
4 | command code - start of 3270 data stream |
5 data... |
| |
-----------------------------------------------------------------
N | ETB - end of block text continued in next block |
| or ETX - end of transmission |
| or ENQ - forward abort |
+-----------------------------------------------------------------|
Where-
User Circuit Number - zero for all single user circuits. Optionally the user
circuit number can select up to 128 individual 3270 devices on a single virtual
circuit.
LCM | 0=No limited conversational | 1=Limited conversational |
response expected | response expected | |
If the LCM (Limited Conversational Mode) bit is set on a command then | ||
a response is expected with the LCM bit set. This indicates that, on | ||
the BSC part of the link, the response can replace the ACK for the | ||
command (see IBM-BSC.TXT Martin Baker) | ||
ACK | 0=No acknowledgement (ACK) | 1=Delivery of this message must be |
message expected | acknowledged with ACK message | |
XPR | 0=This message does not | 1=This message contains transparent |
contain transparent line code. | line code. | |
(for information on transparent line code see IBM-BSC.TXT Martin Baker) |
sequence number - The sequence number allows the receiver to detect missing
or out of order messages. It is set to ONE following a
circuit enable message
Data - It begins with ESC and ends with ETX or ETB (use of forward abort -
the data will end with an ENQ)
8 - Terminal to Host data transfer (RESPONSE)
Data is sent from the terminal in blocks up to 256 bytes each ending in ETB
except the last which ends in ETX. The first segment contains the RESPONSE message
header with FS=0. All subsequent segments contain a header with only the circuit
number and FS=1
RESPONSE message - first block - Q bit=0
0 1 2 3 4 5 6 7
-----------------------------------------------------------------
0 | FS=0 | user circuit number |
-----------------------------------------------------------------
1 | LCM | ACK | XPR | TRQ | 0 | 0 | 0 | 0 |
|limited |expecte|contain| test | | | | |
|conversa| |transpa|request| | | | |
|response| |line | | | | | |
|expected| | code | | | | | |
-----------------------------------------------------------------
2 | sequence number |
-----------------------------------------------------------------
3 | data... |
| |
-----------------------------------------------------------------
N | ETB - end of block text continued in next block |
| or ETX - end of transmission |
| or ENQ - forward abort |
+-----------------------------------------------------------------|
RESPONSE message - subsequent blocks - Q bit=0
0 1 2 3 4 5 6 7
-----------------------------------------------------------------
0 | FS=1 | user circuit number |
-----------------------------------------------------------------
1 | data... |
+----------------------------------------------------------------|
N | ETB - end of block text continued in next block |
| or ETX - end of transmission |
| or ENQ - forward abort |
+-----------------------------------------------------------------|
Where-
User Circuit Number - zero for all single user circuits. Optionally the user
circuit number can select up to 128 individual 3270 devices on a single virtual
circuit.
FS | 0=Indicates the first block | 1=Indicates a response block |
of a response sequence | other than the first | |
LCM | 0=No limited conversational | 1=Limited conversational |
response expected | response expected | |
ACK | 0=No acknowledgement (ACK) | 1=Delivery of this message must be |
message expected | acknowledged with ACK message | |
XPR | 0=This message does not | 1=This message contains transparent |
contain transparent line code. | line code. | |
TRQ | 0=Message is a data response | 1=Message is a test request |
sequence number - The sequence number allows the receiver to detect missing
or out of order messages.
Data - It begins with ESC and ends with ETX or ETB (use of forward abort - the data will end ith an ENQ)
9 - Control Message summary
Here is a summary of the control messages, they are explained in detail on
the following pages, all these messages have Q-bit=1.
byte 0 1 2 3 4 5 6
------------------------
Invitation to clear | 0 | 01 | Reason |
----------------------------------------------
command/response | user | 10 | Sequence| Error | S/S | S/S |
undelivered | circuit | | number | code | byte | byte |
| number | | | | 0 | 1 |
---- ---------------------
command/response | | 11 | | LCM | S/S | S/S |
aborted | | | | error | byte | byte |
| | | | code | 0 | 1 |
---- -------------------------------
status message | | 12 | S/S | S/S |
| | | byte | byte |
| | | 0 | 1 |
----------------------
ACK message | | 14 | Sequence|
| | | number |
----------------------------------------------------
Circuit Enable | | 20 | Source | Source| as call user data field
| | | CUA | DVA |
-------------------------------------------------
Circuit reset | | 21 |Response |command|Reason|
| | |sequence |sequenc|code |
| | | number |number | |
----------------------------------------------------
Circuit request | | 22 | Source | Source| as call user data field
| | | CUA | DVA |
----------------------------------------------------
Circuit Disconnect | | 24 | Reason |
message | | | code |
------------------------
10 - INVITATION TO CLEAR message
Either the terminal or host PAD may equest that the other end of the call
initiate an X.25 Clear Request. This is done by transmitting the following DATA
packet with Q=1 over the call. Its use ensures that a CLEAR REQUEST packet does
not destroy data packets still in progress through the network.
byte (HEX) | value (HEX) | Q=1 |
0 | 0 | |
1 | 1 (message ID) | |
2 | Reason |
11 - COMMAND/RESPONSE UNDELIVERED message
If the host PAD requires positive confirmation that a COMMAND has been successfully
received by the device, the ACK-bit should be set in he COMMAND message. If
the acknowledgement cannot be obtained then a COMMAND UNDELIVERED message is
sent, this is sent as a DATA packet with the Q-bit=1 and coded as follows:
byte (HEX) | value (HEX) | Q=1 |
0 | user circuit number | |
1 | 10 (message ID) | |
2 | Sequence number | |
3 | Error code | |
4 | S/S byte 0 | |
5 | S/S byte 1 |
Error codes -
Value (HEX) | MNEMONIC | DESCRIPTION |
01 | EOT | Message undelivered due to receipt of EOT |
02 | RVI | age undelivered due to receipt of RVI |
03 | FF | Facilities Failure detected |
04 | TIMEOUT | Failure to respond to message |
05 | NAK | Message undelivered due to receipt of NAK |
06 | WACK | Message undelivered due to receipt of WACK |
07 | Reserved | |
08 | INVALID | Unrecognizable message format |
09 | UR | Unrecognizable Response from terminal |
S/S bytes - see M.J.Baker IBM-DS.TXT for meaning of S/S bytes
12 - COMMAND/RESPONSE ABORTED message
When the host is transmitting COMMANDS which exceed the host PAD defined X.25
packet size, the host PAD implementation may initiate packet transmission of
a COMMAND through the network before full receipt of the host COMMAND is completed.
The Forward Abort mechanism allows the host PAD to indicate an abort of the
packet sequence before all packets have been transmitted.
byte (HEX) | value (HEX) | Q=1 |
0 | user circuit number | |
1 | 11 (message ID) | |
2 | Sequence number | |
3 | LCM Error code | |
4 | S/S byte 0 | |
5 | S/S byte 1 |
LCM / Error code
LCM=0 Data not set in response to message with LCM-bit set
LCM=1 Data sent in response to message with LCM-bit set
Value (HEX) | MNEMONIC | DESCRIPTION |
03 | FF | Facilities Failure detected |
04 | TIMEOUT | Failure to respond to message |
05 | NAK | Message undelivered due to receipt of NAK |
0A | STE | 3270 device repeatedly sent STX... SUB... ENQ sequence due to terminal related problem |
S/S bytes - see M.J.Baker IBM-DS.TXT for meaning of S/S bytes
13 - STATUS MESSAGE
If a status message is received from the terminal, the terminal PAD action
may depend on the context. If the status is not device end (DE), the two Status/Sense
(S/S) bytes will be placed into a STATUS message and sent to the host PAD.
byte (HEX) | value (HEX) | Q=1 |
0 | user circuit number | |
1 | 12 (message ID) | |
2 | S/S byte 0 | |
3 | S/S byte 1 |
S/S bytes - see M.J.Baker IBM-DS.TXT for meaning of S/S bytes
14 - ACK MESSAGE
If the host PAD requires positive confirmation that a COMMAND has been successfully
received by the device, the ACK-bit should be set in the COMMAND message. A
successful acknowledgement is sent as an ACK message, this is sent as a DATA
packet with the Q-bit=1 and coded as follows:
byte (HEX) | value (HEX) | Q=1 |
0 | user circuit number | |
1 | 14 (message ID) | |
2 | Sequence Number |
15 - CIRCUIT ENABLE message
On an operator call request, the terminal PAD will generate a CALL REQUEST
packet, if the host can accept the call it will return a CALL ACCEPT packet
followed by a CIRCUIT ENABLE message. The transmission and reception of the
CIRCUIT ENABLE message implies the resetting of the COMMAND and RESPONSE sequence
numbers so that the next message sequence number expected will be ONE. With
the receipt of the CIRCUIT ENABLE message, the terminal PAD will specific poll
the device and subsequently forward a status message to the host.
Q bit=1
0 1 2 3 4 5 6 7
-------------------------------------------------------------------
0 | user circuit number |
-------------------------------------------------------------------
1 | message ID = 20 |
-------------------------------------------------------------------
2 | Source CUA |
-------------------------------------------------------------------
3 | Source DVA |
-------------------------------------------------------------------
4 | 0 | 0 | TT | EA | Device format size | DP |
-------------------------------------------------------------------
5 | reserved |att ptr|colour | character Set |
------------------------------------------------------------------
6 | connection request mode (CRM) |
-------------------------------------------------------------------
7 | Application ID |
-------------------------------------------------------------------
8 | Destination CUA |
-------------------------------------------------------------------
9 | Destination DVA |
-------------------------------------------------------------------
10 | |
11 | additional destination designator information |
12 | |
13 | |
+-------------------------------------------------------------------|
16 - CIRCUIT RESET message
Following an X.25 Reset sequence, the Terminal and Host PAD's should exchange
CIRCUIT RESET messages (level 4 reset). In the case of multiple user circuits
these should be exchanged for each user circuit active. The RESPONSE and COMMAND
sequence numbers to be used are those of the next expected RESPONSE or COMMAND
byte (HEX) | value (HEX) | Q=1 |
0 | user circuit number | |
1 | 21 (message ID) | |
2 | Response sequence number | |
3 | Command Sequence number | |
4 | Reason code |
Reason Codes
Value (HEX) | Description |
0 | undefined |
10 | unidentified DQ packet |
11 | sequnce error detected at level 4 |
12 | invalid DQ format |
13 | invalid data packet format |
17 - CIRCUIT REQUEST message
For Multiple User Circuits over one X.25 call then a CIRCUIT REQUEST is required
to establish each logical connection. Each user circuit is assigned a unique
user circuit number.
Q bit=1
0 1 2 3 4 5 6 7
----------------------------------------------------------------
0 | user circuit number |
----------------------------------------------------------------
1 | message ID = 22 |
---------------------------------------------------------------
2 | Source CUA |
----------------------------------------------------------------
3 | Source DVA |
----------------------------------------------------------------
4 | 0 | 0 | TT | EA | Device format size | DP |
----------------------------------------------------------------
5 | reserved |att ptr| colour| character Set |
----------------------------------------------------------------
6 | connection request mode |
----------------------------------------------------------------
7 | |
. | Destination Designators (n bytes) |
6+n| |
+----------------------------------------------------------------|
18 - CIRCUIT DISCONNECT message
If multiple user circuits are being used on one X.25 call and only an individual
user circuit is to be disconnected then a CIRCUIT DISCONNECT message is used.
Byte (HEX) | value (HEX) | Q=1 |
0 | user circuit number | |
1 | 24 (message ID) | |
2 | Reason Code |
Reason Codes | |
v (hex) | description |
0 | undefined |
1 | user initiated |
1 | unidentified DQ packet |
1 | invalid state transition |
1 | invalid DQ format |
1 | invalid data packet format |
2 | timeout |
2 | facility failure |
19 - Sample Traces
The following traces were taken Using a Telenex Autoscope tee'd in to an IBM
PC connected to a Telenet 3006 making a call to a Tandem computer acting as
a host (Mediat).
emulated on IBM PC PSS Mediat
................... .......... ....................
. . . . . .
. terminal 3274 . ------ . . . .
. - ---- . | |X.25. . . .
. -/ +-| +-.-| 3006 +----..........--. Tandem .
. +---| +----| . +------| | . . . Host .
. . | . . . .
................... | .......... ....................
|
---+-----
| |
| our |
| tester |
+---------|
The trace is read as follows:
timestmp hex coding of
| X.25 data including all
| level 2 and 3 except
| FCS and flags
| |
v v
from term to host - High BCD --> FF14:58:5808100E2
low BCD --> FF 164EBE3
from host to term - High BCD --> FF FFFFFFF
low BCD --> FF FFFFFFF
-------------------
The trace shows following events on the line:
- X.25 call request packet
- X.25 call conf packet
- CIRCUIT ENABLE message
- RR packet
- SS MESSAGE
- RR packet
- RESPONSE message
- RR packet
- COMMAND message
- RR packet
- CLEAR REQUEST packet
- CLEAR CONFIRMATION packet