[Info-vax] Using VMS for a web server
Jan-Erik Soderholm
jan-erik.soderholm at telia.com
Mon Jun 8 09:41:21 EDT 2015
Bill Gunshannon skrev den 2015-06-08 15:20:
> In article <mkt1s9$i52$1 at dont-email.me>,
> David Froble <davef at tsoft-inc.com> writes:
>> 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.
>
> It's not Unix or VMS taht anyone reasonable wants. What they want are
> applications to do their work. As it turns out right now, there are a
> lot of them on Unix and almost none on VMS.
>
>
>>
>> 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.
>
> Apparently no one is or they would be porting them. :-)
>
>>
>> VMS is better at solving VMS problems than at solving Unix problems ..
>
> There are no VMS problems. There are no Unix problems. There are business
> problems and that is what people want to be able to solve. Right now, it
> appears most of the solutions are on Unix and there are no options available
> for doing it on VMS. Personally, I don't see that as VSI's problem as none
> of these applications are a part of VMS.
>
>
>>
>>> 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).
>
> What happened to "the right tool for the job". Just what is it about VMS
> that makes it a better choice for running a webserver than one of the
> existing Unix options?
It is "better" if the source data already is on VMS.
In no other case is VMS "better" as an web server.
Noone would get a VMS system *only* to run a web server...
But then, has anyone said that VMS is *generally* the
best platform for a web server? Don't think so...
>
> Funny, you used mixed case in the sentence above. The teletype is gone.
> we actually have 52 lettters...
58.
abcdefghijklmnopqrstuvwxyzåäö
ABCDEFGHIJKLMNOPQRSTUVWXYZÅÄÖ
Now, this is rather dumb discussion. There are so many
combinations of case sensitive/case unsensitive that one
can not make any generall statements like that.
Teletype had upper case for *everything*. So what?
Then we had terminals where the user screen could use
mixed case. Many programming languages also could use
mixed case but the variables names was still case
unsensitive (Fortran, Cobol)
Then come C along and we got case sensitive variable
and symbol names (a kind of mistake, if you ask me).
When it comes to file names and command (-switches) there
is no real use of case sensitivity. Having two switches
called -a and -A for an application is only confusing.
And there is no real need of having two different files
called filea.dat and fileA.dat. Just silly and confusing.
Jan-Erik.
More information about the Info-vax
mailing list