deanr@lakesys.lakesys.com (Dean Roth) (01/04/90)
My company has been asked to port its communications software to VMS. The software consists of client and server software, uses BSD socket interface and was designed for UNIX and MS-DOS. The software does not perform any disk or terminal I/O - that is left to the application developer. Since I have next to no VMS experience, I need your advice. (Please email directly to me.) I have DEC's "Network and Communications Buyer's Guide". The guide lists three TCP/IP products for VMS: Fusion TCP/IP WIN/TCP TCP/IP Questions: --------- In general, what is your experience with these products for writing interprocess communications software? I do not care about file transfer (ftp), email or virtual terminal support. What about installation and support? Only WIN/TCP is indicated to be compatible with BSD 4.3 UNIX. I'm not sure what that means. Perhaps it means it has the same C function (socket) interface? How easily can I port the UNIX software? Is it (almost) a matter of recompiling? The server software creates a new process to handle each connection. Is this a "problem" under VMS? (One party told me it is too inefficient. Another party said, "No problem".) Thank you for your help. Dean deanr@lakesys.lakesys.com
lars@salt.acc.com (Lars J Poulsen) (01/05/90)
In article <1512@lakesys.lakesys.com> deanr@lakesys.lakesys.com (Dean Roth) writes: >My company has been asked to port its communications >software to VMS. The software consists of client and >server software, uses BSD socket interface and was >designed for UNIX and MS-DOS. The software does not perform >any disk or terminal I/O - that is left to the application developer. Eh ? If this is not application software, what is it ? With a socket library, the application programs are usually clients and servers. If your software does not do that, what exactly does it do ? You see, it may be performing a function that is already provided in the TCP/IP packages that you would be interfacing to. >Since I have next to no VMS experience, >I need your advice. (Please email directly to me.) The issues might be generic enough to warrant sharing, so I am posting. >I have DEC's "Network and Communications Buyer's Guide". >The guide lists three TCP/IP products for VMS: > Fusion TCP/IP By Network Research Corporation in Oxnard, CA > WIN/TCP By the Wollongong Group, Palo Alto, CA > TCP/IP ???? Are you talking about the soon-to-condense vaporware VMS/Ultrix connection by DEC ???? Not mentioned: CMU's Public Domain TCP/IP MultiNet by TGV/SRI OpenLink by Network Solutions Since I work for a company that supplies network interface hardware for use with all of these, I should not comment on which of these are better than which, just ask just to shop around, and compare prices and features. Some of them are bare-bones, others are very complete. Some are obvious ports of Unix systems, using dash-options, others are completely VMS-ified with VMSINSTAL distribution kits, DCL commands and built-in help files. Some of them have everything in a humongous, loadable device driver for the clonable INET pseudodevice, others have protocol layers in separate ACP processes. >Questions: >--------- >In general, what is your experience with these products >for writing interprocess communications software? I do not care about >file transfer (ftp), email or virtual terminal support. I think you mean you want to open a VMS "channel" to a TCP connection. All of them can do that (with the possible exception of VMS/Ultrix connection which has been described as NFS only). The documentation on how to do it, is usually very, very poor, but once you figure it out it's trivial, and very very robust (just like BSD unix). >What about installation and support? A mixed bag. Ask pointed questions of the vendors, and ask for references. Then call those sites. >Only WIN/TCP is indicated to be compatible with BSD 4.3 UNIX. >I'm not sure what that means. Perhaps it means it has >the same C function (socket) interface? WIN/TCP and MultiNet are direct ports of the entire communications portion of 4.3BSD into a loadable VMS driver. The link devices are NOT configured to VMS, instead a UNIX driver is included in the network kernel. A run-time library is supplied, which completely emulates 4.3BSD functionality: You use normal SOCKET, ACCEPT, BIND, SEND and RECEIVE calls, and they work like you'd expect. (Underneath, of course, these are translated into SYS$QIO calls). >How easily can I port the UNIX software? >Is it (almost) a matter of recompiling? Yes. The biggest problem is usually that VMS want an exit status of 1 for success, while Unix programs return 0 for success and ERRNO for error. >The server software creates a new process to >handle each connection. Is this a "problem" >under VMS? (One party told me it is too >inefficient. Another party said, "No problem".) In UNIX, process creation is dirt cheap, and newly created processes are clones of the parent, inheriting all open file descriptors etc. In VMS, process creation is expensive, and a newly created process contains a virgin program load from a file, with newly opened input and output files. In UNIX terms: You CANNOT do a FORK, but only a FORK/EXEC combo. No amount of runtime libraries can cover up this basic design difference completely. In several of the above packages are included generalized network servers similar to the INETD package of 4BSD. The normal way to write a server is to write it a normal program that reads from SYS$INPUT and writes to SYS$OUTPUT. When an incoming connection spawns a server program, it comes up with input and output connected to the TCP connection. So there is no special programming required to do servers. But as I said, each package is different, and you need to ask the right questions. If you don't know VMS, you are not qualified to make the selection. -- / Lars Poulsen <lars@salt.acc.com> (800) 222-7308 or (805) 963-9431 ext 358 ACC Customer Service Affiliation stated for identification only My employer probably would not agree if he knew what I said !!
lars@salt.acc.com (Lars J Poulsen) (01/05/90)
In article <1990Jan4.173759.5244@ginger.acc.com> I wrote: >Not mentioned: > CMU's Public Domain TCP/IP I was wrong !! In the words of Dale Moore from CMU: > The CMU-TEK software is not Public Domain. It is licensed software. > The license is flexible, generous and inexpensive, but not Public Domain. I am (really) grateful for the correction, which I hasten to pass on. -- / Lars Poulsen <lars@salt.acc.com> (800) 222-7308 or (805) 963-9431 ext 358 ACC Customer Service Affiliation stated for identification only My employer probably would not agree if he knew what I said !!