Using VMS for a web server

[Dirk Munk]

I've always been in favour of using VMS for a web server. The reason is
quite simple, VMS is quite save out of the box (now Hoff is going to
explain to us that other operating systems improved very much, and that
certain aspects of VMS are not as save any more :-) ), and that it is
unknown to the script kiddies.

Secure web servers are vitally important for companies and institutions,
so a save web server can be a selling point.

There are three web server packages for VMS: OSU, WASD and Apache (aka
Compaq Secure Web Server CSWS, these days HP Secure Web Server but still
CSWS ?!?). I've worked with CSWS in the past, it seemed the natural
choice given the popularity of Apache - at least at the time.

I've been reading more on WASD, and more specifically on the performance
and security aspects. Performance wise, WASD is much better than CSWS,
and I've read about certain security problems with CSWS (can't find the
link again I'm afraid). WASD is a 'real' VMS product instead of a
Unix/Linux product made to run on VMS, like Apache is.

Also, in general the popularity of Apache is dwindling in favour of the
Microsoft web server. The latter seems to be much faster.

So now I wonder if it wouldn't be better to focus on WASD instead of
CSWS as the standard web server for VMS. The Australian company VMS
Software Services Pty and VSI and much more comparable than was the case
with Compaq or HP. Together the two might be able to build a set of
nice web server products for VMS.

As usual, your thoughts please.

[Jan-Erik Soderholm]

Cannot talk about CSWS, but WASD is one of those things that just starts
at boot and you can forget about it until shutdown. Rock solid...
One year uptime in a week.

We use WASD in prod using gSOAP servers and the Python persitent server,
apart from standard fixed HTML files and .COM file CGI scripts.

OSU seems to be lacking features compared with WASD.

Apache is Apache, I guess...

Jan-Erik.

[Rich Jordan]

When I was running a VMS webserver at home (with Joomla on top of PHP, etc) I was using the HP provided Apache server, and recommending it. Today I don't; it may be somewhat easier to get J-random piece of webware running on it but HP just flat doesn't support it; they are years behind on versions and updates.

When a customer had a problem with an ancient version of WASD, Mark Daniel was very helpful in determining the cause of the problem, and finding a workaround that didn't involve an upgrade (much as we would have liked to do that). WASD is being maintained and improved. You can get a lot of additions that will work with it (just not from HP and so not "the standard" such as it is).

If I get the opportunity to put up a VMS webserver again it will be on WASD.

[Stephen Hoffman]

On 2015-06-03 13:35:39 +0000, Dirk Munk said:

> I've always been in favour of using VMS for a web server. The reason is
> quite simple, VMS is quite save out of the box (now Hoff is going to
> explain to us that other operating systems improved very much, and that
> certain aspects of VMS are not as save any more :-) ), and that it is
> unknown to the script kiddies.

No; I'm just going to think your requirements are different than those
of most other folks.

> Secure web servers are vitally important for companies and
> institutions, so a save web server can be a selling point.

Might want to expand out your experiences with other platforms and tools, too.

> There are three web server packages for VMS: OSU, WASD and Apache (aka
> Compaq Secure Web Server CSWS, these days HP Secure Web Server but
> still CSWS ?!?). I've worked with CSWS in the past, it seemed the
> natural choice given the popularity of Apache - at least at the time.

So go experiment with Apache, and try building a secure configuration
with current / recent patched-to-current Apache circa 2.4.12, current /
recent mod_ssl, supported Java services, current / recent php and
Python and Perl for CGI, get a FastCGI going, current / recent ciphers
for ssh and maybe get IPsec going, get the Apache authentication hooked
to your local OpenVMS LDAP services, get IPv6 going, and post up your
experiences with that. Try out what you're considering and/or
suggesting. FWIW, this experiment is quite entirely unfair, as you
won't be able to do most this with OpenVMS, short of a huge investment
of your time and effort porting and updating code.

> I've been reading more on WASD, and more specifically on the
> performance and security aspects. Performance wise, WASD is much better
> than CSWS, and I've read about certain security problems with CSWS
> (can't find the link again I'm afraid). WASD is a 'real' VMS product
> instead of a Unix/Linux product made to run on VMS, like Apache is.
>
> Also, in general the popularity of Apache is dwindling in favour of the
> Microsoft web server.

The folks leaving Apache aren't going to IIS.
http://w3techs.com/technologies/history_overview/web_server

> The latter seems to be much faster.

If you want speed, try nginx. Maybe also try lighttpd, too. (AFAIK,
neither has been ported to OpenVMS.) Definitely try configuring and
running and managing web services different platforms. The target for
and the capabilities of nginx are different from Apache, too.

> So now I wonder if it wouldn't be better to focus on WASD instead of
> CSWS as the standard web server for VMS. The Australian company VMS
> Software Services Pty and VSI and much more comparable than was the
> case with Compaq or HP. Together the two might be able to build a set
> of nice web server products for VMS.

Most folks are interested in Apache or nginx, or — if they're running
Windows Server — IIS. These folks are not going to be interested in
OpenVMS for quite some time, either — VSI has a whole lot of work
before they're likely to start attracting new users to OpenVMS.
Existing users of OpenVMS, sure, they can run WASD or (preferably
updated) Apache on OpenVMS.

VSI will be working to move the current OpenVMS infrastructure moved
forward — the compilers and core libraries, SSL and ssh, networking,
crypto, LDAP, ncurses, X, password storage, and the many other bits
that enable other packages, for instance — and then with whatever hunks
of Apache and other network services and middle-level infrastructure
might be targeted — and particularly areas such as ease of installation
and ease of management.

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.

> As usual, your thoughts please.

Go try it — test out your guesses and your suppositions. Try some
different configurations. Try some hosted-services options.
Definitely try out some of the operating system configurations other
than OpenVMS, as those _are_ the competition here, and those are also
going to be a potential source of ideas and enhancements for OpenVMS,
too.

You might also need to expand your definition of what comprises modern
web services, too. Of what folks seeking to run such can and will
expect. That's typically going to involve far more than "just" a web
server, and has for a while now.

Related:
http://labs.hoffmanlabs.com/node/525
http://labs.hoffmanlabs.com/node/3



--
Pure Personal Opinion | HoffmanLabs LLC

[Jan-Erik Soderholm]

*Of course* you don't select VMS out of the blue, *only*
becuse you want to run a web server! There are probably
better web-only server platforms, if you are starting
an web-server operation from scratch.

The question is rather what web server should I run on my
VMS system to complement my applications and offer another
option for user interface to the users. In that case it might
be more flexible to run on the same environment as where your
(old or otherwise) applications are running.

[Stephen Hoffman]

On 2015-06-03 17:00:35 +0000, Jan-Erik Soderholm said:

> *Of course* you don't select VMS out of the blue, *only* becuse you
> want to run a web server!

Most folks will not select OpenVMS out of the blue. At all.
Irrespective of a web server.

> There are probably better web-only server platforms, if you are
> starting an web-server operation from scratch.

Probably? Even if the configuration is not starting from scratch,
and even if OpenVMS is in use, it's still common to use some other
platform for the "front-end" web services.

> The question is rather what web server should I run on my VMS system to
> complement my applications and offer another option for user interface
> to the users. In that case it might
> be more flexible to run on the same environment as where your (old or
> otherwise) applications are running.

OP still should learn more about other platforms, as those are what
even OpenVMS sites are going to be looking at, and what they're going
to be expecting, and what sort of ease-of-use or integration might be
involved. Because it's not just the web server that folks are going to
be looking for. They're probably going to be looking for Apache or
maybe nginx, too. Not WASD.

[Phillip Helbig (undress to reply)]

In article <80246$556f02ac$5ed4324a$16...@news.ziggo.nl>, Dirk Munk

<mu...@home.nl> writes:

> There are three web server packages for VMS: OSU, WASD and Apache (aka
> Compaq Secure Web Server CSWS, these days HP Secure Web Server but still
> CSWS ?!?). I've worked with CSWS in the past, it seemed the natural
> choice given the popularity of Apache - at least at the time.

Apache is a unix port, and it shows. Remember, it was originally "a
patchy server" (yes, really).

> I've been reading more on WASD, and more specifically on the performance
> and security aspects. Performance wise, WASD is much better than CSWS,
> and I've read about certain security problems with CSWS (can't find the
> link again I'm afraid). WASD is a 'real' VMS product instead of a
> Unix/Linux product made to run on VMS, like Apache is.

Indeed. OSU as well.

> So now I wonder if it wouldn't be better to focus on WASD instead of
> CSWS as the standard web server for VMS.

Or OSU. Or both.

[David Froble]

Had a short conversation with David Jones some years ago. Best I can
remember, he said that the OSU web server hadn't been updated for a
while, and from the way he said it, I got the impression there probably
wouldn't be any new work. Of course, things can always change.

However, Mark Daniels is adding to WASD, and appears to be available to
look at problems.

That one big issue tells me that there really isn't much of a choice.
You will need new stuff, and, you will need support.

[Phillip Helbig (undress to reply)]

In article <mkno2i$bh$1...@dont-email.me>, David Froble

<da...@tsoft-inc.com> writes:

> Had a short conversation with David Jones some years ago. Best I can
> remember, he said that the OSU web server hadn't been updated for a
> while, and from the way he said it, I got the impression there probably
> wouldn't be any new work. Of course, things can always change.

