On Wednesday, October 4, 2023 at 4:55:29 PM UTC+3, bill wrote:
> On 10/4/2023 9:23 AM, Michael S wrote:
> > On Tuesday, October 3, 2023 at 3:33:07 PM UTC+3, Simon Clubley wrote:
> >>
> >> The engineers clearly know what they are doing, but the same cannot
> >> be said about the management.
> >>
> >
> > I'd speculate that it's combination of engineers and management.
> > Engineers are competent, but aging. They have the common tendency
> > of the age - preference to remain in comfort zone.
> > Now, since they *are* competent the *can* be productive outside of
> > their comfort zone, but unlikely to come here on their own. They have
> > to be dragged. By management, who else? And not primitively, primitive
> > dragging would face strong opposition. The have to be dragged in skilful
> > manner.
> >
> > My favorite example is programming tools where, in my opinion, cross-tools
> > hosted on non-VMS x86-64 should have been produced first. After that,
> > x86-64 port could have been productized, even without all native tools ready.
> > They could have come later.
> > Instead of that VMS-Itanium hosted tools were created first, not because it
> > was technically easier, but because in this way old competent engineers didn't
> > have to leave their comfort zone.
> >
> I am a bit confused by the above. Do you mean tools on VMS but
> not on x86 or do you mean tools not on VMS.
>

