ch10.htm

this describes managing multivendor networks

		<TD ALIGN="LEFT"></TD>
		<TD ALIGN="LEFT">250 [e-mail]... Recipient ok</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">DATA</TD>
		<TD ALIGN="LEFT"></TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT"></TD>
		<TD ALIGN="LEFT">354 Enter mail, end with &quot;.&quot; alone</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">Dear Jim:</TD>
		<TD ALIGN="LEFT"></TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">How are things in lizard land?</TD>
		<TD ALIGN="LEFT"></TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">-- John</TD>
		<TD ALIGN="LEFT"></TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT"></TD>
		<TD ALIGN="LEFT">250 Mail accepted</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">QUIT</TD>
		<TD ALIGN="LEFT"></TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT"></TD>
		<TD ALIGN="LEFT">221 gateway2.heaven.com delivering mail</TD>
	</TR>
</TABLE>
</P>
<P>It's important to note that the preceding conversation is not pseudocode; this
is how the SMTP protocol really operates. The SMTP client transmits the keyword <B><TT>HELO</TT></B>,
and the server does, indeed, reply <B>250</B>. In fact, the entire SMTP protocol
consists of English-like commands and numerical responses. (Note that the exact phrasing
that follows each keyword might vary slightly from one machine to the next, but they
all follow the same general format.)</P>
<P>Basing TCP/IP service protocols on high-level commands and responses makes them
extremely easy to learn, easy to program, and easy to debug. Unfortunately, while
this approach makes life easier for programmers and protocol developers, it presents
significant headaches for network managers. In particular, there are three major
drawbacks:

<UL>
	<LI><I>TCP/IP is not kind to network bandwidth</I>. Since its inception, TCP/IP has
	assumed it will have sufficient bandwidth at its disposal. Other network protocols
	(for example, IBM SNA, Digital DECnet, Novell IPX) are more sensitive to the fact
	that bandwidth is a valuable commodity that is hard to come by. These other protocols
	use bit-oriented flags for commands and responses instead of TCP/IP's multiple-character
	sequences.<BR>
	<BR>
	
	<LI><I>TCP/IP is open to view</I>. Anyone with a network monitor can see everyone's
	dirty laundry (so to speak). You could certainly argue that anyone with a network
	monitor can see everything in the network anyway. But, with TCP/IP, you don't have
	to work very hard; all the information is laid out bare. You don't even have to decode
	bit-level flags as you do with SNA, DECnet, or IPX.<BR>
	<BR>
	
	<LI><I>TCP/IP makes it easy for humans to masquerade as protocols</I>. Most of its
	application-level protocols use sockets as a means of communication. Using Telnet,
	for instance, you can attach to a specific socket and start manually typing in the
	protocol. So a hacker can Telnet into an SMTP socket and type HELO, and so on. You'd
	be surprised (and horrified) to learn what you can accomplish when you disguise yourself
	as a protocol.
</UL>

<P>None of these drawbacks have slowed down the growth and acceptance of TCP/IP.
Nonetheless, they all raise issues that you should address during the design and
operation of any TCP/IP network. You need to watch your available bandwidth, control
who has access to network monitor software, and most importantly, keep close tabs
on who is accessing your TCP/IP servers and why.
<H2><A NAME="Heading16"></A><FONT COLOR="#000077">Telnet and IBM Systems</FONT></H2>
<P>In most TCP/IP environments, Telnet functions as an interactive, character-level
service. That means that when you type a character on the keyboard, the Telnet client
sends that character over the network to the Telnet server, which then passes the
character on to the application. Furthermore, Telnet was designed with the ASCII
character code in mind--Telnet clients assume they will be communicating with the
Telnet server using ASCII encoding.</P>
<P>Unfortunately, character-level operation and the use of the ASCII character set
are contrary to the way that IBM terminals function in mainframe, System/3X, and
AS/400 environments. In particular, IBM 3270 (mainframe) and 5250 (System/3X and
AS/400) terminal types use these alternate approaches:

<UL>
	<LI>IBM terminals are oriented toward block-mode operation instead of character-mode
	operation. In the IBM environment, information typed on the keyboard is stored locally
	until an Enter key or function key is pressed. At that point the input data is transmitted
	as a block of information. As shown in Figure 10.3, this is a stark contrast to character-mode
	operation, where each key is transmitted over the network as it is being pressed.<BR>
	<BR>
	
	<LI>IBM terminals use the EBCIDC character code instead of the ASCII character code.
