[Info-vax] Using VMS for a web server

[David Froble]

Stephen Hoffman wrote:
> On 2015-06-05 20:49:40 +0000, David Froble said:
> 
>> 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.
> 
> OpenSSL is ported over.  CDSA is ported over.  cdrecord is ported over. 
>  Apache is ported over.  php and Perl and Python are ported over.   ICS 
> and zic and related time-handling tools.  TCP/IP Services is ported 
> over.   libxml2.  gSOAP.  SVN.  All sorts of stuff that folks are using 
> and are increasingly depending on.

For some things that have universal usage, the application can be 
applicable to many or all specific platforms.

Everybody has had optical devices.  CDrecord is therefore a universal 
application.  I have no idea.  How much is it a port, and how much is it 
written for VMS, possibly using some logic and code from elsewhere. 
Remember, some code has very little to do with a specific platform. 
Adding 2 + 2 can happen just about everywhere, and with the same code.

OpenSSL should not depend much on any platform, at least I'd think that, 
could be wrong.  However, code can have a style used on a particular 
platform, which doesn't work so well on others.  The encryption part of 
OpenSSL should be rather common to any platform.  Why the actual 
communications are built in, and in the manner they are, is a separate 
issue, and one I feel is done poorly.  Yes, I know, you've pointed out 
in the past that the communication itself might be vulnerable.

The same could be said about several other of what you mentioned.

>> Basically, I'm not too interested in porting Unix stuff to VMS.
> 
> You might not be.  But you're very likely dependent on ported code.  

Being one of my resources, you know I am.  :-)

> More than a little of what folks are using can be.
> 
>> I'm sure there are people who are interested, but I'm not, and all I'm 
>> saying is not everyone is.
> 
> I too wasn't all that interested, but then realized I was going to end 
> up writing and supporting a whole huge pile of code to deal with a 
> common format, or port over a common library that dealt with the format 
> for me.

If the tool fits, fine.  But if it is a square peg for a round hole, 
then sometimes you can use it as an example, but you're better off 
building the round peg.

>> VMS is better at solving VMS problems than at solving Unix problems ..
> 
> It's rare for customers to target OpenVMS for their solutions, and which 
> is something VSI is undoubtedly aware.   Most customer application 
> requirements and expectations are either OS independent, or they're not 
> OpenVMS-specific.   The components of many of the applications and 
> solutions are increasingly fungible, too.

And yet, with all the troubles, some are still running VMS.  They can't 
all have my problem, can they?  I think there is something else here 
that we're not seeing, or, I'm not seeing.


>> ...
>>> 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.
> 
> Yes, for folks operating in US ASCII, implementing case insensitivity is 
> easy and can be obvious, and can be easy to implement due both to ASCII 
> and to the way that English works.
> 
> Unfortunately, in the wider world and in the Unicode world, this 
> simplicity quickly becomes a whole 'nother mess and a quagmire.   Most 
> folks are pretty quickly using a library — quite possibly a library 
> ported over from Unix — and hoping that the authors got this right.
> 
> FWIW, there was a discussion of one of places where case-blindness can 
> bite, with ß / eszett / scharfes S / sharp S, not that long ago, too:
> <https://groups.google.com/d/msg/comp.os.vms/PeqVjG3Mtxc/NF0shBmiGakJ>
> 
> Case-sensitive names can be little more than byte comparisons.  Those 
> are much simpler to implement.
> 
> As much as you or I might like case insensitivity, there are trade-offs.
> 

VMS, for multiple reasons, some of which have been discussed here, 
doesn't do some things well, or at all.  This can be more of an issue 
for some, and less for others.  I would agree that the more it can do, 
the better.  I'm hoping we're heading that way now.