Tools not on VMS, running on the same x86-64 as VMS or on different
machine. Since VMS has to run in VM, anyway, the machine is always available.
It would have been far easier to host LLVM tools on Linux, where all infrastructure
is available. Less easy on Windows, but even on Windows far easier than on VMS.
And devs (customer's devs) can use source control and other auxiliary tools they
already have and are comfortable with.
Unlike VSI devs, customer's devs are not necessarily first-league engineers; they
should not be dragged out of their comfort zone forcefully by somebody as small
and unimportant as VSI.

> In any event, what was chosen was tools on Itanium VMS. I,
> for one, am not so sure that was a good idea. I am sure the
> numbers would never be released but I wonder what the current
> breakdown of licensed production VMS architectures are. (even
> percentages would be interesting). In any event, I think
> requiring one to have an Itanium in order to move to x86 is
> not really a good idea.
>

And that's one of the reasons why The Port was not officially productized
for so long. Would not be a problem if tools were Linux/Windows based.

> Of course the other big question would be can one move directly
> from VAX to x86. Not likely, I suppose, as I would imagine
> most people still on VAX may be there for hardware rather than
> software reasons.
>

I know people that are "on Vax/VMS" for software reasons. Of course, most
of them are on Charon, but they told me about one individual that somehow
manages to use real uVax in production. But "production" in this
particular case is development/maintenance of VAXELN software.

> But, as I said, I would be very interested in the current
> breakdown of architectures still running production VMS.
>
> bill

On Wednesday, October 4, 2023 at 10:32:23 AM UTC-4, Michael S wrote:
> On Wednesday, October 4, 2023 at 4:55:29 PM UTC+3, bill wrote:
> > On 10/4/2023 9:23 AM, Michael S wrote:
> > > On Tuesday, October 3, 2023 at 3:33:07 PM UTC+3, Simon Clubley wrote:
> > >>
> > >> The engineers clearly know what they are doing, but the same cannot
> > >> be said about the management.
> > >>
> > >
> > > I'd speculate that it's combination of engineers and management.
> > > Engineers are competent, but aging. They have the common tendency
> > > of the age - preference to remain in comfort zone.
> > > Now, since they *are* competent the *can* be productive outside of
> > > their comfort zone, but unlikely to come here on their own. They have
> > > to be dragged. By management, who else? And not primitively, primitive
> > > dragging would face strong opposition. The have to be dragged in skilful
> > > manner.
> > >
> > > My favorite example is programming tools where, in my opinion, cross-tools
> > > hosted on non-VMS x86-64 should have been produced first. After that,
> > > x86-64 port could have been productized, even without all native tools ready.
> > > They could have come later.
> > > Instead of that VMS-Itanium hosted tools were created first, not because it
> > > was technically easier, but because in this way old competent engineers didn't
> > > have to leave their comfort zone.
> > >
> > I am a bit confused by the above. Do you mean tools on VMS but
> > not on x86 or do you mean tools not on VMS.
> >
> Tools not on VMS, running on the same x86-64 as VMS or on different
> machine. Since VMS has to run in VM, anyway, the machine is always available.
> It would have been far easier to host LLVM tools on Linux, where all infrastructure
> is available. Less easy on Windows, but even on Windows far easier than on VMS.
> And devs (customer's devs) can use source control and other auxiliary tools they
> already have and are comfortable with.
> Unlike VSI devs, customer's devs are not necessarily first-league engineers; they
> should not be dragged out of their comfort zone forcefully by somebody as small
> and unimportant as VSI.
> > In any event, what was chosen was tools on Itanium VMS. I,
> > for one, am not so sure that was a good idea. I am sure the
> > numbers would never be released but I wonder what the current
> > breakdown of licensed production VMS architectures are. (even
> > percentages would be interesting). In any event, I think
> > requiring one to have an Itanium in order to move to x86 is
> > not really a good idea.
> >
> And that's one of the reasons why The Port was not officially productized
> for so long. Would not be a problem if tools were Linux/Windows based.
> > Of course the other big question would be can one move directly
> > from VAX to x86. Not likely, I suppose, as I would imagine
> > most people still on VAX may be there for hardware rather than
> > software reasons.
> >
> I know people that are "on Vax/VMS" for software reasons. Of course, most
> of them are on Charon, but they told me about one individual that somehow
> manages to use real uVax in production. But "production" in this
> particular case is development/maintenance of VAXELN software.
> > But, as I said, I would be very interested in the current
> > breakdown of architectures still running production VMS.
> >
> > bill
Could we have produced Linux x86-hosted, OpenVMS x86-targeted tooling?

Well that would mean that I would need a Linux x86-hosted/Linux x86-target
version of Macro-32 (a large piece of Macro is written in Macro), BLISS-32,
BLISS-64, SDL, MESSAGE, CDU, just to build my Linux x86-hosted/OpenVMS
targetted compilers. [Yes we had some/many of those in the past, but not
a Macro compiler for example].

In addition, the entire OpenVMS build is many layers of DCL command files
which use things like CMS. Recoding our (admittedly old and crusty) build
environment to Linux with newer tools would just be an unneeded step in
the path.

And things like file name differences, etc would have also slowed things
down to some degree.

As GEM compilers, I have plenty of experience in making non-OpenVMS
hosted compilers. Our bootstrapping of LLVM/clang from Linux-x86 to
OpenVMS-x86 involves a clang cross-compiler. Fortunately, since there
is no Macro, BLISS, SDL, etc in clang/LLVM, I didn't have to invent new
tooling. However, those cross-builds on Linux have a hybrid set of
headers since building that cross-compiler needs to know it is hosted on
Linux (where things like printf is named "printf") but compiling code for
OpenVMS (where things like printf is not named "printf").

We certainly discussed the initial bootstrapping environment for the
OS and compilers. The fact that I have a perfectly good set of Macro,
BLISS, and C compilers that generate code for OpenVMS Itanium as
well as all the tooling (MESSAGE, CDU, MMS, CMS, DCL, etc.) was the
better solution.

On Wednesday, October 4, 2023 at 6:12:14 PM UTC+3, John Reagan wrote:
> On Wednesday, October 4, 2023 at 10:32:23 AM UTC-4, Michael S wrote:
> > On Wednesday, October 4, 2023 at 4:55:29 PM UTC+3, bill wrote:
> > > On 10/4/2023 9:23 AM, Michael S wrote:
> > > > On Tuesday, October 3, 2023 at 3:33:07 PM UTC+3, Simon Clubley wrote:
> > > >>
> > > >> The engineers clearly know what they are doing, but the same cannot
> > > >> be said about the management.
> > > >>
> > > >
> > > > I'd speculate that it's combination of engineers and management.
> > > > Engineers are competent, but aging. They have the common tendency
> > > > of the age - preference to remain in comfort zone.
> > > > Now, since they *are* competent the *can* be productive outside of
> > > > their comfort zone, but unlikely to come here on their own. They have
> > > > to be dragged. By management, who else? And not primitively, primitive
> > > > dragging would face strong opposition. The have to be dragged in skilful
> > > > manner.
> > > >
> > > > My favorite example is programming tools where, in my opinion, cross-tools
> > > > hosted on non-VMS x86-64 should have been produced first. After that,
> > > > x86-64 port could have been productized, even without all native tools ready.
> > > > They could have come later.
> > > > Instead of that VMS-Itanium hosted tools were created first, not because it
> > > > was technically easier, but because in this way old competent engineers didn't
> > > > have to leave their comfort zone.
> > > >
> > > I am a bit confused by the above. Do you mean tools on VMS but
> > > not on x86 or do you mean tools not on VMS.
> > >
> > Tools not on VMS, running on the same x86-64 as VMS or on different
> > machine. Since VMS has to run in VM, anyway, the machine is always available.
> > It would have been far easier to host LLVM tools on Linux, where all infrastructure
> > is available. Less easy on Windows, but even on Windows far easier than on VMS.
> > And devs (customer's devs) can use source control and other auxiliary tools they
> > already have and are comfortable with.
> > Unlike VSI devs, customer's devs are not necessarily first-league engineers; they
> > should not be dragged out of their comfort zone forcefully by somebody as small
> > and unimportant as VSI.
> > > In any event, what was chosen was tools on Itanium VMS. I,
> > > for one, am not so sure that was a good idea. I am sure the
> > > numbers would never be released but I wonder what the current
> > > breakdown of licensed production VMS architectures are. (even
> > > percentages would be interesting). In any event, I think
> > > requiring one to have an Itanium in order to move to x86 is
> > > not really a good idea.
> > >
> > And that's one of the reasons why The Port was not officially productized
> > for so long. Would not be a problem if tools were Linux/Windows based.
> > > Of course the other big question would be can one move directly
> > > from VAX to x86. Not likely, I suppose, as I would imagine
> > > most people still on VAX may be there for hardware rather than
> > > software reasons.
> > >
> > I know people that are "on Vax/VMS" for software reasons. Of course, most
> > of them are on Charon, but they told me about one individual that somehow
> > manages to use real uVax in production. But "production" in this
> > particular case is development/maintenance of VAXELN software.
> > > But, as I said, I would be very interested in the current
> > > breakdown of architectures still running production VMS.
> > >
> > > bill
> Could we have produced Linux x86-hosted, OpenVMS x86-targeted tooling?
>
> Well that would mean that I would need a Linux x86-hosted/Linux x86-target
> version of Macro-32 (a large piece of Macro is written in Macro), BLISS-32,
> BLISS-64, SDL, MESSAGE, CDU, just to build my Linux x86-hosted/OpenVMS
> targetted compilers. [Yes we had some/many of those in the past, but not
> a Macro compiler for example].
>

Linux x86-target does not have to be full-featured. For example, it can be
transpiler from above-mentioned languages to C or to any other language of
choice available on Linux, rather than full compiler.

> In addition, the entire OpenVMS build is many layers of DCL command files
> which use things like CMS. Recoding our (admittedly old and crusty) build
> environment to Linux with newer tools would just be an unneeded step in
> the path.
>

With all utilities available it shouldn't be hard. Remember, you are not limited to
bare bones Linux. You can request practically any available tool or scripting
language you wish.

> And things like file name differences, etc would have also slowed things
> down to some degree.
>
> As GEM compilers, I have plenty of experience in making non-OpenVMS
> hosted compilers. Our bootstrapping of LLVM/clang from Linux-x86 to
> OpenVMS-x86 involves a clang cross-compiler. Fortunately, since there
> is no Macro, BLISS, SDL, etc in clang/LLVM, I didn't have to invent new
> tooling. However, those cross-builds on Linux have a hybrid set of
> headers since building that cross-compiler needs to know it is hosted on
> Linux (where things like printf is named "printf") but compiling code for
> OpenVMS (where things like printf is not named "printf").
>
> We certainly discussed the initial bootstrapping environment for the
> OS and compilers. The fact that I have a perfectly good set of Macro,
> BLISS, and C compilers that generate code for OpenVMS Itanium as
> well as all the tooling (MESSAGE, CDU, MMS, CMS, DCL, etc.) was the
> better solution.

Yes, a comfort zone.
Is not going to be left voluntarily.
An aging competent engineer has to be dragged out of it.
In skillful manner.

On 10/4/2023 11:29 AM, Michael S wrote:
> On Wednesday, October 4, 2023 at 6:12:14 PM UTC+3, John Reagan wrote:
>> On Wednesday, October 4, 2023 at 10:32:23 AM UTC-4, Michael S wrote:
>>> On Wednesday, October 4, 2023 at 4:55:29 PM UTC+3, bill wrote:
>>>> On 10/4/2023 9:23 AM, Michael S wrote:
>>>>> I'd speculate that it's combination of engineers and management.
>>>>> Engineers are competent, but aging. They have the common tendency
>>>>> of the age - preference to remain in comfort zone.
>>>>> Now, since they *are* competent the *can* be productive outside of
>>>>> their comfort zone, but unlikely to come here on their own. They have
>>>>> to be dragged. By management, who else? And not primitively, primitive
>>>>> dragging would face strong opposition. The have to be dragged in skilful
>>>>> manner.
>>>>>
>>>>> My favorite example is programming tools where, in my opinion, cross-tools
>>>>> hosted on non-VMS x86-64 should have been produced first. After that,
>>>>> x86-64 port could have been productized, even without all native tools ready.
>>>>> They could have come later.
>>>>> Instead of that VMS-Itanium hosted tools were created first, not because it
>>>>> was technically easier, but because in this way old competent engineers didn't
>>>>> have to leave their comfort zone.
>>>>>
>>>> I am a bit confused by the above. Do you mean tools on VMS but
>>>> not on x86 or do you mean tools not on VMS.
>>>>
>>> Tools not on VMS, running on the same x86-64 as VMS or on different
>>> machine. Since VMS has to run in VM, anyway, the machine is always available.
>>> It would have been far easier to host LLVM tools on Linux, where all infrastructure
>>> is available. Less easy on Windows, but even on Windows far easier than on VMS.
>>> And devs (customer's devs) can use source control and other auxiliary tools they
>>> already have and are comfortable with.
>>> Unlike VSI devs, customer's devs are not necessarily first-league engineers; they
>>> should not be dragged out of their comfort zone forcefully by somebody as small
>>> and unimportant as VSI.

>>> And that's one of the reasons why The Port was not officially productized
>>> for so long. Would not be a problem if tools were Linux/Windows based.

>> Could we have produced Linux x86-hosted, OpenVMS x86-targeted tooling?
>>
>> Well that would mean that I would need a Linux x86-hosted/Linux x86-target
>> version of Macro-32 (a large piece of Macro is written in Macro), BLISS-32,
>> BLISS-64, SDL, MESSAGE, CDU, just to build my Linux x86-hosted/OpenVMS
>> targetted compilers. [Yes we had some/many of those in the past, but not
>> a Macro compiler for example].
>>
>
> Linux x86-target does not have to be full-featured. For example, it can be
> transpiler from above-mentioned languages to C or to any other language of
> choice available on Linux, rather than full compiler.
>
>> In addition, the entire OpenVMS build is many layers of DCL command files
>> which use things like CMS. Recoding our (admittedly old and crusty) build
>> environment to Linux with newer tools would just be an unneeded step in
>> the path.
>>
>
> With all utilities available it shouldn't be hard. Remember, you are not limited to
> bare bones Linux. You can request practically any available tool or scripting
> language you wish.
>
>> And things like file name differences, etc would have also slowed things
>> down to some degree.
>>
>> As GEM compilers, I have plenty of experience in making non-OpenVMS
>> hosted compilers. Our bootstrapping of LLVM/clang from Linux-x86 to
>> OpenVMS-x86 involves a clang cross-compiler. Fortunately, since there
>> is no Macro, BLISS, SDL, etc in clang/LLVM, I didn't have to invent new
>> tooling. However, those cross-builds on Linux have a hybrid set of
>> headers since building that cross-compiler needs to know it is hosted on
>> Linux (where things like printf is named "printf") but compiling code for
>> OpenVMS (where things like printf is not named "printf").
>>
>> We certainly discussed the initial bootstrapping environment for the
>> OS and compilers. The fact that I have a perfectly good set of Macro,
>> BLISS, and C compilers that generate code for OpenVMS Itanium as
>> well as all the tooling (MESSAGE, CDU, MMS, CMS, DCL, etc.) was the
>> better solution.
>
> Yes, a comfort zone.
> Is not going to be left voluntarily.
> An aging competent engineer has to be dragged out of it.
> In skillful manner.

I cannot follow you.

The VMS users wanting to move to VMS x86-64 has made a choice
not to migrate to Linux. Whether it is because the prefer VMS
over Linux or it is just too expensive/risky to migrate does not
matter - they want VMS not Linux.

VSI made a choice as well regarding their compilers (which
support a large number of VMS specific extension to the
languages) - they could not afford to create a bunch
of new frontends (VCLANG, VFLANG, VPLANG, VBLANG and
VCBLANG) and instead they would use their existing frontends
with the G2L thingy to translate from GEM to LLVM.

It does not make any sense for VSI to port frontends
that already works on VMS Itanium to Linux when the
strategy is to avoid rewriting the frontends.

It does not make any sense for the VMS users to migrate
all the .COM/.MMS/whatever to .sh/makefile/whatever on
Linux when the strategy is to move to VMS x86-64 not to Linux.

Arne

On 10/4/2023 6:34 PM, Arne Vajhøj wrote:
> On 10/4/2023 11:29 AM, Michael S wrote:
>> On Wednesday, October 4, 2023 at 6:12:14 PM UTC+3, John Reagan wrote:
>>> In addition, the entire OpenVMS build is many layers of DCL command
>>> files
>>> which use things like CMS. Recoding our (admittedly old and crusty)
>>> build
>>> environment to Linux with newer tools would just be an unneeded step in
>>> the path.
>>>
>>
>> With all utilities available it shouldn't be hard.  Remember, you are
>> not limited to
>> bare bones Linux. You can request practically any available tool or
>> scripting
>> language you wish.
>>
>>> And things like file name differences, etc would have also slowed things
>>> down to some degree.
>>>
>>> As GEM compilers, I have plenty of experience in making non-OpenVMS
>>> hosted compilers. Our bootstrapping of LLVM/clang from Linux-x86 to
>>> OpenVMS-x86 involves a clang cross-compiler. Fortunately, since there
>>> is no Macro, BLISS, SDL, etc in clang/LLVM, I didn't have to invent new
>>> tooling. However, those cross-builds on Linux have a hybrid set of
>>> headers since building that cross-compiler needs to know it is hosted on
>>> Linux (where things like printf is named "printf") but compiling code
>>> for
>>> OpenVMS (where things like printf is not named "printf").
>>>
>>> We certainly discussed the initial bootstrapping environment for the
>>> OS and compilers. The fact that I have a perfectly good set of Macro,
>>> BLISS, and C compilers that generate code for OpenVMS Itanium as
>>> well as all the tooling (MESSAGE, CDU, MMS, CMS, DCL, etc.) was the
>>> better solution.
>>
>> Yes, a comfort zone.
>> Is not going to be left voluntarily.
>> An aging competent engineer has to be dragged out of it.
>> In skillful manner.
>
> I cannot follow you.
>
> The VMS users wanting to move to VMS x86-64 has made a choice
> not to migrate to Linux. Whether it is because the prefer VMS
> over Linux or it is just too expensive/risky to migrate does not
> matter - they want VMS not Linux.
>
> VSI made a choice as well regarding their compilers (which
> support a large number of VMS specific extension to the
> languages) - they could not afford to create a bunch
> of new frontends (VCLANG, VFLANG, VPLANG, VBLANG and
> VCBLANG) and instead they would use their existing frontends
> with the G2L thingy to translate from GEM to LLVM.
>
> It does not make any sense  for VSI to port frontends
> that already works on VMS Itanium to Linux  when the
> strategy is to avoid rewriting the frontends.
>
> It does not make any sense for the VMS users to migrate
> all the .COM/.MMS/whatever to .sh/makefile/whatever on
> Linux when the strategy is to move to VMS x86-64 not to Linux.

The VMS Itanium cross compilers could be seen as a problem.

Itanium boxes are pretty rare and there are some VMS customers
that never migrated from Alpha to Itanium.

But the described Linux cross-compiler kludge is not
a viable alternative.

I still think that VSI should have called Dave Turner
and setup a deal where interested customers could buy
an Itanium with a development only license and all
the cross-compilers etc. pre-installed and sold that
for an attractive price (something that would be
peanuts for the customers and still give IslandCo a
profit).

Maybe that could have kicked off some earlier porting
activity.

Or maybe not. There seems to be a lot of VMS developers
that waited for native compilers, because they believe that
is a requirement to consider the platform ready.

Arne

In article <ufjm3i$5nab$2@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-10-03, Arne Vajh�j <arne@vajhoej.dk> wrote:
>> But I find this way more likely:
>> 1) the enthusiasts on c.o.v talked about the hot new
>> blockchain and hashgraph technologies and their
>> potential for VMS
>
>I think you will find people were saying at the time this was
>a waste of time and effort - hindsight was not involved.

Marketing people don't care if a thing is reasonable or possible. Marketing
people only care that someone else thinks that it is reasonable or possible
and that they will buy a product based upon that belief. As long as people
think they need something, they will buy it. This is why there is such a
huge cosmetics industry.

It doesn't matter whether blockchain is a good idea or not, it only matters
that people thought it was a good idea and could be sold to. Unfortunately
the sales people were not fast enough on the ball to sell enough licenses
before people realized it was a stupid idea.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Michael S <already5chosen@yahoo.com> wrote:
>They could have come later.
>Instead of that VMS-Itanium hosted tools were created first, not because it
>was technically easier, but because in this way old competent engineers did=
>n't
>have to leave their comfort zone.

I don't think that's a bad thing. The developers are always going to build
tools for themselves first, then build what others want. Better to lose
a little time that way than lose a lot more time having the developers all
become comfortable with visua... err... become comfortable with remote
development environments.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 10/4/2023 8:40 AM, Simon Clubley wrote:
> On 2023-10-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> Customers were not happy, customers complained, they made one
>> adjustment, customers still complained, they made another
>> adjustment, customers seemed to have stopped complaining,
>> maybe customers are not happy about where it ended but
>> they seem to have accepted it.
>
> Or they silently said "sod this" and moved to another solution.
>
> People have mentioned here in the past that the move to time-limited
> production licences have stopped their move to x86-64 VMS.

I have not heard such since the second adjustment was
announced.

Of course someone could have taken action silent.
But the possibility of silent action is very
speculative.

Arne

On 2023-10-05 00:34, Arne Vajhøj wrote:
> On 10/4/2023 11:29 AM, Michael S wrote:
>> Yes, a comfort zone.
>> Is not going to be left voluntarily.
>> An aging competent engineer has to be dragged out of it.
>> In skillful manner.
>
> I cannot follow you.
>
> The VMS users wanting to move to VMS x86-64 has made a choice
> not to migrate to Linux. Whether it is because the prefer VMS
> over Linux or it is just too expensive/risky to migrate does not
> matter - they want VMS not Linux.
>
> VSI made a choice as well regarding their compilers (which
> support a large number of VMS specific extension to the
> languages) - they could not afford to create a bunch
> of new frontends (VCLANG, VFLANG, VPLANG, VBLANG and
> VCBLANG) and instead they would use their existing frontends
> with the G2L thingy to translate from GEM to LLVM.
>
> It does not make any sense  for VSI to port frontends
> that already works on VMS Itanium to Linux  when the
> strategy is to avoid rewriting the frontends.
>
> It does not make any sense for the VMS users to migrate
> all the .COM/.MMS/whatever to .sh/makefile/whatever on
> Linux when the strategy is to move to VMS x86-64 not to Linux.

I agree. Anyone who thinks it would have been a smarted move to do cross
compilations from Linux is badly mistaken, I would say.

John Reagan gave a good summary of extra work a cross compilation from
Linux would imply, and let's not underestimate the amount of problems
and effort those things would be. It would be an horrendous task. And
once done, you still need to move to native tools at some point, because
customers do not necessarily have, or want Linux systems around.

So it wouldn't have been faster to go for cross compilation from Linux,
and it would not not have made the amount of work less.

The cross compilation people usually do not appreciate the problems you
face as soon as you start dealing with something seriously not Unix-like
in the picture. The problems just keep adding up.

This is one of those choices that VSI made that I completely agree with.
Any other choice would have been close to disaster.

And it's no comfort zone issue in here.

Johnny

On 10/4/2023 8:33 AM, Simon Clubley wrote:
> On 2023-10-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> But I find this way more likely:
>> 1) the enthusiasts on c.o.v talked about the hot new
>> blockchain and hashgraph technologies and their
>> potential for VMS
>
> I think you will find people were saying at the time this was
> a waste of time and effort - hindsight was not involved.
>
> Those people turned out to be right by the way. :-)

That is not what I see.

https://groups.google.com/g/comp.os.vms/c/-h6o6gjIPC4

https://groups.google.com/g/comp.os.vms/c/8Exnyv326vk

https://groups.google.com/g/comp.os.vms/c/u_YQPOKeoCs

https://groups.google.com/g/comp.os.vms/c/q16d8hKfzMY

https://groups.google.com/g/comp.os.vms/c/enauGMde0T4

Lots of interest, lots of questions, some skepticism about specific
usage, some skepticism about priorities but the majority seemed
interested in the technology and nobody said that it was
a stupid idea that VSI should stay away from.

Arne

On 10/4/2023 7:42 PM, Johnny Billquist wrote:
> On 2023-10-05 00:34, Arne Vajhøj wrote:
>> On 10/4/2023 11:29 AM, Michael S wrote:
>>> Yes, a comfort zone.
>>> Is not going to be left voluntarily.
>>> An aging competent engineer has to be dragged out of it.
>>> In skillful manner.
>>
>> I cannot follow you.
>>
>> The VMS users wanting to move to VMS x86-64 has made a choice
>> not to migrate to Linux. Whether it is because the prefer VMS
>> over Linux or it is just too expensive/risky to migrate does not
>> matter - they want VMS not Linux.
>>
>> VSI made a choice as well regarding their compilers (which
>> support a large number of VMS specific extension to the
>> languages) - they could not afford to create a bunch
>> of new frontends (VCLANG, VFLANG, VPLANG, VBLANG and
>> VCBLANG) and instead they would use their existing frontends
>> with the G2L thingy to translate from GEM to LLVM.
>>
>> It does not make any sense  for VSI to port frontends
>> that already works on VMS Itanium to Linux  when the
>> strategy is to avoid rewriting the frontends.
>>
>> It does not make any sense for the VMS users to migrate
>> all the .COM/.MMS/whatever to .sh/makefile/whatever on
>> Linux when the strategy is to move to VMS x86-64 not to Linux.
>
> I agree. Anyone who thinks it would have been a smarted move to do cross
> compilations from Linux is badly mistaken, I would say.
>
> John Reagan gave a good summary of extra work a cross compilation from
> Linux would imply,
I even think he omitted a few complications.

Library utility. VMS compilers support pulling include stuff
from text libraries.

> and let's not underestimate the amount of problems
> and effort those things would be. It would be an horrendous task. And
> once done, you still need to move to native tools at some point, because
> customers do not necessarily have, or want Linux systems around.
>
> So it wouldn't have been faster to go for cross compilation from Linux,
> and it would not not have made the amount of work less.

Yes.

> And it's no comfort zone issue in here.

I am not even sure the underlying premise of being older
implies wanting to stay within comfort zone is correct.

Both old and young often want to stay within their
comfort zone.

It is just that their comfort zone is different.

Wanting to do Cobol and Fortran but not PHP and JavaScript
is wanting to stay in comfort zone.

But wanting to do PHP and JavaScript but not Cobol and
Fortran is also wanting to stay in comfort zone.

Arne

On 2023-10-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> The VMS Itanium cross compilers could be seen as a problem.
>
> Itanium boxes are pretty rare and there are some VMS customers
> that never migrated from Alpha to Itanium.
>

The real problem is that there is no such thing as a full system
emulator that emulates Itanium. If one existed, you would not have
to buy a physical Itanium box to run the cross compilers.

> But the described Linux cross-compiler kludge is not
> a viable alternative.
>
> I still think that VSI should have called Dave Turner
> and setup a deal where interested customers could buy
> an Itanium with a development only license and all
> the cross-compilers etc. pre-installed and sold that
> for an attractive price (something that would be
> peanuts for the customers and still give IslandCo a
> profit).
>
> Maybe that could have kicked off some earlier porting
> activity.
>
> Or maybe not. There seems to be a lot of VMS developers
> that waited for native compilers, because they believe that
> is a requirement to consider the platform ready.
>

So contrary to what you say whenever I say the same thing, you are
now saying there are a lot of other people who feel the same as I do ?

Given the critical nature of typical VMS systems, those people are
absolutely right BTW.

Having said that, they should still be using the current WIP compilers
to do early evaluation/testing of x86-64 VMS if they are thinking of
moving to it.

Simon.

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

On 10/4/2023 8:22 PM, Arne Vajhøj wrote:
>
> I am not even sure the underlying premise of being older
> implies wanting to stay within comfort zone is correct.
>
> Both old and young often want to stay within their
> comfort zone.
>
> It is just that their comfort zone is different.
>
> Wanting to do Cobol and Fortran but not PHP and JavaScript
> is wanting to stay in comfort zone.
>
> But wanting to do PHP and JavaScript but not Cobol and
> Fortran is also wanting to stay in comfort zone.
>

And when the programmer is equally proficient in Fortran, COBOL,
PHP and Javascript is it still a "comfort zone" thing when they
want to do Fortran and COBOL but not PHP and Javascript? Or is
it possibly a serious engineering decision?

bill

On 10/5/2023 9:02 AM, bill wrote:
> On 10/4/2023 8:22 PM, Arne Vajhøj wrote:
>> I am not even sure the underlying premise of being older
>> implies wanting to stay within comfort zone is correct.
>>
>> Both old and young often want to stay within their
>> comfort zone.
>>
>> It is just that their comfort zone is different.
>>
>> Wanting to do Cobol and Fortran but not PHP and JavaScript
>> is wanting to stay in comfort zone.
>>
>> But wanting to do PHP and JavaScript but not Cobol and
>> Fortran is also wanting to stay in comfort zone.
>
> And when the programmer is equally proficient in Fortran, COBOL,
> PHP and Javascript is it still a "comfort zone" thing when they
> want to do Fortran and COBOL but not PHP and Javascript?  Or is
> it possibly a serious engineering decision?

The serious engineering decision will be about matching
the language to the type of application - there is not
that much overlap between those 4 languages in usage -
maybe some PHP vs node.js.

But people obviously have preferences. People have
preferences for cars, burgers, beers etc.
and also for programming languages. Ignoring preferences
for work is one of the things that makes it work.
Being able to only do preferred stuff is the joy
of hobby'ism.

Neither is really about comfort zone. The comfort
zone issue is if someone avoids stuff they are not
familiar with.

Arne

On Friday, September 29, 2023 at 8:38:37 AM UTC-4, Simon Clubley wrote:
> On 2023-09-28, ultr...@gmail.com <ultr...@gmail.com> wrote:
> > On Wednesday, September 27, 2023 at 8:53:13?PM UTC-4, David Turner wrote:
> >> How many people are running X86 variant of OpenVMS in Production?
> >> That is on the virtual machine....
> >> Just want to see when I should retire....
> >> ;0(
> As of today, that number should be zero as x86-64 VMS is nowhere near
> ready for running the mission-critical workloads that VMS is used for.
>
> Due to these workloads, I don't think you can call it ready until at
> least 6-12 months after everything is available to production-quality
> standard and VMS is being built using native compilers/etc.
>
> However, as of today, there should also be a good number of sites
> actively testing it to determine if their applications work ok and
> to find and report any problems back to VSI.
>
> Don't forget there needs to be a business case for spending the money
> to move to x86-64 VMS and a measured assessment of whether the new
> platform at least meets the robustness guarantees that the company's
> current architecture provides.
> >
> > they need to get it running native first before you can determine your retire date
> It is running native. Do you actually mean running on bare metal ?
>
> If so, that's a low priority as the market has very much changed
> in that area.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

no you want bare metal to take advantage of the OpenVMS security advantage ....

what good is it to run on a platform that can still get hijacked with ransomware ...

On 10/5/2023 8:19 AM, Simon Clubley wrote:
> On 2023-10-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> I still think that VSI should have called Dave Turner
>> and setup a deal where interested customers could buy
>> an Itanium with a development only license and all
>> the cross-compilers etc. pre-installed and sold that
>> for an attractive price (something that would be
>> peanuts for the customers and still give IslandCo a
>> profit).
>>
>> Maybe that could have kicked off some earlier porting
>> activity.
>>
>> Or maybe not. There seems to be a lot of VMS developers
>> that waited for native compilers, because they believe that
>> is a requirement to consider the platform ready.
>
> So contrary to what you say whenever I say the same thing, you are
> now saying there are a lot of other people who feel the same as I do ?

????

That people have waited for native compilers to start
their porting work has been stated multiple times - also
by people actually having something to port.

And I have always recognized the need for native compilers.

This is a quote from something I posted January 27th:

<quote>
First we need the native compilers. Cross compilers are
not good enough. VMS tradition, confidence in VMS x86-64
and the problem with relying on a dead platform Itanium
makes native compilers a must.
</quote>

That should be pretty clear.

You are probably confusing the topic of native compilers
for users with VSI using native compilers to build VMS.

The first is a must. How good the reasons really are does
not matter - it is a must have. And luckily we now have
5 out of 6!

The second I don't see a big need for. And that is where
I have disagreed with you. VMS users don't really
care what language VMS is coded in and where it was compiled -
they just want something that works. And generally 9.2-1
works great (*).

Sure building VMS with native compilers may give a little
performance boost, but I don't see that as something causing
anyone to delay their port. It is still fast enough.

*) As I understand it then we really do need a math RTL
build with native compilers, but hopefully VSI can do that
very soon.

Arne

On 2023-10-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> That should be pretty clear.
>
> You are probably confusing the topic of native compilers
> for users with VSI using native compilers to build VMS.
>

Maybe. In which case I apologise.

> The first is a must. How good the reasons really are does
> not matter - it is a must have. And luckily we now have
> 5 out of 6!
>
> The second I don't see a big need for. And that is where
> I have disagreed with you. VMS users don't really
> care what language VMS is coded in and where it was compiled -
> they just want something that works. And generally 9.2-1
> works great (*).
>
> Sure building VMS with native compilers may give a little
> performance boost, but I don't see that as something causing
> anyone to delay their port. It is still fast enough.
>

Performance has nothing to do with it.

When you certify that something is working, and can be used in
production, you generally need to certify that something against
the final configuration, not some work-in-progress intermediate
configuration.

Simon.

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

On 10/6/2023 8:15 AM, Simon Clubley wrote:
> On 2023-10-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> The second I don't see a big need for. And that is where
>> I have disagreed with you. VMS users don't really
>> care what language VMS is coded in and where it was compiled -
>> they just want something that works. And generally 9.2-1
>> works great (*).
>>
>> Sure building VMS with native compilers may give a little
>> performance boost, but I don't see that as something causing
>> anyone to delay their port. It is still fast enough.
>>
>
> Performance has nothing to do with it.
>
> When you certify that something is working, and can be used in
> production, you generally need to certify that something against
> the final configuration, not some work-in-progress intermediate
> configuration.

I agree with the concept. But I am applying it different. :-)

