Discussion:
OpenSSL CSWS-2.2-1
(too old to reply)
Neil Rieck
2019-03-14 16:36:33 UTC
Permalink
Everyone reading this already knows that HP (now HPE) used to provide free updates for CSWS (a.k.a. Apache for OpenVMS) modules including SSL, Java, PHP, etc. All of those web pages have been redirected to the common OpenVMS landing page so I guess we can assume that those days are over.

However, life goes on and I just learned that all major browsers are going to disable TLS-1.0 and TLS-1.1 sometime in 2020. Here are a few links which shine more light on the announcement.

https://www.zdnet.com/article/chrome-edge-ie-firefox-and-safari-to-disable-tls-1-0-and-tls-1-1-in-2020/

https://www.cso.com.au/article/648261/tls-1-0-1-1-will-disabled-edge-ie-chrome-firefox-safari-2020/

https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

Now 2020 seems a long way off but web developers at my employer's company are already seeing TLS-1.0 and TLS-1.1 warnings in the AJAX transport associated with "Developer Tools" in Chrome v73 so I suggest that anyone with an OpenVMS support contract at HPE contact them for support (previously they just send out a new version of file "mod_ssl.exe"). I just filed a support request with them this morning.

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net




 
Jan-Erik Söderholm
2019-03-14 17:25:41 UTC
Permalink
Post by Neil Rieck
Everyone reading this already knows that HP (now HPE) used to provide
free updates for CSWS (a.k.a. Apache for OpenVMS) modules including SSL,
Java, PHP, etc. All of those web pages have been redirected to the
common OpenVMS landing page so I guess we can assume that those days are
over.
However, life goes on and I just learned that all major browsers are
going to disable TLS-1.0 and TLS-1.1 sometime in 2020. Here are a few
links which shine more light on the announcement.
https://www.zdnet.com/article/chrome-edge-ie-firefox-and-safari-to-disable-tls-1-0-and-tls-1-1-in-2020/
https://www.cso.com.au/article/648261/tls-1-0-1-1-will-disabled-edge-ie-chrome-firefox-safari-2020/
https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls
Now 2020 seems a long way off but web developers at my employer's
company are already seeing TLS-1.0 and TLS-1.1 warnings in the AJAX much
transport associated with "Developer Tools" in Chrome v73 so I suggest
that anyone with an OpenVMS support contract at HPE contact them for
support (previously they just send out a new version of file
"mod_ssl.exe"). I just filed a support request with them this morning.
Neil Rieck Waterloo, Ontario, Canada. http://neilrieck.net
Not that it helps CSWS much, but WASD got OpenSSL 1.1.1 (incl. TLS 1.3)
pre-support in May 2017 and the SSL 1.1.1 kit is from Nov 2018.

https://wasd.vsm.com.au/wasd_root/doc/misc/changes.html
https://wasd.vsm.com.au/wasd/
Dave Froble
2019-03-14 20:40:49 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Neil Rieck
Everyone reading this already knows that HP (now HPE) used to provide
free updates for CSWS (a.k.a. Apache for OpenVMS) modules including SSL,
Java, PHP, etc. All of those web pages have been redirected to the
common OpenVMS landing page so I guess we can assume that those days are
over.
However, life goes on and I just learned that all major browsers are
going to disable TLS-1.0 and TLS-1.1 sometime in 2020. Here are a few
links which shine more light on the announcement.
https://www.zdnet.com/article/chrome-edge-ie-firefox-and-safari-to-disable-tls-1-0-and-tls-1-1-in-2020/
https://www.cso.com.au/article/648261/tls-1-0-1-1-will-disabled-edge-ie-chrome-firefox-safari-2020/
https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls
Now 2020 seems a long way off but web developers at my employer's
company are already seeing TLS-1.0 and TLS-1.1 warnings in the AJAX much
transport associated with "Developer Tools" in Chrome v73 so I suggest
that anyone with an OpenVMS support contract at HPE contact them for
support (previously they just send out a new version of file
"mod_ssl.exe"). I just filed a support request with them this morning.
Neil Rieck Waterloo, Ontario, Canada. http://neilrieck.net
Not that it helps CSWS much, but WASD got OpenSSL 1.1.1 (incl. TLS 1.3)
pre-support in May 2017 and the SSL 1.1.1 kit is from Nov 2018.
https://wasd.vsm.com.au/wasd_root/doc/misc/changes.html
https://wasd.vsm.com.au/wasd/
Makes me wonder. How difficult is it to move existing stuff from Apache
to WASD?

Of course, then, there is the problem of employees who figure it's the
employer's job to keep their resumes up to date and looking good.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Neil Rieck
2019-03-14 20:59:25 UTC
Permalink
I just received a newer version of "mod_ssl.exe" for Itanium which does not get me to the goal line but is newer than the one I am currently using. Unfortunately, this one is built against OpenSSL-1.0.2L (same as the client-side kit of the same name). I noticed a newer client-side kit available from the patch site, It is based upon OpenSSL-1.0-2O (that's two oh; not twenty).

I am still discussing this with HPE so will get back here if/when we have more news.

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
Neil Rieck
2019-04-06 12:32:57 UTC
Permalink
Strictly as an emergency backup plan, I've been working on trial to replace CSWS-2.2-1 with WASD-11.

For example, if my ~1,200 clients begin to use new browsers next year, they might not be able to connect to my current system so I have got to do something now. But that got me thinking about another problem: we are receiving B2B SOAP transactions from a system in Montreal (another company) which currently relies on SSLv3. If I upgrade my web-server to something that doesn't offer SSLv3 (because it hasn't been compiled into Apache's mod_ssl, or I've linked WASD to an SSL library that is too restrictive) then I'm not going to be able to receive those B2B SOAP connections.

After a restless night of sleep it occurred to me that many other systems are also going to run into this situation but no one seems to be talking about it (at least not in the way they talked about Y2K). So I have decided to call this problem "Y2K20" and have placed some preliminary notes here:

http://neilrieck.net/docs/calendar_time_y2k_etc.html#y2k20

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
Steven Schweda
2019-04-06 13:30:32 UTC
Permalink
[...] I have decided to call this problem "Y2K20" [...]
Because "Y2020" would be so much less compact, and
wouldn't suggest "2200"?
Neil Rieck
2019-04-06 16:03:48 UTC
Permalink
Post by Steven Schweda
[...] I have decided to call this problem "Y2K20" [...]
Because "Y2020" would be so much less compact, and
wouldn't suggest "2200"?
:-)
Arne Vajhøj
2019-04-06 16:16:42 UTC
Permalink
Post by Neil Rieck
Strictly as an emergency backup plan, I've been working on trial to replace CSWS-2.2-1 with WASD-11.
For example, if my ~1,200 clients begin to use new browsers next year, they might not be able to connect to my current system so I have got to do something now. But that got me thinking about another problem: we are receiving B2B SOAP transactions from a system in Montreal (another company) which currently relies on SSLv3. If I upgrade my web-server to something that doesn't offer SSLv3 (because it hasn't been compiled into Apache's mod_ssl, or I've linked WASD to an SSL library that is too restrictive) then I'm not going to be able to receive those B2B SOAP connections.
http://neilrieck.net/docs/calendar_time_y2k_etc.html#y2k20
I don't know how general the problem is.

OpenSSL and Apache httpd are open source.

You can build OpenSSL with the protocols you want.

In Apache config you can enable and disable the protocols you want.

Arne
Arne Vajhøj
2019-04-06 16:19:02 UTC
Permalink
Post by Arne Vajhøj
Post by Neil Rieck
Strictly as an emergency backup plan, I've been working on trial to
replace CSWS-2.2-1 with WASD-11.
For example, if my ~1,200 clients begin to use new browsers next year,
they might not be able to connect to my current system so I have got
we are receiving B2B SOAP transactions from a system in Montreal
(another company) which currently relies on SSLv3. If I upgrade my
web-server to something that doesn't offer SSLv3 (because it hasn't
been compiled into Apache's mod_ssl, or I've linked WASD to an SSL
library that is too restrictive) then I'm not going to be able to
receive those B2B SOAP connections.
After a restless night of sleep it occurred to me that many other
systems are also going to run into this situation but no one seems to
be talking about it (at least not in the way they talked about Y2K).
So I have decided to call this problem "Y2K20" and have placed some
http://neilrieck.net/docs/calendar_time_y2k_etc.html#y2k20
I don't know how general the problem is.
OpenSSL and Apache httpd are open source.
You can build OpenSSL with the protocols you want.
In Apache config you can enable and disable the protocols you want.
Besides that then I would consider not serving static content and
web services from same server.

exposed web 1 serving static content
exposed web 2 web services

or

exposed web 1 serving static content and proxy to web 2
internal web 2 web services

or similar.

Arne
Arne Vajhøj
2019-04-06 16:20:30 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Neil Rieck
Strictly as an emergency backup plan, I've been working on trial to
replace CSWS-2.2-1 with WASD-11.
For example, if my ~1,200 clients begin to use new browsers next
year, they might not be able to connect to my current system so I
have got to do something now. But that got me thinking about another
problem: we are receiving B2B SOAP transactions from a system in
Montreal (another company) which currently relies on SSLv3. If I
upgrade my web-server to something that doesn't offer SSLv3 (because
it hasn't been compiled into Apache's mod_ssl, or I've linked WASD to
an SSL library that is too restrictive) then I'm not going to be able
to receive those B2B SOAP connections.
After a restless night of sleep it occurred to me that many other
systems are also going to run into this situation but no one seems to
be talking about it (at least not in the way they talked about Y2K).
So I have decided to call this problem "Y2K20" and have placed some
http://neilrieck.net/docs/calendar_time_y2k_etc.html#y2k20
I don't know how general the problem is.
OpenSSL and Apache httpd are open source.
You can build OpenSSL with the protocols you want.
In Apache config you can enable and disable the protocols you want.
Besides that then I would consider not serving static content and
web services from same server.
exposed web 1 serving static content
exposed web 2 web services
or
exposed web 1 serving static content and proxy to web 2
internal web 2 web services
or similar.
If your security people are strict they may insist on:

exposed web 0 proxy to web 1 and web 2
internal web 1 serving static content
internal web 2 web services

Arne
Stephen Hoffman
2019-04-06 17:24:01 UTC
Permalink
Post by Neil Rieck
Strictly as an emergency backup plan, I've been working on trial to
replace CSWS-2.2-1 with WASD-11.
The current OpenVMS CSWS version is based on Apache HTTP Server V2.4-38.

Apache HTTP Server 2.4-39 is current.

List of security issues identified in the 2.4 series, including in 2.4-38:
https://httpd.apache.org/security/vulnerabilities_24.html

Building a new version of Apache on OpenVMS is somewhat of a project,
though it's possible.

Updating OpenSSL TLS would usually be a smaller project within an
existing Apache port, so long as the software versions involved aren't
too skewed.

Per Apache, "Apache HTTP Server version 2.4.39 or newer is required in
order to operate a TLS 1.3 web server with OpenSSL 1.1.1."

Also per Apache, "Please note the 2.2.x branch has now passed the end
of life at the Apache HTTP Server project and no further activity will
occur including security patches."

"Y2K20"? Obfuscare, err, obfuscate much? Why not MMXX? 🤪
--
Pure Personal Opinion | HoffmanLabs LLC
t***@glaver.org
2019-04-06 22:54:13 UTC
Permalink
Post by Stephen Hoffman
The current OpenVMS CSWS version is based on Apache HTTP Server V2.4-38.
Is it really that up-to-date? I'd be amazed. A Google search for "OpenVMS CSWS" leads me to https://support.hpe.com/hpsc/doc/public/display?docId=a00058394en_us which says it is based on Apache 2.0.65, and took apparently nearly a year and a half (based on June 2013 release date from the Apache Foundation and an October 2014 date on the HP release notes).

This would seem to be the perfect candidate to be turned over to freeware developers. There will always be sites that insist on running only "vendor released" software, but an actual security audit that finds a site running such horribly out-of-date and known-insecure software will likely cause a re-think of that. Plus, there's no reason that a vendor couldn't receive and review updates from a freeware developer and examine them (the differences should be small if this is done for each release) and then produce a signed version if desired by their customers.

The three things I think HP got wrong (and Compaq and DEC before them) are:

1) Thinking that "port once and done" is a workable solution, and when they find out it isn't, making another "port once and done" effort. This is something that needs to continuously track the upstream branch.

2) Assigning (apparently) arbitrary version numbers instead of using the upstream version number (possibly with a suffix like "-VMS1", "-VMS2", etc. if multiple VMS releases against the same upstream version are needed (which shouldn't happen if the upstream releases are being tracked regularly).

3) Producing incompatible releases of various upstream packages that are supposed to work together. I've read many posts where people say that package A requires OpenSSL X, but package B requires OpenSSL Y which has a different API than OpenSSL X.

Back on the general topic of deprecated crypto libraries, some people may find my blog post "Is no crypto always better than bad crypto?" that I wrote over 3 years ago interesting: https://www.glaver.org/blog/?p=853
Craig A. Berry
2019-04-06 23:34:33 UTC
Permalink
Post by t***@glaver.org
Post by Stephen Hoffman
The current OpenVMS CSWS version is based on Apache HTTP Server V2.4-38.
Is it really that up-to-date?
It is, but only if you are a VSI support customer and know which secret
rock to look under and have the magic decoder ring that allows you to
see what's under the rock.
Robert A. Brooks
2019-04-07 00:17:43 UTC
Permalink
Post by t***@glaver.org
Post by Stephen Hoffman
The current OpenVMS CSWS version is based on Apache HTTP Server V2.4-38.
Is it really that up-to-date? I'd be amazed. A Google search for "OpenVMS
CSWS" leads me to
https://support.hpe.com/hpsc/doc/public/display?docId=a00058394en_us which
says it is based on Apache 2.0.65, and took apparently nearly a year and a
half (based on June 2013 release date from the Apache Foundation and an
October 2014 date on the HP release notes).
We (VSI) have a much more current version of Apache, although I'd be
hard-pressed to tell you what that is. I suspect the version that Steve
referred to is ours.
Post by t***@glaver.org
1) Thinking that "port once and done" is a workable solution, and when they
find out it isn't, making another "port once and done" effort. This is
something that needs to continuously track the upstream branch.
We are not going the DEC/CPQ/HP way. We've got a group of people
who are dedicated to open source work. The current big effort is with Samba.
I'm pretty sure that OpenSSL V1.1.1 is also underway.
Post by t***@glaver.org
2) Assigning (apparently) arbitrary version numbers instead of using the
upstream version number (possibly with a suffix like "-VMS1", "-VMS2", etc.
if multiple VMS releases against the same upstream version are needed (which
shouldn't happen if the upstream releases are being tracked regularly).
In general, I didn't think we are doing that, although the "-Q" above confuses
me. Then again, I know very little about our open source work.
Post by t***@glaver.org
3) Producing incompatible releases of various upstream packages that are
supposed to work together. I've read many posts where people say that package
A requires OpenSSL X, but package B requires OpenSSL Y which has a different
API than OpenSSL X.
I do know that we are pretty good at documenting requirements and restrictions,
and ensuring that they are accurate.
--
-- Rob
Dave Froble
2019-04-07 01:25:17 UTC
Permalink
Post by Robert A. Brooks
Post by t***@glaver.org
Post by Stephen Hoffman
The current OpenVMS CSWS version is based on Apache HTTP Server V2.4-38.
Is it really that up-to-date? I'd be amazed. A Google search for "OpenVMS
CSWS" leads me to
https://support.hpe.com/hpsc/doc/public/display?docId=a00058394en_us which
says it is based on Apache 2.0.65, and took apparently nearly a year and a
half (based on June 2013 release date from the Apache Foundation and an
October 2014 date on the HP release notes).
We (VSI) have a much more current version of Apache, although I'd be
hard-pressed to tell you what that is. I suspect the version that Steve
referred to is ours.
That was my impression.
Post by Robert A. Brooks
Post by t***@glaver.org
1) Thinking that "port once and done" is a workable solution, and when they
find out it isn't, making another "port once and done" effort. This is
something that needs to continuously track the upstream branch.
We are not going the DEC/CPQ/HP way. We've got a group of people
who are dedicated to open source work. The current big effort is with Samba.
I'm pretty sure that OpenSSL V1.1.1 is also underway.
I'm in the process of installing and learning a bit about Mark Daniel's
WASD web server. Included, and optional, is the (I believe) OpenSSL
V1.1.1. At least it is claimed to do TLS V1.3.

Now, I have no idea if it is a complete port of OpenSSL, or, just enough
for WASD. Might be worth checking out, and if Mark can provide VMS
users with a good port of OpenSSL, why not take advantage of that?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2019-04-07 01:58:38 UTC
Permalink
Post by Robert A. Brooks
Post by t***@glaver.org
Post by Stephen Hoffman
The current OpenVMS CSWS version is based on Apache HTTP Server V2.4-38.
Is it really that up-to-date? I'd be amazed.
Be amazed, then.
Post by Robert A. Brooks
Post by t***@glaver.org
A Google search for "OpenVMS CSWS" leads me to
https://support.hpe.com/hpsc/doc/public/display?docId=a00058394en_us
which says it is based on Apache 2.0.65, and took apparently nearly a
year and a half (based on June 2013 release date from the Apache
Foundation and an October 2014 date on the HP release notes).
HPE have less than two years' new-patch support announced, and they're
clearly working toward their long-announced exit from the OpenVMS
business.
Post by Robert A. Brooks
We (VSI) have a much more current version of Apache, although I'd be
hard-pressed to tell you what that is. I suspect the version that
Steve referred to is ours.
The referenced Apache version is from VSI.

Again, HPE is exiting the OpenVMS business.

If you're planning to stay with OpenVMS and want current versions and
support, you'll want to migrate your licenses and support and versions
to VSI.
Post by Robert A. Brooks
Post by t***@glaver.org
2) Assigning (apparently) arbitrary version numbers instead of using
the upstream version number (possibly with a suffix like "-VMS1",
"-VMS2", etc. if multiple VMS releases against the same upstream
version are needed (which shouldn't happen if the upstream releases are
being tracked regularly).
In general, I didn't think we are doing that, although the "-Q" above
confuses me. Then again, I know very little about our open source work.
Version-numbering has been confusing with vendor-provided ports for a
while, yes. VSI has been using the upstream open source version
numbers, to their credit.

VSI is unfortunately sticking with the absurd product names though, but
then acronyms and obfuscations are the OpenVMS way. We can't have
something cleverly called "webserver", after all. Much too obvious.
Requirements around the possession of arcane or obscure knowledge—like
what SWS or CSWS translates into—is part of the membership in the
OpenVMS club. Plain names and clear descriptions? Those are just not
permitted. So we have CSWS, which everybody obviously knows is a web
server.
Post by Robert A. Brooks
Post by t***@glaver.org
3) Producing incompatible releases of various upstream packages that
are supposed to work together. I've read many posts where people say
that package A requires OpenSSL X, but package B requires OpenSSL Y
which has a different API than OpenSSL X.
I do know that we are pretty good at documenting requirements and
restrictions, and ensuring that they are accurate.
This is a restriction of the upstream in the case of the OpenSSL APIs,
and the upstream OpenSSL releases are themselves not completely
compatible.

