From a press release last week:

"Tietoevry is a longstanding Telia partner and will serve as a strategic
advisor to the project, which will start at the beginning of March 2023. As
part of the code and data migration process, Tietoevry will harness
Advanced’s professional services capabilities, automated transformation
tooling, and runtime components to eliminate Telia Finance Final’s current
dependency on OpenVMS. This includes migrating an estimated 1.5 million
lines of COBOL code plus other programming languages to the cloud-ready
language, Java."

Press release:
https://modernsystems.oneadvanced.com/news-and-opinion/telia-finance-selects-tietoevry--advanced-for-application-modernization-initiative/

Generally about their services for OpenVMS:
https://modernsystems.oneadvanced.com/services/openvms/

On 2023-02-20, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> From a press release last week:
>
> "Tietoevry is a longstanding Telia partner and will serve as a strategic
> advisor to the project, which will start at the beginning of March 2023. As
> part of the code and data migration process, Tietoevry will harness
> Advanced?s professional services capabilities, automated transformation
> tooling, and runtime components to eliminate Telia Finance Final?s current
> dependency on OpenVMS. This includes migrating an estimated 1.5 million
> lines of COBOL code plus other programming languages to the cloud-ready
> language, Java."
>
> Press release:
> https://modernsystems.oneadvanced.com/news-and-opinion/telia-finance-selects-tietoevry--advanced-for-application-modernization-initiative/
>

For those of you still thinking VMS can grow into new sites, the above is
well worth a read. In particular:

|From ongoing skills gap pressures to the emphasis of de-risking business,
|companies today are prioritizing legacy mainframe modernization more than
|ever before.

That's how VMS is seen today, not as an asset, but as a liability to the
people still running it.

The above is what VSI should have been addressing, not creating new licences
that drove even more people away from VMS.

Simon.

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

On 2/20/2023 8:01 AM, Jan-Erik Söderholm wrote:
> From a press release last week:
>
> "Tietoevry is a longstanding Telia partner and will serve as a strategic
> advisor to the project, which will start at the beginning of March 2023.
> As part of the code and data migration process, Tietoevry will harness
> Advanced’s professional services capabilities, automated transformation
> tooling, and runtime components to eliminate Telia Finance Final’s
> current dependency on OpenVMS. This includes migrating an estimated 1.5
> million lines of COBOL code plus other programming languages to the
> cloud-ready language, Java."
>
> Press release:
> https://modernsystems.oneadvanced.com/news-and-opinion/telia-finance-selects-tietoevry--advanced-for-application-modernization-initiative/

This is obviously bad news for VMS.

Telia is the type of company that VSI want as a customer. They got
money. :-)

It is not shocking news.

I am sure that every year the last 20-25 years some companies
has migrated off VMS to something else.

VSI need to stop and reverse this trend.

They are working on it.

They are almost there with the first step of getting
VMS production ready for running on x86-64. That will
help quite a bit for VMS that it can run in the same
infrastructure as anything else - VMWare on-prem or
VM's in IaaS cloud or whatever the IT department is
standardizing on.

Next step should be the compilers/libraries/tools/platform-software.

Will it be easy? No!

> Generally about their services for OpenVMS:
> https://modernsystems.oneadvanced.com/services/openvms/

There are companies specializing in migrating
from socalled "legacy" platforms to socalled "modern"
platforms

They exist for IBM mainframe. They exist for VMS.
Etc..

Arne

On 2/20/2023 8:01 AM, Jan-Erik Söderholm wrote:
> This includes migrating an estimated 1.5
> million lines of COBOL code plus other programming languages to the
> cloud-ready language, Java."

Side note:

Java is not more cloud ready than any other language
that can run on x86-64.

In fact Java is less cloud ready than some other
technologies for FaaS cloud.

Arne

