[Info-vax] Using VMS for a web server

[David Froble]

Dirk Munk wrote:
> Stephen Hoffman wrote:
>> On 2015-06-04 05:21:52 +0000, Dirk Munk said:
>>
>>> JF Mezei wrote:
>>>> If VSI continues to support "Apache" on VMS, then it should be *Apache*
>>>> , not some proprietary port.  A proprietary port means that when 
>>>> patches
>>>> or new features become available to the world, they are not availble to
>>>> VMS customers.
>>>>
>>>
>>> You will always have to adapt Apache in order to get it running on
>>> VMS. Apache is a Unix application, and VMS is not Unix. So it will
>>> always be a proprietary port, and any patch will also have to be
>>> ported to VMS I'm afraid. Apache will have VMS specific extensions,
>>> but I don't think it was ever the intention to make it more
>>> proprietary than necessary.
>>
>> The various Unix systems are different from OpenVMS, certainly.  But
>> wouldn't easier ports of Unix applications over to OpenVMS be
>> preferable?   You're not going to get much of a market with Windows
>> applications and something akin to Cygwin, after all.   But FWIW, it's
>> not that the *ports* are different — Apache ports are always different —
>> it's how you manage and extend the platform that matters to the folks
>> that are going to be configuring and operating and troubleshooting the
>> port.   Once I know where the configuration files are, and tools such as
>> apachectl, I can generally get an Apache server to do what I want. I
>> don't need to learn a whole new batch of configuration file syntax, and
>> a new set of OpenVMS-integrated tools.  This if I even need to go to the
>> command line, which is something that I'm needing to do less often, and
>> not something I'd encourage going forward.
>>
>>>
>>>> Also, "<company> Secure Web Server" has 0 marketing value. If VSI can
>>>> claim that Apache runs on VMS, then this has marketing value.
>>>>
>>> Yes, you could be right there.
>>>
>>>> Also having WASD for higher performance wich takes advantage of VMS
>>>> would be good for those who prefer a less common web server that fits
>>>> better in VMS.
>>>
>>> My reasoning to think of WASD as the primary web server is this:
>>> Some one who is used to Apache on Unix will most likely not be used to
>>> using VMS.
>>
>> True.  But they will know Apache syntax, once they are able to find the
>> Apache configuration files.
>>
>> As for changing web servers, some of my larger customers are using
>> Apache on OpenVMS.   Are you planning to deprecate Apache, or to support
>> both Apache and WASD?
> 
> Good question.
> First of all you need to compare the functionality of both servers. You 
> also have to check how well both servers integrate in VMS. And then we 
> have the performance and use of system resources.
> Of course VSI has to think of the effort it takes to maintain a VMS 
> Apache version.
> As I mentioned before, it would be nice if the Australian company VMS 
> Software Services could cooperate with VSI, and join forces to produce 
> nice products like WASD and perhaps bundle them with VMS.
> So in the end you have to list up all these things and then reach a 
> conclusion. If, and that is a big if, there is no real benefit in 
> maintaining Apache on VMS, then dropping it could be considered.

If there are VMS customers, using Apache, and want to continue using it, 
then if VSI wants their support dollars, they'll need to continue with 
Apache support and inclusion of the newest version.

>>
>>> Someone who is used to VMS will perhaps not be used to the Unix style
>>> of doing things as with Apache.  So if WASD is doing things in the VMS
>>> way, then VMS people will be able to setup a WASD server faster then
>>> with Apache.
>>
>> You're presuming that the folks involved either know or will want to
>> learn how OpenVMS does this stuff.
> 
> No, I'm assuming VMS folks want to set up a web server on VMS.

Agreed.

>>  Better integration of common tools
>> is goodness, but assuming folks know OpenVMS means you're limited to the
>> installed base.  TCP/IP Services faced this same mess — there are a
>> variety of tools that are used to configure and troubleshoot and test,
>> and there are those folks that wanted the OpenVMS syntax, and there are
>> (a whole lot more) folks that wanted standard names and standard tools.
>> When there are common practices and tools, being different is something
>> you need to be extremely careful about.
>>
> 
> I absolutely don't mind Unix style TCP/IP commands, >>in addition to VMS 
> style commands!!<< VMS people are used to the VMS CLI, to the VMS way of 
> doing things. For them the standard is the VMS style, not the Unix 
> style. The strange hodgepodge of VMS style commands and Unix style 
> commands in the present TCP/IP services is not a pleasure to work with. 
> Some things have to be done in Unix style, there are no VMS style 
> equivalents. That is not acceptable in my view.
> 

I'm with you on this.