The then-HP SSL V1.3 to SSL V1.4 change—why that wasn't labeled a "2.0"
release?—required app rebuilds and potentially app source code changes.

To address that incompatibility when it next arose, then-HP tried to
make this stuff independent with the SSL1 kit in addition to the
existing SSL kit, but didn't quite complete the design.

VSI has moved to allow multiple installed versions in parallel with
their latest V8.4-2L1 and V8.4-2L2 releases, which will ease the
migrations.

We're headed for another OpenSSL update and likely later this year, as
the OpenSSL security patches are ending for the current series. We'll
see a version based on 1.1.1, and then 3.0.0 as that arrives.

OpenSSL 3.0.0 will be the first release with an Apache 2 license, too.

This particular mess is also why I've commented around the lack of an
API for OpenVMS that masks these differences and that makes creating a
secure network connection rather less of a project than is currently
involved. I've pointed to Secure Transport and similar approaches as
one of various examples from other platforms that have sought to reduce
or to isolate SSL-level differences from the application developers.

Alternatives to OpenSSL include NaCl and libtls, among others.

Then there's the discussion of why any of Apache and OpenSSL is
separate from the OpenVMS distribution, and not integrated. Having
worked with server platforms with integrated networking and network
services, the OpenVMS approach is just a hassle. When it works.

And there's the discussion about VSI marketing.
--
Pure Personal Opinion | HoffmanLabs LLC
Craig A. Berry
2019-04-07 02:59:52 UTC
Permalink
Post by Stephen Hoffman
So we have CSWS, which everybody obviously knows is a web
server.
Not just a web server, but a secure web server from a company named
Compaq that never knew anything about servers or security.
Post by Stephen Hoffman
This particular mess is also why I've commented around the lack of an
API for OpenVMS that masks these differences and that makes creating a
secure network connection rather less of a project than is currently
involved.  I've pointed to Secure Transport and similar approaches as
one of various examples from other platforms that have sought to reduce
or to isolate SSL-level differences from the application developers.
Alternatives to OpenSSL include NaCl and libtls, among others.
Some VMS-friendly wrapper functions might be nice. But as far as the
underlying crypto, it would be unwise for VSI to roll any of that on
their own.
Stephen Hoffman
2019-04-08 17:23:55 UTC
Permalink
Post by Craig A. Berry
So we have CSWS, which everybody obviously knows is a web server.
Not just a web server, but a secure web server from a company named
Compaq that never knew anything about servers or security.
CSWS, SWB, the oddly-named-and-why-are-these-even-separate Apache
language modules, T4, etc.
Terms such as LP and "host-based volume shadowing", for that matter.
LMF, PAKs, etc.
Process has similar issues with the lack of references to "firewall" in
their Multinet docs, IIRC.
There's "autogen", which by all appearances neither autos nor gens, and
with a name that is clear if you knew RSX-11. Why that even still
exists is another discussion.
This certainly isn't going to change for existing environments, but
OpenVMS folks are way too fond of OpenVMS-isms in naming, in
documentation, and in API designs.
Common terms are helpful, both to existing users and particularly to new users.
Post by Craig A. Berry
This particular mess is also why I've commented around the lack of an
API for OpenVMS that masks these differences and that makes creating a
secure network connection rather less of a project than is currently
involved.  I've pointed to Secure Transport and similar approaches as
one of various examples from other platforms that have sought to reduce
or to isolate SSL-level differences from the application developers.
Alternatives to OpenSSL include NaCl and libtls, among others.
Some VMS-friendly wrapper functions might be nice. But as far as the
underlying crypto, it would be unwise for VSI to roll any of that on
their own.
Wouldn't suggest home-grown cryptography. That often ends badly. As
for wrapping, that's what the Apple frameworks provide. Secure
Transport, the Network Framework, etc., wrap libtls, as well as dealing
with DNS and sockets and certificates.

https://developer.apple.com/security/

Do I expect VSI to crib Apple here? No. I reference this so that
folks can see what's been happening in the past decade or two; in the
era since the OpenVMS frameworks have been substantially updated.

And as I've commented elsewhere, go try writing a secure network
connection using DNS, and self-signed root certificate authority and
certificates and CSRs, and sockets. Now work through the failure modes
and the attacks, and "minor" details such as certificate renewals.
Apps with errors and vulnerabilities are probably the norm here, too.
Now make this work with IPv6.

Apple's been rolling all of this right into their networking framework,
past what Secure Transport provides. As have other folks, I'd expect.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2019-04-08 19:26:13 UTC
Permalink
Post by Stephen Hoffman
Post by Craig A. Berry
So we have CSWS, which everybody obviously knows is a web server.
Not just a web server, but a secure web server from a company named
Compaq that never knew anything about servers or security.
CSWS, SWB, the oddly-named-and-why-are-these-even-separate Apache
language modules, T4, etc.
Terms such as LP and "host-based volume shadowing", for that matter.
LMF, PAKs, etc.
Host based mirroring might be a bit more understood, but volume
shadowing sure isn't all that mysterious.

LMF and PAKs should just go away.

Usually when a "challenge" is issued, there will be those who pick up
the gauntlet. I figured at least two methods to get past the LMF. No,
I'm not saying. It wasn't to actually do so, just to answer the challenge.

Thing is, and it's been said before, LMF isn't to stop piracy. If
someone wants it, they will get it. Just ask Bill Gates about the
Chinese. So, all LMF does is harrass those who respect it. Get VMS in
front of as many as possible. Those who will purchase support will do
so. Those who won't don't. No real loss.
Post by Stephen Hoffman
Process has similar issues with the lack of references to "firewall" in
their Multinet docs, IIRC.
There's "autogen", which by all appearances neither autos nor gens, and
with a name that is clear if you knew RSX-11. Why that even still
exists is another discussion.
Yeah, I'd like to see some SYSGEN parameters just go away, or by default
be set so that needing to change them will be rare. I doubt we'll see
an x86 server with less than 16 GB of memory, and maybe much more.
Post by Stephen Hoffman
This certainly isn't going to change for existing environments, but
OpenVMS folks are way too fond of OpenVMS-isms in naming, in
documentation, and in API designs.
Common terms are helpful, both to existing users and particularly to new users.
Post by Craig A. Berry
This particular mess is also why I've commented around the lack of an
API for OpenVMS that masks these differences and that makes creating
a secure network connection rather less of a project than is
currently involved. I've pointed to Secure Transport and similar
approaches as one of various examples from other platforms that have
sought to reduce or to isolate SSL-level differences from the
application developers.
Please! And better documentation, and ease, for what is necessary.
Certificates are obscure, at least I think so, and they aren't any
better, that I'm aware of, on other platforms.
Post by Stephen Hoffman
Post by Craig A. Berry
Alternatives to OpenSSL include NaCl and libtls, among others.
Some VMS-friendly wrapper functions might be nice. But as far as the
underlying crypto, it would be unwise for VSI to roll any of that on
their own.
Wouldn't suggest home-grown cryptography. That often ends badly. As
for wrapping, that's what the Apple frameworks provide. Secure
Transport, the Network Framework, etc., wrap libtls, as well as dealing
with DNS and sockets and certificates.
https://developer.apple.com/security/
Do I expect VSI to crib Apple here? No. I reference this so that folks
can see what's been happening in the past decade or two; in the era
since the OpenVMS frameworks have been substantially updated.
And as I've commented elsewhere, go try writing a secure network
connection using DNS, and self-signed root certificate authority and
certificates and CSRs, and sockets. Now work through the failure modes
and the attacks, and "minor" details such as certificate renewals. Apps
with errors and vulnerabilities are probably the norm here, too. Now
make this work with IPv6.
Apple's been rolling all of this right into their networking framework,
past what Secure Transport provides. As have other folks, I'd expect.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2019-04-08 20:30:46 UTC
Permalink
Post by Dave Froble
Post by Stephen Hoffman
Post by Craig A. Berry
So we have CSWS, which everybody obviously knows is a web server.
Not just a web server, but a secure web server from a company named
Compaq that never knew anything about servers or security.
CSWS, SWB, the oddly-named-and-why-are-these-even-separate Apache
language modules, T4, etc.
Terms such as LP and "host-based volume shadowing", for that matter.
LMF, PAKs, etc.
Host based mirroring might be a bit more understood, but volume
shadowing sure isn't all that mysterious.
Once you know to look for it—once you're aware of the jargon—sure.
Host-based RAID-1 would be the typical jargon. And jargon can and does
change over time.
Post by Dave Froble
LMF and PAKs should just go away.
That's up to VSI.
Post by Dave Froble
Usually when a "challenge" is issued, there will be those who pick up
the gauntlet. I figured at least two methods to get past the LMF. No,
I'm not saying. It wasn't to actually do so, just to answer the challenge.
Thing is, and it's been said before, LMF isn't to stop piracy. If
someone wants it, they will get it. Just ask Bill Gates about the
Chinese. So, all LMF does is harrass those who respect it. Get VMS in
front of as many as possible. Those who will purchase support will do
so. Those who won't don't. No real loss.
I'm not discussing bypassing LMF. I'm discussing simplifying the
existing license management.

For many products, a licensee name and a checksum is enough. There's a
lot of baggage on OpenVMS left over from the era of each giblet being
separately licensed, not the least of which is the design of LMF itself.

As for changing the licensing and support and pricing scheme? That's
the lifeblood of VSI, and there'll be resistance to anything that might
negatively effect revenues.

And there are in-built sales and marketing assumptions carried over
from the DEC era.

LMF was designed to be able to implement most any scheme that the
pricing folks could conceive. It's bloody brilliant for that, too.
But LMF is an inward-facing design, and not a customer-facing one.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2019-04-08 22:30:36 UTC
Permalink
Post by Stephen Hoffman
Post by Dave Froble
Post by Stephen Hoffman
Post by Craig A. Berry
So we have CSWS, which everybody obviously knows is a web server.
Not just a web server, but a secure web server from a company named
Compaq that never knew anything about servers or security.
CSWS, SWB, the oddly-named-and-why-are-these-even-separate Apache
language modules, T4, etc.
Terms such as LP and "host-based volume shadowing", for that matter.
LMF, PAKs, etc.
Host based mirroring might be a bit more understood, but volume
shadowing sure isn't all that mysterious.
Once you know to look for it—once you're aware of the jargon—sure.
Host-based RAID-1 would be the typical jargon. And jargon can and does
change over time.
Ayep. That would be a good name.
Post by Stephen Hoffman
Post by Dave Froble
LMF and PAKs should just go away.
That's up to VSI.
Post by Dave Froble
Usually when a "challenge" is issued, there will be those who pick up
the gauntlet. I figured at least two methods to get past the LMF.
No, I'm not saying. It wasn't to actually do so, just to answer the
challenge.
Thing is, and it's been said before, LMF isn't to stop piracy. If
someone wants it, they will get it. Just ask Bill Gates about the
Chinese. So, all LMF does is harrass those who respect it. Get VMS
in front of as many as possible. Those who will purchase support will
do so. Those who won't don't. No real loss.
I'm not discussing bypassing LMF. I'm discussing simplifying the
existing license management.
For many products, a licensee name and a checksum is enough. There's a
lot of baggage on OpenVMS left over from the era of each giblet being
separately licensed, not the least of which is the design of LMF itself.
As for changing the licensing and support and pricing scheme? That's
the lifeblood of VSI, and there'll be resistance to anything that might
negatively effect revenues.
And there are in-built sales and marketing assumptions carried over from
the DEC era.
Yes, and look at how well that's worked lately.

VSI's future will be based upon support, and to be specific, shpport
from those customers glad to pay for it.

A while back some were bitching about the cost of Rdb. Jan-Erik chipped
in with the statement that the annual support fee was something like
minutes of production. From that perspective, any halt in production
would be VERY expensive. Thus, the willingness, or even gladness, to
pay for support.

The other side of the coin is, get VMS in front of as many eyes as
possible. The worst that can happen is "nothing". Anything else is "to
the good". Never know what some of that might lead to. Even a small
fraction can be profitable.

A VMS "demo disk" should be as simple as one of those Linux disks that
you put in the reader and are immediately running Linux. Or WEENDOZE.
No, there won't be a Solitare game immediately available, but that's not
your target audience. Now, a socket based client and echo server, which
could work with any other system they have, might be a good demo
program. "Yep, VMS will work in your environment".
Post by Stephen Hoffman
LMF was designed to be able to implement most any scheme that the
pricing folks could conceive. It's bloody brilliant for that, too. But
LMF is an inward-facing design, and not a customer-facing one.
And it's one more obstacle to the casual observer.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
t***@glaver.org
2019-04-07 03:07:03 UTC
Permalink
Post by Stephen Hoffman
If you're planning to stay with OpenVMS and want current versions and
support, you'll want to migrate your licenses and support and versions
to VSI.
And there's the discussion about VSI marketing.
Indeed. On a number of occasions I've said to VSI folks "I'm a Hobbyist - please take my money!" and have been told that there's no mechanism in place for that at the (then-current) time. Based on what I've heard from people who have purchased from VSI, pricing is rather more variable than it was with Hpaqital, so I'm not sure why this is happening. I'm running the commercial version of AlphaVM from a customized price quotation, so it isn't impossible for vendors to do this.
Post by Stephen Hoffman
VSI is unfortunately sticking with the absurd product names though, but
then acronyms and obfuscations are the OpenVMS way. We can't have
something cleverly called "webserver", after all. Much too obvious.
Requirements around the possession of arcane or obscure knowledge—like
what SWS or CSWS translates into—is part of the membership in the
OpenVMS club. Plain names and clear descriptions? Those are just not
permitted. So we have CSWS, which everybody obviously knows is a web
server.
It would be nice if the product was called "VSI Apache web server (formerly CSWS) for OpenVMS" or somesuch.
Post by Stephen Hoffman
This is a restriction of the upstream in the case of the OpenSSL APIs,
and the upstream OpenSSL releases are themselves not completely
compatible.
For "native" VMS use, any particular SSL implementation could be shimmed to give it typical VMS calling conventions. For use with Apache, SAMBA, etc. the (undocumented on VMS?) native (non-shimmed) interface could be used if converting the particular application to VMS-type conventions is too much work.
Post by Stephen Hoffman
To address that incompatibility when it next arose, then-HP tried to
make this stuff independent with the SSL1 kit in addition to the
existing SSL kit, but didn't quite complete the design.
If I'm remembering correctly, at one point the newest HP/VMS OpenSSL release had a _lower_ version number than the older release.
Post by Stephen Hoffman
VSI has moved to allow multiple installed versions in parallel with
their latest V8.4-2L1 and V8.4-2L2 releases, which will ease the
migrations.
We're headed for another OpenSSL update and likely later this year, as
the OpenSSL security patches are ending for the current series. We'll
see a version based on 1.1.1, and then 3.0.0 as that arrives.
This would seem to make a good argument for shimming.
Post by Stephen Hoffman
Then there's the discussion of why any of Apache and OpenSSL is
separate from the OpenVMS distribution, and not integrated. Having
worked with server platforms with integrated networking and network
services, the OpenVMS approach is just a hassle. When it works.
Because they update far more frequently than VMS does? But this gets into a discussion of support / patching plans, etc. which is a completely different can of fish?
Neil Rieck
2019-04-07 14:06:20 UTC
Permalink
Post by Stephen Hoffman
Post by Neil Rieck
Strictly as an emergency backup plan, I've been working on trial to
replace CSWS-2.2-1 with WASD-11.
The current OpenVMS CSWS version is based on Apache HTTP Server V2.4-38.
Apache HTTP Server 2.4-39 is current.
https://httpd.apache.org/security/vulnerabilities_24.html
Building a new version of Apache on OpenVMS is somewhat of a project,
though it's possible.
Updating OpenSSL TLS would usually be a smaller project within an
existing Apache port, so long as the software versions involved aren't
too skewed.
Per Apache, "Apache HTTP Server version 2.4.39 or newer is required in
order to operate a TLS 1.3 web server with OpenSSL 1.1.1."
Also per Apache, "Please note the 2.2.x branch has now passed the end
of life at the Apache HTTP Server project and no further activity will
occur including security patches."
"Y2K20"? Obfuscare, err, obfuscate much? Why not MMXX? 🤪
--
Pure Personal Opinion | HoffmanLabs LLC
The current version of CSWS for OpenVMS from HPE is based upon Apache 2.0.63

The current version of CSWS for OpenVMS from VSI is based upon Apache 2.4.12 according to this link.

We attempted to move support from HPE to VSI last year but our management would not approve the purchase of software relicensing by VSI. If they had then I would not find myself in this dilemma; which is why I'm experimenting with WASD.

p.s. managers are always moving around. There is a high likelihood that when dung-hits-the-fan next year, they'll be gone and I'll be blamed for not having a workaround waiting in the wings. A career limiting situation indeed.

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
Bill Gunshannon
2019-04-07 14:21:31 UTC
Permalink
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our management would not approve the purchase of software relicensing by VSI.
I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.

When the recent discussion about Intersystems was going
on I saw it again. There is a very finite expense in
VARs moving to the new version of VMS. Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture. One must buy the
new version of the OS and the necessary licenses to use
it. And one must weigh that cost against expected revenues.
When one was already considering dropping support it can
become very hard to justify the needed expense when one
has other platforms that more than supply the revenue
to keep the company successful.

Sadly, I think this forced change may be more detrimental
to the continued success of VMS than people either expect
or want. And, the way HPE is handling their end (at least
from what I can see and my perception of it) is not going
to help. They wanted to kill VMS. I think they still do
because its continued success would reflect badly on their
decision to kill it. I expect they will do nothing to aids
in VSI's successful revival of VMS and quite the contrary
will do all they can to scuttle it.

bill
Craig A. Berry
2019-04-07 15:20:23 UTC
Permalink
Post by Bill Gunshannon
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by VSI.
I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.
If you were the conveyor of non-bogus information, then people might be
more receptive.
Post by Bill Gunshannon
When the recent discussion about Intersystems was going
on I saw it again.  There is a very finite expense in
VARs moving to the new version of VMS.  Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture.  One must buy the
new version of the OS and the necessary licenses to use
it.  And one must weigh that cost against expected revenues.
When we moved to VSI from HPE a couple of years ago at the time our HPE
support contract was expiring, it was a whole lot cheaper to get a
support contract with VSI including new licenses than to renew with HPE.
So switching to VSI meant saving money immediately, not incurring any
extra expense. Our licenses included upgrade rights to the x86_64
version when it becomes available.

People running unsupported will have some cash outlay to switch to VSI.
But people running unsupported are not planning for the future anyway.