For a given VMS version the compiler moves from work in progress
to final when the VMS version is released.

For VMS as such the compiler is never final and always work in progress.

VMS 9.0 : cross compiler version X-N
....
VMS 9.2 : cross compiler version X
VMS 9.3 : native compiler version Y
....
VMS 9.n : native compiler version Y+1
....
VMS 10.0 : native compiler version Y+M
....
VMS 11.0 : native compiler version Y+P
....

Somebody delivering software for VMS whether internal or external
pick a target VMS version build by some compiler version and a
target compiler version and a target version of various libraries
and develop for that.

After some time they can update target (VMS version and/or
compiler version and/or library versions). Some may update target
after 6 month - some may update after 6 years. In todays world
I think the average time between target updates has decreased
a lot, but everybody is free to make their own decision.

But to me there is no fundamental change for a VMS user to
switch from a VMS version build with "cross compiler version X"
to one build with "native compiler version Y" compared to
switching from a VMS version build with "native compiler version Y"
to one build with "native compiler version Y+M". The change of
VMS version triggers some required actions, but whether VSI
changed compiler for building VMS and whether they changed
build platform for building VMS does not matter.

Arne

On 06/10/2023 01:44, Arne Vajhøj wrote:

<snip>
> First we need the native compilers. Cross compilers are
> not good enough. VMS tradition, confidence in VMS x86-64
> and the problem with relying on a dead platform Itanium
> makes native compilers a must.
<snip>
> The first is a must. How good the reasons really are does
> not matter - it is a must have. And luckily we now have
> 5 out of 6!
>