IIRC he has retired now, and moved the stuff from OSU to source forge.
The mailing list seems to have dried up, which surprised me because it
is independent of where the software lives. I can't be bothered to
navigate through the SourceForge website, especially because it is not
easy with browsers available on VMS. :-(

> However, Mark Daniels is adding to WASD, and appears to be available to
> look at problems.

But if he is a single point of (potential) failure, what will happen
when he is no longer available?

[Phillip Helbig (undress to reply)]

In article <mkno2i$bh$1...@dont-email.me>, David Froble
<da...@tsoft-inc.com> writes:

> Had a short conversation with David Jones some years ago. Best I can
> remember, he said that the OSU web server hadn't been updated for a
> while, and from the way he said it, I got the impression there probably
> wouldn't be any new work. Of course, things can always change.

The newest version works with HTTPs. There have been some updates
probably after you talked to him. Of course, the question is whether
the newest version NEEDS any updates. Is there any essential feature
missing? I don't know.

Dave is still around, but I don't know how much time he plans to put
into the server in the future.

[Jan-Erik Soderholm]

Stephen Hoffman skrev den 2015-06-03 22:13:
> On 2015-06-03 17:00:35 +0000, Jan-Erik Soderholm said:
>
>> *Of course* you don't select VMS out of the blue, *only* becuse you want
>> to run a web server!
>
> Most folks will not select OpenVMS out of the blue. At all. Irrespective
> of a web server.
>
>> There are probably better web-only server platforms, if you are starting
>> an web-server operation from scratch.
>
> Probably? Even if the configuration is not starting from scratch, and
> even if OpenVMS is in use, it's still common to use some other platform for
> the "front-end" web services.

Right, my experience is that most of them hasn't even asked if there
is a web server for their VMS server at all. Serving application data
out from the same VMS server where the data already is is much more
efficent then e.g. replicating data or connecting remotely to get to
the data. It is also easy to call some of your business logic to
gradualy move your users over to web based interface.

>
>> The question is rather what web server should I run on my VMS system to
>> complement my applications and offer another option for user interface to
>> the users. In that case it might
>> be more flexible to run on the same environment as where your (old or
>> otherwise) applications are running.
>
> OP still should learn more about other platforms, as those are what even
> OpenVMS sites are going to be looking at, and what they're going to be
> expecting, and what sort of ease-of-use or integration might be involved.
> Because it's not just the web server that folks are going to be looking
> for. They're probably going to be looking for Apache or maybe nginx, too.
> Not WASD.

As I said, noone would use a VMS system *only* to run a web server.
The need will always be to complement some old application on that
VMS server with some more modern user interface.

[hb]

On 06/03/2015 04:20 PM, Jan-Erik Soderholm wrote:
> We use WASD in prod using gSOAP servers and the Python persitent server,
> apart from standard fixed HTML files and .COM file CGI scripts.

For dynamic webpages you can also use Tomcat as a stand-alone server to
run Java Servlets and JavaServer Pages, known as JSPsserve Servlets and
JSP. Just out of the box - ahem tgz, OK, you may want to have some
scripts aka DCL command procedures, like

$ @[.apache-tomcat-7^.0^.61.bin]version
Server version: Apache Tomcat/7.0.61
Server built: Mar 27 2015 12:03:56 UTC
Server number: 7.0.61.0
OS Name: OpenVMS
OS Version: V8.4
Architecture: ia64
JVM Version: 1.6.0-6
JVM Vendor: Hewlett-Packard Company
$

Latest version is 7.0.62, I haven tried it, but I expect it to work as
well. For Tomcat 7 you need Java 6; Tomcat 6 works with Java 5; Tomact 8
requires Java 7.

[Jan-Erik Soderholm]

I'd prefer a single point that *is* available then one that isn't.
Hopefully VSI can make some arrangement so that Mr Daniels will
not be alone anymore.

> Of course, the question is whether the newest version NEEDS any
> updates. Is there any essential feature missing? I don't know.

You can check: http://wasd.vsm.com.au/wasd_root/doc/misc/scripting.html
Which of those are available natively in OSU?
CGIplus, FasyCGI, ISAPI, HTML5 Web Sockets ?
Persistent servers for Java, Perl, PHP, Python and gSOAP?

[mcle...@gmail.com]

On Thursday, June 4, 2015 at 7:35:09 AM UTC+10, Jan-Erik Soderholm wrote:

> I'd prefer a single point that *is* available then one that isn't.
> Hopefully VSI can make some arrangement so that Mr Daniels will
> not be alone anymore.
>

I used WASD about 10 or 12 years ago. I have a feeling that Mark provided the source code so it could be built on our platform. He was also certainly quick to respond if we had any questions.

We used it with auto-generated and (hopefully) unique tags so that we could store data on the VMS system and pass that tag and little other info (if any) in the URL rather than the long URLs being used by other web-servers at the time. (I heard once of medical or tax records being available via a webserver and if you changed a character or two in the URL you could see someone else's records.) IIRC VMS access controls meant that everything was secure.

WASD is very much a VMS implementation of a webserver, not a port of some other, perhaps buggy, code.

[Rich Jordan]

HP is huge, has/had extremely competent and non S.P.F. resources... and look what happened to OpenVMS Apache and the related products under their control.

[Dirk Munk]

I'm well aware of the enormous list of software products that are in
need of serious updating on VMS. If you can take CSWS out of that list
because WASD can do the same, and maybe even better, than that is one
item less on the list.

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.

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

>> As usual, your thoughts please.
>
> Go try it — test out your guesses and your suppositions. Try some
> different configurations. Try some hosted-services options. Definitely
> try out some of the operating system configurations other than OpenVMS,
> as those _are_ the competition here, and those are also going to be a
> potential source of ideas and enhancements for OpenVMS, too.
>
> You might also need to expand your definition of what comprises modern
> web services, too. Of what folks seeking to run such can and will
> expect. That's typically going to involve far more than "just" a web
> server, and has for a while now.

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.

[Simon Clubley]

On 2015-06-03, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>
> IIRC he has retired now, and moved the stuff from OSU to source forge.
> The mailing list seems to have dried up, which surprised me because it
> is independent of where the software lives. I can't be bothered to
> navigate through the SourceForge website, especially because it is not
> easy with browsers available on VMS. :-(
>

Be warned: given recent events, SF is rapidly getting blacklisted by
people in general so telling technical people to download stuff from SF
is not likely to go down well.

The only thing I would currently trust from SF are the source code kits
(but only if there were no other download source for them) and you won't
catch me downloading those source code kits from a Windows system...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Henry Crun]

On 03/06/15 17:20, Jan-Erik Soderholm wrote:
> Dirk Munk skrev den 2015-06-03 15:35:

>>

<...snip...>

> One year uptime in a week.
>

How do you do that? Faster-than-light travel?

<...more snip...>
>
> Jan-Erik.


--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/php/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before


--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Craig A. Berry]

On 6/3/15 8:01 PM, Simon Clubley wrote:

>
> Be warned: given recent events,

What events?

> SF is rapidly getting blacklisted by
> people in general so telling technical people to download stuff from SF
> is not likely to go down well.
>
> The only thing I would currently trust from SF are the source code kits
> (but only if there were no other download source for them) and you won't
> catch me downloading those source code kits from a Windows system...

Well, that's a shame. As I write this I'm preparing to upload binary
kits for OpenVMS of the latest release of Perl to SourceForge. You seem
to be saying I shouldn't do this but I have no idea why.

[Simon Clubley]

On 2015-06-04, Craig A. Berry <craig...@nospam.mac.com> wrote:
> On 6/3/15 8:01 PM, Simon Clubley wrote:
>
>>
>> Be warned: given recent events,
>
> What events?
>

Sorry, I assumed this was now common knowledge.

Start here and work backwards through the links to catch up:

http://it.slashdot.org/story/15/06/03/126224/nmap-maintainer-warns-he-doesnt-control-nmap-sourceforge-mirror

> > SF is rapidly getting blacklisted by
>> people in general so telling technical people to download stuff from SF
>> is not likely to go down well.
>>
>> The only thing I would currently trust from SF are the source code kits
>> (but only if there were no other download source for them) and you won't
>> catch me downloading those source code kits from a Windows system...
>
> Well, that's a shame. As I write this I'm preparing to upload binary
> kits for OpenVMS of the latest release of Perl to SourceForge. You seem
> to be saying I shouldn't do this but I have no idea why.
>

OpenVMS binaries probably are ok, but given the huge backlash the actions
of the current SF owners have caused, SF itself is getting boycotted
in certain (ever increasing) circles.

As for the will not download from Windows system reference above, search
the above nmap story for "fake download". The claim is that SF are
presenting what appear to be fake download buttons in come cases
alongside the genuine ones.

I don't know if it only happens in certain circumstances or if they are
doing operating system sniffing, but I have not seen these myself yet.
However, given everything else SF have been reported as doing, I'm not
taking any chances from now on.

[Alan Frisbie]

On 06/03/2015 06:35 AM, Dirk Munk wrote:

> So now I wonder if it wouldn't be better to focus on WASD
> instead of CSWS as the standard web server for VMS.

I installed WASD at a client's site for some simple in-house
web pages about three years ago. It is still running with
no further attention necessary (the contents are updated by
a periodic batch job).

Alan Frisbie

[David Froble]

Phillip Helbig (undress to reply) wrote:

And in what way is this worse than no support and no one to contact ?

If VSI should embrace WASD, then they would need to look at the issues
and be prepared to insure Mark gets "encourgement" (read money) and backup.

[JF Mezei]

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.


Also, "<company> Secure Web Server" has 0 marketing value. If VSI can
claim that Apache runs on VMS, then this has marketing value.

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.

One aspect:

If Command files are to be a supported scripting language, then some
form of support must be provided for file uploads, long free form text
fields and other constructs which don't fit well in DCL symbols. (or
update DCL to support those).

[Dirk Munk]

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.

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

[terry+go...@tmk.com]

On Wednesday, June 3, 2015 at 11:27:28 PM UTC-4, Simon Clubley wrote:
> As for the will not download from Windows system reference above, search
> the above nmap story for "fake download". The claim is that SF are
> presenting what appear to be fake download buttons in come cases
> alongside the genuine ones.

That probably isn't SF's doing. Those same fake download buttons appear on many other sides and are ads. A number of the more legitimate (and illegitimate 8-) download sites have a "remove ad" button to hide some of them.

Almost all of the ones I've encountered are served by a particular advertising platform (this is the one with a green "<" and "[X]" in the top right). Unfortunately, the link for "report this ad" doesn't have a category for "ad serves malware".

BTW, SF and Slashdot are owned by the same holding company (DHI) which makes it amusing that this story broke on Slashdot.

[Simon Clubley]

On 2015-06-04, terry+go...@tmk.com <terry+go...@tmk.com> wrote:
>
> BTW, SF and Slashdot are owned by the same holding company (DHI)
> which makes it amusing that this story broke on Slashdot.

