ch04.htm

this describes managing multivendor networks

	<BR>
	
	<LI><I>Remote Spooling Communications System (RSCS).</I> This is VM's job entry facility.
	RSCS runs in conjunction with the GCS.
</UL>

<P>In terms of terminal support, all of these mainframe systems are normally used
with the IBM 3270 line of terminals.
<H2><A NAME="Heading9"></A><FONT COLOR="#000077">Strategy for Connectivity</FONT></H2>
<P>IBM unleashed its Systems Network Architecture (SNA) on the public in 1974. Before
this occasion, the IBM world of data communications was filled with byte-oriented,
synchronous protocols, such as the now-classic bisynchronous 3270-terminal protocol
and the bisynchronous 2780 and 3780 RJE protocols. With the introduction of SNA,
however, IBM replaced these protocols with bit-oriented Synchronous Data Link Control
(SDLC) protocol variations, and the relationships between the various communications
devices became more strict and formal.</P>
<P>In terms of topology, SNA was originally a networking architecture that featured
a central host as the control point. It was continually refined and expanded in subsequent
releases to support networks with multiple hosts and to facilitate host-to-host communications.
Under SNA, each participating device is given a physical unit (PU) definition that
establishes its role in the hierarchical relationship between the terminal and the
host (see Figure 4.4).</P>
<P>The PU definitions are as follows:

<UL>
	<LI><I>Physical Unit Type 2.</I> PU 2 defines a device that controls workstations.
	This includes the traditional IBM cluster controllers (for example, 3274 and 3174)
	as well as the System/3X and AS/400 midrange systems.<BR>
	<BR>
	
	<LI><I>Physical Unit Type 2.1.</I> PU 2.1 is a refinement to SNA that was added to
	enable peer-to-peer communications between intelligent PU 2 devices, such as midrange
	systems, PCs and PS/2s. This is an integral part of the Advanced Peer-to-Peer Networking
	(APPN) aspect of SNA.<BR>
	<BR>
	
	<LI><I>Physical Unit Type 4.</I> A PU 4 device is a communications controller or
	front-end processor (for example, 3705 and 3725). This is a mainframe-oriented device
	that interfaces with the PU 2 and PU 2.1 devices which, in turn, interface with the
	actual terminals and workstations.<BR>
	<BR>
	
	<LI><I>Physical Unit Type 5.</I> A PU 5 device is a host (mainframe) processor that
	provides global services to the SNA network. These devices sponsor the System Services
	Control Points (SSCPs).
</UL>



<BLOCKQUOTE>
	<P>
<HR>
<B><font color=#000077>NOTE:</font> </B>Physical Unit Type 1 and Physical Unit Type 3 have no validity
	in the modern SNA architecture.&#160;n 
<HR>


</BLOCKQUOTE>

<P>While PUs describe network devices that provide physical services, SNA logical
units (LUs) define the contents of the data stream (information flow) between the
PUs. LU definitions include the following:

<UL>
	<LI><I>Logical Unit Type 0.</I> LU 0 is used for unregulated, direct-link communications
	between two entities in the network (typically two programs). Any two programs using
	the LU 0 information flow must be programmed to define and use the same format for
	the information.<BR>
	<BR>
	
	<LI><I>Logical Unit Type 1.</I> LU 1 refers to the format of data sent to and received
	from specialized data processing workstations (such as RJE stations).
</UL>

<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch04/04fig04.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/ch04/04fig04.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch04/04fig04.gif"><B>FIG. 4.4</B></A> <I>SNA Physical Units</I>

<UL>
	<LI><I>Logical Unit Type 2.</I> LU 2 defines the format of data sent to and received
	from the 3270 family of workstations.<BR>
	<BR>
	
	<LI><I>Logical Unit Type 3.</I> LU 3 describes the format of data sent to the 3270
	family of printers.<BR>
	<BR>
	
	<LI><I>Logical Unit Type 4.</I> LU 4 refers to the format of data sent to and received
	from dedicated word processing workstations.<BR>
	<BR>
	
	<LI><I>Logical Unit Type 6.1.</I> LU 6.1 is for program-to-program communications
	using one of the following SNA data formats: character string, 3270 workstation,
	logical message services, or user-defined.<BR>
	<BR>
	
	<LI><I>Logical Unit Type 6.2.</I> LU 6.2 is also for program-to-program communications.
	Programs using the LU 6.2 definition can use either an SNA general data format or
	can define and use their own data format.<BR>
	<BR>
	
	<LI><I>Logical Unit Type 7.</I> LU 7 defines the format of data sent to and received
	from the 5250 family of workstations.
</UL>



<BLOCKQUOTE>
	<P>
<HR>
<B><font color=#000077>NOTE:</font> </B>The Logical Unit Type 6.2 is often used with Physical Unit
	Type 2.1 for Advanced Program-to-Program Communications (APPC). Under this approach,
	the PU 2.1 devices establish a peer-to-peer connection and then a program running
	on each device initiates an LU 6.2 conversation. In support of this, IBM supplies
	a library of LU 6.2 calls to facilitate programming the LU 6.2 interface.&#160;n
	
<HR>


</BLOCKQUOTE>