</UL>

<P>These two differences affect how IBM devices operate in the Telnet environment
from both the client and server perspective. For example, if an IBM terminal initiates
a Telnet client connection using VT100 emulation, the Telnet client must provide
EBCDIC to ASCII translation and provide terminal emulation for the following reasons:

<UL>
	<LI>To translate display highlights.<BR>
	<BR>
	
	<LI>To translate function key operations.<BR>
	<BR>
	
	<LI>To compensate for the difference between block-mode and character-mode operations.
</UL>

<P>From a purely technical perspective, the EBCDIC/ASCII translation is a minor issue
while the terminal emulation issue is significantly more difficult (but certainly
not impossible).</P>
<P>Using an IBM mainframe, System/3X, or AS/400 as a Telnet server for VT100-style
traffic causes similar difficulties. As in the case of the client, the IBM Telnet
server must provide EBCDIC/ASCII translation and terminal emulation, but for the
server, terminal emulation means:

<UL>
	<LI>Translating display highlights sequences into IBM highlight attributes.<BR>
	<BR>
	
	<LI>Translating keystrokes into standard IBM function keys (for example, PF1-PF24).<BR>
	<BR>
	
	<LI>Translating character-mode operations into block-mode operations.
</UL>

<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch10/10fig03.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/ch10/10fig03.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch10/10fig03.gif"><B>FIG. 10.3</B></A> <I>Character-Mode and Block-Mode Operations</I></P>
<P>The server side of IBM Telnet also has one other interesting consideration. Because
the IBM terminal environment is block-oriented and Telnet is traditionally character-oriented,
a lot of unnecessary traffic is generated on the network. As noted, the Telnet client
typically sends out characters as they are being typed. If these characters are going
to an IBM Telnet server, the server simply collects them until it receives a termination
key (for example, the Enter key) at which point it sends the block to the application.
From a networking perspective, the overhead of sending characters out one at a time
is much higher than the overhead of sending them out as a block (which is the traditional
IBM approach).
<H3><A NAME="Heading17"></A><FONT COLOR="#000077">TN3270</FONT></H3>
<P>In order to alleviate many of these concerns, IBM developed an IBM 3270 terminal
type for the Telnet environment. Released in 1988, the Telnet IBM 3270 terminal type
is a negotiated option between the Telnet server and client that addresses many of
the difficulties associated with Telnet and the IBM environment. These difficulties
are addressed by instilling greater awareness for the IBM environment into the Telnet
3270 client program. Some of the benefits of the IBM Telnet 3270 solution include:

<UL>
	<LI><I>Support for block-mode operations</I>. The Telnet 3270 client collects keystrokes
	and forwards them on to the Telnet server as a block when a trigger key (for example,
	Enter or a function key) is pressed.<BR>
	<BR>
	
	<LI><I>Flexible mapping for IBM 3270 keys.</I> Keyboard mapping files enable terminal
	keys to be mapped into IBM 3270 keys (including function keys) as desired.<BR>
	<BR>
	
	<LI><I>Translation of display attributes.</I> The Telnet 3270 client translates IBM
	field attributes into the appropriate highlight sequences for the client terminal.<BR>
	<BR>
	
	<LI><I>EBCDIC/ASCII translation.</I> The Telnet 3270 client can translate and switch
	between EBCDIC and ASCII character codes as needed.
</UL>

<P>These features work together to create a Telnet client environment that has the
look and feel of an IBM 3270 terminal. Thus, information can be entered into structured
display forms; the Tab key can be used to move from field to field; and incorrect
information entered into fields can be changed prior to transmission.</P>
<P>The Telnet 3270 solution can be used by ASCII terminals accessing IBM systems,
by IBM terminals accessing a UNIX systems, and by IBM terminals accessing IBM systems
over a TCP/IP network. Use of Telnet 3270 to accommodate ASCII terminal access is
by far the most popular scenario.</P>
<P>IBM 3270 support is typically included in a separate Telnet program--usually called
<I>TN3270</I>. This means it is not uncommon to find Telnet client environments that
feature multiple Telnet programs. For example, the IBM RS/6000 includes both Telnet
and TN3270 programs. The Telnet program negotiates for the current terminal type
while the TN3270 negotiates for the IBM 3270 terminal type.


