|
|
|
|
Accessing
Mainframe and Minicomputers: X marks the spot Many
large organizations have made the move from minicomputers and mainframes with
character-based terminals attached to stand-alone PC systems running either
Windows 95 or Windows NT. In many
cases, though, it’s impossible to totally replace the larger systems because
of legacy applications or the need for company-wide single-point data access.
In those cases, terminal emulation software on a Windows PC allows access
to the larger systems. Unfortunately, the software provided with Microsoft’s
Windows versions is a lackluster terminal emulation package, lacking support for
many popular terminals and more advanced protocols like NFS.
To fill that void, a healthy third-party market of TCP/IP suites,
dedicated mainframe access packages, and X client software has evolved. In
this article we look at what you need to consider when purchasing a TCP/IP
suite. A number of suites have been tested for overall performance and
reliability, as well as their end-user friendliness. We also take a long look at NFS clients and servers, as many
organizations have to integrate new Windows NT machines into networks that rely
on UNIX or mainframe-based NFS file sharing. Third-party
TCP/IP packages fall into a number of categories, primarily based on whether you
need mainframe terminal emulation only, TCP/IP emulation suites, X client
software, and NFS access. Some
packages are available in flavors that cover one or more of these categories,
while others are specifically designed for a single task. A different approach is taken by some vendors who offer
hardware-based connectivity options for TCP/IP networks and mainframes,
providing fast and efficient emulation of terminals. Hardware
solutions Hardware
based systems have two major advantages over software systems: speed and
flexibility. These allow for very
fast connection to a network with support for ESCON and Bus & Tag
interfaces, which software cannot hope to properly model.
These solutions will not suite many organizations unless they are still
very mainframe dependent and need to offer an interface between PC subnetworks
and the mainframe. Polaris
Communications is one of the largest vendors of such solutions, offering their
boards as OEM products to a number of vendors.
The Polaris hardware is PCI-based and supports data transfer at rates up
to a blazing 200Mb per second (using ESCON).
Plugged into a Windows NT workstation, the hardware and software
integrate smoothly with mainframes and can emulate a number of IBM control
units. From a system that runs one of these Polaris boards, you can support a
network of SNA clients (including Windows NT and Windows 95) with full TN3270
terminal emulation. The problems with hardware-based access solutions is their
cost: a typical system will cost about $12,000. There are several alternatives to Polaris boards, including
OBM, BusTek, and General Signal. TCP/IP
Suites Sometimes
it seems that everywhere you turn there’s a new TCP/IP suite on the market.
With the virtual demise of IPX/SPX for larger networks, TCP/IP
integration is vitally important for all machines.
While Windows NT and Windows 95 offers basic TCP/IP capabilities as
delivered by Microsoft, more advanced features are often required.
That’s given rise to a lucrative third-party TCP/IP software market,
into which many newcomers have rushed over the last couple of years. Although all these packages offer TCP/IP capabilities, not
all offer industrial-strength enterprise-wide support. Selecting the right
TCP/IP suite for your organization requires you to consider a number of factors,
including the protocols you will be running on your networks. For example, if
you run NFS or AFS, you need a TCP/IP suite or add-on that supports these
protocols. We’ll look at NFS
clients specifically later, so for now we’ll concentrate on suites that may or
may not have NFS support included (often as two different versions of the same
suite). Windows
NT handles TCP/IP through part of the layered operating system design. Device
drivers define the hardware-specific characteristics of the network interface
card. The device drivers talk to a
low-level software layer (Network Drive Interface Specification – NDIS, Open
Data-Link Interface – ODI, or one of several packet drivers) which control how
the network interface card handles data. This data handling is
independent of the network operating system protocol. Above the low-level
software layer are subsystems to handle specific network protocols (TCP/IP in
this case, although IPX/SPX and NetBIOS are supported in the same way). Windows
NT places the Windows Socket API above the TCP/IP layer to perform
network-related high-level tasks for applications.
Several
of the TCP/IP suites have taken a bottom-up design approach, trying to replace
the Microsoft TCP/IP kernel with a faster, more secure and reliable kernel.
Others build upon the Microsoft kernel with extra capabilities.
Of the two, the replacement kernel approach is a better solution as it
does offer a noticeable performance enhancement, as well as better integration
with the rest of the suite. Although
no TCP/IP products we evaluated are yet ready for the next generation of IP (IP
v 6, or IP next generation), most of the vendors are readily IPv6-compatible
suites for release as the protocol is rolled out. Having an upgrade path to an IPv6-compatible system should be
a major requirement for anyone investing in a large-scale TCP/IP suite rollout
or moving to WinSock 2.0 (neither of which Microsoft TCP/IP supports).
For smaller groups, the addition of IPv6
and WinSock 2.0 may not be as critical and can be added later. What
should you look for in a TCP/IP suites? A
replacement TCP/IP kernel is an excellent place to start, as it tends to offer
better security, reliability and performance than Microsoft’s product. A suite
that has been around for a while and been thoroughly tested in a variety of
networks tends to be a logical choice. Then look at configuration protocols.
When a machine joins the network, you either configure each machine
manually with an IP address, or let a server configure it automatically. IP
address assignment can be achieved through Windows’ DHCP (Dynamic Host
Configuration Protocol) or through BOOTP (Boot Protocol).
If you need IP assignment, look for one or both of these protocols (DHCP
is almost always Windows NT Server based, while BOOTP is almost always
UNIX-based). The
next consideration is the ease of configuration and maintenance. This is often
hard to judge from product literature or reviews, but look for a package that
offers both Windows and command-line interfaces for maximum flexibility.
The best suites offer both types of interfaces, as well as consistent
interfaces between all the support tools and components in the suite.
A
complete set of tools would seem to be logical, but there are some suites that
skip one or more of the following components for one reason or another: telnet
and rlogin (for remote connection and remote execution of commands); FTP and
TFTP (for file transfers), LPD or LPR (network printing), basic utilities like
ping and sendroute, and support for protocols like Network File System (NFS),
Network Information Service (NIS) and Domain Name Service (DNS).
Other components often included in a TCP/IP suite are e-mail packages, X
clients, support for PPP and SLIP (for remote access through a modem), and Web
browsers. If
you do use a suite’s e-mail component, look for a suite that includes all the
standard protocols like Simple Mail Transfer Protocol (SMTP), Post Office
Protocol 3 (POP3), and Internet Mail Access Protocol 4 (IMAP4).
Verify that the suite’s e-mail system will integrate with your existing
organization’s e-mail system, as some won’t work well with proprietary mail
systems. X
clients are a source of much of the TCP/IP suite’s sales, allowing Windows
systems to access UNIX X and Motif servers with a similar interface.
X implementations vary considerable with these suites, and not all behave
well. The speed at which X clients
operate also varies noticeably depending on the suite, and some suites offer
extra features that enhance a user’s session, allowing better integration
between X and Windows NT. Since this is not intended to be a comparison of X
packages, per se, we didn’t evaluate the suites that do offer X any
differently than those that don’t. Of
the X implementations that we did experiment with, though, two stood out:
Hummingbird’s eXceed and WRQ’s Reflection X.
Both have talented, flexible, and highly configurable X clients that
worked with all our X servers. TCP/IP
suites can be used to access non-UNIX systems, of course, using terminal
emulation. If you are accessing a
mainframe or minicomputer, flexible terminal emulation options are a boon.
Many suites limit terminal emulation support to a couple of basics: IBM
3270 and DEC VT220. Some packages
add TN5250 emulators, used to connect to IBM AS/400 systems. While these do
allow reasonable behavior connected to larger systems, more versatile emulations
add features such as split screening, better color and font support, and
graphics. If the suite you are
choosing will be used to access a larger non-X system, make sure that
applications users will access work well with the terminal emulators provided.
Having to buy an additional terminal emulator on top of your TCP/IP suite
is annoying and expensive. Of
the suites we tested, most vary only in the configuration and administration
features. All offer the basic
TCP/IP protocols and utility support, with fairly consistent performance.
The accompanying table shows the basic features and performance results
achieved through a repeated script that exercised almost all the protocols and
utilities in turn, looping for twenty times.
Variation in performance numbers was marginal over the test length,
making this a poor indicator of which suite to choose.
We’ve also rated all the suites based on their features.
This is a composite rating of the ease of installation, configuration and
management, combined with the ease of use of each of the components. While
several of the suites offer different ways of achieving the same end, we judged
the products as a single suite instead of by comparison to other suites.
A suite that continues the same interface, actions, user friendliness and
help system from component to component scores high.
Also scoring high are tools that add extra features to the suite. NFS
and NT Network
File System, developed by Sun Microsystems, is the standard network-wide
file-sharing method on most UNIX systems. Since
any network that has a mix of NT and UNIX platforms (whether workstations,
minicomputers, or larger systems) will have to share files between the two
operating systems, NFS is the most logical method to accomplish this task.
Support for NFS on NT platforms is excellent, with at least a baker’s
dozen different software packages claiming NFS support, and several NT-based NFS
servers also available. Since
the number of NFS servers for NT is small, it’s worth while starting with that
aspect. Why bother using a Windows
NT system as an NFS server if you have UNIX platforms available?
Most likely because the applications that most need sharing are NT-based.
By placing an NFS server on an NT platform, all the NFS-compatible
clients (NT, Windows 95, and UNIX) can gain access to the application files.
Since a network can have any number of NFS servers, it makes a lot of
sense to spread the NFS server load across several systems when large networks
or several applications on different operating systems are involved. Integrating
NFS and Windows NT offers software developers an interesting problem.
They must balance the need for providing translation between NFS-specific
file requests and Windows NT filesystem requests (Both FAT and NTFS) as fast as
possible, while adding support for Windows NT user authentication, group
identifications, and Access Control List (ACL permissions).
Throw into the mix NFS’ security and UNIX naming conventions, and
development has the chance to become sticky.
A quick warning for those of you running NT with FAT or FAT32 filesystems:
NFS’ file-based security mechanisms do not translate to these filesystems
because NT does not have ACLs for each file.
To enforce proper NT and NFS security you must be running either HPFS
(pre-NT 4) or NTFS. To
test NFS server software, we installed three products on different NT Server 4.0
systems and used several of the client packages described later to access data
on them. To test UNIX access, we used four IBM, HP and Sun workstations to
access data files on each NT server through a Fast Ethernet network.
The Servers were all identically configured ALR Revolution 2XL systems
with dual 266MHZ Pentiums, 128MB RAM, and 9.1GB Fast-SCSI hard drives.
To compare performance of the NT-based NFS servers, we tested against a
Sun Solaris 2.5 NFS server running on a 120MHz SPARCstation, as well as an HP-UX
10.2 server running on a 715 workstation. The test procedure is described later. We
tested Attachmate’s PathWay Server NFS for Windows NT (version 1.0), FTP
Software’s InterDrive Server (version 2.0) and Hummingbird’s NFS Maestro
Server (version 5.1). All three are
stand-alone NFS packages, which offers the maximum flexibility for
administrators. Some TCP/IP client
suites also include NFS server software but they tend to have less flexibility
and features than the stand-alone products.
Therefore we ruled them out of the server test.
A fourth server package, Intergraph’s DiskShare, could not be obtained
for review. The versions we tested don’t support NFS 3, the latest standard.
New versions with NFS 3 support are expected to be out by the time you
read this. Comparing
the three NT servers with UNIX server yielded an interesting result; the fastest
packages weren’t UNIX-based. Both the Hummingbird NFS Maestro Server and FTP
InterDrive Server were faster than the Solaris NFS server, with the Attachmate
PathWay Server NFS running neck and neck with the HP-UX server, slightly slower
than Solaris (although it was difficult to obtain proper results for PathWay
Server due to software crashes discussed shortly). UNIX-based NFS administration
and configuration has never been user friendly, and while all three NT packages
do a very good job of using the Windows interface to make the setup and
management process better, Hummingbird’s NFS Maestro Server took top honors
with a superbly designed interface. Considering the price point of NFS Maestro
Server, this is the NFS Server product of choice despite the fact that it was a
little slower than the fastest, FTP InterDrive Server. InterDrive Server does
have a slight edge on NFS Maestro Server in administrator statistics and NFS
usage monitoring, and a better ability to fine-tune the server’s priorities. Hummingbird
NFS Maestro Server supports UNIX-style export files which allow your NT system
to look just like an NFS export file on a UNIX box. If you administer both operating systems, then this little
item makes moving between platforms a breeze.
FTP’s InterDrive Server doesn’t support standard exports, but it does
have a proprietary scheme that allows partitions to be exported in such as way
as to appear like a standard export. As
a side benefit of a proprietary scheme, though, InterDrive does allow some
features like automatic switching of case of FAT and FAT32 filenames. What
about Attachmate’s PathWay Server NFS for Windows NT? It crashed. And
crashed. And continued to crash at
regular intervals. When it was
running, PathWay Server chewed up our server’s RAM at alarming rates.
Norton Utilities for Windows NT reported continued alarms as memory got
short. After a two hour testing
cycle, our 128MB RAM was completely used up, mostly by PathWay Server (by
contrast, the other two products never exceeded 20MB total).
To top that off, PathWay Server took up our entire NT file cache of 75MB
in the same time span. We can only
assume that these problems are endemic to version 1 of this software, and that a
much more seasoned and robust product will follow with version 2.
NFS
client packages are a different kettle of fish altogether, and there’s a lot
to choose from. To test the client
software we used a Windows NT Workstation 4.0 Pentium Pro system with 64MB RAM
and 9.1GB Fast-SCSI hard drives. Over
a Fast Ethernet network, we had each client package run three sessions of a test
script. We used Mercury Interactive’s WinRunner to control the scripts.
Each script read and wrote files of sizes from 1kB to 3.5MB to each of
the three NT NFS servers and two UNIX NFS servers, with the emphasis weighted to
reading files (as would be the case in most networks). Each script was run for
two hours, and used to gauge performance of the client and each server.
Only one client ran at a time when the client evaluations were being
performed, but eight clients (that’s all the machines we had) ran
simultaneously when testing the servers under load.
We used NFS 2 for all our tests. As
a reference, we also used IBM AIX, SunSoft Solaris, and HP HP-UX workstations to
repeat the NFS client tests. As
with the server packages, Hummingbird
and FTP both provided excellent NFS client packages. This time the NFS Software package wins top honors because if
its excellent configuration flexibility, performance, and price.
WRQ’s Reflection NFS was the fastest of the products we tested. Although
most of the NFS client packages offer clean configuration and administration
interfaces, FTP Software’s InterDrive Client stood out for its ability to
interface with the Network Neighborhood integration. When you right-click on an NFS exported object InterDrive
allows you to create aliases that applications that are limited in their network
and drive abilities can understand. For
many older Windows and DOS applications, this ability may be the only way to
provide access to NFS objects. InterDrive
lets you set up user and password access rights for each object, as well as use
the Properties window to show details about the NFS export.
Not many other NFS clients are this capable and Windows-friendly.
Even better, during all the testing we conducted InterDrive didn’t once
lose a mount or attributes associated with a mount, which cannot be said for
most of the other clients. There
are a couple of weak spots with InterDrive: it doesn’t have a convenient and
simple way to establish an NFS export and there’s no support for
industry-standard NFS utilities. There’s
also no NIS capability provided for verifying access to NFS exports, but these
factors didn’t change our mind about the best of the bunch. Century
Software’s TERM Professional crashed on us in our testing, although it did
behave just under average for the few cycles we recorded. We did confirm that
our copy (version 3.3) was recent, and didn’t manage to solve the problem.
TERM Professional has no integration with NT to speak of; all changes are
through the Network applet. Esker’s
Tun NET also didn’t complete the testing suite properly due to crashes we
couldn’t solve. Based on the brief testing we did complete, performance was
poorer than average. A positive aspect of Tun NET is its ability to connect to
exports in three ways: through the Network Neighborhood, Explorer, or from the
command line. It was nice having
the choice, although we’re not sure how many people would require this option. Frontier
Technologies SuperNFS is part of the company’s growing TCP/IP suite. However,
while some other components in the Super suite are feature-rich, this one
isn’t. There’s only a poor
configuration routine and some utilities are either very badly implemented or
missing altogether. SuperNFS doesn’t support server-specific logins.
Performance was average. SuperNFS can be configured as a peer-to-peer NFS
server. Hummingbird
Communication’s NFS Maestro Client offers support for most authentication
schemes likely to be used in mounts, including NIS. It is also the only NFS client to offer a vendor-developed
replacement for PCNFSD, which supports both 16-bit group IDs and full 32-bit
file locking (both features lacking in PCNFSD). While perhaps not as friendly as
some of the other clients, NFS Maestro is perfectly suited for those who are
veteran users and want to get on with the job as quickly as possible.
Intergraph
Software Solutions DiskAccess was one of the poorer performers in the client
group, and also lost a coupe of mounts over time. On the plus side, DiskAccess does have a very good
configuration routines. DiskAccess creates its own Applet in the Control Panel,
which few other packages do. Network
Computing Devices’ Marathon for Windows NT had poor behavior in our tests,
losing mounts and offering lower-than-average performance. Topping that off,
over a two hour test Marathon crashed completely six times. Rather than
developing their own tool, NCD seems to have licensed an early version of FTP
Software’s InterDrive Client and dropped most of the newer features. There are
no NFS utilities bundled with Marathon, and configuration and setup is
annoyingly difficult for a relatively simple task. NetManage
Chameleon UNIXLink 97 is the follow-on to a veteran product, ChameleonNFS, which
several years ago was one of the few NFS client packages available for Windows.
Unfortunately, NetManage hasn’t kept up with the competition in terms of
features and utilities, offering no add-ons or support for NT file attributes..
On the positive side, UNIXLink behaved solidly throughout the tests and while
performance was only average, one feature stood out. UNIXLink allows you to
create groups with pairs of logins and passwords for different servers to access
exports transparently, negating the need to login in separately. The process is
fast and convenient. A definite weak point in our testing was the Control Panel
applet’s ability to retain only one configuration set for the entire system,
so reconfiguring for different servers meant losing old configuration data.
The ability to save several data sets would help enormously.
UNIXLink can be configured as an NFS server, but only for peer-to-peer
situations. SunSoft’s
Solstice Network Client (replacing the venerable PCNFS Pro) surprised us with
only slightly-above average performance, as we had expected better.
The configuration and management utilities are very good, but not
noteworthy. WRQ’s
Reflection NFS Connection for NT was slightly faster the InterDrive in our tests
and has an excellent NFS Administrator application. NFS Administrator offers an
Explorer-like interface to files and drives. Summary We’ve
seen through the testing results that most of the TCP/IP suites behave much the
same when it comes to standard functionality.
However, they do differ noticeably when configuration and manageability
are factored into the formula. Choosing
the right package for your needs will be a balance between these factors and the
roll-out price. Every company
offers multiple unit discounts and site licenses, usually with considerable
savings over the per-seat prices shown in the tables. We’ve also looked at NFS in some detail, based primarily on the need to support NFS on Windows NT workstations and servers. NFS performance is much more variable than straight TCP/IP suite performance, as you have seen. Most of the NFS clients (and some of the servers) can be purchased at a lower price in a combined suite with TCP/IP tools, reducing purchase prices even further. Nevertheless, the combined suites offering TCP/IP and NFS tend to be $400 to $500 per seat, which is an appreciable amount to thrown away on a poor decision. Consider your choices carefully in order to best leverage your existing equipment and legacy applications. Mainframes and minicomputers will be around for years yet, and your Windows NT systems must talk to them. You might as well make the experience as pleasant as possible! TCP/IP Suites
NFS Server Packages
NFS Client Packages
|
|
Send mail to
tparker@tpci.com with
questions or comments about this web site.
|