Actually the initial story broke elsewhere and Slashdot suppressed story
submissions about it for several days until the tide of anger among the
Slashdot community was so large they couldn't do that any more.

It's only now that Slashdot are giving full coverage to these events.

[Jan-Erik Soderholm]

Henry Crun skrev den 2015-06-04 04:03:
> On 03/06/15 17:20, Jan-Erik Soderholm wrote:
>> Dirk Munk skrev den 2015-06-03 15:35:
>
>>>
> <...snip...>
>> One year uptime in a week.

One year of uptime at 14-June.

[Paul Sture]

On 2015-06-04, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
wrote:

> On 2015-06-04, terry+go...@tmk.com <terry+go...@tmk.com> wrote:
>>
>> BTW, SF and Slashdot are owned by the same holding company (DHI)
>> which makes it amusing that this story broke on Slashdot.
>
> Actually the initial story broke elsewhere and Slashdot suppressed story
> submissions about it for several days until the tide of anger among the
> Slashdot community was so large they couldn't do that any more.
>
> It's only now that Slashdot are giving full coverage to these events.

Ars Technica from a couple of days ago:

<http://arstechnica.com/information-technology/2015/06/sourceforge-locked-in-projects-of-fleeing-users-cashed-in-on-malvertising/>

--
I don't know what the language of the year 2000 will look like, but I
know it will be called Fortran. -- Tony Hoare 1982

[Craig A. Berry]

On 6/3/15 10:26 PM, Simon Clubley wrote:
> On 2015-06-04, Craig A. Berry <craig...@nospam.mac.com> wrote:
>> On 6/3/15 8:01 PM, Simon Clubley wrote:
>>
>>>
>>> Be warned: given recent events,
>>
>> What events?
>>
>
> Sorry, I assumed this was now common knowledge.
>
> Start here and work backwards through the links to catch up:
>
> http://it.slashdot.org/story/15/06/03/126224/nmap-maintainer-warns-he-doesnt-control-nmap-sourceforge-mirror

Thanks. I had skimmed the headline on Ars Technica a couple days ago but
didn't see that there was any big deal.

>>> SF is rapidly getting blacklisted by
>>> people in general so telling technical people to download stuff from SF
>>> is not likely to go down well.
>>>
>>> The only thing I would currently trust from SF are the source code kits
>>> (but only if there were no other download source for them) and you won't
>>> catch me downloading those source code kits from a Windows system...
>>
>> Well, that's a shame. As I write this I'm preparing to upload binary
>> kits for OpenVMS of the latest release of Perl to SourceForge. You seem
>> to be saying I shouldn't do this but I have no idea why.
>>
>
> OpenVMS binaries probably are ok, but given the huge backlash the actions
> of the current SF owners have caused, SF itself is getting boycotted
> in certain (ever increasing) circles.
>
> As for the will not download from Windows system reference above, search
> the above nmap story for "fake download". The claim is that SF are
> presenting what appear to be fake download buttons in come cases
> alongside the genuine ones.

As far as I can tell, what they did is only incrementally more evil than
all the ads and crapware they've always pushed and is identical to what
companies like Oracle with Java and Adobe with Flash routinely do. If
you aren't paying careful attention during the install, you don't see
the checkboxes preselected that will install extra doodads that you
might not want.

SF has always had extra ad-related crud. Typically when you start a
download you are then presented with another Download button an inch
high that is for something completely unrelated. I don't like it but
there aren't many places one can publish binaries; GitHub did away with
downloads and code.google.com did the same and is now shutting down
entirely.

[MG]

Paul Sture schreef op 4-jun-2015 om 14:01:

> On 2015-06-04, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> wrote:
>> On 2015-06-04, terry+go...@tmk.com <terry+go...@tmk.com> wrote:
>>>
>>> BTW, SF and Slashdot are owned by the same holding company (DHI)
>>> which makes it amusing that this story broke on Slashdot.
>>
>> Actually the initial story broke elsewhere and Slashdot suppressed story
>> submissions about it for several days until the tide of anger among the
>> Slashdot community was so large they couldn't do that any more.
>>
>> It's only now that Slashdot are giving full coverage to these events.
>
> Ars Technica from a couple of days ago:
>
> <http://arstechnica.com/information-technology/2015/06/sourceforge-locked-in-projects-of-fleeing-users-cashed-in-on-malvertising/>

It's beginning to get quite hard to keep up with, with all of these
security and privacy intrusions and violations, especially nowadays...
And it's a de facto requirement that you spend a considerable time
going through all these news sites, attempting to stay 'up-to-date'
on all of these truly heartwarming issues.

Luckily our governments are working hard to protect us from these
violations and scams.

It's amazing what people put up with nowadays. This reminds me of
one of the things I absolutely love about operating systems like
VMS (save for things like the PAKs hassle), Tru64 UNIX, IRIX and
so forth, being that you have in essence a largely 'nag-free'
operating system.

- MG

[Stephen Hoffman]

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?

[Stephen Hoffman]

On 2015-06-04 02:57:30 +0000, Craig A. Berry said:

> On 6/3/15 8:01 PM, Simon Clubley wrote:
>
>>
>> Be warned: given recent events,
>
> What events?

Some background on the so-called "SourceForgery" kerfuffle:

http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/

http://libregraphicsworld.org/blog/entry/anatomy-of-sourceforge-gimp-controversy

https://blog.l0cal.com/2015/06/02/what-happened-to-sourceforge/

>> SF is rapidly getting blacklisted by people in general so telling
>> technical people to download stuff from SF is not likely to go down
>> well.
>>
>> The only thing I would currently trust from SF are the source code kits
>> (but only if there were no other download source for them) and you
>> won't catch me downloading those source code kits from a Windows
>> system...
>
> Well, that's a shame. As I write this I'm preparing to upload binary
> kits for OpenVMS of the latest release of Perl to SourceForge. You seem
> to be saying I shouldn't do this but I have no idea why.

I'd hope that at some point, VSI gets a few cycles to look at project
hosting, either outsourced or their own server. Having access to the
download data might be interesting to the VSI folks, too.

One overarching downside at present is a general lack of easy-to-use
OpenVMS tools for doing distributed source control. There's some work
try to make that easier including work toward a pre-installed OpenVMS
kit for hobbyist developers, but — even for an experienced user,
getting SVN going or particularly a newer environment such as git or
mercurial going is presently a non-trivial slog. If you're not using
an add-on GUI IDE, then getting a LSEDIT session and some command line
tools to connect with a repository other than CMS and a build engine
other than MMS would be nice, too. (This also ties back into the lack
of common tools in OpenVMS that I mentioned in a posting elsewhere —
client tools and repositories are both missing from OpenVMS, and "going
your own way" with platform-unique tools such as CMS and MMS not only
makes for more efforts, it provides comparative limits in the DVCS and
distributed build tools; in the more current world.)

[Stephen Hoffman]

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?

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

[Jan-Erik Soderholm]

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.

[Jan-Erik Soderholm]

Mercurial is pre-installed in the Python kit/port for VMS.

$ @ MERCURIAL_ROOT:<vms>setup
$
$ hg
Mercurial Distributed SCM

basic commands:

add add the specified files on the next commit
annotate show changeset information by line for each file
clone make a copy of an existing repository
commit commit the specified files or all outstanding changes
...
...

I have done nothing apart from running the setup.com above.
And installing the two Python virtual (LD) disks, of course...

[JF Mezei]

On 15-06-05 10:40, Stephen Hoffman wrote:

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

While I agree with the above, there is however an exception: if your
proprietary web browser offers performance or other features that beat
the pants off Apache, then that could become a selling point. But you
will need to have Apache on VMS.

[Dirk Munk]

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.

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

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

[terry+go...@tmk.com]

On Friday, June 5, 2015 at 3:11:27 PM UTC-4, Dirk Munk wrote:
> Of course VSI has to think of the effort it takes to maintain a VMS
> Apache version.

IMHO, such efforts would be better applied to making it easier to build random apps written in Unix-style source, rather than spending the effort trying to wrestle with the code of specific apps to get them to build on VMS.

VMS has attempted to deal with this in a variety of ways over time. I was excited to install the VMS Posix product when it was first released. On a VAX 8650 (no slouch at the time), Perl's "configure" script ran for over an hour and then bombed out.

Since then, various things have been tried. It seems that Compaq (and even more so) HP have gone the route of extensively modifying various packages (SAMBA, Apache, SSL, etc.). Unfortunately those are moving targets, whereas HP seems to have decided "We ported version X.Y.Z (and called it version A.B-C), our work is done". It doesn't help when the port is called "Industry Standard Thingamajig" instead of the name the rest of the world knows it by.

Sometimes the changes have been submitted back to the upstream. Some upstreams would accept VMS changes, some would not. Rejections seemed to me to be more a case of the upstream not having a VMS system to test against rather than any particular loathing of VMS.

Of course, as VMS became more and more compatible, many of those changes were no longer relevant, even on VMS. While VMS folks might be offended by the motto of OpenSSL Valhalla Rampage - "Tearing apart OpenSSL, one arcane VMS hack at a time", it is rather true if you look at the code.

In that particular case, I'd categorize the changes into 3 major groups and estimate their prevalence as:

1) Missing Unix-like functionality that needed to be emulated / worked around
2) VMS compiler bugs or things thought to be bugs because everybody else used GCC
3) Other

At the time I was porting Unix code to VMS (which I admit was years ago), some common problems were deficiencies in things like select(), where some parts were not implemented and other parts were implemented but broken, and case-sensitivity in symbols and filenames (this was long before ODS-5 solved the latter). Writing a DCL command file to build the code was trivial after wrestling with the code, though it would have been nice to be able to re-use the existing Makefile.

A lot of these are things that could best be addressed during a port to a new architecture. It might be worthwhile asking some of the people doing porting work (such as GNV) what sort of new / changed VMS features would make building Unix-style software on VMS an easier task.

Perhaps this is already being done - I haven't been involved with developing / porting code onto VMS in years.

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

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.

[David Froble]

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.

[JF Mezei]

Suggestion to VSI on Apache:

It is unclear to me how much patching is required to make Apache run on VMS.

Ideally, customers should have a "kit" to which they can apply changed
Apache stuff and rebuilt the VMS version.

