Discussion:
A new VMS?
(too old to reply)
Johann 'Myrkraverk' Oskarsson
2021-04-23 16:48:46 UTC
Permalink
Dear c.o.vms,

In light of recent discussions about licenses from VSI expiring, I bring
up the following point. For reference: I am not a VSI customer, but I
hope to be in the future.

It is not too late to just replace VMS. I don't mean migrate your code
to *nix or something else, but to recreate VMS from scratch, or at least
the parts you're using.

Don't take my word for the legality of it, run the recent SCOTUS ruling
in Oracle vs. Google through your legal department, and get back to me.

The project itself doesn't have to be open source; even with closed
source, you can still start with n+1 open source kernels to bootstrap
the project.

People who participate can be confident they can run the system license
free forever, at the cost of maintaining an OS [1]. Even if VSI relents
and changes its licensing policies, I'd still consider investing in such
a project, for future prooving my business.

[1] Which is not cheap, today.
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk
Arne Vajhøj
2021-04-23 16:58:03 UTC
Permalink
Post by Johann 'Myrkraverk' Oskarsson
In light of recent discussions about licenses from VSI expiring, I bring
up the following point.  For reference: I am not a VSI customer, but I
hope to be in the future.
It is not too late to just replace VMS.  I don't mean migrate your code
to *nix or something else, but to recreate VMS from scratch, or at least
the parts you're using.
Don't take my word for the legality of it, run the recent SCOTUS ruling
in Oracle vs. Google through your legal department, and get back to me.
The project itself doesn't have to be open source; even with closed
source, you can still start with n+1 open source kernels to bootstrap
the project.
People who participate can be confident they can run the system license
free forever, at the cost of maintaining an OS [1].  Even if VSI relents
and changes its licensing policies, I'd still consider investing in such
a project, for future prooving my business.
[1] Which is not cheap, today.
That idea has come up occasionally during the last
20 years.

I don't think it is realistic.

The effort is required huge. There is no big commercial opportunities.
And the interest in writing open source is very limited in the VMS
community.

Arne
John H. Reinhardt
2021-04-23 17:46:37 UTC
Permalink
Post by Arne Vajhøj
Post by Johann 'Myrkraverk' Oskarsson
In light of recent discussions about licenses from VSI expiring, I bring
up the following point.  For reference: I am not a VSI customer, but I
hope to be in the future.
It is not too late to just replace VMS.  I don't mean migrate your code
to *nix or something else, but to recreate VMS from scratch, or at least
the parts you're using.
Don't take my word for the legality of it, run the recent SCOTUS ruling
in Oracle vs. Google through your legal department, and get back to me.
The project itself doesn't have to be open source; even with closed
source, you can still start with n+1 open source kernels to bootstrap
the project.
People who participate can be confident they can run the system license
free forever, at the cost of maintaining an OS [1].  Even if VSI relents
and changes its licensing policies, I'd still consider investing in such
a project, for future prooving my business.
[1] Which is not cheap, today.
That idea has come up occasionally during the last
20 years.
I don't think it is realistic.
The effort is required huge. There is no big commercial opportunities.
And the interest in writing open source is very limited in the VMS
community.
Arne
How long did it take Linux to be commercially usable? Now multiply that time by about 1000 (maybe a 1,000,000) because there will be at least 1000 times fewer people than Linux had to develop the kernel and all the userland apps that you would need. And how many millions invested by companies such as IBM, Dell, Redhat, etc with their employees contributing code? Yeah. Not going to happen.
--
John H. Reinhardt
Andrew Commons
2021-04-25 09:07:18 UTC
Permalink
How long did it take Linux to be commercially usable? Now multiply that time by about 1000 (maybe a 1,000,000) because there will be at least 1000 times fewer people than Linux had to develop the kernel and all the userland apps that you would need. And how many millions invested by companies such as IBM, Dell, Redhat, etc with their employees contributing code? Yeah. Not going to happen.
--
John H. Reinhardt
It took 7 years to get a fully native VAX/VMS released with all the resources of DEC behind it.
OpenVMS as it stands today is vastly more complex than that so a clean room implementation
is highly unlikely.
Johann 'Myrkraverk' Oskarsson
2021-04-25 15:15:48 UTC
Permalink
Post by Arne Vajhøj
Post by Johann 'Myrkraverk' Oskarsson
In light of recent discussions about licenses from VSI expiring, I bring
up the following point.  For reference: I am not a VSI customer, but I
hope to be in the future.
It is not too late to just replace VMS.  I don't mean migrate your code
to *nix or something else, but to recreate VMS from scratch, or at least
the parts you're using.
Don't take my word for the legality of it, run the recent SCOTUS ruling
in Oracle vs. Google through your legal department, and get back to me.
The project itself doesn't have to be open source; even with closed
source, you can still start with n+1 open source kernels to bootstrap
the project.
People who participate can be confident they can run the system license
free forever, at the cost of maintaining an OS [1].  Even if VSI relents
and changes its licensing policies, I'd still consider investing in such
a project, for future prooving my business.
[1] Which is not cheap, today.
That idea has come up occasionally during the last
20 years.
I don't think it is realistic.
The effort is required huge. There is no big commercial opportunities.
And the interest in writing open source is very limited in the VMS
community.
Bootstrapping an OS today is not what it was 40 years ago.

Commercial opportunities are irrelevant. All the project needs to do,
is to run the code of the funding organizations at acceptable
perforce with acceptable cost [1]. The project absolutely does not need
to be open source.

If I am left to my own devices about how to do it, I can get you a DCL
prompt through SSH is less than 12 months. That's

Me. Alone. Part time.

After a decade, you could be paying me for support.

The project is not as big as you believe[2]. All we have to support is
the set union of features used by the funding organizations. That is
not /all of VMS/. Even though the project is big.
How long did it take Linux to be commercially usable?  Now multiply that
time by about 1000 (maybe a 1,000,000) because there will be at least
1000 times fewer people than Linux had to develop the kernel and all the
userland apps that you would need.  And how many millions invested by
companies such as IBM, Dell, Redhat, etc with their employees
contributing code?
If you mean /can be sold/ by "commercially usable", then that's
irrelevant. Any and all measurements to Linux are pointless, until
newVMS exists.

If you look at the project as an insurance, in case VSI fails, then you
can start to look at what is realistic and what isn't. How much are
people willing to invest in an insurance of mission critical
infrastructure, even if it takes a decade to realize?

If you decide not to, because you decide a priori that it can't be done,
then you can only blame yourself when VMS is gone.
Yeah.  Not going to happen.
Only if you make sure it doesn't happen.


[1] For some reason, both bean counters and executives have a hard time
measuring cost when it's included in salaries; even regular people
have a hard time measuring the cost of their own effort in salaries.

[2] And in other ways, bigger than I believe.
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk
Arne Vajhøj
2021-04-25 15:50:53 UTC
Permalink
Post by Johann 'Myrkraverk' Oskarsson
Post by Arne Vajhøj
Post by Johann 'Myrkraverk' Oskarsson
In light of recent discussions about licenses from VSI expiring, I bring
up the following point.  For reference: I am not a VSI customer, but I
hope to be in the future.
It is not too late to just replace VMS.  I don't mean migrate your code
to *nix or something else, but to recreate VMS from scratch, or at least
the parts you're using.
Don't take my word for the legality of it, run the recent SCOTUS ruling
in Oracle vs. Google through your legal department, and get back to me.
The project itself doesn't have to be open source; even with closed
source, you can still start with n+1 open source kernels to bootstrap
the project.
People who participate can be confident they can run the system license
free forever, at the cost of maintaining an OS [1].  Even if VSI relents
and changes its licensing policies, I'd still consider investing in such
a project, for future prooving my business.
[1] Which is not cheap, today.
That idea has come up occasionally during the last
20 years.
I don't think it is realistic.
The effort is required huge. There is no big commercial opportunities.
And the interest in writing open source is very limited in the VMS
community.
Bootstrapping an OS today is not what it was 40 years ago.
Commercial opportunities are irrelevant.  All the project needs to do,
is to run the code of the funding organizations at acceptable
perforce with acceptable cost [1].  The project absolutely does not need
to be open source.
If I am left to my own devices about how to do it, I can get you a DCL
prompt through SSH is less than 12 months.  That's
 Me.  Alone.  Part time.
After a decade, you could be paying me for support.
The project is not as big as you believe[2].  All we have to support is
the set union of features used by the funding organizations.  That is
not /all of VMS/.  Even though the project is big.
Writing an OS today is not like writing an OS 40 years ago. It is way
more expensive today, because a lot more functionality is required.

Work requires people to do it. People will do it either because
someone is paying them to do it or because they think it is fun. Or both.

Not enough commercial opportunities mean that noone will pay
people to do it. And not enough volunteers.

The subset idea it just going to make things worse. The interest in
a 50% VMS compatible OS is not going to be big. And even though
it saves implementation work, then it creates more requirements work,
because it will need to define what subset to implement and what will be
different.
Post by Johann 'Myrkraverk' Oskarsson
How long did it take Linux to be commercially usable?  Now multiply
that time by about 1000 (maybe a 1,000,000) because there will be at
least 1000 times fewer people than Linux had to develop the kernel and
all the userland apps that you would need.  And how many millions
invested by companies such as IBM, Dell, Redhat, etc with their
employees contributing code?
If you mean /can be sold/ by "commercially usable", then that's
irrelevant.  Any and all measurements to Linux are pointless, until
newVMS exists.
If you look at the project as an insurance, in case VSI fails, then you
can start to look at what is realistic and what isn't.  How much are
people willing to invest in an insurance of mission critical
infrastructure, even if it takes a decade to realize?
Very few will be willing to invest in creating an OS from scratch.
Post by Johann 'Myrkraverk' Oskarsson
If you decide not to, because you decide a priori that it can't be done,
then you can only blame yourself when VMS is gone.
Yeah.  Not going to happen.
Only if you make sure it doesn't happen.
Nobody can prevent someone from starting the project. It has
been tried before.

But just like any other idea it will evaluated for
feasibility.

Arne
Dave Froble
2021-04-25 16:39:40 UTC
Permalink
Post by Johann 'Myrkraverk' Oskarsson
Post by John H. Reinhardt
Post by Arne Vajhøj
Post by Johann 'Myrkraverk' Oskarsson
In light of recent discussions about licenses from VSI expiring, I bring
up the following point. For reference: I am not a VSI customer, but I
hope to be in the future.
It is not too late to just replace VMS. I don't mean migrate your code
to *nix or something else, but to recreate VMS from scratch, or at least
the parts you're using.
Don't take my word for the legality of it, run the recent SCOTUS ruling
in Oracle vs. Google through your legal department, and get back to me.
The project itself doesn't have to be open source; even with closed
source, you can still start with n+1 open source kernels to bootstrap
the project.
People who participate can be confident they can run the system license
free forever, at the cost of maintaining an OS [1]. Even if VSI relents
and changes its licensing policies, I'd still consider investing in such
a project, for future prooving my business.
[1] Which is not cheap, today.
That idea has come up occasionally during the last
20 years.
I don't think it is realistic.
The effort is required huge. There is no big commercial opportunities.
And the interest in writing open source is very limited in the VMS
community.
Bootstrapping an OS today is not what it was 40 years ago.
Commercial opportunities are irrelevant. All the project needs to do,
is to run the code of the funding organizations at acceptable
perforce with acceptable cost [1]. The project absolutely does not need
to be open source.
If I am left to my own devices about how to do it, I can get you a DCL
prompt through SSH is less than 12 months. That's
Me. Alone. Part time.
After a decade, you could be paying me for support.
The project is not as big as you believe[2]. All we have to support is
the set union of features used by the funding organizations. That is
not /all of VMS/. Even though the project is big.
Post by John H. Reinhardt
How long did it take Linux to be commercially usable? Now multiply
that time by about 1000 (maybe a 1,000,000) because there will be at
least 1000 times fewer people than Linux had to develop the kernel and
all the userland apps that you would need. And how many millions
invested by companies such as IBM, Dell, Redhat, etc with their
employees contributing code?
If you mean /can be sold/ by "commercially usable", then that's
irrelevant. Any and all measurements to Linux are pointless, until
newVMS exists.
If you look at the project as an insurance, in case VSI fails, then you
can start to look at what is realistic and what isn't. How much are
people willing to invest in an insurance of mission critical
infrastructure, even if it takes a decade to realize?
If you decide not to, because you decide a priori that it can't be done,
then you can only blame yourself when VMS is gone.
Post by John H. Reinhardt
Yeah. Not going to happen.
Only if you make sure it doesn't happen.
[1] For some reason, both bean counters and executives have a hard time
measuring cost when it's included in salaries; even regular people
have a hard time measuring the cost of their own effort in salaries.
[2] And in other ways, bigger than I believe.
While anything "can be done", I have to wonder what it is that you envision?