On 2/20/2023 9:12 AM, Arne Vajhøj wrote:
> On 2/20/2023 8:01 AM, Jan-Erik Söderholm wrote:
>>  From a press release last week:
>>
>> "Tietoevry is a longstanding Telia partner and will serve as a
>> strategic advisor to the project, which will start at the beginning of
>> March 2023. As part of the code and data migration process, Tietoevry
>> will harness Advanced’s professional services capabilities, automated
>> transformation tooling, and runtime components to eliminate Telia
>> Finance Final’s current dependency on OpenVMS. This includes migrating
>> an estimated 1.5 million lines of COBOL code plus other programming
>> languages to the cloud-ready language, Java."
>>
>> Press release:
>> https://modernsystems.oneadvanced.com/news-and-opinion/telia-finance-selects-tietoevry--advanced-for-application-modernization-initiative/
>
> This is obviously bad news for VMS.
>
> Telia is the type of company that VSI want as a customer. They got
> money. :-)
>
> It is not shocking news.
>
> I am sure that every year the last 20-25 years some companies
> has migrated off VMS to something else.
>
> VSI need to stop and reverse this trend.
>
> They are working on it.
>
> They are almost there with the first step of getting
> VMS production ready for running on x86-64. That will
> help quite a bit for VMS that it can run in the same
> infrastructure as anything else - VMWare on-prem or
> VM's in IaaS cloud or whatever the IT department is
> standardizing on.
>
> Next step should be the compilers/libraries/tools/platform-software.
>
> Will it be easy? No!
>
> > Generally about their services for OpenVMS:
> > https://modernsystems.oneadvanced.com/services/openvms/
>
> There are companies specializing in migrating
> from socalled "legacy" platforms to socalled "modern"
> platforms
>
> They exist for IBM mainframe. They exist for VMS.
> Etc..

The really funny thing about this is while migrating from legacy
hardware to modern hardware for reasons like availability and
expense are probably valid, that doesn't mean you should re-write
your applications into totally different languages. In particular
going from a language designed to do the work you need done to a
language with no particular target for what it is supposed to do.

bill

On 2/20/2023 9:32 AM, bill wrote:
> On 2/20/2023 9:12 AM, Arne Vajhøj wrote:
>> On 2/20/2023 8:01 AM, Jan-Erik Söderholm wrote:
>>>  From a press release last week:
>>>
>>> "Tietoevry is a longstanding Telia partner and will serve as a
>>> strategic advisor to the project, which will start at the beginning
>>> of March 2023. As part of the code and data migration process,
>>> Tietoevry will harness Advanced’s professional services capabilities,
>>> automated transformation tooling, and runtime components to eliminate
>>> Telia Finance Final’s current dependency on OpenVMS. This includes
>>> migrating an estimated 1.5 million lines of COBOL code plus other
>>> programming languages to the cloud-ready language, Java."
>>>
>>> Press release:
>>> https://modernsystems.oneadvanced.com/news-and-opinion/telia-finance-selects-tietoevry--advanced-for-application-modernization-initiative/

>>  > Generally about their services for OpenVMS:
>>  > https://modernsystems.oneadvanced.com/services/openvms/
>>
>> There are companies specializing in migrating
>> from socalled "legacy" platforms to socalled "modern"
>> platforms

> The really funny thing about this is while migrating from legacy
> hardware to modern hardware for reasons like availability and
> expense are probably valid, that doesn't mean you should re-write
> your applications into totally different languages.  In particular
> going from a language designed to do the work you need done to a
> language with no particular target for what it is supposed to do.

For a Cobol/VMS application there are multiple options:
1) stay on Cobol/VMS
2) change both language and platform like to Java/Linux (*)
3) change just platform like to Cobol/Linux
4) change just language like to Java/VMS

Telia chose #2. They could have chosen #3.

More companies pick #2 than #3. They want to get off
Cobol and if they need to start a huge migration project
to change platform then they want to change the language
as well (changes in some code due to different context +
changes to operations + full test + project overhead is
not that much smaller than change all code +
changes to operations + full test + project overhead).

Note that the option VSI really want #4 is even rarer.

:-(

*) could also be C#/Linux or Go/Linux or polyglot/Linux
(like node.js for frontend and Java for backend all on Linux),
but Telia was supposedly Java.

Arne