This would give VMS customers "instant" access to patches and new
features while allowing VSI to focus only on the modules that are very
VMS specific.

For the "standard" modules that have only minor modifs in the code, VSI
should embed them with #ifdef stuff in the open sourced code base once
so they don't have to constant do it.

[David Froble]

If I was still installing new systems I have the opinion that I could
roll in that rack or two of new systems and have them up and running
without a lot of fuss.

What you're talking about is whether knowledge and capability are
required, or whether any old dummy that can figure out a mouse can do
so. Maybe there are systems where any old dummy can set them up, but I
have to wonder, how well are they actually set up, and is this type of
thing where some of today's security and other problems might be coming
from? You get what you pay for. Pay for the dummy, if that's all you want.

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

You actually open up a topic that isn't often considered. Who were
those people in the 1980s and 1990s, and 1970s for that matter, that
were solving problems with what was then very expensive computers? To
answer my own question, they were people who vitally needed the
capabilities, and had the resources to pay for the capabilities. Don't
think those people no longer exist. What has happened is that the costs
have dropped so low that just about anyone can make use of some of the
capabilities. So yes, the majority are the newer users, and yes, they
expect things to be easy, and cheap. But the "more serious" (my term)
users are still there, and they sometimes still need the "more serious"
capabilities.

You claim it's "a few parts of the installed base". Mostly because the
installed base has grown so much larger. Not because there is no longer
any need.

Or most of the above ....

[Jan-Erik Soderholm]

JF Mezei skrev den 2015-06-05 23:05:
> Suggestion to VSI on Apache:
>
> It is unclear to me how much patching is required to make Apache run on VMS.
>
> Ideally, customers should have a "kit" to which they can apply changed
> Apache stuff and rebuilt the VMS version.

I'd rather use a product (web server or whatever) that *I*
do not have to build myself.

>
> This would give VMS customers "instant" access to patches and new
> features while allowing VSI to focus only on the modules that are very
> VMS specific.

What if the very VMS specific modules are part of the patches?
Why do you think that all patches just "work" in the VMS
adapted version of the application?

>
> For the "standard" modules that have only minor modifs in the code, VSI
> should embed them with #ifdef stuff in the open sourced code base once
> so they don't have to constant do it.
>

Yes, if the maintainer accepts VMS specific def/ifdef's in the code
base. That is not at all always the case.

[John Reagan]

On Friday, June 5, 2015 at 4:48:21 PM UTC-4, David Froble wrote:

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

I'm in the other boat of course as I'm porting LLVM to OpenVMS. It uses subversion for source control, uses configure, make, and Python for the build and test. It uses mixed-cased filenames (which is fine with me). It came from the Linux/Darwin world and most of the contributors come from there. I need to be able to track/get changes quickly and efficiently. I've already got my scars from the C headers (the lack of a handful of definitions AND some just broken feature flags in the decc$types.h header). Using GNV, I'm making good programs (and no, I'm not going to send my changes to the newsgroup for a code-review).

Making OpenVMS live in a mixed-OS world seems important to me if some customer wants to write an application that runs on all the platforms (although you can make the argument in that case that OpenVMS has little added value).

[John Reagan]

On Friday, June 5, 2015 at 5:25:37 PM UTC-4, John Reagan wrote:
> Using GNV, I'm making good programs

*progress

[terry+go...@tmk.com]

On Friday, June 5, 2015 at 4:48:21 PM UTC-4, David Froble wrote:

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

Neither of which is particularly relevant to the business community. They have business problems*, not VMS or Unix problems. Most will want to solve their business problems for the smallest cost that accomplishes their goals of features / performance / security (probably in that priority). In many cases, that involves hiring or utilizing existing staff who are familiar with the tools used to solve that business problem. VMS is going to be difficult enough to sell to new customers (remember, on x86 it is competing with "free"**) without also telling those customers that they will need to find people with an obscure talent to not only manage the operating system, but the applications that support the business, instead of getting some of the widely available sysadmins / developers familiar with Unix-type systems.

* This is a particular point with me because as a fresh-out-of-school kid I interviewed with Data General for a software development position and completely flunked the "why are we here" part of the interview. It isn't to sell computers, or have the best product - it is to provide something that lets customers solve their problems in a more effective manner than if they bought from the competition. All else follows on from that.

** And who might buy software and support from VSI, but who might not want HP hardware for any one of a number of reasons. There's a famous quote from a school (not mine) from when DEC cancelled the Jupiter project: "We're switching to Unix because then we will have a huge choice of vendors to screw us."

[David Froble]

I know nothing, but if I did know something, one thing might be that one
of the really big issues is FORK. VMS doesn't FORK, and I don't miss
it. Unfortunately, VMS doesn't make it easy to work around, with
respect to accepting a socket connection and having each processed while
additional connection requests are serviced. The documentation on this
in the TCP/IP docs is non-existent.

So it's most likely not some little things in Apache, but at least one
BIG thing. The way I understand the VMS workaround in Apache is a set
of sub-processes is set up and used as required. Not sure what happens
if that set is all in use and more connection requests come in. Maybe
it gets expanded.

I'm not even sure it should be sub-processes. Once a task is assigned,
it should finish, and not be terminated if the parent process has a
problem. At least that's my plan, if I ever get back to that task.

Unix is not VMS, and VMS is not Unix. Expecting one to work like the
other just isn't reasonable, in my opinion. That leads to Unix
applications perhaps not working so well on VMS. To me the problem is
not being able to port Unix applications to VMS. The problem is not
having the functionality in VMS applications.

[David Froble]

terry+go...@tmk.com wrote:
> On Friday, June 5, 2015 at 4:48:21 PM UTC-4, David Froble wrote:
>> VMS is better at solving VMS problems than at solving Unix problems
>> ..
>
> Neither of which is particularly relevant to the business community.
> They have business problems*, not VMS or Unix problems. Most will
> want to solve their business problems for the smallest cost that
> accomplishes their goals of features / performance / security
> (probably in that priority). In many cases, that involves hiring or
> utilizing existing staff who are familiar with the tools used to
> solve that business problem. VMS is going to be difficult enough to
> sell to new customers (remember, on x86 it is competing with
> "free"**) without also telling those customers that they will need to
> find people with an obscure talent to not only manage the operating
> system, but the applications that support the business, instead of
> getting some of the widely available sysadmins / developers familiar
> with Unix-type systems.

If this is the case, then why are people still using VMS?

Aging personal, which usually means more expensive to hire ..

Smaller pool of knowledgeable people ..

More solutions available ..

And so on ..

So, why then is anyone still using VMS?

Maybe what you suggest isn't accurate, or, maybe there is something
else. Got to be something, because there are still people using VMS,
and I doubt VSI could have raised one cent if they didn't know who these
people are, and could count on their continued usage of VMS.

I doubt it's a holdover thing. It's been over 15 years since DEC
started pushing Unix and weendoze. Anybody that could use the Unix or
weendoze systems is most likely long gone. Why is anyone left?

Perhaps there are VMS problems that customers can use VMS to solve in
the most effective manner?

[terry+go...@tmk.com]

On Friday, June 5, 2015 at 8:54:34 PM UTC-4, David Froble wrote:
> If this is the case, then why are people still using VMS?
>

> So, why then is anyone still using VMS?
>

> Perhaps there are VMS problems that customers can use VMS to solve in
> the most effective manner?

They may have a system that meets their needs where they don't feel the need for new programming / sysadmin support. If the VMS system just sits in the corner performing its task, then things may be perfectly fine until it breaks. At which point the customer may have to face the hard reality of pricing for spares / support on the existing system, and/or the cost to migrate to newer, supported hardware and software. At which point it is entirely possible that they'll do the least expensive thing to limp along until the system is replaced by something else. This may be complicated by no longer having the source code (or having it, but it no longer compiles) to their applications.

By definition, HP only has accurate information (and has presumably passed at least some of it along to VSI) about customers who are still paying HP for hardware and/or software support. The rest of their "customer database" is likely inaccurate (companies that have gone out of business/merged, who no longer run VMS, or who still run VMS but don't see any benefit to what HP is offering).

Paying customers are almost definitely a small subset of the number of non-hobbyist systems deployed, although I'm sure there are some MAJOR customers still paying for support.

The challenge for VMS, and thus for VSI, is to bring a new VMS platform to the attention of both of the following groups:

1) Shops still running VMS, but either without support or who pay some 3rd party for support
2) Shops that either never ran VMS or who already migrated away from VMS for some reason

In other words, attracting new business. It would seem that VSI feels that there is enough of a market there to justify doing the work they're doing. I mentioned in much older posts that the desires of those two groups are pretty much the opposite of each other - the first group wants to run their existing applications (possibly without recompiling, if they no longer have the sources or there is no compiler support for them). For this group, the less change the better. And "modern" VMS and the hardware it runs on need to be priced competitively enough that they aren't dismissed out of hand in favor of migration. The second group wants the exact opposite, feature-wise - a modern operating system with modern language and library support where they can re-implement their existing applications and grow. But they also want an environment where VMS + hardware is cost-competitive with what they're already doing. In fact, for these potential customers the advantage needs to be more than that - VMS needs to make the case for being a better solution for them, not just one "that doesn't cost much more"

[Stephen Hoffman]

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.

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

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

> ...

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

[Craig A. Berry]

On 6/5/15 8:43 PM, Stephen Hoffman wrote:
> On 2015-06-05 20:49:40 +0000, David Froble said:


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

Also, Unix portability is not just about getting created-on-Unix
packages. I have seen e-mail traffic from people involved in producing
commercial VMS products at big-name companies who were begging for
better Unix portability so they wouldn't have to spend so many resources
customizing the build for VMS.

[Stephen Hoffman]

On 2015-06-05 21:14:47 +0000, David Froble said:

> Stephen Hoffman wrote:
>>

>> 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.
>
> If I was still installing new systems I have the opinion that I could
> roll in that rack or two of new systems and have them up and running
> without a lot of fuss.
>
> What you're talking about is whether knowledge and capability are
> required, or whether any old dummy that can figure out a mouse can do
> so.