To totally replace VMS, in my mind, the new OS would have to support
everything that VMS currently supports.

Would Macro-32 applications work?
Would Basic applications work?
Would (whatever language) applications work?

To be usable for just about all current VMS users, the compilers and
such would need to be available.

Perhaps not a large issue, but what CPUs would be supported? VAX?
Alpha? Itanic? x86? ARM? Power?

What devices would be supported?

Would there still be a terminal driver? Terminal software?

Some chopped down spec to run C programs isn't going to replace VMS.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Scott Dorsey
2021-04-25 16:44:01 UTC
Permalink
The thing is, there have been at least two projects that I know of which have
intended to write a VMS work-alike clone. Both of these projects failed due to
a lack of interest and funding.

Such a project could be successful given proper funding. But that is the
rub.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Johann 'Myrkraverk' Oskarsson
2021-04-25 17:15:37 UTC
Permalink
Post by Dave Froble
Post by Johann 'Myrkraverk' Oskarsson
Post by Arne Vajhøj
Post by Johann 'Myrkraverk' Oskarsson
In light of recent discussions about licenses from VSI expiring, I bring
up the following point.  For reference: I am not a VSI customer, but I
hope to be in the future.
It is not too late to just replace VMS.  I don't mean migrate your code
to *nix or something else, but to recreate VMS from scratch, or at least
the parts you're using.
Don't take my word for the legality of it, run the recent SCOTUS ruling
in Oracle vs. Google through your legal department, and get back to me.
The project itself doesn't have to be open source; even with closed
source, you can still start with n+1 open source kernels to bootstrap
the project.
People who participate can be confident they can run the system license
free forever, at the cost of maintaining an OS [1].  Even if VSI relents
and changes its licensing policies, I'd still consider investing in such
a project, for future prooving my business.
[1] Which is not cheap, today.
That idea has come up occasionally during the last
20 years.
I don't think it is realistic.
The effort is required huge. There is no big commercial opportunities.
And the interest in writing open source is very limited in the VMS
community.
Bootstrapping an OS today is not what it was 40 years ago.
Commercial opportunities are irrelevant.  All the project needs to do,
is to run the code of the funding organizations at acceptable
perforce with acceptable cost [1].  The project absolutely does not need
to be open source.
If I am left to my own devices about how to do it, I can get you a DCL
prompt through SSH is less than 12 months.  That's
  Me.  Alone.  Part time.
After a decade, you could be paying me for support.
The project is not as big as you believe[2].  All we have to support is
the set union of features used by the funding organizations.  That is
not /all of VMS/.  Even though the project is big.
How long did it take Linux to be commercially usable?  Now multiply
that time by about 1000 (maybe a 1,000,000) because there will be at
least 1000 times fewer people than Linux had to develop the kernel and
all the userland apps that you would need.  And how many millions
invested by companies such as IBM, Dell, Redhat, etc with their
employees contributing code?
If you mean /can be sold/ by "commercially usable", then that's
irrelevant.  Any and all measurements to Linux are pointless, until
newVMS exists.
If you look at the project as an insurance, in case VSI fails, then you
can start to look at what is realistic and what isn't.  How much are
people willing to invest in an insurance of mission critical
infrastructure, even if it takes a decade to realize?
If you decide not to, because you decide a priori that it can't be done,
then you can only blame yourself when VMS is gone.
Yeah.  Not going to happen.
Only if you make sure it doesn't happen.
[1] For some reason, both bean counters and executives have a hard time
measuring cost when it's included in salaries; even regular people
have a hard time measuring the cost of their own effort in salaries.
[2] And in other ways, bigger than I believe.
While anything "can be done", I have to wonder what it is that you envision?
Why are you asking me? I do not have code running on VMS that I
specifically need VMS for. I know what /I/ can deliver in a reasonable
time frame. But I have no idea of that'll meet /your/ requirements.
Post by Dave Froble
To totally replace VMS, in my mind, the new OS would have to support
everything that VMS currently supports.
Would Macro-32 applications work?
Would Basic applications work?
Would (whatever language) applications work?
To be usable for just about all current VMS users, the compilers and
such would need to be available.
Compilers are not hard.
Post by Dave Froble
Perhaps not a large issue, but what CPUs would be supported?  VAX?
Alpha?  Itanic?  x86?  ARM?  Power?
Only a funding organization can have any say in this matter. I know
where I would /start/ and that's it.
Post by Dave Froble
What devices would be supported?
See above.
Post by Dave Froble
Would there still be a terminal driver?  Terminal software?
Some chopped down spec to run C programs isn't going to replace VMS.
Nope, it isn't.

Without funding on the table, either for a contract with my employer,
or yours, for your time, no real discussions can take place.

I am not really interested in arguments about theoretical requirements
without money nor time on the table. [Funding organizations can put
time of employees on the table, in lieu of monetary contract with some-
one else.]

You can 1) shut up about the idea, because you think it cannot be done;
2) talk to someone about funding the idea, for which you can decide what
is and isn't on the table; or 3) directly fund the idea with time or
money.
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk
John Reagan
2021-04-25 18:30:09 UTC
Permalink
Post by Johann 'Myrkraverk' Oskarsson
Post by Dave Froble
Would Macro-32 applications work?
Would Basic applications work?
Would (whatever language) applications work?
To be usable for just about all current VMS users, the compilers and
such would need to be available.
Compilers are not hard.
Ah, thanks for writing my single slide for my Tuesday Webinar.
Craig A. Berry
2021-04-25 18:44:03 UTC
Permalink
Post by John Reagan
Post by Johann 'Myrkraverk' Oskarsson
Post by Dave Froble
To be usable for just about all current VMS users, the compilers and
such would need to be available.
Compilers are not hard.
Ah, thanks for writing my single slide for my Tuesday Webinar.
I hope you didn't hurt yourself when you fell off your chair laughing :-).
Chris Townley
2021-04-25 19:56:14 UTC
Permalink
Post by Craig A. Berry
Post by John Reagan
Post by Johann 'Myrkraverk' Oskarsson
Post by Dave Froble
To be usable for just about all current VMS users, the compilers and
such would need to be available.
Compilers are not hard.
Ah, thanks for writing my single slide for my Tuesday Webinar.
I hope you didn't hurt yourself when you fell off your chair laughing :-).
+1

Chris
Dave Froble
2021-04-25 21:12:41 UTC
Permalink
Post by John Reagan
Post by Johann 'Myrkraverk' Oskarsson
Post by Dave Froble
Would Macro-32 applications work?
Would Basic applications work?
Would (whatever language) applications work?
To be usable for just about all current VMS users, the compilers and
such would need to be available.
Compilers are not hard.
Ah, thanks for writing my single slide for my Tuesday Webinar.
Well John, he's most likely right, at least for some definition of "not
hard". Gonna be one hell of a definition.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Galen
2021-04-26 02:05:04 UTC
Permalink
Post by Dave Froble
Post by John Reagan
Post by Johann 'Myrkraverk' Oskarsson
Post by Dave Froble
Would Macro-32 applications work?
Would Basic applications work?
Would (whatever language) applications work?
To be usable for just about all current VMS users, the compilers and
such would need to be available.
Compilers are not hard.
Ah, thanks for writing my single slide for my Tuesday Webinar.
Well John, he's most likely right, at least for some definition of "not
hard". Gonna be one hell of a definition.
Maybe he’s mentally comparing it to creating a viable fusion power plant,
or to building a LHC++ particle accelerator.
Phillip Helbig (undress to reply)
2021-04-26 04:59:44 UTC
Permalink
Post by Dave Froble
Post by John Reagan
Post by Johann 'Myrkraverk' Oskarsson
Post by Dave Froble
To be usable for just about all current VMS users, the compilers and
such would need to be available.
Compilers are not hard.
Ah, thanks for writing my single slide for my Tuesday Webinar.
Well John, he's most likely right, at least for some definition of "not
hard". Gonna be one hell of a definition.
The following is actually a standard-conforming Fortran compiler:

$ WRITE SYS$OUTPUT "%FTN-F-TCPLX, Program too complex for processor"
$ EXIT

The quality of implementation leaves much to be desired, however.
V***@SendSpamHere.ORG
2021-04-26 10:04:12 UTC
Permalink
Post by John Reagan
Post by Johann 'Myrkraverk' Oskarsson
Post by Dave Froble
Would Macro-32 applications work?
Would Basic applications work?
Would (whatever language) applications work?
To be usable for just about all current VMS users, the compilers and
such would need to be available.
Compilers are not hard.
Ah, thanks for writing my single slide for my Tuesday Webinar.
LOL
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Simon Clubley
2021-04-26 12:37:53 UTC
Permalink
Post by Johann 'Myrkraverk' Oskarsson
Compilers are not hard.
How long do you think it would take you to write a Macro-32 compiler
and how long do you think it would take you to make it compatible with
existing Macro-32 code ?

Other VMS-specific issues:

How long do you think it would take you to do the following ?

1) Implement full VMS-style clustering ?

2) Implement the shadowing driver and tie it into 1) above so you can
do VMS-style volume shadowing across a cluster ?

3) Implement the ODS-2/ODS-5 filesystems ? (Or would you use another
filesystem that you could map RMS attributes support onto ?)

4) Implement full RMS support ? (Or would you only support sequential
files and use databases for anything above that ?)

Also, would you maintain the existing 4-mode KESU VMS memory model or
would you collapse it down to a 2-mode KU model ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Johann 'Myrkraverk' Oskarsson
2021-04-26 13:31:46 UTC
Permalink
Post by Simon Clubley
Post by Johann 'Myrkraverk' Oskarsson
Compilers are not hard.
How long do you think it would take you to write a Macro-32 compiler
and how long do you think it would take you to make it compatible with
existing Macro-32 code ?
Realistically? Anywhere from a few days to a month, depending on how
complete you need the proof-of-concept to be, if I'm left on my own to
decide how to do it.

After that, I'd be working with funding and a team, at bare minimum some
of my own coworkers, for which the estimate changes completely. Even if
we scrap the original proof-of-concept.
Put money on the table, and ask again. I am not interested in phantom
requirements from people who aren't going to fund the effort. When,
more than if, you don't like my replies, you can take the money off the
table.
Post by Simon Clubley
How long do you think it would take you to do the following ?
1) Implement full VMS-style clustering ?
2) Implement the shadowing driver and tie it into 1) above so you can
do VMS-style volume shadowing across a cluster ?
3) Implement the ODS-2/ODS-5 filesystems ? (Or would you use another
filesystem that you could map RMS attributes support onto ?)
4) Implement full RMS support ? (Or would you only support sequential
files and use databases for anything above that ?)
Also, would you maintain the existing 4-mode KESU VMS memory model or
would you collapse it down to a 2-mode KU model ?
Simon.
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk
El SysMan
2021-05-02 09:46:54 UTC
Permalink
Post by Arne Vajhøj
And the interest in writing open source is very limited in the VMS
community.
VSI does not interested of the support any ports by volunteers.
John Dallman
2021-04-23 22:55:00 UTC
Permalink
Post by Johann 'Myrkraverk' Oskarsson
It is not too late to just replace VMS. I don't mean migrate your
code to *nix or something else, but to recreate VMS from scratch,
or at least the parts you're using.
Presumably you'd want to write something with source-level compatibility
on hardware with a future? A new implementation of VMS on IA-64 would be
foolish, since the hardware will soon only be available used. That saves
you from needing perfect binary compatibility, but exposes another big
problem: you need compilers to port applications.