<P>Beyond the introduction of many new concepts and terminology, the biggest immediate
change that SNA posed to IBM customers was the switch from the well-understood, byte-oriented
protocols to the bit-oriented Synchronous Data Link Control (SDLC) protocol and its
variations.</P>
<P>Under the older bisynchronous formats, the information physically transmitted
and received was relatively easy to understand because at its core was the actual
data being transferred in its native character format. Surrounding that basic data
were additional control characters that signaled the start of data, start of field,
the field attributes, end of field, end of data, and so on. By sitting at a simple
line monitor, a technician could see and identify the data itself.</P>
<P>Unfortunately, this approach has severe limitations. For example, if the information
being sent is binary, it might turn into control characters when it is prepared for
transmission. Because it is inappropriate to have an end-of-data control character
in the middle of the data, additional structures and control characters must be inserted
to handle these special cases. This need for special processing often greatly increases
the amount of data transmitted and also requires an additional amount of processing
overhead before transmission.</P>
<P>To address these and other concerns, IBM developed the bit-oriented SDLC protocol.
Under SDLC, data is not interpreted on a byte-by-byte basis; rather, it is interpreted
as a series of bits, with control bits at the beginning indicating the size and length
of the bit patterns to follow. This bit-level approach to data communications easily
handles standard terminal input/output information as well as the special problems
posed by binary data.</P>
<P>In fact, IBM was so pleased with its SDLC implementation that it submitted SDLC
to the ANSI and ISO standards organizations for their approval. ANSI modified the
basic SDLC definition and called it Advanced Data Communications Control Procedure
(ADCCP), which is used today by many government organizations. ISO changed it into
High-level Data Link Control (HDLC) and it is a model for many other computer manufacturers'
communications protocols. Finally, the Consultative Committee for International Telegraphy
and Telephony (CCITT) further modified HDLC into Link Access Procedure (LAP) and
then into LAP-B (LAP-Balanced) as part of its X.25 network definition.</P>
<P>In SNA, SDLC is the main communications protocol used by workstations, controllers,
and front-end processors alike. To accommodate the variety of devices (3270 versus
5250, for example), SDLC then carries the LU and PU assignments of the transmitting
and receiving devices. Thus, an SDLC transmission can be identified as coming from
a 3270 (LU 2) on a cluster controller (PU 2).</P>
<P>Another connectivity strategy is IBM's MQSeries, a messaging middleware that is
used to connect applications across dissimilar environments. Different programs are
capable of communicating with the MQSeries API, a high-level interface that shields
developers from the various complexities of the different operating systems. MQSeries
is often used by institutions, such as banks, that need to handle large numbers of
transactions. Messages can be placed on queues and retrieved from queues instantly,
and delivery is registered to ensure reliability.
<H3><A NAME="Heading10"></A><FONT COLOR="#000077">APPN (Advanced Peer-to-Peer Networking)</FONT></H3>
<P>APPN is a creation of IBM, which it originally positioned as the successor to
SNA. APPN is used mostly in AS/400 environments, although it can support a mainframe
network in a limited fashion. However, APPN is not able to provide native support
for SNA 3270 datastreams, which makes up most mission-critical traffic.</P>
<P>Cisco Systems and Bay Networks, two major router vendors, both managed to overcome
this limitation by enabling a routed APPN network to support SNA traffic from any
SNA device. Without this solution, each device must contain its own dependent LU
Requestor (dLUR) software. dLUR software is not widely available--it is offered only
for 3174 controllers and OS/2 PCs. Cisco's and Bay's approach provides support for
any SNA device, regardless of whether it possesses the dLUR software. With Cisco
and Bay bridge/routers, it will be possible to run an APPN-based multiprotocol system
that can support SNA traffic.</P>
<P>APPN has a number of strengths. It offers peer-to-peer networking, it can dynamically
discover remote destinations, and it has a traffic prioritization mechanism. However,
APPN does not support dynamic alternate routing. APPN might still be a good solution
for complex networks because of its dynamic destination discovery service.
<H3><A NAME="Heading11"></A><FONT COLOR="#000077">High-Speed Networking</FONT></H3>
<P>IBM is working towards supporting Asynchronous Transfer Mode (ATM) in LAN/WAN
environments. Price is one major barrier to wide area ATM, but another is the amount
of work required to interface ATM with legacy networks.</P>
<P>IBM's solution for joining ATM with its SNA/APPN installed base uses the High
Performance Routing (HPR) feature to provide native access to wide-area ATM networks
for SNA/APPN. SNA is well suited for interfacing with ATM because of its service
features. However, SNA routing is less suited to high-speed networking. HPR fills
in for this area. IBM proposes that the native interface to ATM be through the HPR
feature. Mainframe SNA and APPN would connect directly to ATM using either LAN emulation
or Frame Relay emulation.</P>
<P>HPR is an open technology for routing data quickly and efficiently. The technology
combines some features of APPN, frame relay, IP, and SNA. In case of a link failure,
HPR's built-in rerouting capabilities relieves network managers from having to physically
reroute sessions . In addition, HPR supports SNA priority and class-of-service features.
HPR can run on existing hardware, and interoperates with existing SNA and APPN products.</P>
<P>HPR uses three separate techniques to improve data routing: Rapid Transport Protocol
(RTP), Automatic Network Routing (ANR), and Adaptive Rate-Based (ARB) congestion
control. RTP, a connection protocol, supports data transfer over a high-speed network.
RTP automatically establishes end-to-end connections and generates the appropriate
routing information. In the event of failure, RTP will detect the failure, and recalculate