As far as buying new hardware to make a platform switch, do you really
think it will be cheaper to maintain 10-20-year-old Alpha or Integrity
hardware over the next five years than to get some brand new x86 kit (or
possibly just spin up some VM instances on a host most companies already
have available)?
Bill Gunshannon
2019-04-07 15:49:15 UTC
Permalink
Post by Craig A. Berry
Post by Bill Gunshannon
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by VSI.
I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.
If you were the conveyor of non-bogus information, then people might be
more receptive.
Why do you say it was bogus? Neil just posted an example from his
own personal experience supporting it. Others have been mentioned
here in the past. And I remember similar (for other products) from
my days in the business and academic world.
Post by Craig A. Berry
Post by Bill Gunshannon
When the recent discussion about Intersystems was going
on I saw it again.  There is a very finite expense in
VARs moving to the new version of VMS.  Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture.  One must buy the
new version of the OS and the necessary licenses to use
it.  And one must weigh that cost against expected revenues.
When we moved to VSI from HPE a couple of years ago at the time our HPE
support contract was expiring, it was a whole lot cheaper to get a
support contract with VSI including new licenses than to renew with HPE.
You were lucky. Are everyone's licenses going to expire at just
the right time?
Post by Craig A. Berry
 So switching to VSI meant saving money immediately, not incurring any
extra expense.  Our licenses included upgrade rights to the x86_64
version when it becomes available.
But that doesn't pay for the new equipment which will be an
additional expense. Management look at everything. If they
have to buy new machines and new software and new licenses
they will be looking at the big picture. And the competitors
to VMS are going to be more in the front of their minds
because they see the ads on TV during the golf and in their
trade journals and on billboards when they drive to work.
Post by Craig A. Berry
People running unsupported will have some cash outlay to switch to VSI.
 But people running unsupported are not planning for the future anyway.
That's true and I never said it wasn't. The only people who matter
are the ones spending money.
Post by Craig A. Berry
As far as buying new hardware to make a platform switch, do you really
think it will be cheaper to maintain 10-20-year-old Alpha or Integrity
hardware over the next five years than to get some brand new x86 kit (or
possibly just spin up some VM instances on a host most companies already
have available)?
No, I don't think it will be cheaper. But, going back to the
Intersystems example. Dou you think it will be cheaper (or
more profitable) to invest in the move to X86-64 VMS than to
just let the VMS support wither and die? The sell their
product on a lot of long-term viable systems. Is there really
likely to be enough business left on VMS to justify the expense
of maintaining it.

Not saying it is a bad idea, just trying to get past the blinders
of people here and point out that the picture is not as rosy as
some would like it to be. It's hard sell and with the negative
picture that HPE continues to paint, it isn't going to get better.

Tell me, has HPE provided VSI with their VMS customer list so that
VSI can actively talk with these people about migrating? Last
thing about I saw about that here was "No".

bill
Jan-Erik Söderholm
2019-04-07 16:05:31 UTC
Permalink
Post by Craig A. Berry
Post by Bill Gunshannon
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by VSI.
I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.
If you were the conveyor of non-bogus information, then people might be
more receptive.
Why do you say it was bogus?  Neil just posted an example from his
own personal experience supporting it.
Neil posted one example from one specific company. I can post another
example from another specific company that did the opposite. So then
we are even, right?
Post by Craig A. Berry
When we moved to VSI from HPE a couple of years ago at the time our HPE
support contract was expiring, it was a whole lot cheaper to get a
support contract with VSI including new licenses than to renew with HPE.
You were lucky.  Are everyone's licenses going to expire at just
the right time?
Everyone's licences will expire when the support from HPE ends.
What would the "right time" be otherwise?
Post by Craig A. Berry
  So switching to VSI meant saving money immediately, not incurring any
extra expense.  Our licenses included upgrade rights to the x86_64
version when it becomes available.
But that doesn't pay for the new equipment which will be an
additional expense.
The usual x86 server replacement period is 3-4 years. How could it
then be an issue to replace some 10-15 year old Alpha with x86?
Not saying it is a bad idea, just trying to get past the blinders
of people here and point out that the picture is not as rosy as
some would like it to be.  It's hard sell and with the negative
picture...
What "negative picture". They have transferred the maintenance
of VMS to someone else and are winding down their own business.
What else could they do?
that HPE continues to paint, it isn't going to get better.
Tell me,
Ask VSI if you need to know.
Bill Gunshannon
2019-04-08 00:17:34 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Craig A. Berry
Post by Bill Gunshannon
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by VSI.
I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.
If you were the conveyor of non-bogus information, then people might be
more receptive.
Why do you say it was bogus?  Neil just posted an example from his
own personal experience supporting it.
Neil posted one example from one specific company. I can post another
example from another specific company that did the opposite. So then
we are even, right?
Even in this race is a loser.
Example: There are 100 companies running HPE VMS.
50 move to VSI VMS.
50 move to Linux or Windows.

Even, right?
Post by Jan-Erik Söderholm
Post by Craig A. Berry
When we moved to VSI from HPE a couple of years ago at the time our HPE
support contract was expiring, it was a whole lot cheaper to get a
support contract with VSI including new licenses than to renew with HPE.
You were lucky.  Are everyone's licenses going to expire at just
the right time?
Everyone's licences will expire when the support from HPE ends.
What would the "right time" be otherwise?
And how many of them will be left with a bitter taste in their mouth.
And before you say none, how many people here really dislike HP/HPE
over the past treatment of VMS? And, how many of these will choose
to take it out on VMS rather than HPE who will have left the game.
Post by Jan-Erik Söderholm
Post by Craig A. Berry
  So switching to VSI meant saving money immediately, not incurring any
extra expense.  Our licenses included upgrade rights to the x86_64
version when it becomes available.
But that doesn't pay for the new equipment which will be an
additional expense.
The usual x86 server replacement period is 3-4 years. How could it
then be an issue to replace some 10-15 year old Alpha with x86?
We are not talking about replacing the Alphas. We are talking
about having to develop software on the new machine while still
running on the Alpha. This is not a light switch solution where
you can turn one off turn the other on and continue operations.
Post by Jan-Erik Söderholm
Not saying it is a bad idea, just trying to get past the blinders
of people here and point out that the picture is not as rosy as
some would like it to be.  It's hard sell and with the negative
picture...
What "negative picture". They have transferred the maintenance
of VMS to someone else and are winding down their own business.
What else could they do?
Actively work on convincing their current installed VMS base
to move over to VSI. Anybody heard about them doing that?
Post by Jan-Erik Söderholm
that HPE continues to paint, it isn't going to get better.
Tell me,
Ask VSI if you need to know.
bill
Dave Froble
2019-04-08 02:41:50 UTC
Permalink
Another Bill post to stomp upon ...
Post by Bill Gunshannon
Post by Jan-Erik Söderholm
Post by Bill Gunshannon
Post by Craig A. Berry
Post by Bill Gunshannon
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by VSI.
I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.
If you were the conveyor of non-bogus information, then people might be
more receptive.
Why do you say it was bogus? Neil just posted an example from his
own personal experience supporting it.
Neil posted one example from one specific company. I can post another
example from another specific company that did the opposite. So then
we are even, right?
Even in this race is a loser.
Example: There are 100 companies running HPE VMS.
50 move to VSI VMS.
50 move to Linux or Windows.
Even, right?
You are correct, it is NOT even. There is NO WAY anyone will take
applications running on VMS and move them to anything else, including
Linux, without spending much more money. MUCH MORE!
Post by Bill Gunshannon
Post by Jan-Erik Söderholm
Post by Bill Gunshannon
Post by Craig A. Berry
When we moved to VSI from HPE a couple of years ago at the time our HPE
support contract was expiring, it was a whole lot cheaper to get a
support contract with VSI including new licenses than to renew with HPE.
You were lucky. Are everyone's licenses going to expire at just
the right time?
Everyone's licences will expire when the support from HPE ends.
What would the "right time" be otherwise?
And how many of them will be left with a bitter taste in their mouth.
And before you say none, how many people here really dislike HP/HPE
over the past treatment of VMS? And, how many of these will choose
to take it out on VMS rather than HPE who will have left the game.
Bitter about HP(e)s treatment of VMS? Bitter doesn't even begin to
describe it. The only way I would not piss on HP(e) is if they were on
fire.

VSI has my gratitude ...
Post by Bill Gunshannon
Post by Jan-Erik Söderholm
Post by Bill Gunshannon
Post by Craig A. Berry
So switching to VSI meant saving money immediately, not incurring any
extra expense. Our licenses included upgrade rights to the x86_64
version when it becomes available.
But that doesn't pay for the new equipment which will be an
additional expense.
You won't need "new equipment" for Linux? You are so full of FUD.
Post by Bill Gunshannon
Post by Jan-Erik Söderholm
The usual x86 server replacement period is 3-4 years. How could it
then be an issue to replace some 10-15 year old Alpha with x86?
We are not talking about replacing the Alphas. We are talking
about having to develop software on the new machine while still
running on the Alpha. This is not a light switch solution where
you can turn one off turn the other on and continue operations.
It was just that for us with the Alpha to itanic port. Re-compile,
re-link, move data files, and run.

Yes, transferring the data files took just a bit longer than flicking a
light switch.
Post by Bill Gunshannon
Post by Jan-Erik Söderholm
Post by Bill Gunshannon
Not saying it is a bad idea, just trying to get past the blinders
of people here and point out that the picture is not as rosy as
some would like it to be. It's hard sell and with the negative
picture...
What "negative picture". They have transferred the maintenance
of VMS to someone else and are winding down their own business.
What else could they do?
Actively work on convincing their current installed VMS base
to move over to VSI. Anybody heard about them doing that?
Yes ...
Post by Bill Gunshannon
Post by Jan-Erik Söderholm
Post by Bill Gunshannon
that HPE continues to paint, it isn't going to get better.
Tell me,
Ask VSI if you need to know.
bill
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
s***@gmail.com
2019-05-16 10:42:33 UTC
Permalink
Post by Bill Gunshannon
Even in this race is a loser.
Example: There are 100 companies running HPE VMS.
50 move to VSI VMS.
50 move to Linux or Windows.
Even, right?
WRONG! IF THEY LOOK AT THE CERT COUNTS FROM THE LAST 20 YEARS
OPENVMS 19 LINUX 2205 I BET IT WILL BE 100 TO VMS 0 TO LINUX.
Simon Clubley
2019-05-16 12:28:36 UTC
Permalink
Post by s***@gmail.com
Post by Bill Gunshannon
Even in this race is a loser.
Example: There are 100 companies running HPE VMS.
50 move to VSI VMS.
50 move to Linux or Windows.
Even, right?
WRONG! IF THEY LOOK AT THE CERT COUNTS FROM THE LAST 20 YEARS
OPENVMS 19 LINUX 2205 I BET IT WILL BE 100 TO VMS 0 TO LINUX.
Comparing CVE counts for different operating systems means absolutely
nothing unless (at an absolute minimum):

1) There are a comparable number of security researchers looking at each
operating system being compared as well as spending the same amount
of effort looking for flaws in each operating system and

2) There is a comparable range of software installed on all the
operating systems being compared.

Neither of these are true when comparing Linux to VMS.

BTW Bob, the ASR 33 is no longer the standard input device in use
these days and it is ok to include lower case in your replies.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Arne Vajhøj
2019-05-16 12:35:45 UTC
Permalink
Post by s***@gmail.com
Post by Bill Gunshannon
Even in this race is a loser.
Example: There are 100 companies running HPE VMS.
50 move to VSI VMS.
50 move to Linux or Windows.
Even, right?
WRONG! IF THEY LOOK AT THE CERT COUNTS FROM THE LAST 20 YEARS
OPENVMS 19 LINUX 2205 I BET IT WILL BE 100 TO VMS 0 TO LINUX.
Like nobody has moved from VMS to Unix/Linux/Windows the last 20 years ...

:-)

You need to view the world as the world actually is and not how you wish
it were.

Arne
Scott Dorsey
2019-04-07 16:49:18 UTC
Permalink
Post by Bill Gunshannon
But that doesn't pay for the new equipment which will be an
additional expense. Management look at everything. If they
have to buy new machines and new software and new licenses
they will be looking at the big picture. And the competitors
to VMS are going to be more in the front of their minds
because they see the ads on TV during the golf and in their
trade journals and on billboards when they drive to work.
Computers are cheap. Support is expensive.

If you're already paying for support, the new software and new licenses
will be coming along for free in the bargain. Your cost is the
hardware and that of transitioning your own software in that day when the
move to x86 becomes essential.

If you're not paying for support, then you have more serious problems
to worry about.

Timeline: you move from HPE support to VSI support right now. This is
likely to be a cost savings rather than an extra cost. When the x86 port
comes along, you buy x86 hardware and move your applications to it. That
will cost money, but that's not today, and it's likely a drop in the
bucket compared with the support costs.

If, on the other hand, you are running unsupported software on unsupported
hardware, you have the choice of either putting up the money and getting
support, or continuing on with the same path. Depending on how critical
your system is, you may realistically prefer either one. I have a vax
right now in the corner of the machine room for reading the occaisonal
9-track tape. The OS is not supportable, neither is the hardware, but if
it breaks I'll fix it. If it takes a few weeks for me to get it done,
that's okay. It doesn't need support. On the other hand, we also have
critical systems that need and have support.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Neil Rieck
2019-04-13 18:10:54 UTC
Permalink
Post by Craig A. Berry
Post by Bill Gunshannon
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by VSI.
I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.
If you were the conveyor of non-bogus information, then people might be
more receptive.
Post by Bill Gunshannon
When the recent discussion about Intersystems was going
on I saw it again.  There is a very finite expense in
VARs moving to the new version of VMS.  Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture.  One must buy the
new version of the OS and the necessary licenses to use
it.  And one must weigh that cost against expected revenues.
When we moved to VSI from HPE a couple of years ago at the time our HPE
support contract was expiring, it was a whole lot cheaper to get a
support contract with VSI including new licenses than to renew with HPE.
So switching to VSI meant saving money immediately, not incurring any
extra expense. Our licenses included upgrade rights to the x86_64
version when it becomes available.
People running unsupported will have some cash outlay to switch to VSI.
But people running unsupported are not planning for the future anyway.
As far as buying new hardware to make a platform switch, do you really
think it will be cheaper to maintain 10-20-year-old Alpha or Integrity
hardware over the next five years than to get some brand new x86 kit (or
possibly just spin up some VM instances on a host most companies already
have available)?
Unfortunately that was not my experience.

In 2015, we purchased a brand new rx2800-i2 from HP and this meant trading in Alpha licenses (OpenVMS, C, C++, BASIC, FMS) to get new Itanium equivalents. The total purchase (which was not cheap) also provided three years of hardware and software support.

Three years later, our software support agreement with HPE was expiring so I reached out to VSI where I was told that I needed to buy new licenses, then upgrade the OS in order to get a one-year support contract. The new business quote from VSI was three times larger than the software support renewal from HPE.

I recommended going with VSI but middle management (who were making the decisions and would need to sign off on the approvals) absolutely refused. From their perspective, we had just bought new licenses 3-years earlier from HP and didn't give a damn about anything else. In fact, one middle-manager said to me (paraphrased) "that if VSI took over the OpenVMS product line from HP/HPE then they (VSI) should honor the HP licenses"

While I disagreed with him, I could see his point of view.

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
Craig A. Berry
2019-04-13 18:52:02 UTC
Permalink
Post by Neil Rieck
Post by Craig A. Berry
Post by Bill Gunshannon
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by VSI.
I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.
If you were the conveyor of non-bogus information, then people might be
more receptive.
Post by Bill Gunshannon
When the recent discussion about Intersystems was going
on I saw it again.  There is a very finite expense in
VARs moving to the new version of VMS.  Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture.  One must buy the
new version of the OS and the necessary licenses to use
it.  And one must weigh that cost against expected revenues.
When we moved to VSI from HPE a couple of years ago at the time our HPE
support contract was expiring, it was a whole lot cheaper to get a
support contract with VSI including new licenses than to renew with HPE.
So switching to VSI meant saving money immediately, not incurring any
extra expense. Our licenses included upgrade rights to the x86_64
version when it becomes available.
People running unsupported will have some cash outlay to switch to VSI.
But people running unsupported are not planning for the future anyway.
As far as buying new hardware to make a platform switch, do you really
think it will be cheaper to maintain 10-20-year-old Alpha or Integrity
hardware over the next five years than to get some brand new x86 kit (or
possibly just spin up some VM instances on a host most companies already
have available)?
Unfortunately that was not my experience.
In 2015, we purchased a brand new rx2800-i2 from HP and this meant trading in Alpha licenses (OpenVMS, C, C++, BASIC, FMS) to get new Itanium equivalents. The total purchase (which was not cheap) also provided three years of hardware and software support.
Three years later, our software support agreement with HPE was expiring so I reached out to VSI where I was told that I needed to buy new licenses, then upgrade the OS in order to get a one-year support contract. The new business quote from VSI was three times larger than the software support renewal from HPE.
I recommended going with VSI but middle management (who were making the decisions and would need to sign off on the approvals) absolutely refused. From their perspective, we had just bought new licenses 3-years earlier from HP and didn't give a damn about anything else. In fact, one middle-manager said to me (paraphrased) "that if VSI took over the OpenVMS product line from HP/HPE then they (VSI) should honor the HP licenses"
While I disagreed with him, I could see his point of view.
Did you try pricing a three-year support contract? It may be that VSI
does not offer attractive trade-ins without that, or it may be that they
stopped offering such deals shortly after we got ours.
Dave Froble
2019-04-14 00:33:01 UTC
Permalink
Post by Neil Rieck
Unfortunately that was not my experience.
In 2015, we purchased a brand new rx2800-i2 from HP and this meant trading in Alpha licenses (OpenVMS, C, C++, BASIC, FMS) to get new Itanium equivalents. The total purchase (which was not cheap) also provided three years of hardware and software support.
Three years later, our software support agreement with HPE was expiring so I reached out to VSI where I was told that I needed to buy new licenses, then upgrade the OS in order to get a one-year support contract. The new business quote from VSI was three times larger than the software support renewal from HPE.
I recommended going with VSI but middle management (who were making the decisions and would need to sign off on the approvals) absolutely refused. From their perspective, we had just bought new licenses 3-years earlier from HP and didn't give a damn about anything else. In fact, one middle-manager said to me (paraphrased) "that if VSI took over the OpenVMS product line from HP/HPE then they (VSI) should honor the HP licenses"
While I disagreed with him, I could see his point of view.
I'm going to agree with the manager. It's just plain stupid of VSI to
throw away the support contract. I sure hope their reasoning is not
"they'll be back, where else can they go". Management might just decide
to throw VMS out completely, or, run without support.

Don't know what they are thinking, but, it sure isn't long term ...

Now they get nothing.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2019-04-07 16:59:44 UTC
Permalink
Post by Bill Gunshannon
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by VSI.
I'm not aware of VSI's pricing, but, if long term support is desired,
then I personally think it is just stupid to charge any significant
re-licensing fees. That just means they won't get the support money.