Presumably you mean C, C++, Cobol, Fortran & Pascal, with Basic outstanding.

What about Python and Java?

and of course LSE

--
Chris

On 10/6/23 12:06 PM, Chris Townley wrote:
> On 06/10/2023 01:44, Arne Vajhøj wrote:
>
> <snip>
>> First we need the native compilers. Cross compilers are
>> not good enough. VMS tradition, confidence in VMS x86-64
>> and the problem with relying on a dead platform Itanium
>> makes native compilers a must.
> <snip>
>> The first is a must. How good the reasons really are does
>> not matter - it is a must have. And luckily we now have
>> 5 out of 6!
>>
>
> Presumably you mean C, C++, Cobol, Fortran & Pascal, with Basic
> outstanding.
>
> What about Python and Java?

Java is available on x86, not sure about Python.

> and of course LSE

DECSET has been available for a year and a half at least.

On 10/6/2023 1:06 PM, Chris Townley wrote:
> On 06/10/2023 01:44, Arne Vajhøj wrote:
>> First we need the native compilers. Cross compilers are
>> not good enough. VMS tradition, confidence in VMS x86-64
>> and the problem with relying on a dead platform Itanium
>> makes native compilers a must.
> <snip>
>> The first is a must. How good the reasons really are does
>> not matter - it is a must have. And luckily we now have
>> 5 out of 6!
>
> Presumably you mean C, C++, Cobol, Fortran & Pascal, with Basic
> outstanding.

