[Info-vax] Using VMS for a web server

[David Froble]

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?

While I read where lots of people mention this, I'm not sure I agree. 
My feeling is, if it''s Unix you want, then get and use Unix.

Basically, I'm not too interested in porting Unix stuff to VMS.  I'm 
sure there are people who are interested, but I'm not, and all I'm 
saying is not everyone is.

VMS is better at solving VMS problems than at solving Unix problems ..

>   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?

Never has to be "either or".  But I have to ask, but, I have to ask, how 
long has it been since Apache has been supported on VMS?  Or for that 
matter, anything else on or part of VMS, but that is being adressed by 
VSI for the future.  Perhaps they'll be interested in supporting web 
server(s).

>> 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.   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.
> 
> 

Standard names, as in "case sensitive"?  No thanks.