If you're on x86-64, you can use the open-source Clang for OpenVMS, but
that only gets you C and C++. Are you going to be able to license the
other OpenVMS compilers for your new OS, or will you have to write new
ones? Than you need RDB for many applications, but will you be able to
license that?

The project keeps getting bigger when you look at what's necessary to
deliver a system that can be used for commercial work.

John
Johann 'Myrkraverk' Oskarsson
2021-04-25 15:20:48 UTC
Permalink
Post by John Dallman
Post by Johann 'Myrkraverk' Oskarsson
It is not too late to just replace VMS. I don't mean migrate your
code to *nix or something else, but to recreate VMS from scratch,
or at least the parts you're using.
Presumably you'd want to write something with source-level compatibility
on hardware with a future? A new implementation of VMS on IA-64 would be
foolish, since the hardware will soon only be available used. That saves
you from needing perfect binary compatibility, but exposes another big
problem: you need compilers to port applications.
If you're on x86-64, you can use the open-source Clang for OpenVMS, but
that only gets you C and C++. Are you going to be able to license the
other OpenVMS compilers for your new OS, or will you have to write new
ones? Than you need RDB for many applications, but will you be able to
license that?
The project keeps getting bigger when you look at what's necessary to
deliver a system that can be used for commercial work.
I am not going into details of what I can personally deliver, since I
don't know the needs of the funding organizations, if any.

If you want to make a development contract through my employer, we can
talk. Until then, I'd prefer if people kept the discussion to what they
can deliver, or need.

I already have n+1 projcets of my own. I will not add VMS as yet
another side project.
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk
Tim Sneddon
2021-04-27 01:41:10 UTC
Permalink
Post by Johann 'Myrkraverk' Oskarsson
Post by John Dallman
Post by Johann 'Myrkraverk' Oskarsson
It is not too late to just replace VMS. I don't mean migrate your
code to *nix or something else, but to recreate VMS from scratch,
or at least the parts you're using.
Presumably you'd want to write something with source-level compatibility
on hardware with a future? A new implementation of VMS on IA-64 would be
foolish, since the hardware will soon only be available used. That saves
you from needing perfect binary compatibility, but exposes another big
problem: you need compilers to port applications.
If you're on x86-64, you can use the open-source Clang for OpenVMS, but
that only gets you C and C++. Are you going to be able to license the
other OpenVMS compilers for your new OS, or will you have to write new
ones? Than you need RDB for many applications, but will you be able to
license that?
The project keeps getting bigger when you look at what's necessary to
deliver a system that can be used for commercial work.
I am not going into details of what I can personally deliver, since I
don't know the needs of the funding organizations, if any.
So, to paraphrase..."You bet, I can re-write an operating system,
compilers, drivers, etc. blind-folded, hopping on one leg with my hand
tied up my arse, but you just have to believe me, I don't have the time
to tell you how!"

Really..?!

Too busy re-writing Windows from scratch, or maybe UNIX?
Post by Johann 'Myrkraverk' Oskarsson
If you want to make a development contract through my employer, we can
talk. Until then, I'd prefer if people kept the discussion to what they
can deliver, or need.
I already have n+1 projcets of my own. I will not add VMS as yet
another side project.
Right. I had to get up in the morning at ten o'clock at night half an
hour before I went to bed, drink a cup of sulphuric acid, work
twenty-nine hours a day down mill, and pay mill owner for permission
to come to work, and when we got home, our Dad and our mother would
kill us and dance about on our graves singing Hallelujah!

You try and tell the youth of today that...they won't believe ya!
Mark Daniel
2021-04-27 03:00:11 UTC
Permalink
Post by Tim Sneddon
Post by Johann 'Myrkraverk' Oskarsson
Post by John Dallman
Post by Johann 'Myrkraverk' Oskarsson
It is not too late to just replace VMS. I don't mean migrate your
code to *nix or something else, but to recreate VMS from scratch,
or at least the parts you're using.
Presumably you'd want to write something with source-level compatibility
on hardware with a future? A new implementation of VMS on IA-64 would be
foolish, since the hardware will soon only be available used. That saves
you from needing perfect binary compatibility, but exposes another big
problem: you need compilers to port applications.
If you're on x86-64, you can use the open-source Clang for OpenVMS, but
that only gets you C and C++. Are you going to be able to license the
other OpenVMS compilers for your new OS, or will you have to write new
ones? Than you need RDB for many applications, but will you be able to
license that?
The project keeps getting bigger when you look at what's necessary to
deliver a system that can be used for commercial work.
I am not going into details of what I can personally deliver, since I
don't know the needs of the funding organizations, if any.
So, to paraphrase..."You bet, I can re-write an operating system,
compilers, drivers, etc. blind-folded, hopping on one leg with my hand
tied up my arse, but you just have to believe me, I don't have the time
to tell you how!"
Really..?!
Too busy re-writing Windows from scratch, or maybe UNIX?
Post by Johann 'Myrkraverk' Oskarsson
If you want to make a development contract through my employer, we can
talk. Until then, I'd prefer if people kept the discussion to what they
can deliver, or need.
I already have n+1 projcets of my own. I will not add VMS as yet
another side project.
Right. I had to get up in the morning at ten o'clock at night half an
hour before I went to bed, drink a cup of sulphuric acid, work
twenty-nine hours a day down mill, and pay mill owner for permission
to come to work, and when we got home, our Dad and our mother would
kill us and dance about on our graves singing Hallelujah!
You try and tell the youth of today that...they won't believe ya!
+1
--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.
V***@SendSpamHere.ORG
2021-04-27 11:56:15 UTC
Permalink
Post by Tim Sneddon
Post by Johann 'Myrkraverk' Oskarsson
Post by John Dallman
Post by Johann 'Myrkraverk' Oskarsson
It is not too late to just replace VMS. I don't mean migrate your
code to *nix or something else, but to recreate VMS from scratch,
or at least the parts you're using.
Presumably you'd want to write something with source-level compatibility
on hardware with a future? A new implementation of VMS on IA-64 would be
foolish, since the hardware will soon only be available used. That saves
you from needing perfect binary compatibility, but exposes another big
problem: you need compilers to port applications.
If you're on x86-64, you can use the open-source Clang for OpenVMS, but
that only gets you C and C++. Are you going to be able to license the
other OpenVMS compilers for your new OS, or will you have to write new
ones? Than you need RDB for many applications, but will you be able to
license that?
The project keeps getting bigger when you look at what's necessary to
deliver a system that can be used for commercial work.
I am not going into details of what I can personally deliver, since I
don't know the needs of the funding organizations, if any.
So, to paraphrase..."You bet, I can re-write an operating system,
compilers, drivers, etc. blind-folded, hopping on one leg with my hand
tied up my arse, but you just have to believe me, I don't have the time
to tell you how!"
Really..?!
Too busy re-writing Windows from scratch, or maybe UNIX?
Post by Johann 'Myrkraverk' Oskarsson
If you want to make a development contract through my employer, we can
talk. Until then, I'd prefer if people kept the discussion to what they
can deliver, or need.
I already have n+1 projcets of my own. I will not add VMS as yet
another side project.
Right. I had to get up in the morning at ten o'clock at night half an
hour before I went to bed, drink a cup of sulphuric acid, work
twenty-nine hours a day down mill, and pay mill owner for permission
to come to work, and when we got home, our Dad and our mother would
kill us and dance about on our graves singing Hallelujah!
You try and tell the youth of today that...they won't believe ya!
Ah, so you're from Yorkshire, Tim?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Phillip Helbig (undress to reply)
2021-04-27 15:47:14 UTC
Permalink
Post by Tim Sneddon
So, to paraphrase..."You bet, I can re-write an operating system,
compilers, drivers, etc. blind-folded, hopping on one leg with my hand
tied up my arse, but you just have to believe me, I don't have the time
to tell you how!"
I just came from the "compilers on x86" webinar. Very interesting.

Put it this way: several people with decades of experience with VMS have
been working hard for years on this. It is coming along nicely and I am
looking forward to using native compilers on VMS on x86 which support
the latest version of the standard.

Back in the 1930s, some don claimed that anyone with a background in
classics could master physics in a fortnight. Yeah, right.
John Reagan
2021-04-27 20:15:30 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Put it this way: several people with decades of experience with VMS have
been working hard for years on this. It is coming along nicely and I am
looking forward to using native compilers on VMS on x86 which support
the latest version of the standard.
Thanks. There are lots of moving pieces and dark corners to compilers.

To clarify on native compilers and standard support:

The native compilers will be our existing compiler frontends from Itanium with the
exception of we'll be using clang for C++. clang is C++17 with partial C++20 and C++23
support. https://clang.llvm.org/cxx_status.html

In the future (post V9.2), we hope to also provide the flang compiler alongside our current Fortran
compiler to provide f18 support and more. https://flang.llvm.org/docs/ReleaseNotes.html

Running clang as a C11 compiler might not be totally supported by V9.2 as it entails more
stuff in the CRTL and perhaps pthreads (clang as C++ pushes on that interface as well).

Beyond that, there are no plans for standard support for COBOL. Pascal already has much of the
last and final Pascal standard from 1990. BASIC really doesn't have a valid standard that anybody
follows. And of course, BLISS is its own standard.
Scott Dorsey
2021-04-27 21:42:15 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Tim Sneddon
So, to paraphrase..."You bet, I can re-write an operating system,
compilers, drivers, etc. blind-folded, hopping on one leg with my hand
tied up my arse, but you just have to believe me, I don't have the time
to tell you how!"
I just came from the "compilers on x86" webinar. Very interesting.
Put it this way: several people with decades of experience with VMS have
been working hard for years on this. It is coming along nicely and I am
looking forward to using native compilers on VMS on x86 which support
the latest version of the standard.
Compilers are sort of easy, in that gcc has a nice x86 backend and generates
ELF files and you'd only have to rewrite the library functions a bit to be
able to use it on VMS.

Compilers are sort of hard, in that what you want goes way beyond gcc and
in order to be even remotely useful you'd need to support the very specific
DEC supersets of common languages.
Post by Phillip Helbig (undress to reply)
Back in the 1930s, some don claimed that anyone with a background in
classics could master physics in a fortnight. Yeah, right.
There was a lot less physics in the 1930s then there was in the 1950s.
It would have been even easier in 1850 when there was a whole lot less
physics.

Likewise, building a VMS 4.7 clone would be a lot easier than building one
to emulate the latest release.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Phillip Helbig (undress to reply)
2021-04-28 07:00:14 UTC
Permalink
Post by Scott Dorsey
There was a lot less physics in the 1930s then there was in the 1950s.
It would have been even easier in 1850 when there was a whole lot less
physics.
True, but still no way that it could be "mastered in a fortnight", not
even by someone really interested in it, much less a classicist.

1500s: still possible to know "all that is known" in some sense (say
Leonardo).

1600s: still possible to know all about science (say Huygens).

1700s: still possible to know all about one branch of science, say
physics (say Newton).

1800s: still possible to know all about one branch of physics, say
astrophysics.

