[Info-vax] Using VMS for a web server

[Jan-Erik Soderholm]

Stephen Hoffman skrev den 2015-06-05 16:40:
> On 2015-06-03 23:28:39 +0000, Dirk Munk said:
>
>> I'm aware of all these things, but if WASD can be the web server of
>> choice for VMS, then it would be possible to drop Apache. After alle,
>> WASD is a pure VMS product, it may be easier to implement on VMS than
>> Apache.
>
> As good as WASD is, Apache is the web server that folks expect and are
> familiar with.  Increasing the delta between familiar platforms and tools
> isn't usually the best approach.  Do not ever underestimate the advantages
> of being compatible with expectations, training and tools.
>
>
>>
>>>
>>> Then there's the question of pricing.  VSI is also competing with a
>>> zero-cost entry-price for Linux and BSD distros; for those folks
>>> experimenting with and just getting started.  If hosting services are in
>>> play, then you're competing with Amazon and folks like
>>> https://www.digitalocean.com/ or http://www.rackspace.com/ or
>>> http://azure.microsoft.com/ here.  Spooling up a guest is seriously fast
>>> on most boxes, too.  A few clicks and you're off and running, whether
>>> hosted services or with an end-user-targeted server OS configuration.
>>>
>>
>> I'm referring to the type of web server that is a front end to your
>> business, not some box at a hosting organization.
>
> Seems you're following the one-box one-architecture model, and that was
> something familiar, comfortable and common back in the 1990s and 2000s, but
> most places are now dealing with heterogeneous server installations, or
> with their own existing and installed web front-ends. OpenVMS isn't at the
> center of nearly as many business configurations.  While there are some
> web-facing OpenVMS boxes at businesses — running Apache, BTW — there are
> more than a few folks that are running tools and content management and the
> rest that are predicated on other platforms.  Until and unless those
> front-ends and tools are available on OpenVMS, moving OpenVMS into the roll
> of a web host is going to be a tough sell.  Then there's the question of
> whether you want to have your production OpenVMS boxes in your DMZ.
>
> It's possible to be your own hosting organization, BTW.  Makes for a handy
> way to quickly increase the scale of your hosting by either rolling in a
> rack or two of servers — something OpenVMS is not very good at — and/or by
> temporarily adding outside hosting for some tasks.
>
> Individually managing specific servers is also becoming rare — servers are
> resources, and having to individually configure and manage and name and
> address them and load applications and modify startup files is inefficient
> at best.
>
>
>> I suppose it all depends on what you want to do with your web server. I'm
>> not suggesting that a VMS web server could or should do anything any
>> other web server can do. It's like with buying a car, you can buy a very
>> amall one, a big one, a sports car, a saloon, a station wagon, a pickup,
>> it all depends on your needs and wishes.
>>
>> And if a VMS webserver can do the things we need it for, then that is
>> good enough.
>
> Trying other server platforms and tools means you'll know much more about
> both the sorts of things that OpenVMS does better, and the things that
> OpenVMS does worse.   OpenVMS still solves the same sorts of problems that
> were common back in the 1980s and 1990s, but those sorts of problems aren't
> necessarily the sorts of problems and limitations and environments that
> many folks are working with now, and interested in acquiring servers for
> now.   OpenVMS also solves many of those problems in ways different from
> other approaches; not necessarily for the better.  Those 1980 and 1990 data
> centers and configurations basically don't exist anymore, outside of a few
> parts of the installed base.
>
> If you're not looking around and learning about other approaches and other
> tools and other platforms, then your ability to even try to discuss and to
> promote OpenVMS — if that's your goal here — will be poor.   Beyond the
> basic marketing and comparisons, you'll also have the sorts of technical
> issues around just managing and supporting OpenVMS servers, as there'll be
> requests to integrate with various newer tools — everybody's managing more
> and more servers, or deploying more and more, or reconfiguring, etc.
>
> You might learn that if you're going to be different, then you usually need
> to bring specific advantages over the other approaches.  Being different
> because you're better integrated with OpenVMS might not be something folks
> evaluating OpenVMS care all that much about, for instance.  The folks might
> prefer a better-integrated Apache, for instance, because that means they
> can use their Apache skills and tools.  Existing OpenVMS Apache users will
> probably want to see that continue, which means that Apache will either
> continue and that adds to the work, or it gets deprecated and that might be
> a problem for some in the installed base.
>
> To repeat some of my comments from a boot camp a whole back, OpenVMS is far
> too piecemeal in its installation and configuration and management — there
> are other platforms around which are *massively* better at this — and I'd
> really like to have what are now core features — web services among those —
> in the base distro.  Apache would be the local preference, just because
> that's familiar to many, already present, already in use, and very common
> in the industry.   But whether that integrated web server becomes WASD or
> Apache or nginx or something else?
>
>
>

Well, you are way of reality again... :-)

Yes, my custumer has (of course) *all* their web based activity on other
platforms. I would never dream of suggesting moving *that* to VMS!

Still, WASD on VMS is the best tool to web-enable our VMS based
business data for the users. And besides, web pages are linked all
over the place, so for the user this is of no major importance.

About WASD and Apache:

http://wasd.vsm.com.au/wasd_root/doc/scripting/wasd_scripting.pdf
 > VMS Apache (CSWS) Compliance.
 > WASD v7.0 had its CGI environment tailored slightly to ease portability
 > between VMS Apache (Compaq Secure Web Server) and WASD. This included
 > the provision of an APACHE$INPUT: stream and several Apache-specific
 > CGI variables (see the table below). The CGILIB C function library
 > (Section 1.12) has also been made CSWS V1.0-1 and later (Apache
 > 1.3.12 and higher) compliant.

That is of course not everything, but WASD has a number of fixes
to make it easier to use Apache specific features.