As per Relevance of the word function, we have this rfc below:
Network Working Group B.
Request for Comments: 1647 Auburn
Category: Standards Track July 1994
TN3270
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document describes a protocol that more fully supports 3270
devices than do the existing tn3270 practices. Specifically,
defines a method of emulating both the terminal and printer
of the 3270 family of devices via Telnet; it provides for the
of a Telnet client to request that it be assigned a specific device
name (also referred to as "LU name" or "network name"); finally,
adds support for a variety of functions such as the ATTN key,
SYSREQ key, and SNA response handling
This protocol would be negotiated and implemented under a new
Option and would be unrelated to the Telnet 3270 Regime Option
defined in RFC 1041 [1].
TABLE OF
1. Introduction ............................................... 2
2. TN3270E OVERVIEW ........................................... 3
3. COMMAND NAMES AND CODES .................................... 4
4. COMMAND MEANINGS ........................................... 5
5. DEFAULT SPECIFICATION ...................................... 6
6. MOTIVATION ................................................. 7
7. TN3270E SUB-NEGOTIATION RULES .............................. 7
7.1 DEVICE-TYPE Negotiation ................................ 7
7.1.1 Device Pools ...................................... 8
7.1.2 CONNECT Command ................................... 9
7.1.3 ASSOCIATE Command ................................. 10
7.1.4 Device Selection Rules ............................ 10
7.1.5 Accepting a Request ............................... 11
7.1.6 REJECT Command .................................... 12
7.2 FUNCTIONS Negotiation .................................. 13
7.2.1 Commands .......................................... 13
Kelly [Page 1]
RFC 1647 TN3270 Enhancements July 1994
7.2.2 List of TN3270E Functions ......................... 14
8. TN3270E DATA MESSAGES ...................................... 15
8.1 The TN3270E Message Header ............................. 16
8.1.1 DATA-TYPE Field ................................... 16
8.1.2 REQUEST-FLAG Field ................................ 17
8.1.3 RESPONSE-FLAG Field ............................... 17
8.1.4 SEQ-NUMBER Field .................................. 18
9. BASIC TN3270E .............................................. 18
9.1 3270 Mode and NVT Mode ................................. 19
10. DETAILS OF PROCESSING TN3270E FUNCTIONS .................... 20
10.1 The SCS-CTL-CODES Function ............................. 20
10.2 The DATA-STREAM-CTL Function ........................... 20
10.3 The BIND-IMAGE Function ................................ 21
10.4 The RESPONSES Function ................................. 22
10.4.1 Response Messages ................................. 23
10.5 The SYSREQ Function .................................... 26
10.5.1 Background ........................................ 26
10.5.2 TN3270E Implementation of SYSREQ .................. 27
11. THE 3270 ATTN KEY .......................................... 28
12. 3270 STRUCTURED FIELDS ..................................... 29
13. IMPLEMENTATION GUIDELINES .................................. 29
13.1 3270 Data Stream Notes ................................. 29
13.2 Negotiation of the TN3270E Telnet Option ............... 30
13.3 A "Keep-alive" Mechanism ............................... 30
13.4 Examples ............................................... 31
14. SECURITY CONSIDERATIONS .................................... 33
15. REFERENCES ................................................. 33
16. AUTHOR'S NOTE .............................................. 34
17. AUTHOR'S ADDRESS ........................................... 34
1.
Currently, support for 3270 terminal emulation over Telnet
accomplished by the de facto standard of negotiating three
Telnet Options - Terminal-Type [2], Binary Transmission [3], and
of Record [4]. Note that there is no RFC that specifies
negotiation as a standard. RFC 1041 attempted to standardize
method of negotiating 3270 terminal support by defining the 3270
Regime Telnet Option. Very few developers and vendors
implemented RFC 1041.
This document will refer to the existing practice of
these three Telnet Options before exchanging the 3270 data stream
"traditional tn3270".
NOTE: Except where otherwise stated, this document does
distinguish between Telnet servers that represent SNA devices
those that represent non-SNA 3270 devices
Kelly [Page 2]
RFC 1647 TN3270 Enhancements July 1994
All references in this document to the 3270 data stream, 3270
stream commands, orders, structured fields and the like rely on [5].
References to SNA Request and Response Units rely on [6].
to SNA versus non-SNA operation rely on [7].
There are several shortcomings in traditional tn3270; among them
the following
- It provides no capability for Telnet clients to emulate the 328
class of printers
- There is no mechanism by which a Telnet client can request
a connection be associated with a given 3270 device-name.
can be of importance when a terminal session is
established, since many host applications behave
depending on the network name of the terminal. In the case
printer emulation, this capability is an absolute
because a large number of host applications have some method
pre-defining printer destinations
- The 3270 ATTN and SYSREQ keys are not universally supported
- There is no support for the SNA positive/negative
process. This is particularly important if printer emulation
to function properly, but is also useful for some
applications. A positive response is used to indicate
the previously received data has been successfully processed
A negative response indicates some sort of error has
while processing the previously received data; this could
caused by the host application building a 3270 data stream
contains an invalid command, or by a mechanical error at
client side, among other things
- There is no mechanism by which the client can access the
Bind information. The Bind image contains a
description of the session between the Telnet server and
host application
- There is no mechanism by which the server can determine
a client supports 3270 structured fields, or a client
request that it receive them
2. TN3270E
In order to address these issues, this document proposes a new
Option - TN3270E. Telnet clients and servers would be free
negotiate support of the TN3270E option or not. If either side
not support TN3270E, traditional tn3270 can be used; otherwise,
Kelly [Page 3]
RFC 1647 TN3270 Enhancements July 1994
sub-negotiation will occur to determine what subset of TN3270E
be used on the session. It is anticipated that a client or
capable of both types of 3270 emulation would attempt to
TN3270E first, and only negotiate traditional tn3270 if the
side refuses TN3270E
Once a client and server have agreed to use TN3270E, negotiation
the TN3270E suboptions can begin. The two major elements of TN3270
sub-negotiation are
- a device-type negotiation that is similar to, but
more complicated than, the existing Telnet Terminal-Type Option
- the negotiation of a set of supported 3270 functions, such
printer data stream type (3270 data stream or SNA
Stream), positive/negative response exchanges, device
information, and the passing of BIND information from server
client
Successful negotiation of these two suboptions signals the
of 3270 data stream transmission. In order to support several of
new functions in TN3270E, each data message must be prefixed by
header. This header will contain flags and indicators that
such things as positive and negative responses and what type of
follows the header (for example, 3270 data stream, SNA
Stream, or device status information).
3. Command Names and
TN3270E 40
ASSOCIATE 00
CONNECT 01
DEVICE-TYPE 02
FUNCTIONS 03
IS 04
REASON 05
REJECT 06
REQUEST 07
SEND 08
Reason-
CONN-PARTNER 00
DEVICE-IN-USE 01
INV-ASSOCIATE 02
INV-DEVICE-NAME 03
INV-DEVICE-TYPE 04
TYPE-NAME-ERROR 05
UNKNOWN-ERROR 06
Kelly [Page 4]
RFC 1647 TN3270 Enhancements July 1994
UNSUPPORTED-REQ 07
Function
BIND-IMAGE 00
DATA-STREAM-CTL 01
RESPONSES 02
SCS-CTL-CODES 03
SYSREQ 04
4. Command
IAC WILL TN3270
The sender of this command is willing to send TN3270
information in subsequent sub-negotiations
IAC WON'T TN3270
The sender of this command refuses to send TN3270E information
IAC DO TN3270
The sender of this command is willing to receive TN3270
information in subsequent sub-negotiations
IAC DON'T TN3270
The sender of this command refuses to receive TN3270
information
Note that while they are not explicitly negotiated, the equivalent
the Telnet Binary Transmission Option [3] and the Telnet End
Record Option [4] is implied in the negotiation of the TN3270
Option. That is, a party to the negotiation that agrees to
TN3270E is automatically required to support bi-directional
and EOR transmissions
IAC SB TN3270E SEND DEVICE-TYPE IAC
Only the server may send this command. This command is used
request that the client transmit a device-type and, optionally
device-name information
IAC SB TN3270E DEVICE-TYPE REQUEST
[CONNECT | ASSOCIATE ] IAC
Only the client may send this command. It is used in
to the server's SEND DEVICE-TYPE command, as well as to
Kelly [Page 5]
RFC 1647 TN3270 Enhancements July 1994
another device-type after the server has sent a DEVICE-
REJECT command (see below). This command requests emulation
a specific 3270 device type and model. The REQUEST command
optionally include either the CONNECT or the ASSOCIATE
(but not both). If present, CONNECT and ASSOCIATE must both
followed by . (See the section
"DEVICE-TYPE Negotiation" for more detailed information.)
IAC SB TN3270E DEVICE-TYPE IS
IAC
Only the server may send this command. This command is used
accept a client's DEVICE-TYPE REQUEST command and to return
server-defined device-name
IAC SB TN3270E DEVICE-TYPE REJECT REASON IAC
Only the server may send this command. This command is used
reject a client's DEVICE-TYPE REQUEST command
IAC SB TN3270E FUNCTIONS REQUEST <function-list> IAC
Either side may send this command. This command is used
suggest a set of 3270 functions that will be supported on
session. It is also sent as an implicit rejection of a
FUNCTIONS REQUEST command sent by the other side (see
section entitled "FUNCTIONS Negotiation" for more information).
Note that when used to reject a FUNCTIONS REQUEST command,
function-list must not be identical to that received in
previous REQUEST command
IAC SB TN3270E FUNCTIONS IS <function-list> IAC
Either side may send this command. This command is sent as
response to a FUNCTIONS REQUEST command and implies
of the set of functions sent to it in the REQUEST command.
that the list of functions in the FUNCTIONS IS command
match the list that was received in the previous
REQUEST command
5. Default
WON'T TN3270
DON'T TN3270
i.e., TN3270E will not be used
Kelly [Page 6]
RFC 1647 TN3270 Enhancements July 1994
6.
See the section entitled "Introduction".
7. TN3270E Sub-negotiation
All TN3270E commands and parameters are NVT ASCII strings in
upper and lower case are considered equivalent
Once it has been agreed that TN3270E will be supported, the
sub-negotiation must concern the DEVICE-TYPE (and possibly DEVICE
NAME) information. Only after that has been successfully
can the client and server exchange FUNCTIONS information. Only
both DEVICE-TYPE and FUNCTIONS have been successfully negotiated
3270 data stream transmission occur
7.1 DEVICE-TYPE
Device-type (and device-name) negotiation begins when the
transmits the DEVICE-TYPE SEND command to the client. The
responds with the DEVICE-TYPE REQUEST command, which must
a device-type and may include a device-name request
Valid device-types are
terminals: IBM-3278-2 IBM-3278-2-E (24 row x 80 col display
IBM-3278-3 IBM-3278-3-E (32 row x 80 col display
IBM-3278-4 IBM-3278-4-E (43 row x 80 col display
IBM-3278-5 IBM-3278-5-E (27 row x 132 col display
IBM-DYNAMIC (no pre-defined display size
printers: IBM-3287-1
Note that the use of '3278' and '3287' is NOT intended to
any particular device capabilities; they are used here
because they are commonly known designations for a terminal and
printer member of the 3270 family of devices. The intention is
simplify the device-type negotiation (in comparison to
tn3270) by minimizing the number of possible device-types, and
breaking the association of a specific piece of IBM hardware
a related set of data stream capabilities. For example
negotiation of device-type IBM-3278-2-E does NOT in and of
preclude the use of any of the functions associated with
physical 3279 model S2B. A client's ability to support the
advanced functions of the 3270 data stream will be indicated
by negotiation of an IBM device type and model number, but
by the combination of Read Partition Query and Query Reply
Kelly [Page 7]
RFC 1647 TN3270 Enhancements July 1994
All of the terminal device-types support a "primary" display
of 24 rows by 80 columns. The "-3", "-4" and "-5" types
support an "alternate" display size as noted in the above list
The IBM-DYNAMIC device-type implies no pre-defined
display size; this value will be passed from the client to
applications as part of the Query Reply structured field, and
can represent any display size the client and the host
can support
Terminal device-types with the "-E" suffix should only
negotiated by clients that are willing to support some subset
the 3270 "extended data stream". This usually includes at
minimum support for extended colors and highlighting, but may
include a number of other functions, such as graphics capability
alternate character sets, and partitions
Clients that negotiate a terminal device-type with the "-E"
or the DYNAMIC type, as well as those that negotiate a
device-type, must be able to accept and respond to a
Partition Query command (see the section entitled "3270
Fields"). This allows the client to indicate to host
which subsets of the 3270 extended data stream the client
willing to support
In a VTAM/SNA environment, negotiation of IBM-DYNAMIC as
device-type should result in a Bind in which the
Services Usage screen field (the eleventh byte in the logmode'
PSERVIC field) is set to 0x03, indicating that the
screen size will be determined by the Query Reply (Usable Area
7.1.1 Device
An explanation of the CONNECT and ASSOCIATE commands
requires a discussion of the organization of terminal
printer device pools that the server maintains and from
it selects device-names to assign to session requests. (
terms "device-name", "LU name" and "network name" can
considered interchangeable in this document.) Also, for
purposes of this discussion, the term "generic session request
will be used to describe a request for a session by a
client (either traditional or TN3270E) that does not include
request for a specific device-name. The term "specific
request" will be used to describe a request for a session by
TN3270E client that includes a request for a specific device
name (either via CONNECT or ASSOCIATE).
As is the case with traditional tn3270, the TN3270E server
maintain a set of terminal device-names. A generic request
Kelly [Page 8]
RFC 1647 TN3270 Enhancements July 1994
a terminal session would result in the server selecting
available device-name from this pool. The server, however,
also maintain a separate pool of terminal device-names
can only be used to satisfy specific terminal session requests
This is to ensure that a terminal device that has
significance to host applications (and is therefore likely
be the target of a specific session request) is
"accidentally" assigned to a generic request and winds
associated with a client that has no use for it. Note that
reverse situation is allowed. That is, a specific
session request could ask for a device-name that happens to
in the "generic terminal pool".
For each terminal device (in both the "generic" and
"specific" pools), the TN3270E server could also have defined
"partner" or "paired" printer device. There should be
unique, one-to-one mapping between a terminal and
associated printer. The reasoning behind such a
is to allow for those host applications that produce
output bound for a printer whose device-name is determined
the device-name of the terminal that initiated the
request. These printer devices can only be assigned
specific printer session requests that use the
command (see below).
In addition, the TN3270E server may also maintain a pool
printer device-names that are not associated with any terminal
These printer devices can only be assigned to specific
session requests that use the CONNECT command (see below).
This allows for those host applications that generate
output bound for a printer whose device-name is determined
something other than the device-name of the terminal
initiated the print request (for example, when the userid
the person signed on to a terminal determines the
destination).
Finally, it is possible that a pool of printer device-
could be maintained and used only to satisfy generic
for printers
7.1.2 CONNECT
CONNECT is used by the client to request that the server
a specific device-name to this Telnet session; it may be
when requesting either a terminal or a printer session.
specified device-name must not conflict with the device-type
e.g., if the client requests DEVICE-TYPE IBM-3287-1 (a printer
and specifies CONNECT T1000001, but T1000001 is defined at
Kelly [Page 9]
RFC 1647 TN3270 Enhancements July 1994
host as a terminal, then the server should deny the request
Further, if the requested device-name is already
with some other Telnet session, or if it is not defined to
server, the server should deny the request
7.1.3 ASSOCIATE
ASSOCIATE can be used by the client only when requesting
DEVICE-TYPE that represents a printer. The ASSOCIATE
requests that this session be assigned the device-name of
printer that is paired with the terminal named in the request
If the device-type does not represent a printer, or if
device-name is not that of a terminal, then the server
deny the request. It is anticipated that the device-
specified in this request would be one returned by the
when accepting a previous terminal session request (see the
command below). Since no means of authentication has
provided for, it is possible that the printer paired with
terminal specified in the ASSOCIATE command has already
assigned to some other Telnet session; in this case, the
should deny the request
7.1.4 Device Selection
To summarize, assume a TN3270E server has the following
pools defined to it (device-names that begin with a "T"
terminal devices; those that begin with a "P" are printers):
Generic Terminal Pool Specific Terminal
--------------------- ----------------------
TG000001 <--> PTG00001 TS000001 <--> PTS00001
TG000002 <--> PTG00002 TS000002 <--> PTS00002
TG000003 <--> PTG00003 TS000003 <--> PTS00003
Generic Printer Pool Specific Printer
-------------------- ----------------------
PG000001 PS000001
PG000002 PS000002
PG000003 PS000003
Note that the only pool that absolutely must be defined to
server is the generic terminal pool. The absence of
pools (or of partner printers for a terminal pool) simply
that the server is unable to satisfy as wide a variety
requests as would be possible if all pools were defined to it
Given the above configuration, the following rules apply
Kelly [Page 10]
RFC 1647 TN3270 Enhancements July 1994
- a generic terminal request can only be satisfied from
generic terminal pool (device-names TG000001 - TG000003).
- a specific terminal request (allowable only via the
command) can be satisfied from either the generic or
specific terminal pool, although it is anticipated that
majority of such requests would ask for terminals in
specific terminal pool (TS000001 - TS000003).
- a generic printer request can only be satisfied from
generic printer pool (device-names PG000001 - PG000003).
- a specific printer request may come in one of two forms
via ASSOCIATE: the request can only be satisfied using
partner of the specified terminal,
may be in the generic or the
terminal pool; therefore, devices in
ranges PTG00001 - PTG00003 and PTS00001 -
PTS00003 can be used to satisfy the request
via CONNECT: the request can be satisfied either
the generic or the specific printer
(although, as with specific terminal requests
it is likely that most such requests will
printers in the specific printer pool);
request cannot be satisfied with the
printer of a terminal in either the specific
the generic terminal pools
7.1.5 Accepting a
The server must accept the client's request or deny it as
whole - it cannot, for example, accept the DEVICE-TYPE
but deny the CONNECT portion
If the server wishes to accept the request, it sends back
DEVICE-TYPE IS command confirming the requested device-type
the CONNECT command specifying the device-name of the
or printer assigned to this Telnet session. This device-
may be the one directly requested (via CONNECT) by the client
the one indirectly requested (via ASSOCIATE) by the client,
one chosen by the server if the client specified
CONNECT nor ASSOCIATE
Kelly [Page 11]
RFC 1647 TN3270 Enhancements July 1994
7.1.6 REJECT
If the server wishes to deny the request, it sends back
DEVICE-TYPE REJECT command with one of the following reason
codes
Reason code name
---------------- -----------------------------------
INV-DEVICE-TYPE The server does not support
requested device-type
INV-DEVICE-NAME The device-name specified in
CONNECT or ASSOCIATE command
not known to the server
DEVICE-IN-USE The requested device-name
already associated with
Telnet session
TYPE-NAME-ERROR The requested device-name
incompatible with the
device-type (such as terminal
printer mismatch).
UNSUPPORTED-REQ The server is unable to
the type of request sent by
client; e.g., a specific
or printer was requested but
server does not have such a pool
device-names defined to it, or
ASSOCIATE command was used but
partner printers are defined to
server
INV-ASSOCIATE The client used the
command and either the device-
is not a printer or the device-
is not a terminal
CONN-PARTNER The client used the CONNECT
to request a specific printer
the device-name requested is
partner to some terminal
UNKNOWN-ERROR Any other error in device type
name processing has occurred
Kelly [Page 12]
RFC 1647 TN3270 Enhancements July 1994
The process of negotiating a device-type and device-name
are acceptable to both client and server may entail
iterations of DEVICE-TYPE REQUEST and DEVICE-TYPE
commands. The client should make use of the reason-
specified by the server in any DEVICE-TYPE REJECT command(s)
minimize the amount of negotiation necessary. For example,
the client initially requests that it be assigned a
terminal device-name via the CONNECT command, and the
rejects the request with a reason-code of UNSUPPORTED-REQ,
client should make no further specific terminal requests in
negotiations. If at any point in the process either
wishes to "bail out," it can simply send a WON'T (or DON'T
TN3270E command to the other side. At this point both
are free to negotiate other Telnet options (
traditional tn3270).
7.2 FUNCTIONS
Once the DEVICE-TYPE negotiation has successfully completed (i.e
when the client receives the DEVICE-TYPE IS command), the
should initiate the FUNCTIONS negotiation by sending the \.
FUNCTIONS REQUEST command to the server. After this
REQUEST command, both sides are free to transmit FUNCTIONS
and FUNCTIONS IS commands as needed
7.2.1
The FUNCTIONS REQUEST command contains a list of the 3270
functions that the sender would like to see supported on
session. All functions not in the list are to be
unsupported. The function-list consists of a string of 2-
entries separated from one another by a single space character
The list is terminated by the IAC code that precedes the
command. Functions may appear in any order in the list
Upon receipt of a FUNCTIONS REQUEST command, the recipient
two choices
- it may respond in the positive (meaning it agrees to
all functions in the list, and not to transmit any
related to functions not in the list). To do this, it
the FUNCTIONS IS command with the function-list exactly as
was received. At this point, FUNCTIONS negotiation
successfully completed
- it may respond in the negative by sending a
REQUEST command in which the function-list differs from
one it received (and not simply in the order of
Kelly [Page 13]
RFC 1647 TN3270 Enhancements July 1994
of functions in the list; at least one function must
been added to, or removed from, the list).
To avoid endlessly looping, neither party should add to
function-list it receives any function that it has
added and that the other side has removed
The process of sending FUNCTIONS REQUEST commands back
forth continues until one side receives a function-list it
willing to live with. It uses the FUNCTIONS IS command
accept the list, and, once this command is received by
other side, all necessary negotiation has been completed.
this point, 3270 data stream transmission can begin
Note that it is possible that the function-list agreed to
null; this is referred to as "basic TN3270E". See the
entitled "Basic TN3270E" for more information
7.2.2 List of TN3270E
The following list briefly describes the 3270 functions
may be negotiated in the function-list
Function Name
------------- -----------
SCS-CTL-CODES (Printer sessions only). Allows the
of the SNA Character Stream (SCS) and
control codes on the session. SCS
used with LU type 1 SNA sessions
DATA-STREAM-CTL (Printer sessions only). Allows the
of the standard 3270 data stream.
corresponds to LU type 3 SNA sessions
RESPONSES Provides support for positive
negative response handling. Allows
server to reflect to the client any
all definite, exception, and no
requests sent by the host application
BIND-IMAGE Allows the server to send the SNA
image and Unbind notification to
client
SYSREQ Allows the client and server to
some (or all, depending on the server)
the functions of the SYSREQ key in an
environment
Kelly [Page 14]
RFC 1647 TN3270 Enhancements July 1994
See the section entitled "Details of Processing TN3270
Functions" for a more detailed explanation of the meaning
use of these functions
8. TN3270E Data
3270 device communications are generally understood to be
oriented in nature. That is, each partner buffers data until
entire "message" has been built, at which point the data is sent
the other side. The "outbound message" (from host to device
consists of a 3270 command and a series of buffer orders,
addresses, and data, while the "inbound message" contains only
orders, addresses and data. The end of a message is understood to
the last byte transmitted (note that this discussion disregards
chaining). The Telnet EOR command is used to delimit these
blocks of 3270 data within the Telnet data stream
In TN3270E, each 3270 message must be prefixed with a TN3270E header
which consists of five bytes and whose format is defined below (
the section entitled "The TN3270E Message Header").
A "data message" in TN3270E therefore has the following construction
It should be noted that it is possible that, for certain
types, there is no data portion present. In this case, the TN3270
data message consists of
If either side wishes to transmit the decimal value 255 and have
interpreted as data, it must "double" this byte. In other words,
single occurrence of decimal 255 will be interpreted by the
side as an IAC, while two successive bytes containing decimal 255
will be treated as one data byte with a value of decimal 255.
It is strongly recommended that Telnet commands (other than IAC IAC
should be sent between TN3270E data messages, with no header and
trailing IAC EOR. If a TN3270E data message containing either IAC
(to be interpreted as 3270 Attention) or IAC AO (to be interpreted
SYSREQ) is received, the receiver should defer processing the
until the 3270 data has been processed (see the appropriate
for discussion of 3270 Attention and SYSREQ). If a TN3270E
message containing any other IAC-command sequence (other than
IAC) is received, it is implementation dependent when the IAC-
sequence will be processed, but it must be processed. The
may process it immediately, which in effect causes it to be
Kelly [Page 15]
RFC 1647 TN3270 Enhancements July 1994
as if it had been received before the current TN3270E data message
or the processing may be deferred until after the current TN3270
data message has been processed. It is because of this
that the presence of Telnet commands within a TN3270E data
(i.e., between the header and the trailing IAC EOR) is
recommended; neither clients nor servers should send such data
8.1 The TN3270E Message
As stated earlier, each data message in TN3270E must be
by a header, which consists of five bytes and is formatted
follows
-----------------------------------------------------------
| DATA-TYPE | REQUEST-FLAG | RESPONSE-FLAG | SEQ-NUMBER |
-----------------------------------------------------------
1 byte 1 byte 1 byte 2
8.1.1 DATA-TYPE
The DATA-TYPE field indicates how the data portion of
message is to be interpreted by the receiver. Possible
for the DATA-TYPE field are
Data-type Name Code
-------------- ---- ---------------------------------
3270-DATA 0x00 The data portion of the
contains only the 3270 data stream
SCS-DATA 0x01 The data portion of the
contains SNA Character Stream data
RESPONSE 0x02 The data portion of the
constitutes device-status
and the RESPONSE-FLAG field
whether this is a positive or
response (see below).
BIND-IMAGE 0x03 The data portion of the message
the SNA bind image from the
established between the server and
host application
UNBIND 0x04 The data portion of the message
an Unbind reason code
NVT-DATA 0x05 The data portion of the message is
be interpreted as NVT data
Kelly [Page 16]
RFC 1647 TN3270 Enhancements July 1994
REQUEST 0x06 There is no data portion present
the message. Only the REQUEST-
field has any meaning
SSCP-LU-DATA 0x07 The data portion of the message
data from the SSCP-LU session
8.1.2 REQUEST-FLAG
The REQUEST-FLAG field only has meaning when the DATA-
field has a value of REQUEST; otherwise, the REQUEST-FLAG
must be ignored by the receiver and should be set to 0x00
the sender. Possible values for the REQUEST-FLAG field are
Request-Flag Name Code
----------------- ---- ---------------------------------
ERR-COND-CLEARED 0x00 The client sends this to the
when some previously
printer error condition has
cleared. (See the section
"The RESPONSES Function" below.)
8.1.3 RESPONSE-FLAG
The RESPONSE-FLAG field only has meaning for certain values
the DATA-TYPE field. For DATA-TYPE field values of 3270-
and SCS-DATA, the RESPONSE-FLAG is an indication of whether
not the sender of the data expects to receive a response.
this case the possible values of RESPONSE-FLAG are
Response-Flag Name Code
------------------ ---- ---------------------------------
NO-RESPONSE 0x00 The sender does not expect
receiver to respond
positively or negatively to
message. The receiver
therefore not send any
to this data-message
ERROR-RESPONSE 0x01 The sender only expects
receiver to respond to this
if some type of error occurred,
which case a negative response
be sent by the receiver
ALWAYS-RESPONSE 0x02 The sender expects the receiver
respond negatively if an
occurs, or positively if no
Kelly [Page 17]
RFC 1647 TN3270 Enhancements July 1994
occur. One or the other
always be sent by the receiver
For a DATA-TYPE field value of RESPONSE, the RESPONSE-FLAG
an actual response to a previous data message (which must
definition have had a DATA-TYPE of either 3270-DATA or SCS-
and a RESPONSE-FLAG value of either ERROR-RESPONSE or ALWAYS
RESPONSE). In this case the possible values of RESPONSE-
are
Response-Flag Name Code
------------------ ---- ---------------------------------
POSITIVE-RESPONSE 0x00 The previous message was
and executed successfully
no errors
NEGATIVE-RESPONSE 0x01 The previous message was
but an error(s) occurred
processing it
Accompanying status information will be found in the
portion of the message
For any other values of the DATA-TYPE field, the RESPONSE-
field must be ignored by the receiver and should be set to 0x00
by the sender
8.1.4 SEQ-NUMBER
The SEQ-NUMBER field is only used when the RESPONSES
has been agreed to. It contains a 2 byte binary number, and
used to correlate positive and negative responses to the
messages for which they were intended. See the
entitled "The RESPONSES Function" for further information
When the RESPONSES function is not agreed to, this field
always be set to 0x0000 by the sender and ignored by
receiver
9. Basic TN3270
As has been stated earlier, whether or not the use of each of
TN3270E functions is allowed on a session is negotiated when
connection is established. It is possible that none of the
are agreed to (in this case, the function-list in the
REQUEST and FUNCTIONS IS commands is null). This mode of
is referred to as "basic TN3270E". Note that, since neither
SCS-CTL-CODES function nor the DATA-STREAM-CTL function is agreed to
basic TN3270E refers to terminal sessions only
Kelly [Page 18]
RFC 1647 TN3270 Enhancements July 1994
Basic TN3270E requires the support of only the following TN3270
header values
Header field
------------ -----
DATA-TYPE 3270-
DATA-TYPE NVT-
The REQUEST-FLAG, RESPONSE-FLAG and SEQ-NUMBER fields are not used
basic TN3270E
9.1 3270 Mode and NVT
At any given time, a TN3270E connection can be considered to
operating in either "3270 mode" or "NVT mode". In 3270 mode,
party may send data messages with the DATA-TYPE flag set to 3270-
DATA; sending a DATA-TYPE flag set to NVT-DATA constitutes
request to switch modes. In NVT mode, each party may send
messages with the DATA-TYPE flag set to NVT-DATA; sending 3270-
DATA is a request to switch modes. The connection is initially
3270 mode when TN3270E operation is successfully negotiated.
a party receives a message with a DATA-TYPE different from
mode it is operating in, the mode of operation for the
is switched. Switching modes results in the client performing
equivalent of a 3270 Erase/Reset operation, as described in [5],
using the default partition (screen) size. The server
assume the client preserves any attributes of the
environment across a mode switch
Note that even when sending NVT-DATA, each side should buffer
until an entire message is built (for the client, this
normally mean until the user presses Enter). At that point,
complete TN3270E data message should be built to transmit the
data
Typically, NVT data is used by a server to interact with the
of a client. It allows the server to do this using a simple
data stream, instead of requiring a 3270 data stream. An
would be a server which displays a list of 3270 applications
which it can connect the client. The server would use NVT data
display the list and read the user's choice. Then the
would connect to the application, and begin the exchange of 3270
data between the application and the client
Kelly [Page 19]
RFC 1647 TN3270 Enhancements July 1994
10. Details of Processing TN3270E
Agreement by both parties to a specific function in the
REQUEST function-list implies agreement by each party to support
related set of values in the TN3270E header. It also implies
willingness to adhere to the rules governing the processing of
messages with regard to the agreed upon function. Either party
fails to accept header values associated either with agreed
functions or with basic TN3270E, or attempts to use header
associated with a function that is not a part of basic TN3270E
was not agreed upon, will be considered non-conforming and
violation of the protocol. The following sections detail for
TN3270E function the associated header values and processing rules
10.1 The SCS-CTL-CODES
This function can only be supported on a 3270 printer session
Agreement to support this function requires that the party
the following TN3270E header values
Header field
------------ -----
DATA-TYPE SCS-
A client representing a printer device uses this function
indicate its willingness to accept a data stream that includes
control codes. For the purposes of NVT mode versus 3270 mode
SCS-DATA should be treated exactly like 3270-DATA (i.e., it
cause a switch from NVT mode to 3270 mode).
When a printer device-type has been negotiated, either the SCS
CTL-CODES function or the DATA-STREAM-CTL function, or both,
be negotiated. This enables the server to know when it should
should not accept a session with a host application on behalf
the client. If only the SCS-CTL-CODES function is agreed to,
the server will not establish sessions with host applications
would send 3270 data stream control. If both SCS-CTL-CODES
DATA-STREAM-CTL are agreed to, then the server will
sessions both with host applications that would send SCS
codes and with those that would send 3270 orders
10.2 The DATA-STREAM-CTL
This function can only be supported on a 3270 printer session
Agreement to support this function requires that the party
the following TN3270E header values
Kelly [Page 20]
RFC 1647 TN3270 Enhancements July 1994
Header field
------------ -----
DATA-TYPE 3270-
A client representing a printer device uses this function
indicate its willingness to accept a data stream that
3270 orders and attributes
When a printer device-type has been negotiated, either the SCS
CTL-CODES function or the DATA-STREAM-CTL function, or both,
be negotiated. This enables the server to know when it should
should not accept a session with a host application on behalf
the client. If only the DATA-STREAM-CTL function is agreed to
then the server will not establish sessions with host
that would send SCS control codes in a data stream. If both SCS
CTL-CODES and DATA-STREAM-CTL are agreed to, then the server
establish sessions both with host applications that would send
control codes and with those that would send 3270 orders
10.3 The BIND-IMAGE
This function can only be supported when the TN3270E
represents SNA terminals and printers
Agreement to support this function requires that the party
the following TN3270E header values
Header field
------------ -----
DATA-TYPE BIND-
DATA-TYPE
DATA-TYPE SSCP-LU-
When BIND-IMAGE is in effect, the server must inform the
when an SNA session has been established with a host application
and when such a session has been terminated. It uses DATA-
values of BIND-IMAGE and UNBIND to convey this information
When establishing an SNA session on behalf of a client, the
will receive a Bind RU from the host application. It will
receive a Start Data Traffic RU. Once both of these have
responded to positively by the server, it must then inform
client of the presence of this session by sending it a
message with the DATA-TYPE flag set to BIND-IMAGE. The
portion of this message must contain the bind image exactly as
was received in the Bind RU that the server accepted on behalf
the client
Kelly [Page 21]
RFC 1647 TN3270 Enhancements July 1994
When an SNA session between the server and a host application
terminated, the server should send a data message to the
with the DATA-TYPE flag set to UNBIND. If the server was
of the session termination via an SNA Unbind RU, it should
the Unbind reason code in the data portion of the message it
to the client. If the server itself requested the SNA
termination (for example, as part of SYSREQ key processing),
should set the data portion of the UNBIND message to 0x01,
indicating "normal end of session".
Another aspect of the BIND-IMAGE function alters the
DATA-TYPE flag values slightly from the behavior described in
section entitled "Basic TN3270E". When BIND-IMAGE is in effect
data messages with DATA-TYPE set to 3270-DATA or SCS-DATA are
allowed before the first BIND-IMAGE is received by the client
only SSCP-LU-DATA or NVT-DATA can be used to transmit user
oriented data. The same applies to data messages exchanged
an UNBIND is sent and before another BIND-IMAGE is received by
client. Once the client receives a BIND-IMAGE data message,
allowable DATA-TYPE values include 3270-DATA and/or SCS-DATA
depending on whether a terminal or printer device-type
negotiated, and whether a printer client agreed to DATA-STREAM-
or SCS-CTL-CODES, or both. (See the section entitled "The
Function" for further discussion of the SSCP-LU session in an
environment.)
10.4 The RESPONSES
This function can be supported for both terminal and
sessions connected to both SNA and non-SNA servers
Agreement to support this function requires that the party
the following TN3270E header values
Header field
------------ -----
DATA-TYPE
DATA-TYPE
RESPONSE-FLAG -all values
REQUEST-FLAG ERR-COND-
SEQ-NUMBER binary values from 0-32767
Whenever a data message is sent with a DATA-TYPE of either SCS
DATA or 3270-DATA, the sender must set the RESPONSE-FLAG field
either NO-RESPONSE, ERROR-RESPONSE, or ALWAYS-RESPONSE. It
anticipated that the client side will normally set RESPONSE-
to NO-RESPONSE. The server, if it represents an SNA device
should set RESPONSE-FLAG to reflect the response value set in
Kelly [Page 22]
RFC 1647 TN3270 Enhancements July 1994
RH of the RU that generated this data message - Definite
resulting in a RESPONSE-FLAG value of ALWAYS-RESPONSE,
Response resulting in ERROR-RESPONSE being set, and No
causing a setting of NO-RESPONSE. A non-SNA server should
RESPONSE-FLAG to ERROR-RESPONSE
In addition, the sender must keep a count of the messages with
DATA-TYPE of 3270-DATA or SCS-DATA that it sends on a
session. This counter should start at zero for the first
message, and be incremented by one for each subsequent message
If the counter reaches the maximum of 32767, it should
restarted at zero. The sender should place this value in
SEQ-NUMBER field of the TN3270E header before it sends
message. Note that the SEQ-NUMBER field must be set regardless
the value of the RESPONSE-FLAG field
10.4.1 Response
Whenever a data message with a DATA-TYPE of either SCS-DATA
3270-DATA is received, the receiver must attempt to process
data in the data portion of the message, then determine
or not it should send a data message with a DATA-TYPE
RESPONSE. If the data message it has just processed had
RESPONSE-FLAG value of NO-RESPONSE, or if it had a value
ERROR-RESPONSE and there were no errors encountered
processing the data, then no RESPONSE type message should
sent. Otherwise, a data message should be sent in which
header DATA-TYPE field is set to RESPONSE, and in which
SEQ-NUMBER field is a copy of the SEQ-NUMBER field from
message to which this response corresponds. The RESPONSE-
field in this header must have a value of either POSITIVE
RESPONSE or NEGATIVE-RESPONSE. A POSITIVE-RESPONSE should
sent if the previously processed message's header
ALWAYS-RESPONSE and no errors were encountered in
the data. A NEGATIVE-RESPONSE should be sent
1) the previously processed message specified ERROR-
or ALWAYS-RESPONSE
2) some kind of error occurred while processing the data
Normally only the client will be constructing and sending
RESPONSE messages. A negative response sent by the client
the server is the equivalent of a Unit Check Status [7].
references to device status and sense codes in this
rely on [7].
Kelly [Page 23]
RFC 1647 TN3270 Enhancements July 1994
The data portion of a RESPONSE message must consist of one
of binary data. The value of this byte gives a more
account of the results of having processed the
received data message. The possible values for this byte are
For a RESPONSE-FLAG value of POSITIVE-RESPONSE -
Value
----- -------
0x00 Successful completion (when sent by the client
this is equivalent to "Device End").
For a RESPONSE-FLAG value of NEGATIVE-RESPONSE -
Value
----- -------
0x00 An invalid 3270 command was
(equivalent to "Command Reject").
0x01 Printer is not ready (equivalent
"Intervention Required").
0x02 An illegal 3270 buffer address or
sequence was received (equivalent
"Operation Check").
0x03 Printer is powered off or not
(equivalent to "Component Disconnected").
When the server receives any of the above responses, it
pass along the appropriate information to the host application
The appropriate information is determined by whether the
represents an SNA or a non-SNA device
An SNA server should pass along a POSITIVE-RESPONSE from
client as an SNA positive Response Unit to the
application. It should translate a NEGATIVE-RESPONSE from
client into an SNA negative Response Unit in which the
Data Indicator bit is on and which contains one of
following sense codes
Kelly [Page 24]
RFC 1647 TN3270 Enhancements July 1994
RESPONSE-FLAG Equivalent SNA Sense
------------- ---------- --------------
0x00 Command Reject 0x10030000
0x01 Intervention Required 0x08020000
0x02 Operation Check 0x10050000
0x03 Component Disconnected 0x08310000
A non-SNA server should pass along a POSITIVE-RESPONSE from
client by setting the Device End Status bit on. It
reflect a NEGATIVE-RESPONSE from the client by setting the
Check Status Bit on, and setting either the Command Reject
Intervention Required, or Operation Check Sense bit on
responding to the Sense command
In the case of Intervention Required or Component
being passed by the server to the host application, the
would normally refrain from sending any further data to
printer. If and when the error condition at the client
been resolved, the client must send to the server a
message whose header DATA-TYPE field is set to REQUEST,
whose REQUEST-FLAG is set to ERR-COND-CLEARED. Note that
message has no data portion. Upon receipt of this message,
server should pass along the appropriate information to
host application so that it may resume sending printer output
Again, the form of this information depends on whether
server represents an SNA or a non-SNA device
An SNA server should reflect an ERR-COND-CLEARED to the
application by sending an SNA LUSTAT RU with one of
following sense codes
- if the previous error condition was an
Required, the server should send sense code 0x00010000
- if the previous error condition was
Disconnected, the server should send sense code 0x082B0000
A non-SNA server should set the corresponding bits in
Ending Status and Sense Condition bytes
Kelly [Page 25]
RFC 1647 TN3270 Enhancements July 1994
10.5 The SYSREQ
This function can only be supported when the TN3270E
represents SNA devices
Agreement to support this function requires that the party
the following TN3270E header values
Header field
------------ -----
DATA-TYPE SSCP-LU-
The 3270 SYSREQ key can be useful in an SNA environment when
ATTN key is not sufficient to terminate a process. (See
section entitled "The 3270 ATTN Key" for more information.)
10.5.1
In SNA, there is a session between the host application (
PLU, or Primary Logical Unit) and the TN3270E
representing the client (the SLU, or Secondary Logical Unit).
This is referred to as the PLU-SLU session, and it is the
on which normal communications flow. There is also a
between the host telecommunications access method (the SSCP,
System Services Control Point) and the SLU, and it is
to as the SSCP-LU session. This session is used to
various control information and is normally transparent to
user; normal 3270 data stream orders are not allowed in
data. For more information, refer to [7].
The terminal display and keyboard are usually "owned" by
PLU-SLU session, meaning any data the user types is sent to
host application. The SYSREQ key is used to toggle
of the keyboard and display between the PLU-SLU session and
SSCP-LU session. In other words, the user is able to
SYSREQ and then communicate directly with the host SSCP.
user may then enter any valid Unformatted Systems
commands, which are defined in the USS table associated
the SLU. The most common USS command users employ is "LOGOFF,"
which requests that the SSCP immediately terminate the PLU-
session. The usual reason for requesting such an action
that the host application (the PLU) has stopped
altogether
Whenever the keyboard and display are owned by the SSCP-
session, no data is allowed to flow in either direction on
PLU-SLU session. Once "in" the SSCP-LU session, the user
decide to switch back to the PLU-SLU session by again
Kelly [Page 26]
RFC 1647 TN3270 Enhancements July 1994
the SYSREQ key
10.5.2 TN3270E Implementation of
The design of some TN3270E servers allows them to fully
the SYSREQ key because they are allowed to send USS commands
the SSCP-LU session. Other TN3270E servers operate in
environment which does not allow them to send USS commands
the SSCP; this makes full support of the SYSREQ key impossible
For such servers, TN3270E provides for emulation of a
subset of functions, namely, for the sequence of
SYSREQ and typing LOGOFF that many users employ to
terminate the PLU-SLU session
The Telnet Abort Output (AO) command is the mechanism used
implement SYSREQ key support in TN3270E because, in a real
session, once the user presses the SYSREQ key, the
application is prevented from sending any more output to
terminal (unless the user presses SYSREQ a second time),
the user's process continues to execute
In order to implement SYSREQ key support, TN3270E clients
have agreed to the SYSREQ function should provide a key (
combination of keys) that is identified as mapping to the 3270
SYSREQ key. When the user presses this key(s), the
should transmit a Telnet AO command to the server
Upon receipt of the AO command, a TN3270E server that
agreed to the SYSREQ function should enter what will be
termed "suspended mode" for the connection. If a server
has not agreed to the SYSREQ function receives an AO command
it should simply ignore it. Any attempt by the
application to send data to the client while the connection
"suspended" should be responded to by the server with
negative response, sense code 0x082D, indicating an "LU Busy
condition. The server should not transmit anything to
client on behalf of the host application. While the
is "suspended," any data messages (except TN3270E responses
exchanged between the client and server should have the DATA
TYPE flag set to SSCP-LU-DATA
At this point, the behavior of the server depends upon
or not it is allowed to send USS commands on the SSCP-
session. Servers that have this ability should simply act as
vehicle for passing USS commands and responses between
client and the SSCP
Kelly [Page 27]
RFC 1647 TN3270 Enhancements July 1994
Servers that are not allowed to send USS commands on the SSCP
LU session should behave as follows
- if the user transmits the string LOGOFF (upper or lower case),
the server should send an Unbind SNA RU to the
application. This will result in termination of the PLU-
session. If the BIND-IMAGE function was agreed upon,
the server should also send a data message to the client
the DATA-TYPE flag set to UNBIND and the data portion set
0x01.
- if the user transmits anything other than LOGOFF, the
should respond with the string "COMMAND UNRECOGNIZED" to
client. The server should not send anything to the
application on behalf of the client
Regardless of which kind of server is present (i.e., whether
not it may send USS commands on the SSCP-LU session), while
connection is suspended, the user may press the "SYSREQ"
again. This will result in the transmission of another AO
the server. The server should then send to the
application an LUSTAT RU with a value of 0x082B
"presentation space integrity lost". The server will
"un-suspend" the Telnet connection to the client, meaning
will allow the host application to once again send data to
client
11. The 3270 ATTN
The 3270 ATTN key is interpreted by many host applications in an
environment as an indication that the user wishes to interrupt
execution of the current process. The Telnet Interrupt Process (IP
command was defined expressly for such a purpose, so it is used
implement support for the 3270 ATTN key. This requires two things
- TN3270E clients should provide as part of their
mapping a single key or a combination of keys that map
the 3270 ATTN key. When the user presses this key(s),
client should transmit a Telnet IP command to the server
- TN3270E servers should translate the IP command received
a TN3270E client into the appropriate form and pass it
to the host application as an ATTN key. In other words,
server representing an SLU in an SNA session should
a SIGNAL RU to the host application
Kelly [Page 28]
RFC 1647 TN3270 Enhancements July 1994
The ATTN key is not supported in a non-SNA environment; therefore,
TN3270E server representing non-SNA 3270 devices should ignore
Telnet IP commands it receives from a client
12. 3270 Structured
3270 structured fields provide a much wider range of features
"old-style" 3270 data, such as support for graphics, partitions
IPDS printer data streams. It would be unreasonable to expect
TN3270E clients to support all possible structured field functions
yet there must be a mechanism by which those clients that are
of supporting some or all structured field functions can
their wishes
The design of 3270 structured fields provides a convenient means
convey the level of support (including no support) for the
structured field functions. This mechanism is the Read
Query command, which is sent from the host application to the device
The device responds with a Query Reply structured field(s)
which, if any, structured field functions it supports
The Query Reply is also used to indicate some device
which do not require the use of structured fields, such as
color support and extended highlighting capability. Most
applications will use Read Partition Query to precisely determine
device's capabilities when there has been some indication that
device supports the "extended data stream".
Therefore, all TN3270E clients that negotiate a terminal device-
that contains a "-E" suffix, the DYNAMIC terminal type, or a
device-type, must be able to respond to a Read Partition
command. Note that these clients must support both the
Partition Query (Type 02), and all forms of the Read Partition
List (Type 03).
13. Implementation
13.1 3270 Data Stream
Implementors of TN3270E clients should note that the command
for the various 3270 Read and Write commands have different
depending on how the server is conne