Den 2023-02-20 kl. 15:57, skrev Arne Vajhøj:
> On 2/20/2023 9:32 AM, bill wrote:
>> On 2/20/2023 9:12 AM, Arne Vajhøj wrote:
>>> On 2/20/2023 8:01 AM, Jan-Erik Söderholm wrote:
>>>>  From a press release last week:
>>>>
>>>> "Tietoevry is a longstanding Telia partner and will serve as a
>>>> strategic advisor to the project, which will start at the beginning of
>>>> March 2023. As part of the code and data migration process, Tietoevry
>>>> will harness Advanced’s professional services capabilities, automated
>>>> transformation tooling, and runtime components to eliminate Telia
>>>> Finance Final’s current dependency on OpenVMS. This includes migrating
>>>> an estimated 1.5 million lines of COBOL code plus other programming
>>>> languages to the cloud-ready language, Java."
>>>>
>>>> Press release:
>>>> https://modernsystems.oneadvanced.com/news-and-opinion/telia-finance-selects-tietoevry--advanced-for-application-modernization-initiative/
>
>>>  > Generally about their services for OpenVMS:
>>>  > https://modernsystems.oneadvanced.com/services/openvms/
>>>
>>> There are companies specializing in migrating
>>> from socalled "legacy" platforms to socalled "modern"
>>> platforms
>
>> The really funny thing about this is while migrating from legacy
>> hardware to modern hardware for reasons like availability and
>> expense are probably valid, that doesn't mean you should re-write
>> your applications into totally different languages.  In particular
>> going from a language designed to do the work you need done to a
>> language with no particular target for what it is supposed to do.
>
> For a Cobol/VMS application there are multiple options:
> 1) stay on Cobol/VMS
> 2) change both language and platform like to Java/Linux (*)
> 3) change just platform like to Cobol/Linux
> 4) change just language like to Java/VMS
>
> Telia chose #2. They could have chosen #3.
>
> More companies pick #2 than #3. They want to get off
> Cobol and if they need to start a huge migration project
> to change platform then they want to change the language
> as well (changes in some code due to different context +
> changes to operations + full test + project overhead is
> not that much smaller than change all code +
> changes to operations + full test + project overhead).
>
> Note that the option VSI really want #4 is even rarer.
>
> :-(
>
> *) could also be C#/Linux or Go/Linux or polyglot/Linux
> (like node.js for frontend and Java for backend all on Linux),
> but Telia was supposedly Java.
>
> Arne
>

It will be very interesting to follow this project.
*If* it fails, it would be the first failed Java migration.

One could think that a "mission-critical finance engine"
would be a good target for a Cobol based platform...

On 2/20/2023 11:14 AM, Jan-Erik Söderholm wrote:
> Den 2023-02-20 kl. 15:57, skrev Arne Vajhøj:
>> For a Cobol/VMS application there are multiple options:
>> 1) stay on Cobol/VMS
>> 2) change both language and platform like to Java/Linux (*)
>> 3) change just platform like to Cobol/Linux
>> 4) change just language like to Java/VMS
>>
>> Telia chose #2. They could have chosen #3.
>>
>> More companies pick #2 than #3. They want to get off
>> Cobol and if they need to start a huge migration project
>> to change platform then they want to change the language
>> as well (changes in some code due to different context +
>> changes to operations + full test + project overhead is
>> not that much smaller than change all code +
>> changes to operations + full test + project overhead).
>>
>> Note that the option VSI really want #4 is even rarer.
>>
>> :-(
>>
>> *) could also be C#/Linux or Go/Linux or polyglot/Linux
>> (like node.js for frontend and Java for backend all on Linux),
>> but Telia was supposedly Java.
>
> It will be very interesting to follow this project.
> *If* it fails, it would be the first failed Java migration.

I assume you meant "not the first".

Big software migration projects are always risky.

My crystal ball provides the following probabilities:

20% it goes without problems
60% delayed and over budget but eventually succeed
20% fails

> One could think that a "mission-critical finance engine"
> would be a good target for a Cobol based platform...

Cobol can certainly do the job. It was what Cobol was
intended for. And Cobol has done that particular job
for a number of decades.

The main reasons behind the desire to move from
Cobol to Java are probably:
- easier to find developers
- easier integration with all sorts of new things
- faster implementation of changes due to more encapsulation
and better tools
- an expectation of reducing the code base they have
to maintain by utilizing various external libraries
(random numbers: replace 1.5 MLOC of Cobol with
300 KLOC of Java that uses external libraries for
stuff that was one in Cobol before - those external
libraries may be 25 MLOC of Java code, but Telia is
not paying for maintenance of those)

Arne

On Monday, February 20, 2023 at 10:30:54 AM UTC-6, Arne Vajhøj wrote:
> On 2/20/2023 11:14 AM, Jan-Erik Söderholm wrote:
> > Den 2023-02-20 kl. 15:57, skrev Arne Vajhøj:
> >> For a Cobol/VMS application there are multiple options:
> >> 1) stay on Cobol/VMS
> >> 2) change both language and platform like to Java/Linux (*)
> >> 3) change just platform like to Cobol/Linux
> >> 4) change just language like to Java/VMS
> >>
>
It has been our experience that changing the language of the application during a migration makes the whole migration project exponentially more difficult, expensive, long and risky. It makes the whole thing a moving target that is incredibly difficult to manage. One fun feature is that you’re always waiting for something to be migrated before you can run even just some parts of the application. Another fun feature is that testing is complex because of the differences between the two systems.

