https://www.linkedin.com/posts/vms-software-inc-_thats-a-wrap-for-the-malm%C3%B6-bootcamp-over-activity-7330638443586256898-OxYT/
Next one will be:
Portsmouth, NH
October 22–24
On 5/20/2025 23:00, Arne Vajhøj wrote:
https://www.linkedin.com/posts/vms-software-inc-_thats-a-wrap-for-the-malm%C3%B6-bootcamp-over-activity-7330638443586256898-OxYT/
Next one will be:
Portsmouth, NH
October 22–24
We think Portsmouth will be a fine location for the boot camp. Rooms should be much cheaper than
in Boston, and there are buses that go directly from Boston/Logan Airport to Portsmouth.
We think Portsmouth will be a fine location for the boot camp. Rooms should be much cheaper than
in Boston, and there are buses that go directly from Boston/Logan Airport to Portsmouth.
I've heard Innsmouth is a nice place (during the day), though the bus
driver has a certain look about him.
On 5/20/2025 23:00, Arne Vajhøj wrote:
https://www.linkedin.com/posts/vms-software-inc-_thats-a-wrap-for-the-malm%C3%B6-bootcamp-over-activity-7330638443586256898-OxYT/
Next one will be:
Portsmouth, NH
October 22–24
We think Portsmouth will be a fine location for the boot camp. Rooms
should be much cheaper than in Boston, and there are buses that go
directly from Boston/Logan Airport to Portsmouth.
On 5/20/2025 23:00, Arne Vajhøj wrote:
https://www.linkedin.com/posts/vms-software-inc-_thats-a-wrap-for-the-
malm%C3%B6-bootcamp-over-activity-7330638443586256898-OxYT/
Next one will be:
Portsmouth, NH
October 22–24
We think Portsmouth will be a fine location for the boot camp. Rooms
should be much cheaper than
in Boston, and there are buses that go directly from Boston/Logan
Airport to Portsmouth.
https://www.linkedin.com/posts/vms-software-inc-_thats-a-wrap-for-the- malm%C3%B6-bootcamp-over-activity-7330638443586256898-OxYT/
Next one will be:
Portsmouth, NH
October 22–24
On 5/20/2025 11:00 PM, Arne Vajhøj wrote:
https://www.linkedin.com/posts/vms-software-inc-_thats-a-wrap-for-the-
malm%C3%B6-bootcamp-over-activity-7330638443586256898-OxYT/
Next one will be:
Portsmouth, NH
October 22–24
Note that there are links to presentations from Malmö at:
https://events.vmssoftware.com/bootcamp-repository
On 6/3/25 12:24 PM, Arne Vajhøj wrote:
On 5/20/2025 11:00 PM, Arne Vajhøj wrote:
https://www.linkedin.com/posts/vms-software-inc-_thats-a-wrap-for-
the- malm%C3%B6-bootcamp-over-activity-7330638443586256898-OxYT/
Next one will be:
Portsmouth, NH
October 22–24
Note that there are links to presentations from Malmö at:
https://events.vmssoftware.com/bootcamp-repository
The link to presentation materials under Malmö points to
https://app.box.com/folder/322067756653
but Box says, "Oops! We can't seem to find the page you're looking for."
On 6/5/2025 9:28 PM, Craig A. Berry wrote:
On 6/3/25 12:24 PM, Arne Vajhøj wrote:
On 5/20/2025 11:00 PM, Arne Vajhøj wrote:
https://www.linkedin.com/posts/vms-software-inc-_thats-a-wrap-for-
the- malm%C3%B6-bootcamp-over-activity-7330638443586256898-OxYT/
Next one will be:
Portsmouth, NH
October 22–24
Note that there are links to presentations from Malmö at:
https://events.vmssoftware.com/bootcamp-repository
The link to presentation materials under Malmö points to
https://app.box.com/folder/322067756653
but Box says, "Oops! We can't seem to find the page you're looking for."
When I click that link I get prompted for login.
VSI should fix.
https://www.linkedin.com/posts/vms-software-inc-_thats-a-wrap-for-the-malm%C3%B6-bootcamp-over-activity-7330638443586256898-OxYT/
Next one will be:
Portsmouth, NH
October 22–24
Arne
... just what went down at Malmo?
On Sat, 7 Jun 2025 17:06:31 +1000, Subcommandante XDelta wrote:
... just what went down at Malmo?
I think that’s either “Malmø” or “Malmö”, depending on which side of the
Øresund (or is that Öresund?) you’re on ...
On 6/7/2025 3:24 AM, Lawrence D'Oliveiro wrote:
On Sat, 7 Jun 2025 17:06:31 +1000, Subcommandante XDelta wrote:
... just what went down at Malmo?
I think that?s either ?Malm? or ?Malm?, depending on which side of the
resund (or is that resund?) you?re on ...
It is resund in Danish and resund in Swedish, but it may be
most correct to use Malm and resund, because Sweden got the
city from Denmark in 1658 (due to cold weather!!!!), but the
waterway stayed with Denmark (and Denmark collected tax from
ships sailing through until 1857).
$ set response/mode=good_natured
Us crazy Europeans and the fact we refuse to restrict ourselves to
using good old 7-bit US ASCII. :-)
On 2025-06-07, Arne Vajhj <arne@vajhoej.dk> wrote:
On 6/7/2025 3:24 AM, Lawrence D'Oliveiro wrote:
On Sat, 7 Jun 2025 17:06:31 +1000, Subcommandante XDelta wrote:
... just what went down at Malmo?
I think that?s either ?Malm? or ?Malm?, depending on which side of the >>> resund (or is that resund?) you?re on ...
It is resund in Danish and resund in Swedish, but it may be
most correct to use Malm and resund, because Sweden got the
city from Denmark in 1658 (due to cold weather!!!!), but the
waterway stayed with Denmark (and Denmark collected tax from
ships sailing through until 1857).
$ set response/mode=good_natured
Us crazy Europeans and the fact we refuse to restrict ourselves to
using good old 7-bit US ASCII. :-)
What is interesting is how some same word spellings are pronounced >differently depending on which European country you are in.
In article <1026kum$hpp1$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2025-06-07, Arne Vajhj <arne@vajhoej.dk> wrote:
On 6/7/2025 3:24 AM, Lawrence D'Oliveiro wrote:
On Sat, 7 Jun 2025 17:06:31 +1000, Subcommandante XDelta wrote:
... just what went down at Malmo?
I think that?s either ?Malm? or ?Malm?, depending on which side of the >>>> resund (or is that resund?) you?re on ...
It is resund in Danish and resund in Swedish, but it may be
most correct to use Malm and resund, because Sweden got the
city from Denmark in 1658 (due to cold weather!!!!), but the
waterway stayed with Denmark (and Denmark collected tax from
ships sailing through until 1857).
$ set response/mode=good_natured
Us crazy Europeans and the fact we refuse to restrict ourselves to
using good old 7-bit US ASCII. :-)
"Us"? Aren't you in the UK? :-D :-D :-D
(Too soon?)
I've always found this criticism of ASCII kind of weird. Of
course it's US-centric; it was designed in the US. The "A"
stands for "American", after all.
On 2025-06-09, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <1026kum$hpp1$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2025-06-07, Arne Vajhj <arne@vajhoej.dk> wrote:
On 6/7/2025 3:24 AM, Lawrence D'Oliveiro wrote:
On Sat, 7 Jun 2025 17:06:31 +1000, Subcommandante XDelta wrote:
... just what went down at Malmo?
I think that?s either ?Malm? or ?Malm?, depending on which side of the >>>>> resund (or is that resund?) you?re on ...
It is resund in Danish and resund in Swedish, but it may be
most correct to use Malm and resund, because Sweden got the
city from Denmark in 1658 (due to cold weather!!!!), but the
waterway stayed with Denmark (and Denmark collected tax from
ships sailing through until 1857).
$ set response/mode=good_natured
Us crazy Europeans and the fact we refuse to restrict ourselves to
using good old 7-bit US ASCII. :-)
"Us"? Aren't you in the UK? :-D :-D :-D
Not everyone in the UK denies geography and shared cultural values. :-(
(Too soon?)
I've always found this criticism of ASCII kind of weird. Of
course it's US-centric; it was designed in the US. The "A"
stands for "American", after all.
I guess I was being a bit too subtle. :-)
It was not a comment against the US ASCII character set, but a comment
about how too many Americans expect everyone else in the world to adapt
to them (and to their limited understanding of the rest of the world).
"Why don't they just speak English ?"
-- Clueless political person talking about alien contact, Contact (1997)
A fictional comment that seems to reflect reality, especially these days.
What is interesting is how some same word spellings are pronounced differently depending on which European country you are in.
If a character set had been designed in some European country, I
would expect it to be localized to that country's writing
system; it wouldn't be reasonable for me to be upset that it did
not cater to the US in that case, because the US didn't invent
it.
On 6/9/2025 8:44 AM, Simon Clubley wrote:
What is interesting is how some same word spellings are pronounced
differently depending on which European country you are in.
Different languages have totally different "sound style" - not
particular surprising that the same word may be pronounced
differently. Some words are close to impossible to pronounce in
some languages.
What is weird is that in English many cities got very different
spelling of names than in their native language - more different
than what is warranted by differences in alphabets.
København - Copenhagen
On 6/9/2025 15:23, Arne Vajhøj wrote:
On 6/9/2025 8:44 AM, Simon Clubley wrote:
What is interesting is how some same word spellings are pronounced
differently depending on which European country you are in.
Different languages have totally different "sound style" - not
particular surprising that the same word may be pronounced
differently. Some words are close to impossible to pronounce in
some languages.
What is weird is that in English many cities got very different
spelling of names than in their native language - more different
than what is warranted by differences in alphabets.
København - Copenhagen
When I was in Denmark, I asked about that, and the answer I was given
was along the lines of "Blame the French".
On 6/9/2025 8:44 AM, Simon Clubley wrote:
What is interesting is how some same word spellings are pronounced
differently depending on which European country you are in.
Different languages have totally different "sound style" - not
particular surprising that the same word may be pronounced
differently. Some words are close to impossible to pronounce in
some languages.
What is weird is that in English many cities got very different
spelling of names than in their native language - more different
than what is warranted by differences in alphabets.
København - Copenhagen
München - Munich
Köln - Cologne
Firenze - Florence
etc.
Arne
On 6/9/2025 11:58 AM, Dan Cross wrote:
If a character set had been designed in some European country, I
would expect it to be localized to that country's writing
system; it wouldn't be reasonable for me to be upset that it did
not cater to the US in that case, because the US didn't invent
it.
The Western European alphabets are supersets of the English alphabet,
so the UK/US would not be missing any letters.
But if we for Western European alphabets take the abomination
known as ISO-646/ECMA-6, then all SW people will be missing
something. ASCII [\]{|} are among those used for national characters.
On Mon, 9 Jun 2025 15:16:26 -0400, Arne Vajhøj wrote:
But if we for Western European alphabets take the abomination known as
ISO-646/ECMA-6, then all SW people will be missing something.
Aren’t all the world’s national character sets on the way out, being steadily supplanted by Unicode?
But if we for Western European alphabets take the abomination known as ISO-646/ECMA-6, then all SW people will be missing something.
What is weird is that in English many cities got very different
spelling of names than in their native language - more different
than what is warranted by differences in alphabets.
Kbenhavn - Copenhagen
Mnchen - Munich
Kln - Cologne
Firenze - Florence
etc.
On 6/9/2025 11:58 AM, Dan Cross wrote:
If a character set had been designed in some European country, I
would expect it to be localized to that country's writing
system; it wouldn't be reasonable for me to be upset that it did
not cater to the US in that case, because the US didn't invent
it.
The Western European alphabets are supersets of the English alphabet,
so the UK/US would not be missing any letters.
But if we for Western European alphabets take the abomination
known as ISO-646/ECMA-6, then all SW people will be missing
something. ASCII [\]{|} are among those used for national characters.
Enquiring minds want to know - just what went down at Malmo?Business as usual.
Le 07/06/2025 09:06, Subcommandante XDelta a crit:
Enquiring minds want to know - just what went down at Malmo?Business as usual.
The supplier is the center of the ecosystem and knows what is good for you.
The problem is: did VMS ecosystem survived thanks to "business as
usual"? I remember discutions here in 2013 where everybody known VMS
will dye, because of the standard rules of business.
Summary: VSI is redoing the same mistake as Digital: because we have got
a superior and genial offer we have not to hear about the way the
ecosystem and its context have evolved. The bad side of the excellence.
The problem is: did VMS ecosystem survived thanks to "business as
usual"? I remember discutions here in 2013 where everybody known VMS
will dye, because of the standard rules of business.
On 2025-07-01, gcalliet <gerard.calliet@pia-sofer.fr> wrote:
Le 07/06/2025 à 09:06, Subcommandante XDelta a écrit :
Enquiring minds want to know - just what went down at Malmo?Business as usual.
The supplier is the center of the ecosystem and knows what is good for you. >>
The problem is: did VMS ecosystem survived thanks to "business as
usual"? I remember discutions here in 2013 where everybody known VMS
will dye, because of the standard rules of business.
Summary: VSI is redoing the same mistake as Digital: because we have got
a superior and genial offer we have not to hear about the way the
ecosystem and its context have evolved. The bad side of the excellence.
Can you offer specific examples ? It's hard to have a discussion unless
there are specific concerns listed.
Simon.
On Tue, 1 Jul 2025 11:39:15 +0200, gcalliet wrote:Of course.
The problem is: did VMS ecosystem survived thanks to "business as
usual"? I remember discutions here in 2013 where everybody known VMS
will dye, because of the standard rules of business.
I would say their market is a fraction of what it would have been if they
had been ready with an x86 port say, five years earlier.
Le 01/07/2025 à 19:27, Simon Clubley a écrit :
On 2025-07-01, gcalliet <gerard.calliet@pia-sofer.fr> wrote:
Le 07/06/2025 à 09:06, Subcommandante XDelta a écrit :
Enquiring minds want to know - just what went down at Malmo?Business as usual.
The supplier is the center of the ecosystem and knows what is good
for you.
The problem is: did VMS ecosystem survived thanks to "business as
usual"? I remember discutions here in 2013 where everybody known VMS
will dye, because of the standard rules of business.
Summary: VSI is redoing the same mistake as Digital: because we have got >>> a superior and genial offer we have not to hear about the way the
ecosystem and its context have evolved. The bad side of the excellence.
Can you offer specific examples ? It's hard to have a discussion unless
there are specific concerns listed.
Camiel explain very clearly the strategy choosed, and explain the way
users should go. How can we do if this strategy is not good for us?
Darya says "our actual goal is making our customers go to x86". Is it
sure all the VMS users can go as fast as possible to x86?
I know people who need bare metal solutions, there were someone at the bootcamp who ask this question. No answer. It is not the strategy.
Presentation of the best (for VSI) new solution: going to the cloud (VSI Cloud offer based on Oracle cloud) and final possibility being some
Saas. Not any discussion about this strategy except "the times are
changing, we go with them".
Every point has somehow strong justifications. But I think we are
missing a more collaborating brainstorming about the needs, pace of evolutions, goals...
In the old times, when we had a strong world wide compagny, and when everything was at its beginning, ok. Now there is a complex ecosystem
trying to rebound. Perhaps another way of building strategies could help.
Presentation of the best (for VSI) new solution: going to the cloud (VSI Cloud offer based on Oracle cloud) and final possibility being some
Saas. Not any discussion about this strategy except "the times are
changing, we go with them".
On Wed, 2 Jul 2025 14:01:46 +0200, gcalliet wrote:
Le 02/07/2025 à 02:05, Lawrence D'Oliveiro a écrit :
I would say their market is a fraction of what it would have been ifOf course.
they had been ready with an x86 port say, five years earlier.
But also VSI didn't really address the ecosystem as the complex set it
is, with totally different needs and paces of evolution.
Essentially all the (remaining) customers were waiting to move to x86, because all the existing platforms that VMS ran on were dead-ends 10 years ago. The only strategy left to VSI was “run as fast as possible”.
We discussed this sort of thing in this group a few years ago. The obvious way it seemed to me to get to a shipping product as quickly as possible
was to re-implement VMS as an emulation layer on top of a Linux kernel.
Chuck away all the internals of the super/exec/kernel-mode legacy baggage: keep just the userland APIs and DCL. Hardly anybody would care about
anything else.
Le 02/07/2025 à 02:05, Lawrence D'Oliveiro a écrit :
Of course.
I would say their market is a fraction of what it would have been if
they had been ready with an x86 port say, five years earlier.
But also VSI didn't really address the ecosystem as the complex set it
is, with totally different needs and paces of evolution.
On 7/2/2025 7:32 PM, Lawrence D'Oliveiro wrote:
[snip]
You keep pushing that idea.
But:
[snip]
5) The idea of emulating one OS on another OS is questionable
in itself.
It is not that difficult to achieve 90-95%
compatibility. But 100% compatibility is very hard.
Because
the core OS design tend to spill over into
userland semantics. It is always tricky to emulate *nix
on VMS and it would be be tricky to emulate VMS on *nix.
Getting DCL, image activation, process permanent files,
subprocesses, logicals and symbols working 100% compatible
on a Linux kernel would not be easy. A lot hang on the
4 mode design and DCL being in S.
On 7/3/2025 10:56 AM, Arne Vajhøj wrote:
On 7/2/2025 7:32 PM, Lawrence D'Oliveiro wrote:
On Wed, 2 Jul 2025 14:01:46 +0200, gcalliet wrote:
Le 02/07/2025 à 02:05, Lawrence D'Oliveiro a écrit :
I would say their market is a fraction of what it would have been if >>>>> they had been ready with an x86 port say, five years earlier.Of course.
But also VSI didn't really address the ecosystem as the complex set it >>>> is, with totally different needs and paces of evolution.
Essentially all the (remaining) customers were waiting to move to x86,
because all the existing platforms that VMS ran on were dead-ends 10
years
ago. The only strategy left to VSI was “run as fast as possible”.
We discussed this sort of thing in this group a few years ago. The
obvious
way it seemed to me to get to a shipping product as quickly as possible
was to re-implement VMS as an emulation layer on top of a Linux kernel.
Chuck away all the internals of the super/exec/kernel-mode legacy
baggage:
keep just the userland APIs and DCL. Hardly anybody would care about
anything else.
You keep pushing that idea.
But:
1) Third party user mode emulations has existed for decades, but
there is still demand for VMS, so the hypothesis that
"Hardly anybody would care about anything else" does not
match with the real world.
2) The assumption that it would be easier to rewrite user mode
stuff to use Linux kernel than rewrite VMS kernel to support
x86-64 has been rejected by everyone that has spoken on the
topic *and* has actually worked on VMS.
3) The kernel is only a part of the project - an important part
but still just a part. Another huge part has been the compilers.
Getting Fortran, Pascal, Cobol and Basic compilers that
accept all the traditional VMS extensions so existing code
continues to compile has been a huge effort.
4) As with any software project writing the code is just a
part of the project. On top of that comes planning,
project management, testing, documentation etc.. The number
of hours for does not depend much on the technical implementation.
5) The idea of emulating one OS on another OS is questionable
in itself. It is not that difficult to achieve 90-95%
compatibility. But 100% compatibility is very hard. Because
the core OS design tend to spill over into
userland semantics. It is always tricky to emulate *nix
on VMS and it would be be tricky to emulate VMS on *nix.
Getting DCL, image activation, process permanent files,
subprocesses, logicals and symbols working 100% compatible
on a Linux kernel would not be easy. A lot hang on the
4 mode design and DCL being in S.
Please stop feeding the troll. He is going to continue to insist
that the only survival for VMS is to become another Linux distribution.
You can't win. Starve it and let it die.
bill
5) The idea of emulating one OS on another OS is questionable
in itself. It is not that difficult to achieve 90-95%
compatibility. But 100% compatibility is very hard. Because
the core OS design tend to spill over into
userland semantics. It is always tricky to emulate *nix
on VMS and it would be be tricky to emulate VMS on *nix.
Getting DCL, image activation, process permanent files,
subprocesses, logicals and symbols working 100% compatible on a
Linux kernel would not be easy. A lot hang on the 4 mode design and
DCL being in S.
On Thu, 3 Jul 2025 10:56:26 -0400, Arne Vajhøj wrote:
5) The idea of emulating one OS on another OS is questionable
in itself. It is not that difficult to achieve 90-95%
compatibility. But 100% compatibility is very hard. Because
the core OS design tend to spill over into
userland semantics. It is always tricky to emulate *nix
on VMS and it would be be tricky to emulate VMS on *nix.
It was always tricky to emulate *nix on proprietary OSes. But emulating proprietary OSes on Linux does actually work a lot better. Look at WINE, which has progressed to the point where it can be the basis of a
successful shipping product (the Steam Deck) that lets users run Windows games without Windows. That works so well, it puts true Windows-based handheld competitors in the shade.
That has never been done before. And it’s got to be a more difficult job than emulating VMS, with its much simpler APIs.
Getting DCL, image activation, process permanent files,
subprocesses, logicals and symbols working 100% compatible on a
Linux kernel would not be easy. A lot hang on the 4 mode design and
DCL being in S.
We don’t need to emulate the internals of DCL. We just need to be able to run users’ command procedures.
After 31 years of work, then Wine is pretty good. But I don't think
anyone would call it 100% compatible.
We don’t need to emulate the internals of DCL. We just need to be able
to run users’ command procedures.
The issue is that the internals is reflected in the semantics. It
becomes messy.
On Thu, 3 Jul 2025 10:56:26 -0400, Arne Vajhøj wrote:
5) The idea of emulating one OS on another OS is questionable
in itself. It is not that difficult to achieve 90-95%
compatibility. But 100% compatibility is very hard. Because
the core OS design tend to spill over into
userland semantics. It is always tricky to emulate *nix
on VMS and it would be be tricky to emulate VMS on *nix.
It was always tricky to emulate *nix on proprietary OSes. But emulating proprietary OSes on Linux does actually work a lot better. Look at WINE, which has progressed to the point where it can be the basis of a
successful shipping product (the Steam Deck) that lets users run Windows games without Windows. That works so well, it puts true Windows-based handheld competitors in the shade.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
It was always tricky to emulate *nix on proprietary OSes. But
emulating proprietary OSes on Linux does actually work a lot
better. Look at WINE, which has progressed to the point where it
can be the basis of a successful shipping product (the Steam Deck)
that lets users run Windows games without Windows. That works so
well, it puts true Windows-based handheld competitors in the shade.
You mention Wine, but do you know what you are talking about?
What went wrong? Clearly VSI hit some difficulties. Public information indicates that work on compilers took more time than expected (and that
could slow down other work as it depends on working compilers).
On Sun, 6 Jul 2025 00:36:51 -0000 (UTC), Waldek Hebisch wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
It was always tricky to emulate *nix on proprietary OSes. But
emulating proprietary OSes on Linux does actually work a lot
better. Look at WINE, which has progressed to the point where it
can be the basis of a successful shipping product (the Steam Deck)
that lets users run Windows games without Windows. That works so
well, it puts true Windows-based handheld competitors in the shade.
You mention Wine, but do you know what you are talking about?
Just look at the success of the Steam Deck, and you’ll see.
What went wrong? Clearly VSI hit some difficulties. Public information
indicates that work on compilers took more time than expected (and that
could slow down other work as it depends on working compilers).
Weren’t they using existing code-generation tools like LLVM? That should have saved them a lot of work.
No, the sheer job of reimplementing the entire kernel stack (including
custom driver support) on a new architecture was what slowed them down.
And the effort should have been avoided.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
No, the sheer job of reimplementing the entire kernel stack (including
custom driver support) on a new architecture was what slowed them down.
And the effort should have been avoided.
There are no indicatianos of substantial reimplementation.
You mention Wine, but do you know what you are talking about? At the
start Wine project had idea similar to yours: write loader for Windows binaries, redirect system library calls to equivalent Linux
system/library calls and call it done. The loader part
went smoothly, but they relatively quickly (in around 2 years)
discoverd that devil is in emulating Windows libraries. Initial idea
of redirecting...
Given 40+ developement team (this seem to correspond to publicaly
available information about VSI) and considering 10kloc/year developer productivity...
...What went wrong? Clearly VSI hit some difficulties...
There are no indicatianos of substantial reimplementation. Official
info says that new or substantially reworked code is in C. But w also
have information that amount of Macro32 and Bliss did not substantially decrease. So, (almost all) old code is still in use.
It could be that small changes to old code took a lot of time. It could
be that some new pieces were particularly tricky. However, you should understand that porting really means replicating exisiting behaviour on
new hardware. Replicating behaviour gets more tricky if you change
more parts and especially if you want to target a high level interface.
Some bozo once wrote: "...VSI spends years creating an inevitably-somewhat-incomplete third-party Linux porting kit for
customer OpenVMS apps ...
... and the end goal of the intended customers then
inexorably shifts toward the removal of that porting kit, and probably
in the best case the whole effort inevitably degrades into apps ported
top and running on VSI Linux.
And I'd be willing to bet money VSI will need a number of modifications
to the Linux kernel, too.
What you've posted has been highlighted before. As has porting VAX/VMS
to the Mach kernel, which actually happened.
It also doesn't appreciably move the operating system work forward.
Ports ~never do.
And there is a vendor that already provides custom solutions based on
porting parts of the APIs to another platform, with Sector7. What
Sector7 offers very much parallels Proton and Wine, too.
40 or 50 engineers is far too small for a project of the scale and scope
of a feature-competitive operating system.
For a competitive platform, I'd be looking to build (slowly) to
2000, andquite possibly more. But that takes revenues and
reinvestments.
As an example of scale and scope that ties back to Valve and their
efforts with Wine and Proton and Steam Deck and other functions, Valve
may well presently have as many job openings as VSI has engineers ...
On 2025-07-06 12:52:22 +0000, Waldek Hebisch said:
There are no indicatianos of substantial reimplementation. Official
info says that new or substantially reworked code is in C. But w also
have information that amount of Macro32 and Bliss did not
substantially decrease. So, (almost all) old code is still in use.
It could be that small changes to old code took a lot of time. It
could be that some new pieces were particularly tricky. However, you
should understand that porting really means replicating exisiting
behaviour on new hardware. Replicating behaviour gets more tricky if
you change more parts and especially if you want to target a high
level interface.
You're correct. Reworking existing working code is quite often an
immense mistake.
It usually fails. If not always fails.
And bringing a source-to-source translation tooling or an LLM can be
helpful, and can also introduce new issues and new bugs.
About the only way a global rewrite can succeed — absent a stratospheric-scale budget for the rewrite, and maybe not even then — is
an incremental rewrite, as the specific modules need more than trivial modifications.
Reworking a project of the scale of OpenVMS — easily a decade-long
freeze — and for little benefit to VSI.
On 7/11/2025 8:16 PM, Arne Vajhøj wrote:
The idea of a 1:1 port is usually bad. Yes - you can implement the
exact same flow of your Cobol application in Java/C++/Go/C#,
but that only solves a language problem not an architecture problem.
The biggest problem with this the idea of going from a domain specific language to a general purpose language. While you can write an IS in
pretty much any language (imagine rewriting the entire government
payroll currently in COBOL in BASIC!!) there were real advantages to
having domain specific languages. But then, no one today seems to even consider things like efficiency. Just throw more hardware at the
problem.
You need to re-architect the solution: from ISAM to RDBMS,
This is the only one I totally agree with but the original problem
had nothing to do with the language. It had to do with the fact that
RDBMS wasn't around when COBOL was written. I have been doing COBOL
and RDBMS since 1980 and it was old code when I got there.
from vertical app scaling to horizontal app scaling,
Not really sure what this means. :-)
from 5x16 to
7x24 operations etc..
Certainly don't get this. Every place I ever saw COBOL was 24/7 and
that is going back to at least 1972.
On 7/12/2025 10:41 AM, Arne Vajhøj wrote:
On 7/12/2025 9:35 AM, bill wrote:
On 7/11/2025 8:16 PM, Arne Vajhøj wrote:If
you have a Cobol system using ISAM files, then do not want to convert
it to a Java/C++/Go/C# system using ISAM files.
If you have a COBOL program using ISAM today it should have been
converted to DBMS years ago. That does not imply that it should be converted to JAVA/C++/Go/C#.
from vertical app scaling to horizontal app scaling,
Not really sure what this means. :-)
You can call it cluster support.
If you run out of CPU power, then instead of upgrading from a
big expensive box to a very big very expensive box then you just
add a cluster node more.
OK. But I don't see what that has to do with it being written in COBOL.
Or are you saying that IBM Systems don't scale?
from 5x16 to
7x24 operations etc..
Certainly don't get this. Every place I ever saw COBOL was 24/7 and
that is going back to at least 1972.
I would be surprised if you have never experienced a financial
institution operating with a "transaction will be completed
next day" model.
I get that now. That has nothing to do with IT and everything to do
with people and their being more "legacy" than the IS. I am finally starting to see change. My last automatic payment from DFAS wasn't
really due until a Monday, but the funds showed up on a Saturday.
Even things that once ran only nightly as "batch" are now processed
almost immediately. But the people still only work 8 hours a day 5
days a week and it is them that cause the apparent lag in most IT processing. Used to be systems went offline for 6-8 hours for backups. Today if they go offline at all it is for seconds to minutes. But, none
of this was ever related to the language an IS was written in and
rewriting it in JAVA/C++/Go/C# is not going to improve anything.
On 7/12/2025 11:13 AM, Arne Vajhøj wrote:
So again again if you rewrite an application, then you want
to change that logic instead of doing the 1:1 conversion.
And this, of course, is where we disagree. You see rewrites as
normal and the best way to go. I see them as usually a waste of
time being called on for the wrong reasons. Because your peers
at a conference laugh at your legacy system is no reason to rewrite
it. (And, yes, I have seen senior management want to make major
and often ridiculous changes based on something their peers said
over lunch at a conference!!)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 508 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 14:42:05 |
| Calls: | 9,991 |
| Calls today: | 1 |
| Files: | 13,839 |
| Messages: | 6,359,891 |
| Posted today: | 1 |
