As per Relevance of the word terminal, we have this rfc below:
Network Working Group J.
Request for Comments: 1576 DCA, Inc
Category: Informational January 1994
TN3270 Current
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document describes the existing implementation of
3270 display terminal data using currently available
capabilities. The name traditionally associated with
implementation is TN3270.
Information is provided to aid in the implementation of TN3270
servers as well as client terminal emulators
The following areas pertaining to TN3270 implementations are
in this document
1. the telnet options negotiated to transition from a NVT
state to a TN3270 state ready to process incoming 3270
stream
2. the method for sending and receiving 3270
3. the method of handling some special keys known as SYSREQ
ATTN using current available telnet
4. the events that will transition a TN3270 session back to an
Table of
1. Motivation . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . 2
3. Telnet Options and Commands Used . . . . . . . . 4
4. Connection Negotiation . . . . . . . . . . . . . 4
4.1 3270 Regime Option . . . . . . . . . . . . . . . 6
4.2 Suppress Go Ahead Option . . . . . . . . . . . . 6
4.3 Echo Option . . . . . . . . . . . . . . . . . . . 6
4.4 Timing Mark Option . . . . . . . . . . . . . . . 7
TN3270 Enhancements Working Group [Page 1]
RFC 1576 TN3270 Current Practices January 1994
5. Testing for session presence . . . . . . . . . . 7
6. Handling 3270 data . . . . . . . . . . . . . . . 7
7. 3270 Structured Fields . . . . . . . . . . . . . 8
8. The 3270 ATTN (Attention) Key . . . . . . . . . . 8
9. The 3270 SYSREQ Key . . . . . . . . . . . . . . . 9
10. Items not addressed by TN3270 . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . 11
13. Author's Note . . . . . . . . . . . . . . . . . . 11
14. Author's Address . . . . . . . . . . . . . . . . 12
1.
3270 display terminal data differs from traditional display
data in that it is block mode and uses EBCDIC instead of
character representation. These two differences are the
reason for the differentiation of TN3270 from standard Telnet in
document
2.
Existing complex IBM 3270 display terminal networks are not
integrated with the increasing number of multi-platform
environments, specifically TCP/IP. These complex networks
terminals attached to a 3270 host using SNA (Systems
Architecture) and non-SNA connections. To address the issue of
connecting display terminals to 3270 hosts using IP networks,
vendors have introduced telnet servers that provide TCP/IP users
connection to existing IBM mainframes by supporting display
emulation using a subset of the existing telnet protocol.
servers may exist on the host itself, or be connected to the
using SNA or non-SNA methods
IBM terminals are generically referred to as 3270's which includes
broad range of terminals and devices, not all of which actually
with the numbers 327x
3270 terminals in the IBM SNA network environment have two
with the host computer application. One is used for
with the host application, the other is used for communicating
the SSCP (System Services Control Point) that links the terminal
the appropriate host computer. For the purposes of TN3270,
distinction is not apparent or relevant since there is actually
a single telnet session with the host computer or server. On an
SNA network, the 3270 terminal has a special key that toggles
the two sessions (SYSREQ). A brief discussion on how some
servers deal with this is included
TN3270 Enhancements Working Group [Page 2]
RFC 1576 TN3270 Current Practices January 1994
In an SNA environment, a client session is identified by a
Unit (LU) name. In a non-SNA environment, there is not a LU
associated with a client session. The closest thing to a LU name
the TN3270 environment is the client's IP address. Although
telnet servers are connected to the host using SNA, TN3270
using these servers have no defined way to determine the LU
associated with the session
Telnet servers that exist in non-SNA environments do not have to
concerned about providing TN3270 clients with support for the
functions described in this document
TN3270 does not support typical SNA responses and is classified as
non-SNA protocol. A TN3270 emulator is not aware or concerned
how the telnet server is connected to a 3270 host application
NOTE: Except where otherwise stated, this document does
distinguish between telnet servers that represent SNA devices
those that represent non-SNA 3270 devices
Some typical "SNA" functions such as the SYSREQ and ATTN keys
been mapped to existing telnet commands and are supported by
telnet server implementations
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]. This negotiation and the resulting data flow will
described below
RFC 1041 [1] attempted to standardize the method of negotiating 3270
terminal support by defining the 3270 Regime Telnet Option
Historically, very few developers and vendors ever implemented
1041.
All references in this document to the 3270 datastream, SNA
non-SNA operation, 3270 datastream commands, orders,
fields and the like rely on [6].
References to SNA Request and Response Units rely on [7].
to SNA and SSCP rely on [12].
TN3270 Enhancements Working Group [Page 3]
RFC 1576 TN3270 Current Practices January 1994
3. Telnet Options and Commands
TN3270 makes use of existing Telnet options and does not define
additional options or commands
Telnet option Value (decimal
------------- ---------------
BINARY 0
TERMINAL-TYPE 24
EOR 25
Additional options may be used during a TN3270 session and
interpreted as per their respective RFCs. These are [1] 3270-REGIME
[8] SUPPRESS-GO-AHEAD, [9] ECHO and [10] TIMING-MARK. Other
should be rejected unless they are specifically handled by the
for NVT mode
Commands that may be encountered during a TN3270 session and
described in RFC 854 [11] include NOP, BREAK and Interrupt Process
4. Connection
The following example shows a TN3270-capable server and a TN3270
client establishing a connection
The TCP/IP port used to connect with is 23 (Telnet).
At any place before and during the TN3270 connection
process, other telnet commands and data may be transferred and
be interpreted under the existing telnet state. Some existing TN3270
servers start a client connection using an NVT telnet dialog
establish parameters needed to complete the TN3270 connection to
desired host
The order of negotiating terminal type, EOR and BINARY is
significant, this example shows a typical TN3270 connection
Server: IAC DO TERMINAL-
Client: IAC WILL TERMINAL-
Server: IAC SB TERMINAL-TYPE SEND IAC
Client: IAC SB TERMINAL-TYPE IS <terminal type>IAC
where <terminal type> is a string consisting of terminal model
type and support of enhanced attribute bytes; an example is IBM
3278-2. The acceptable values are listed in RFC 1340,
TN3270 Enhancements Working Group [Page 4]
RFC 1576 TN3270 Current Practices January 1994
Numbers [5]. Other values are in use that do not exist in [5].
The -2 following 3278 designates the alternate screen size. 3270
terminals have the ability to switch between the standard (24x80)
screen size and an alternate screen size. Model -2 is 24x80
is the same as the standard size. Model -3 is 32x80, model -4
43x80 and model -5 is 27x132.
Appending the two character string "-E" to the end of the
type signifies that the terminal is capable of handling 3270
extended data stream. This is interpreted to mean that
terminal is able to handle structured fields, which are
below. Some telnet server implementations also interpret this
mean that the terminal is capable of handling extended
(highlighting, field validation, character set, outlining, etc.)
[6].
The 3279 series of terminals is capable of extended
while the 3278 series is not
Server: IAC DO EOR IAC WILL
Client: IAC WILL EOR IAC DO
Server: IAC DO BINARY IAC WILL
Client: IAC WILL BINARY IAC DO
Server: <3270 data stream> IAC
Client: <3270 data stream> IAC
. .
. .
To terminate the connection the socket is closed by one of
session partners. Typically, when the user logs off of the host,
telnet server closes the connection
If the telnet server wishes to go back to NVT mode, it may issue
following telnet options
Server: IAC WONT
Client: IAC DONT
Server: IAC WONT
Client: IAC DONT
Either one of the above two cases causes the connection to
satisfy the requirements for a valid TN3270 session. The
client would then process data from the server as though it were
ASCII data
TN3270 Enhancements Working Group [Page 5]
RFC 1576 TN3270 Current Practices January 1994
The following examples show how a TN3270 client handles the 3270-
REGIME, SUPPRESS-GO-AHEAD, ECHO and TM options
4.1 3270 Regime
Very few servers support the 3270 Regime Telnet Option. If
client does not support this option and responds negatively as
in the following example, the server will proceed on to the
typical example shown above
Server: IAC DO 3270-
Client: IAC WONT 3270-
Normal negotiation
Server: IAC DO TERMINAL-
... (see above
4.2 Suppress Go Ahead
The Suppress Go Ahead option [8] is requested by some servers.
Suppress Go Ahead option RFC lists the default as being go aheads
transmitted to signal the receiver to begin transmitting.
TN3270 negotiates binary and end-of-record and is a block
protocol, the telnet go ahead character is not sent. Most servers
not negotiate this option even though they do not use the telnet
ahead character
Server: IAC DO SUPPRESS-GO-
Client: IAC WILL SUPPESS-GO-
4.3 Echo
The Echo option [9] is negotiated by those servers that make use
the telnet NVT mode to allow the user to enter information prior
negotiating the options necessary for TN3270. This
includes but is not limited to user identification, password
destination 3270 host. Some servers accept the default for
option which is for the client to not do a local echo of
the user enters at the keyboard. This allows the server to decide
it should echo characters back to the client (or not in the case
password). Echoing characters back to the client causes slow
time since every character is typically echoed individually.
of this, some servers negotiate for the client to do it's own
echoing (except for passwords). The following example
this case
TN3270 Enhancements Working Group [Page 6]
RFC 1576 TN3270 Current Practices January 1994
Server: IAC DO
Client: IAC WILL
(Client does local display of all characters
Server: IAC WONT
Client: IAC DONT
(Client enters password - not locally displayed or
echoed
Server: IAC DO
Client: IAC WILL
(Client resumes local display of all characters
4.4 Timing Mark
The Timing Mark option [10] is used by some servers to test for
continued presence of a TN3270 client. The following example
assure the server the client is still alive
Server: IAC DO TIMING-
Client: IAC WONT TIMING-
5. Testing for session
The NOP command (hexadecimal F1) [11] is used by some servers to
for the continued presence of a TN3270 client. If a client
terminated abnormally, TCP/IP send errors will occur. The Timing
option, described above, is also used to test for presence
Server: IAC
Client: response
6. Handling 3270
The 3270 data stream consists of a command and its associated data
Commands include but are not limited to erase screen, erase and
to screen and read current screen; see [6] for a complete
of 3270 commands and parameters
The reason for negotiating the EOR telnet option [4] is to provide
method for separating these commands since no length information
specified. 3270 commands are interpreted by the telnet client
their entirety. Each 3270 command and possible data is
with the IAC EOR sequence
The Binary option [3] is also required since 3270 data may
the FF (hexadecimal) or IAC character. When this character
encountered during a TN3270 connection it is handled as per
Binary RFC [3].
TN3270 Enhancements Working Group [Page 7]
RFC 1576 TN3270 Current Practices January 1994
7. 3270 Structured
3270 structured fields provide a much wider range of features
"old-style" 3270 data, such as support for graphics, partitions
IPDS printer datastreams. A structured field is a 3270 data type
allows non 3270 data to be embedded within 3270 data. Briefly,
structured field consists of the structured field command followed
one or more data blocks. Each data block has a length and
structured field identifier, followed optionally by additional data
Not every TN3270 client can be expected to support all
field functions. There must be a mechanism by which those
that are capable of supporting some or all structured field
can indicate their wishes. This is typically done by adding "-E"
the end of the terminal type string. That is, when the
identifies itself as being able to handle extended attributes,
also is capable of being able to send and receive structured fields
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 client
The client responds with a Query Reply, listing which, if any
structured field functions it supports
A TN3270 client that supports structured fields will respond to
Read Partition Query command with the appropriate reply.
sequence of events when a client receives a Read Partition Query
does not support structured fields is left up to the
implementation. Typically clients can identify at least
structured field and reply with a null set
8. The 3270 ATTN (Attention)
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. A majority of the telnet
currently accept the telnet IAC BREAK (code 243) [11] sequence
signal this event
Use of this key requires two things
- The TN3270 clients 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 transmits a Telnet BREAK command to the server
TN3270 Enhancements Working Group [Page 8]
RFC 1576 TN3270 Current Practices January 1994
- The TN3270 servers translate the BREAK command received
a TN3270 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 would
a SIGNAL RU to the host application
The ATTN key is not supported in a non-SNA environment; therefore,
TN3270 server representing non-SNA 3270 devices ignores any
BREAK commands it receives from a client
9. The 3270 SYSREQ
The 3270 SYSREQ key is useful in an environment where the
server is attached to the host using SNA. The SYSREQ key is useful
this environment when the host application becomes locked or the
wishes to terminate the session without closing the
connection
The Telnet Interrupt Process (IP) command [11] is interpreted by
telnet servers as a SYSREQ key. Other servers recognize the 3270
Request key as a SYSREQ key. In an SNA environment, pressing
key toggles the terminal between the host application session and
SSCP session. Usually the user will enter LOGOFF once this key
been pressed to terminate the application session and then select
new host to connect to. Sometimes, if SYSREQ is pressed again,
host application will become unlocked and normal activities may
proceed
It is entirely up to the telnet server to interpret this command
send the appropriate commands to the host as well as format
resulting host data for display on the telnet client. The data
during the SSCP session is in a slightly different format than
3270 data. Since the telnet server has no way to pass this
directly to the telnet client, it must either handle it entirely
ignore SYSREQ events or convert it to 3270 data to present to
client
To implement SYSREQ key support, TN3270 clients provide a key (
combination of keys) that is identified as mapping to the 3270
key. When the user presses this key(s), the client would
transmit a Telnet IP command or Test Request key to the server
depending on the server implementation
TN3270 servers representing non-SNA 3270 terminals may ignore
Telnet IP commands or Test Request keys they receive from a client
TN3270 Enhancements Working Group [Page 9]
RFC 1576 TN3270 Current Practices January 1994
10. Items not addressed by TN3270
There are several items that are not supported by current TN3270
implementations; among them are the following
- TN3270 provides no capability for 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
- The 3270 ATTN and SYSREQ keys are not universally supported
- There is no support for the SNA positive/negative
process. All data that is sent is assumed to either be
or ignored. The lack of SNA response processing in TN3270
part of what makes TN3270 efficient
A negative response indicates some sort of error at the
while processing the previously received data; this could
caused by the host application building a 3270 datastream
contains an invalid command, or by a mechanical error at
client side, among other things
Positive responses indicate processing of the previously
data has completed
- There is no mechanism by which the client can access the
BIND information. The BIND image in a SNA
contains a detailed description of the session between
telnet server and the host application
- The connection negotiation does not make it clear
clients should support 3270 structured fields
11.
[1] Rekhter, Y., "Telnet 3270 Regime Option", RFC 1041,
Corporation, January 1988.
[2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091,
Software, Inc., February 1989.
[3] Postel, J., and J. Reynolds, "Telnet Binary Transmission",
27, RFC 856, USC/Information Sciences Institute, May 1983.
TN3270 Enhancements Working Group [Page 10]
RFC 1576 TN3270 Current Practices January 1994
[4] Postel, J., "Telnet End of Record Option", RFC 885,
USC/Information Sciences Institute, December 1983.
[5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[6] "3270 Information Display System - Data Stream Programmer'
Reference", publication number GA23-0059, IBM Corporation
[7] "Systems Network Architecture - Formats", publication
GA27-3136, IBM Corporation
[8] Postel, J., and J. Reynolds, "Telnet Suppress Go Ahead Option",
STD 29, RFC 858, USC/Information Sciences Institute, May 1983.
[9] Postel, J., and J. Reynolds, "Telnet Echo Option", STD 28,
857, USC/Information Sciences Institute, May 1983.
[10] Postel, J., and J. Reynolds, "Telnet Timing Mark Option", STD 31,
RFC 860, USC/Information Sciences Institute, May 1983.
[11] Postel, J., and J. Reynolds, "Telnet Protocol Specification",
8, RFC 854, USC/Information Sciences Institute, May 1983.
[12] "Systems Network Architecture - Concepts and Products",
publication number GC30-3072, IBM Corporation
12. Security
Security issues are not discussed in this memo
13. Author's
Portions of this document were drawn from the following sources
- A White Paper written by Owen Reddecliffe, WRQ Corporation
October 1991.
- Experimental work on the part of Cleve Graves and
Angel, OpenConnect Systems, 1992 - 1993.
- Discussions at the March 1993 IETF meeting and TN3270 BOF
Interop August 1993.
- Discussions on the "TN3270E" list, 1993.
TN3270 Enhancements Working Group [Page 11]
RFC 1576 TN3270 Current Practices January 1994
14. Author's
Jon
DCA, Inc
2800 Oakmont
Austin, TX 78664
Phone: (512) 388-7090
EMail: jjp@bscs.
or dca/g=Jon/s=Penner/ou=DCAAUS@mhs.attmail.
TN3270 Enhancements Working Group [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