One of the features of boxes is that they self configure — you roll in
the rack, screw down the legs, connect the network, power it up, and
the box announces itself and configures itself, using the the
infrastructure that was set up from some centralized IT management
center.
<http://www.dell.com/learn/us/en/555/solutions/integrated-dell-remote-access-controller-idrac>

<https://software.intel.com/en-us/articles/remote-configuration-for-intel-amt>

(From what I can find, HPE iLO trails in terms of its support for
provisioning and profiles — most of what I see seems to involve
pressing F10 in POST.)

> Maybe there are systems where any old dummy can set them up, but I have
> to wonder, how well are they actually set up, and is this type of thing
> where some of today's security and other problems might be coming from?
> You get what you pay for. Pay for the dummy, if that's all you want.

Are you mapping your experience with setting up and managing OpenVMS
servers over to other systems, and without — as I've been suggesting in
this thread — having tried some of those other systems? Newer systems
increasingly self-manage, and self-patch, and increasingly
self-configure.

This patching does mean that you can need to become part of the vendor
field-test process, rather than the older model were the ISV rolled out
the updates. Yes, that older model is still possible. Some ISVs and
some organizations do stage patches and do roll out their patches and
their own deployments, but they're increasingly using vendor-provided
tools and services to do that.

Also ponder how many under-patched OpenVMS systems are around. The
much-vaunted uptime statistic that some folks like to quote is the
measure for how down-revision the box is, after all.

[David Froble]

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.

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.

[David Froble]

I've played with various flavors of weendoze. No, I've not had any
experience with *ux. Personally, I'm not impressed with the direction
weendoze is going.

As for self patch, that's the first thing I turn off. I might trust VSI
in the future, but Microsoft, I don't think so.

I'm not saying there cannot be improvements. While AUTOGEN is rather
old, something like it that is better automated would be a good thing.
Something better than MODPARAMS.DAT for you to add your own flavoring
would also be a good thing.

You and I have had discussions in the past about monitoring the P400
controller and disks. You're aware that I'm rather disgusted with
what's available. Yes, room for vast improvement.

> This patching does mean that you can need to become part of the vendor
> field-test process, rather than the older model were the ISV rolled out
> the updates. Yes, that older model is still possible. Some ISVs and
> some organizations do stage patches and do roll out their patches and
> their own deployments, but they're increasingly using vendor-provided
> tools and services to do that.
>
> Also ponder how many under-patched OpenVMS systems are around. The
> much-vaunted uptime statistic that some folks like to quote is the
> measure for how down-revision the box is, after all.
>
>

My unpatched VAX/VMS V7.2 system doesn't seem to have any problems.

Ok, I went too far with that. I have to admit that it's more an
electric heater than a computer, considering the amount of usage it sees.

:-)

[Jan-Erik Soderholm]

David Froble skrev den 2015-06-06 02:55:
> terry+go...@tmk.com wrote:
>> On Friday, June 5, 2015 at 4:48:21 PM UTC-4, David Froble wrote:
>>> VMS is better at solving VMS problems than at solving Unix problems
>>> ..
>>
>> Neither of which is particularly relevant to the business community.
>> They have business problems*, not VMS or Unix problems. Most will
>> want to solve their business problems for the smallest cost that
>> accomplishes their goals of features / performance / security
>> (probably in that priority). In many cases, that involves hiring or
>> utilizing existing staff who are familiar with the tools used to
>> solve that business problem. VMS is going to be difficult enough to
>> sell to new customers (remember, on x86 it is competing with
>> "free"**) without also telling those customers that they will need to
>> find people with an obscure talent to not only manage the operating
>> system, but the applications that support the business, instead of
>> getting some of the widely available sysadmins / developers familiar
>> with Unix-type systems.
>
> If this is the case, then why are people still using VMS?
>
> Aging personal, which usually means more expensive to hire ..
>
> Smaller pool of knowledgeable people ..

I had a talk with a customer last week. We comment the fact
that there had been no support ticket regarding the platform
(HW, VMS and Rdb, more or less) since last reboot June-14.
And very few application level supports tickets b.t.w.
It's rock solid.

This is of course a good thing for the users, but it does not help
building and maintaining the knowledge in the support group. :-)
And that is actualy seen as a real problem...

But the system still does what it has done the last 30+ years,
the users are happy and we have several different projects for
additional functionallity. Mostly new connections to PLC's
and logging additional status from the assembly lines.

[Dirk Munk]

Jan-Erik Soderholm wrote:

> I had a talk with a customer last week. We comment the fact
> that there had been no support ticket regarding the platform
> (HW, VMS and Rdb, more or less) since last reboot June-14.
> And very few application level supports tickets b.t.w.
> It's rock solid.
>
> This is of course a good thing for the users, but it does not help
> building and maintaining the knowledge in the support group. :-)
> And that is actualy seen as a real problem...
>

I applied for a VMS job several months ago. During the job interview I
was asked about my knowledge on all kind of other things, but not on
VMS. I wasn't an expert on those areas, so they said that would be a
problem. When I replied that they were asking for a VMS expert, they
never mentioned those other areas of expertise. Well, that was true, but
the VMS system had the habit of doing what it was suppose to do, and it
had been doing that for years. It never needed any human assistance or
intervention. In fact I would have almost nothing to do if my only work
would be maintaining the VMS system.

To be fair, other systems can be made to run very reliable as well, but
quite often systems are set up to run, not to run reliable. The drive to
build reliable systems often just isn't there.

[Stephen Hoffman]

On 2015-06-06 10:35:49 +0000, Jan-Erik Soderholm said:

> This is of course a good thing for the users, but it does not help
> building and maintaining the knowledge in the support group. :-) And
> that is actualy seen as a real problem...

Ayup. Skills can and do atrophy.

> But the system still does what it has done the last 30+ years, the
> users are happy and we have several different projects for additional
> functionallity. Mostly new connections to PLC's and logging additional
> status from the assembly lines.

Very familiar with that environment. Thankfully, most PLCs are slight
less stupid than they once were. Slightly. Biggest discussions and
debates tend to happen with the next-generation installations. When
the production line or the factory is due for replacement. That's when
OpenVMS installations tend to be replaced. With the existing
production lines, changes are rare and incremental, and spare parts are
accrued and the old server boxes are lovingly and very effectively run
into the ground.

The support staff can get stuck in their own time warp — donno about
your bunch Jan-Erik, but I've seen it happen in factory environments —
in terms of their skills with OpenVMS and with newer and competitive
automation systems and PLCs, and also around newer development tools
and approaches.

[David Froble]

It can be worse than that.

At one former customer, there was this lady in charge of IT. Two person
shop, so that made her both chief and indian. The way she put things
together, she made herself indispensible. The management knew it. They
didn't know what to do about it. Any time they said something, she
threatened to quit. The stuff she was in charge of needed manual
control, every day. If she left, they were dead in the water.

Now, I've heard that if you have someone irreplacable, the first step is
to fire them. They should have been training others is what needed to
be done, and didn't for whatever reason, including guaranteed job
security. Things could only get worse.

They had one application I provided back in 1985, running on RSTS, and
ported to VAX-VMS in the 1990s. It did not need the daily hand holding.
It was the only reliable application they had. So, you guessed it,
management was enamored by weendoze, and wanted that application ported
(re-written) for weendoze. It was good money.

Stick around in this business long enough, and nothing will ever
surprise you.

[David Froble]

So, what are we saying? That there can be such a thing as "too good"?

[Stephen Hoffman]

On 2015-06-06 16:02:11 +0000, David Froble said:

> So, what are we saying? That there can be such a thing as "too good"?

Yes, there is such a thing. Over-designing some product is
comparatively easy. If you miss your target market, you're in deep
trouble.

If you're building a barn, then you'll find using trees are expensive
and heavy, you need a number of large trees, and constructing a classic
post-and-beam requires effort, skill and (lately) a ginormous CNC mill.
Using an engineered solution such as truss involves more complex
pieces, and trusses are prone to sudden failures in extreme conditions,
but trusses are cheaper, and you can use more of what might have been a
brace or just scrap wood within a post-and-beam structure. There are
yet more expensive and better solutions than using a post-and-beam
design, too. There's a market for post-and-beam barns, but it's not
nearly as big as that of the pole barn, or of the ordinary commercial
prefab construction that you can see getting delivered to building
sites by the truckload. But I digress.

Getting back to software, a well-run, existing production application
installation usually tries to get to at least a local minima of
whatever they're optimizing for (usually cost and effort, increasingly
based on data collection and analysis), and a major upgrade or a
replacement installation often looks at getting into whatever the
current global minima might be.

Yes, there are vendors which target better-grade products — not usually
"too good" — and there can be profits here for the best of those
vendors. But it's a whole lot of work and a whole lot of investment
to ensure that you're meeting and variously exceeding the expectations
of your customers. Spend too much getting to "perfect", and you'll
likely lose your customers, too. Tradeoffs.

[Paul Sture]

That one was interesting. We solved a similar problem many moons ago
via a shareable writable image plus associated utility to change the
settings on a per system basis, and that could without too much effort
have been repurposed to do the same on a group basis. I'm not sure that
would have been the right solution for the compiler problem though.

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

I recently came across another little head scratcher in this morass,
where the error message was along the lines of "invalid character for
your locale". Well yes, being Portuguese it was strictly speaking
invalid for my locale, but when you have packages which contain a range
of supported languages, simply throwing errors for filenames which
belong to a different locale isn't really the right thing to do.

--
I don't know what the language of the year 2000 will look like, but I
know it will be called Fortran. -- Tony Hoare 1982

[Stephen Hoffman]

ps/btw/fwiw: for those pondering the available implementations and the
compatibility of web browsers and of web servers, there are some HTTP
changes underway, with HTTP/2:

http://chimera.labs.oreilly.com/books/1230000000545/ch12.html

[David Froble]

Stephen Hoffman wrote:
> On 2015-06-06 16:02:11 +0000, David Froble said:
>
>> So, what are we saying? That there can be such a thing as "too good"?
>
> Yes, there is such a thing. Over-designing some product is
> comparatively easy. If you miss your target market, you're in deep
> trouble.