Our long migration experience has confirmed that a tools-based, like for like approach is best. We have developed tools that transform the OpenVMS version of a language to a Linux-compatible version of the language, where such a language exists on Linux. We have a transformation tool for COBOL, another for Fortran, and yet others for C/C++. For languages that do not exist on Linux, such as Pascal, we have a translator that converts the Pascal to C++, and BASIC to C.

Using our transformational tool for COBOL (or Fortran…) allows us to migrate the entire codebase simultaneously. There is no waiting for specific modules to me migrated in order to start testing. We can migrate millions of LOC of COBOL in just a few minutes. When we find errors in the generated COBOL code on Linux, we adjust the tool, not the generated code, and then we process the whole codebase again. So, when we fix one error, it is fixed throughout the entire code base. We never want to have hand modifications performed on the generated code.

Using a tools-based transformation tool is the best way to preserve all the business logic built into the application over the years and decades. There is no code freeze needed, this methodology allows for continuous integration of new and enhanced source code at any time. The transformation tool produce COBOL code that can be compiled on Linux by native compilers such as NETCOBOL (only needs an inexpensive development license, no run time licenses required) and you have native executables running on Linux, no interpreter or simulator needed. The executables will run a LOT faster on Linux than they do on OpenVMS.

Since all VMS features such as logicals, FMS, and DCL scripts and so on are supported on Linux, the migrated application runs on Linux, exactly the same was as on OpenVMS. Testing is easy, it’s like for like. A test script on OpenVMS runs the same way on Linux and must produce the same results. If it doesn’t, the bug is fixed in the migration tool and the codebase get completely migrated again. This migration just takes a few minutes for millions of LOC of COBOL code. The entire COBOL code base is migrated at the same time so testing never waits for some component that hasn’t been migrated yet.

Once the application is migrated and is now running on the new platform, you can start replacing various components with components written in other languages. You can do this at your leisure and not worry about big bang deployments. The development and support staff remain very current because it’s the same code running on Linux. They learn the new Linuxy tools at their own pace as components are rewritten in other tools, but they can continue to support the COBOL code directly on Linux for as long as needed.
One important, often overlooked benefit of a like-for-like migration is that you do not have to retrain the users. We have done this for banks, insurance companies, manufacturing facilities, and other places with hundreds or thousands of users and the application runs exactly the same way for them. This makes deployment very easy, and your users are unaware of the change, except that it runs faster.

On Monday, February 20, 2023 at 3:20:37 PM UTC-6, Denys Beauchemin wrote:
> On Monday, February 20, 2023 at 10:30:54 AM UTC-6, Arne Vajhøj wrote:
> > On 2/20/2023 11:14 AM, Jan-Erik Söderholm wrote:
> > > Den 2023-02-20 kl. 15:57, skrev Arne Vajhøj:
> > >> For a Cobol/VMS application there are multiple options:
> > >> 1) stay on Cobol/VMS
> > >> 2) change both language and platform like to Java/Linux (*)
> > >> 3) change just platform like to Cobol/Linux
> > >> 4) change just language like to Java/VMS
> > >>
> >
> It has been our experience that changing the language of the application during a migration makes the whole migration project exponentially more difficult, expensive, long and risky. It makes the whole thing a moving target that is incredibly difficult to manage. One fun feature is that you’re always waiting for something to be migrated before you can run even just some parts of the application. Another fun feature is that testing is complex because of the differences between the two systems.
>
> Our long migration experience has confirmed that a tools-based, like for like approach is best. We have developed tools that transform the OpenVMS version of a language to a Linux-compatible version of the language, where such a language exists on Linux. We have a transformation tool for COBOL, another for Fortran, and yet others for C/C++. For languages that do not exist on Linux, such as Pascal, we have a translator that converts the Pascal to C++, and BASIC to C.
>

I wanted to add that we at Sector7 are very much adherents to the concept that if you can't measure it you can't manage it. With a tools-based migration using our transformation engines, you get exact numbers of errors during the adjustment phase during each iteration. Once the migrated code compiles cleanly on Linux and you build the executables, you have an exact number of executables to test and you can measure that. Also, since the transformation is automated, you do not have to worry about encountering manual errors; when there is an error, it is systematic and you fix the tool. The error is fixed throughout the code base.

