Discussion:
Making Open Source Tools Work for VMS
Add Reply
Ken Farmer
2021-11-21 13:46:49 UTC
Reply
Permalink
For more than four years, a small team of devoted volunteers has put open source tools onto OpenVMS servers. The effort is focusing on OpenVMS 8.4 for the IA-64 servers from HP Enterprise. In the latest development for the project, the volunteers are bringing the new x86 version of OpenVMS from VMS Software Inc. into the picture.

This isn't the first proposed project expansion. Volunteers say one stretch goal makes open source serve the OpenVMS VAX 7.3 release, too. One of the prizes of this work is perl, operating on OpenVMS.

GNUlib makes open source software a reality on any platform. The HP 3000 community got this vital bootstrap during the 1990s. Open source was spreading its wings at the time, so tools like the Apache webserver and Samba pulled up for MPE/iX duty. GNUlib is the porting tool to bring open source to OpenVMS.

Read more...
https://LegacyOS.org/making-open-source-tools-work-for-vms/
Jon Schneider
2021-11-22 10:12:59 UTC
Reply
Permalink
I would really like to see a developers' guide Wiki for OpenVMS for
those of us, and I think there are quite a few, who have been writing
software for decades yet don't have a feel for doing so under (Open)VMS.

Jon
Phillip Helbig (undress to reply)
2021-11-22 11:28:00 UTC
Reply
Permalink
Post by Jon Schneider
I would really like to see a developers' guide Wiki for OpenVMS for
those of us, and I think there are quite a few, who have been writing
software for decades yet don't have a feel for doing so under (Open)VMS.
It would be nice if there were some sort of standard BUILD.COM which
would do everything (perhaps with parameters to determine whether one
wants to use supplied .EXE, link supplied .OBJ, or compile from supplied
sources). When finished, it can print out the required symbol
definition (which one would presumably place with others), command to
add the HELP to some library (ideally one would have a separate HELP
library for such third-party products), and so on.
Phillip Helbig (undress to reply)
2021-11-22 20:43:47 UTC
Reply
Permalink
I have been thinking about that - it would be very nice with a standard
for that.
foobar-1_2_3-src.zip with source
foobar-1_2_3-bin-vax.zip, foobar-1_2_3-bin-axp.zip,
foobar-1_2_3-bin-i64.zip and foobar-1_2_3-bin-x64.zip with obj and exe
all zip contains path foobar-1_2_3/bla/bla
build.com builds from source
link.com link obj (are called from build.com)
setup_logicals.com that define logicals and has a p1 so one can specify
"/system" and a p2 "yes" to specify that hlp$library_n to be defined
I think that the ZIP file should create a directory which includes the
version number. Maybe one for all architectures, as the non-binary
files will be the same and some folks might have mixed clusters.
Arne Vajhøj
2021-11-22 20:56:21 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
I have been thinking about that - it would be very nice with a standard
for that.
foobar-1_2_3-src.zip with source
foobar-1_2_3-bin-vax.zip, foobar-1_2_3-bin-axp.zip,
foobar-1_2_3-bin-i64.zip and foobar-1_2_3-bin-x64.zip with obj and exe
all zip contains path foobar-1_2_3/bla/bla
build.com builds from source
link.com link obj (are called from build.com)
setup_logicals.com that define logicals and has a p1 so one can specify
"/system" and a p2 "yes" to specify that hlp$library_n to be defined
I think that the ZIP file should create a directory which includes the
version number.
all zip contains path foobar-1_2_3/bla/bla
means.

Arne
Craig A. Berry
2021-11-22 14:23:57 UTC
Reply
Permalink
Post by Jon Schneider
I would really like to see a developers' guide Wiki for OpenVMS for
those of us, and I think there are quite a few, who have been writing
software for decades yet don't have a feel for doing so under (Open)VMS.
You mean something like this?

<https://sourceforge.net/p/gnv/wiki/Home/>
Jon Schneider
2021-11-22 16:55:24 UTC
Reply
Permalink
Post by Craig A. Berry
<https://sourceforge.net/p/gnv/wiki/Home/>
More without the GNU blinkers and lower level.

I'd like to see a guide to