<BLOCKQUOTE>
	<P>
<HR>
<B><font color=#000077>NOTE:</font> </B>An enhanced version of TN3270 is also available. This version--termed
	TN3270E--enables some addition 3270 features in the Telnet environment, the most
	important feature being printer support. n 
<HR>


</BLOCKQUOTE>

<H3><A NAME="Heading18"></A><FONT COLOR="#000077">TN5250</FONT></H3>
<P>When TCP/IP connectivity was first introduced to the IBM AS/400 environment, the
AS/400 supported Digital VT100 and IBM 3270 Telnet terminal types. Telnet access
using the VT100 terminal type posed exactly the same difficulties found in the mainframe
environment (for example, ASCII instead of EBCDIC and character-mode instead of block-mode),
so Telnet 3270 access seemed a more logical choice. Unfortunately, 3270 access into
the AS/400 had its own set of problems.</P>
<P>Telnet 3270 traffic going into the AS/400 goes through the exact same handling
routines applied to &quot;real&quot; IBM 3270 terminals attached to the AS/400. These
routines translate the 3270 data streams and function keys into 5250 data streams
and function keys, so application programs only &quot;see&quot; 5250 terminals. Because
3270 and 5250 terminals are not functionally identical, the translation process introduces
new considerations regarding keyboard support, data entry field handling, and screen
display attributes.</P>
<P>To address these considerations, IBM developed a definition for a new Telnet terminal
type: the <I>Telnet 5250</I> terminal. Introduced in 1991, Telnet 5250 operation
provides all of the benefits of Telnet 3270 operation (for example, block-mode support,
EBCDIC/ASCII translation, and so on), and also addresses the limitations of the 3270-to-5250
translation process by making the Telnet client program aware of the unique characteristics
of the 5250 terminal. Thus, a Telnet 5250 client provides the following features
not found in a Telnet 3270 client:

<UL>
	<LI><I>Support for 5250-specific keys.</I> The Telnet 5250 client permits flexible
	keyboard mapping like Telnet 3270 and also provide client-based emulation of the
	&quot;Roll Up&quot;, &quot;Roll Down&quot;, &quot;Field Exit&quot;, &quot;Field +&quot;,
	and &quot;Field -&quot;, and other unique 5250 keys.<BR>
	<BR>
	
	<LI><I>Enforcement of numeric-only fields</I>. The Telnet 5250 client recognizes
	numeric data entry fields and restricts data access on a local basis.<BR>
	<BR>
	
	<LI><I>Support for the full range of highlight attributes</I>. The Telnet 5250 client
	provides direct translation between 5250 highlight attributes and the actual terminal
	running the Telnet client program.
</UL>

<P>The enhancements available in the Telnet 5250 solution make it superior to Telnet
3270 for accessing an AS/400 via Telnet. As in the case of Telnet 3270 clients, IBM
5250 support is normally available as a separate client program, often called <I>TN5250</I>.</P>
<CENTER>
<P>
<HR>
<A HREF="ch09.htm" tppabs="http://docs.rinet.ru:8080/MuNet/ch09/ch09.htm"><IMG SRC="previous.gif" tppabs="http://docs.rinet.ru:8080/MuNet/button/previous.gif" WIDTH="128" HEIGHT="28"
ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="ch11.htm" tppabs="http://docs.rinet.ru:8080/MuNet/ch11/ch11.htm"><IMG
SRC="next.gif" tppabs="http://docs.rinet.ru:8080/MuNet/button/next.gif" WIDTH="128" HEIGHT="28" ALIGN="BOTTOM" ALT="Next chapter"
BORDER="0"></A><A HREF="index-2.htm" tppabs="http://docs.rinet.ru:8080/MuNet/index.htm"><IMG SRC="contents.gif" tppabs="http://docs.rinet.ru:8080/MuNet/button/contents.gif" WIDTH="128"
HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A> <BR>
<BR>
<BR>


<P>&#169; <A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/copy.htm  \n\nThis file was not retrieved by Teleport Pro, because it was deleted using Teleport Pro\'s Delete command.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/copy.htm'" tppabs="http://docs.rinet.ru:8080/MuNet/copy.htm">Copyright</A>, Macmillan Computer Publishing. All
rights reserved.
</CENTER>


</BODY>

</HTML>