The application will run immediately on Linux using the Sector7 library of system services running on Linux, so you do not have to wait for the rewrite of whatever VMS feature your application uses. The whole migration is measurable and thus manageable.

On 2023-02-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> They are almost there with the first step of getting
> VMS production ready for running on x86-64. That will
> help quite a bit for VMS that it can run in the same
> infrastructure as anything else - VMWare on-prem or
> VM's in IaaS cloud or whatever the IT department is
> standardizing on.
>
> Next step should be the compilers/libraries/tools/platform-software.
>
> Will it be easy? No!
>

If that's what you think is required, then it most certainly isn't and
what VSI should _really_ be doing they show no evidence of doing.

Make no mistake, the above is essential and must be done as soon as
possible, but it's not the most important thing VSI should be doing.

The most important thing that VSI should be doing is convincing the people
that sign the cheques that staying with VMS is the safest option for them
instead of those people paying for a migration project.

VSI need to be cultivating a feeling of familiarity and safety towards
VMS in the minds of these people instead of what is the current thinking
in those people of VMS being a risky obsolete technology that is holding
back the company and putting them at risk.

Even IBM understands this. IBM have cultivated an entire environment that
gives people structured knowledge and training on z/OS for free, in what
was originally known as the Master the Mainframe program.

To the people that have been through this process, z/OS is no longer some
weird unknown operating system, but something they are now familiar with
and understand.

VSI should have had similar programs for both technical and management paths
and they should have had them years ago. _That_ is the single most important
thing that VSI should have been doing - to induce a culture of knowledge and
familiarity towards VMS in the current generation of people.

The reason why the above is so important is that it works towards convincing
the managers that staying with VMS is the safest option for them.

You are thinking about this at a technology level Arne. Wrong. :-) You need
to be thinking about it in terms of the concerns going through the heads of
the people who sign the cheques.

Simon.

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

On 2023-02-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 2/20/2023 8:01 AM, Jan-Erik Söderholm wrote:
>> This includes migrating an estimated 1.5
>> million lines of COBOL code plus other programming languages to the
>> cloud-ready language, Java."
>
> Side note:
>
> Java is not more cloud ready than any other language
> that can run on x86-64.
>
> In fact Java is less cloud ready than some other
> technologies for FaaS cloud.
>

However, it's easy to convince the cheque signers that Java is a nice
modern language while COBOL is some old obsolete language that needs to
be replaced.

Note that I am NOT saying this is the reality. I am only saying that it's
easy to convince the cheque signers that it is...

Simon.

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

On 2/21/2023 8:42 AM, Simon Clubley wrote:
> On 2023-02-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> They are almost there with the first step of getting
>> VMS production ready for running on x86-64. That will
>> help quite a bit for VMS that it can run in the same
>> infrastructure as anything else - VMWare on-prem or
>> VM's in IaaS cloud or whatever the IT department is
>> standardizing on.
>>
>> Next step should be the compilers/libraries/tools/platform-software.
>>
>> Will it be easy? No!
>
> If that's what you think is required, then it most certainly isn't and
> what VSI should _really_ be doing they show no evidence of doing.
>
> Make no mistake, the above is essential and must be done as soon as
> possible, but it's not the most important thing VSI should be doing.
>
> The most important thing that VSI should be doing is convincing the people
> that sign the cheques that staying with VMS is the safest option for them
> instead of those people paying for a migration project.

It is obvious that VSI need to push VMS.

But just pushing BS does not work out long term.

Long term something of substance is needed.

Staying on VMS will not be considered the safest option just because
VSI says so.

Staying on VMS may be considered the safest option if VMS is
seen as having a future.

VMS will be seen as having a future if it runs on standard
infrastructure, has the the compilers/libraries/tools/platform-software
that is needed and has the applications needed.

> VSI need to be cultivating a feeling of familiarity and safety towards
> VMS in the minds of these people instead of what is the current thinking
> in those people of VMS being a risky obsolete technology that is holding
> back the company and putting them at risk.
>
> Even IBM understands this. IBM have cultivated an entire environment that
> gives people structured knowledge and training on z/OS for free, in what
> was originally known as the Master the Mainframe program.
>
> To the people that have been through this process, z/OS is no longer some
> weird unknown operating system, but something they are now familiar with
> and understand.
>
> VSI should have had similar programs for both technical and management paths
> and they should have had them years ago. _That_ is the single most important
> thing that VSI should have been doing - to induce a culture of knowledge and
> familiarity towards VMS in the current generation of people.