* Interprocess (not network) communications
* Synchronisation
* The process model, debugging
* The (Files-11 I guess) filesystem
* Clustering features (and no seeing somebody gaffer tape a load of
Raspberry Pis together doesn't tell me much)
* Any features that are novel or handled quite differently in VMS

aimed at those with some knowledge of these thing in Unixen and MS Windows.
Dave Froble
2021-11-22 18:26:11 UTC
Reply
Permalink
Post by Jon Schneider
Post by Craig A. Berry
<https://sourceforge.net/p/gnv/wiki/Home/>
More without the GNU blinkers and lower level.
I'd like to see a guide to
Can I guess that RTFM doesn't apply?
Post by Jon Schneider
* Interprocess (not network) communications
Mailboxes, global sections, both in the "fine manual" ...
Post by Jon Schneider
* Synchronisation
DLM (Distributed lock manager) and again, in the "fine manual" ...
Post by Jon Schneider
* The process model, debugging
Not sure of the question, but, manuals and ISDM ...
Post by Jon Schneider
* The (Files-11 I guess) filesystem
It's in there ...
Post by Jon Schneider
* Clustering features (and no seeing somebody gaffer tape a load of Raspberry
Pis together doesn't tell me much)
I'd read the manual on clustering ...
Post by Jon Schneider
* Any features that are novel or handled quite differently in VMS
aimed at those with some knowledge of these thing in Unixen and MS Windows.
Honestly, I'm not trying to be a smartass. (Well, actually I am a smartass, but
wasn't trying in this reply.)

The VMS documentation is quite extensive. So extensive that at times it's a bit
hard to know where to look. Recently I was looking for some info on ASTs, and I
went through at least 3 manuals before I found the info. But, "it's in there."

Thinking about that search, perhaps a tool to find references to particular
subjects would be rather helpful. For example, enter "AST" and get a list of
the manuals that mention ASTs and briefly what's in each manual.
--
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
2021-11-22 19:04:44 UTC
Reply
Permalink
Post by Jon Schneider
I'd like to see a guide to
* Interprocess (not network) communications
Use IP, or use TLS for sensitive traffic, or maybe use ICC
intra-cluster communications services.

The use cases for mailboxes and shared-memory sections and such do
exist, but are more limited in my experience, tend not to scale all
that well, and you can find yourself re-implementing IP networking and
locking and memory cache management and the rest and for little gain
over IP and with much added effort. I've done all this stuff with all
these mechanisms and with DECnet and and DLM-based comms and more,
and—until and unless IP ran out of performance—I'd use IP as the
baseline for even local communications.

TLS is a quagmire on OpenVMS too, as it's little better than a
bag-on-the-side, with no integrated root certificate list, and a whole
pile of command-line tooling to get anywhere. A framework to deal with
IPv4, IPv6, DNS, TLS, VPNs, and the rest has been discussed,
but—outside of some open source here—that won't happen until well after
OpenVMS x86-64 ships. If then.
Post by Jon Schneider
* Synchronisation
The distributed lock manager (the Linux distributed lock managers were
patterned on the OpenVMS lock manager, so it should look familiar),
interlocked bitlocks and interlocked queues. There's a chapter or three
in the programming concepts manuals on these topics.

And you'll want to read the processor architectural manuals for shared
memory caching, as Alpha memory caching and re-ordering is...
aggressive.

Or use IP.
Post by Jon Schneider
* The process model, debugging
That's not well documented anywhere, though the debugger manual is a
reasonable start. I once had some stuff on remote debugging and
debugging detached processes posted a whole while back, but that's all
been offline for some years now.
Post by Jon Schneider
* The (Files-11 I guess) filesystem
There's a manual or two on that in the doc set. Expect and assume
ODS-5, and expect to get derailed by some C feature logical name or
some ancient volume still stuck at ODS-2.
Post by Jon Schneider
* Clustering features (and no seeing somebody gaffer tape a load of
Raspberry Pis together doesn't tell me much)
The cluster pricing rendered most cluster features infrequently
commercially used. There are a couple of manuals on this topic. One at
a higher level, one at a lower level. For programming, there's rather
less available in the docs. And app failover and the rest have
scattershot documentation.
Post by Jon Schneider
* Any features that are novel or handled quite differently in VMS
The only weird (useful) feature I can think of off-hand is software
RAID-1; Host-based Volume Shadowing. Pretty much the entirety of the
rest of the OpenVMS feature-set will have a corollary, analog, or
alternative on other platforms. Variously different, and variously
better. LDAP versus SYSUAF, for instance—outside of add-on
bag-on-the-side external authentication support, OpenVMS knows zilch
about LDAP. Which is just quaint from here in 2021.
Post by Jon Schneider
aimed at those with some knowledge of these thing in Unixen and MS Windows.
Trying to port over knowledge of Unix or Windows features and
expectations to OpenVMS tends to end badly, from a very long history of
folks trying to learn OpenVMS around here.

OpenVMS expects the developer to read much of the whole wall of
documentation, and doesn't really provide a cookbook-style
examples-based approach to app development. And there are gaps in the
docs that are less than fully visible to long-time developers. All of
which has been fodder for various previous discussions.

I've done day-long training sessions on these topics for various sites
and for experienced developers. But this whole area is one that starts
out very different from other platforms, and the resulting discussions
then go in myriad directions depending on local needs and expectations.
--
Pure Personal Opinion | HoffmanLabs LLC
Jon Schneider
2021-11-23 09:21:56 UTC
Reply
Permalink
have you read the OpenVMS Programming Concepts Manual - volumes 1&2 ?
Ah no but I should (seriously).

Jon
Stephen Hoffman
2021-11-22 18:36:02 UTC
Reply
Permalink
Post by Jon Schneider
I would really like to see a developers' guide Wiki for OpenVMS for
those of us, and I think there are quite a few, who have been writing
software for decades yet don't have a feel for doing so under (Open)VMS.
The VSI OpenVMS Programming Concepts manuals are the introduction to
this, and the OpenVMS Calling Standard manual.

https://docs.vmssoftware.com

The old Modular Procedures manual (no longer part of the doc set) and
the really-hard-to-find DIGITAL Software Engineering Manual,1988,
document identifier A-DG-ELEN571-00-0, have some more information on
how DEC envisioned designing, packaging, shipping, and supporting apps.

https://www.computerhistory.org/collections/catalog/102773805
https://www.nassi.com/VAX-11_SoftwEngrMan_Feb77.pdf (this is the 1977
predecessor version, though the 1988 version is vastly improved)

OpenVMS itself has no opinion on build procedures, though builds
inherently do presume compilers and related tooling and which may not
be or will not be available.

Compilations weren't something most DEC layered products did.

Which is why you see suggestions around a procedure for building and
another for linking.

Oh, and for C code there's one of my absolute favorite OpenVMS feature
of all time, the absolutely spectacular idea that are the feature
logical names. A mechanism which allows an out-of-band setting from
elsewhere in the build environment to re-tune or alter your source
build output and app run-time behavior in exceedingly arcane and subtle
ways. Even better, this is built atop logical names for app
configuration, a scheme which fell out of the 1970s and the corpse of
RSX-11M, and—outside of _maybe_ redirecting file paths—somebody should
dig up that corpse and re-bury the whole idea with it, then pour some
concrete over the grave with some engraved warnings for future
generations of developers that some ideas can come at too high a cost.

Some PCSI kits might link objects at install time, but providing
executables within install kits is commonplace.

Troubleshooting site-built executables is more difficult than
vendor-built executables, too—kits and users might build the necessary
listings and maps, or might not, or those files might get deleted and
which makes symbolicating and debugging crashes that much more
difficult.

There are various means to start apps. One being a manually-edited
startup file and a pair of manually-edited shutdown files, which is
common and quaint and error-prone. The other means is using the SYSMAN
tool, which would be preferred but for ~nobody using it, including PCSI
kits having had some hooks here but not using this. (I can think of
better ways to deal with all of this startup stuff, but manual edits
and PCSI—or maybe VMSINSTAL—is what we have.) There are other and
somewhat less-common means too, such as the auxiliary server (inetd).

There are many discussions of how to package and structure installed
apps too, though again OpenVMS itself and its tooling has few or no
opinions here. Some apps and kits scatter files through the system
directories, some create an app-specific directory structure. And
clustering complicates this, as now you can have two or more different
object file formats and executable formats involved, and can have both
a host-specific and a cluster-shared common directory. About the
biggest opinion in the PCSI tooling is a flat filename address space,
multi-architecture kits aren't all that well documented, and there can
be comparative difficulty in installing apps anywhere but on the system
disk.

For building, look around, and you'll find a mix of DECset MMS, MMK,
DCL, gmake, bash, and other tools used to build the apps, too.

OpenVMS has no means to package together and isolate app-related
features and dependencies (e.g. sandbox, container, jail, app bundle,
etc), and conflict avoidance is via facility prefixes and naming
conventions. Manual. No automation. Collisions with usernames and IP
ports and UICs and such can and do and have arisen. There's no facility
name coordination and no facility registrar at present AFAIK—x86-64
might be a good time to see that restarted—and which means name
collisions are possible. (These collisions happen less often due mostly
to few OpenVMS servers and few layered product kits and comparatively
few apps. This manually-coordinated by-convention model doesn't scale
all that well, but that hasn't been a problem in this millennium.)

One of the biggest mistakes I've encountered with OpenVMS apps is
incorporating flexibility around meaningless details—TCP/IP Services
configuration tool is one such example, where it's massively flexible
around what clients and what services get configured and how, and for
no benefit, and—with the different UICs and the rest of the
differences—with added complexity and costs. In 2021, nobody cares
about that, and it'd be easier to have everything configured, with the
only remaining decision being whether to start a particular service at
boot. And we still trip over the occasional bugs in all that
complexity. For... naught. The other is maintaining old and bad ideas
and broken APIs and limited APIs for far too long if not for forever,
but that's all fodder for several other debates.

Until and unless OpenVMS itself and the OpenVMS tooling has some
opinions here, I'd expect there can and will be as many different
opinions on how to name and organize and label build procedures and
source code distributions as there are developers involved. If not
more. Above comments obviously included.

BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
--
Pure Personal Opinion | HoffmanLabs LLC
John Dallman
1970-01-01 00:00:00 UTC
Reply
Permalink
Post by Stephen Hoffman
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS.
Yes. Really. Outright rejected that. Put slightly differently,
some of the open-source preferences around here can be...
unexpected.
I have encountered companies who wanted nothing to do with open source
because it "threatened their intellectual property" or "was communist."

John
Arne Vajhøj
2021-11-22 23:23:00 UTC
Reply
Permalink
Post by John Dallman
Post by Stephen Hoffman
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS.
Yes. Really. Outright rejected that. Put slightly differently,
some of the open-source preferences around here can be...
unexpected.
I have encountered companies who wanted nothing to do with open source
because it "threatened their intellectual property"
There are a few rare problematic cases like (A)GPL and libraries,
but generally there is no problem.
Post by John Dallman
or "was communist."
I can not remember any open source software that comes
from a communist country.

Arne
Arne Vajhøj
2021-11-22 23:26:24 UTC
Reply
Permalink
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS.  Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
If it was HP(E) that made the offer then I would actually
have been skeptical as well - it could be part of a plan
to offload maintenance cost to the community aka drop support.

Arne
Arne Vajhøj
2021-11-23 13:16:32 UTC
Reply
Permalink
Post by Stephen Hoffman
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code,
Almost all VMS people use lots of open source.

Arne
Phillip Helbig (undress to reply)
2021-11-23 13:38:19 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code,
Almost all VMS people use lots of open source.
Yes. Not all is bad, by any means. I use some myself. But there are
many things to criticize about Gnu philosophy. I can understand people
not wanting VMS to go that route.
Arne Vajhøj
2021-11-23 13:47:31 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Stephen Hoffman
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code,
Almost all VMS people use lots of open source.
Yes. Not all is bad, by any means. I use some myself. But there are
many things to criticize about Gnu philosophy. I can understand people
not wanting VMS to go that route.
There is a very long line of people that don't like Stallman.

But an OS under GPL is not a license problem for users.

But GPL VMS by HE would have looked like an escape plan. And
GPL VMS by VSI sound like a bad business plan.

Arne
Jon Schneider
2021-11-23 17:15:48 UTC
Reply
Permalink
I went to several FreeBSD events in the before times and found several
companies with products where a major selling point was that it was free
of GPL (though not saying whether proprietary or some other license).

Just keep in mind open source does not necessarily GPL.

Jon
Arne Vajhøj
2021-11-23 18:38:16 UTC
Reply
Permalink
Post by Arne Vajhøj
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS.  Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
No surprise.  People who use VMS like VMS.  People who use VMS don't
like some open-source code,
Almost all VMS people use lots of open source.
Yes.  Not all is bad, by any means.  I use some myself.  But there are
many things to criticize about Gnu philosophy.  I can understand people
not wanting VMS to go that route.
I agree. GPLed software is not free it is encumbered and controlled
by the FSF.  "Free" Opensource Software needs to come under something
like the BSD license which makes it truly free with no controlling
strings attached.
I think you are mixing some things up.

Most GNU projects has a policy of assigning copyright to FSF,
but that has nothing to do with GPL. Lot of GPL software has
nothing to do with FSF (except that FSF created the GPL license
text decades ago).

Whether permissive or copyleft licenses are most free depends
perspective. Permissive licenses allow for proprietary forks
while copyleft licenses ensure the code remains open source.
Is it more or less free if you restrict someone from restricting
others?

Strong copyleft licenses (GPL, AGPL) does not work for commercial
usage of libraries. That is a well known issue and often a topic for
heated debate. The practical impact is pretty small as very few
libraries are under such licenses. Libraries for obvious reasons
tend to pick weak copyleft licenses (LGPL, GPL with linking exception,
MPL etc.) - or permissive licenses.

Which permissive license to pick (BSD 2 clause, BSD 3 clause, Apache,
MIT etc.) is not so important. And it seems like the choice is
mostly determined by who is releasing the open source than the
specific license text. C code to be released under permissive
license are very often one of the BSD license flavors.

Arne
David Goodwin
2021-11-24 19:26:13 UTC
Reply
Permalink
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code, and don't like Richard
if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
Stallman and his ilk driving the community. (Yes, Stallman---who by all
accounts seems to be a rather creepy guy---really said that, insulting
millions of victims of real crimes against humanity.)
It has been some years since RMS had any real influence. Most open-source
software is unaffiliated with the Free Software Foundation or the GNU project.
Quite a lot these days is built by companies like Intel, IBM, Apple, Microsoft and
Google.
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code, and don't like Richard
if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
Stallman and his ilk driving the community. (Yes, Stallman---who by all
accounts seems to be a rather creepy guy---really said that, insulting
millions of victims of real crimes against humanity.)
Has VMS been handled badly by its owners, including DEC? Sure. Should
the solution be open source? Probably not. The world is not black and
white, though it seems that more and more people try to see it that way,
e.g. either one supports Trump or one is woke. Whatever happened to
old-fashioned common sense?
If it had been open sourced then VAX hobbyists wouldn't be loosing access
to OpenVMS at the end of this year. Same goes for people with older Alpha
hardware.

I think the main thing open-sourcing it would have achieved is securing *a*
future for it. It would have guaranteed access indefinitely to anyone with an
interest in running it.

Now is there is no guarantee VMS will be available long term - its continued
availability depends on it being profitable. If VSI is not replacing every customer
that leaves then eventually everyone who is not the original owner of a permanent
license will find themselves in the same situation as VAX hobbyists.
Arne Vajhøj
2021-11-24 20:20:45 UTC
Reply
Permalink
Post by David Goodwin
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code, and don't like Richard
if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
Stallman and his ilk driving the community. (Yes, Stallman---who by all
accounts seems to be a rather creepy guy---really said that, insulting
millions of victims of real crimes against humanity.)
Has VMS been handled badly by its owners, including DEC? Sure. Should
the solution be open source? Probably not. The world is not black and
white, though it seems that more and more people try to see it that way,
e.g. either one supports Trump or one is woke. Whatever happened to
old-fashioned common sense?
If it had been open sourced then VAX hobbyists wouldn't be loosing access
to OpenVMS at the end of this year. Same goes for people with older Alpha
hardware.
I think the main thing open-sourcing it would have achieved is securing *a*
future for it. It would have guaranteed access indefinitely to anyone with an
interest in running it.
Now is there is no guarantee VMS will be available long term - its continued
availability depends on it being profitable. If VSI is not replacing every customer
that leaves then eventually everyone who is not the original owner of a permanent
license will find themselves in the same situation as VAX hobbyists.
I don't think there is much point as I don't think VSI can make VMS
open source and HPE won't make VMS open source.

But even if they could and would, then I am not so sure about how
well it would work out.

The VMS community is notorious for how few that actually contribute
to open source, so the VMS community could not drive the development.

VSI can drive the development, but need to make money. Redhat makes
a lot of money from Linux, but there is a lot of Linux systems out there
and Redhat can keep the price so low that their commercial offering
still sell despite various free clones. But VMS does not have that
volume.

Arne
David Goodwin
2021-11-24 20:44:52 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by David Goodwin
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code, and don't like Richard
if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
Stallman and his ilk driving the community. (Yes, Stallman---who by all
accounts seems to be a rather creepy guy---really said that, insulting
millions of victims of real crimes against humanity.)
Has VMS been handled badly by its owners, including DEC? Sure. Should
the solution be open source? Probably not. The world is not black and
white, though it seems that more and more people try to see it that way,
e.g. either one supports Trump or one is woke. Whatever happened to
old-fashioned common sense?
If it had been open sourced then VAX hobbyists wouldn't be loosing access
to OpenVMS at the end of this year. Same goes for people with older Alpha
hardware.
I think the main thing open-sourcing it would have achieved is securing *a*
future for it. It would have guaranteed access indefinitely to anyone with an
interest in running it.
Now is there is no guarantee VMS will be available long term - its continued
availability depends on it being profitable. If VSI is not replacing every customer
that leaves then eventually everyone who is not the original owner of a permanent
license will find themselves in the same situation as VAX hobbyists.
I don't think there is much point as I don't think VSI can make VMS
open source and HPE won't make VMS open source.
But even if they could and would, then I am not so sure about how
well it would work out.
The VMS community is notorious for how few that actually contribute
to open source, so the VMS community could not drive the development.
VSI can drive the development, but need to make money. Redhat makes
a lot of money from Linux, but there is a lot of Linux systems out there
and Redhat can keep the price so low that their commercial offering
still sell despite various free clones. But VMS does not have that
volume.
Yeah, it seems unlikely the OpenVMS community would jump in and keep
the operating system alive. But I expect if the code was available someone
would eventually compile it and a free distribution of OpenVMS would then
exist.

Supposedly HPE was considering open-sourcing it but if that was ever going
to happen it had to happen back when HPE announced OpenVMS was dead.
When there were still people at HPE who knew what OpenVMS was and
before VSI stepped in. I expect by the time OpenVMS is no longer
commercially viable at VSI there will be no one left at HPE with the ability
to open-source it. Most likely at some point in the next few decades
OpenVMS will join Tru64, Ultrix and all the other operating systems that can
not be licensed anymore.
Dave Froble
2021-11-24 21:50:54 UTC
Reply
Permalink
Post by David Goodwin
Post by Arne Vajhøj
Post by David Goodwin
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code, and don't like Richard
if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
Stallman and his ilk driving the community. (Yes, Stallman---who by all
accounts seems to be a rather creepy guy---really said that, insulting
millions of victims of real crimes against humanity.)
Has VMS been handled badly by its owners, including DEC? Sure. Should
the solution be open source? Probably not. The world is not black and
white, though it seems that more and more people try to see it that way,
e.g. either one supports Trump or one is woke. Whatever happened to
old-fashioned common sense?
If it had been open sourced then VAX hobbyists wouldn't be loosing access
to OpenVMS at the end of this year. Same goes for people with older Alpha
hardware.
I think the main thing open-sourcing it would have achieved is securing *a*
future for it. It would have guaranteed access indefinitely to anyone with an
interest in running it.
Now is there is no guarantee VMS will be available long term - its continued
availability depends on it being profitable. If VSI is not replacing every customer
that leaves then eventually everyone who is not the original owner of a permanent
license will find themselves in the same situation as VAX hobbyists.
I don't think there is much point as I don't think VSI can make VMS
open source and HPE won't make VMS open source.
But even if they could and would, then I am not so sure about how
well it would work out.
The VMS community is notorious for how few that actually contribute
to open source, so the VMS community could not drive the development.
VSI can drive the development, but need to make money. Redhat makes
a lot of money from Linux, but there is a lot of Linux systems out there
and Redhat can keep the price so low that their commercial offering
still sell despite various free clones. But VMS does not have that
volume.
Yeah, it seems unlikely the OpenVMS community would jump in and keep
the operating system alive. But I expect if the code was available someone
would eventually compile it and a free distribution of OpenVMS would then
exist.
Supposedly HPE was considering open-sourcing it but if that was ever going
to happen it had to happen back when HPE announced OpenVMS was dead.
When there were still people at HPE who knew what OpenVMS was and
before VSI stepped in. I expect by the time OpenVMS is no longer
commercially viable at VSI there will be no one left at HPE with the ability
to open-source it. Most likely at some point in the next few decades
OpenVMS will join Tru64, Ultrix and all the other operating systems that can
not be licensed anymore.
Got to ask, what HW did/does those old OSs run on? VAX is no more. Alpha is no
more. Itanic is no more. Anything HP could open up has no HW to run on. So
what does it matter whether it's open or not?

The only reasonable source for an OpenVMS is VSI, and only after they complete
the port, and most likely some other things. Their deal with HP, as far as
those not at VSI knows, precludes an "open" OpenVMS. So it's not anything but a
conversation thing.

With the soon end of valid hobbyist licenses for VAX/VMS, it would not surprise
me to see a distribution of VAX/VMS V7.3 patched to avoid all license PAK
checking. Methods are already known. The capabilities to do so exist. All it
takes is one entity willing to do so.

Yes, there will be those who deplore the violation of copyright and ownership.
There will also be those willing to use such a distribution. Just don't blame
me, I have a valid license.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
David Goodwin
2021-11-24 23:36:43 UTC
Reply
Permalink
Post by David Goodwin
Post by Arne Vajhøj
Post by David Goodwin
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code, and don't like Richard
if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
Stallman and his ilk driving the community. (Yes, Stallman---who by all
accounts seems to be a rather creepy guy---really said that, insulting
millions of victims of real crimes against humanity.)
Has VMS been handled badly by its owners, including DEC? Sure. Should
the solution be open source? Probably not. The world is not black and
white, though it seems that more and more people try to see it that way,
e.g. either one supports Trump or one is woke. Whatever happened to
old-fashioned common sense?
If it had been open sourced then VAX hobbyists wouldn't be loosing access
to OpenVMS at the end of this year. Same goes for people with older Alpha
hardware.
I think the main thing open-sourcing it would have achieved is securing *a*
future for it. It would have guaranteed access indefinitely to anyone with an
interest in running it.
Now is there is no guarantee VMS will be available long term - its continued
availability depends on it being profitable. If VSI is not replacing every customer
that leaves then eventually everyone who is not the original owner of a permanent
license will find themselves in the same situation as VAX hobbyists.
I don't think there is much point as I don't think VSI can make VMS
open source and HPE won't make VMS open source.
But even if they could and would, then I am not so sure about how
well it would work out.
The VMS community is notorious for how few that actually contribute
to open source, so the VMS community could not drive the development.
VSI can drive the development, but need to make money. Redhat makes
a lot of money from Linux, but there is a lot of Linux systems out there
and Redhat can keep the price so low that their commercial offering
still sell despite various free clones. But VMS does not have that
volume.
Yeah, it seems unlikely the OpenVMS community would jump in and keep
the operating system alive. But I expect if the code was available someone
would eventually compile it and a free distribution of OpenVMS would then
exist.
Supposedly HPE was considering open-sourcing it but if that was ever going
to happen it had to happen back when HPE announced OpenVMS was dead.
When there were still people at HPE who knew what OpenVMS was and
before VSI stepped in. I expect by the time OpenVMS is no longer
commercially viable at VSI there will be no one left at HPE with the ability
to open-source it. Most likely at some point in the next few decades
OpenVMS will join Tru64, Ultrix and all the other operating systems that can
not be licensed anymore.
Got to ask, what HW did/does those old OSs run on? VAX is no more. Alpha is no
more. Itanic is no more. Anything HP could open up has no HW to run on. So
what does it matter whether it's open or not?
Historic preservation.

Its interesting exploring an era of computing I never got to experience first hand using
real hardware. Something people can no longer do unless they've either got a lot of
money or are willing to break the law.

An open-source OpenVMS would have fixed this (though not as well as a non-expiring
hobbyist license - I liked playing with even older versions too). But the opportunity, if
there ever was one, has passed.
Phillip Helbig (undress to reply)
2021-11-24 21:34:05 UTC
Reply
Permalink
Post by David Goodwin
Now is there is no guarantee VMS will be available long term - its continued
availability depends on it being profitable. If VSI is not replacing every customer
that leaves then eventually everyone who is not the original owner of a permanent
license will find themselves in the same situation as VAX hobbyists.
That is indeed sad, but open-sourcing VMS is not the only solution.
Dave Froble
2021-11-24 21:34:44 UTC
Reply
Permalink
Post by David Goodwin
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code, and don't like Richard
if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
Stallman and his ilk driving the community. (Yes, Stallman---who by all
accounts seems to be a rather creepy guy---really said that, insulting
millions of victims of real crimes against humanity.)
It has been some years since RMS had any real influence. Most open-source
software is unaffiliated with the Free Software Foundation or the GNU project.
Quite a lot these days is built by companies like Intel, IBM, Apple, Microsoft and
Google.
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code, and don't like Richard
if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
Stallman and his ilk driving the community. (Yes, Stallman---who by all
accounts seems to be a rather creepy guy---really said that, insulting
millions of victims of real crimes against humanity.)
Has VMS been handled badly by its owners, including DEC? Sure. Should
the solution be open source? Probably not. The world is not black and
white, though it seems that more and more people try to see it that way,
e.g. either one supports Trump or one is woke. Whatever happened to
old-fashioned common sense?
If it had been open sourced then VAX hobbyists wouldn't be loosing access
to OpenVMS at the end of this year. Same goes for people with older Alpha
hardware.
I think the main thing open-sourcing it would have achieved is securing *a*
future for it. It would have guaranteed access indefinitely to anyone with an
interest in running it.
Now is there is no guarantee VMS will be available long term - its continued
availability depends on it being profitable. If VSI is not replacing every customer
that leaves then eventually everyone who is not the original owner of a permanent
license will find themselves in the same situation as VAX hobbyists.
As usual, not black or white. just shades of grey.

As I read posts here in c.o.v, some of which deplore some of the parts of VMS,
as in the recent discussion about ASTs and the R0,R1,etc arguments, I have to
wonder what might happen to an "open" VMS. Might some of the fanatical
"do-gooders" start upgrading or replacing some of the things that makes VMS
upward compatible? Might some C programmers decide they didn't need Macro-32,
Basic, Fortran, Cobol, and such? Might the desire for OO make many existing
applications no longer usable? Where might such a thing go?

One consideration, when one is paying a vendor for a product, they have someone
who must listen to their needs, at least if they want the customer to continue
to pay them. One then asks, what leverage does users have over those "core"
people in that rust thingy?

As I mentioned, grey. I think there might be some decent arguments to make the
OS free and open, while maintainers such as VSI makes their money with support
and such. There might also be some valid arguments against.

Never forget, the road to hell is paved with good intentions.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
David Goodwin
2021-11-24 21:53:47 UTC
Reply
Permalink
Post by Dave Froble
Post by David Goodwin
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code, and don't like Richard
if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
Stallman and his ilk driving the community. (Yes, Stallman---who by all
accounts seems to be a rather creepy guy---really said that, insulting
millions of victims of real crimes against humanity.)
It has been some years since RMS had any real influence. Most open-source
software is unaffiliated with the Free Software Foundation or the GNU project.
Quite a lot these days is built by companies like Intel, IBM, Apple, Microsoft and
Google.
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code, and don't like Richard
if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
Stallman and his ilk driving the community. (Yes, Stallman---who by all
accounts seems to be a rather creepy guy---really said that, insulting
millions of victims of real crimes against humanity.)
Has VMS been handled badly by its owners, including DEC? Sure. Should
the solution be open source? Probably not. The world is not black and
white, though it seems that more and more people try to see it that way,
e.g. either one supports Trump or one is woke. Whatever happened to
old-fashioned common sense?
If it had been open sourced then VAX hobbyists wouldn't be loosing access
to OpenVMS at the end of this year. Same goes for people with older Alpha
hardware.
I think the main thing open-sourcing it would have achieved is securing *a*
future for it. It would have guaranteed access indefinitely to anyone with an
interest in running it.
Now is there is no guarantee VMS will be available long term - its continued
availability depends on it being profitable. If VSI is not replacing every customer
that leaves then eventually everyone who is not the original owner of a permanent
license will find themselves in the same situation as VAX hobbyists.
As usual, not black or white. just shades of grey.
As I read posts here in c.o.v, some of which deplore some of the parts of VMS,
as in the recent discussion about ASTs and the R0,R1,etc arguments, I have to
wonder what might happen to an "open" VMS. Might some of the fanatical
"do-gooders" start upgrading or replacing some of the things that makes VMS
upward compatible? Might some C programmers decide they didn't need Macro-32,
Basic, Fortran, Cobol, and such? Might the desire for OO make many existing
applications no longer usable? Where might such a thing go?
If OpenVMS were ever open-sourced my bet would be on no significant changes
at all. No doubt someone would try to get the source code to compile which might
result in a free version of OpenVMS. Perhaps some companies who still depend on
it would employ some people to fix problems as they occur - providing their own
support effectively (as some large companies do in the Linux world).

Possibly some "do-gooder" might start some project to make drastic changes but
OpenVMS is probably far too obscure and incompatible to attract a large enough
number of developers from the Linux world to make such a project viable.

If there ever were an open-source OpenVMS any changes would almost certainly
come down to the OpenVMS community. And the OpenVMS community seems
little interested in making changes.

This is perhaps the biggest argument against open-sourcing it really. The OpenVMS
community doesn't seem to care so the only thing to really be achieved is historic
preservation.
Simon Clubley
2021-11-25 13:16:49 UTC
Reply
Permalink
Post by Dave Froble
As I read posts here in c.o.v, some of which deplore some of the parts of VMS,
as in the recent discussion about ASTs and the R0,R1,etc arguments, I have to
wonder what might happen to an "open" VMS. Might some of the fanatical
"do-gooders" start upgrading or replacing some of the things that makes VMS
upward compatible? Might some C programmers decide they didn't need Macro-32,
Basic, Fortran, Cobol, and such? Might the desire for OO make many existing
applications no longer usable? Where might such a thing go?
Due to the monolithic mass of integrated code which is _not_ cleanly
broken into clean interfaces, upgrading the internals of VMS is massively
harder than doing the same things elsewhere.

For one really simple example, adding a new filesystem to Linux is easy
(and can be done by end user organisations) because Linux has a nice
clean internal filesystem architecture.

VMS is a monolithic ugly mass of intertwined filesystem code by comparison.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Loading...