1900s (up until about 1980): still possible to know about one branch of
astrophysics, say cosmology.

Since then: not even possible to know about a branch of a branch of
physics, much less all of science, much less all of knowledge. Even
keeping up on just one branch of cosmology, say the cosmic microwave
background radiation, is possible for only a few very smart people.
Craig A. Berry
2021-04-28 13:01:11 UTC
Permalink
Post by Phillip Helbig (undress to reply)
1700s: still possible to know all about one branch of science, say
physics (say Newton).
Most of his work was in the 1600s though he did live until 1727 and
produced a couple more books in the early part of that century. Your
point holds, but I don't think he's generally thought of as an
eighteenth-century physicist.
Phillip Helbig (undress to reply)
2021-04-28 15:59:43 UTC
Permalink
Post by Craig A. Berry
Post by Phillip Helbig (undress to reply)
1700s: still possible to know all about one branch of science, say
physics (say Newton).
Most of his work was in the 1600s though he did live until 1727 and
produced a couple more books in the early part of that century. Your
point holds, but I don't think he's generally thought of as an
eighteenth-century physicist.
Yes, he moved from physics to the financial world. That's not uncommon,
even today. :-) He did live until 1727 though.

Interestingly, there was a sort of lull after Newton until physics
picked up a gain in the 19th century with Faraday and so on, though
towards the latter part of the 18th century, astronomy got a big boost
with Herschel (originally a professional musician).
V***@SendSpamHere.ORG
2021-04-28 11:40:15 UTC
Permalink
Post by Scott Dorsey
Post by Phillip Helbig (undress to reply)
Post by Tim Sneddon
So, to paraphrase..."You bet, I can re-write an operating system,
compilers, drivers, etc. blind-folded, hopping on one leg with my hand
tied up my arse, but you just have to believe me, I don't have the time
to tell you how!"
I just came from the "compilers on x86" webinar. Very interesting.
Put it this way: several people with decades of experience with VMS have
been working hard for years on this. It is coming along nicely and I am
looking forward to using native compilers on VMS on x86 which support
the latest version of the standard.
Compilers are sort of easy, in that gcc has a nice x86 backend and generates
ELF files and you'd only have to rewrite the library functions a bit to be
able to use it on VMS.
Compilers are sort of hard, in that what you want goes way beyond gcc and
in order to be even remotely useful you'd need to support the very specific
DEC supersets of common languages.
Post by Phillip Helbig (undress to reply)
Back in the 1930s, some don claimed that anyone with a background in
classics could master physics in a fortnight. Yeah, right.
There was a lot less physics in the 1930s then there was in the 1950s.
It would have been even easier in 1850 when there was a whole lot less
physics.
Likewise, building a VMS 4.7 clone would be a lot easier than building one
to emulate the latest release.
Someone needs to watch their quoting.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Simon Clubley
2021-04-27 12:12:20 UTC
Permalink
Post by Tim Sneddon
Right. I had to get up in the morning at ten o'clock at night half an
hour before I went to bed, drink a cup of sulphuric acid, work
twenty-nine hours a day down mill, and pay mill owner for permission
to come to work, and when we got home, our Dad and our mother would
kill us and dance about on our graves singing Hallelujah!
You try and tell the youth of today that...they won't believe ya!
You forgot the bit about walking uphill both ways. :-)

I think Johann's reply to me says everything. You cannot develop
a new operating system without having at least some ideas even at
this stage about how to answer the questions I asked him.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2021-04-27 12:47:13 UTC
Permalink
Post by Tim Sneddon
Too busy re-writing Windows from scratch, or maybe UNIX?
I've wanted to re-write Unix for quite some time. In Ada. :-)

Back in my Ada Users Group days when I worked for Martin Marietta
I once asked a bigger name in the Ada world than I would ever be
about it. Stressing that it would remove the known security
problems. He told me it could be done but would result in an
OS that was so inefficient as to be unusable. :-)

bill
plugh
2021-04-27 13:31:32 UTC
Permalink
The great thing about c.o.v. is that it has
/always/
/always/
/always/
taken the time to stop and feed the trolls.

For that I thank you, one and all...
Dave Froble
2021-04-27 17:01:13 UTC
Permalink
Post by plugh
The great thing about c.o.v. is that it has
/always/
/always/
/always/
taken the time to stop and feed the trolls.
For that I thank you, one and all...
Glad to be of service ...
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-04-27 17:21:40 UTC
Permalink
Post by Bill Gunshannon
Back in my Ada Users Group days when I worked for Martin Marietta
I once asked a bigger name in the Ada world than I would ever be
about it. Stressing that it would remove the known security
problems. He told me it could be done but would result in an
OS that was so inefficient as to be unusable. :-)
People once used to say the same thing about microkernels.

VAXELN was written in Pascal. DEC actively planned to rewrite the
VMS replacement in Pillar. Why would using Ada impose such a
massively larger overhead than those examples ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2021-04-27 18:31:29 UTC
Permalink
Post by Simon Clubley
Post by Bill Gunshannon
Back in my Ada Users Group days when I worked for Martin Marietta
I once asked a bigger name in the Ada world than I would ever be
about it. Stressing that it would remove the known security
problems. He told me it could be done but would result in an
OS that was so inefficient as to be unusable. :-)
People once used to say the same thing about microkernels.
VAXELN was written in Pascal. DEC actively planned to rewrite the
VMS replacement in Pillar. Why would using Ada impose such a
massively larger overhead than those examples ?
Probably because once it got started Ada picked up a lot of
momentum and the cruft that came along with it. :-)

Always remember Ada started as an Air Force project looking
for a replacement for languages like Jovial, their favorite.
When the project ended and Ada was foisted on the Government
by mandate, The Air Force refused to use it and last I saw,
Wright-Patterson still uses Jovial.

bill
Arne Vajhøj
2021-04-27 19:10:59 UTC
Permalink
Post by Bill Gunshannon
Always remember Ada started as an Air Force project looking
for a replacement for languages like Jovial, their favorite.
When the project ended and Ada was foisted on the Government
by mandate, The Air Force refused to use it and last I saw,
Wright-Patterson still uses Jovial.
https://en.wikipedia.org/wiki/Ada_(programming_language)#History

Arne
Bill Gunshannon
2021-04-28 01:19:23 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Always remember Ada started as an Air Force project looking
for a replacement for languages like Jovial, their favorite.
When the project ended and Ada was foisted on the Government
by mandate, The Air Force refused to use it and last I saw,
Wright-Patterson still uses Jovial.
https://en.wikipedia.org/wiki/Ada_(programming_language)#History
Arne
Looks fairly accurate to what I remember but a little sparse.

I do like the "elephantine" comment, though. :-)

bill
Ian Hammond
2021-04-28 12:40:11 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
Post by Bill Gunshannon
Back in my Ada Users Group days when I worked for Martin Marietta
I once asked a bigger name in the Ada world than I would ever be
about it. Stressing that it would remove the known security
problems. He told me it could be done but would result in an
OS that was so inefficient as to be unusable. :-)
People once used to say the same thing about microkernels.
VAXELN was written in Pascal. DEC actively planned to rewrite the
VMS replacement in Pillar. Why would using Ada impose such a
massively larger overhead than those examples ?
Probably because once it got started Ada picked up a lot of
momentum and the cruft that came along with it. :-)
Always remember Ada started as an Air Force project looking
for a replacement for languages like Jovial, their favorite.
When the project ended and Ada was foisted on the Government
by mandate, The Air Force refused to use it and last I saw,
Wright-Patterson still uses Jovial.
bill
When I did some (free) work for the U.S. Air Force in the 80's, I saw some
Fortran code where each subroutine was prefixed by the same function written
in Ada, embedded in the comments. This craziness was a workaround to
satisfy the requirement that all new code be written in Ada. Working around
bureaucracy was part of their daily life.
Arne Vajhøj
2021-04-27 18:57:14 UTC
Permalink
Post by Simon Clubley
Post by Bill Gunshannon
Back in my Ada Users Group days when I worked for Martin Marietta
I once asked a bigger name in the Ada world than I would ever be
about it. Stressing that it would remove the known security
problems. He told me it could be done but would result in an
OS that was so inefficient as to be unusable. :-)
People once used to say the same thing about microkernels.
VAXELN was written in Pascal. DEC actively planned to rewrite the
VMS replacement in Pillar. Why would using Ada impose such a
massively larger overhead than those examples ?
Ada is more strict than Pascal.

But I would be surprised if an OS written in Ada would
not work fine on todays hardware. Those checks should
not be so bad with modern CPU.

But no mainstream OS has been created in more than 25
years.

And today the alternative to C would probably be
Rust not Ada.

Arne
Simon Clubley
2021-04-28 12:59:44 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Bill Gunshannon
Back in my Ada Users Group days when I worked for Martin Marietta
I once asked a bigger name in the Ada world than I would ever be
about it. Stressing that it would remove the known security
problems. He told me it could be done but would result in an
OS that was so inefficient as to be unusable. :-)
People once used to say the same thing about microkernels.
VAXELN was written in Pascal. DEC actively planned to rewrite the
VMS replacement in Pillar. Why would using Ada impose such a
massively larger overhead than those examples ?
Ada is more strict than Pascal.
Most of those extra checks are at compile time, not during execution.

That's the whole point of Ada.

What's left during execution is sort-of roughly comparable to the
other Wirth style languages.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-04-28 15:28:33 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Post by Bill Gunshannon
Back in my Ada Users Group days when I worked for Martin Marietta
I once asked a bigger name in the Ada world than I would ever be
about it. Stressing that it would remove the known security
problems. He told me it could be done but would result in an
OS that was so inefficient as to be unusable. :-)
People once used to say the same thing about microkernels.
VAXELN was written in Pascal. DEC actively planned to rewrite the
VMS replacement in Pillar. Why would using Ada impose such a
massively larger overhead than those examples ?
Ada is more strict than Pascal.
Most of those extra checks are at compile time, not during execution.
That's the whole point of Ada.
What's left during execution is sort-of roughly comparable to the
other Wirth style languages.
My Ada skills are not that over hello world level.

But even I can produce a runtime difference.

$ type ii.pas
program ii(input, output);

type
onetoten = 1..10;

var
v : onetoten;

begin
writeln('Pascal here');
write('Enter number: ');
readln(v);
writeln(v);
end.
$ pas ii
$ lin ii
$ define/user sys$input sys$command
$ run ii
Pascal here
Enter number: 3
3
$ define/user sys$input sys$command
$ run ii
Pascal here
Enter number: 1111
1111
$ delete ii.exe;*,ii.obj;*
$ type ii.adb
with Ada.Text_IO, Ada.Integer_Text_IO;

use Ada.Text_IO, Ada.Integer_Text_IO;

procedure II is

subtype OneToTen is Integer range 1..10;

V : OneToTen;

begin
Put("Ada here");
New_Line;
Put("Enter number: ");
Flush;
Get(V);
Put(V);
New_Line;
end II;
$ gnat make ii.adb
gcc -c ii.adb
gnatbind -x ii.ali
gnatlink ii.ali
GNU:[LIB]CRT0.OBJ
DISK2:[ARNE]B$II.OBJ
DISK2:[]II.OBJ
GNU:[LIB.OPENVMS7_1.2_8_1.DECLIB]LIBDECGNAT.OLB/library
GNU:[LIB.OPENVMS7_1.2_8_1.ADALIB]LIBGNAT.EXE/shareable
GNU:[LIB]LIBGCC.OLB/library
sys$library:vaxcrtltx.olb/library
GNU:[LIB]LIBGCC.OLB/library
$ define/user sys$input sys$command
$ run ii
Ada here
Enter number: 3
3
$ define/user sys$input sys$command
$ run ii
Ada here
Enter number: 1111