It would be interesting to know just what fees were quoted. And for how
many systems. Be a good indicator of which side, or both, are being
unreasonable.
Post by Bill Gunshannon
I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.
When the recent discussion about Intersystems was going
on I saw it again. There is a very finite expense in
VARs moving to the new version of VMS. Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture. One must buy the
new version of the OS and the necessary licenses to use
it. And one must weigh that cost against expected revenues.
When one was already considering dropping support it can
become very hard to justify the needed expense when one
has other platforms that more than supply the revenue
to keep the company successful.
Well, you just made a big leap there Bill, with nothing to justify it.
I did not notice Neil mentioning any plans to drop support, or move to
alternates.
Post by Bill Gunshannon
Sadly, I think this forced change may be more detrimental
to the continued success of VMS than people either expect
or want. And, the way HPE is handling their end (at least
from what I can see and my perception of it) is not going
to help. They wanted to kill VMS. I think they still do
because its continued success would reflect badly on their
decision to kill it. I expect they will do nothing to aids
in VSI's successful revival of VMS and quite the contrary
will do all they can to scuttle it.
If HP(e) wanted to kill VMS, all they had to do was not give it to VSI.

Then again, they may have had some legal reasons to do so. Doesn't mean
they want VSI to succeed.

The bottom line, VSI should be taking the "long view" if they want to
succeed.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2019-04-08 00:07:46 UTC
Permalink
Post by Dave Froble
Post by Bill Gunshannon
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by VSI.
I'm not aware of VSI's pricing, but, if long term support is desired,
then I personally think it is just stupid to charge any significant
re-licensing fees.  That just means they won't get the support money.
He didn't say how much it was. he said they would not approve it.
The one may not have been the reason for the other.
Post by Dave Froble
It would be interesting to know just what fees were quoted.  And for how
many systems.  Be a good indicator of which side, or both, are being
unreasonable.
From their own point of view, I doubt either is unreasonable.
Post by Dave Froble
Post by Bill Gunshannon
I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.
When the recent discussion about Intersystems was going
on I saw it again.  There is a very finite expense in
VARs moving to the new version of VMS.  Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture.  One must buy the
new version of the OS and the necessary licenses to use
it.  And one must weigh that cost against expected revenues.
When one was already considering dropping support it can
become very hard to justify the needed expense when one
has other platforms that more than supply the revenue
to keep the company successful.
Well, you just made a big leap there Bill, with nothing to justify it. I
did not notice Neil mentioning any plans to drop support, or move to
alternates.
In that paragraph I was talking about Intersystems and Cache.
While some have said they heard otherwise the web page still
says no new VMS versions. If no new VMS versions are going
to be forthcoming people using Intersystems Cache on VMS
have only two choices. Stay where they are to move to a
system that has a path forward.
Post by Dave Froble
Post by Bill Gunshannon
Sadly, I think this forced change may be more detrimental
to the continued success of VMS than people either expect
or want.  And, the way HPE is handling their end (at least
from what I can see and my perception of it) is not going
to help.  They wanted to kill VMS.  I think they still do
because its continued success would reflect badly on their
decision to kill it.  I expect they will do nothing to aids
in VSI's successful revival of VMS and quite the contrary
will do all they can to scuttle it.
If HP(e) wanted to kill VMS, all they had to do was not give it to VSI.
If they did that they would live the possible bad press of their
failure with VMS to come back and haunt them in the future. Now,
if VMS fails the blame lands squarely on VSI's shoulders.
Post by Dave Froble
Then again, they may have had some legal reasons to do so.  Doesn't mean
they want VSI to succeed.
I don;t think they care about VSI. I think it is all about VMS
and corporate image.
Post by Dave Froble
The bottom line, VSI should be taking the "long view" if they want to
succeed.
I am sure they are. But I also think that it is a long uphill
battle and HPE, who could be helping at no real cost to themselves
are actually doing the opposite.

bill
Dave Froble
2019-04-08 02:44:50 UTC
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Bill Gunshannon
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by VSI.
I'm not aware of VSI's pricing, but, if long term support is desired,
then I personally think it is just stupid to charge any significant
re-licensing fees. That just means they won't get the support money.
He didn't say how much it was. he said they would not approve it.
The one may not have been the reason for the other.
Post by Dave Froble
It would be interesting to know just what fees were quoted. And for
how many systems. Be a good indicator of which side, or both, are
being unreasonable.
From their own point of view, I doubt either is unreasonable.
Post by Dave Froble
Post by Bill Gunshannon
I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.
When the recent discussion about Intersystems was going
on I saw it again. There is a very finite expense in
VARs moving to the new version of VMS. Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture. One must buy the
new version of the OS and the necessary licenses to use
it. And one must weigh that cost against expected revenues.
When one was already considering dropping support it can
become very hard to justify the needed expense when one
has other platforms that more than supply the revenue
to keep the company successful.
Well, you just made a big leap there Bill, with nothing to justify it.
I did not notice Neil mentioning any plans to drop support, or move to
alternates.
In that paragraph I was talking about Intersystems and Cache.
While some have said they heard otherwise the web page still
says no new VMS versions. If no new VMS versions are going
to be forthcoming people using Intersystems Cache on VMS
have only two choices. Stay where they are to move to a
system that has a path forward.
Web sites are never out of date, or missing information? BA HA HA HA
Post by Bill Gunshannon
Post by Dave Froble
Post by Bill Gunshannon
Sadly, I think this forced change may be more detrimental
to the continued success of VMS than people either expect
or want. And, the way HPE is handling their end (at least
from what I can see and my perception of it) is not going
to help. They wanted to kill VMS. I think they still do
because its continued success would reflect badly on their
decision to kill it. I expect they will do nothing to aids
in VSI's successful revival of VMS and quite the contrary
will do all they can to scuttle it.
If HP(e) wanted to kill VMS, all they had to do was not give it to VSI.
If they did that they would live the possible bad press of their
failure with VMS to come back and haunt them in the future. Now,
if VMS fails the blame lands squarely on VSI's shoulders.
Post by Dave Froble
Then again, they may have had some legal reasons to do so. Doesn't
mean they want VSI to succeed.
I don;t think they care about VSI. I think it is all about VMS
and corporate image.
Post by Dave Froble
The bottom line, VSI should be taking the "long view" if they want to
succeed.
I am sure they are. But I also think that it is a long uphill
battle and HPE, who could be helping at no real cost to themselves
are actually doing the opposite.
Frankly, I'd be afraid of any more HP(e) help, seeing what they have
done in the past, and even now.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2019-04-07 18:54:44 UTC
Permalink
Post by Bill Gunshannon
When the recent discussion about Intersystems was going
on I saw it again.  There is a very finite expense in
VARs moving to the new version of VMS.  Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture.  One must buy the
new version of the OS and the necessary licenses to use
it.  And one must weigh that cost against expected revenues.
When one was already considering dropping support it can
become very hard to justify the needed expense when one
has other platforms that more than supply the revenue
to keep the company successful.
They don't need to buy new x86-64 HW - they can run it on VM's.

And I expect that VSI offer ISV's (I assume you mean ISV's not VAR's)
licenses for free or very little.

So the cost is the effort to port and test. Which obviously
can be substantial.
Post by Bill Gunshannon
Sadly, I think this forced change may be more detrimental
to the continued success of VMS than people either expect
or want.
The move from Itanium to x86-64 will certainly hurt VMS short term.

But given that Itanium is dead then either VMS move or VMS is dead. It
was not a real choice.

And long term being on a standard HW platform may turn out to be a good
thing.

Arne
Robert A. Brooks
2019-04-07 20:46:06 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
When the recent discussion about Intersystems was going
on I saw it again.  There is a very finite expense in
VARs moving to the new version of VMS.  Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture.  One must buy the
new version of the OS and the necessary licenses to use
it.  And one must weigh that cost against expected revenues.
When one was already considering dropping support it can
become very hard to justify the needed expense when one
has other platforms that more than supply the revenue
to keep the company successful.
They don't need to buy new x86-64 HW - they can run it on VM's.
And I expect that VSI offer ISV's (I assume you mean ISV's not VAR's)
licenses for free or very little.
That's correct.
--
-- Rob
Bill Gunshannon
2019-04-07 23:58:14 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
When the recent discussion about Intersystems was going
on I saw it again.  There is a very finite expense in
VARs moving to the new version of VMS.  Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture.  One must buy the
new version of the OS and the necessary licenses to use
it.  And one must weigh that cost against expected revenues.
When one was already considering dropping support it can
become very hard to justify the needed expense when one
has other platforms that more than supply the revenue
to keep the company successful.
They don't need to buy new x86-64 HW - they can run it on VM's.
And those are free?
Post by Arne Vajhøj
And I expect that VSI offer ISV's (I assume you mean ISV's not VAR's)
licenses for free or very little.
I certainly have n ot heard of anyone getting free licenses. Anybody
want to confirm that? Very little is a subjective term. How much
"very little" actually is may depend on which side of the fence you
are standing.
Post by Arne Vajhøj
So the cost is the effort to port and test. Which obviously
can be substantial.
And maintain after you have ported and tested.
Post by Arne Vajhøj
Post by Bill Gunshannon
Sadly, I think this forced change may be more detrimental
to the continued success of VMS than people either expect
or want.
The move from Itanium to x86-64 will certainly hurt VMS short term.
But given that Itanium is dead then either VMS move or VMS is dead. It
was not a real choice.
And long term being on a standard HW platform may turn out to be a good
thing.
Yes, it may. And believe it or not, I would like to see that happen.
But some people really need to look at this from the point of view
of the outside world. It is not as rosy as many want to see it.

bill
Dave Froble
2019-04-08 02:32:52 UTC
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
When the recent discussion about Intersystems was going
on I saw it again. There is a very finite expense in
VARs moving to the new version of VMS. Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture. One must buy the
new version of the OS and the necessary licenses to use
it. And one must weigh that cost against expected revenues.
When one was already considering dropping support it can
become very hard to justify the needed expense when one
has other platforms that more than supply the revenue
to keep the company successful.
They don't need to buy new x86-64 HW - they can run it on VM's.
And those are free?
Nothing is free. TANSTAAFL ...

But, if you'e going to run some stuff on some system, then isn't the
cost going to be there, regardless of what system?

Stop expounding a double standard ...
Post by Bill Gunshannon
Post by Arne Vajhøj
And I expect that VSI offer ISV's (I assume you mean ISV's not VAR's)
licenses for free or very little.
I certainly have n ot heard of anyone getting free licenses. Anybody
want to confirm that? Very little is a subjective term. How much
"very little" actually is may depend on which side of the fence you
are standing.
Here you go ...

OpenVMS V8.4-2L1 on node AS800 7-APR-2019 21:23:51.78 Uptime 66
06:13:48

Courtesy of a VSI developer's license.

Confirmed now?

Oh, yeah, and I have VMS V8.4 2L2 for my EV6 systems, though not using
them at this time.

I will admit it would be nice to have the new TCP/IP to learn from, but,
I can be patient.
Post by Bill Gunshannon
Post by Arne Vajhøj
So the cost is the effort to port and test. Which obviously
can be substantial.
And maintain after you have ported and tested.
Again, tell me how that would differ in any other environment? It's a
wash. W A S H !!!

Actually, if one is on VMS, then any change to anything else will be
more expensive. Sometimes too expensive to survive.
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
Sadly, I think this forced change may be more detrimental
to the continued success of VMS than people either expect
or want.
The move from Itanium to x86-64 will certainly hurt VMS short term.
But given that Itanium is dead then either VMS move or VMS is dead. It
was not a real choice.
And long term being on a standard HW platform may turn out to be a good
thing.
Yes, it may. And believe it or not, I would like to see that happen.
But some people really need to look at this from the point of view
of the outside world. It is not as rosy as many want to see it.
If the outside world has vision problems, that is an issue, and one
"they" will suffer from. Or, they can have an ounce of sense.

One thing is clear, and if you do not agree, then you're fooling
yourself, or just being difficult.

It is always easier and cheaper to remain with what works and is in hand
than to convert to something else, all else being equal. With VMS on
x86 and VMs, it seems all else will be at least equal.

Now, are you done crying "Wolf!"
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Kerry Main
2019-04-27 14:09:41 UTC
Permalink
-----Original Message-----
via Info-vax
Sent: April 7, 2019 2:55 PM
Subject: Re: [Info-vax] OpenSSL CSWS-2.2-1
When the recent discussion about Intersystems was going on I saw it
again. There is a very finite expense in VARs moving to the new
version of VMS. Both on the current architecture and on the future
new architecture.
One must buy new equipment to develop, test and maintain the product
on the new architecture. One must buy the new version of the OS and
the necessary licenses to use it. And one must weigh that cost
against expected revenues.
When one was already considering dropping support it can become very
hard to justify the needed expense when one has other platforms that
more than supply the revenue to keep the company successful.
They don't need to buy new x86-64 HW - they can run it on VM's.
And I expect that VSI offer ISV's (I assume you mean ISV's not VAR's) licenses
for free or very little.
So the cost is the effort to port and test. Which obviously can be substantial.
Sadly, I think this forced change may be more detrimental to the
continued success of VMS than people either expect or want.
The move from Itanium to x86-64 will certainly hurt VMS short term.
But given that Itanium is dead then either VMS move or VMS is dead. It was
not a real choice.
And long term being on a standard HW platform may turn out to be a good
thing.
Arne
Agree.

Just look at Oracle license costs alone. Oracle savings alone often stated as one of the reasons to move Oracle on OpenVMS A64/I64 to Linux on X86-64.

Sample licensing for Oracle for small environment: (5 core server)using list pricing:
OpenVMS - 5 cores x$50,000 x Oracle Processor Core Factor (1 for Alpha, Integrity) = $250,000
Linux - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000

Going fwd with OpenVMS/X86-64:
OpenVMS - - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000
Linux - - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000