But I don't think that that was the issue or question. The question
was, can you hit your target market so well that there are little to no
problems, and your support people don't get much experience in solving
the non-existent problems.

Such a solution is not over designed, it is very well designed.

For such a solution to be considered "bad" because it is well designed
is distasteful to me, and things go much further downhill from there.

Should we design out nuclear power stations so that they periodically
throw out some radioactive gases, so we can keep the hazmet people on
their toes? That's in my opinion rather similar to tossing rocks at
Jan-Erik's VMS based solution(s) that don't have problems.

> If you're building a barn, then you'll find using trees are expensive
> and heavy, you need a number of large trees, and constructing a classic
> post-and-beam requires effort, skill and (lately) a ginormous CNC mill.
> Using an engineered solution such as truss involves more complex pieces,
> and trusses are prone to sudden failures in extreme conditions, but
> trusses are cheaper, and you can use more of what might have been a
> brace or just scrap wood within a post-and-beam structure. There are
> yet more expensive and better solutions than using a post-and-beam
> design, too. There's a market for post-and-beam barns, but it's not
> nearly as big as that of the pole barn, or of the ordinary commercial
> prefab construction that you can see getting delivered to building sites
> by the truckload. But I digress.

Yes, you do, and I'll digress some more.

I happen to have one of those post and beam barns. I think replicating
it would be very expensive, and for anything it could be used for,
rather stupid. It has those 12-14 inch square oak beams. I'd really
hate to pay for one of those today, let along the dozens in the barn.

As for failures, one of the joints is pulling apart. But that barn will
most likely out-live me, even if the problem is not addressed. The
building is unbelievable. I do plan on pulling it back together one of
these days. That's going to be fun.

If I was smart, I'd disassemble the barn and find buyers for all the
lumber. With the proceeds I could probably put up several truss based
buildings. But the old barn does have "character".

> Getting back to software, a well-run, existing production application
> installation usually tries to get to at least a local minima of whatever
> they're optimizing for (usually cost and effort, increasingly based on
> data collection and analysis), and a major upgrade or a replacement
> installation often looks at getting into whatever the current global
> minima might be.
>
> Yes, there are vendors which target better-grade products — not usually
> "too good" — and there can be profits here for the best of those
> vendors. But it's a whole lot of work and a whole lot of investment to
> ensure that you're meeting and variously exceeding the expectations of
> your customers. Spend too much getting to "perfect", and you'll likely
> lose your customers, too. Tradeoffs.

Sometimes it's not cost that is involved, it is good design. Many times
it doesn't cost more to do the job "right", and sometimes it cost less.

[Dirk Munk]

Very, very true indeed. In fact most of the time it is a matter of
knowledge and experience. Once you have learned the trick so to speak,
you only have to repeat it. It's all about insight, understanding, not
about hours and hours of experimenting and testing every time.

Every hour you spend on doing things the right way, repays itself
10-fold later on.

[Dirk Munk]

Stephen Hoffman wrote:
>
> ps/btw/fwiw: for those pondering the available implementations and the
> compatibility of web browsers and of web servers, there are some HTTP
> changes underway, with HTTP/2:
>
> http://chimera.labs.oreilly.com/books/1230000000545/ch12.html
>

Thanks for pointing us at that page. I had been reading about this a few
weeks ago, and this is a big improvement indeed. I had been thinking
about something like that for years, in very vague terms that is. It
always appeared to me how very inefficient HTTP is in transmitting a web
page. For every item on the page a new connection is made, a waste of
resources, and very time consuming. I always wondered if it wouldn't
been possible to zip the whole page at the server and send it in one
stream. It seems the push mechanism og HTTP/2 is doing something
similar, inspecting the page for links to other objects, and including
those objects in the stream before the client asks for them.

[johnwa...@yahoo.co.uk]

Hmmm, looking briefly at the book, I can't help wondering if
this is a more formalised, more structured, and probably somewhat
extended, version of what Opera Mini (Mobile?) have been doing
for years. As have other caching/compressing web proxies?

If I were sufficiently interested I'd also want to understand how
http/2 works where the transfers are intended to be secure (https?).
Encrypted stuff tends to be difficult to interpret (e.g. can't
see links) and to compress, by anything other than the original
server(s)?

Not that Google and friends would be interested in being able to
access anyone's encrypted webstuff as easily as they can the rest.

Want faster loading of web pages? Consider using an ad blocker,
script blocker, Flash blocker, etc. Or use Lynx :)

[johnwa...@yahoo.co.uk]

> > Yes, there are vendors which target better-grade products -- not usually
> > "too good" -- and there can be profits here for the best of those

> > vendors. But it's a whole lot of work and a whole lot of investment to
> > ensure that you're meeting and variously exceeding the expectations of
> > your customers. Spend too much getting to "perfect", and you'll likely
> > lose your customers, too. Tradeoffs.
>
> Sometimes it's not cost that is involved, it is good design. Many times
> it doesn't cost more to do the job "right", and sometimes it cost less.

Beautifully put.

Over here, the bit about "doing it right" vs "doing it shiny" is
exemplified by London's Millenium Bridge. Very shiny on paper (or
modern equivalent), functional disaster in the real world, slightly
embarrassing for a country that used to have a world leading bridge
design industry, cost a small fortune to fix. But shiny.

If people regularly designed bridges the way that people regularly
design complex computer systems...

[Jan-Erik Soderholm]

But the server would check for additional data *before* the
encryption layer takes over, I guess.

I do not know what the "original server" is. There is usualy
only one "server" processing the browser request.

Another issue is that in many cases, in particularly at larger
complex sites like eBay or similar, there are different root
URL's for application script and other data such as icons,
images or other data to be displayed.

And then the user can have disabled download of some types
of content, and the server can harldy know about that.

And finaly, the browser can have most of the additional
contents cached, so no extra network transfer will be
done at all anyway.

I'm not convinces that *that* part of HTTP/2 will be a major
benefit.

The two major points are, IMHO, compression and keeping a
single TCPIP connection between the client and server.

[Simon Clubley]

On 2015-06-07, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>
> I do not know what the "original server" is. There is usualy
> only one "server" processing the browser request.
>

Think about proxy servers which may be between you and the original
server.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Jan-Erik Soderholm]

Here is another page that clears up some points:

http://www.infoworld.com/article/2886381/internet/seven-no-bull-facts-about-the-new-http-2-protocol.html

And here is what the WASD maintainer says about it:

> HTTP/2
>
> https://en.m.wikipedia.org/wiki/HTTP/2
>
> has recently moved from draft to published IETF RFC 7540
>
> https://tools.ietf.org/html/rfc7540
>
> Not without its critics, it does look like becoming the next
> instantiation ofthe Web protocol" and so deserves attention.
>
> A WASD implementation actively is being pursued (though at a very early
> stage) and if runs to completion would constitute WASD v11. However the
> protocol and associated header compression RFC are non-trivial and the
> developmental timeline probably puts any release somewhere in late
> 2016.I looked at its progenitor development, SPDY, a couple of years
> ago but understandably was unprepared to put in the effort on an
> "experiment". Whether or not the average WASD site will benefit from
> HTTP/2 is moot as it doesn't fundamentally change the underlying
> semantics of HTTP/1.1 (it could be thought of as "wrapper" of sorts) and
> is targeted at reducing perceived networking bottlenecks in the
> client-server relationship.
>
> Cheers...

[li...@openmailbox.org]

On Sun, 7 Jun 2015 01:59:14 -0700 (PDT)
johnwallace4--- via Info-vax <info...@rbnsn.com> wrote:

> Over here, the bit about "doing it right" vs "doing it shiny" is
> exemplified by London's Millenium Bridge. Very shiny on paper (or
> modern equivalent), functional disaster in the real world, slightly
> embarrassing for a country that used to have a world leading bridge
> design industry, cost a small fortune to fix. But shiny.

An alternative and perhaps better (albeit more expensive) approach:

https://en.wikipedia.org/wiki/Forth_Bridge

--
Please DO NOT COPY ME on mailing list replies. I read the mailing list.
RSA 4096 fingerprint 7940 3F02 16D3 AFEE F2F8 ACAA 557C 4B36 98E4 4D49

[Dirk Munk]

johnwa...@yahoo.co.uk wrote:

>>
>> Sometimes it's not cost that is involved, it is good design. Many times
>> it doesn't cost more to do the job "right", and sometimes it cost less.
>
> Beautifully put.
>
> Over here, the bit about "doing it right" vs "doing it shiny" is
> exemplified by London's Millenium Bridge. Very shiny on paper (or
> modern equivalent), functional disaster in the real world, slightly
> embarrassing for a country that used to have a world leading bridge
> design industry, cost a small fortune to fix. But shiny.
>

Well, to be fair to the designers, the movement of the bridge isn't that
unique. We had a similar problem in the Netherlands with the Erasmus
bridge in Rotterdam (it was also stopped by mounting dampers). I
recently saw a video clip of a Russian bridge galloping wildly in the wind.

And we've all seen the famous film of the collapse of "Galloping Gertie"
haven't we?

[johnwa...@yahoo.co.uk]

Yes but :)

Making a mistake once is, in general, forgivable, though sometimes it
may indicate that the development and test process needs improvement.

If it's a mistake that's been seen before and is well known, there's
less of an excuse.

Fortunately the people in the IT world never repeat a mistake
that's well known and documented.

[Dirk Munk]

Thanks Jan-Eri, I found that quote on the WASD mail list.

I downloaded all the pdf manuals of WASD, 530 pages of excellent VMS
style manuals. That in itself shows the quality of the product.

It convinces me even more that WASD should be in the VMS distribution kit.

[Bill Gunshannon]

In article <mkt1s9$i52$1...@dont-email.me>,

David Froble <da...@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?

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

Funny, you used mixed case in the sentence above. The teletype is gone.
we actually have 52 lettters to choose from now just like every natural
language I am aware of. Well, except maybe for ASL. :-) Is VMS deaf
as well?

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Bill Gunshannon]

In article <mktg9v$6jo$1...@dont-email.me>,

David Froble <da...@tsoft-inc.com> writes:
> terry+go...@tmk.com wrote:
>> On Friday, June 5, 2015 at 4:48:21 PM UTC-4, David Froble wrote:

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