Maybe.

But whatever IBM is doing has not stopped the decline of z/OS.

Sounds like a nice initiative.

But it has not changed the fundamental problems of z/OS with
expensive hardware and usually very old software.

> You are thinking about this at a technology level Arne. Wrong. :-) You need
> to be thinking about it in terms of the concerns going through the heads of
> the people who sign the cheques.

I believe that is what I am doing.

Arne

On 2/21/2023 8:46 AM, Simon Clubley wrote:
> On 2023-02-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/20/2023 8:01 AM, Jan-Erik Söderholm wrote:
>>> This includes migrating an estimated 1.5
>>> million lines of COBOL code plus other programming languages to the
>>> cloud-ready language, Java."
>>
>> Side note:
>>
>> Java is not more cloud ready than any other language
>> that can run on x86-64.
>>
>> In fact Java is less cloud ready than some other
>> technologies for FaaS cloud.
>
> However, it's easy to convince the cheque signers that Java is a nice
> modern language while COBOL is some old obsolete language that needs to
> be replaced.
>
> Note that I am NOT saying this is the reality. I am only saying that it's
> easy to convince the cheque signers that it is...

"modern" and "obsolete" does not mean anything for those people.

("supported" and "unsupported" means something, but both Java and
Cobol are supported so that does not tip the scale any way)

But there are some realities that they are aware of:
- the developers they hire knows Java not Cobol
- almost any DB/MQ/cache comes with a Java client while few comes
with a Cobol client
- the typical Java setup would be much more geared towards
CI/CD than the typical Cobol setup
- there are around 32 million open source artifacts available
for Java via Maven not for Cobol

There are serious reasons to wish to be on Java instead
of Cobol.

There are also very serious reasons to not wanting to rewrite
large applications!

Arne

On Wednesday, February 22, 2023 at 9:06:53 AM UTC+13, Arne Vajhøj wrote:
> On 2/21/2023 8:42 AM, Simon Clubley wrote:
> > On 2023-02-20, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >>
> >> They are almost there with the first step of getting
> >> VMS production ready for running on x86-64. That will
> >> help quite a bit for VMS that it can run in the same
> >> infrastructure as anything else - VMWare on-prem or
> >> VM's in IaaS cloud or whatever the IT department is
> >> standardizing on.
> >>
> >> Next step should be the compilers/libraries/tools/platform-software.
> >>
> >> Will it be easy? No!
> >
> > If that's what you think is required, then it most certainly isn't and
> > what VSI should _really_ be doing they show no evidence of doing.
> >
> > Make no mistake, the above is essential and must be done as soon as
> > possible, but it's not the most important thing VSI should be doing.
> >
> > The most important thing that VSI should be doing is convincing the people
> > that sign the cheques that staying with VMS is the safest option for them
> > instead of those people paying for a migration project.
> It is obvious that VSI need to push VMS.
>
> But just pushing BS does not work out long term.
>
> Long term something of substance is needed.
>
> Staying on VMS will not be considered the safest option just because
> VSI says so.
>
> Staying on VMS may be considered the safest option if VMS is
> seen as having a future.
>
> VMS will be seen as having a future if it runs on standard
> infrastructure, has the the compilers/libraries/tools/platform-software
> that is needed and has the applications needed.

Even then I wouldn't consider that enough. Plenty of other operating systems
backed by much larger companies than VSI met all those requirements and
yet no longer exist.

The only guarantee of a future is for the source to be made available under
a worthwhile license. Without the source there are no long-term guarantees.

On 2/21/2023 6:59 PM, David Goodwin wrote:
> The only guarantee of a future is for the source to be made available under
> a worthwhile license. Without the source there are no long-term guarantees.

There is no guarantee with source either.

The vast majority of VMS customers are not interested
in maintaining an OS.

Having the possibility to take the VMS source code,
make fixes and do a build does not change anything,
because they don't want to do that.

Arne

David Goodwin <dgsoftnz@gmail.com> wrote:
>
>The only guarantee of a future is for the source to be made available under
>a worthwhile license. Without the source there are no long-term guarantees.