Also remember that, similar to RH Linux and Windows, the OpenVMS subscription licensing for VSI remains the same whether the server is on a physical or virtual VM server.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Craig A. Berry
2019-04-27 19:51:02 UTC
Permalink
Post by Kerry Main
Just look at Oracle license costs alone. Oracle savings alone often
stated as one of the reasons to move Oracle on OpenVMS A64/I64 to Linux
on X86-64.
OpenVMS - 5 cores x$50,000 x Oracle Processor Core Factor (1 for Alpha, Integrity) = $250,000
Linux - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000
OpenVMS - - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000
Linux - - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000
Given that no recent version of Oracle database server runs on VMS,
those are very expensive client licenses. Or if you are assuming that
at some point they will bring Oracle classic up-to-date on VMS and
release it on OpenVMS x64, how do you know they would charge the same
price for it that they charge for the Linux version?
Jan-Erik Söderholm
2019-04-27 21:19:13 UTC
Permalink
Post by Craig A. Berry
Post by Kerry Main
Just look at Oracle license costs alone. Oracle savings alone often
stated as one of the reasons to move Oracle on OpenVMS A64/I64 to Linux
on X86-64.
OpenVMS - 5 cores x$50,000 x Oracle  Processor Core Factor (1 for Alpha,
Integrity) = $250,000
Linux - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000
OpenVMS - - 5 cores x$50,000 x Oracle  Processor Core Factor (0.5 for
X86-64) = $125,000
Linux - - 5 cores x$50,000 x Oracle  Processor Core Factor (0.5 for
X86-64) = $125,000
Given that no recent version of Oracle database server runs on VMS,
those are very expensive client licenses.  Or if you are assuming that
at some point they will bring Oracle classic up-to-date on VMS and
release it on OpenVMS x64, how do you know they would charge the same
price for it that they charge for the Linux version?
And do we know if/that Rdb would see the same cost savings?
Arne Vajhøj
2019-04-27 22:39:41 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Craig A. Berry
Post by Kerry Main
Just look at Oracle license costs alone. Oracle savings alone often
stated as one of the reasons to move Oracle on OpenVMS A64/I64 to Linux
on X86-64.
Sample licensing for Oracle for small environment: (5 core
OpenVMS - 5 cores x$50,000 x Oracle  Processor Core Factor (1 for
Alpha, Integrity) = $250,000
Linux - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000
OpenVMS - - 5 cores x$50,000 x Oracle  Processor Core Factor (0.5 for
X86-64) = $125,000
Linux - - 5 cores x$50,000 x Oracle  Processor Core Factor (0.5 for
X86-64) = $125,000
Given that no recent version of Oracle database server runs on VMS,
those are very expensive client licenses.  Or if you are assuming that
at some point they will bring Oracle classic up-to-date on VMS and
release it on OpenVMS x64, how do you know they would charge the same
price for it that they charge for the Linux version?
And do we know if/that Rdb would see the same cost savings?
You should ask somebody at Oracle.

But as I read the price list:

https://www.oracle.com/assets/technology-price-list-070617.pdf

then RDB use the same processor calculation as Classic.

Arne
Arne Vajhøj
2019-04-27 22:36:45 UTC
Permalink
Post by Craig A. Berry
Post by Kerry Main
Just look at Oracle license costs alone. Oracle savings alone often
stated as one of the reasons to move Oracle on OpenVMS A64/I64 to Linux
on X86-64.
Sample licensing for Oracle for small environment: (5 core
OpenVMS - 5 cores x$50,000 x Oracle  Processor Core Factor (1 for
Alpha, Integrity) = $250,000
Linux - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000
OpenVMS - - 5 cores x$50,000 x Oracle  Processor Core Factor (0.5 for
X86-64) = $125,000
Linux - - 5 cores x$50,000 x Oracle  Processor Core Factor (0.5 for
X86-64) = $125,000
Given that no recent version of Oracle database server runs on VMS,
those are very expensive client licenses.  Or if you are assuming that
at some point they will bring Oracle classic up-to-date on VMS and
release it on OpenVMS x64, how do you know they would charge the same
price for it that they charge for the Linux version?
Oracle "Oracle Processor Core Factor Table" is by CPU type.

It has nothing to do with OS.

See:

http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf

It seems very unlikely that Oracle would make an exception for VMS.

Arne
Craig A. Berry
2019-04-27 23:32:14 UTC
Permalink
Post by Arne Vajhøj
Post by Craig A. Berry
Post by Kerry Main
Just look at Oracle license costs alone. Oracle savings alone often
stated as one of the reasons to move Oracle on OpenVMS A64/I64 to Linux
on X86-64.
Sample licensing for Oracle for small environment: (5 core
OpenVMS - 5 cores x$50,000 x Oracle  Processor Core Factor (1 for
Alpha, Integrity) = $250,000
Linux - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000
OpenVMS - - 5 cores x$50,000 x Oracle  Processor Core Factor (0.5 for
X86-64) = $125,000
Linux - - 5 cores x$50,000 x Oracle  Processor Core Factor (0.5 for
X86-64) = $125,000
Given that no recent version of Oracle database server runs on VMS,
those are very expensive client licenses.  Or if you are assuming that
at some point they will bring Oracle classic up-to-date on VMS and
release it on OpenVMS x64, how do you know they would charge the same
price for it that they charge for the Linux version?
Oracle "Oracle Processor Core Factor Table" is by CPU type.
It has nothing to do with OS.
http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf
It seems very unlikely that Oracle would make an exception for VMS.
Maybe. But if the cost per license to them were higher than on other
OSs that have a larger installed base, then I'm sure they could find a
way to charge more for it if they felt they needed to. It's all
speculative until and unless they decide to port some future version of
the product to some future version of OpenVMS x64. I do genuinely hope
that happens.

As far as processor count, people might well save more by reducing the
number of cores than by the benefits of the core factor. A current
8-core Xeon surely wipes the floor with a 32-core AlphaServer GS1280,
for example. The folks on the oldest hardware would likely benefit the
most, which is a good thing, as they're also likely the ones most in
need of persuading to make a change.
Kerry Main
2019-04-28 01:42:14 UTC
Permalink
-----Original Message-----
via Info-vax
Sent: April 27, 2019 7:32 PM
Subject: Re: [Info-vax] OpenSSL CSWS-2.2-1
Post by Arne Vajhøj
Post by Craig A. Berry
Post by Kerry Main
Just look at Oracle license costs alone. Oracle savings alone often
stated as one of the reasons to move Oracle on OpenVMS A64/I64 to
Linux on X86-64.
Sample licensing for Oracle for small environment: (5 core
OpenVMS - 5 cores x$50,000 x Oracle Processor Core Factor (1 for
Alpha, Integrity) = $250,000 Linux - 5 cores x$50,000 x Oracle
Processor Core Factor (0.5 for
X86-64) = $125,000
OpenVMS - - 5 cores x$50,000 x Oracle Processor Core Factor (0.5
for
X86-64) = $125,000
Linux - - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for
X86-64) = $125,000
Given that no recent version of Oracle database server runs on VMS,
those are very expensive client licenses. Or if you are assuming
that at some point they will bring Oracle classic up-to-date on VMS
and release it on OpenVMS x64, how do you know they would charge the
same price for it that they charge for the Linux version?
Oracle "Oracle Processor Core Factor Table" is by CPU type.
It has nothing to do with OS.
http://www.oracle.com/us/corporate/contracts/processor-core-factor-tab
le-070634.pdf
It seems very unlikely that Oracle would make an exception for VMS.
Maybe. But if the cost per license to them were higher than on other OSs
that have a larger installed base, then I'm sure they could find a way to
charge more for it if they felt they needed to. It's all speculative until and
unless they decide to port some future version of the product to some
future version of OpenVMS x64. I do genuinely hope that happens.
As far as processor count, people might well save more by reducing the
number of cores than by the benefits of the core factor. A current 8-core
Xeon surely wipes the floor with a 32-core AlphaServer GS1280, for example.
The folks on the oldest hardware would likely benefit the most, which is a
good thing, as they're also likely the ones most in need of persuading to
make a change.
Minor nit, but as a fyi, the OpenVMS license model for Integrity servers is based on socket counts not core counts.

Applies to both HPE and VSI.

Hence a IA64 server with 1 socket for all its OpenVMS licensing might be $50K. If that same server has 4 sockets, the licensing pricing jumps to $200K.

This might be reason why Neil's pricing quote awhile back was high.

Lesson learned - if you have an older Integrity server with 4 sockets e.g. I2 (or pre-I2) blade server and using HPE for OpenVMS support, moving to a new Integrity server with VSI and fewer sockets might be wise move. The change in license costs might even pay for the new server. Especially if one considers the new I4/I6 server cores will be much faster so you likely can reduce core counts as well as socket counts and hence really reduce the overall license costs for OpenVMS Integrity.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
d***@aol.com
2019-04-29 15:24:13 UTC
Permalink
Given the original topic for this thread being "OpenSSL CSWS-2.2-1" and seeing the concerns about keeping up-to-date with OpenSSL and Apache, I thought I'd throw in my $.02 to let you know what VSI is doing.

VSI continues to keep both OpenSSL and Apache up-to-date and is working on advancing support for many open source offering with a team dedicated to that effort.

SSL1 Update R has been released (OpenSSL 1.0.2r).

OpenSSL 1.1.1(b) kits have been developed and will be released soon (TLS V1.3 support). The product name will likely be SSL111 and maintain the same install structure as SSL1 (separate directory trees for co-existence).

CSWS will be released built against SSL111 and include TLS V1.3 support in the near future. Current support level is TLS V1.2.

There is also an LDAP client update (V3) that allows the caller to specify which TLS version to restrict connections to as an alternative to the current handshake negotiations from TLSV1.2 down to as low as SSLV3.

Plans are also in place to follow the OpenSSL V3.0 release when it becomes available. (SSL3?)

Hope this helps.

Doug.
Craig A. Berry
2019-04-29 16:06:25 UTC
Permalink
Post by d***@aol.com
OpenSSL 1.1.1(b) kits have been developed and will be released soon
(TLS V1.3 support). The product name will likely be SSL111 and maintain
the same install structure as SSL1 (separate directory trees for co-existence).
SSL11 would make more sense than SSL111 in that it preserves those parts (and only those parts) of the version number indicating a binary compatible release. There may never be a 1.1.2, but if there is, it will be binary compatible with 1.1.1, so no need for a new product name.

While it will probably throw a wrench into human-readable version comparisons for those versions that already exist, v3.x.x might be a good time to deal with the fact that in a few years there will likely be an OpenSSL 10.x.x. A product name like SSL0300 for a release based on OpenSSL 3.0.x would have an obvious relationship to a product called SSL1013 and based on OpenSSL 10.13.x.
Simon Clubley
2019-04-29 17:30:03 UTC
Permalink
Post by Craig A. Berry
While it will probably throw a wrench into human-readable version
comparisons for those versions that already exist, v3.x.x might be a good
time to deal with the fact that in a few years there will likely be an
OpenSSL 10.x.x. A product name like SSL0300 for a release based on OpenSSL
3.0.x would have an obvious relationship to a product called SSL1013 and
based on OpenSSL 10.13.x.
I agree.

In fact, all VMS kits based around open source products should just use
the open source product version number as part of the kit name instead
of making up a version number that is VMS specific.

Having VMS specific version numbers for open source products is just
yet another source of confusion that simply does not need to exist.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Craig A. Berry
2019-04-29 18:30:54 UTC
Permalink
Post by Simon Clubley
Post by Craig A. Berry
While it will probably throw a wrench into human-readable version
comparisons for those versions that already exist, v3.x.x might be a good
time to deal with the fact that in a few years there will likely be an
OpenSSL 10.x.x. A product name like SSL0300 for a release based on OpenSSL
3.0.x would have an obvious relationship to a product called SSL1013 and
based on OpenSSL 10.13.x.
I agree.
In fact, all VMS kits based around open source products should just use
the open source product version number as part of the kit name instead
of making up a version number that is VMS specific.
Having VMS specific version numbers for open source products is just
yet another source of confusion that simply does not need to exist.
I agree, but I'm actually talking about product names not version numbers. If you want to simultaneously support two different versions that are not binary compatible with each other, you need different product names and they need to appear not just in the kit names but also in the filenames of whatever libraries end up in sys$share or sys$library, not to mention system-level logical names.
Arne Vajhøj
2019-04-30 01:53:39 UTC
Permalink
Post by Craig A. Berry
Post by Simon Clubley
Post by Craig A. Berry
While it will probably throw a wrench into human-readable version
comparisons for those versions that already exist, v3.x.x might be a good
time to deal with the fact that in a few years there will likely be an
OpenSSL 10.x.x. A product name like SSL0300 for a release based on OpenSSL
3.0.x would have an obvious relationship to a product called SSL1013 and
based on OpenSSL 10.13.x.
In fact, all VMS kits based around open source products should just use
the open source product version number as part of the kit name instead
of making up a version number that is VMS specific.
Having VMS specific version numbers for open source products is just
yet another source of confusion that simply does not need to exist.
I agree, but I'm actually talking about product names not version
numbers. If you want to simultaneously support two different versions
that are not binary compatible with each other, you need different
product names and they need to appear not just in the kit names but also
in the filenames of whatever libraries end up in sys$share or
sys$library, not to mention system-level logical names.
This is only a problem if products insist on dumping their stuff
into the operating systems structure.

Very common across operating systems.

But still a bad idea in my opinion.

Arne
Craig A. Berry
2019-04-30 03:01:15 UTC
Permalink
Post by Arne Vajhøj
Post by Craig A. Berry
Post by Simon Clubley
Post by Craig A. Berry
While it will probably throw a wrench into human-readable version
comparisons for those versions that already exist, v3.x.x might be a good
time to deal with the fact that in a few years there will likely be an
OpenSSL 10.x.x.  A product name like SSL0300 for a release based on
OpenSSL
3.0.x would have an obvious relationship to a product called SSL1013 and
based on OpenSSL 10.13.x.
In fact, all VMS kits based around open source products should just use
the open source product version number as part of the kit name instead
of making up a version number that is VMS specific.
Having VMS specific version numbers for open source products is just
yet another source of confusion that simply does not need to exist.
I agree, but I'm actually talking about product names not version
numbers. If you want to simultaneously support two different versions
that are not binary compatible with each other, you need different
product names and they need to appear not just in the kit names but also
in the filenames of whatever libraries end up in sys$share or
sys$library, not to mention system-level logical names.
This is only a problem if products insist on dumping their stuff
into the operating systems structure.
Very common across operating systems.
But still a bad idea in my opinion.
It certainly has its problems, but without a common, canonical location,
configure scripts would not know where to find the library to link
against it. Of course they then have to examine the headers and see
what version they've got and whether it's compatible with the package
being built.

Having to handle multiple, incompatible versions of the same package is
kind of a mess any way you slice it. Here's something I recently
encountered on a RHEL system:

$ which java
/usr/bin/java
$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Apr 22 15:20 /usr/bin/java ->
/etc/alternatives/java
$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 73 Apr 22 15:20 /etc/alternatives/java ->
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64/jre/bin/java

So there's double indirection via two symlinks from the canonical
location of the java binary to the actual location. This system only
has one version of java installed, but if there were more than one, I
could use the "alternatives" program to fiddle with the intermediate
symlink and enable a different version. Except the installation
processing of a lot of things that depend on Java follows the symlinks
and hard-codes the actual java binary locations in the start-up scripts,
which tends to break something even when you just do a minor update.

Compared to that, choosing between running SYS$STARTUP:SSL$STARTUP or
SYS$STARTUP:SSL1$STARTUP and then following the OPENSSL logical name
doesn't seem especially worse than what everyone else does.
Arne Vajhøj
2019-04-30 23:27:31 UTC
Permalink
Post by Craig A. Berry
Post by Arne Vajhøj
Post by Craig A. Berry
I agree, but I'm actually talking about product names not version
numbers. If you want to simultaneously support two different versions
that are not binary compatible with each other, you need different
product names and they need to appear not just in the kit names but also
in the filenames of whatever libraries end up in sys$share or
sys$library, not to mention system-level logical names.
This is only a problem if products insist on dumping their stuff
into the operating systems structure.
Very common across operating systems.
But still a bad idea in my opinion.
It certainly has its problems, but without a common, canonical location,
configure scripts would not know where to find the library to link
against it.
I would suggest the developer decide what library to link against.
Post by Craig A. Berry
Having to handle multiple, incompatible versions of the same package is
kind of a mess any way you slice it.  Here's something I recently
$ which java
/usr/bin/java
$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Apr 22 15:20 /usr/bin/java ->
/etc/alternatives/java
$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 73 Apr 22 15:20 /etc/alternatives/java ->
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64/jre/bin/java
So there's double indirection via two symlinks from the canonical
location of the java binary to the actual location.  This system only
has one version of java installed, but if there were more than one, I
could use the "alternatives" program to fiddle with the intermediate
symlink and enable a different version.  Except the installation
processing of a lot of things that depend on Java follows the symlinks
and hard-codes the actual java binary locations in the start-up scripts,
which tends to break something even when you just do a minor update.
That is also fucked up.

/allmyjavaversions/jdk1.8.0_182/bin/java
/allmyjavaversions/jdk-11.0.2/bin/java
etc.

works fine.

And again I want the sysadm to decide what Java version to use.
Post by Craig A. Berry
Compared to that, choosing between running SYS$STARTUP:SSL$STARTUP or
SYS$STARTUP:SSL1$STARTUP and then following the OPENSSL logical name
doesn't seem especially worse than what everyone else does.
True.

The situation is approx. the same across VMS, Linux and Windows.

Arne
Stephen Hoffman
2019-05-01 00:06:00 UTC
Permalink
Post by Arne Vajhøj
The situation is approx. the same across VMS, Linux and Windows.
https://nixos.org/nix/ — "You can have multiple versions or variants
of a package installed at the same time. This is especially important
when different applications have dependencies on different versions of
the same package — it prevents the “DLL hell”. Because of the hashing
scheme, different versions of a package end up in different paths in
the Nix store, so they don’t interfere with each other." Etc.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2019-05-01 22:26:53 UTC
Permalink
Post by Arne Vajhøj
The situation is approx. the same across VMS, Linux and Windows.
https://nixos.org/nix/  — "You can have multiple versions or variants of
a package installed at the same time. This is especially important when
different applications have dependencies on different versions of the
same package — it prevents the “DLL hell”. Because of the hashing
scheme, different versions of a package end up in different paths in the
Nix store, so they don’t interfere with each other."  Etc.
There are typical plenty of technical solutions for the problem.

But they are not commonly used.

Arne
Neil Rieck
2019-05-02 11:15:44 UTC
Permalink
Just thought I'd toss in my own 2-cents on the OpenSSL issue as well.

I've been playing with WASD HTTPd v11.3 as a drop in replacement for CSWS-2.2-1

First off, WASD is a hackers delight because it is published with all the source code. If you have a DEC-C compiler then you will be able to support yourself if need be.

Secondly, during the install (you are given the choice of "just linking" or "compile then link") you will be prompted for five OpenSSL options depending upon what you've already got installed on your system. For example WASD can link against its own SSL library, or HP-SSL1 (OpenSSL 1.0 and higher) or HP-SSL (OpenSSL 0.9 and lower) although this last step is disabled by default when HP-SSL1 is present. How cool is that!

Last but not least, WASD HTTPd is the fastest web server in my shop. Although I'm running WASD on an old rx2600 (8 CPUs, 16 GB of RAM), it is faster than CSWS-2.2-1 on my rx2800-i2 (8 CPUs, 64 GB of RAM) as well as Apache 2.4 under CentOS-7 on my DL385p-gen8 (24 CPUs, 132 GB of RAM).

Now I haven't (yet) done full-load testing of WASD, but it appears get its speed from doing a lot of caching to avoid disk i/o -AND- does not be using the pre-fork model seen in CSWS on OpenVMS-8.4 or Apache 2.4 on CentOS-7

Comment: I've done at least a half-dozen installs of CentOS which included Apache by default. I do not recall ever being asked to choose between pre-fork or something else. And yet, all the Apache self-help sites tell you not to use pre-fork. Go figure!

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net/docs/openvms_notes_wasd.html
Jan-Erik Söderholm
2019-05-02 12:25:24 UTC
Permalink
Post by Neil Rieck
Just thought I'd toss in my own 2-cents on the OpenSSL issue as well.
I've been playing with WASD HTTPd v11.3 as a drop in replacement for CSWS-2.2-1
First off, WASD is a hackers delight because it is published with all
the source code. If you have a DEC-C compiler then you will be able to
support yourself if need be.
Secondly, during the install (you are given the choice of "just linking"
or "compile then link") you will be prompted for five OpenSSL options
depending upon what you've already got installed on your system. For
example WASD can link against its own SSL library,
Based on OpenSL 1.1.1 and last release/update was 15-Mar-2019.
There is also a OpenSSL 1.0.2r on the WASD page...
Post by Neil Rieck
or HP-SSL1 (OpenSSL 1.0 and higher)
Seems to be HPE SSL1 1.0-2G based on OpenSSL 1.0.2g (?).
Post by Neil Rieck
or HP-SSL (OpenSSL 0.9 and lower) although this last
step is disabled by default when HP-SSL1 is present. How cool is that!
Last but not least, WASD HTTPd is the fastest web server in my shop.
Not only fast, it is rock-solid. After install and config (apart from later
configs for new function) it just starts at boot and runs to shutdown.
Post by Neil Rieck
Although I'm running WASD on an old rx2600 (8 CPUs, 16 GB of RAM), it is
faster than CSWS-2.2-1 on my rx2800-i2 (8 CPUs, 64 GB of RAM) as well as
Apache 2.4 under CentOS-7 on my DL385p-gen8 (24 CPUs, 132 GB of RAM).
Now I haven't (yet) done full-load testing of WASD, but it appears get
its speed from doing a lot of caching to avoid disk i/o -AND- does not
be using the pre-fork model seen in CSWS on OpenVMS-8.4 or Apache 2.4 on
CentOS-7
Comment: I've done at least a half-dozen installs of CentOS which
included Apache by default. I do not recall ever being asked to choose
between pre-fork or something else. And yet, all the Apache self-help
sites tell you not to use pre-fork. Go figure!
Neil Rieck Waterloo, Ontario, Canada.
http://neilrieck.net/docs/openvms_notes_wasd.html
Stephen Hoffman
2019-05-02 15:16:26 UTC
Permalink
Local operating assumption: Install-time questions are to be avoided.
Install-time questions usually means the developer either couldn't
answer a question and couldn't figure out how to eliminate the
question, or didn't want to answer a question and didn't want to
consider why. Or wanted to ask questions to show off. Among the
various things that PCSI—the most recent OpenVMS platform package
installer—did right here, it made asking questions of the installer
more difficult. If there are questions that cannot be answered at
install time, provide a configuration tool. And gather what data you
can from the local environment and local network services, whether it's
from mDNS or DHCP or NTP or otherwise. Yeah, OpenVMS isn't good at any
of that. And it'd be very handy if there were standardized profiles
and configuration files and tools available here, so that the
installation deployment and configuration process can be automated,
when there are questions or customizations required. With OpenVMS, we
all either end up writing that ourselves, and often differently. Or
making automated and faster deployments more difficult.
Post by Neil Rieck
Just thought I'd toss in my own 2-cents on the OpenSSL issue as well.
I've been playing with WASD HTTPd v11.3 as a drop in replacement for CSWS-2.2-1
First off, WASD is a hackers delight because it is published with all
the source code. If you have a DEC-C compiler then you will be able to
support yourself if need be.
Apache source code is also available, and both HPE and VSI have made
source code of the ports available. Downside: OpenVMS C hasn't tracked
that of other platforms, so the ports tend to be more complex. VSI is
on a path to fix that, starting with Clang and LLVM support. There's
rather more past that, and hopefully the existing OpenVMS C RTL is
eventually relegated to use by unmaintained applications. There are
far too many layers of backward-compatibility clogging the existing
environment.
Post by Neil Rieck
Secondly, during the install (you are given the choice of "just
linking" or "compile then link") you will be prompted for five OpenSSL
options depending upon what you've already got installed on your
system. For example WASD can link against its own SSL library, or
HP-SSL1 (OpenSSL 1.0 and higher) or HP-SSL (OpenSSL 0.9 and lower)
although this last step is disabled by default when HP-SSL1 is present.
How cool is that!
How about installs with no questions at all? That's cool. That's the
best. For this case, probably with an embedded OpenSSL or libtls or
libsodium kit, though this presumes there'll be upgrades to that
support and thus some provisions are necessary for upgrades.

Now if somebody wants (needs) linkages against some other crypto
library, allow that after the install, and instrument that to see how
many folks use it as a foundation for adding or removing encryption
support, or for removing the feature entirely.

And I'm skeptical around needing changes here, if the crypto libraries
are kept current.

https://www.libressl.org
https://github.com/jedisct1/libsodium
etc.

Biggest reason to provide that variant support on OpenVMS has been a
bad trade-off between longstanding issues with old vendor SSL
libraries, and the time and effort involved in maintaining app-specific
libraries. OpenVMS is unfortunately missing a number of common
libraries, and the pace of change here makes keeping the dependencies
current more effort, whether that cost is at the vendor or at the
developer. And the crypto has been lagging, both with the OpenSSL
library and with the embedded SSL within various versions of Apache.
Post by Neil Rieck
Last but not least, WASD HTTPd is the fastest web server in my shop.
Although I'm running WASD on an old rx2600 (8 CPUs, 16 GB of RAM), it
is faster than CSWS-2.2-1 on my rx2800-i2 (8 CPUs, 64 GB of RAM) as
well as Apache 2.4 under CentOS-7 on my DL385p-gen8 (24 CPUs, 132 GB of
RAM).
Now I haven't (yet) done full-load testing of WASD, but it appears get
its speed from doing a lot of caching to avoid disk i/o -AND- does not
be using the pre-fork model seen in CSWS on OpenVMS-8.4 or Apache 2.4
on CentOS-7
It'd be interesting to try that against a tuned Apache HTTP Server
2.4-39 on VSI OpenVMS. Also against nginx on CentOS, if running a
comparison. Apache has never been particularly fast. It is, however,
extremely common.
Post by Neil Rieck
Comment: I've done at least a half-dozen installs of CentOS which
included Apache by default. I do not recall ever being asked to choose
between pre-fork or something else. And yet, all the Apache self-help
sites tell you not to use pre-fork. Go figure!
The worker MPM is necessary when some part of your Apache module
environment isn't thread-safe, and prefork MPM is the choice when your
Apache module environment is thread-safe. If the default Apache
install is thread-safe, then there's no reason to ask a question.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2019-04-30 15:50:05 UTC
Permalink
Post by Craig A. Berry
I agree, but I'm actually talking about product names not version
numbers. If you want to simultaneously support two different versions
that are not binary compatible with each other, you need different
product names and they need to appear not just in the kit names but
also in the filenames of whatever libraries end up in sys$share or
sys$library, not to mention system-level logical names.
This is only a problem if products insist on dumping their stuff into
the operating systems structure.
Very common across operating systems.
But still a bad idea in my opinion.
OpenVMS itself encourages the scatter-shot installation misbehavior,
requiring logical names if the message file and shareable images and
whatnot are to be isolated from a bespoke bundle. Wouldn't surprise
me to see VSI start to take a few swings at this and related problems,
at least for themselves and their layered products, and sometime after
the port is available.

As for OpenSSL, one of the few precedents for installing parallel
versions—and one of the few that works—is multi-version Rdb. There's
little (no?) documentation on what's involved with that too, and it's
easy to get it wrong.

And as for OpenSSL, the API changes are almost certainly going to
continue, which means we re-code and update our apps for those and/or
migrate to a VSI or third-party API. Or we embed the required versions
in the app directory, which is probably where we're headed. Downside
of embedding OpenSSL or other dependencies: chasing individual app
updates because of vulnerabilities in the OpenSSL or other
dependencies. Which means that easier and more automated and faster
patch notification and update notification and patch and update
application paths are necessary.

For those folks that haven't seen what can be available for maintaining
and updating apps: https://sparkle-project.org

We ain't headed back to the era of small disks or infrequent updates or
limited vulnerabilities. We have what we have. And we have the trends
we have. And the treadmill we're all on around patches and upgrades is
only going to accelerate.

ps: "There are only two hard things in Computer Science: cache
invalidation, naming things, and off-by-one errors."
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2019-04-30 20:20:21 UTC
Permalink
Post by Stephen Hoffman
As for OpenSSL, one of the few precedents for installing parallel
versions—and one of the few that works—is multi-version Rdb.  There's
little (no?) documentation on what's involved with that too, and it's easy
to get it wrong.
A slightly unnecessary and mostly wrong comment.

The Install and Config Guide:

http://download.oracle.com/otndocs/products/rdb/pdf/rdb073_install_guide.pdf

has these chapters:

2.3 Overview of Multiple−Version Support in Oracle Rdb
2.4 Accessing Multiple Versions of Oracle Rdb
2.5 How Applications Access Multiple Versions of Oracle Rdb
3.14 Deleting Versions of Oracle Rdb

I have used only Rdb multiversion kits since they was introduced,
I think it was 4.1 or 4.2, and the "standard" (non-multi-version)
kit was removed from 7.1, and I have never had any issues.

One single line in the script where you start Rdb at boot and
that is the default for the whole system after that.

$ @SYS$LIBRARY:RDB$SETVER 7.3 /SYSTEM

And one line in your system wide SYLOGIN.COM (does not have to be
changed if you still want all users to use the system default):

$ @SYS$LIBRARY:RDB$SETVER RESET

For specific needs you can easily establish the right environment.

You can get *anything* wrong, but *this* is not hard to get right.
Stephen Hoffman
2019-04-30 23:06:37 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Stephen Hoffman
As for OpenSSL, one of the few precedents for installing parallel
versions—and one of the few that works—is multi-version Rdb.  There's
little (no?) documentation on what's involved with that too, and it's
easy to get it wrong.
A slightly unnecessary and mostly wrong comment.
I referenced multi-version Rdb as an example of an installer that
allows multiple versions.

Rdb is certainly an example of an installer that permits parallel
installations.

Rdb does arrive with documentation of how to install Rdb, too.

Rdb does not arrive with documentation around how to *construct* a
multi-version installation kit, whether Rdb or otherwise.

You have pointed to some documentation for a kit that I had
acknowledged as a multi-version kit, and a design that works pretty
well.

However, you did not reference design and implementation documentation
for a multi-version kit, whether PCSI or VMSINSTAL or otherwise.

Distinct from Rdb, there's ample evidence that there have been folks
creating kits have tried and have encountered issues with their
designs, too.

Yes, in the absence of design and implementation documentation, having
some familiarity with an example is valuable.

There's a hole here in the OpenVMS kitting documentation.

There's are related holes in the OpenVMS application design
documentation around supporting upgrades in our apps, supporting
cluster rolling upgrades in our apps, and better supporting app
availability.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2019-05-01 10:57:50 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Stephen Hoffman
As for OpenSSL, one of the few precedents for installing parallel
versions—and one of the few that works—is multi-version Rdb.  There's
little (no?) documentation on what's involved with that too, and it's
easy to get it wrong.
A slightly unnecessary and mostly wrong comment.
I referenced multi-version Rdb as an example of an installer that allows
multiple versions.
Rdb is certainly an example of an installer that permits parallel
installations.
Rdb does arrive with documentation of how to install Rdb, too.
Rdb does not arrive with documentation around how to *construct* a
multi-version installation kit, whether Rdb or otherwise.
.......
OK. I read your post as there was something missing in the Rdb docs
on how to configure and use the Rdb MV kits. Rdb MV works just fine,
as you also noted. Fine then. Maybe someone else also misread your
post and got that right...
Craig A. Berry
2019-05-30 18:47:12 UTC
Permalink
Post by Craig A. Berry
Post by d***@aol.com
OpenSSL 1.1.1(b) kits have been developed and will be released soon
(TLS V1.3 support). The product name will likely be SSL111 and maintain
the same install structure as SSL1 (separate directory trees for co-existence).
SSL11 would make more sense than SSL111 in that it preserves those
parts (and only those parts) of the version number indicating a
binary compatible release. There may never be a 1.1.2, but if there
is, it will be binary compatible with 1.1.1, so no need for a new
product name.
Oh well, I tried. They just released it and the product name is indeed
SSL111. So eventually we'll be going cross-eyed over things like
version V1.1-2C of a product named SSL111.
Post by Craig A. Berry
While it will probably throw a wrench into human-readable version
comparisons for those versions that already exist, v3.x.x might be a
good time to deal with the fact that in a few years there will likely
be an OpenSSL 10.x.x. A product name like SSL0300 for a release
based on OpenSSL 3.0.x would have an obvious relationship to a
product called SSL1013 and based on OpenSSL 10.13.x.
I'm revising this advice slightly (not that it's any more likely to be
followed than my advice above) based on the fact that beginning with
OpenSSL 3.0.0, all versions sharing a major version number will be
binary compatible. So a product name of SSL03 would be sufficient for
everything in the 3.x.x series.
Stephen Hoffman
2019-06-03 16:13:31 UTC
Permalink
Post by Craig A. Berry
Oh well, I tried. They just released it and the product name is
indeedSSL111. So eventually we'll be going cross-eyed over things like
version V1.1-2C of a product named SSL111.
...
Post by Craig A. Berry
I'm revising this advice slightly (not that it's any more likely to be
followed than my advice above) based on the fact that beginning with
OpenSSL 3.0.0, all versions sharing a major version number will be
binary compatible. So a product name of SSL03 would be sufficient for
everything in the 3.x.x series.
Multiple parallel kits works better when the goal is to minimal changes
with some possibility of coexistence and incremental migration. This
is what I've previously suggested, too.

But I've rethought what I was suggesting here a while back, too. Ship
a TLS patch kit with all of the latest of the currently-supported TLS
versions—the two or three or whatever that are actively seeing OpenSSL
patches—and that removes the unsupported versions, and whatever
TLS-related changes are needed in the OpenVMS-specific TLS framework
that abstracts the changes in the OpenSSL APIs.

This as part of integrating IP networking and security, integrate
certificates, replacing and deprecating CDSA, etc. And part of keeping
that security current, particularly since OpenVMS claims to be "the
most secure operating system on the planet".

An omnibus kit that also deprecates and eventually removes the
unsupported OpenSSL releases will cause some grief for some app
developers and some sites. The TLS API provides a path for some of
those to migrate, and better handling around encryption, and around
writing a network server without having to deal (as much) with IPv4 and
IPv6 and certificates and DNS and the rest. The rest of the folks want
or need to be insecure and down-revision and for whatever reason, and
can find and integrate their own OpenSSL kits.

Down-revision and backward-compatibility? I really don't care why
those of y'all want or need to run down-revision and variously fossil
software, y'all have your reasons. I've heard most of those reasons
too, and you're probably not special. Whether you've accepted or
ignored or mitigated the associated risks, your down-revision needs
should not degrade the security of the rest of the folks and of those
developers that are keeping apps current. There's no transparent
upgrade path here short of the addition of a TLS API, and there'll be
folks that can't or won't upgrade to and migrate to that, and for
whatever reason. We're on a treadmill of upgrades, whether any of us
wants to be. But I digress.

This all assumes there's to be more of an investment in security and of
keeping SSL current, and around adding (better) support for calls from
the descriptor-oriented programming languages. Otherwise, we get what
we have: parallel OpenSSL kits for three and potentially more releases.
In a yet better world, OpenVMS logs first-use and then periodic
(monthly?) message about apps using deprecated and insecure APIs, too.
There are a number of folks that just don't know or don't realize
they're using insecure constructs.

But....

If the associated investment around security is to continue to be
delegated to the apps and the ISVs as is currently the case, then
parallel kits. Craig's proposed naming seems reasonable for that.
Though this current approach is going to be yet another round of
permutations and complexity; of kicking the costs to the system
administration ("manager") and to the ISVs and developers.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2019-06-03 23:21:18 UTC
Permalink
Post by Stephen Hoffman
Post by Craig A. Berry
Oh well, I tried. They just released it and the product name is
indeedSSL111. So eventually we'll be going cross-eyed over things
like version V1.1-2C of a product named SSL111.
...
Post by Craig A. Berry
I'm revising this advice slightly (not that it's any more likely to be
followed than my advice above) based on the fact that beginning with
OpenSSL 3.0.0, all versions sharing a major version number will be
binary compatible. So a product name of SSL03 would be sufficient for
everything in the 3.x.x series.
Multiple parallel kits works better when the goal is to minimal changes
with some possibility of coexistence and incremental migration. This is
what I've previously suggested, too.
But I've rethought what I was suggesting here a while back, too. Ship a
TLS patch kit with all of the latest of the currently-supported TLS
versions—the two or three or whatever that are actively seeing OpenSSL
patches—and that removes the unsupported versions, and whatever
TLS-related changes are needed in the OpenVMS-specific TLS framework
that abstracts the changes in the OpenSSL APIs.
This as part of integrating IP networking and security, integrate
certificates, replacing and deprecating CDSA, etc. And part of keeping
that security current, particularly since OpenVMS claims to be "the most
secure operating system on the planet".
An omnibus kit that also deprecates and eventually removes the
unsupported OpenSSL releases will cause some grief for some app
developers and some sites. The TLS API provides a path for some of
those to migrate, and better handling around encryption, and around
writing a network server without having to deal (as much) with IPv4 and
IPv6 and certificates and DNS and the rest. The rest of the folks want
or need to be insecure and down-revision and for whatever reason, and
can find and integrate their own OpenSSL kits.
Down-revision and backward-compatibility? I really don't care why those
of y'all want or need to run down-revision and variously fossil
software, y'all have your reasons. I've heard most of those reasons too,
and you're probably not special. Whether you've accepted or ignored or
mitigated the associated risks, your down-revision needs should not
degrade the security of the rest of the folks and of those developers
that are keeping apps current. There's no transparent upgrade path here
short of the addition of a TLS API, and there'll be folks that can't or
won't upgrade to and migrate to that, and for whatever reason. We're on
a treadmill of upgrades, whether any of us wants to be. But I digress.
This all assumes there's to be more of an investment in security and of
keeping SSL current, and around adding (better) support for calls from
the descriptor-oriented programming languages. Otherwise, we get what
we have: parallel OpenSSL kits for three and potentially more releases.
In a yet better world, OpenVMS logs first-use and then periodic
(monthly?) message about apps using deprecated and insecure APIs, too.
There are a number of folks that just don't know or don't realize
they're using insecure constructs.
But....
If the associated investment around security is to continue to be
delegated to the apps and the ISVs as is currently the case, then
parallel kits. Craig's proposed naming seems reasonable for that.
Though this current approach is going to be yet another round of
permutations and complexity; of kicking the costs to the system
administration ("manager") and to the ISVs and developers.
First, I agree that the latest TLS/SSL should be provided.

I also feel that the interface to the product should be somehow
compatable rather than needing re-coding to use the newer stuff. Not
sure how easy that might be.

But, I'm going to ask, why remove older capabilities? Sure, it would be
best to not use them. But there will be some users that do not have a
choice, if they want to continue communicating with existing trading
partners. So, whynot some type of configuration tool that can set flags
as to which protocols should be allowed? Default it to TLS3, but allow
when necessary for older protocols to be allowed.

It's an imperfect world, but it's the one we must live in.

I could also mention that needed support, or lack thereof, would play
some part in selection or rejection of VMS for new users.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
d***@aol.com
2019-06-04 14:57:41 UTC
Permalink
"I also feel that the interface to the product should be somehow
compatable rather than needing re-coding to use the newer stuff. Not
sure how easy that might be. "

Easier said than done. Making internal structures opaque that were once directly visible and modifiable precludes forward compatibility.

Silo'd coexisting releases at least allow customers to continue to run their current applications until such time as they can, if ever, update their source code.

"So, whynot some type of configuration tool that can set flags
as to which protocols should be allowed? Default it to TLS3, but allow
when necessary for older protocols to be allowed."

The handshake does this now by connecting to the strongest protocol enabled by both sides. Applications can set options to limit which protocols are available during the handshake. For instance, you can restrict protocols to SSL3 and TLS1.3 and ignore the three TLS versions in between.
Stephen Hoffman
2019-06-06 03:09:30 UTC
Permalink
Post by d***@aol.com
"I also feel that the interface to the product should be
somehowcompatable rather than needing re-coding to use the newer stuff.
Notsure how easy that might be. "
Easier said than done. Making internal structures opaque that were once
directly visible and modifiable precludes forward compatibility.
Assuming folks call OpenSSL directly, quite correct.

Also welcome to why I've suggested wrapping the existing APIs.

I've previously released a descriptor-friendly set of wrappers for
OpenVMS and OpenSSL. That wrapper API could undoubtedly be done better
than what I designed, too. But it works. I'm aware of and have
previously linked to other wrappers for other platforms.

Welcome to why I keep grumbling about upward compatibility and the
inherent conflicts with fixing stuff and deprecating older APIs, too.
Post by d***@aol.com
Silo'd coexisting releases at least allow customers to continue to run
their current applications until such time as they can, if ever, update
their source code.
"So, whynot some type of configuration tool that can set flagsas to
which protocols should be allowed? Default it to TLS3, but allowwhen
necessary for older protocols to be allowed."
The handshake does this now by connecting to the strongest protocol
enabled by both sides. Applications can set options to limit which
protocols are available during the handshake. For instance, you can
restrict protocols to SSL3 and TLS1.3 and ignore the three TLS versions
in between.
Or with a wrapper, let that deal with selecting the requisite TLS
settings and the other details of the various OpenSSL APIs—preferably
also dealing with DNS and sockets and certificates and related baggage,
and preferably AST- or KP-friendly—and allow the wrapper to upgrade
connection security as newer implementations are available and/or as
older implementations become vulnerable.

ps: If I don't ever have to deal with another nonce in my
encryption-related code again, it'll be too soon...
https://eprint.iacr.org/2019/624
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2019-06-06 14:19:20 UTC
Permalink
Post by Stephen Hoffman
Post by d***@aol.com
"I also feel that the interface to the product should be
somehowcompatable rather than needing re-coding to use the newer
stuff.  Notsure how easy that might be. "
Easier said than done. Making internal structures opaque that were
once directly visible and modifiable precludes forward compatibility.
Assuming folks call OpenSSL directly, quite correct.
Also welcome to why I've suggested wrapping the existing APIs.
I've previously released a descriptor-friendly set of wrappers for
OpenVMS and OpenSSL.  That wrapper API could undoubtedly be done better
than what I designed, too.  But it works.  I'm aware of and have
previously linked to other wrappers for other platforms.
OpenSSL actually comes with an abstraction: BIO.

BIO handle plain sockets, SSL sockets and disk files transparently.

It is a C API and I don't think it is widely used.

But it does exist.

Arne

Stephen Hoffman
2019-06-04 23:31:45 UTC
Permalink
Post by Dave Froble
First, I agree that the latest TLS/SSL should be provided.
I also feel that the interface to the product should be somehow
compatable rather than needing re-coding to use the newer stuff. Not
sure how easy that might be.
This goes well past TLS, too. There's a whole pile of drudge work here,
and developers are increasingly being provided with frameworks for
these tasks.

For not the first time, yes, it is possible to do all of this in
bespoke app code—and variously either incompletely, or with errors—but
that's not where we're headed.
Post by Dave Froble
But, I'm going to ask, why remove older capabilities? Sure, it would
be best to not use them. But there will be some users that do not have
a choice, if they want to continue communicating with existing trading
partners. So, whynot some type of configuration tool that can set
flags as to which protocols should be allowed? Default it to TLS3, but
allow when necessary for older protocols to be allowed.
For various of these cases both involving OpenSSL and those beyond
OpenSSL, and in no particular order...

... all code has support costs, whether that code is used or supported
or not. Building, packaging, storage, kitting, installations, testing,
etc.
... unsupported code still has bugs. Unsupported security code has known bugs.
... folks that are not maintaining and are not updating their code are
the wrong end of the market. The folks that are not integrating with
and not networking with other systems is getting ever smaller.
... old and unsupported code can have API problems and constraints and
incompatibilities, and can constrain updates.
... more than a few OpenVMS sites have no idea what's secure and what's
not, and look to the folks maintaining "the most secure operating
system on the planet" for guidance and suggestions.
... economics. VSI can't do everything for everybody. Where there are
problems, start by creating and then migrating folks to better APIs.
Deprecate and eventually remove the worst and most problematic.

For this particular case, folks using old releases and old features can
lock in and hope it'll all keep working and as many (most?) do, or they
can fix and maintain their code if they want or need current versions
and support and they can then install a free OpenSSL kit and maintain
it themselves, or possibly use an add-on and extra-cost OpenSSL kit.

Why deprecate and eventually remove? Various reasons around the older
OpenSSL TLS bits: the older approaches are insecure. They're
fundamentally broken. More than a few users don't know this or don't
recognize this, and it's incumbent on VSI to guide OpenVMS developers
and end-users forward as part of the VSI "the most secure operating
system on the planet" marketing efforts. Preserving the older
approaches and older APIs variously also limit the range and scope of
enhancements and upgrades possible.

I really like compatibility. In theory. But that compatibility can be
far more costly and far more constraining than many realize. And it's
just not possible to fit sixteen or thirty-two bytes into an eight byte
buffer. I'd prefer the development focus on newer bits and newer
updates than on preserving APIs and designs for code that isn't being
maintained.

In practice, complete upward-compatibility is increasingly incompatible
with the future sales and future usefulness of a product, and
incompatible with the level of development effort that can be expended
and where and what, and with what the folks that are keeping current
and are maintaining their products need and want. Some old APIs have
to be retired and removed, preferably with migration paths and/or with
better replacements available.

I'd hope that VSI would prefer to steer user expectations away from
some of the more problematic DEC ideas. VSI and OpenVMS users can
either have a focus on better APIs and features and retiring what's
known problematic, or a focus on existing and old apps and on
increasingly convoluted APIs and increasingly hostile designs and
absurd defaults. DEC focused on the latter—on compatibility—at the
expense of the former—on usability, clear APIs, good defaults, current
tooling, etc. Based on what I've seen if it, the latter approach is
also a long-term declining market, too.

There's no right answer here, and there are always trade-offs. If
y'all have a can't-ever-upgrade-something or
can't-ever-change-something installation, have at. Again, I've heard
just about every reason for that too, and I really don't care what
constraints or evaluations or other requirements you've gotten tangled
with. Figure out how to do that. Go do it. Whatever. But please
don't expect the rest of us using OpenVMS to want to cater to your
requirements, nor to want our maintenance and our new work and our new
apps and our development costs to be more expensive so that your
existing and old installations can make fewer or no changes. Or the
new apps and new deployments increasingly go elsewhere, and the whole
dealing-with-upgrade problems become moot.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2019-06-05 05:37:05 UTC
Permalink
Post by Stephen Hoffman
Post by Dave Froble
First, I agree that the latest TLS/SSL should be provided.
I also feel that the interface to the product should be somehow
compatable rather than needing re-coding to use the newer stuff. Not
sure how easy that might be.
This goes well past TLS, too. There's a whole pile of drudge work here,
and developers are increasingly being provided with frameworks for these
tasks.
For not the first time, yes, it is possible to do all of this in bespoke
app code—and variously either incompletely, or with errors—but that's
not where we're headed.
Post by Dave Froble
But, I'm going to ask, why remove older capabilities? Sure, it would
be best to not use them. But there will be some users that do not
have a choice, if they want to continue communicating with existing
trading partners. So, whynot some type of configuration tool that can
set flags as to which protocols should be allowed? Default it to
TLS3, but allow when necessary for older protocols to be allowed.
For various of these cases both involving OpenSSL and those beyond
OpenSSL, and in no particular order...
... all code has support costs, whether that code is used or supported
or not. Building, packaging, storage, kitting, installations, testing, etc.
... unsupported code still has bugs. Unsupported security code has known bugs.
... folks that are not maintaining and are not updating their code are
the wrong end of the market. The folks that are not integrating with
and not networking with other systems is getting ever smaller.
... old and unsupported code can have API problems and constraints and
incompatibilities, and can constrain updates.
... more than a few OpenVMS sites have no idea what's secure and what's
not, and look to the folks maintaining "the most secure operating system
on the planet" for guidance and suggestions.
... economics. VSI can't do everything for everybody. Where there are
problems, start by creating and then migrating folks to better APIs.
Deprecate and eventually remove the worst and most problematic.
For this particular case, folks using old releases and old features can
lock in and hope it'll all keep working and as many (most?) do, or they
can fix and maintain their code if they want or need current versions
and support and they can then install a free OpenSSL kit and maintain it
themselves, or possibly use an add-on and extra-cost OpenSSL kit.
Why deprecate and eventually remove? Various reasons around the older
OpenSSL TLS bits: the older approaches are insecure. They're
fundamentally broken. More than a few users don't know this or don't
recognize this, and it's incumbent on VSI to guide OpenVMS developers
and end-users forward as part of the VSI "the most secure operating
system on the planet" marketing efforts. Preserving the older
approaches and older APIs variously also limit the range and scope of
enhancements and upgrades possible.
I really like compatibility. In theory. But that compatibility can be
far more costly and far more constraining than many realize. And it's
just not possible to fit sixteen or thirty-two bytes into an eight byte
buffer. I'd prefer the development focus on newer bits and newer
updates than on preserving APIs and designs for code that isn't being
maintained.
In practice, complete upward-compatibility is increasingly incompatible
with the future sales and future usefulness of a product, and
incompatible with the level of development effort that can be expended
and where and what, and with what the folks that are keeping current and
are maintaining their products need and want. Some old APIs have to be
retired and removed, preferably with migration paths and/or with better
replacements available.
I'd hope that VSI would prefer to steer user expectations away from some
of the more problematic DEC ideas. VSI and OpenVMS users can either
have a focus on better APIs and features and retiring what's known
problematic, or a focus on existing and old apps and on increasingly
convoluted APIs and increasingly hostile designs and absurd defaults.
DEC focused on the latter—on compatibility—at the expense of the
former—on usability, clear APIs, good defaults, current tooling, etc.
Based on what I've seen if it, the latter approach is also a long-term
declining market, too.
There's no right answer here, and there are always trade-offs. If y'all
have a can't-ever-upgrade-something or can't-ever-change-something
installation, have at. Again, I've heard just about every reason for
that too, and I really don't care what constraints or evaluations or
other requirements you've gotten tangled with. Figure out how to do
that. Go do it. Whatever. But please don't expect the rest of us
using OpenVMS to want to cater to your requirements, nor to want our
maintenance and our new work and our new apps and our development costs
to be more expensive so that your existing and old installations can
make fewer or no changes. Or the new apps and new deployments
increasingly go elsewhere, and the whole dealing-with-upgrade problems
become moot.
You're missing the point. If a significant part of some companies
business is with a trading partner who will not upgrade their SSL
capabilities, and you have no way to get them to change, then, you do
what you have to do to stay in business.

Most of your arguments are good, but, when the alternatives are "stay in
business" or "go out of business", the choice is easy, at least for me.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Phillip Helbig (undress to reply)
2019-06-05 16:02:07 UTC
Permalink
Post by Dave Froble
You're missing the point. If a significant part of some companies
business is with a trading partner who will not upgrade their SSL
capabilities, and you have no way to get them to change, then, you do
what you have to do to stay in business.
Indeed. While I understand the purpose of both encryption and
authentication, many SSL implementations will refuse to connect if the
offered ciphers are deemed to be insecure, rather than having an option
(more common in web browsers) saying: "there is a problem, but if you
know what you are doing, you can continue". Without that option, SSL is
a non-starter if the other side is "too old", which is why some people
still run telnet. Even if the cypher is not up to date, it is still
better than no encryption, and at least there is authentication.
Bill Gunshannon
2019-06-05 16:33:20 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
You're missing the point. If a significant part of some companies
business is with a trading partner who will not upgrade their SSL
capabilities, and you have no way to get them to change, then, you do
what you have to do to stay in business.
Indeed. While I understand the purpose of both encryption and
authentication, many SSL implementations will refuse to connect if the
offered ciphers are deemed to be insecure, rather than having an option
(more common in web browsers) saying: "there is a problem, but if you
know what you are doing, you can continue". Without that option, SSL is
a non-starter if the other side is "too old", which is why some people
still run telnet. Even if the cypher is not up to date, it is still
better than no encryption, and at least there is authentication.
Having considerable experience with the subject at hand, I can
assure you that if the cypher is not up to date it is not better
than no encryption. It is the same as no encryption. The days
if security by obscurity should be long gone by this point.

bill
Simon Clubley
2019-06-05 17:54:11 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
You're missing the point. If a significant part of some companies
business is with a trading partner who will not upgrade their SSL
capabilities, and you have no way to get them to change, then, you do
what you have to do to stay in business.
Indeed. While I understand the purpose of both encryption and
authentication, many SSL implementations will refuse to connect if the
offered ciphers are deemed to be insecure, rather than having an option
(more common in web browsers) saying: "there is a problem, but if you
know what you are doing, you can continue". Without that option, SSL is
a non-starter if the other side is "too old", which is why some people
still run telnet. Even if the cypher is not up to date, it is still
better than no encryption, and at least there is authentication.
SSL has nothing to do with interactive command line communications;
you are thinking of SSH.

As for SSL, people go for more secure options because those are now
the required industry standards. That's why TLS 1.2 is now so commonly
required (for example) and why you may not be allowed to fall back to
TLS 1.0 (for example) to talk to that service/website.

Similar comments apply to SSH however. If an organisation is upgrading
their SSH requirements then they are unlikely to offer telnet as an
option because that would defeat the point of upgrading SSH.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2019-06-06 03:07:36 UTC
Permalink
Post by Dave Froble
You're missing the point. If a significant part of some companies
business is with a trading partner who will not upgrade their SSL
capabilities, and you have no way to get them to change, then, you do
what you have to do to stay in business.
Most of your arguments are good, but, when the alternatives are "stay
in business" or "go out of business", the choice is easy, at least for
me.
These companies that are both buying support and that are rolling out
OpenVMS and layered product upgrades, but that are also not
particularly maintaining their own code? That's not going to be a
growing market. Or one with much funding.

Given: OpenSSL isn't going to stop tweaking APIs with future releases.
Other products and other APIs will have similar issues, such as with
requiring particular and longer certificates.

Let those companies stay on older OpenVMS releases for the duration of
some hypothetical long-term-support LTS-style support offering. And
specifically with an old OpenSSL, these companies can't fix a flunked
audit without some app-level work, which means they're already well on
their way to maintenance or to outsourcing or to gone, or well on their
way to eventually flunking some audit or some review, and then funding
an upgrade or a port. Let these companies then figure out how to link
their own OpenSSL port. Or let these companies pay more for the older
OpenSSL. Either of these on the off chance these companies decide to
fund an upgrade or a port.

Preferably, give the folks a networking API that allows us to expunge
our pages and pages of existing IPv4 and IPv6 and DNS and TLS and
certificate-related code, as a path for folks needing SSL upgrades, and
as a foundation for new apps and for porting. And for better
capabilities and security. This also makes future software upgrades
somewhat easier, but there's a cost here to both VSI and to end-users.

Catering to the past at the expense of the present and of the future is
what got OpenVMS where it is now. I really don't think continuing
these practices can get OpenVMS where VSI and most of us want it to be,
either.

The economics have changed markedly over the years, the tech has
changed, the treadmill of upgrades is only going to accelerate, and VSI
and VSI customers are operating with fewer folks and smaller budgets.
VSI can't be everything for all. Not without a bigger and more vibrant
installed base. And how does VSI get to that? It won't be with
perpetual support of OpenSSL 0.9.8.7.6.5.4xyzzy.

Total upward-compatibility is an impossible dream. It trains folks to
dig in, and to want what is impossible. Some customer app code is
inevitably going to have to be tweaked. That's the world we're in. We
can't fit thirty-two bytes in an eight-byte buffer. Not without code
changes. Or you're not upgrading. Or the rest of us are losing out on
fixes and updates for the apps we are maintaining.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2019-04-08 15:25:41 UTC
Permalink
Post by Neil Rieck
The current version of CSWS for OpenVMS from HPE is based upon Apache 2.0.63
HPE is exiting the OpenVMS business, with new-patch support ending in
less than two years. I'd expect the HPE investments to taper over
time, too.
Post by Neil Rieck
The current version of CSWS for OpenVMS from VSI is based upon Apache
2.4.12 according to this link.
For not the first time I have stated this in this thread, the current
VSI CSWS Apache Web Server version is V2.4-38. If what is posted on
the VSI web site doesn't indicate that, what is posted is stale.
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by
VSI. If they had then I would not find myself in this dilemma; which is
why I'm experimenting with WASD.
Then keep records, and expect to toss the whole discussion back at your
management, as part of transitioning from HPE support to VSI support;
positioned as a one-time on-boarding fee or transition fee or whatever.
It'd be nice if the licensing could be buried in the support costs,
but that's not currently the case. The current VSI web site and the
VSI communications and the lack of a list price price list aren't
particularly helpful here, either.
Post by Neil Rieck
p.s. managers are always moving around. There is a high likelihood that
when dung-hits-the-fan next year, they'll be gone and I'll be blamed
for not having a workaround waiting in the wings. A career limiting
situation indeed.
I'm familiar with organizations that use "bungee bosses", and with the
energy and the effort entailed with bringing each new boss up to speed,
and with the organizational knock-off effects when a mix of good boss
and bad bosses transition through an organization, and how those
managers pick good and bad managers and staff. This managerial churn
can be quite challenging. Both for the staff, and for the up-or-out
policies that the managers themselves are generally measured by.
--
Pure Personal Opinion | HoffmanLabs LLC
Kerry Main
2019-05-19 20:32:30 UTC
Permalink
-----Original Message-----
Hoffman via Info-vax
Sent: April 8, 2019 11:26 AM
Subject: Re: [Info-vax] OpenSSL CSWS-2.2-1
Post by Neil Rieck
The current version of CSWS for OpenVMS from HPE is based upon Apache 2.0.63
HPE is exiting the OpenVMS business, with new-patch support ending in less
than two years. I'd expect the HPE investments to taper over time, too.
Post by Neil Rieck
The current version of CSWS for OpenVMS from VSI is based upon Apache
2.4.12 according to this link.
For not the first time I have stated this in this thread, the current VSI
CSWS
Apache Web Server version is V2.4-38. If what is posted on the VSI web
site
doesn't indicate that, what is posted is stale.
Post by Neil Rieck
We attempted to move support from HPE to VSI last year but our
management would not approve the purchase of software relicensing by
VSI. If they had then I would not find myself in this dilemma; which
is why I'm experimenting with WASD.
Then keep records, and expect to toss the whole discussion back at your
management, as part of transitioning from HPE support to VSI support;
positioned as a one-time on-boarding fee or transition fee or whatever.
It'd be nice if the licensing could be buried in the support costs, but
that's not
currently the case. The current VSI web site and the VSI communications
and
the lack of a list price price list aren't particularly helpful here,
either.
[snip..]

Also, remember to look at sockets on your Integrity servers to be
transitioned to VSI. Current Integrity OpenVMS licensing from both HPE and
VSI is based on the base OpenVMS prod license cost x # of sockets in that
server. I believe this change was implemented in OpenVMS V8.4 timeframe
(before this, it was core based pricing).

If you are using older pre-I2 or I2 servers with 4 sockets and total of 8
cores, then it might be worth buying a newer I4 or I6 server with 1 socket
(with fewer cores, keeping in mind much better core perf on I4/I6's)

Example - if an Integrity server total OpenVMS licenses costs $50K on a
single socket I4/I6 server, the same OpenVMS licensing will cost $200K on an
older 4 socket I2 server.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
s***@gmail.com
2019-05-16 10:26:54 UTC
Permalink
Post by Neil Rieck
Strictly as an emergency backup plan, I've been working on trial to replace CSWS-2.2-1 with WASD-11.
For example, if my ~1,200 clients begin to use new browsers next year, they might not be able to connect to my current system so I have got to do something now. But that got me thinking about another problem: we are receiving B2B SOAP transactions from a system in Montreal (another company) which currently relies on SSLv3. If I upgrade my web-server to something that doesn't offer SSLv3 (because it hasn't been compiled into Apache's mod_ssl, or I've linked WASD to an SSL library that is too restrictive) then I'm not going to be able to receive those B2B SOAP connections.
http://neilrieck.net/docs/calendar_time_y2k_etc.html#y2k20
Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
BRING BACK PURVEYOR :)
Arne Vajhøj
2019-03-14 21:08:18 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Neil Rieck
Everyone reading this already knows that HP (now HPE) used to provide
free updates for CSWS (a.k.a. Apache for OpenVMS) modules including SSL,
Java, PHP, etc. All of those web pages have been redirected to the
common OpenVMS landing page so I guess we can assume that those days are
over.
However, life goes on and I just learned that all major browsers are
going to disable TLS-1.0 and TLS-1.1 sometime in 2020. Here are a few
links which shine more light on the announcement.
 Now 2020 seems a long way off but web developers at my employer's
