Telecommunications - 3270 DSP - Display System Protocol

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:

  1. X.25 call request packet
  2. X.25 call conf packet
  3. CIRCUIT ENABLE message
  4. RR packet
  5. SS MESSAGE
  6. RR packet
  7. RESPONSE message
  8. RR packet
  9. COMMAND message
  10. RR packet
  11. CLEAR REQUEST packet
  12. CLEAR CONFIRMATION packet


 


metadata block
see also:

 

Correspondence about this page

Book Shop - Further reading.

Where I can, I have put links to Amazon for books that are relevant to the subject, click on the appropriate country flag to get more details of the book or to buy it from them.

cover The Essential Guide to Telecommunications (Essential Guide).

Commercial Software Shop

Where I can, I have put links to Amazon for commercial software, not directly related to the software project, but related to the subject being discussed, click on the appropriate country flag to get more details of the software or to buy it from them.

 

This site may have errors. Don't use for critical systems.

Copyright (c) 1998-2015 Martin John Baker - All rights reserved - privacy policy.