This is likely true, but how are you going to convince someone at HPE of this?
It's not like VSI has any choice in the situation.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <tt5324$505$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>David Goodwin <dgsoftnz@gmail.com> wrote:
>>
>>The only guarantee of a future is for the source to be made available under
>>a worthwhile license. Without the source there are no long-term guarantees.
>
>This is likely true, but how are you going to convince someone at HPE of this?
>It's not like VSI has any choice in the situation.

This is why I mentioned Sun earlier, though most people seemed
to utterly miss the point by fixating on Sun's eventual failure.
But the critical observation was Sun was able to do this with
Unix, which seemed like an impossible task at the time...until
it actually happened.

So there is precedent.

- Dan C.

Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>Scott Dorsey <kludge@panix.com> wrote:
>>David Goodwin <dgsoftnz@gmail.com> wrote:
>>>
>>>The only guarantee of a future is for the source to be made available under
>>>a worthwhile license. Without the source there are no long-term guarantees.
>>
>>This is likely true, but how are you going to convince someone at HPE of this?
>>It's not like VSI has any choice in the situation.
>
>This is why I mentioned Sun earlier, though most people seemed
>to utterly miss the point by fixating on Sun's eventual failure.
>But the critical observation was Sun was able to do this with
>Unix, which seemed like an impossible task at the time...until
>it actually happened.

I'm not sure what you mean here. Sun did release an open-source version of
Solaris 2, but that was because they actually saw a market and were already
putting considerable effort into maintaining the OS. (And there was really
no SysV code left in Solaris 2 at that point.)

The problem is that nobody at HPE cares about VMS and they don't care enough
to do anything with it, like the effort to release it as open source. VSI
cares about VMS, but they don't have any rights to do anything like that.

>So there is precedent.

I don't see the situations as even vaguely related. But feel free to get
on the phones and call HPE and suggest that they open-source VMS. But first
you'll have to find someone at HPE who knows what VMS actually is.

While you're at it, feel free to call someone at Oracle and ask them to
open-source SunOS 4.1.4. If you can actually get someone to understand
that SunOS is different than Solaris you'll have got farther than anyone else
ever has.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2/22/2023 9:31 AM, John Dallman wrote:
> In article <tt54sb$p0h$1@reader2.panix.com>,
> cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> This is why I mentioned Sun earlier, though most people seemed
>> to utterly miss the point by fixating on Sun's eventual failure.
>> But the critical observation was Sun was able to do this with
>> Unix, which seemed like an impossible task at the time...until
>> it actually happened.
>
> It took them lawyer-years, which was quite expensive. HPE would either
> have to do that work themselves, or contract it out. I don't think they
> have that much motivation about the future of VMS.

The relative size/power of VSI-HPE is far from the same
as of Sun-TSG.

But in the end money matters.

If Sweeney and Gedda walk in Neri's office and say "we
have an analysis here that show we can make 200 M$ more in
profit by open sourcing VMS", then he will not answer
"no" - he will ask "what do you need from me and how do
you propose we split the money?".

The problem is that the business case is not there.

Sun open sourced 3 large chunks of software:
* StarOffice that became OpenOffice that was forked
as LibreOffice
* Solaris that became OpenSolaris that was forked
as Solaris and illumos
* Java that became OpenJDK

Seen from the user perspective then it went OK:
* LibreOffice never took over from Microsoft Office and is niche today
compared to Microsofts and Googles offerings, but it is actively
developed and I believe the users are quite happy.
* Solaris is in maintenance mode at Oracle and illumos has not
taken off, but they still exist
* OpenJDK thrive with backing from Oracle, IBM traditional,
IBM Redhat, Anazon, SAP, Microsoft etc. and huge open
source eco system

Let us score that 2.25/3.0 (0.75 for LO, 0.5 for illumos
and 1.0 for OpenJDK).

But from a business perspective it has been a disaster
for Sun/Oracle:
* there were no money on OOo/LO so it was spun off to
volunteers
* there were no money in OpenSolaris so Solaris was
put in maintenance mode
* Oracle has changed the licensing model for the
commercial Java offering again and again, but nothing
make them money (they make a ton of money on products
using Java but that is a different business)

Let us score that 0.5/3.0 (0.0 for LO, 0.25 for Solaris
and 0.25 for Java).

No business case means that it will not happen.

Arne