>> Neither of which is particularly relevant to the business community.
>> They have business problems*, not VMS or Unix problems. Most will
>> want to solve their business problems for the smallest cost that
>> accomplishes their goals of features / performance / security
>> (probably in that priority). In many cases, that involves hiring or
>> utilizing existing staff who are familiar with the tools used to
>> solve that business problem. VMS is going to be difficult enough to
>> sell to new customers (remember, on x86 it is competing with
>> "free"**) without also telling those customers that they will need to
>> find people with an obscure talent to not only manage the operating
>> system, but the applications that support the business, instead of
>> getting some of the widely available sysadmins / developers familiar
>> with Unix-type systems.
>
> If this is the case, then why are people still using VMS?

Beleive it or not, that is a question I often hear asked. :-)
The only stranger one is why is anyone still running Primos. (and they are)

>
> Aging personal, which usually means more expensive to hire ..
>
> Smaller pool of knowledgeable people ..
>

> More solutions available ..
>
> And so on ..
>
> So, why then is anyone still using VMS?

See above. Be careful what questions you ask. People with the power
to make decisions might be listening.

>
> Maybe what you suggest isn't accurate, or, maybe there is something
> else. Got to be something, because there are still people using VMS,
> and I doubt VSI could have raised one cent if they didn't know who these
> people are, and could count on their continued usage of VMS.
>
> I doubt it's a holdover thing. It's been over 15 years since DEC
> started pushing Unix and weendoze. Anybody that could use the Unix or
> weendoze systems is most likely long gone. Why is anyone left?
>
> Perhaps there are VMS problems that customers can use VMS to solve in
> the most effective manner?

Name one.

>
>> * This is a particular point with me because as a fresh-out-of-school
>> kid I interviewed with Data General for a software development
>> position and completely flunked the "why are we here" part of the
>> interview. It isn't to sell computers, or have the best product - it
>> is to provide something that lets customers solve their problems in a
>> more effective manner than if they bought from the competition. All
>> else follows on from that.
>>
>> ** And who might buy software and support from VSI, but who might not
>> want HP hardware for any one of a number of reasons. There's a famous
>> quote from a school (not mine) from when DEC cancelled the Jupiter
>> project: "We're switching to Unix because then we will have a huge
>> choice of vendors to screw us."

[Bill Gunshannon]

In article <5b4d3$5572eb23$5ed4324a$44...@news.ziggo.nl>,

Dirk Munk <mu...@home.nl> writes:
>
>
> I applied for a VMS job several months ago. During the job interview I
> was asked about my knowledge on all kind of other things, but not on
> VMS. I wasn't an expert on those areas, so they said that would be a
> problem. When I replied that they were asking for a VMS expert, they
> never mentioned those other areas of expertise. Well, that was true, but
> the VMS system had the habit of doing what it was suppose to do, and it
> had been doing that for years. It never needed any human assistance or
> intervention. In fact I would have almost nothing to do if my only work
> would be maintaining the VMS system.

Not surprising. A few years ago (the first time I retired from the
University :-) I applied for a job as a COBOL programmer for the Navy
down in GA. Same thing. After the interview when they asked if I had
any questions I said the same thing. "This is supposed to be a COBOL
Programmer job but you asked no questions about COBOL." They just kinda
shrugged it off with a comment of, "I guess you're right." About four
months into the jb they started scheduling me to go to courses opn PL/SQL
and Crystal Reports and other non-COBOL stuff. And when I asked about it
the answer was, "Oh, we're getting rid of the COBOL. We're going to re-
write it all in PL/SQL and Crystal Reports." Two months later I left.
So, did you take the job? :-)

>
> To be fair, other systems can be made to run very reliable as well, but
> quite often systems are set up to run, not to run reliable. The drive to
> build reliable systems often just isn't there.

The only place I hear that is here. My VMS system (more than a decade ago)
was more reliable than the one's run by the University data center. My
Unix and Windows servers today are v ery reliable. Moreso than the affore-
mentioned University data center VMS systems.

[Jan-Erik Soderholm]

>>> not that the *ports* are different — Apache ports are always different —

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.

[Bill Gunshannon]

In article <mkv59v$jue$1...@dont-email.me>,

And the moral of the story:
If you run something obscure you can be blackmailed by poor employees
but if you run what is the Industry Standard they can't get away with
it.

How exactly does your story provide a recommendation for going with VMS?

[Dirk Munk]

Without naming one, there are quite a number of applications that people
have tried to port to another O.S., and they didn't succeed.

Ans as others have pointed out frequently, VMS is capable of handling
big loads and many users withe ease

[Dirk Munk]

Jan-Erik Soderholm wrote:

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

Depends on your needs and wishes. I still remember the competition where
hackers were invited to hack a VMS system, and they didn't succeed.

VMS web servers are unknown, and that in itself is a safety advantage.

If I had to set up a web server that handles sensitive information, and
I know people who can do it on VMS, even if the database behind it is on
another o.s., with my knowledge of these aspects of VMS, I certainly
would consider using VMS.

[Stephen Hoffman]

On 2015-06-08 13:41:21 +0000, Jan-Erik Soderholm said:

> Bill Gunshannon skrev den 2015-06-08 15:20:
>> In article <mkt1s9$i52$1...@dont-email.me>,
>> David Froble <da...@tsoft-inc.com> writes:
>>
>> 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.

It's not even that clear-cut. Even if the source data is already on
OpenVMS, it may well be beneficial to have the web server(s) running on
separate box(es), whether that is for software availability or load
sharing or caching or DDoS or network security partitioning or
otherwise.

>
>> Funny, you used mixed case in the sentence above. The teletype is
>> gone. we actually have 52 lettters...
>
> 58.
> abcdefghijklmnopqrstuvwxyzåäö
> ABCDEFGHIJKLMNOPQRSTUVWXYZÅÄÖ

52? David is being somewhat parochial.

Add Spanish with 27 letters (ñ) and the acutes (é, ó, etc), French
orthography, German, and add those to a host of other languages, and
pretty soon you've got Unicode.

Much like the too-short username fields tend to annoy Mr. Schenkenberg,
if your code isn't dealing with these characters in your user
interfaces, then you can be puzzling or even irritating a subset of
your customers. Even for US-only products in the US, Spanish is
increasingly commonly used. Having at least some of your content
localized into Spanish can help your users.

[Bill Gunshannon]

In article <4f422b94-1faa-40ce...@googlegroups.com>,

They would fall down.

[Dirk Munk]

bi...@server3.cs.scranton.edu (Bill Gunshannon) wrote:
> In article <5b4d3$5572eb23$5ed4324a$44...@news.ziggo.nl>,
> Dirk Munk <mu...@home.nl> writes:
>>
>>
>> I applied for a VMS job several months ago. During the job interview I
>> was asked about my knowledge on all kind of other things, but not on
>> VMS. I wasn't an expert on those areas, so they said that would be a
>> problem. When I replied that they were asking for a VMS expert, they
>> never mentioned those other areas of expertise. Well, that was true, but
>> the VMS system had the habit of doing what it was suppose to do, and it
>> had been doing that for years. It never needed any human assistance or
>> intervention. In fact I would have almost nothing to do if my only work
>> would be maintaining the VMS system.
>
> Not surprising. A few years ago (the first time I retired from the
> University :-) I applied for a job as a COBOL programmer for the Navy
> down in GA. Same thing. After the interview when they asked if I had
> any questions I said the same thing. "This is supposed to be a COBOL
> Programmer job but you asked no questions about COBOL." They just kinda
> shrugged it off with a comment of, "I guess you're right." About four
> months into the jb they started scheduling me to go to courses opn PL/SQL
> and Crystal Reports and other non-COBOL stuff. And when I asked about it
> the answer was, "Oh, we're getting rid of the COBOL. We're going to re-
> write it all in PL/SQL and Crystal Reports." Two months later I left.
> So, did you take the job? :-)

No, I was over-experienced, I had to much knowledge they told me.

>
>>
>> To be fair, other systems can be made to run very reliable as well, but
>> quite often systems are set up to run, not to run reliable. The drive to
>> build reliable systems often just isn't there.
>
> The only place I hear that is here. My VMS system (more than a decade ago)
> was more reliable than the one's run by the University data center. My
> Unix and Windows servers today are v ery reliable. Moreso than the affore-
> mentioned University data center VMS systems.
>

Let me give you an example. I once was confronted with a cluster of
three Alpha 8400 systems. Big boys for the time, they had 4GB of memory
each, and that was a lot in those days. The whole configuration must
have cost millions. There was group of 10 people running the
application, solving problems, talking with the customers etc.

They had performance problems with this cluster, I did some basic checks
and found that the disk cache was still at the default 3MB. They had
important batch runs that were limited to 2.5MB memory usage. When I
asked them why on earth they had these ridiculous settings, they didn't
know.

We moved that application to a much smaller cluster of two ES40's, fixed
all kind of small problems and stupid settings, and then these 10 people
could be relocated to other work.

Or that wonderful story of a Solaris server. I walked into a room, and
saw they were monitoring a system. I asked if there was a problem. Yes
there was a problem, the performance. They didn't know what to do to
improve it. They had meetings with the supplier, and the supplier didn't
know either what to do. So I watched the screen, and saw that only 4GB
of the 8GB of memory was in use. So I asked about the size of the
database cache. 350MB they told me. I cursed, and told them to increase
it to 3GB. Problem solved.

I can go on and on with these stories. People setting up raid 1 sets on
two partitions of the same disk drive is also a nice one.

Quite often staff doesn't have a clue about how to properly set up a
system or a database.

[Bill Gunshannon]

In article <10801f5d-10d6-4751...@googlegroups.com>,

Where's the smiley? I certainly missed it. Oh, you don't read The
Risk's Digest. The one thing we have learned from this periodical
is that nothing has been learned.

[Dirk Munk]

Stephen Hoffman wrote:
> On 2015-06-08 13:41:21 +0000, Jan-Erik Soderholm said:
>
>> Bill Gunshannon skrev den 2015-06-08 15:20:
>>> In article <mkt1s9$i52$1...@dont-email.me>,
>>> David Froble <da...@tsoft-inc.com> writes:
>>>
>>> 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.
>
> It's not even that clear-cut. Even if the source data is already on
> OpenVMS, it may well be beneficial to have the web server(s) running on
> separate box(es), whether that is for software availability or load
> sharing or caching or DDoS or network security partitioning or otherwise.

