[Info-vax] Using VMS for a web server

[terry+googleblog at tmk.com]

On Friday, June 5, 2015 at 3:11:27 PM UTC-4, Dirk Munk wrote:
> Of course VSI has to think of the effort it takes to maintain a VMS 
> Apache version.

IMHO, such efforts would be better applied to making it easier to build random apps written in Unix-style source, rather than spending the effort trying to wrestle with the code of specific apps to get them to build on VMS.

VMS has attempted to deal with this in a variety of ways over time. I was excited to install the VMS Posix product when it was first released. On a VAX 8650 (no slouch at the time), Perl's "configure" script ran for over an hour and then bombed out.

Since then, various things have been tried. It seems that Compaq (and even more so) HP have gone the route of extensively modifying various packages (SAMBA, Apache, SSL, etc.). Unfortunately those are moving targets, whereas HP seems to have decided "We ported version X.Y.Z (and called it version A.B-C), our work is done". It doesn't help when the port is called "Industry Standard Thingamajig" instead of the name the rest of the world knows it by.

Sometimes the changes have been submitted back to the upstream. Some upstreams would accept VMS changes, some would not. Rejections seemed to me to be more a case of the upstream not having a VMS system to test against rather than any particular loathing of VMS.

Of course, as VMS became more and more compatible, many of those changes were no longer relevant, even on VMS. While VMS folks might be offended by the motto of OpenSSL Valhalla Rampage - "Tearing apart OpenSSL, one arcane VMS hack at a time", it is rather true if you look at the code.

In that particular case, I'd categorize the changes into 3 major groups and estimate their prevalence as:

  1) Missing Unix-like functionality that needed to be emulated / worked around
  2) VMS compiler bugs or things thought to be bugs because everybody else used GCC
  3) Other

At the time I was porting Unix code to VMS (which I admit was years ago), some common problems were deficiencies in things like select(), where some parts were not implemented and other parts were implemented but broken, and case-sensitivity in symbols and filenames (this was long before ODS-5 solved the latter). Writing a DCL command file to build the code was trivial after wrestling with the code, though it would have been nice to be able to re-use the existing Makefile.

A lot of these are things that could best be addressed during a port to a new architecture. It might be worthwhile asking some of the people doing porting work (such as GNV) what sort of new / changed VMS features would make building Unix-style software on VMS an easier task.

Perhaps this is already being done - I haven't been involved with developing / porting code onto VMS in years.