Yes.

> What about Python and Java?

The 5 out of 6 was just the traditional source to exe compilers.

For Python, Java, PHP and Perl I think we have 3 out of 4.
Python is missing.

> and of course LSE

If we go beyond languages then there are more stuff we are waiting for.

Rdb probably the biggest.

I would not worry about LSE. VSI is supposedly already using
LSE internally, so it will show up.

Arne

On 10/6/2023 2:12 PM, Craig A. Berry wrote:
> On 10/6/23 12:06 PM, Chris Townley wrote:
>> and of course LSE
>
> DECSET has been available for a year and a half at least.

LSE was reported missing in DECset on x86-64.

It should be on its way.

https://forum.vmssoftware.com/viewtopic.php?f=37&t=8806

Arne

On 06/10/2023 19:12, Craig A. Berry wrote:
> On 10/6/23 12:06 PM, Chris Townley wrote:
>> On 06/10/2023 01:44, Arne Vajhøj wrote:
>>
>> <snip>
>>> First we need the native compilers. Cross compilers are
>>> not good enough. VMS tradition, confidence in VMS x86-64
>>> and the problem with relying on a dead platform Itanium
>>> makes native compilers a must.
>> <snip>
>>> The first is a must. How good the reasons really are does
>>> not matter - it is a must have. And luckily we now have
>>> 5 out of 6!
>>>
>>
>> Presumably you mean C, C++, Cobol, Fortran & Pascal, with Basic
>> outstanding.
>>
>> What about Python and Java?
>
> Java is available on x86, not sure about Python.
>
>> and of course LSE
>
> DECSET has been available for a year and a half at least.