company are already seeing TLS-1.0 and TLS-1.1 warnings in the AJAX much
transport associated with "Developer Tools" in Chrome v73 so I suggest
that anyone with an OpenVMS support contract at HPE contact them for
support (previously they just send out a new version of file
"mod_ssl.exe"). I just filed a support request with them this morning.
Not that it helps CSWS much, but WASD got OpenSSL 1.1.1 (incl. TLS 1.3)
pre-support in May 2017 and the SSL 1.1.1 kit is from Nov 2018.
https://wasd.vsm.com.au/wasd_root/doc/misc/changes.html
https://wasd.vsm.com.au/wasd/
Makes me wonder.  How difficult is it to move existing stuff from Apache
to WASD?
Depends a lot on what the stuff is.

Static content : should be easy.

CGI scripts : probably easy.

Some very specific Apache modules : somewhere between hard and impossible

Arne
Bill Gunshannon
2019-03-14 17:43:14 UTC
Permalink
Post by Neil Rieck
Everyone reading this already knows that HP (now HPE) used to provide free updates for CSWS (a.k.a. Apache for OpenVMS) modules including SSL, Java, PHP, etc. All of those web pages have been redirected to the common OpenVMS landing page so I guess we can assume that those days are over.
However, life goes on and I just learned that all major browsers are going to disable TLS-1.0 and TLS-1.1 sometime in 2020. Here are a few links which shine more light on the announcement.
https://www.zdnet.com/article/chrome-edge-ie-firefox-and-safari-to-disable-tls-1-0-and-tls-1-1-in-2020/
https://www.cso.com.au/article/648261/tls-1-0-1-1-will-disabled-edge-ie-chrome-firefox-safari-2020/
https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls
Now 2020 seems a long way off but web developers at my employer's company are already seeing TLS-1.0 and TLS-1.1 warnings in the AJAX transport associated with "Developer Tools" in Chrome v73 so I suggest that anyone with an OpenVMS support contract at HPE contact them for support (previously they just send out a new version of file "mod_ssl.exe"). I just filed a support request with them this morning.
This is only peripherally related to VMS but it is a case of
the same effect. In talking about long term support (something
VMS is still claimed to have) it has been mentioned that MicroSoft
has sold longer term use of EOLed OSes like XP and Vista. Well,
being probably one of the last US users of either of these OSes
(mostly Vista!) I have run in to a similar problem as the one
stated above. None of the currently popular Web Browsers are
doing any versions for XP or Vista. What good is continued
vendor support of an OS if application support has been terminated?
Isn't this the same problem VMS users are going to start seeing
because of so much being so far behind the current standards of
the industry?