Sure, using DECnet between systems could also be a proper show stopper
for a hacker :-)

[Stephen Hoffman]

On 2015-06-08 14:30:53 +0000, Dirk Munk said:

> Sure, using DECnet between systems could also be a proper show stopper
> for a hacker :-)

Sure. Or a good way to pick off usernames and passwords in cleartext.

[Dirk Munk]

Stephen Hoffman wrote:
> On 2015-06-08 14:30:53 +0000, Dirk Munk said:
>
>> Sure, using DECnet between systems could also be a proper show stopper
>> for a hacker :-)
>
> Sure. Or a good way to pick off usernames and passwords in cleartext.
>
>

But then he would have to scan an internal network connection, not that
easy. And of course you can use proxies. For that he has to log in, not
so asy without a password (or a username), and he would have to know the
proxy concept.

[Dirk Munk]

Sorry, the right comment at the wrong place :-)

[Bill Gunshannon]

In article <c5ba6$55759ca4$5ed4324a$33...@news.ziggo.nl>,

The question wasn't about a specific application, it was about a business
problem. Believe it or not, there is nothing unique about the capabilities
of the OS VMS.

>
> Ans as others have pointed out frequently, VMS is capable of handling
> big loads and many users withe ease

And you somehow think nothing else can? OPne of the biggest IT Systems in
the world is the US IRS. It is not running on VMS (OK, it is also not
running on Windows or Unix. :-)

>
>>
>>>
>>>> * This is a particular point with me because as a fresh-out-of-school
>>>> kid I interviewed with Data General for a software development
>>>> position and completely flunked the "why are we here" part of the
>>>> interview. It isn't to sell computers, or have the best product - it
>>>> is to provide something that lets customers solve their problems in a
>>>> more effective manner than if they bought from the competition. All
>>>> else follows on from that.
>>>>
>>>> ** And who might buy software and support from VSI, but who might not
>>>> want HP hardware for any one of a number of reasons. There's a famous
>>>> quote from a school (not mine) from when DEC cancelled the Jupiter
>>>> project: "We're switching to Unix because then we will have a huge
>>>> choice of vendors to screw us."

bill

[Bill Gunshannon]

In article <ml47on$p8t$1...@dont-email.me>,

Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
> On 2015-06-08 13:41:21 +0000, Jan-Erik Soderholm said:
>
>> Bill Gunshannon skrev den 2015-06-08 15:20:
>>> In article <mkt1s9$i52$1...@dont-email.me>,
>>> David Froble <da...@tsoft-inc.com> writes:
>>>
>>> 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.
>
> It's not even that clear-cut. Even if the source data is already on
> OpenVMS, it may well be beneficial to have the web server(s) running on
> separate box(es), whether that is for software availability or load
> sharing or caching or DDoS or network security partitioning or
> otherwise.

Exactly. I would never run a webserver on a machine that was intended
to do the data processing for the business.

>
>>
>>> Funny, you used mixed case in the sentence above. The teletype is
>>> gone. we actually have 52 lettters...
>>
>> 58.
>> abcdefghijklmnopqrstuvwxyzåäö
>> ABCDEFGHIJKLMNOPQRSTUVWXYZÅÄÖ
>
> 52? David is being somewhat parochial.

Not David this time, bill. :-)

>
> Add Spanish with 27 letters (ñ) and the acutes (é, ó, etc), French
> orthography, German, and add those to a host of other languages, and
> pretty soon you've got Unicode.

I was, of course, merely refering to ASCII which has 26 upper and lowercase
letters.

>
> Much like the too-short username fields tend to annoy Mr. Schenkenberg,
> if your code isn't dealing with these characters in your user
> interfaces, then you can be puzzling or even irritating a subset of
> your customers. Even for US-only products in the US, Spanish is
> increasingly commonly used. Having at least some of your content
> localized into Spanish can help your users.

[li...@openmailbox.org]

On Mon, 08 Jun 2015 15:59:43 +0200
Dirk Munk via Info-vax <info...@rbnsn.com> wrote:

> Jan-Erik Soderholm wrote:
>
> >>
> >> 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...
>
> Depends on your needs and wishes. I still remember the competition where
> hackers were invited to hack a VMS system, and they didn't succeed.
>
> VMS web servers are unknown, and that in itself is a safety advantage.

It is an unknown on VAX, Alpha, and Itanium. As soon as VMS runs on Intel
and uses an Apache port it's essentially no longer VMS.

Running on a less common architecture is in itself a fairly effective means
of security by obscurity. But since most of the attacks now focus on open
source vulnerabilities and AlL YoUR OS bELoNg 2US with everybody running
parts of a small subset of crapware (Apache/PHP/MYSQL/BrokenSSL) on the
same crapware hardware platform, using VMS as a webserver in the future is
probably not going to add any value except as you say if you have the data
there already (and don't care about it that much.)

Most exploits start out in C code that has buffer overruns or does other
stupid programming tricks. A lot of (most?) exploits are in web-facing
stuff like PHP, bash CGI scripts, and various SQL servers. It remains to be
seen how far you could get on VMS with all that junk ported to VMS running
on Intel but even if you could only get as far as the database you could
still do a lot of damage without having any VMS-specific exploit code at
all.

[Jan-Erik Soderholm]

Bill Gunshannon skrev den 2015-06-08 17:29:
> In article <ml47on$p8t$1...@dont-email.me>,
> Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>> On 2015-06-08 13:41:21 +0000, Jan-Erik Soderholm said:
>>
>>> Bill Gunshannon skrev den 2015-06-08 15:20:
>>>> In article <mkt1s9$i52$1...@dont-email.me>,
>>>> David Froble <da...@tsoft-inc.com> writes:
>>>>
>>>> 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.
>>
>> It's not even that clear-cut. Even if the source data is already on
>> OpenVMS, it may well be beneficial to have the web server(s) running on
>> separate box(es), whether that is for software availability or load
>> sharing or caching or DDoS or network security partitioning or
>> otherwise.
>
> Exactly. I would never run a webserver on a machine that was intended
> to do the data processing for the business.

Just silly. Of course. Speaks more about the "other" platforms that
you might have experience from then anything else. Saying "never"
is wrong in a case like this where the right answer is "it depends".

>
>>
>>>
>>>> Funny, you used mixed case in the sentence above. The teletype is
>>>> gone. we actually have 52 lettters...
>>>
>>> 58.
>>> abcdefghijklmnopqrstuvwxyzåäö
>>> ABCDEFGHIJKLMNOPQRSTUVWXYZÅÄÖ
>>
>> 52? David is being somewhat parochial.
>
> Not David this time, bill. :-)
>
>>
>> Add Spanish with 27 letters (ñ) and the acutes (é, ó, etc), French
>> orthography, German, and add those to a host of other languages, and
>> pretty soon you've got Unicode.
>
> I was, of course, merely refering to ASCII which has 26 upper and lowercase
> letters.

ASCII close to as outdated as the Teletype.
The "A" says it all. Make it WWSCII instead... :-)

[David Froble]

It had nothing at all to do with VMS, other than the part about the app
I provided, originally on RSTS and then on VMS. The story was about one
of the sorry practices I've seen. And about poor management and judgment.

Now, the business was rather custom, and they were constantly looking
for an "industry standard" application, but Word and Excel wasn't going
to run the company.

[David Froble]

Dirk Munk wrote:

> I can go on and on with these stories. People setting up raid 1 sets on
> two partitions of the same disk drive is also a nice one.

BAHAHAHAHAHAHAHA ...

ROTFLMAO


It's things like this that show that you don't want that high school
sophmore as your consultant ....

:-)

[David Froble]

Bill Gunshannon wrote:
> In article <mktg9v$6jo$1...@dont-email.me>,
> David Froble <da...@tsoft-inc.com> writes:

>> Perhaps there are VMS problems that customers can use VMS to solve in
>> the most effective manner?
>
> Name one.

What does my being able to name one have to do with reality. I
certainly don't have every problem in the world.

Are you implying that VMS is never the best solution?

But Ok, you tossed down the gauntlet, and I can provide one sure answer.

Running VAX/DEC/HP Basic applications. Not only is VMS the best
solution, it is the only solution.

I'm sure you'll come back with one of your smart-ass replys, but, you
issued the challenge, not me, and I've successfully met it.

:-)

[johnwa...@yahoo.co.uk]

Same class of people as don't understand the difference between RAID and backups. There's a surprising amount of it about.

[David Froble]

In English, DAVID FROBLE = david froble = David Froble

As for case sensitive computer stuff, DAVID FROBLE <> david froble <>
David Froble

Now, if you're used to the first example, the second example can mess
with your mind.

If the second example was in use in say shipping, there would be a lot
of letters and packages that never get delivered.


What is a "lettters" ?

[David Froble]

Stephen Hoffman wrote:
> On 2015-06-08 13:41:21 +0000, Jan-Erik Soderholm said:
>
>> Bill Gunshannon skrev den 2015-06-08 15:20:
>>> In article <mkt1s9$i52$1...@dont-email.me>,
>>> David Froble <da...@tsoft-inc.com> writes:
>>>
>>> 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.
>
> It's not even that clear-cut. Even if the source data is already on
> OpenVMS, it may well be beneficial to have the web server(s) running on
> separate box(es), whether that is for software availability or load
> sharing or caching or DDoS or network security partitioning or otherwise.
>
>>
>>> Funny, you used mixed case in the sentence above. The teletype is
>>> gone. we actually have 52 lettters...
>>
>> 58.
>> abcdefghijklmnopqrstuvwxyzåäö
>> ABCDEFGHIJKLMNOPQRSTUVWXYZÅÄÖ
>
> 52? David is being somewhat parochial.

Not guilty! That was Bill. Hang him, not me.

[David Froble]

Bill Gunshannon wrote:

> Exactly. I would never run a webserver on a machine that was intended
> to do the data processing for the business.

It would depend, but I'd usually agree with this.