raised CONSTRAINT_ERROR : a-tiinio.ads:61

Arne
John Wallace
2021-04-28 16:48:58 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Post by Bill Gunshannon
Back in my Ada Users Group days when I worked for Martin Marietta
I once asked a bigger name in the Ada world than I would ever be
about it.  Stressing that it would remove the known security
problems.  He told me it could be done but would result in an
OS that was so inefficient as to be unusable.  :-)
People once used to say the same thing about microkernels.
VAXELN was written in Pascal. DEC actively planned to rewrite the
VMS replacement in Pillar. Why would using Ada impose such a
massively larger overhead than those examples ?
Ada is more strict than Pascal.
Most of those extra checks are at compile time, not during execution.
That's the whole point of Ada.
What's left during execution is sort-of roughly comparable to the
other Wirth style languages.
My Ada skills are not that over hello world level.
But even I can produce a runtime difference.
$ type ii.pas
program ii(input, output);
type
 onetoten = 1..10;
var
 v : onetoten;
begin
 writeln('Pascal here');
 write('Enter number: ');
 readln(v);
 writeln(v);
end.
$ pas ii
$ lin ii
$ define/user sys$input sys$command
$ run ii
Pascal here
Enter number: 3
        3
$ define/user sys$input sys$command
$ run ii
Pascal here
Enter number: 1111
     1111
$ delete ii.exe;*,ii.obj;*
$ type ii.adb
with Ada.Text_IO, Ada.Integer_Text_IO;
use Ada.Text_IO, Ada.Integer_Text_IO;
procedure II is
subtype OneToTen is Integer range 1..10;
V : OneToTen;
begin
   Put("Ada here");
   New_Line;
   Put("Enter number: ");
   Flush;
   Get(V);
   Put(V);
   New_Line;
end II;
$ gnat make ii.adb
gcc -c ii.adb
gnatbind -x ii.ali
gnatlink ii.ali
GNU:[LIB]CRT0.OBJ
DISK2:[ARNE]B$II.OBJ
DISK2:[]II.OBJ
GNU:[LIB.OPENVMS7_1.2_8_1.DECLIB]LIBDECGNAT.OLB/library
GNU:[LIB.OPENVMS7_1.2_8_1.ADALIB]LIBGNAT.EXE/shareable
GNU:[LIB]LIBGCC.OLB/library
sys$library:vaxcrtltx.olb/library
GNU:[LIB]LIBGCC.OLB/library
$ define/user sys$input sys$command
$ run ii
Ada here
Enter number: 3
         3
$ define/user sys$input sys$command
$ run ii
Ada here
Enter number: 1111
raised CONSTRAINT_ERROR : a-tiinio.ads:61
Arne
You might want to think about your compile-time options for runtime
subrange checking.

If I remember rightly, runtime subrange checking is not enabled by
default in DEC/CPQ/VSI Pascal. Have a read of The Fine Manual or
equivalent, compile with runtime subrange checking enabled and then see
what you get?

Clearly the equivalent Ada option is active in your example. But runtime
subrange checking in Ada can be, and frequently is, disabled for reasons
of "efficiency".

Which of those choices makes sense in any particular case is a different
matter.
Arne Vajhøj
2021-04-28 17:58:20 UTC
Permalink
Post by John Wallace
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Ada is more strict than Pascal.
Most of those extra checks are at compile time, not during execution.
That's the whole point of Ada.
What's left during execution is sort-of roughly comparable to the
other Wirth style languages.
My Ada skills are not that over hello world level.
But even I can produce a runtime difference.
$ define/user sys$input sys$command
$ run ii
Pascal here
Enter number: 3
         3
$ define/user sys$input sys$command
$ run ii
Pascal here
Enter number: 1111
      1111
$ define/user sys$input sys$command
$ run ii
Ada here
Enter number: 3
          3
$ define/user sys$input sys$command
$ run ii
Ada here
Enter number: 1111
raised CONSTRAINT_ERROR : a-tiinio.ads:61
You might want to think about your compile-time options for runtime
subrange checking.
/CHECK=SUBRANGE gets it to complain.

And VMS Pascal does better than FPC:

C:\Work>ii
Pascal here
Enter number: 1111
87

Not only does it not range check - it also does a silent truncate to 1 byte.
Post by John Wallace
If I remember rightly, runtime subrange checking is not enabled by
default in DEC/CPQ/VSI Pascal. Have a read of The Fine Manual or
equivalent, compile with runtime subrange checking enabled and then see
what you get?
Clearly the equivalent Ada option is active in your example. But runtime
subrange checking in Ada can be, and frequently is, disabled for reasons
of "efficiency".
Yes. But defaults gives a view into what is considered desirable.

I have not checked the language specs, but I would not be surprised
if the Ada spec required such check to at least be possible, while
the Pascal spec did not.

Arne
John Reagan
2021-04-28 20:19:47 UTC
Permalink
Post by Arne Vajhøj
Post by John Wallace
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Ada is more strict than Pascal.
Most of those extra checks are at compile time, not during execution.
That's the whole point of Ada.
What's left during execution is sort-of roughly comparable to the
other Wirth style languages.
My Ada skills are not that over hello world level.
But even I can produce a runtime difference.
$ define/user sys$input sys$command
$ run ii
Pascal here
Enter number: 3
3
$ define/user sys$input sys$command
$ run ii
Pascal here
Enter number: 1111
1111
$ define/user sys$input sys$command
$ run ii
Ada here
Enter number: 3
3
$ define/user sys$input sys$command
$ run ii
Ada here
Enter number: 1111
raised CONSTRAINT_ERROR : a-tiinio.ads:61
You might want to think about your compile-time options for runtime
subrange checking.
/CHECK=SUBRANGE gets it to complain.
C:\Work>ii
Pascal here
Enter number: 1111
87
Not only does it not range check - it also does a silent truncate to 1 byte.
Post by John Wallace
If I remember rightly, runtime subrange checking is not enabled by
default in DEC/CPQ/VSI Pascal. Have a read of The Fine Manual or
equivalent, compile with runtime subrange checking enabled and then see
what you get?
Clearly the equivalent Ada option is active in your example. But runtime
subrange checking in Ada can be, and frequently is, disabled for reasons
of "efficiency".
Yes. But defaults gives a view into what is considered desirable.
I have not checked the language specs, but I would not be surprised
if the Ada spec required such check to at least be possible, while
the Pascal spec did not.
Arne
The Pascal standard leaves most of these run-time checks as implementation dependent.

The decision for VAX Pascal V2 on what the default was for /CHECK was based on the perceived overhead of the run-time checking. I use /CHECK almost all the time.
John Reagan
2021-04-28 20:16:42 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Post by Bill Gunshannon
Back in my Ada Users Group days when I worked for Martin Marietta
I once asked a bigger name in the Ada world than I would ever be
about it. Stressing that it would remove the known security
problems. He told me it could be done but would result in an
OS that was so inefficient as to be unusable. :-)
People once used to say the same thing about microkernels.
VAXELN was written in Pascal. DEC actively planned to rewrite the
VMS replacement in Pillar. Why would using Ada impose such a
massively larger overhead than those examples ?
Ada is more strict than Pascal.
Most of those extra checks are at compile time, not during execution.
That's the whole point of Ada.
What's left during execution is sort-of roughly comparable to the
other Wirth style languages.
My Ada skills are not that over hello world level.
But even I can produce a runtime difference.
$ type ii.pas
program ii(input, output);
type
onetoten = 1..10;
var
v : onetoten;
begin
writeln('Pascal here');
write('Enter number: ');
readln(v);
writeln(v);
end.
$ pas ii
$ lin ii
$ define/user sys$input sys$command
$ run ii
Pascal here
Enter number: 3
3
$ define/user sys$input sys$command
$ run ii
Pascal here
Enter number: 1111
1111
Pascal's checking is off by default. You have to ask for it

$ pascal/check check
$ link check
$ run check
Pascal here
Enter number: 1111
%PAS-F-SUBASGVAL, subrange assignment value is out of range
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
CHECK II II 12 0000000000000100 0000000000010100
0 FFFFFFFF80AA2152 FFFFFFFF80AA2152
DCL 0 000000000007D2B2 000000007AE312B2
%TRACE-I-END, end of TRACE stack dump
Zane H. Healy
2021-04-28 15:33:28 UTC
Permalink
Post by Bill Gunshannon
Post by Tim Sneddon
Too busy re-writing Windows from scratch, or maybe UNIX?
I've wanted to re-write Unix for quite some time. In Ada. :-)
Back in my Ada Users Group days when I worked for Martin Marietta
I once asked a bigger name in the Ada world than I would ever be
about it. Stressing that it would remove the known security
problems. He told me it could be done but would result in an
OS that was so inefficient as to be unusable. :-)
bill
Have you by any chance seen or heard of PULSE? I tried to find out if it
still existed in any form back in 2003. Interestingly I see that my copy of
the book has a couple printouts, showing I'd hit a dead-end. One was a
reply from one of the authors of the book. At that time no one knew if the
source still existed.

Book:
"PULSE: An Ada-based Distributed Operating System"
D. Keeffe, G.M. Tomlinson, I.C. Wand and A.J. Wellings
APIC Studies in Data Processing No. 26
(c) 1985

It says the OS attempts to take the best features of UNIX and apply them to
a distributed environment using Ada as the implementation language.

Apparently they started develpment on the PDP-11, and then moved to VAX.

Zane
Arne Vajhøj
2021-04-28 17:43:54 UTC
Permalink
Post by Zane H. Healy
Post by Bill Gunshannon
Post by Tim Sneddon
Too busy re-writing Windows from scratch, or maybe UNIX?
I've wanted to re-write Unix for quite some time. In Ada. :-)
Back in my Ada Users Group days when I worked for Martin Marietta
I once asked a bigger name in the Ada world than I would ever be
about it. Stressing that it would remove the known security
problems. He told me it could be done but would result in an
OS that was so inefficient as to be unusable. :-)
Have you by any chance seen or heard of PULSE? I tried to find out if it
still existed in any form back in 2003. Interestingly I see that my copy of
the book has a couple printouts, showing I'd hit a dead-end. One was a
reply from one of the authors of the book. At that time no one knew if the
source still existed.
"PULSE: An Ada-based Distributed Operating System"
D. Keeffe, G.M. Tomlinson, I.C. Wand and A.J. Wellings
APIC Studies in Data Processing No. 26
(c) 1985
It says the OS attempts to take the best features of UNIX and apply them to
a distributed environment using Ada as the implementation language.
Apparently they started develpment on the PDP-11, and then moved to VAX.
Lots of stuff are done experimental.

