ted@blia.sharebase.com (Ted Marshall) (04/26/91)
Hello all. One week ago, I posted the following query:
- We are in the process of selecting a TCP/IP vendor for VAX/VMS for a
- special project. I am in the process of contacting the vendors for
- information but I have two questions that may be difficult to get
- answers for that I was hoping that the net could help with.
-
- The implementations I am looking at are:
- UCX from DEC (is this officially called the "VMS/ULTRIX connection"
- or are these two different products?);
- WIN/TCP from The Wollongong Group;
- Fusion TCP/IP from Network Research; and
- MultiNet TCP/IP from TGV.
- I already have a copy of CMU-TEK TCP but this project requires a commercially
- supported product.
-
- My basic requirements include:
- TCP and IP (supported by ARP and ICMP);
- Share DEC Ethernet interface with DECnet;
- Process-to-process TCP connections (other protocols and utilities
- desired but not required; socket library not required, QIO
- interface adequite);
- At least 200 simultaneous TCP connections to other hosts (given a
- large enough VAX).
- I believe that all of the implementations I've listed meet these requirement,
- possibly excepting the last. If anyone knows of other vendors, please feel
- free to suggest them.
-
- My two basic questions:
-
- (1) Does anyone know what the actual limit of simultaneous connections is for
- a given implementation. Or at least, conformation that an implementation can
- make it to 200.
-
- (2) Has anyone benchmarked any of the implementations against another? I am
- interested in performance of TCP and IP only. For example, Given two VAXen
- on an Ethernet, a small program on one feeding data to a small program on the
- other over TCP, how many KB per second?
I have received ten responses. Although for the most part they did not address
my specific questions, they were all very helpful. I have sent individual
thank-you messages to each sender. If you sent something but did not get a
response, either your mail or my response got eaten by the email monster;
sorry.
The over all winner seems to be Multinet from TGV. Six of the messages
specificly recommended it. One message only had negative comments and those
seemed to be monor (he went with it anyway). Several of the messages gave
informal comparisons of performance; these all said that Multinet was the
fastest, though no one had numbers to back that up.
Two messages gave positive evaluations to WIN/TCP from Wollongong. However,
one of these senders went with Multinet anyway and the other sender did not
seem to have actually compared to against the other implementations; he simply
said "it seems to work fine". Five messages recommended against Wollongong;
Reasons cited were bugs, poor support, and that Multinet was better.
No one seemed to like UCX from DEC. Four messages recommended against
it, citing lack of features, buggy installation and again, that Multinet was
better.
Two messages mentioned Fusion TCP from Network Research. One stated that
the sender felt that it would not meet my requirements and the other stated
that its performance was subjectively poor.
Additionally, one person suggested TCPware from Process Software. He is very
happy running their RSX-11 product and suggested I check on their VMS product.
The last message, included in the total count but not in any others, was from
Kenneth Adelman at TGV. He made the following useful comment:
- MultiNet has no architectural limit on the number of incoming
- TELNET or RLOGIN connections. Each connection requires about 500
- bytes of memory, and the CPU resources are about the same as a
- hardwired DZ11 terminal line. You'll find that whatever those users
- are doing on the machine is going to require more resources than the
- TELNET server itself and that you can ignore the overhead of the
- TELNET server when sizing your machine. The same can also be said for
- Wollongong's product; I'm not familiar with the others.
He also made some suggestions on how to benchmark TCPs against each other.
Well, everything seems to be pointing to Multinet. If WIN/TCP and UCX have
the same number of supporters, I didn't hear from them. When we get closer
to starting our project, I plan to request evaluation copies of WIN/TCP and
Multinet and check them out myself. (This was suggested by several messages.)
Finally, Ben Pashkoff of Technion IIT in Israel (BEN@VMSA.TECHNION.AC.IL)
sent a detailed evaluation of TCP products he did and gave permission to
post it. IMPORTANT: this was done in 1989 and some things have changed since
then. He later wrote that it hasn't been updated because they selected Multinet
and are very happy with it.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VAX/VMS Tcp/Ip Evaluation July 1989
------------------------------------
Ben Pashkoff
Computer Center
Technion, IIT
Haifa, Israel
The following document is a summary evaluation of a series of
products for VMS network communication. This document was written in
conjunction with research and tests performed by the author as well as
Mr. Yehavi Bourvine of the Hebrew University Computation Center.
DEC, Digital, VMS, VAX, Ultrix, VAXBI are registered trademarks of
Digital Equipment Corp.
UNIX is a registered trademark of AT&T.
NFS is a registered trademark of Sun Microsystems Inc.
Introduction
The Tcp/Ip protocol has been established as the de facto standard for
inter-computer and workstation communication. The protocol defines a
description for inter-process communication between computers. The
standard descriptions are available for public inspection as a series
of articles.
I. Criterion
In order to evaluate a Tcp/Ip product for VMS, a set
of criterion and limitations was developed. These included:
1) Availability: Is the product immediately available for inspection
from the company or a representative of the company developing the
product?
2) Support: Is the company located in Israel? If not, does it have a
duly authorized agent for sales and support in Israel? If so, does
this agent have the necessary personnel, experience and expertise to
completely guarantee assistance with the product? If there is no local
agent, is the company available for consultation by Phone, facsimile, telex
or electronic mail? Is there a fee involved for any of these services
to the customer? Does the company guarantee to notify and update the
customer when and/or if any problems are found and fixed with the
product?
3) SMP: Does the product support VMS 5.x? or DEC/VMS SMP (Symmetric
Multi-Processing)? These two questions become imperative
with the introduction of 6000 class VAX machines on each of the major
university campuses and with the introduction of parallel processing.
4) Installation: Is the product relatively simple to install,
customize, manage, and maintain? Is sufficient documentation available
to inform the system manager what to change and how to customize the
product to suit the environment? Does the product require any system
parameter changes in order to install and operate?
5) Special Hardware: Is special hardware required to install, or
operate the product? Is the product versatile enough in order to
operate over a variety of hardware configurations?
6) Standard Protocol Applications:
A) TELNET- Does the product conform to the documented TELNET
standards? Is a IBM 3270 terminal emulation supplied/supported (e.g.
tn3270)? What is the theoretical and actual limit to the number of
TELNET logins? What is the system overhead of a typical TELNET login
and at what point will system degradation be noticeable to the end-user?
Is there an on-line help available?
B) FTP - Does the product conform to the documented FTP standards?
Does the product support 3rd part transfers? Is there a clear and
concise on-line help facility? Is there proper security restrictions
built into the product? Are the commands similar enough to other
versions of this product under other operating systems that end-users
do not have to re-learn a new facility? Are extensions for VMS file
types included?
C) SMTP - Is the SMTP server included in the base product?
If not, what is the extra charge? If included, is there a mail user
interface included? Does the SMTP implementation include routing
capabilities and mail handlers?
D) Subnets - Is subnetting included?
7) Extra Utilities and Applications:
A) LPR/LPD - Is this available for both client and server operation?
How difficult to install as well as to maintain? Which Lpr/Lpd
features are supplied?
B) Nameserver - Does the product support an implementation of BIND
Nameserver either as client, server, or both?
C) R-commands - Are the Berkeley R client/server services included?
This includes rlogin, rshell, rcopy, rexec, etc.
D) NFS - Does the product support an implementation of Sun NFS
(Network File Server) either as client, server, or both? How is file
name mapping handled in each?
E) talk - Does the product support the UNIX talk facility (similar
to VMS PHONE)? If so, is it 4.2 or 4.3 UNIX compatible?
F) finger - Does the product support a finger process? If so, is it
compatible to UNIX Finger processes?
G) Statistics - What kind of diagnostics and statistic information
is provided by the implementation to aid the manager in following net
traffic, and measuring network load?
H) Gateway - Can the implementation support a gateway configuration?
8) USER Interface: Is the user interface easily accessible by any
end-user? How much time will be involved in training a new user to use
the facility? Is the response time (apart from system overhead) short
enough to be easily acceptable to the end-user? Are on-line help files
available? If so, how well written and usable are they? In any case,
what is the status and availability of written documentation for the
user as well as the system and network manager?
9) Cost: What is the pricing schedule for this product? Is the
company willing to consider a site license? an academic discount? a
group pricing scheme?
10) Source: Are program sources available? If so, to what extent,
what media, and at what cost? Would the source material be usable by
system maintenance personnel if they had it?
11) Programming interface: Is there a programming interface available
for expansion and implementation of new applications? If so, is this
at the Socket level? at the $QIO interface level ($QIO is the VMS low
level Queue Input and Output programming interface)? Is there
documentation and support at this level?
II. Product Candidates
There are several products on the market that advertise themselves as
Tcp/Ip implementations for VMS. Product Information from each vendor
is available on request, or may be appended at a later date. For one
reason or another, most are not suitable for use here. The following
are available, but for the reason stated were not considered:
A. VMS/Ultrix Connection: This is a DEC supported product that is
still in its 'software infancy'. Though purported to be a Tcp/Ip
implementation, it does not support SMTP at the present time. It does
support an NFS Server implementation, which is its main selling point.
A version was not made available for our inspection, though without
SMTP, it was not considered worthwhile. Mixed reports have been
received. TELNET is not supported and FTP is only partially supported.
B. CMU-Tek: This is a joint product in the public domain between
Carnegie Mellon University, and the Tektronix Corp. It is written in
BLISS, and requires a BLISS compiler to be on-site in order to
operate. There is no formal support for the product from either of the
parties involved in its production. At last notice, it also does not
support SMP as yet.
C. Wollongong, V/IP: Wollongnong, in its first version, was not at all
suitable for use. The second version is reportedly a much better
product. Digital is supposedly a sales agent for Wollongong, but
attempts to even request a price quote for this have not been
answered. It is a ported product from the Berkeley UNIX Tcp/Ip, so it
does conform to almost all known standards.
The following comments are courtesy of Mr. Benzi Mizrachi of the
Weizmann Institute. Weizmann currently runs both Win/Tcp (Wollongong)
and Fusion at their site.
Wollongong does support various hardware interfaces as well as the
ability to share the DEC ethernet controller. The next version is
scheduled to support DEC SMP. The current version supports tn3270
though is supposed to be very CPU time consuming. Weizmann reports
that this is still bearable, and that the tn3270 interface is very
convenient to work with. Wollongong does support a Nameserver.
The current version was reportedly easy to install and maintain. SMTP
is also through the VMSmail interface, similar to that of Fusion or
Multinet. There is a good $QIO interface. The current product has been
in use for 4 years at Weizmann and there have been very few problems
to report. Documentation is considered better and easier to use than
that of Fusion (see below).
The local agent for V/IP is Bricom, the same as was for EXOS, so
support is not expected to be any better. V/Ip is reportedly an OEM
adaptation of Wollongong, though there is no word or credit to
Wollongong in any of the literature received. The price quotation for
this that was received was more than for any of the other candidates.
A price quote that was received for this product for one VAXBI
based computer (e.g. VAX 6000 series) was approximately $17,000, not
including NFS. This price does not include source code and is
non-transferable to other machines.
The last three candidates are Exelans' EXOS, NRC-Fusion, and
the SRI/TGV Multinet version. Since these were given
considerable more testing, the results from these will be covered in
the next sections.
D. EXOS/Exelan: This is the Tcp/Ip product currently in use at
Technion and the Hebrew University. At last notice, though it does
support VMS 5.x, SMP support was not available. EXOS also requires its
own hardware interface to ethernet which is not currently available
for a VAXBI bus implementation nor for the VAX 6000 class computers.
Bricom, the local agent that was responsible for EXOS has now decided
not to sell or support this product.
Customer support for this product has not been up to satisfactory
standards over the past 2 years of its use. Further information on
this product is available on request, but since it does not meet some
basic requirements, it will not be elaborated upon here.
E. NRC-Fusion:
The NRC-Fusion implementation is very complete in many aspects.
The design philosophy used to develop it was different from other
implementations. It is, by design, not a port of the Berkeley Tcp/Ip
product, rather the developers designed a VMS product from scratch
that comply to the requisite Tcp/Ip standards. This would seem to lead to
the conclusion that NRC-Fusion would be a more efficient and better
suited product for VMS.
NRC-Fusion is sold and supported by an NRC representative here in
Israel, COMDA Ltd. COMDA is not a subsidiary of NRC, but has a
commitment to support of this product. They have claimed to have an
extensive support service available, with a second source from NRC in the
U.S. Telephone response and support has been fairly decent. The
representatives from COMDA are interested in establishing group discount
either via each individual university or via MACHBA.
This product does have a SMP, and a Version 5.x capability.
Installation of the product and operation for TELNET, FTP and other
utilities was achieved in approximately two hours including some
minor, but disturbing problems. Fusion does support a Nameserver,
which is reportedly simple to implement. Without this, all hosts must
be separately defined, if using dbedit. The interface to their tables,
is either via a special program that is supplied (dbedit) or a regular
test editor.
In the implementation tested, only the dbedit proved possible, and
after a short while it became annoying to use. The database itself is
different from those used in other implementations.
FUSION runs in parallel and on the same hardware as DECnet, thus
most VAXen need no additional hardware installation.
Pricing information for the NRC-Fusion was received. The basic
Tcp/Ip product (including TELNET, FTP, finger, diagnostics) was
$10,800. An additional $1800 was required for SMTP and the mail
interface. Another additional $1800 for the R-commands, and another
$4500 for an NFS server. After 30% academic discount, this package
would be $13,230. This price does not include sources, nor is it
transferable or take into account any smaller VAXen on campus.
TELNET from the VAX is slow, as were all functions with Fusion.
TELNET to the VAX is also slow. There is a definite feeling of sluggishness
when connected via TELNET (response time approx. 1 sec.). A control key
guide is also written to the terminal to inform the user as to the
proper exit key.
Fusion also supports a very nice third party file transfer via
FTP. In other words, it is possible to be logged into A and transfer a
file from B to C. The FTP suite will prompt for all necessary user
information as well as source and target for files. FTP also has the
ability to submit files to remote VMS print queues
SMTP is supported as a separate product, and not part of the base
product. At the time of the original test, it was not available so it
was not tested. It has since been made available, and a testing of it
could be performed. Weizmann reports that the Fusion SMTP mailer uses
either the VMSmail interface or their own unix-like mail interface,
which is fairly convenient.
Fusion does support a finger utility, and a nice variety of
diagnostic tools.
As to extra utilities and functions, while LPR/LPD was promised
to be available, it is not mentioned in the documentation, nor in the
advertisements. A domain Nameserver and resolver is included, Berkeley R
commands, as stated above, are available, but as a separate package.
There is no talk facility.
The user documentation is excellent. Unlike other VMS third party
software developers, it makes no attempt to emulate VMS documentation.
The documentation for managers as well as users is well written and
carefully and logically organized. There is a lack of a troubleshooting
guide, but this is natural in a product that expects no problems.
Unfortunately, a completely problem-free software package has yet to
be produced. On-line help facilities are equally well written and the
guide for the end-user is concise and simple, integrating where
necessary with other concepts of VMS.
Installation of this product, as stated previously, was in
approximately two hours. There are some anomalies that are disturbing.
The databases are case dependent, and this is not stated anywhere.
When the dbedit program is run, and information is given in
lower-case, it will not be received by the program. There is no error
checking for this, but the manager has ample error documentation in
a full set of error log files. Changes to the configuration as well
as customization are best done via dbedit. This program is a full
screen based question and answer routine that allows the manager to
change the basic configuration of the implementation as well as to
expand the host and routing tables. However, additions are included
one at a time, and a full conversion for a downloaded host-table was
not found. One annoying problem with dbedit is that it never paused as
it was supposed to on page boundaries to display explanatory text,
rather scrolled through the complete text without stopping.
Fusion, while not including sources with their product (this is
also an extra charge that could well be above $20,000), does include a
programmers $QIO interface.
F. Multinet:
Multinet is essentially a code port from Berkeley UNIX 4.2 and
4.3, developed and distributed to the academic community by SRI
International, and marketed and supported by the TGV company in
California. SRI International is attached to the Stanford Research
Institute and its primary function is the distribution of research
reports including the above-mentioned Tcp/Ip Standards reports
concerning the standards for Tcp/Ip. TGV is an admittedly small
company (3 plus people) whose sole function is support for this product.
According to the software product description it is a very complete
product, and for the most part very professionally produced.
There is no local Israeli representative for SRI or for TGV, and
all discussion concerning sales and support has been handled to this
date via e-mail and facsimile. Both TGV and SRI are available on Arpa-net
and thus have good e-mail access. Response time for support has been
approximately 12 hours, which is very good, taking into account a 10
hour time difference between Israel and California.
Multinet supports the widest number of hardware configurations
available as a Tcp/Ip product for VMS. The list includes all known DEC
ethernet controllers as well as many third party controllers
(including Execelans' EXOS family of controllers). Multinet can also
be configured to use more than one controller on a computer and thus
serve as a gateway between two networks. According to TGV, the
technical support for Multinet, the EXOS cards run approximately
10% faster than the DEC ethernet controllers. (Please note that the
EXOS cards run in 'dumb' mode in any case.)
Multinet is one of three producers of a SMP and Version 5.x
compatible Tcp/Ip implementation. At the time of this study, only two
were available for inspection (Fusion and Multinet).
Multinet installation was incredibly quick, easy, and painless.
Installation and operation was achieved in approximately 25 minutes.
This included installation and operation of the Domain Nameserver and
SMTP. Like other implementations installation is via the VMS VMSINSTAL
program with a simple question and answer routine to establish Hosts
and Nameserver parameters. All tables are either identical or
sufficiently similar to UNIX implementation to pose no compatibility
problems with the tables.
Multinet, as a base package for universities, includes all base
applications and most utilities except for NFS and a mail interface.
All connections are handled by a master server, so there is only one
process running for inbound connections. Inbound TELNET connections
are routed through the standard VMS TTYDRIVER so all VMS supported
terminals are supported. Outbound connections support tn3270 for
connection to IBM hosts running Tcp/Ip. The response times are very
good (typically <0.5 sec.) and the tn3270 is a very efficient emulator.
The TELNET server tries to negotiate the terminal type if possible.
There is no described limit on the number of TELNET sessions to the
computer and other sites have reported more than 100 sessions on a
VAX 6000 class computer with before noticeable degradation in performance.
Each TELNET connection requires approximately 0.2 Kbyte of memory
for the connection.
FTP is also fairly efficient and quick (measurements in the range
of 30 were seen as opposed to 10 with Fusion). Outgoing FTP does not
ask for Username and Password as a default, but will not allow any
actions until the appropriate commands for User and Password are given.
All standard FTP commands are supported and the On-line helpfile is
quite explicit. FTP transfers between to other Multinet implementations
can also be made using a Lempel-Ziv Compression routine. The FTP
client can also be asked to negotiate a VMS file-type transfer with
another Multinet implementation. This allows transparent binary and
image file transfers.
The SMTP server is included as a standard part of the base
product. There is an optional Mail interface available, but this is
not necessary for use by the end-user. The SMTP implementation can use
the Nameserver to resolve addresses. Mail headers are also written
according to Tcp/Ip standards. Incoming mail must be sent using a
VMS external Mail carrier. This is defined from the user point of
view in the Send line as:
SMTP%"user@host" or BITNET%"user@host".
Since this is compatible with what is currently in use, this should
pose no problems for end-users at this site.
Multinet supports the Berkeley BIND Nameserver in either client
or server mode. In client mode it queries the server to reply with the
required resolved address, if the address is not resolved it resorts
to its own internal host tables. All tables are stored in memory for
faster access. This also uses what could be much needed memory on
smaller systems. In server mode, the definition tables are identical
to those used in UNIX implementations. Personnel already familiar with
the Berkeley implementation have no trouble utilizing this one. Like
the Berkeley BIND, a primary and secondary made be designated.
There were some documented commands in the current inspection copy
that were not clearly functional. TGV has assured us that a new
documentation set is in process. (See below)
A full set of R-commands is also included in the base set. This
includes rlogin, rshell, etc. These work as expected (i.e. not
different than their UNIX counterparts.), but are not suggested due to
security considerations.
As a side note, the managerial software is designed in such a way
that certain servers may be enabled or disabled as the manager deems
necessary. This means that the R-commands features may be completely
disabled.
NFS is available as an additional feature from SRI. It was not
requested as a necessary component for this test.
Multinet also includes both old-talk and new-talk as a part of
the base set. This has been tested and works very well with both UNIX
4.2, UNIX 4.3 and SUNos. The talk facility provides a VMS-Phone like
utility between UNIX and VMS.
Finger is available as a part of the base package. It is useful
on the local computer as well as other computers connected via the
network.
Both RIP and SLIP protocols are supported by Multinet according
to the documentation.
LPR/LPD protocol is supplied. This was installed and tested.
Installation was very easy and quick, though these are not in
the current documentation set received. As a client, the foreign print
queue appears as a VMS native print queue, and as a server, incoming
jobs are treated as VMS print jobs. There are no facilities currently
available to observe the foreign queue or for the remote machine to
observe the local queue, nor is there a facility to remove the job once
it has left the local machine. Remote jobs, sent to a remote computer,
appear on the remote computer with a file name like:
"Remote print file from node xxxx" and not the actual file name.
The Multinet documentation is sorely lacking in the present
version. While it is pretty to look at, there leaves a lot to be
desired in completeness and organization. We have received assurance
from TGV that a new version of all documentation is in process and is
due to be distributed this Fall. The Installation section basically
says to run the standard VMS Install procedure, which is more than
ample to install and begin the product. The user section very cleanly
and basically describes the currently available features. The on-line
help is similar and is equally clean and direct. Documentation
concerning additional features is sparse, e.g. tn3270 is not mentioned
at all in the current set.
SRI is willing to give favorable pricing to universities. The
basic package is available at $5500 for a single CPU and $2750 for
each additional CPU on a site. They also have a special discount of
$16,500 for 13 VAX units. (1 Vax unit = 1 VAX 7xx, 8xxx, 6xxx or 3
microVaxen, or 10 Vaxstations). NFS is available for $750/CPU or
$4688/site. All of the above prices are subject to a further 10%
discount on condition if the SRI standard license agreement is signed
with no major modification or negotiation. Partial sources and a
Public Domain C language compiler are also included for academic
institutions. Partial sources include all but the kernel code
concerning the SMP interface.
In addition to partial sources, Multinet also includes a $QIO
programming and a socket programming interface. Both have been used
and are quite easy to work with and understand for the systems
programmer.
Conclusions
In order to decide which of the preceding packages is worthwhile to
purchase all of the above criterion must weighed. There is a benefit
and a deficit to not having direct support here in Israel, however,
having good support even via e-mail is far better than poor support
next door. On a price-per-performance basis, we see that Multinet is
both reliable and efficient in use and performance. The main drawback
for Multinet is the documentation, which is sadly the same situation
with many equally large commercial packages. Even though a package
specifically designed for VMS may be advantageous to the VMS system
point of view, this was not obvious in performance, and having a
Berkeley based and similar product expands the possible support group
to include UNIX personnel that are already familiar with the product
from the UNIX perspective. It is the authors' opinion that the
Multinet product be purchased.
The 13 unit license is advantageous only if there are more than 6
computers to be installed. With the growing number of Vaxstations on
the Technion campus, it would seem that this may be possible. It is
recommended that the Multinet NFS server be tested as well.
31-July-1989
Comparison of Product features VAX/VMS TCP/IP.
================================================
The following table is based on a comparison of Wollonong and Fusion,
received from Comda and NRC Inc.
Expanded to include Multinet and pricing information by Ben Pashkoff.
FEATURE Wollongong NRC-Fusion Multinet
==========================================================================
Source of product Berkeley Port In-House Berkeley Port
Source code available No OEM Most
Multi-protocol No Yes Yes
Program Interface FTP FTP,SMTP(mail) All
QI/O Support Yes Read/Write Yes
Socket Lib BSD 4.3 BSD 4.2 BSD 4.3,RPC
GATED-RIP,HELLO
EGP YES PLANNED YES
DEC-SMP ALMOST YES YES
VMSINSTAL PLANNED YES YES
NET MANAGEMENT UTILS NO PROPRIETARY YES
SHARED DECNET YES YES YES
MULTI-CONTROLLER EXTRA $$$ YES YES
VAN JACOBSEN ALGORITHM YES PLANNED YES
DOMAINNAME SERVER YES YES YES
FTP Features
==========================================================================
Copy, Move Append No Yes No
Print Queue No Yes No
VMS Loginout No Yes Yes
RMS-RMS No Yes Yes
Command Complexity 62 <40 56
3 rd Party Copy No Yes No
Wildcard copy Yes Yes Yes
Multiple connects ??? No Yes -
Lempel-Ziv compression ? ? Yes
TELNET Features
=============================================================================
Line at a time ??? No Yes -
Terminal Type No Yes YES
TN3270 support Yes NO Yes
Print Queue ??? No Yes -
Options available
===========================================================================
NFS Server Extra $$$ Extra $$$ Extra $$$
RPC/XDR Lib No Extra $$$ Yes
Mail/SMTP Yes Extra $$$ Yes
'R' Commands Yes Extra $$$ Yes
X.25 ?? Yes(w/Hdwre) Yes(w/Hdwre) Yes
DMV/DMR Synch Yes Yes Yes
Asynch DDCMP No Yes Yes
Talk No No Yes
Finger Yes Yes Yes
LPR/LPD ? No Yes
SLIP ? ? Yes
Security Features
==========================================================================
Tcp/Ip Security option No Yes Yes
Host/Network Security No net_secure Yes
Price Features
==========================================================================
Pricing information not given for Wollongong.
Site based on approximation of current Technion configuration and
assumption that all known VMS nodes.
Configuration of:
6 VAXen (7xx,6xxx)
5 micro-VAXen (uVax 2 or 3 with multi-user license)
15 Vaxstations (1-2 User license)
Tcp/Ip $31500 $14850
SMTP $ 5442 included
R-commands included included
NFS $19325 $ 4688
===========================================================================
Total $56267 $19538
Future Expansion (1) (2)
(1) NRC-Fusion prices are on condition that at least $10,000 worth is
ordered by end of December 1989, afterwards all prices are
re-negotiable.
(2) Multinet prices are based on a 13 Unit license for indefinite
period of time. Under this license 1 Vax is exchangeable at a rate of
1.5 microVaxes or 10 Vaxstations. The Configuration considered is
equal to 10 Vax units, thus leaving room for expansion.
________________________________________________________________________
| Ben Pashkoff BEN@VMSA.TECHNION.AC.IL |
| BEN@TECHUNIX.BITNET |
| VAX/VMS Systems |
| Computer Center Phone:(972)-4-292177 office |
| Technion IIT FAX: (972)-4-236212 |
| Haifa, Israel 32000 |
|______________________________________________________________________|
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--
Ted Marshall ted@airplane.sharebase.com
ShareBase Corp., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000
The opinions expressed above are those of the poster and not his employer.