In article <tt5b4i$qn5$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>Scott Dorsey <kludge@panix.com> wrote:
>>>David Goodwin <dgsoftnz@gmail.com> wrote:
>>>>
>>>>The only guarantee of a future is for the source to be made available under
>>>>a worthwhile license. Without the source there are no long-term guarantees.
>>>
>>>This is likely true, but how are you going to convince someone at HPE of this?
>>>It's not like VSI has any choice in the situation.
>>
>>This is why I mentioned Sun earlier, though most people seemed
>>to utterly miss the point by fixating on Sun's eventual failure.
>>But the critical observation was Sun was able to do this with
>>Unix, which seemed like an impossible task at the time...until
>>it actually happened.
>
>I'm not sure what you mean here. Sun did release an open-source version of
>Solaris 2, but that was because they actually saw a market and were already
>putting considerable effort into maintaining the OS. (And there was really
>no SysV code left in Solaris 2 at that point.)

The latter point is certainly not true; there's a ton of
System V code _still_ in illumos.

>The problem is that nobody at HPE cares about VMS and they don't care enough
>to do anything with it, like the effort to release it as open source. VSI
>cares about VMS, but they don't have any rights to do anything like that.

Then take the examples of Multics, Plan 9 and Research Unix, all
of which were open-sourced after there was no interest in them
in their respective owners anymore.

>>So there is precedent.
>
>I don't see the situations as even vaguely related. But feel free to get
>on the phones and call HPE and suggest that they open-source VMS. But first
>you'll have to find someone at HPE who knows what VMS actually is.

The point is: things that seem difficult, or even impossible to
open source have, in fact, been open-sourced.

>While you're at it, feel free to call someone at Oracle and ask them to
>open-source SunOS 4.1.4. If you can actually get someone to understand
>that SunOS is different than Solaris you'll have got farther than anyone else
>ever has.

I'll make some inquiries.

- Dan C.

> While you're at it, feel free to call someone at Oracle and ask them
> to open-source SunOS 4.1.4. If you can actually get someone to
> understand that SunOS is different than Solaris you'll have got
> farther than anyone else ever has.

Perhaps that's because SunOS 4.1.4 was rebranded "Solaris 1.1.2". As
the "Solaris 1.1.2 System Software Installation Instructions" which came
with the CD-ROM said:

> Welcome to Solaris 1.1.2. This release is fully binary compatible
> with SunOS 4.1 and subsequent SunOS 4.1.x releases.

It's like the difference between VMS and OpenVMS. "Solaris 2", on
the other hand, _was_ different.

Steven Schweda <sms.antinode@gmail.com> wrote:
>> While you're at it, feel free to call someone at Oracle and ask them
>> to open-source SunOS 4.1.4. If you can actually get someone to
>> understand that SunOS is different than Solaris you'll have got
>> farther than anyone else ever has.
>
> Perhaps that's because SunOS 4.1.4 was rebranded "Solaris 1.1.2". As
>the "Solaris 1.1.2 System Software Installation Instructions" which came
>with the CD-ROM said:
>
>> Welcome to Solaris 1.1.2. This release is fully binary compatible
>> with SunOS 4.1 and subsequent SunOS 4.1.x releases.

Yes, it was a deliberate attempt to obscure what was going on, since so many
people were pissed off about Solaris 2.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2/22/2023 10:08 AM, Scott Dorsey wrote:
>
>
> While you're at it, feel free to call someone at Oracle and ask them to
> open-source SunOS 4.1.4. If you can actually get someone to understand
> that SunOS is different than Solaris you'll have got farther than anyone else
> ever has.

Why would anyone want SunOS 4.1.4 open sourced? There is nothing
there that isn't in any of the BSD's that are already available
and include versions that run on Sun hardware. I can see Oracle's
reluctance to waste any time or money doing anything with any
version of SunOS. Assuming they even still have copies of any of it!!

bill

In article <k5n2tcFtd0kU9@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
>On 2/22/2023 10:08 AM, Scott Dorsey wrote:
>>
>>
>> While you're at it, feel free to call someone at Oracle and ask them to
>> open-source SunOS 4.1.4. If you can actually get someone to understand
>> that SunOS is different than Solaris you'll have got farther than anyone else
>> ever has.
>
>Why would anyone want SunOS 4.1.4 open sourced? There is nothing
>there that isn't in any of the BSD's that are already available
>and include versions that run on Sun hardware. I can see Oracle's
>reluctance to waste any time or money doing anything with any
>version of SunOS. Assuming they even still have copies of any of it!!

I rest my case.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."