Microsoft did an experimental OS called Singularity where they
did kernel and device drivers in managed code (C#).

Arne
Arne Vajhøj
2021-04-25 16:01:14 UTC
Permalink
Post by John Dallman
Post by Johann 'Myrkraverk' Oskarsson
It is not too late to just replace VMS. I don't mean migrate your
code to *nix or something else, but to recreate VMS from scratch,
or at least the parts you're using.
Presumably you'd want to write something with source-level compatibility
on hardware with a future? A new implementation of VMS on IA-64 would be
foolish, since the hardware will soon only be available used. That saves
you from needing perfect binary compatibility, but exposes another big
problem: you need compilers to port applications.
If you're on x86-64, you can use the open-source Clang for OpenVMS, but
that only gets you C and C++. Are you going to be able to license the
other OpenVMS compilers for your new OS, or will you have to write new
ones? Than you need RDB for many applications, but will you be able to
license that?
The project keeps getting bigger when you look at what's necessary to
deliver a system that can be used for commercial work.
clang will not even make it for C/C++.

There are all the DEC C extensions / quirks.

Sure getting read of all that stuff in the code and go with
nice standard C/C++ would be great.

But code with all the bad stuff exists today. And if someone
is to do a major cleanup then porting off VMS may make sense.

Arne
Gianluca Bonetti
2021-04-27 09:26:49 UTC
Permalink
Post by Johann 'Myrkraverk' Oskarsson
Dear c.o.vms,
In light of recent discussions about licenses from VSI expiring, I bring
up the following point. For reference: I am not a VSI customer, but I
hope to be in the future.
It is not too late to just replace VMS. I don't mean migrate your code
to *nix or something else, but to recreate VMS from scratch, or at least
the parts you're using.
Don't take my word for the legality of it, run the recent SCOTUS ruling
in Oracle vs. Google through your legal department, and get back to me.
The project itself doesn't have to be open source; even with closed
source, you can still start with n+1 open source kernels to bootstrap
the project.
People who participate can be confident they can run the system license
free forever, at the cost of maintaining an OS [1]. Even if VSI relents
and changes its licensing policies, I'd still consider investing in such
a project, for future prooving my business.
[1] Which is not cheap, today.
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
Hello

There was an open source project called FreeVMS, to recreate VMS on x86 hardware.
It started on 32 bit systems at the time, and I'm not sure whether 64 bit port ever started.

Now it had almost disappeared from the internet, just to give you an idea about the interest in this project.
To vanish from the internet, is something difficult to do even if you want to, and FreeVMS almost vanished without too many efforts.
FreeVMS.net domain name now hosts a retro gaming website.

There are some repositories on github which seem to host that code, or part of, but I'm not sure which one is the most up to date version as they all look different.
https://github.com/wazoox/FreeVMS
https://github.com/rroart/freevms
https://github.com/ztmr/FreeVMS

Cheers
Gianluca
JKB
2021-04-27 10:05:49 UTC
Permalink
Post by Gianluca Bonetti
Hello
There was an open source project called FreeVMS, to recreate VMS on x86 hardware.
It started on 32 bit systems at the time, and I'm not sure whether 64 bit port ever started.
Now it had almost disappeared from the internet, just to give you an idea about the interest in this project.
To vanish from the internet, is something difficult to do even if you want to, and FreeVMS almost vanished without too many efforts.
FreeVMS.net domain name now hosts a retro gaming website.
There are some repositories on github which seem to host that code, or part of, but I'm not sure which one is the most up to date version as they all look different.
https://github.com/wazoox/FreeVMS
https://github.com/rroart/freevms
https://github.com/ztmr/FreeVMS
Main git tree is : git://rayleigh.systella.fr/FreeVMS.git.

www.freevms.net was not renewed after a crash disk. pager and
swapper have to be written for 0.4.

JKB
--
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.
plugh
2021-04-27 14:02:57 UTC
Permalink
Post by Gianluca Bonetti
Hello
There was an open source project called FreeVMS, to recreate VMS on x86 hardware.
It started on 32 bit systems at the time, and I'm not sure whether 64 bit port ever started.
Now it had almost disappeared from the internet, just to give you an idea about the interest in this project.
To vanish from the internet, is something difficult to do even if you want to, and FreeVMS almost vanished without too many efforts.
FreeVMS.net domain name now hosts a retro gaming website.
I've been meaning to ask - what was the name of the DOS (?) package that emulated VMS logical names, maybe DCL? Maybe from the late '80s?
John Dallman
2021-04-27 14:47:00 UTC
Permalink
Post by plugh
I've been meaning to ask - what was the name of the DOS (?) package
that emulated VMS logical names, maybe DCL? Maybe from the late
'80s?
https://jonesrh.info/dcll/index.html

John
plugh
2021-04-27 15:05:39 UTC
Permalink
Post by John Dallman
Post by plugh
I've been meaning to ask - what was the name of the DOS (?) package
that emulated VMS logical names, maybe DCL? Maybe from the late
'80s?
https://jonesrh.info/dcll/index.html
John
Thanks, but that's not it. It was advertised, I think, in the RSTS/E magazine. I doubt it was the other magazines from that era (C user's journal being the most likely in my case).

Looks very interesting. It's a product similar to the one I recall "... when I flog my memory." I think the company was in Montana, or Wyoming. Definitely pre-internet.
V***@SendSpamHere.ORG
2021-04-27 20:36:45 UTC
Permalink
Post by plugh
Post by John Dallman
Post by plugh
I've been meaning to ask - what was the name of the DOS (?) package
that emulated VMS logical names, maybe DCL? Maybe from the late
'80s?
https://jonesrh.info/dcll/index.html
John
Thanks, but that's not it. It was advertised, I think, in the RSTS/E magazine. I doubt it was the other magazines from that era (C user's journal being the most likely in my case).
Looks very interesting. It's a product similar to the one I recall "... when I flog my memory." I think the company was in Montana, or Wyoming. Definitely pre-internet.
Wendin Assoc. PC-VMS. Company was in Washington State.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Alan Frisbie
2021-04-27 15:00:43 UTC
Permalink
Post by plugh
I've been meaning to ask - what was the name of the DOS (?) package
that emulated VMS logical names, maybe DCL? Maybe from the late '80s?
VCL from Boston Business Computing, Ltd., "The Leader in VMS-to-Unix
Solutions". It allowed you to run simple DCL scripts on Linux.

I used their EDT+ product on both Linux and Windows and wish it were
still around. They also sold VBackup, which wrote & read
VMS-compatible save sets. Other products included Vmail and Vnet,
but I don't know anything about them.

I've still got their T-shirt with musical notes and the words,
"I've got that VMS feeling..." on the front and "...oh, that
VMS feeling" on the back.

Alan "Packrat" Frisbie
plugh
2021-04-27 15:07:54 UTC
Permalink
Post by Alan Frisbie
Post by plugh
I've been meaning to ask - what was the name of the DOS (?) package
that emulated VMS logical names, maybe DCL? Maybe from the late '80s?
VCL from Boston Business Computing, Ltd., "The Leader in VMS-to-Unix
Solutions". It allowed you to run simple DCL scripts on Linux.
It pre-dated Linux by several years. This was for DOS. I think it came after the shift to DCL on RSTS/E
This was all pre-internet.
plugh
2021-04-27 15:19:17 UTC
Permalink
Found it:
https://vetusware.com/download/Operating%20System%20Toolbox%20_OST_%201.08/?id=16645

Forensics in 3,2,1...
plugh
2021-04-27 15:29:32 UTC
Permalink
Post by plugh
https://vetusware.com/download/Operating%20System%20Toolbox%20_OST_%201.08/?id=16645
Forensics in 3,2,1
Computer Language cover, Feb-1987
https://drive.google.com/file/d/1Fibanhi3fBMwhye_Iao8Y4Xe3LcecyS3/view?usp=sharing

Full page ad
https://drive.google.com/file/d/1FaGJcOpQRdCLcbMc_7CwZJLYRwt8hg9-/view?usp=sharing

HLMGTFY
https://supratim-sanyal.blogspot.com/2020/12/pcvms-taking-aspirational-dos-based-vms.html
David Turner
2021-04-30 00:04:30 UTC
Permalink
People bringing this up reminds me that perhaps an Alpha emulator and a
very faxt x86 box is worth going to
I mean, most people migrated from Alpha to HP Integrity. I bet going
back to Alpha, but on an emulator, would not be that big a deal.
Most people I am sure still have their ALpha PERPETUAL licenses

Then to fix issues with the oft-complained about part of VMS, the slow
networking, go to multinet

A thought right?!?!?!


DT
Post by plugh
Post by plugh
https://vetusware.com/download/Operating%20System%20Toolbox%20_OST_%201.08/?id=16645
Forensics in 3,2,1
Computer Language cover, Feb-1987
https://drive.google.com/file/d/1Fibanhi3fBMwhye_Iao8Y4Xe3LcecyS3/view?usp=sharing
Full page ad
https://drive.google.com/file/d/1FaGJcOpQRdCLcbMc_7CwZJLYRwt8hg9-/view?usp=sharing
HLMGTFY
https://supratim-sanyal.blogspot.com/2020/12/pcvms-taking-aspirational-dos-based-vms.html
Chris Townley
2021-04-30 00:13:23 UTC
Permalink
Post by David Turner
People bringing this up reminds me that perhaps an Alpha emulator and a
very faxt x86 box is worth going to
I mean, most people migrated from Alpha to HP Integrity. I bet going
back to Alpha, but on an emulator, would not be that big a deal.
Most people I am sure still have their ALpha PERPETUAL licenses
Then to fix issues with the oft-complained about part of VMS, the slow
networking, go to multinet
A thought right?!?!?!
Is Multinet much better than TCPWare?

Chris
Michael C
2021-05-13 22:35:35 UTC
Permalink
Post by Chris Townley
Post by David Turner
People bringing this up reminds me that perhaps an Alpha emulator and a
very faxt x86 box is worth going to
I mean, most people migrated from Alpha to HP Integrity. I bet going
back to Alpha, but on an emulator, would not be that big a deal.
Most people I am sure still have their ALpha PERPETUAL licenses
Then to fix issues with the oft-complained about part of VMS, the slow
networking, go to multinet
A thought right?!?!?!
Is Multinet much better than TCPWare?
Chris
NO! It is slower and not VMS like in command feel.
k***@gmail.com
2021-05-13 23:18:12 UTC
Permalink
-----Original Message-----
Info-vax
Sent: May-13-21 7:36 PM
Subject: Re: [Info-vax] A new VMS?
Post by Chris Townley
Post by David Turner
People bringing this up reminds me that perhaps an Alpha emulator
and a very faxt x86 box is worth going to I mean, most people
migrated from Alpha to HP Integrity. I bet going back to Alpha, but
on an emulator, would not be that big a deal.
Most people I am sure still have their ALpha PERPETUAL licenses
Then to fix issues with the oft-complained about part of VMS, the
slow networking, go to multinet
A thought right?!?!?!
Is Multinet much better than TCPWare?
Chris
NO! It is slower and not VMS like in command feel.
_______________________________________________
I disagree - this may have been true a long time ago, but not for recent
changes in Mutlinet.

There have been many performance enhancements in Mutlinet over the last few
years, so I suspect this is no longer true.

Sample of recent version Multinet enhancements:
<https://www.process.com/products/multinet/whats_new.html>

It is true that Multinet does have a UNIX background, so its initial
look-and-feel might be a bit more familiar to UNIX/Networking types.

However, like all interfaces, it just takes a bit of experience with it.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
Simon Clubley
2021-05-14 12:08:30 UTC
Permalink
Post by k***@gmail.com
It is true that Multinet does have a UNIX background, so its initial
look-and-feel might be a bit more familiar to UNIX/Networking types.
No. I am not going to talk about performance, because I don't have enough
knowledge about that, but Bob is right about the interface.

Multinet has a TOPS-20 feel to it, not Unix and it's yucky to work with.
Post by k***@gmail.com
However, like all interfaces, it just takes a bit of experience with it.
Some interfaces are easier to learn than others.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
k***@gmail.com
2021-05-18 00:29:24 UTC
Permalink
-----Original Message-----
via Info-vax
Sent: May-14-21 9:09 AM
Subject: Re: [Info-vax] A new VMS?
Post by k***@gmail.com
It is true that Multinet does have a UNIX background, so its initial
look-and-feel might be a bit more familiar to UNIX/Networking types.
No. I am not going to talk about performance, because I don't have enough
knowledge about that, but Bob is right about the interface.
Multinet has a TOPS-20 feel to it, not Unix and it's yucky to work with.
Post by k***@gmail.com
However, like all interfaces, it just takes a bit of experience with it.
Some interfaces are easier to learn than others.
Simon.
Reference:
<http://www3.sympatico.ca/n.rieck/docs/openvms_notes_tcpware.html>

