From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 26-APR-1991 07:34:58.65 To: ARISIA::EVERHART CC: Subj: SUMMARY: my query on VMS TCP (LONG) From: RELAY-INFO-VAX@CRVAX.SRI.COM@SMTP@CRDGW2 To: Everhart@Arisia@MRGATE Received: by crdgw1.ge.com (5.57/GE 1.97) id AA12909; Fri, 26 Apr 91 07:12:56 EDT Received: From UCBVAX.BERKELEY.EDU by CRVAX.SRI.COM with TCP; Fri, 26 APR 91 03:59:14 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10882; Fri, 26 Apr 91 03:32:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 91 22:56:21 GMT From: voder!blia!ted@ucbvax.Berkeley.EDU (Ted Marshall) Organization: ShareBase Corp, Los Gatos, CA Subject: SUMMARY: my query on VMS TCP (LONG) Message-Id: <13911@blia.sharebase.com> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com 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.