bill
Stephen Hoffman
2019-03-14 18:26:28 UTC
Permalink
Post by Neil Rieck
Everyone reading this already knows that HP (now HPE) used to provide
free updates for CSWS (a.k.a. Apache for OpenVMS) modules including
SSL, Java, PHP, etc. All of those web pages have been redirected to the
common OpenVMS landing page so I guess we can assume that those days
are over.
However, life goes on and I just learned that all major browsers are
going to disable TLS-1.0 and TLS-1.1 sometime in 2020.
Upgrade to VSI OpenVMS.

For not the first time this has been mentioned, HPE is exiting the
OpenVMS new-patch business at the end of 2020.

Or port at least the web front-end to a different platform with a more
current web server.

With TLSv1.3 now available, all TLS prior to TLSv1.2 is headed for scrap.

I'm already routinely encountering minimal SSL connections requirements
for TLSv1.2 for connections, and the deprecation of all earlier SSL/TLS
connections.

As for the SSL and SSL1 kits, the foundation of SSL1 is OpenSSL 1.0.2
(LTS) and that is end-of-life at the end of this year. AFAIK, neither
HPE nor VSI offer the current 1.1.1 release as yet.
https://www.openssl.org/policies/releasestrat.html

While discussing certs and security with HPE, check whether the secure
delivery certificates have been updated, too. (I don't have a
currently-patched HPE OpenVMS V8.4 server handy to check.) The
longstanding (current?) HPE public cert will expire at the end of 2028,
which means that PCSI PRODUCT INSTALL and VMSINSTAL will start to fail
then absent various workarounds, which means y'all have until the end
of 2020 when new-patches support ends to get HPE to re-issue the root
public cert. HPE and VSI both updated to higher-level security, but I
don't recall HPE having re-issued the secure delivery root public cert
with an extended date.
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Gunshannon
2019-03-14 19:04:05 UTC
Permalink
Post by Stephen Hoffman
Or port at least the web front-end to a different platform with a more
current web server.
But, that was my point exactly. I am being forced off of XP
and (mostly) Vista. I am not upgrading to Windows 7 or Windows
10. I am leaving Microsoft behind. (And recommending other
people do the same!!)