"MultiNet was a competitor to TCPware originally created by TGV. PSC
(Process Software Corp) purchased the MultiNet stack from CISCO in 1997 so
now they sell two stacks but only MultiNet is capable of both IPv4 and
IPv6."

Hunter would likely be able to provide much more detail on Multinet history
specifics.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
Simon Clubley
2021-04-30 04:36:17 UTC
Permalink
Post by David Turner
People bringing this up reminds me that perhaps an Alpha emulator and a
very faxt x86 box is worth going to
I mean, most people migrated from Alpha to HP Integrity. I bet going
back to Alpha, but on an emulator, would not be that big a deal.
Most people I am sure still have their ALpha PERPETUAL licenses
Then to fix issues with the oft-complained about part of VMS, the slow
networking, go to multinet
A thought right?!?!?!
You would have to use a version of Alpha VMS that is still supported
by VSI so that security issues (and any other issues) would be fixed
as they occur.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Jan-Erik Söderholm
2021-04-30 07:13:30 UTC
Permalink
Post by Simon Clubley
Post by David Turner
People bringing this up reminds me that perhaps an Alpha emulator and a
very faxt x86 box is worth going to
I mean, most people migrated from Alpha to HP Integrity. I bet going
back to Alpha, but on an emulator, would not be that big a deal.
Most people I am sure still have their ALpha PERPETUAL licenses
Then to fix issues with the oft-complained about part of VMS, the slow
networking, go to multinet
A thought right?!?!?!
You would have to use a version of Alpha VMS that is still supported
by VSI so that security issues (and any other issues) would be fixed
as they occur.
Simon.
"Still"? It is today and the raodmap has "standard support" for
Alpha 8.4-2L1 and 8.4-2L2 until 2030. Not that the support actually
ends there, the roadmap just doesn't go any further today.
Simon Clubley
2021-04-30 12:14:06 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by David Turner
People bringing this up reminds me that perhaps an Alpha emulator and a
very faxt x86 box is worth going to
I mean, most people migrated from Alpha to HP Integrity. I bet going
back to Alpha, but on an emulator, would not be that big a deal.
Most people I am sure still have their ALpha PERPETUAL licenses
Then to fix issues with the oft-complained about part of VMS, the slow
networking, go to multinet
A thought right?!?!?!
You would have to use a version of Alpha VMS that is still supported
by VSI so that security issues (and any other issues) would be fixed
as they occur.
Simon.
"Still"? It is today and the raodmap has "standard support" for
Alpha 8.4-2L1 and 8.4-2L2 until 2030. Not that the support actually
ends there, the roadmap just doesn't go any further today.
Yes, "still". Read what David is suggesting. He is talking about going
back to the traditional perpetual licences and the way he phrases it he is
talking about the old HPE licences because he talks about "HP Integrity"
not "VSI Integrity".

That's why I am pointing out that may not be good enough and you would
need to use one of the Alpha VMS versions supported by VSI in order to
get patches for security and other issues. From comments recently, it
appears the newer VSI Alpha VMS licences are also time-limited unlike
the earlier Alpha VMS licences you clearly have.

Also, are those people now using versions of products on Itanium that are
simply not available for Alpha ? I don't think David's suggestion is
viable for a number of reasons and these are just a couple of those reasons.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Jan-Erik Söderholm
2021-04-30 12:48:48 UTC
Permalink
Post by Simon Clubley
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by David Turner
People bringing this up reminds me that perhaps an Alpha emulator and a
very faxt x86 box is worth going to
I mean, most people migrated from Alpha to HP Integrity. I bet going
back to Alpha, but on an emulator, would not be that big a deal.
Most people I am sure still have their ALpha PERPETUAL licenses
Then to fix issues with the oft-complained about part of VMS, the slow
networking, go to multinet
A thought right?!?!?!
You would have to use a version of Alpha VMS that is still supported
by VSI so that security issues (and any other issues) would be fixed
as they occur.
Simon.
"Still"? It is today and the raodmap has "standard support" for
Alpha 8.4-2L1 and 8.4-2L2 until 2030. Not that the support actually
ends there, the roadmap just doesn't go any further today.
Yes, "still". Read what David is suggesting. He is talking about going
back to the traditional perpetual licences and the way he phrases it he is
talking about the old HPE licences because he talks about "HP Integrity"
not "VSI Integrity".
That's why I am pointing out that may not be good enough and you would
need to use one of the Alpha VMS versions supported by VSI in order to
get patches for security and other issues. From comments recently, it
appears the newer VSI Alpha VMS licences are also time-limited unlike
the earlier Alpha VMS licences you clearly have.
Also, are those people now using versions of products on Itanium that are
simply not available for Alpha ? I don't think David's suggestion is
viable for a number of reasons and these are just a couple of those reasons.
Simon.
Agree, staying on Alpha is not particulally forward-looking.
Our Alpha *VSI* PAKs are perpetual. And they was not renewed
or replaced when we prolonged the earlier 3 year contract
another 2 years last summer (2020).

We had a meeting today around a larger change project for our
envionment and I had some points on not to invest developer time
using tools that are not available on x86, but they were more
interested in how this OpenVMS "thing" could be thrown out...
Dave Froble
2021-04-30 15:34:50 UTC
Permalink
Post by Jan-Erik Söderholm
We had a meeting today around a larger change project for our
envionment and I had some points on not to invest developer time
using tools that are not available on x86, but they were more
interested in how this OpenVMS "thing" could be thrown out...
I'm curious Jan-Erik. What were the reasons for wanting to "throw out"
VMS? Reasonable? Or bigotry?
--
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
2021-04-30 18:27:12 UTC
Permalink
Post by Jan-Erik Söderholm
We had a meeting today around a larger change project for our
envionment and I had some points on not to invest developer time
using tools that are not available on x86, but they were more
interested in how this OpenVMS "thing" could be thrown out...
I'm curious Jan-Erik.  What were the reasons for wanting to "throw out"
VMS?  Reasonable?  Or bigotry?
Sometimes the line between "we want to run something where we can get
people with skills and all the normal tools are available" and "we want
to run the same as everybody else to avoid criticism" can be hard to
determine.

Arne
Dave Froble
2021-04-30 19:41:20 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Jan-Erik Söderholm
We had a meeting today around a larger change project for our
envionment and I had some points on not to invest developer time
using tools that are not available on x86, but they were more
interested in how this OpenVMS "thing" could be thrown out...
I'm curious Jan-Erik. What were the reasons for wanting to "throw
out" VMS? Reasonable? Or bigotry?
Sometimes the line between "we want to run something where we can get
people with skills and all the normal tools are available" and "we want
to run the same as everybody else to avoid criticism" can be hard to
determine.
I've been there. One former customer came under the influence of a
manager that wanted things his way. Spent millions, and, that company
no longer exists.

Do what you want, be prepared to pay the price. It's unfortunate that
the manager didn't pay the price, the company owner did.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-04-30 22:28:50 UTC
Permalink
Post by Jan-Erik Söderholm
We had a meeting today around a larger change project for our
envionment and I had some points on not to invest developer time
using tools that are not available on x86, but they were more
interested in how this OpenVMS "thing" could be thrown out...
I'm curious Jan-Erik.  What were the reasons for wanting to "throw out"
VMS?  Reasonable?  Or bigotry?
Good question. Their VMS systems is simply "something from the past"
that has to be replaced sooner or later. There is nothing but issues
as it is right now. Old and desuported hardware. Issues to get staff
with OpenVMS knowledge. Not a "standard" platform. Those who knows
anything about the system (me) can quite and retire anytime, and that
would be a major issue to handle.

But the services that this system supplies are just great from the
users perspective. Fast with short response times. Flexible. Fairly
easy to adjust and adopt the in-house software. Fast implementations
to new production equipment.

My *personal* view is that we could do a lot to keep the main/core
system but replace VT-based UI with more modern and flexible web
based UI. But no investments in that since "it is going to be
replaced anyway"...
Dave Froble
2021-04-30 23:53:38 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Jan-Erik Söderholm
We had a meeting today around a larger change project for our
envionment and I had some points on not to invest developer time
using tools that are not available on x86, but they were more
interested in how this OpenVMS "thing" could be thrown out...
I'm curious Jan-Erik. What were the reasons for wanting to "throw
out" VMS? Reasonable? Or bigotry?
Good question. Their VMS systems is simply "something from the past"
that has to be replaced sooner or later. There is nothing but issues
as it is right now. Old and desuported hardware. Issues to get staff
with OpenVMS knowledge. Not a "standard" platform.
Ok, next question. What is a "standard platform" ?
Post by Jan-Erik Söderholm
Those who knows
anything about the system (me) can quite and retire anytime, and that
would be a major issue to handle.
But, they won't have you train anyone, because, "it is going to be
replaced anyway", huh?
Post by Jan-Erik Söderholm
But the services that this system supplies are just great from the
users perspective. Fast with short response times. Flexible. Fairly
easy to adjust and adopt the in-house software. Fast implementations
to new production equipment.
Oh, my, can't have that! Where is the job security for the IT people?
Post by Jan-Erik Söderholm
My *personal* view is that we could do a lot to keep the main/core
system but replace VT-based UI with more modern and flexible web
based UI. But no investments in that since "it is going to be
replaced anyway"...
Well, you do have experience with WASD ...

But, I'm going to assume that "fast with short response times" just
might suffer some.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-05-01 08:26:54 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Jan-Erik Söderholm
We had a meeting today around a larger change project for our
envionment and I had some points on not to invest developer time
using tools that are not available on x86, but they were more
interested in how this OpenVMS "thing" could be thrown out...
I'm curious Jan-Erik.  What were the reasons for wanting to "throw
out" VMS?  Reasonable?  Or bigotry?
Good question. Their VMS systems is simply "something from the past"
that has to be replaced sooner or later. There is nothing but issues
as it is right now. Old and desuported hardware. Issues to get staff
with OpenVMS knowledge. Not a "standard" platform.
Ok, next question.  What is a "standard platform" ?
It depends, of course. But a platform that is a few % of the total
IT environment (for this customer) is probably not seen as "standard".
Arne Vajhøj
2021-05-02 15:48:12 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Jan-Erik Söderholm
We had a meeting today around a larger change project for our
envionment and I had some points on not to invest developer time
using tools that are not available on x86, but they were more
interested in how this OpenVMS "thing" could be thrown out...
I'm curious Jan-Erik.  What were the reasons for wanting to "throw
out" VMS?  Reasonable?  Or bigotry?
Good question. Their VMS systems is simply "something from the past"
that has to be replaced sooner or later. There is nothing but issues
as it is right now. Old and desuported hardware. Issues to get staff
with OpenVMS knowledge. Not a "standard" platform.
Ok, next question.  What is a "standard platform" ?
Different definitions by different people.

But the two biggest groups are probably:
* Linux/x86-64
* Linux/x86-64 or Windows/x84-64

VMS/Alpha and VMS/I64 are not likely to be part of many's definition.
Post by Jan-Erik Söderholm
Those who knows
anything about the system (me) can quite and retire anytime, and that
would be a major issue to handle.
But, they won't have you train anyone, because, "it is going to be
replaced anyway", huh?
Post by Jan-Erik Söderholm
But the services that this system supplies are just great from the
users perspective. Fast with short response times. Flexible. Fairly
easy to adjust and adopt the in-house software. Fast implementations
to new production equipment.
Oh, my, can't have that!  Where is the job security for the IT people?
Post by Jan-Erik Söderholm
My *personal* view is that we could do a lot to keep the main/core
system but replace VT-based UI with more modern and flexible web
based UI. But no investments in that since "it is going to be
replaced anyway"...
Well, you do have experience with WASD ...
But, I'm going to assume that "fast with short response times" just
might suffer some.
VT will likely be very unusual UI in a modern enterprise setup.

browser---traditional web app
browser and HTML5 app---web service
phone/tablet app---web service
windows app---web service