But that excluded LSE

--
Chris

On 10/6/23 1:39 PM, Chris Townley wrote:
> On 06/10/2023 19:12, Craig A. Berry wrote:
>> On 10/6/23 12:06 PM, Chris Townley wrote:
>>> On 06/10/2023 01:44, Arne Vajhøj wrote:
>>>
>>> <snip>
>>>> First we need the native compilers. Cross compilers are
>>>> not good enough. VMS tradition, confidence in VMS x86-64
>>>> and the problem with relying on a dead platform Itanium
>>>> makes native compilers a must.
>>> <snip>
>>>> The first is a must. How good the reasons really are does
>>>> not matter - it is a must have. And luckily we now have
>>>> 5 out of 6!
>>>>
>>>
>>> Presumably you mean C, C++, Cobol, Fortran & Pascal, with Basic
>>> outstanding.
>>>
>>> What about Python and Java?
>>
>> Java is available on x86, not sure about Python.
>>
>>> and of course LSE
>>
>> DECSET has been available for a year and a half at least.
>
> But that excluded LSE

Ah, sorry. I forgot about that. I'm pretty sure the VMS IDE for VSCode
is available for anyone interested in doing old things in a new way.

On 10/6/2023 2:39 PM, Chris Townley wrote:
> On 06/10/2023 19:12, Craig A. Berry wrote:
>> On 10/6/23 12:06 PM, Chris Townley wrote:
>>> On 06/10/2023 01:44, Arne Vajhøj wrote:
>>>
>>> <snip>
>>>> First we need the native compilers. Cross compilers are
>>>> not good enough. VMS tradition, confidence in VMS x86-64
>>>> and the problem with relying on a dead platform Itanium
>>>> makes native compilers a must.
>>> <snip>
>>>> The first is a must. How good the reasons really are does
>>>> not matter - it is a must have. And luckily we now have
>>>> 5 out of 6!
>>>>
>>>
>>> Presumably you mean C, C++, Cobol, Fortran & Pascal, with Basic outstanding.
>>>
>>> What about Python and Java?
>>
>> Java is available on x86, not sure about Python.
>>
>>> and of course LSE
>>
>> DECSET has been available for a year and a half at least.
>
> But that excluded LSE
>

Don't really know, but, doesn't LSE depend upon the compilers?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486