If a business is running on VMS and a major part of that business
is a web server front end and they have to move that front end to
a different platform where is the incentive to leave anything
still on the VMS system? I have worked with heterogeneous systems.
It ain't fun. Especially when something goes wrong and you have to
determine which platform is responsible (and I am not even talking
about the politics and finger pointing at the meeting tables!!)

bill
Dave Froble
2019-03-14 20:38:50 UTC
Permalink
Post by Bill Gunshannon
Post by Stephen Hoffman
Or port at least the web front-end to a different platform with a more
current web server.
But, that was my point exactly. I am being forced off of XP
and (mostly) Vista. I am not upgrading to Windows 7 or Windows
10. I am leaving Microsoft behind. (And recommending other
people do the same!!)
So what are you going to use? Specifically for the desktop?

I also do not like using WEENDOZE 7, and refuse to boot up 10.
Post by Bill Gunshannon
If a business is running on VMS and a major part of that business
is a web server front end and they have to move that front end to
a different platform where is the incentive to leave anything
still on the VMS system? I have worked with heterogeneous systems.
It ain't fun. Especially when something goes wrong and you have to
determine which platform is responsible (and I am not even talking
about the politics and finger pointing at the meeting tables!!)
What you do is design and implement the required interfaces. Not so
hard. It's even somewhat good to totally segregate some things. Easier
to determine where problems exist.

It's amusing to see the suggestions to "port". 40 years of specific
business logic just doesn't get re-implemented all that easily. Or
cheaply. Sort of tough to get a businessman to pay to re-implement
something he already has.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2019-03-15 12:05:18 UTC
Permalink
Post by Stephen Hoffman
Or port at least the web front-end to a different platform with a more
current web server.
But, that was my point exactly.  I am being forced off of XP
and (mostly) Vista.  I am not upgrading to Windows 7 or Windows
10.  I am leaving Microsoft behind. (And recommending other
people do the same!!)
So what are you going to use?  Specifically for the desktop?
My every day, workhorse desktop is Ubuntu. Been working fine since
the machine (running Vista) died about 3 years ago. I also have it
on a couple of my laptops. Have not found anything Windows did that
these can not do and a lot of things they can do that Windows could
not.
I also do not like using WEENDOZE 7, and refuse to boot up 10.
I refuse to pay any more money into the Microsoft coffers. Just wish
the government would adopt this idea as well and stop wasting billions
of taxpayers dollars making them rich.
If a business is running on VMS and a major part of that business
is a web server front end and they have to move that front end to
a different platform where is the incentive to leave anything
still on the VMS system?  I  have worked with heterogeneous systems.
It ain't fun.  Especially when something goes wrong and you have to
determine which platform is responsible (and I am not even talking
about the politics and finger pointing at the meeting tables!!)
What you do is design and implement the required interfaces.  Not so
hard.  It's even somewhat good to totally segregate some things.  Easier
to determine where problems exist.
So you add a third layer in between giving yet another item to
point fingers at and blame. yeah, that's gonna work.
It's amusing to see the suggestions to "port".  40 years of specific
business logic just doesn't get re-implemented all that easily.  Or
cheaply.  Sort of tough to get a businessman to pay to re-implement
something he already has.
But when you are being forced off of a system by the lack of
current, required technology what choice do you really have?

bill
Scott Dorsey
2019-03-15 14:19:40 UTC
Permalink
But, that was my point exactly.  I am being forced off of XP
and (mostly) Vista.  I am not upgrading to Windows 7 or Windows
10.  I am leaving Microsoft behind. (And recommending other
people do the same!!)
XP was -never- safe to use on the open internet, even when it was supported
by Microsoft. Now it's even less so. Since nobody in their right mind would
be using it on the internet, browser vendors are not supporting it.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Dave Froble
2019-03-15 19:45:54 UTC
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Bill Gunshannon
Post by Stephen Hoffman
Or port at least the web front-end to a different platform with a more
current web server.
But, that was my point exactly. I am being forced off of XP
and (mostly) Vista. I am not upgrading to Windows 7 or Windows
10. I am leaving Microsoft behind. (And recommending other
people do the same!!)
So what are you going to use? Specifically for the desktop?
My every day, workhorse desktop is Ubuntu. Been working fine since
the machine (running Vista) died about 3 years ago. I also have it
on a couple of my laptops. Have not found anything Windows did that
these can not do and a lot of things they can do that Windows could
not.
Post by Dave Froble
I also do not like using WEENDOZE 7, and refuse to boot up 10.
I refuse to pay any more money into the Microsoft coffers. Just wish
the government would adopt this idea as well and stop wasting billions
of taxpayers dollars making them rich.
Post by Dave Froble
Post by Bill Gunshannon
If a business is running on VMS and a major part of that business
is a web server front end and they have to move that front end to
a different platform where is the incentive to leave anything
still on the VMS system? I have worked with heterogeneous systems.
It ain't fun. Especially when something goes wrong and you have to
determine which platform is responsible (and I am not even talking
about the politics and finger pointing at the meeting tables!!)
What you do is design and implement the required interfaces. Not so
hard. It's even somewhat good to totally segregate some things.
Easier to determine where problems exist.
So you add a third layer in between giving yet another item to
point fingers at and blame. yeah, that's gonna work.
Post by Dave Froble
It's amusing to see the suggestions to "port". 40 years of specific
business logic just doesn't get re-implemented all that easily. Or
cheaply. Sort of tough to get a businessman to pay to re-implement
something he already has.
But when you are being forced off of a system by the lack of
current, required technology what choice do you really have?
But that's not happening.

True, SSL and certificates give us fits. But nothing much else. And
it's not like there is anything better available.

You present a case that doesn't exist. VMS works for us.

Really, what might be a possible replacement? Don't forget that 40
years of business logic. That is a critical part. Other vendors have
tried to compete. None came close.

Some might blithely say "port elsewhere". None seem to consider the
cost, both monetarily, and in mistakes that are sure to occur.

We on the other hand must consider such. We have done so. We don't
want to think of doing such a potentially disastrous and costly thing,
to end up with at best, what already exists. At best, most likely less.

Now, if you wish to actually consider the ramifications of what you
propose, before doing the proposing, that might be wise.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2019-03-15 21:09:23 UTC
Permalink
Post by Dave Froble
You present a case that doesn't exist. VMS works for us.
Really, what might be a possible replacement? Don't forget that 40
years of business logic. That is a critical part. Other vendors have
tried to compete. None came close.
Some might blithely say "port elsewhere". None seem to consider the
cost, both monetarily, and in mistakes that are sure to occur.
We on the other hand must consider such. We have done so. We don't
want to think of doing such a potentially disastrous and costly thing,
to end up with at best, what already exists. At best, most likely less.
Now, if you wish to actually consider the ramifications of what you
propose, before doing the proposing, that might be wise.
As you quite correctly state, re-hosting and wholesale rewriting can be
(and variously will be) difficult for an incumbent provider with an
installed base. Incremental migration or incremental refactoring
(usually) being the most viable path.

Remember too to ponder whether a new competitor might be able to sell
at a lower price, with a different approach, with different tooling, or
a different platform. If a business isn't looking to undercut itself
and its own products and to attract new, somebody else can be. If
(when?) a "cheaper, and good enough" competitor appears, it can well be
too late for an incumbent.

As for OpenVMS and SSL and this particular comp.os.vms newsgroup
thread, Apache and a whole chain of other packages including SSL and
certificates and a password store should all have been fully integrated
into the base distro a decade ago. Trade-offs and assumptions and
expectations can and do change. What worked for a single-core VAX with
456 MB disks and 8 MB of RAM can be an entirely wrong trade-off when
desktops and low-end servers routinely operate with 16 or more cores,
64 GB of RAM, and a few dozen terabytes of SSD. And worse, as fast,
byte-addressable, persistent memory continues to arrive. And app
development tools on OpenVMS are weak, in the most charitable of terms.
Why do I mention this? Because this makes app development on OpenVMS
more tedious, more difficult, and variously more expensive.

There are always trade-offs with products and product updates and
pricing. Some management decisions will pay off. Some won't.
--
Pure Personal Opinion | HoffmanLabs LLC
seasoned_geek
2019-06-02 23:27:12 UTC
Permalink
Post by Dave Froble
So what are you going to use? Specifically for the desktop?
I also do not like using WEENDOZE 7, and refuse to boot up 10.
10 is not as bad as it once was, but I only use it when forced to at a client site. The bulk of my personal machines run either KDE Neon

https://neon.kde.org/

or Ubuntu 18.04 LTS.

Of all the distros I have used KDE Neon currently seems to be the best.

Linux Mint used to be a very good desktop.
https://linuxmint.com/

They had serious distro specific problems with NVidia drivers some years back so anyone running BOINC left them.

Of course you could just stick with IE

/ducks and runs
j***@yahoo.co.uk
2019-06-03 13:42:38 UTC
Permalink
Post by seasoned_geek
Post by Dave Froble
So what are you going to use? Specifically for the desktop?
I also do not like using WEENDOZE 7, and refuse to boot up 10.
10 is not as bad as it once was, but I only use it when forced to at a client site. The bulk of my personal machines run either KDE Neon
https://neon.kde.org/
or Ubuntu 18.04 LTS.
Of all the distros I have used KDE Neon currently seems to be the best.
Linux Mint used to be a very good desktop.
https://linuxmint.com/
They had serious distro specific problems with NVidia drivers some years back so anyone running BOINC left them.
Of course you could just stick with IE
/ducks and runs
Hmmm. Never been a particular fan of Ubuntu myself, especially
in recent years, but it does seem to have mindshare sometimes,
and a share of press coverage in mainstream-ish media that to
me seems to be more related to Canonical's media-friendly skills
rather than anything directly related to what Canonical/Ubuntu
has brought to the table in recent years (even taking things like
Mint into account).

I do still like KDE etc for various reasons.

Where does KDE Neon fit in? Have a look at
https://neon.kde.org/faq
for a better answer than I can offer here at the moment.

Another well kept secret is that official variants of SUSE
(both Enterprise Server and OpenSuse flavours) are and have
been available through the Windows 10 App Store for maybe
a couple of years. It's not just for Ubuntu :)

Might be of interest to some folk (but not to me, as the
Windows Store is not currently in my IT strategy).
Arne Vajhøj
2019-03-14 21:10:22 UTC
Permalink
Post by Bill Gunshannon
Post by Stephen Hoffman
Or port at least the web front-end to a different platform with a more
current web server.
But, that was my point exactly.
If a business is running on VMS and a major part of that business
is a web server front end and they have to move that front end to
a different platform where is the incentive to leave anything
still on the VMS system?  I  have worked with heterogeneous systems.
It ain't fun.  Especially when something goes wrong and you have to
determine which platform is responsible (and I am not even talking
about the politics and finger pointing at the meeting tables!!)
I suspect that the companies running VMS typically already are
heterogeneous. Maybe not fun but reality.

Arne
Stephen Hoffman
2019-03-15 14:50:28 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Stephen Hoffman
Or port at least the web front-end to a different platform with a more
current web server.
But, that was my point exactly.
I wasn't replying to you with that posting, Bill.
Post by Arne Vajhøj
Post by Bill Gunshannon
If a business is running on VMS and a major part of that business is a
web server front end and they have to move that front end to a
different platform where is the incentive to leave anything still on
the VMS system?
The cost and the effort getting the apps ported off of OpenVMS,
usually. Inertia. This is the VSI market for the foreseeable future.

Or an established and long-time pool of experienced OpenVMS developers
working on the apps, and that either don't know or that are disinclined
to port or to learn different platforms and different tools and for any
of various good and bad reasons, for that matter.

Half-expecting to see somebody do a run of EDT4EVR stickers. If EDT
works for you, sure. But don't assume that most (any?) newer
developers are going to want to learn EDT. You'll have to pay them to
learn it and to contend with its limits. But I digress.

As for more general server configurations, web servers routinely
operate remotely from and separate from the associated database
servers. That's something that the common front-end web-oriented
languages make quite feasible.
Post by Arne Vajhøj
Post by Bill Gunshannon
  I  have worked with heterogeneous systems. It ain't fun.  Especially
when something goes wrong and you have to determine which platform is
responsible (and I am not even talking about the politics and finger
pointing at the meeting tables!!)
I suspect that the companies running VMS typically already are
heterogeneous. Maybe not fun but reality.
It'd be more interesting to find those organizations that weren't
heterogeneous, what with the prevalence of mobile clients and Windows
clients, and with integration with Windows Server and Active Directory
and and Exchange Server and other related services.

I'm sure there are still a few customers that are wholly based on
OpenVMS, and maybe even with VT terminals. Or that have non-networked
OpenVMS boxes. Most of those are probably using OpenVMS as an embedded
operating system, too.

But customers commonly using homogeneous configurations? Not a chance.

And not when OpenVMS isn't built, sold or positioned for front-end
client usage. Not that there's really been a supported front-end box
suitable for and priced for front-end client usage available with
OpenVMS in recent years. There are some folks using local or remote X
via DECwindows, not that that is seemingly all that common. I see
rather more command line and previous-millennium UIs, and web UIs. Not
so much X, though there's some around.

There are some folks using Apache on OpenVMS as a production front-end
for the server, any complaints around the various issues with the
commonly-down-revision components and with the utterly absurd
web-related packaging aside.
--
Pure Personal Opinion | HoffmanLabs LLC
Kerry Main
2019-04-06 17:12:39 UTC
Permalink
-----Original Message-----
via Info-vax
Sent: March 14, 2019 5:10 PM
Subject: Re: [Info-vax] OpenSSL CSWS-2.2-1
Post by Bill Gunshannon
Post by Stephen Hoffman
Or port at least the web front-end to a different platform with a
more current web server.
But, that was my point exactly.
If a business is running on VMS and a major part of that business is a
web server front end and they have to move that front end to a
different platform where is the incentive to leave anything still on
the VMS system? I have worked with heterogeneous systems.
It ain't fun. Especially when something goes wrong and you have to
determine which platform is responsible (and I am not even talking
about the politics and finger pointing at the meeting tables!!)
I suspect that the companies running VMS typically already are
heterogeneous. Maybe not fun but reality.
Arne
While true, we should also remember, that in todays world, unless it is a small site, there are very few companies that are only using 1 type of OS platform. There is always some group that says "we really need XYZ application and the vendor says their preferred OS platform is [insert your favourite OS]"

The days of Windows only or Linux only or OpenVMS only or UNIX only platforms etc. are long gone for most med-large companies.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Scott Dorsey
2019-04-06 18:10:33 UTC
Permalink
While true, we should also remember, that in todays world, unless it is =
a small site, there are very few companies that are only using 1 type of =
OS platform. There is always some group that says "we really need XYZ =
application and the vendor says their preferred OS platform is [insert =
your favourite OS]"
A lot of IT people think their company is only using one platform, as
they actively don't see (or sometimes have users deliberately hiding
from them) anything that doesn't look like their notion of what a
computer is.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Stephen Hoffman
2019-03-14 19:49:41 UTC
Permalink
Post by Stephen Hoffman
For not the first time this has been mentioned, HPE is exiting the
OpenVMS new-patch business at the end of 2020.
If you want to or need to run older versions and older apps in
isolation, have at.

But for not the first time, it is not possible to stay on older
software releases forever. Not for very much past the end of the app-
or product- or OS-specific long-term support. Not if there's to be
network connectivity and heterogeneous operations.

We are on a treadmill, and the treadmill is only going to accelerate.
Security patches and related updates are not going to slow down.

This also causes issues for vendors, as they're necessarily updating
their own development efforts, and they're tracking security issues and
patches and more general updates in their dependencies, and testing the
related bits.

Which further gets back to my comment around the need for APIs that
isolate some of the API differences that can arise here. Those APIs
not just for end-users, too.

Yes, this all heads toward SaaS and subscriptions and the "fun" of
continuous releases, too.

This is the world we're in, whether we want it or not.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...