There are a number of scenarios in which smaller computers or computing environments must interact with larger ones. Such interactions can take place within a single site or even a single room, or they can involve remote connections. We'll begin this chapter with a look at the history of smaller-to-larger hookups since contemporary solutions to the puzzle of linking to minis and mainframes must build upon what this history produced. Then we'll examine the means by which connections to minis or mainframes can be made; today's thoroughly distributed environments require such connections. Finally, we'll present scenarios that illustrate linking to minis and mainframes.
There was a time when the term network meant "a big computer with a bunch of terminals hooked to it." But with the advent of PCs in the 1980s and the appearance of LANs soon thereafter, the lexicon of data processing was forced to expand. Networking became as much the province of the small computer as of the large.
The first inroads made by PCs into large machine/batch-processing environments came about because of the ability of a PC to wear two hatsóthat is, to act not only independently but also as a terminal to a mini or a mainframe. Such emulation was accomplished almost entirely by means of software. But as with all data entry or display devices smart or dumb, a cable had to connect the little guy to the big guy. Direct PC-to-mini/mainframe connections were usually cabled with coaxial cable and often required such extra hardware as multiplexers or communications controllers.
Figure 16.1 shows a PC-direct-to-large computer link of this sort.
Figure 16.1 PCs were frequently connected to minis or mainfreames with a coaxial link.
But simply laying down a length of cable wasn't enough to cut the mustard. The impersonation of a terminal by a PC was made possible by the development of software that allowed the PC to transmit to the mini or mainframe at the far end of the cable those signals expected from it and that identified its data entry and display devices. For instance, an early (and still widely used) terminal emulation package generated from the PC that ran it the control characters (such as start of text and so on) that identified it as a member of the 3270 family of IBM terminals.
In addition, the earliest PC-to-big machine hookups often were supported by the following two additional hardware devices:
One of the most widely used families of emulation software was and still is IBM 3270 emulation. Families is appropriate because many vendors produced such packages, which provide PCs with the ability to masquerade as any one of a number of the 3270 series of terminals. These models are intelligent terminals. That is, they have the following characteristics.
Similar combinations of communications controllers and emulation software have been and remain avialable for the DEC world. In fact, the VT100 terminal emulation is still one of the most widely used applications of this sort.
Even if at least some of your connectivity needs might be met by the controller/emulator combo, you must still evaluate the particular models you're considering. As might be expected, not all emulation software, whether 3270, VT, or other, is compatible with every IBM PC clone. In addition, you must be certain that the package you choose not only maps PC keystrokes to the signals that the large computer to which you're connecting expects but also provides for transfer of data to and from the host. That is, the emulator must be compatible with whatever mini or mainframe operating system is involved.
At the end of the 1980s and during the first couple of years of this decade, token-ring networks functioned, not as autonomous LANs, but as the highest-tech solution to the PC-to-mini/mainframe puzzle. During this period, IBM made Token Ring a "strategic path;" however, there were reasons other than market forces that dictated its use.
The use of token-ring as a means of linking to minis and mainframes foreshadowed many of the concerns that system and network managers would next have to grapple with, connecting LANs to larger computing environments.
When a LAN and a mini or mainframe are at the same site, their operating environments and circumstances still differ enough to make a direct connection of most of the types discussed to this point impractical. Even a token-ring LAN, if it is truly a LAN and not merely a physical segment of a larger computing environment that happens to consist of PCs, is functionally distinct enough from the machine that it must talk to that provision must be made for its members to be able to continue to act as LAN workstations. Only when an exchange of data with the mini or mainframe is needed should this role be exchanged for that of terminal. Therefore, establishing a LAN-to-large link is in effect, if not in fact, the same as establishing a remote access connection.
Some traditional and some more recent applications seem to be tailor-made for remote access and by extension for the PC-to-big-machine link. Chief among the first group are database-intensive tasks. If a station's primary reason for being is to input, access, or massage some portion of a database, there is little reason, given today's technology, to require that station to be close at hand to its host. The easy availability of software for the remote management of networks makes such neighborliness even less necessary. Of tasks that have more recently come to be popular with the "average" PC user, twoófile transfer and electronic mailóalso imply the processing and storage capacities of minis or mainframes, as well as the possibility of remote access.
Because of their need for real-time or near-real-time access to data, from a variety of locations, a number of types of organizations can benefit from connecting PCs to minis or mainframes, whether through in-house or remote access:
There are three major types of remote access, each of which has its own methods and technologiesófor more information on these and other remote access concepts, turn to chapter 27, "Adding Remote Network Access (Telecommuting)." These three, which can also serve as models for the small-to-large-computer connection, are
For a more detailed discussion on the technologies involved in accomplishing the three types of remote access and in particular the remote control and remote node methods, turn to chapter 25, "Adding Network Modems."
The following table summarizes these remote access schemes.
| Has These Strengths | And These Weaknesses |
| Application-Specific | |
| Consists of a single
piece of software; therefore low-cost, for example, remote file access software such as Carbon Copy |
Only allows access to a single application
May require separate host and
May require a dedicated gateway PC Remote Control |
| Remote Control | |
| Handles a large number of simultaneous sessions
Compatible with most LANs and mini or mainframe hosts Provides centralized management of remote stations |
Can be expensive to set up and operate.
May not offer remote management
Support for Macintosh not readily available |
| Remote Node |
Can support the widest variety of PC platforms.
Can support the widest variety of applications.
More applicable to mini-based LANs than to PC-to-mainframe connections.
Figure 16.2 follows traces the paths between the definition of your user's needs and the access methods that best meet those needs.
Figure 16.2 Clearly defining users needs facilitates choosing the right access method.
Now that you've walked your way from "I only have seven users who need to talk to the corporate mainframe, and of those, no more than three need regular access" to "Looks like some form of remote control server is what's called for", let's take a look at the more detailed requirements your choice must meet:
Support for as wide a variety as possible of operating systems. This requirement applies to both ends of the conversation; look for a remote access solution that can deal with
Support for as many LAN operating systems as possible. Look for a technology that can handle
Connectivity-specific features supported. Look for
As important as its ability to meet existing needs is the ability of a network to grow to meet those needs as they change. In maintaining and enhancing access, for instance, you may have to add ports or support for PBX-type (that is, branch office) features or enhance or change cabling. In addition, recent studies have found that while the number of network nodes and other means of remote access grows by about 40% annually, and the number of LANs and LAN segments increases by as much as 30% each year, budgets for system and network management grow by no more than an average of 12%.
Such conditions in the overall computing environment will undoubtedly affect the configuration of a link between PCs and larger computers. You can get a jump on needed future small-to-large connection (and on network management in general) by using some means of network modeling.
As distributed processing grows and takes on new wrinkles, the number and rate of appearance of variables that system and network administrators must deal with grow proportionately. In such circumstances, paper-and-pencil analyses become unwieldy; there simply isn't enough time, money, or resources to study, model, and only then recommend.
Unfortunately, only a few computer-aided network design (CAN-D) applications are available today, although the number is expected to increase steadily. However, the principles upon which such packages operate can be applied to a do-it-yourself analysis to make it as efficient as possible.
Probably the best-known CAN-D package currently available is the Block-Oriented Network Simulator (BONeS) PlanNet from Systems and Networks.
Keep the following points in mind when conducting your analysis:
Skip back to chapter 4, "Upgrading to a WAN," if you need to review the characteristics of a WAN.
ï Include a list of all possible interconnectivity devices. In other words, even if you don't currently use or don't think you'll ever need a translating bridge, include translating bridges in your set of possible connectors.
ï Produce a list of all possible applications with which the distributed environment does or may have to deal.
ï Have at hand a thorough and accurate outline of traffic patterns for individual applications, individual workstations, individual servers or hosts, and the environment at large.
With these outlines in hand, you can evaluate any remote access, or other anticipated, network enhancement, simply by measuring the effect of every candidate on each of the elements just presented.
Figure 16.3 sketches part of one possible such checklist.
Figure 16.3 A checklist aids in modeling remote or small-to-large access.
Let's review the definitions of user needs presented in figure 16.2, and use these as the basis for a discussion of specific technologies for linking to minis and mainframes.
If your environment is one in which a handful of users, of individual PCs or networked ones, need to carry out a single application that involves interacting with a mini or mainframe host, a software solution, in combination with either a coaxial direct connection or a dialup link as appropriate, will suffice. Packages like the following are good candidates.
If the application in question is solely mini- or mainframe-residentóthat is, if the PCs accessing it need no more than terminal emulation capabilities to do soóthe Terminal utility available with Windows will fill the bill. And it's free!
An ingeneous form of application-based access has been implemented at the University of California at Berkeley, running Carbon Copy on a dedicated LAN workstation. This configuration has proven faster than a true bridge for some applications. It doesn't pass entire executable to the remote, but rather only displays and keystrokes, thereby achieving high performance while using very little bandwidth. While this imaginative, low-cost solution does not offer links to minis or mainframes, it could be modified to do so.
Consider the following:
A non-profit organization headquarters in the Pittsburgh area must find a way for the PCs on its two LANs, one NetWare- and the other TCP/IP-based, to download statistical data from a mainframe on a WAN operated by, let's say, the Federal Government's Department of Health and Human Services.
In researching the task, the network administrator identifies, as the potential source of her worst headaches, the fact that her LANs are connectionless, while the WAN through that they must communicate with the mainframe is connection-oriented.
A LAN workstation doesn't precede its messages with a request to the intended recipient. It simply transmits. As a result of this approach, LAN connectivity devices like bridges and routers assume that the bandwidth that is available to them is effectively unlimited. However, on a WAN, there's no such thing as such infinitely available bandwidth and no such thing as CL transmissions. On a WAN, all protocols are connection-oriented and operate as virtual circuits. That is, they identify a recipient and set up a circuit between sender and receiver before a message is transmitted.
But, ever intrepid, our network administrator comes up with a solution. She implements a Switched Multimegabit Data Service (SMDS).
An SMDS is connectionless, but simulates a connection-oriented environment. SMDS access devices pass 53-byte packets to a switch. That switch determines the destination address and passes messages one at a time and in the correct order as do connection-oriented protocols to that destination over any available path.
Because SMDS is connectionless, it is readily compatible with LANs. SMDS can easily feed into WANs because it employs T1 and T3 circuits as its delivery system. SMDS also "bridges" other LAN/WAN gaps:
For more information on SMDS as a LAN-to-WAN solution, contact, the SMDS Interest Group (SIG), an industry association of service providers, equipment manufacturers, users, and others working to speed the proliferation and interoperability of SMDS services, products and applications.
Phone: (415) 578-6979
Fax: (415) 525-0182
E-Mail: sig@interop.com
WWW: http://www.zdexpos.com/zdexpos/associations/smds/home.html
Another solution Ms. Intrepid might have considered is the DIRECTROUTE family of products from Symplex Communications. These products use a combination of hardware and software features to present connection-oriented, switched internetworking that offers, in addition to the abilities commonly found in connection-oriented routers, bandwidth management, call and connection management, and data compression.
About two blocks east on Grant Street from Ms. Intrepid's office, a LAN manager in a multi-national corporation's headquarters grapples with another variant on the small-to-large model. He must provide every PC on a departmental Novell LAN with the ability to access all the resources of the Ethernet LAN in another department and to carry out application-oriented access with a mini in that second department as well as a mainframe in MIS.
Like his peer down the street, this LAN manager is up-to-date on upgrading and repairing networks. His reading on this topic allows him to select a single communications controller that meets at least most of the criteria detailed in the "Details To Look for in Remote Access Methods" section. The component in question offers
Such controllers include the Remote Annex line of products from Xylogics, the LANRover from Shiva Corporation, and components from U.S. Robotics and Microcom. However, some of these boxes have drawbacks. For instance, the relatively low speed of phone lines can be a problem which the LANRover cannot overcome.
Combinet manufactures a connection controller that combines an Ethernet bridge and an ISDN terminal adapter. This component can be hooked up to an ISDN line that has another such Combinet component on the other end, yielding 56Kbpsñ128Kbps transmissions between LANS or between an individual user and a LAN. Actual bandwidth and line costs depend on whether true ISDN service is available between one Combinet controller and the other. The advantages of this solution are its speed and seamlessness; there is very little performance difference between a remote station using it and a local LAN station. However, this is not a low-cost connectivity option. Each of the pair of devices needed for a single ISDN hookup cost approximately $2,000.00.
Hardware-driven access to minis and mainframes can also be accomplished by a PC-based server that houses a modem, a multi-port serial card, or a switch that allows a number of sub-channels to access a single RS-232 circuit. Multi-port cards are available from companies such as DigiBoard. (For more detail on selecting and implementing access hardware, see chapter 25, "Adding Network Modems.")
Like all data processing technologies, the means of linking PCs or LANs to minis, mainframes, or WANs have evolved at near-warp speeds. The following checklist will help you make an informed evaluation of access methods for such connections.
Nature of communications media (for example, phone lines) that are available for the connection
