TCP/IP history, a VMS Perl perspective

A brief, biased recounting of history my someone who wasn't even there

If you've tried to compile VMS Perl with TCP/IP socket support, you've probably noticed it's a little strange (or, for versions prior to 5.004_03, a lot strange). You may well have wondered why. Well, here's a brief rundown on the history of TCP/IP networking on VMS, from a Perl perspective.

In the beginning

VMS, for the longest time, has had very strong networking support built-in. Unfortunately, that support has been for DEC's networking protocols, DECNET and LAT. TCP/IP, the networking protocol in common use on Unix, wasn't available on VMS.

This particular state of affairs was fixed, fairly quickly, by several third-parties. The freeware CMUIP stack, from Carnegie-Mellon University, as well TGV's Multinet (now owned by Process), Process software's TCPware, and Wollongong's stack. DEC, too, came out with a TCP stack, UCX, that was available.

Unfortunately, with the exception of CMUIP (which was limited to Vax), all these solutions required paying extra. In some cases a lot extra. Also, each of the different TCP/IP stacks had a different interface. Most implemented at least part of the Berkley socket library (the standard TCP/IP interface library for Unix systems), but they all did it differently. DEC provided some socket routines in DEC C, but when they first came out they were a touch unstable, and required Dec C. VMS Perl, supporting Vax C and Gnu C, couldn't count on them.

Then there was NETLIB

This state of affairs was particularly vexing, and the clever folks of MadGoat software whipped up NETLIB. Netlib's a set of shim routines that sit between your program and whatever TCP/IP package you're using. It's a nice, VMS-style interface, and it does the job very nicely.

Unfortunately, Perl's written to use the Berkley socket library, and depends on it very heavily. Writing a socket to netlib shim library is no small task. So no netlib.

Enter SOCKETSHR

Then SOCKETSHR came on the scene. SOCKETSHR is a library that provides the Berkley socket interface, and talks to either DEC's UCX (via the C compiler routines DEC provided in DEC C) or NETLIB. This is neato-keen, and support for sockets got rolled into Perl. Now you could compile either plain, or with sockets.

Nothing's perfect

Unfortunately, of course, there are problems. First, of course, is the fact that you need the SOCKETSHR library, as well as possibly NETLIB. Second, SOCKETSHR's got some problems somewhere with Multinet UDP sockets. It's a workable solution, though.

DEC C's Sockets got better

Meanwhile, DEC continued to improve the reliability of DEC C's sockets, and sold more and more Alphas, increasing the DEC C user base. UCX got more reliable (being rather less so in earlier versions), and DEC finally decided to bundle it in with the base VMS license.

With the main port of Perl done, there was time to roll in support for DEC C's socket library. Initial support was pretty preliminary, and through perl 5.004_01 you had to mess around with the DESCRIP.MMS file to get DEC C sockets, rather than SOCKETSHR sockets. A significant fraction of VMS VAX Perl sites were (and are) still not using DEC C as their compiler, since DEC charges a bunch for it.

Integrated Support

As of Perl 5.004_03, DESCRIP.MMS was changed to allow for easier selection of the socket library. Now, rather than just using a SOCKET macro, you can use a DECC_SOCKET or SOCKETSHR_SOCKET to select the socket library you're going to use.

The Future?

There's a new version of Gnu's GCC on the horizon for both VAX and Alpha machines. (Previously it's only been available on VAX) Hopefully it has full support for the Berkley socket routines. If so, we'll do our best to make Perl use them, opening up socket support (and perl itself) to more systems.

A final rundown

Just for the record, here's the current design rationale for the way Perl builds.


Last updated 12-September-1997
Questions or Comments?
Write the Webmaster