will all be way more common and likely fit better into what the
PC people and the network people like to support.

Arne
Simon Clubley
2021-05-02 03:19:52 UTC
Permalink
Post by Jan-Erik Söderholm
My *personal* view is that we could do a lot to keep the main/core
system but replace VT-based UI with more modern and flexible web
based UI. But no investments in that since "it is going to be
replaced anyway"...
And if I know users (and I do :-)) they will hate it because the
"old UI was a lot quicker to use". :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Jan-Erik Söderholm
2021-05-02 09:24:59 UTC
Permalink
Post by Simon Clubley
Post by Jan-Erik Söderholm
My *personal* view is that we could do a lot to keep the main/core
system but replace VT-based UI with more modern and flexible web
based UI. But no investments in that since "it is going to be
replaced anyway"...
And if I know users (and I do :-)) they will hate it because the
"old UI was a lot quicker to use". :-)
Simon.
No, the requests on a new/modern UI comes from the user side.
But on the other side, there are also some workplaces, such as
special terminals out in the production, where web UI is not
always the most efficient solution. Sometimes it can be the
old VT-UI, sometimes it is better to use the UI of the local
PLC system.
Dave Froble
2021-05-02 13:46:01 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by Jan-Erik Söderholm
My *personal* view is that we could do a lot to keep the main/core
system but replace VT-based UI with more modern and flexible web
based UI. But no investments in that since "it is going to be
replaced anyway"...
And if I know users (and I do :-)) they will hate it because the
"old UI was a lot quicker to use". :-)
Simon.
No, the requests on a new/modern UI comes from the user side.
Ever heard "be careful what you ask for, you might get it" ??

Users are always ready for something new. But sometimes, not always,
they are not happy when the "something new" occurs.

It's been proven, over and over again, that a simple, memorized,
solution is usually easier and faster than something that requires
constant decisions. Having to reach for a mouse is usually the worst
thing in such situations.

While the simpler UI may require some initial learning, and there are
people who cannot be bothered to learn, it can be very productive once
learned.
Post by Jan-Erik Söderholm
But on the other side, there are also some workplaces, such as
special terminals out in the production, where web UI is not
always the most efficient solution. Sometimes it can be the
old VT-UI, sometimes it is better to use the UI of the local
PLC system.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-05-02 15:55:29 UTC
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by Jan-Erik Söderholm
My *personal* view is that we could do a lot to keep the main/core
system but replace VT-based UI with more modern and flexible web
based UI. But no investments in that since "it is going to be
replaced anyway"...
And if I know users (and I do :-)) they will hate it because the
"old UI was a lot quicker to use". :-)
Simon.
No, the requests on a new/modern UI comes from the user side.
Ever heard "be careful what you ask for, you might get it" ??
Users are always ready for something new.  But sometimes, not always, they
are not happy when the "something new" occurs.
It's been proven, over and over again, that a simple, memorized, solution
is usually easier and faster than something that requires constant
decisions.  Having to reach for a mouse is usually the worst thing in such
situations.
While the simpler UI may require some initial learning, and there are
people who cannot be bothered to learn, it can be very productive once
learned.
I do not understand why you are simply repeating what I wrote below.
Poeple in the office are very used to reach for the mouse, they
do that for enerything else, why not in the VMS UI also?

We have web applications in the production that have neither keyboard
or a mouse, just Windows with a touch screen. Works perfectly.
Post by Dave Froble
Post by Jan-Erik Söderholm
But on the other side, there are also some workplaces, such as
special terminals out in the production, where web UI is not
always the most efficient solution. Sometimes it can be the
old VT-UI, sometimes it is better to use the UI of the local
PLC system.
Dave Froble
2021-05-02 17:05:37 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by Jan-Erik Söderholm
My *personal* view is that we could do a lot to keep the main/core
system but replace VT-based UI with more modern and flexible web
based UI. But no investments in that since "it is going to be
replaced anyway"...
And if I know users (and I do :-)) they will hate it because the
"old UI was a lot quicker to use". :-)
Simon.
No, the requests on a new/modern UI comes from the user side.
Ever heard "be careful what you ask for, you might get it" ??
Users are always ready for something new. But sometimes, not always,
they are not happy when the "something new" occurs.
It's been proven, over and over again, that a simple, memorized,
solution is usually easier and faster than something that requires
constant decisions. Having to reach for a mouse is usually the worst
thing in such situations.
While the simpler UI may require some initial learning, and there are
people who cannot be bothered to learn, it can be very productive once
learned.
I do not understand why you are simply repeating what I wrote below.
Was pretty much agreeing with you. We've seen it many times.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-05-02 20:11:42 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by Jan-Erik Söderholm
My *personal* view is that we could do a lot to keep the main/core
system but replace VT-based UI with more modern and flexible web
based UI. But no investments in that since "it is going to be
replaced anyway"...
And if I know users (and I do :-)) they will hate it because the
"old UI was a lot quicker to use". :-)
Simon.
No, the requests on a new/modern UI comes from the user side.
Ever heard "be careful what you ask for, you might get it" ??
Users are always ready for something new.  But sometimes, not always,
they are not happy when the "something new" occurs.
It's been proven, over and over again, that a simple, memorized,
solution is usually easier and faster than something that requires
constant decisions.  Having to reach for a mouse is usually the worst
thing in such situations.
While the simpler UI may require some initial learning, and there are
people who cannot be bothered to learn, it can be very productive once
learned.
I do not understand why you are simply repeating what I wrote below.
Was pretty much agreeing with you.  We've seen it many times.
OK. Just fine in that case... :-)
Phillip Helbig (undress to reply)
2021-04-30 07:56:47 UTC
Permalink
Post by David Turner
People bringing this up reminds me that perhaps an Alpha emulator and a
very faxt x86 box is worth going to
I mean, most people migrated from Alpha to HP Integrity. I bet going
back to Alpha, but on an emulator, would not be that big a deal.
Most people I am sure still have their ALpha PERPETUAL licenses
Legal? Support?
David Turner
2021-05-01 15:12:24 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by David Turner
People bringing this up reminds me that perhaps an Alpha emulator and a
very faxt x86 box is worth going to
I mean, most people migrated from Alpha to HP Integrity. I bet going
back to Alpha, but on an emulator, would not be that big a deal.
Most people I am sure still have their ALpha PERPETUAL licenses
Legal? Support?
Legal - If you own the licenses, HP sells emulator transfer licenses for
OS, and layered products. $1000 each

Support?

PARSEC

BRUDEN

SECTOR 7

Numerous large companies like Park Place, IBM, etc etc etc


DT
Simon Clubley
2021-05-02 03:46:28 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Support?
PARSEC
BRUDEN
SECTOR 7
I don't see how this is a viable option.

The typical timeline for a security issue these days goes something
like this, assuming that VSI management were to follow responsible
disclosure procedures (yeah, yeah, I know...):

Security researcher reports an issue to VSI (probably to one of the VSI
people directly as VSI doesn't have a security reporting mechanism)
and gives them a maximum of 90 days to fix the issue before revealing
the details.

VSI investigates, confirms the issue over the next few days and
requests a CVE.

VSI works on a patch, releases it within the 90 days and provides a
public reference for the patch so the CVE can be updated with a
summary of the vulnerability and made public. This is the first point
at which the above companies will know there is a security issue which
needs fixing.

Security researcher either then releases the details immediately after
the patch is released or they give users a little bit of time (up to
a month or so) to install the patch.

Question: how can the above support companies possibly develop and
release their own patch for the security issue immediately after the
VSI patch is released ?

They may not have the vulnerability details if the researcher holds
off for a while before releasing them and they certainly don't have
an up to date buildable copy of the VMS sources which are used to
build the VSI releases.

In that situation, how could they possibly be an alternative to VSI
support ?
Post by Phillip Helbig (undress to reply)
Numerous large companies like Park Place, IBM, etc etc etc
IBM does VMS support ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-02 15:40:28 UTC
Permalink
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Support?
PARSEC
BRUDEN
SECTOR 7
I don't see how this is a viable option.
The typical timeline for a security issue these days goes something
like this, assuming that VSI management were to follow responsible
Security researcher reports an issue to VSI (probably to one of the VSI
people directly as VSI doesn't have a security reporting mechanism)
and gives them a maximum of 90 days to fix the issue before revealing
the details.
VSI investigates, confirms the issue over the next few days and
requests a CVE.
VSI works on a patch, releases it within the 90 days and provides a
public reference for the patch so the CVE can be updated with a
summary of the vulnerability and made public. This is the first point
at which the above companies will know there is a security issue which
needs fixing.
Security researcher either then releases the details immediately after
the patch is released or they give users a little bit of time (up to
a month or so) to install the patch.
Question: how can the above support companies possibly develop and
release their own patch for the security issue immediately after the
VSI patch is released ?
They may not have the vulnerability details if the researcher holds
off for a while before releasing them and they certainly don't have
an up to date buildable copy of the VMS sources which are used to
build the VSI releases.
In that situation, how could they possibly be an alternative to VSI
support ?
For closed source all support vendors are not created equal.

The one with the source has some advantages.
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Numerous large companies like Park Place, IBM, etc etc etc
IBM does VMS support ?
Never heard about it.

But I can not see why the consultant branch of IBM should turn
down money to do VMS support. Their business is to provide what the
customers are wiling to pay for.

Arne
David Turner
2021-05-03 14:16:11 UTC
Permalink
Well I was talking more about simple support. Not patching etc
There are a lot of customers out there happy and content with their
current status.
They just need a hand held when something goes wrong
I would say that goes for the majority of users out there.
Post by Arne Vajhøj
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Support?
PARSEC
BRUDEN
SECTOR 7
I don't see how this is a viable option.
The typical timeline for a security issue these days goes something
like this, assuming that VSI management were to follow responsible
Security researcher reports an issue to VSI (probably to one of the VSI
people directly as VSI doesn't have a security reporting mechanism)
and gives them a maximum of 90 days to fix the issue before revealing
the details.
VSI investigates, confirms the issue over the next few days and
requests a CVE.
VSI works on a patch, releases it within the 90 days and provides a
public reference for the patch so the CVE can be updated with a
summary of the vulnerability and made public. This is the first point
at which the above companies will know there is a security issue which
needs fixing.
Security researcher either then releases the details immediately after
the patch is released or they give users a little bit of time (up to
a month or so) to install the patch.
Question: how can the above support companies possibly develop and
release their own patch for the security issue immediately after the
VSI patch is released ?
They may not have the vulnerability details if the researcher holds
off for a while before releasing them and they certainly don't have
an up to date buildable copy of the VMS sources which are used to
build the VSI releases.
In that situation, how could they possibly be an alternative to VSI
support ?
For closed source all support vendors are not created equal.
The one with the source has some advantages.
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Numerous large companies like Park Place, IBM, etc etc etc
IBM does VMS support ?
Never heard about it.
But I can not see why the consultant branch of IBM should turn
down money to do VMS support. Their business is to provide what the
customers are wiling to pay for.
Arne
Dave Froble
2021-05-03 16:25:07 UTC
Permalink
Post by David Turner
Well I was talking more about simple support. Not patching etc
There are a lot of customers out there happy and content with their
current status.
They just need a hand held when something goes wrong
I would say that goes for the majority of users out there.
This is a strength of VMS, at least for some people. Simon feels that
all users must have immediate access to security patches. It's an
opinion, everybody is entitled to at least one.

I've got to add, I personally feel that all commercial VMS sites should
subscribe to VSI support. This is to support VSI, who is the only game
in town with respect to moving VMS into the future. This is needed,
because relying on old un-replaceable hardware sooner or later will fail.

Still, the robust long term viability of VMS is a strength for users,
should VSI at some time not be around. As David Turner mentions,
emulators add to this strength.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Loading...