0x01 Printer is not ready (equivalent to
"Intervention Required").
0x02 An illegal 3270 buffer address or order
sequence was received (equivalent to
"Operation Check").
0x03 Printer is powered off or not connected
(equivalent to "Component Disconnected").
When the server receives any of the above responses, it should
pass along the appropriate information to the host application.
The appropriate information is determined by whether the server
represents an SNA or a non-SNA device.
An SNA server should pass along a POSITIVE-RESPONSE from the
client as an SNA positive Response Unit to the host
application. It should translate a NEGATIVE-RESPONSE from the
client into an SNA negative Response Unit in which the Sense
Data Indicator bit is on and which contains one of the
following sense codes:
RESPONSE-FLAG Equivalent SNA Sense Code
------------- ---------- --------------
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 the
client by setting the Device End Status bit on. It should
reflect a NEGATIVE-RESPONSE from the client by setting the Unit
Check Status Bit on, and setting either the Command Reject,
Intervention Required, or Operation Check Sense bit on when
responding to the Sense command.
In the case of Intervention Required or Component Disconnected
being passed by the server to the host application, the host
would normally refrain from sending any further data to the
printer. If and when the error condition at the client has
been resolved, the client must send to the server a data
message whose header DATA-TYPE field is set to REQUEST, and
whose REQUEST-FLAG is set to ERR-COND-CLEARED. Note that this
message has no data portion. Upon receipt of this message, the
server should pass along the appropriate information to the
host application so that it may resume sending printer output.
Again, the form of this information depends on whether the
server represents an SNA or a non-SNA device.
An SNA server should reflect an ERR-COND-CLEARED to the host
application by sending an SNA LUSTAT RU with one of the
following sense codes:
- if the previous error condition was an Intervention
Required, the server should send sense code 0x00010000
- if the previous error condition was Component
Disconnected, the server should send sense code 0x082B0000
A non-SNA server should set the corresponding bits in the
Ending Status and Sense Condition bytes.
10.5 The SYSREQ Function
This function can only be supported when the TN3270E server
represents SNA devices.
Agreement to support this function requires that the party support
the following TN3270E header values:
Header field Value
------------ -----
DATA-TYPE SSCP-LU-DATA
The 3270 SYSREQ key can be useful in an SNA environment when the
ATTN key is not sufficient to terminate a process. (See the
section entitled "The 3270 ATTN Key" for more information.)
10.5.1 Background
In SNA, there is a session between the host application (the
PLU, or Primary Logical Unit) and the TN3270E server
representing the client (the SLU, or Secondary Logical Unit).
This is referred to as the PLU-SLU session, and it is the one
on which normal communications flow. There is also a session
between the host telecommunications access method (the SSCP, or
System Services Control Point) and the SLU, and it is referred
to as the SSCP-LU session. This session is used to carry
various control information and is normally transparent to the
user; normal 3270 data stream orders are not allowed in this
data. For more information, refer to [7].
The terminal display and keyboard are usually "owned" by the
PLU-SLU session, meaning any data the user types is sent to the
host application. The SYSREQ key is used to toggle ownership
of the keyboard and display between the PLU-SLU session and the
SSCP-LU session. In other words, the user is able to press
SYSREQ and then communicate directly with the host SSCP. The
user may then enter any valid Unformatted Systems Services
commands, which are defined in the USS table associated with
the SLU. The most common USS command users employ is "LOGOFF,"
which requests that the SSCP immediately terminate the PLU-SLU
session. The usual reason for requesting such an action is
that the host application (the PLU) has stopped responding
altogether.
Whenever the keyboard and display are owned by the SSCP-LU
session, no data is allowed to flow in either direction on the
PLU-SLU session. Once "in" the SSCP-LU session, the user may
decide to switch back to the PLU-SLU session by again pressing
the SYSREQ key.
10.5.2 TN3270E Implementation of SYSREQ
The design of some TN3270E servers allows them to fully support
the SYSREQ key because they are allowed to send USS commands on
the SSCP-LU session. Other TN3270E servers operate in an
environment which does not allow them to send USS commands to
the SSCP; this makes full support of the SYSREQ key impossible.
For such servers, TN3270E provides for emulation of a minimal
subset of functions, namely, for the sequence of pressing
SYSREQ and typing LOGOFF that many users employ to immediately
terminate the PLU-SLU session.
The Telnet Abort Output (AO) command is the mechanism used to
implement SYSREQ key support in TN3270E because, in a real SNA
session, once the user presses the SYSREQ key, the host
application is prevented from sending any more output to the
terminal (unless the user presses SYSREQ a second time), but
the user's process continues to execute.
In order to implement SYSREQ key support, TN3270E clients that
have agreed to the SYSREQ function should provide a key (or
combination of keys) that is identified as mapping to the 3270
SYSREQ key. When the user presses this key(s), the client
should transmit a Telnet AO command to the server.
Upon receipt of the AO command, a TN3270E server that has
agreed to the SYSREQ function should enter what will be loosely
termed "suspended mode" for the connection. If a server that
has not agreed to the SYSREQ function receives an AO command,
it should simply ignore it. Any attempt by the host
application to send data to the client while the connection is
"suspended" should be responded to by the server with a
negative response, sense code 0x082D, indicating an "LU Busy"
condition. The server should not transmit anything to the
client on behalf of the host application. While the connection
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 whether
or not it is allowed to send USS commands on the SSCP-LU
session. Servers that have this ability should simply act as a
vehicle for passing USS commands and responses between the
client and the SSCP.
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 host
application. This will result in termination of the PLU-SLU
session. If the BIND-IMAGE function was agreed upon, then
the server should also send a data message to the client with
the DATA-TYPE flag set to UNBIND and the data portion set to
0x01.
- if the user transmits anything other than LOGOFF, the server
should respond with the string "COMMAND UNRECOGNIZED" to the
client. The server should not send anything to the host
application on behalf of the client.
Regardless of which kind of server is present (i.e., whether or
not it may send USS commands on the SSCP-LU session), while the
connection is suspended, the user may press the "SYSREQ" key
again. This will result in the transmission of another AO to
the server. The server should then send to the host
application an LUSTAT RU with a value of 0x082B indicating
"presentation space integrity lost". The server will then
"un-suspend" the Telnet connection to the client, meaning it
will allow the host application to once again send data to the
client.
11. The 3270 ATTN Key
The 3270 ATTN key is interpreted by many host applications in an SNA
environment as an indication that the user wishes to interrupt the
execution of the current process. The Telnet Interrupt Process (IP)
command was defined expressly for such a purpose, so it is used to
implement support for the 3270 ATTN key. This requires two things:
- TN3270E clients should provide as part of their keyboard
mapping a single key or a combination of keys that map to
the 3270 ATTN key. When the user presses this key(s), the
client should transmit a Telnet IP command to the server.
- TN3270E servers should translate the IP command received from
a TN3270E client into the appropriate form and pass it along
to the host application as an ATTN key. In other words, the
server representing an SLU in an SNA session should send
a SIGNAL RU to the host application.
The ATTN key is not supported in a non-SNA environment; therefore, a
TN3270E server representing non-SNA 3270 devices should ignore any
Telnet IP commands it receives from a client.
12. 3270 Structured Fields
3270 structured fields provide a much wider range of features than
"old-style" 3270 data, such as support for graphics, partitions and
IPDS printer data streams. It would be unreasonable to expect all
TN3270E clients to support all possible structured field functions,
yet there must be a mechanism by which those clients that are capable
of supporting some or all structured field functions can indicate
their wishes.
The design of 3270 structured fields provides a convenient means to
convey the level of support (including no support) for the various
structured field functions. This mechanism is the Read Partition
Query command, which is sent from the host application to the device.
The device responds with a Query Reply structured field(s) listing
which, if any, structured field functions it supports.
The Query Reply is also used to indicate some device capabilities
which do not require the use of structured fields, such as extended
color support and extended highlighting capability. Most host
applications will use Read Partition Query to precisely determine a
device's capabilities when there has been some indication that the
device supports the "extended data stream".
Therefore, all TN3270E clients that negotiate a terminal device-type
that contains a "-E" suffix, the DYNAMIC terminal type, or a printer
device-type, must be able to respond to a Read Partition Query
command. Note that these clients must support both the Read
Partition Query (Type 02), and all forms of the Read Partition Query
List (Type 03).
13. Implementation Guidelines
13.1 3270 Data Stream Notes
Implementors of TN3270E clients should note that the command codes
for the various 3270 Read and Write commands have different values
depending on how the server is connected to the host (local versus
remote, SNA versus non-SNA). Clients should be coded to check for
the various possible values if they wish to be compatible with the
widest range of servers. See [7] for further details.
13.2 Negotiation of the TN3270E Telnet Option
Since TN3270E is a Telnet Option governed by [8], both client and
server are free to attempt to initiate negotiation of TN3270E by
sending a DO TN3270E command. However, just as is usually the
case with the Telnet DO TERMINAL-TYPE, it is anticipated that the
server will normally be the one sending the DO TN3270E, and the
client will be responding with a WILL or a WON'T TN3270E.
13.3 A "Keep-alive" Mechanism
In many environments, it is very helpful to have in place a
mechanism that allows timely notification of the loss of a 3270
session. TN3270E does not require that any form of keep-alive
mechanism be employed by either clients or servers, but
implementors wishing to support such a mechanism should consider
the following guidelines.
There are at least two possible means of providing a keep-alive
mechanism in TN3270E: the Telnet IAC NOP command [8], and the
Telnet DO TIMING-MARK option [9]. Both methods have their
advantages and disadvantages. It is recommended that TN3270E
clients and servers that support keep-alives should accept both
NOPs and TIMING-MARKs, and that both sides should always respond
to TIMING-MARKs.
Note that both clients and servers could be configured to
"actively" implement keep-alives. That is, both sides could send
a TIMING-MARK or a NOP in order to determine whether or not the
partner is still alive. Alternatively, network administrators may
wish to configure only one side to send TIMING-MARKs or NOPs; in
this case, the other side would be a "passive" participant which
simply responds to the keep-alives it receives.
Implementors who want their code to be capable of being an
"active" keep-alive participant should make their client or server
configurable so that administrators can set which, if any, keep-
alive mechanism should be employed, and how often the NOP or
TIMING-MARK should be sent on each session.
Upon failure of a session on which keep-alives are used, both
parties should make the proper notifications. A client should
give the user some indication of the failure, such as an error
code in the Operator Information Area of the screen. A server
should notify the host application that the session has been
terminated, for example by sending an UNBIND with type CLEANUP in
an SNA environment.
13.4 Examples
The following example shows a TN3270E-capable server and a
traditional tn3270 client establishing a connection:
Server: IAC DO TN3270E
Client: IAC WON'T TN3270E
Server: IAC DO TERMINAL-TYPE
Client: IAC WILL TERMINAL-TYPE
Server: IAC SB TERMINAL-TYPE SEND IAC SE
Client: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE
Server: IAC DO EOR IAC WILL EOR
Client: IAC WILL EOR IAC DO EOR
Server: IAC DO BINARY IAC WILL BINARY
Client: IAC WILL BINARY IAC DO BINARY
(3270 data stream is exchanged)
The following example shows a TN3270E-capable server and a
TN3270E-capable client establishing a generic pool (non-specific)
terminal session:
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
anyterm IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
(3270 data stream is exchanged)
The following example shows a TN3270E-capable server and a
TN3270E-capable client establishing a terminal session where the
client requests a specific device-name:
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5-E
CONNECT myterm IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5-E CONNECT
myterm IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES
BIND-IMAGE IAC SE
Server: IAC SB TN3270E FUNCTIONS IS RESPONSES BIND-IMAGE
IAC SE
(3270 data stream is exchanged)
The following example shows a TN3270E-capable server and a
TN3270E-capable client attempting to establish a terminal session;
multiple attempts are necessary because the device-name initially
requested by the client is already in use:
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5
CONNECT myterm IAC SE
Server: IAC SB TN3270E DEVICE-TYPE REJECT REASON
DEVICE-IN-USE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2
CONNECT herterm IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
herterm IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
(3270 data stream is exchanged)
The following example shows a TN3270E-capable server and a
TN3270E-capable client establishing a printer session where the
client requests a specific device-name, and where some amount of
3270 function negotiation is required before an agreement is
reached:
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 CONNECT
myprt IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
myprt IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC
Server: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL
RESPONSES IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC
Server: IAC SB TN3270E FUNCTIONS IS DATA-STREAM-CTL IAC SE
(3270 data stream is exchanged)
The following example shows a TN3270E-capable server and a
TN3270E-capable client establishing first a generic terminal
session, then a printer session where the "partner" printer for
the assigned terminal is requested:
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
termXYZ IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
(3270 data stream is exchanged)
. .
. .
(user decides to request a printer session,
so client again connects to Telnet port on server)
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1
ASSOCIATE termXYZ IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
termXYZ's-prt IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST SCS-CTL-CODES
RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES RESPONSES
IAC SE
(3270 data stream is exchanged)
14. Security Considerations
Security issues are not addressed in this document. It is
anticipated that once authentication mechanisms have become well
established, use of them can be made by TN3270E. One of the
important uses of authentication would be to answer the question of
whether or not a given user should be allowed to "use" a specific
terminal or printer device-name.
15. References
[1] Rekhter, J., "Telnet 3270 Regime Option", RFC1041, IBM
Corporation, January 1988.
[2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC1091, FTP
Software, Inc., February 1989.
[3] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD
27, RFC856, USC/Information Sciences Institute, May 1983.
[4] Postel, J., "Telnet End of Record Option", RFC885, USC/
Information Sciences Institute, December 1983.
[5] "3270 Information Display System - Data Stream Programmer's
Reference", publication number GA24-0059, IBM Corporation.
[6] "SNA Formats", publication number GA27-3136, IBM Corporation.
[7] "3174 Establishment Controller Functional Description",
publication number GA23-0218, IBM Corporation.
[8] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD
8, RFC854, USC/Information Sciences Institute, May 1983.
[9] Postel, J., and J. Reynolds, "Telnet Timing Mark Option", STD 31,
RFC860, USC/Information Sciences Institute, May 1983.
16. Author's Note
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 Michelle
Angel, OpenConnect Systems, 1992 - 1993.
- Discussions at the 1993 IETF meetings.
- Discussions on the "TN3270E" list, 1993-94.
17. Author's Address
Bill Kelly
Division of University Computing
144 Parker Hall
Auburn University, AL 36849
Phone: (205) 844-4512