Rdb/x86

Post by Jan-Erik SÃ¶derholm
From tadays presentation from France by Kevin Duffy from Oracle.
Oracle Rdb x86 Port.
* Rdb 7.4 environment established.
* Rdb 7.4 x86 changes needed for test system underway.
* Running 9.0 on multiple system.
* Cross compilations completed or underway
** COSI
** KODA
** SQL
* Next cross compilations
** RMU, SQLMOD, SQLPRE with goal of getting the monitor running.
* Have been working on SORT in preparation for the port.
http://youtu.be/mWfpPzGbPr4

Which is pretty good news.

Sounds like they are full speed ahead with the x86-64 port.

Arne

Dave Froble

2020-11-12 16:18:28 UTC

Oh, No, what does this mean to all those bemoaning the lack of Rdb on
x86 VMS? What will they have to obsess over now? Their whole reason
for being has been destroyed. Woe is them ....

:-)

Myself, never had any doubts ....

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

Simon Clubley

2020-11-12 18:22:28 UTC

Post by Dave Froble
Oh, No, what does this mean to all those bemoaning the lack of Rdb on
x86 VMS? What will they have to obsess over now? Their whole reason
for being has been destroyed. Woe is them ....

How about the fact that VSI marketing is hopeless and that this should
have been a public announcement from _VSI_ way before now ?

Jan-Erik should not have been the one who needed to reveal this.

I've just checked VSI's website - there's nothing there that I can see
and this is _major_ and _very_ good news for VMS on x86-64.

My previous position is unchanged. VSI marketing should be building
up excitement about VMS on x86-64 via an ongoing stream of public
announcements, including reporting on developments from their partners.

The goal should be obvious: to construct an image of VMS becoming
active again after all this time.

Oh, and thanks to Jan-Erik for posting this information.

Simon.

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

Jan-Erik Söderholm

2020-11-12 23:35:00 UTC

How about the fact that VSI marketing is hopeless and that this should
have been a public announcement from _VSI_ way before now ?

Right. After the Youtube recording was closed down, the Zoom conference
was kept alive. And there was a sometimes a bit infected discussion about
the (lack of) VSI "marketing". In particular one guy, who has been involved
in Ada work in France that I think you know, raised his voice.

But then, VSI, as a partner to Oracle, can't officially announce anything
that Oracle does not agree to. The news must come from Oracle, as I see it.
So it is not only VSI that should be blamed here…

Post by Simon Clubley
Jan-Erik should not have been the one who needed to reveal this.

Actually, in the Youtube recording, at the and when the official conference
had ended, I think I heard my name as one that was still online after the
official end... At 2:55:00 I think I can hear my name, "Jean-Eric" as it
is usually pronounced in French, I'm used to that after 5 years in Tunisia.
:-)

And besides, I was not the one who revealed it. It was Kevin Duffy,
director at Oracle for all products for OpenVMS. And it was revealed
to everyone taking part of the presentation.

Post by Simon Clubley
I've just checked VSI's website - there's nothing there that I can see
and this is _major_ and _very_ good news for VMS on x86-64.

Right, and I think that was commented on also.

Post by Simon Clubley
My previous position is unchanged. VSI marketing should be building
up excitement about VMS on x86-64 via an ongoing stream of public
announcements, including reporting on developments from their partners.

You are somewhat kicking in open doors. There was a fair amount of
criticism against VSI for the lack of marketing. Most of it was efter
the Youtube recording had been closed down...

Post by Simon Clubley
The goal should be obvious: to construct an image of VMS becoming
active again after all this time.
Oh, and thanks to Jan-Erik for posting this information.

Thanks!
Having worked professionaly and constantly with Rdb since 25+ years,
I have no problem taking the time to post some news now and then. :-)

Post by Simon Clubley
Simon.

Simon Clubley

2020-11-13 13:18:57 UTC

Post by Simon Clubley
I've just checked VSI's website - there's nothing there that I can see
and this is _major_ and _very_ good news for VMS on x86-64.

Right, and I think that was commented on also.

It's now the next day and still nothing on the VSI website that I can see.

This is absolutely massive and excellent news for the future of VMS
and by now every customer that VSI has the contact details for should
have been told about it, especially the non-Rdb users. :-(

This would send a major signal because VSI have managed to get _Oracle_
to commit to Rdb on x86-64 and it would be a major confidence boost that
x86-64 VMS is less likely to suddenly fail at the last moment.

I hope any VSI employees reading this tell VSI marketing to get their
act together _today_ (literally) and get this news out to everyone.

This is really good news for building confidence in the future of VMS,
but only if everyone knows about it.

Simon.

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

Jan-Erik Söderholm

2020-11-13 14:01:24 UTC

Post by Simon Clubley
I've just checked VSI's website - there's nothing there that I can see
and this is _major_ and _very_ good news for VMS on x86-64.

Right, and I think that was commented on also.

It's now the next day and still nothing on the VSI website that I can see.
This is absolutely massive and excellent news for the future of VMS
and by now every customer that VSI has the contact details for should
have been told about it, especially the non-Rdb users. :-(
This would send a major signal because VSI have managed to get _Oracle_
to commit to Rdb on x86-64 and it would be a major confidence boost that
x86-64 VMS is less likely to suddenly fail at the last moment.
I hope any VSI employees reading this tell VSI marketing to get their
act together _today_ (literally) and get this news out to everyone.
This is really good news for building confidence in the future of VMS,
but only if everyone knows about it.
Simon.

Cool down...

What Kevin Duffy presented is probably what everyone already expected.
It is not a major surprice that Oracle are looking at Rdb/x86.
It would have been if they were *not* looking at Rdb/x86.

And besides, "next day" after what? How do you know that a large part
of the VMS customers doesn't already knew this? How do you know that
this hasn't been presented in other events before? Just the fact that
something isn't mentioned on c.o.v does not mean that it doesn't exist...
And who are those "everyone" you speak for?

So, cool down...

Anyway, I have just registered to an online event where Kevin Duffy will
have a 30 min update on "Oracle and VMS". Aranged by HP-Connect Sweden.
I expect the same information.

Phillip Helbig (undress to reply)

2020-11-13 16:01:09 UTC

Post by Jan-Erik SÃ¶derholm
Cool down...

Indeed.

Post by Jan-Erik SÃ¶derholm
What Kevin Duffy presented is probably what everyone already expected.
It is not a major surprice that Oracle are looking at Rdb/x86.
It would have been if they were *not* looking at Rdb/x86.

If Jan-Erik and I agree, then we must be right. :-)

Simon Clubley

2020-11-13 19:23:11 UTC

Post by Jan-Erik SÃ¶derholm
Cool down...

Indeed.

If Jan-Erik and I agree, then we must be right. :-)

Or you are both equally not seeing the bigger picture.

Simon.

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

Simon Clubley

2020-11-13 19:22:35 UTC

Post by Simon Clubley
I've just checked VSI's website - there's nothing there that I can see
and this is _major_ and _very_ good news for VMS on x86-64.

Right, and I think that was commented on also.

It's now the next day and still nothing on the VSI website that I can see.
This is absolutely massive and excellent news for the future of VMS
and by now every customer that VSI has the contact details for should
have been told about it, especially the non-Rdb users. :-(
This would send a major signal because VSI have managed to get _Oracle_
to commit to Rdb on x86-64 and it would be a major confidence boost that
x86-64 VMS is less likely to suddenly fail at the last moment.
I hope any VSI employees reading this tell VSI marketing to get their
act together _today_ (literally) and get this news out to everyone.
This is really good news for building confidence in the future of VMS,
but only if everyone knows about it.
Simon.

Oracle just dropped "Oracle Classic" on VMS.

Expected (also known as "hoping") is not the same thing as knowing.

Post by Jan-Erik SÃ¶derholm
And besides, "next day" after what? How do you know that a large part
of the VMS customers doesn't already knew this? How do you know that
this hasn't been presented in other events before? Just the fact that
something isn't mentioned on c.o.v does not mean that it doesn't exist...
And who are those "everyone" you speak for?

The next day after this is known to the VMS community at large.

When this was being discussed recently no-one could even confirm that
Rdb was being ported to x86-64 and we didn't know if it was going to
go the way of Oracle Classic.

Many people around here would make excellent VSI marketing employees.
That is not a good thing BTW.

The reason why people are commenting about (the lack of) VSI marketing
is because I suspect they can see the same bigger picture that I can.

After years of broken promises about when x86-64 VMS would become
available, big things are finally starting to happen in the x86-64 VMS
world, and VSI should be shouting that out loud to anyone who will
listen.

VSI should be actively continuing to keep the idea of VMS as a still
viable choice in the minds of people and when something like this comes
along which shows that, after years of broken promises, x86-64 VMS is
_finally_ almost here, VSI should be telling everyone about it as soon
as they are allowed to (which at the latest is when Oracle did their
first public presentation on it).

This is excellent news for VMS and any other company would be massively
promoting the hell out of it and generally building up an atmosphere
of excitement towards the upcoming release of x86-64 VMS.

Even HP (at least back in the days of Sue) did a better job of this
than VSI marketing are doing. Who knows, once they have got around to
doing normal marketing, perhaps VSI could even start creating promotional
materials like Sue did that could be on display in your workplaces and
hence start discussions about VMS and keep it in the minds of people. :-)

Simon.

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

Jan-Erik Söderholm

2020-11-13 23:10:42 UTC

Post by Simon Clubley
I've just checked VSI's website - there's nothing there that I can see
and this is _major_ and _very_ good news for VMS on x86-64.

Right, and I think that was commented on also.

It's now the next day and still nothing on the VSI website that I can see.
This is absolutely massive and excellent news for the future of VMS
and by now every customer that VSI has the contact details for should
have been told about it, especially the non-Rdb users. :-(
This would send a major signal because VSI have managed to get _Oracle_
to commit to Rdb on x86-64 and it would be a major confidence boost that
x86-64 VMS is less likely to suddenly fail at the last moment.
I hope any VSI employees reading this tell VSI marketing to get their
act together _today_ (literally) and get this news out to everyone.
This is really good news for building confidence in the future of VMS,
but only if everyone knows about it.
Simon.

Oracle just dropped "Oracle Classic" on VMS.
Expected (also known as "hoping") is not the same thing as knowing.

The next day after this is known to the VMS community at large.

Why do you think that is the same as c.o.v?

Post by Simon Clubley
When this was being discussed recently no-one could even confirm that
Rdb was being ported to x86-64 and we didn't know if it was going to
go the way of Oracle Classic.

I can't speak for anyone but myself, but I hadn't asked Oracle.

Can't bother to read the rest.

IanD

2020-11-14 09:52:36 UTC

Well this is good news

I've worked with rdb for just over 20 years and I thought after Oracle ended Oracle real on VMS I figured rdb would meet the same fate

Somewhat disappointing the news wasn't via Oracle or vsi as an announcement, even chatter to say it's being worked on as an investigative endeavor

So vsi had no idea Oracle was working on rdb x86? Oracle never had a complier problem or issue getting rdb running?

What else might be being worked on that would be good for VMS users out there to know?

Phillip Helbig (undress to reply)

2020-11-14 11:50:31 UTC

Post by IanD
I've worked with rdb for just over 20 years and I thought after Oracle
ended Oracle real on VMS I figured rdb would meet the same fate

Rdb started at DEC. It was bought by Oracle via the argument that if it
stayed with DEC, then Oracle wouldn't offer Oracle "Classic" on VMS.
But development continued with pretty much the same people in the same
places. Rdb is a very small part of Oracle. Does Larry know about it?
Almost certainly. Does he know the syntax of RMU/UNLOAD? Probably not.

Post by IanD
Somewhat disappointing the news wasn't via Oracle or vsi as an
announcement, even chatter to say it's being worked on as an
investigative endeavor

This is OLD NEWS. The Rdb folks have said all along that if VMS runs on
x86 then so will Rdb. As an Oracle product, VSI couldn't announce it by
themselves. As for Oracle, again, it is a small part of the enterprise.

Post by IanD
So vsi had no idea Oracle was working on rdb x86?

Of course they did.

Post by IanD
Oracle never had a complier problem or issue getting rdb running?

The port can't have been that difficult, considering that this is the
fourth port (yes, there was Rdb for WNT).

Post by IanD
What else might be being worked on that would be good for VMS users out there to know?

Soon we'll hear about the web browser being developed by the skunk
works. :-)

IanD

2020-11-23 22:55:29 UTC

Post by IanD
I've worked with rdb for just over 20 years and I thought after Oracle
ended Oracle real on VMS I figured rdb would meet the same fate

Post by IanD
Somewhat disappointing the news wasn't via Oracle or vsi as an
announcement, even chatter to say it's being worked on as an
investigative endeavor

Post by IanD
So vsi had no idea Oracle was working on rdb x86?

Of course they did.

Post by IanD
Oracle never had a complier problem or issue getting rdb running?

The port can't have been that difficult, considering that this is the
fourth port (yes, there was Rdb for WNT).

Post by IanD
What else might be being worked on that would be good for VMS users out there to know?

Soon we'll hear about the web browser being developed by the skunk
works. :-)

I was making the point that if all these things were known then vsi could have been promoting this sort of stuff, even if unofficially

For example, look at how many people here, who are vms advocates and keep fairly well in the know about what's happening on vms, didn't really know the state of play with rdb on x86...

It's all fine to say 'of course' but assumptions don't make for sales or keep vms customers who are on fringe systems eyeing the door and potentially leaving

Risk drives everything and if the marketing arm of vsi is not getting the word out on every success and even potential success, then businesses will keep shedding vms to mitigate the risk that they are running on a dead platform

I've worked in at least 2 places now where vms has been marched out the door.
One place might have even kept vms but it was too late, by the time I heard of their plans and created a simple web interface to their existing rdb platform to show what could be done, their decision to retire vms had already been concluded at the board level and funding approved for the replacement system

By the time the technical people hear of platform decisions, other marketing departments have already got in and sold the business their solutions

Lead times of 12++ months is typical in large companies for platform decisions, so throwing information into the public arena late is potentially letting your competitors have a head start and they are already out there pushing their glossy brochures and vaporware to lock in future sales

I happen to think vsi could have said a lot more about rdb on x86 because from my perspective they actually didn't say anything at all

Simon Clubley

2020-11-24 13:17:04 UTC

Post by IanD
I was making the point that if all these things were known then vsi could have been promoting this sort of stuff, even if unofficially
For example, look at how many people here, who are vms advocates and keep fairly well in the know about what's happening on vms, didn't really know the state of play with rdb on x86...
It's all fine to say 'of course' but assumptions don't make for sales or keep vms customers who are on fringe systems eyeing the door and potentially leaving
Risk drives everything and if the marketing arm of vsi is not getting the word out on every success and even potential success, then businesses will keep shedding vms to mitigate the risk that they are running on a dead platform
I've worked in at least 2 places now where vms has been marched out the door.
One place might have even kept vms but it was too late, by the time I heard of their plans and created a simple web interface to their existing rdb platform to show what could be done, their decision to retire vms had already been concluded at the board level and funding approved for the replacement system
By the time the technical people hear of platform decisions, other marketing departments have already got in and sold the business their solutions
Lead times of 12++ months is typical in large companies for platform decisions, so throwing information into the public arena late is potentially letting your competitors have a head start and they are already out there pushing their glossy brochures and vaporware to lock in future sales
I happen to think vsi could have said a lot more about rdb on x86 because from my perspective they actually didn't say anything at all

I have included Ian's comment in full as it deserves a second read as
Ian very clearly "gets it".

The above is a good example of exactly why VSI should be promoting,
in public, the fact that Rdb is now known to be actively being ported
to x86-64 VMS.

I've just checked the VSI website again and there's _still_ nothing
I can see in the news section about Rdb on x86-64 VMS.

Absolutely bloody pathetic. :-(

Simon.

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

Arne Vajhøj

2020-11-24 14:00:29 UTC

Post by IanD
I was making the point that if all these things were known then vsi
could have been promoting this sort of stuff, even if unofficially
For example, look at how many people here, who are vms advocates
and keep fairly well in the know about what's happening on vms,
didn't really know the state of play with rdb on x86...
It's all fine to say 'of course' but assumptions don't make for
sales or keep vms customers who are on fringe systems eyeing the
door and potentially leaving
Risk drives everything and if the marketing arm of vsi is not
getting the word out on every success and even potential success,
then businesses will keep shedding vms to mitigate the risk that
they are running on a dead platform
I've worked in at least 2 places now where vms has been marched out
the door. One place might have even kept vms but it was too late,
by the time I heard of their plans and created a simple web
interface to their existing rdb platform to show what could be
done, their decision to retire vms had already been concluded at
the board level and funding approved for the replacement system
By the time the technical people hear of platform decisions, other
marketing departments have already got in and sold the business
their solutions
Lead times of 12++ months is typical in large companies for
platform decisions, so throwing information into the public arena
late is potentially letting your competitors have a head start and
they are already out there pushing their glossy brochures and
vaporware to lock in future sales
I happen to think vsi could have said a lot more about rdb on x86
because from my perspective they actually didn't say anything at
all

I have included Ian's comment in full as it deserves a second read
as Ian very clearly "gets it".
The above is a good example of exactly why VSI should be promoting,
in public, the fact that Rdb is now known to be actively being
ported to x86-64 VMS.
I've just checked the VSI website again and there's _still_ nothing I
can see in the news section about Rdb on x86-64 VMS.
Absolutely bloody pathetic. :-(

But what exactly do you want VSI to say?

"VSI promise that Rdb will be available on VMS x86-64"

then VSI would have a serious problem if Oracle changed their mind
and Oracle may get pretty pissed at VSI.

"Oracle promise that Rdb will be available on VMS x86-64"

Unless Oracle senior management has officially committed then
same issues as above.

"We hear that some smart guys over at Oracle is working on Rdb
VMS x86-64"

And leave it to readers to make their own conclusions.

That could easily sound rather un-enthusiastic.

"We just has a meeting with Oracle and the future
looks bright - see link here ..."

Maybe that would work.

But finding a message that is both without legal/business risk
and enthusiastic is not trivial (unless Oracke has officially
announced).

Arne

Jan-Erik Söderholm

2020-11-24 14:35:47 UTC

Post by IanD
I was making the point that if all these things were known then vsi
could have been promoting this sort of stuff, even if unofficially
For example, look at how many people here, who are vms advocates
and keep fairly well in the know about what's happening on vms,
didn't really know the state of play with rdb on x86...
It's all fine to say 'of course' but assumptions don't make for
sales or keep vms customers who are on fringe systems eyeing the
door and potentially leaving
Risk drives everything and if the marketing arm of vsi is not
getting the word out on every success and even potential success,
then businesses will keep shedding vms to mitigate the risk that
they are running on a dead platform
I've worked in at least 2 places now where vms has been marched out
the door. One place might have even kept vms but it was too late,
by the time I heard of their plans and created a simple web
interface to their existing rdb platform to show what could be
done, their decision to retire vms had already been concluded at
the board level and funding approved for the replacement system
By the time the technical people hear of platform decisions, other
marketing departments have already got in and sold the business
their solutions
Lead times of 12++ months is typical in large companies for
platform decisions, so throwing information into the public arena
late is potentially letting your competitors have a head start and
they are already out there pushing their glossy brochures and
vaporware to lock in future sales
I happen to think vsi could have said a lot more about rdb on x86
because from my perspective they actually didn't say anything at
all

I have included Ian's comment in full as it deserves a second read
as Ian very clearly "gets it".
The above is a good example of exactly why VSI should be promoting, in
public, the fact that Rdb is now known to be actively being
ported to x86-64 VMS.
I've just checked the VSI website again and there's _still_ nothing I
can see in the news section about Rdb on x86-64 VMS.
Absolutely bloody pathetic. :-(

But what exactly do you want VSI to say?
"VSI promise that Rdb will be available on VMS x86-64"
then VSI would have a serious problem if Oracle changed their mind
and Oracle may get pretty pissed at VSI.
"Oracle promise that Rdb will be available on VMS x86-64"
Unless Oracle senior management has officially committed then
same issues as above.
"We hear that some smart guys over at Oracle is working on Rdb
VMS x86-64"
And leave it to readers to make their own conclusions.
That could easily sound rather un-enthusiastic.
"We just has a meeting with Oracle and the future
looks bright - see link here ..."
Maybe that would work.
But finding a message that is both without legal/business risk
and enthusiastic is not trivial (unless Oracke has officially
announced).
Arne

Those that very much depending on Rdb has probably already
checked this with Oracle. Those a bit smaller might plan to
stay on Alpha or IA64.

Most probaby just thought that it would had been highly surprising
of Oracle was *not* looking at, and/or working on, Rdb/x86. It would
had been surprising of VSI hadn't talked to Oracle *before* the
x86 port even begun...

And, if someone would say anything about this, it would be Oracle,
and they have done so in their regular presentations this fall.
And I'd call that "offical", there was no NDA involved or such.

If anything is pathetic here, it is Simons continued bashing on VSI.

Simon Clubley

2020-11-24 18:19:25 UTC

Post by Jan-Erik SÃ¶derholm
And, if someone would say anything about this, it would be Oracle,
and they have done so in their regular presentations this fall.
And I'd call that "offical", there was no NDA involved or such.

And VSI should be telling _everyone_ about it as proof that things
in the x86-64 VMS world are finally happening and that important vendors
(in this case Oracle) are committing to x86-64 VMS, hence helping to
keep the platform viable for everyone, including those who do not use Rdb.

Everyone here is very technically knowledgeable but sometimes many of
you have a really big problem with seeing the larger non-technical
picture.

Go and re-read Ian's posting again. That sums up the non-technical
bigger picture far better than I can.

The technical stuff doesn't matter if lack of exposure means that
people think the future of VMS is not viable because VSI are not
hammering home all the things that are happening in the x86-64 VMS world.

Post by Jan-Erik SÃ¶derholm
If anything is pathetic here, it is Simons continued bashing on VSI.

Remind me Jan-Erik, am I the only one complaining about VSI marketing ?

Simon.

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

Phillip Helbig (undress to reply)

2020-11-24 15:19:05 UTC

Post by Jan-Erik SÃ¶derholm
Those that very much depending on Rdb has probably already
checked this with Oracle. Those a bit smaller might plan to
stay on Alpha or IA64.
Most probaby just thought that it would had been highly surprising
of Oracle was *not* looking at, and/or working on, Rdb/x86. It would
had been surprising of VSI hadn't talked to Oracle *before* the
x86 port even begun...

Exactly.

:-|

Simon Clubley

2020-11-24 18:30:06 UTC

Post by Arne VajhÃ¸j
But what exactly do you want VSI to say?

I want VSI to tell _everyone_ about the latest Oracle briefing on
Rdb for x86-64 VMS and to sell it as proof that major things are
finally happening in the x86-64 VMS world and that important
vendors are committing to x86-64 VMS and hence helping to keep the
platform viable for everyone, even for those who do not use the
vendor's products.

Even HP/HPE was better than this in times gone past. Remember the
disaster-proof video from a decade ago ? How much exposure do you
think that one video gave to VMS for the following few years ?

I'm not asking VSI to blow something up. All I want them to do is
some proper marketing which would be a major improvement over the
current situation.

Simon.

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

Arne Vajhøj

2020-11-24 18:54:00 UTC

Post by Arne VajhÃ¸j
But what exactly do you want VSI to say?

But as I trised to explain then VSI cannot commit on
behalf of Oracle.

Post by Simon Clubley
Even HP/HPE was better than this in times gone past. Remember the
disaster-proof video from a decade ago ? How much exposure do you
think that one video gave to VMS for the following few years ?
I'm not asking VSI to blow something up. All I want them to do is
some proper marketing which would be a major improvement over the
current situation.

They can always publish some CVE count comparisons.

:-)

Arne

Dave Froble

2020-11-24 19:16:29 UTC

Post by Arne VajhÃ¸j
But what exactly do you want VSI to say?

But as I trised to explain then VSI cannot commit on
behalf of Oracle.

If any vendor says something public about their product, then interested
parties can surely point people to that information.

I'm not taking any sides here. I don't know what VSI "knows".

From what I've seen, VSI should be able to "mention" what Oracle has
said publicly, even if it was only to their customers. But consider,
perhaps Oracle has asked VSI to not do so. Don't ask me why. I haven't
a clue. But it is a possibility.

It is my impression that VSI just might not have a huge marketing budget
at this time.

As I may have mentioned in the past, anyone that could easily get off
VMS has most likely already done so. Thus, perhaps VSI looks at the
current user base as their primary customers, and doesn't seem to need
to inform them, as most already keep themselves informed.

I'm not saying I agree with such a decision, if indeed that is anyway an
accurate read of the situation.

It's VSI's problem, and they might know what they are doing. I will
only comment that it's not 1980, and perhaps marketing requirements just
might be different today.

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

Arne Vajhøj

2020-11-24 19:44:55 UTC

Post by Arne VajhÃ¸j
But what exactly do you want VSI to say?

But as I trised to explain then VSI cannot commit on
behalf of Oracle.

If any vendor says something public about their product, then interested
parties can surely point people to that information.

If Oracle put something official about the port on their Rdb section
on their web then linking to that would be obvious.

Post by Dave Froble
From what I've seen, VSI should be able to "mention" what Oracle has
said publicly, even if it was only to their customers. But consider,
perhaps Oracle has asked VSI to not do so. Don't ask me why. I haven't
a clue. But it is a possibility.
It is my impression that VSI just might not have a huge marketing budget
at this time.

Putting something on VSI web and sending a note
to a few IT news web sites is not going to cost much.

Arne

Simon Clubley

2020-11-25 13:23:23 UTC

Post by Arne VajhÃ¸j
They can always publish some CVE count comparisons.
:-)

Don't go there Arne. :-) Seriously, don't go there. :-)

Simon.

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

Phillip Helbig (undress to reply)

2020-11-25 07:51:53 UTC

Post by Arne VajhÃ¸j
But what exactly do you want VSI to say?

Why should someone who is interested in other products care about Rdb?
A commitment to Rdb does not imply a commitment to a web browser, for
example. :-) And those interested in Rdb have known it for years.

How many sales were the result of that video?

Simon Clubley

2020-11-25 14:01:47 UTC

Post by Arne VajhÃ¸j
But what exactly do you want VSI to say?

Why should someone who is interested in other products care about Rdb?

Seriously Phillip ? You really need this explained to you ? Ok, here goes:

No manager is going to invest in a move to a platform that they think is
dead or may shortly become dead. They have their company pension and
not getting a P45/pink slip as a result of that decision to think about.

Alpha is dead.

Itanium will shortly be dead.

The port of VMS to x86-64 has been going on for 6 years and has not
yet delivered anything a customer can use in production.

Even when VMS on x86-64 becomes available, no manager is going to invest
in a move to that platform (see above about company pension/P45) unless
they think it has a viable long-term future.

As part of that decision, they will want to see that x86-64 VMS has,
or will shortly have, a critical mass of other people using the same
platform in order to make that platform viable. To that manager, it
doesn't matter what products those other people are using; it only
matters that enough people are going to be using VMS on x86-64 to make
it a relatively safe decision for that manager to also take.

By that measure, Oracle formally announcing that they are porting Rdb
to x86-64 VMS is a major sign of commitment to x86-64 VMS and a major
confidence boost that x86-64 VMS may end up with enough users to make
it a long-term viable platform.

This only helps however if those other managers know about this and if
those same managers see a stream of _public_ activity from VSI marketing
about all the other products and users coming to x86-64 VMS which helps
to increase confidence that VMS on x86-64 is a reasonable option for
that manager's organisation to be using.

In the absence of a usable VMS on x86-64, that public activity also helps
to allow the manager to make decisions that keep future options open,
including a possible move to x86-64 VMS, instead of them making a decision
_now_ to move away from VMS.

This is why it's so damned important to tell _everyone_ about Rdb on
x86-64 VMS now that Oracle have formally announced their plans.

A few people around here clearly understand this. Surely, the rest of
you can see this as well ?

Post by Phillip Helbig (undress to reply)
A commitment to Rdb does not imply a commitment to a web browser, for
example. :-) And those interested in Rdb have known it for years.

How many sales were the result of that video?

Wrong question. The correct question is how many people were able to
continue using VMS within their organisation because they and their
managers saw HP treating VMS as an actively supported product ?

Simon.

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

Phillip Helbig (undress to reply)

2020-11-25 14:54:42 UTC

Post by Simon Clubley
As part of that decision, they will want to see that x86-64 VMS has,
or will shortly have, a critical mass of other people using the same
platform in order to make that platform viable. To that manager, it
doesn't matter what products those other people are using; it only
matters that enough people are going to be using VMS on x86-64 to make
it a relatively safe decision for that manager to also take.

The announcement that Rdb is available for x86-VMS tells the manager
nothing about whether enough people will be using VMS on x86-64 to make
it a relatively safe decision for that manager to also take.

How many customers can Oracle keep by porting to x86? How much did the
port cost? Do the benefits outweigh the costs? Probably, since
othewise they wouldn't have done it. But, for example, say that enough
customers are kept that Oracle's revenue is 1 million higher than it
otherwise would have been, and that that covered the cost. That might
mean just a few customers---enough for it to be worth it for Oracle, but
perhaps not enough to mean that VMS on x86 is viable.

Post by Simon Clubley
By that measure, Oracle formally announcing that they are porting Rdb
to x86-64 VMS is a major sign of commitment to x86-64 VMS and a major
confidence boost that x86-64 VMS may end up with enough users to make
it a long-term viable platform.
This only helps however if those other managers know about this and if
those same managers see a stream of _public_ activity from VSI marketing
about all the other products and users coming to x86-64 VMS which helps
to increase confidence that VMS on x86-64 is a reasonable option for
that manager's organisation to be using.

Any manager who would base his decision on whether Rdb was on x86 VMS
already knows that Rdb will run on x86 VMS.

Post by Phillip Helbig (undress to reply)
How many sales were the result of that video?

OK, let's see it that way. My guess is that a large fraction of paying
VMS customers use Rdb, but those already know it, so the question is
whether the non-Rdb customers will be convinced to stay on VMS because
Rdb is running on VMS. But, as mentioned above, that tells them only
that the port was worth it for Oracle, not whether a critical mass has
been achieved.

Simon Clubley

2020-11-25 18:35:43 UTC

You _still_ don't get it Phillip.

It tells the manager that a major vendor has committed to x86-64 VMS
and that in itself helps give a increased level of confidence. Unlike you,
the people making these decisions are not VMS zealots. They want to make
a safe decision that's less likely to cost them their company pension or
end up giving them a nice free pink slip or P45.

A Rdb announcement should have been a major announcement in what should
have been an ongoing stream of announcements by VSI marketing, all of
which had the combined purpose of projecting a positive, and viable,
long-term future for x86-64 VMS.

There's a reason why DEC spent the time maintaining the old application
source books. This stuff matters. Big time.

How many potential x86-64 VMS customers have VSI lost over the last
2-3 years because of the lack of marketing ?

Post by Phillip Helbig (undress to reply)
Any manager who would base his decision on whether Rdb was on x86 VMS
already knows that Rdb will run on x86 VMS.

That information only became available in public very recently and is
still not on the VSI website that I can see.

Simon.

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

Phillip Helbig (undress to reply)

2020-11-25 21:02:40 UTC

Post by Phillip Helbig (undress to reply)
The announcement that Rdb is available for x86-VMS tells the manager
nothing about whether enough people will be using VMS on x86-64 to make
it a relatively safe decision for that manager to also take.

You _still_ don't get it Phillip.
It tells the manager that a major vendor has committed to x86-64 VMS
and that in itself helps give a increased level of confidence.

In other contexts known as vaporware.

Post by Simon Clubley
There's a reason why DEC spent the time maintaining the old application
source books. This stuff matters. Big time.

And what happened to DEC?

Post by Simon Clubley
That information only became available in public very recently and is
still not on the VSI website that I can see.

Rdb engineers have said, publicly, for years now that they expect Rdb to
run on VMS a short time after the first boot. Old news.

IanD

2020-11-25 22:04:17 UTC

<snip>

Post by Phillip Helbig (undress to reply)
Rdb engineers have said, publicly, for years now that they expect Rdb to
run on VMS a short time after the first boot. Old news.

Care to point out where? (Genuine question)

If you have to resort to some information buried in an old email or some some smelly old static web-page somewhere then it's not really any good for most people other than those already in the know

I wasn't asking for official statement or clauses that might get vsi into hot water by stating something that might give a legal beagle an 'expected outcome' but surely we could have something put up to where we can send people to to shows things beyond the official x86 port are happening and where those browsing might easily stumble across it

What's wrong with a Rumor's mill page?

For example: https://www.gsmarena.com/rumored.php3

Google Rumor Mill and you'll get 10,600,000 results. Have quick browse of them and you'll see how they are being used

Rumor mill pages typically have some factual basis to them but they come without official endorsement

For example, those working on open source aspects of vms can post there to show what they are working on a new release of say php or mysql. At present this information has to be gleaned by listening to the discussions that get recorded each month and/or written up in the summary notes on Sourceforge

Approximate time frames might or might not be included but what they do is give people the idea that life is still there and that things are still happening

Rumor mills are great advertising focus points

Every tiny angle should be used and explored, irrespective of whether people believe it will yield 20% sales increase or 0.2% sales or none

HP already put a bullet into vms and that event was pushed very loudly around the globe and that was really the last great bit of vms news heard at scale. Most shops I talk to still don't know who vsi is and they still think HP are getting rid of vms

Arne Vajhøj

2020-11-26 02:34:08 UTC

Post by IanD
I wasn't asking for official statement or clauses that might get vsi
into hot water by stating something that might give a legal beagle an
'expected outcome' but surely we could have something put up to where
we can send people to to shows things beyond the official x86 port
are happening and where those browsing might easily stumble across
it
What's wrong with a Rumor's mill page?
For example: https://www.gsmarena.com/rumored.php3
Google Rumor Mill and you'll get 10,600,000 results. Have quick
browse of them and you'll see how they are being used
Rumor mill pages typically have some factual basis to them but they
come without official endorsement
For example, those working on open source aspects of vms can post
there to show what they are working on a new release of say php or
mysql. At present this information has to be gleaned by listening to
the discussions that get recorded each month and/or written up in the
summary notes on Sourceforge
Approximate time frames might or might not be included but what they
do is give people the idea that life is still there and that things
are still happening
Rumor mills are great advertising focus points

Sounds like you are asking for the resurrection of
Charlie Matco.

:-)

But it is a different world today.

I suspect that the decision makers of today will pay
very little attention to rumor mills. They will only
consider official commitments. Way too many rumors
out there.

Arne

Dave Froble

2020-11-27 04:07:55 UTC

Sounds like you are asking for the resurrection of
Charlie Matco.

If only ....

I liked Terry, and was rather distressed when he could not go on ...

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

Simon Clubley

2020-11-27 18:52:25 UTC

[I'm posting the following again because the original posting doesn't
appear to have made it out of Eternal September. Apologies if you see
this a second time and those of you who have posted using Eternal
September over the last day or so might want to check that your own
postings have made it out of Eternal September.]

You _still_ don't get it Phillip.
It tells the manager that a major vendor has committed to x86-64 VMS
and that in itself helps give a increased level of confidence.

In other contexts known as vaporware.

You really don't get this marketing and building confidence within end-user
organisations thing do you Phillip ?

It is the job of VSI marketing to convince the end-user organisations
that staying the course with VSI, for however long it takes for x86-64
VMS to become available, is the safest option for the end-user organisation
(and for the manager's company pension!).

So far, VSI marketing don't appear to be doing a very good job of that
(to put it mildly).

Post by Simon Clubley
There's a reason why DEC spent the time maintaining the old application
source books. This stuff matters. Big time.

And what happened to DEC?

For a time, they were the second most powerful computer company around.

Post by Simon Clubley
That information only became available in public very recently and is
still not on the VSI website that I can see.

Rdb engineers have said, publicly, for years now that they expect Rdb to
run on VMS a short time after the first boot. Old news.

Most certainly not old news.

Even if the engineers were saying that (and I didn't see any mention
of that), you cannot trust what they said until their management made
a decision.

At the start of the x86-64 VMS port, people were lead to believe that
Ada would be coming to x86-64 VMS right until it was realised that it
would not be.

Those Ada customers no longer have a way forward on VMS.

Simon.

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

Dave Froble

2020-11-27 21:01:20 UTC

Post by Phillip Helbig (undress to reply)
Rdb engineers have said, publicly, for years now that they expect Rdb to
run on VMS a short time after the first boot. Old news.

Most certainly not old news.
Even if the engineers were saying that (and I didn't see any mention
of that), you cannot trust what they said until their management made
a decision.

If engineers have been told to work on a project, then the chances of
that project becoming available are better than not.

Don't forget Simon, management can change their minds about things.
Anything they say may not be any better forecast than what the engineers
might say.

Post by Simon Clubley
At the start of the x86-64 VMS port, people were lead to believe that
Ada would be coming to x86-64 VMS right until it was realised that it
would not be.

Sort of reinforces my point, don't ya think?

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

Simon Clubley

2020-11-30 13:07:45 UTC

Post by Simon Clubley
At the start of the x86-64 VMS port, people were lead to believe that
Ada would be coming to x86-64 VMS right until it was realised that it
would not be.

Sort of reinforces my point, don't ya think?

Just the opposite. It was engineers indicating that it was going to
become available on x86-64 VMS until it suddenly wasn't.

Simon.

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

John Reagan

2020-11-30 15:17:55 UTC

Post by Simon Clubley
At the start of the x86-64 VMS port, people were lead to believe that
Ada would be coming to x86-64 VMS right until it was realised that it
would not be.

Sort of reinforces my point, don't ya think?

Just the opposite. It was engineers indicating that it was going to
become available on x86-64 VMS until it suddenly wasn't.
Simon.

To be clear, I never said that. If you look at the slides from any of my earliest compiler presentations, I either kept Ada separate or didn't mention it at all. Our "GEM to LLVM" converter is not sufficient for our ancient DEC Ada which was never on Itanium, just Alpha. What I have said is that I personally think that an Ada solution would be helpful to many customers.

John Dallman

2020-11-30 18:13:00 UTC

Post by John Reagan
Our "GEM to LLVM" converter is not sufficient for our ancient DEC
Ada which was never on Itanium, just Alpha. What I have said is
that I personally think that an Ada solution would be helpful to
many customers.

Presumably, porting GNAT (Gnu Ada) may be possible in principle, but
would be a lot of work? There's work towards porting it to Itanium at
https://github.com/AdaLabs/gnat-vms

John

John Reagan

2020-11-30 18:20:12 UTC

Presumably, porting GNAT (Gnu Ada) may be possible in principle, but
would be a lot of work? There's work towards porting it to Itanium at
https://github.com/AdaLabs/gnat-vms
John

That's the direction I would go. You might end up with the entire gcc toolchain. There have been reports with VMS support going away so it might have to come back. There have been mentions of rehosting GNAT to LLVM. And there was a gcc-compatibility layer for LLVM called DragonEgg in the past. It has been removed from the current source tree due to lack of support (doesn't mean it couldn't be brought back to life).

John Dallman

2020-11-30 19:05:00 UTC

Post by John Reagan
That's the direction I would go. You might end up with the entire
gcc toolchain. There have been reports with VMS support going away
so it might have to come back.

Bringing back the GCC toolchain might be a good idea anyway. I've
remembered an LLVM feature that caused me trouble a few years back, which
may surprise people used to the DEC compilers.

With GCC, and AFAIK with the DEC compilers, one can enable floating-point
traps, and get sensible results, trapping when you divide by zero,
overflow or try an invalid operation, such as sqrt(-1.0).

GCC is well aware that floating-point operations may cause traps, and its
optimiser limits the rearrangement of code so that you don't get spurious
ones. For example if you have:

double a, b;
...
if ( b < really-small-number)
a = 0.0;
else
a = 1.0 / b;

GCC won't move the divide out from under the test that guards against
divide-by-zero.

LLVM, in contrast, explicitly assumes that floating-point traps will
never be enabled, and regards this as obvious, not mentioning the point
in its documentation AFAICS. If it has compiled the above code, it may
well execute the divide before it knows if the guard condition is true.
If that happens, and floating-point traps are enabled, you'll get a trap
/every time/ the code is executed with b = 0.0. I hit this problem on x86
macOS a few years back, and had to give up using floating-point traps on
that platform.

MSVC and GCC still respect trap semantics, for now.

John

John Reagan

2020-11-30 21:48:05 UTC

That's the direction I would go. You might end up with the entire
gcc toolchain. There have been reports with VMS support going away
so it might have to come back.

Bringing back the GCC toolchain might be a good idea anyway. I've
remembered an LLVM feature that caused me trouble a few years back, which
may surprise people used to the DEC compilers.
With GCC, and AFAIK with the DEC compilers, one can enable floating-point
traps, and get sensible results, trapping when you divide by zero,
overflow or try an invalid operation, such as sqrt(-1.0).
GCC is well aware that floating-point operations may cause traps, and its
optimiser limits the rearrangement of code so that you don't get spurious
double a, b;
...
if ( b < really-small-number)
a = 0.0;
else
a = 1.0 / b;
GCC won't move the divide out from under the test that guards against
divide-by-zero.
LLVM, in contrast, explicitly assumes that floating-point traps will
never be enabled, and regards this as obvious, not mentioning the point
in its documentation AFAICS. If it has compiled the above code, it may
well execute the divide before it knows if the guard condition is true.
If that happens, and floating-point traps are enabled, you'll get a trap
/every time/ the code is executed with b = 0.0. I hit this problem on x86
macOS a few years back, and had to give up using floating-point traps on
that platform.

Not true anymore. LLVM has added support for all of those trapping modes to match gcc. And including FENV support in clang.

John Dallman

2020-11-30 22:22:00 UTC

Not true anymore. LLVM has added support for all of those
trapping modes to match gcc. And including FENV support in clang.

Oh, good show. What version of LLVM has this?

John

John Reagan

2020-12-01 15:12:56 UTC

Not true anymore. LLVM has added support for all of those
trapping modes to match gcc. And including FENV support in clang.

Oh, good show. What version of LLVM has this?
John

Most should be in the released clang/LLVM 10.0.1 but I think I've seen a few changes past that.

The missing support has been a concern of mine as well but with the FENV support and the integration of the flang compiler into LLVM, the missing floating exception support was added. I've been sitting back and watching it. It is 99.99% the model that GEM uses so our mapping should be easy as we bootstrap to those newer versions on native systems.

John Dallman

2020-12-01 17:07:00 UTC

Post by John Reagan
Most should be in the released clang/LLVM 10.0.1 but I think I've
seen a few changes past that.

Thanks!

John

Simon Clubley

2020-12-01 13:07:30 UTC

Post by John Dallman
Bringing back the GCC toolchain might be a good idea anyway. I've
remembered an LLVM feature that caused me trouble a few years back, which
may surprise people used to the DEC compilers.
With GCC, and AFAIK with the DEC compilers, one can enable floating-point
traps, and get sensible results, trapping when you divide by zero,
overflow or try an invalid operation, such as sqrt(-1.0).
GCC is well aware that floating-point operations may cause traps, and its
optimiser limits the rearrangement of code so that you don't get spurious
double a, b;
...
if ( b < really-small-number)
a = 0.0;
else
a = 1.0 / b;
GCC won't move the divide out from under the test that guards against
divide-by-zero.

Would declaring the variables volatile have avoided this reordering ?

And talking of volatile, I wonder if John has encountered any cases
with LLVM where variables now need to be declared volatile where they
did not need to be with the DEC compilers.

Simon.

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

Arne Vajhøj

2020-12-01 15:33:21 UTC

Would declaring the variables volatile have avoided this reordering ?
And talking of volatile, I wonder if John has encountered any cases
with LLVM where variables now need to be declared volatile where they
did not need to be with the DEC compilers.

I am not a memory model expert, but everybody is saying that
the x86-64 memory model is easier to work with than the
Alpha and Itanium memory models.

Arne

John Reagan

2020-12-01 16:03:58 UTC

Would declaring the variables volatile have avoided this reordering ?
And talking of volatile, I wonder if John has encountered any cases
with LLVM where variables now need to be declared volatile where they
did not need to be with the DEC compilers.

I am not a memory model expert, but everybody is saying that
the x86-64 memory model is easier to work with than the
Alpha and Itanium memory models.
Arne

This is more a compiler issue with regards to legal code optimizations. Compiling -O0 /NOOPT will keep the error in the "right" stop.

As far as the hardware memory ordering, yes, the x86 is more like VAX. Alpha is the most, uh, "flexible" that needs MB and IMB instructions to serialize memory ordering.

Simon Clubley

2020-12-01 18:27:19 UTC

Post by John Reagan
This is more a compiler issue with regards to legal code optimizations. Compiling -O0 /NOOPT will keep the error in the "right" stop.
As far as the hardware memory ordering, yes, the x86 is more like VAX. Alpha is the most, uh, "flexible" that needs MB and IMB instructions to serialize memory ordering.

I was thinking more that the VMS APIs are much more asynchronous than
the Unix APIs so I wondered if the optimiser in LLVM was doing things
to asynchronous VMS code that broke the code when compiled with LLVM
but which worked when compiled with the DEC compilers.

We have had this discussion in the past when talking about memory
locations which were not marked as volatile, but at that time, things
were not far enough along in the port to know if there were any
issues there.

Now that things are further along, I was wondering if any issues
had been discovered with the asynchronous updating of memory locations
(ie: outside of a call boundary to a VMS API) and, if so, if it was
just a simple matter of correctly marking those locations as volatile.

Simon.

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

Arne Vajhøj

2020-12-01 19:18:35 UTC

Post by John Reagan

Post by Simon Clubley
Would declaring the variables volatile have avoided this
reordering ?
And talking of volatile, I wonder if John has encountered any
cases with LLVM where variables now need to be declared volatile
where they did not need to be with the DEC compilers.

I am not a memory model expert, but everybody is saying that the
x86-64 memory model is easier to work with than the Alpha and
Itanium memory models.

This is more a compiler issue with regards to legal code
optimizations. Compiling -O0 /NOOPT will keep the error in the
"right" stop.
As far as the hardware memory ordering, yes, the x86 is more like
VAX. Alpha is the most, uh, "flexible" that needs MB and IMB
instructions to serialize memory ordering.

From what I have heard then MS engineers had to rethink some things
when they 15 years ago ported .NET from x86/x86-64 to Itanium.

Arne

John Dallman

2020-12-01 16:14:00 UTC

Would declaring the variables volatile have avoided this reordering?

As best I recall, it didn't, but the pattern is so common in our code
that we could not have use that as a solution.

And talking of volatile, I wonder if John has encountered any cases
with LLVM where variables now need to be declared volatile where
they did not need to be with the DEC compilers.

I have not used the DEC compilers for about twenty years, and the code I
work on has changed a lot in that time. Sorry I can't be more help.

John

Simon Clubley

2020-12-01 18:29:36 UTC

Post by Simon Clubley
And talking of volatile, I wonder if John has encountered any cases
with LLVM where variables now need to be declared volatile where
they did not need to be with the DEC compilers.

I have not used the DEC compilers for about twenty years, and the code I
work on has changed a lot in that time. Sorry I can't be more help.

My apologies. I was referring to John Reagan. John has been working
on the port of LLVM to x86-64 VMS.

Simon.

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

John Reagan

2020-12-02 02:49:28 UTC

Would declaring the variables volatile have avoided this reordering ?
And talking of volatile, I wonder if John has encountered any cases
with LLVM where variables now need to be declared volatile where they
did not need to be with the DEC compilers.
Simon.
--
Walking destinations on a map are further away than they appear.

You've asked that question before. It ended up in a long and twisted thread (as most do here at c.o.v).

So all compilers (DEC, gcc, clang/LLVM, IBM, etc.) all perform their own unique set of optimizations. Some are classic compiler optimizations and some are vendor-specific and might vary based on chip set (ie /ARCH or /OPT=TUNE). And with the various command line options, the permutations of optimizations that might be applied are unbounded.

In my opinion, "volatile" is a place where you have written a technically illegal program that did not perform as expected due one or more optimizations making assumptions that your program was legal. Illegal programs have undefined behavior, but instead of saying "turn off all optimizations and deal with it", the language provides "volatile" as a way to tell the compiler that operations on a "volatile variable" do not follow the language specification as an attempt to preserve as much performance as possible.

To answer your question directly, no, I've never seen a place where I would need to now use volatile with LLVM than with DEC C, but my experience is limited. I don't know all the optimizations in LLVM, how they are applied, etc. I can barely wrap my head around all the optimizations in GEM.

Your question is really: Are there illegal programs that work "correctly" with DEC C without using volatile that will not work correctly with LLVM? Who knows. The number of illegal programs are infinite. Could there possibly be one that works accidentally on VAX, Alpha, Itanium with GEM but not with LLVM on x86 (or ARM or PPC or Apple M1 or some quantum computer)? Probably.

Eberhard Heuser

2020-11-30 19:11:59 UTC

Presumably, porting GNAT (Gnu Ada) may be possible in principle, but
would be a lot of work? There's work towards porting it to Itanium at
https://github.com/AdaLabs/gnat-vms
John
_______________________________________________
Info-vax mailing list
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com

I can confirm that this code still works with V8.x C-header files.

Eberhard

gérard Calliet

2020-12-01 16:21:41 UTC

Presumably, porting GNAT (Gnu Ada) may be possible in principle, but
would be a lot of work? There's work towards porting it to Itanium at
https://github.com/AdaLabs/gnat-vms
John

We have done this (cross-)built 4 years ago (we: adalabs, pia-sofer(me,
www.pia-sofer.fr)) with some friendly help of members of Adacore who
knew perfectly what was done for gcc/vms on Ada. We used a set of
headers from 8.4* itanium.

It is a little bit old now. For example we need a Linux wheezy
environment, wich is now archived. It is based en gcc 4.3.7

I (pia-sofer and a more community-oriented link here: www.vmsadaall.org)
am working now to go ahead.

First it seems possible to upgrade to gcc 4.9 which is the last version
for which adacore published on FSF. In the same time I am working to get
with the Ada compiler the C and C++ (gcc) compilers. It seems it is
possible. Eveything only on Itanium.

Second, with a little more effort, I'll try upgrades to more recent gcc
versions. I have to bring back the VMS specificities Adacore had taken
off. And pray that gcc improvments will not imply too much work on VMS.
This second step is a little bit "just for fun", not a priority. I would
like to understand what have been the technical difficulties Adacore
encountered to get off, even if I think the problem was mostly
commercial, and of bad relations with HP.

To get Ada on VMS/x86 the better way seems to play with the Adacore
work-in-progress of gnat/llvm (https://github.com/AdaCore/gnat-llvm). It
is something up-to-date (more than DragonEgg). I'm just beginning to
explore their work today.

For sure their use of llvm has to be tranformed to plug it on
VSI/llvm/x86. And I don't know how VSI could accept to communicate on
their llvm internals (on linux, itanium and x86). On my side I'm totally
open :)

Everyone is welcomed on a community effort. And I do think, because of
the nature (open source) and complexity (huge) of gcc, Ada and llvm that
only a community effort could do the job. I'll initiate soon a blog on
www.vmsadaall.org .

gérard Calliet

2020-12-03 11:04:13 UTC

A thread initiated partly because of a french initiative where
information came about rdb. The intiative is from an user group where
I'm part of its fondation, saving an old Decus group from dead.

The same thread about ADA, for which I built the compiler for Itanium
VMS in 2015.

A new proposition of method to go ahead with Ada.

Not any answer.

Perhaps the guy who wrote an Opened Letter against the death of VMS. The
same guy who didn't think a second that VMS could die and was thought as
a "poet". The same guy who was named VMS ambassador by Sue Skonetski
because of his action. The guy whom partner in France selled the first
VSI licence, because of decades of lobbying. This guy, perhaps, is
perceived as a troll and deserves being treated like a plague victim.

I have to apologize for all my commitment for VMS. The Big Bosses and
the Overactive Community must not be bothered. As could say Clair:
nothing heard. I hope my VMS customers don't hear this deafness.

However thanks to the one guy (be patient, don't confess you are friend
with the wrong guy) who answered In the Minute about what can be done
for Ada / VMS. The old spirit of the VMS community is not dead.

Nowhere man (you the song).

Presumably, porting GNAT (Gnu Ada) may be possible in principle, but
would be a lot of work? There's work towards porting it to Itanium at
https://github.com/AdaLabs/gnat-vms
John

Simon Clubley

2020-11-30 18:13:56 UTC

Post by John Reagan

Post by Simon Clubley
At the start of the x86-64 VMS port, people were lead to believe that
Ada would be coming to x86-64 VMS right until it was realised that it
would not be.

Sort of reinforces my point, don't ya think?

Just the opposite. It was engineers indicating that it was going to
become available on x86-64 VMS until it suddenly wasn't.
Simon.

I wasn't thinking of you when I said that.

It was someone else from VSI, probably Clair, who indicated the efforts
being made to get Ada on to x86-64 VMS. At some point those efforts
collapsed suddenly and hence no Ada for x86-64 VMS.

Simon.

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

Clair Grant

2020-12-01 14:50:47 UTC

Post by Simon Clubley
It was someone else from VSI, probably Clair, who indicated the efforts
being made to get Ada on to x86-64 VMS. At some point those efforts
collapsed suddenly and hence no Ada for x86-64 VMS.

We have made multiple efforts to resolve the Ada situation. None have worked out. We have never stopped looking for a solution, as we continue to now.

Clair

Arne Vajhøj

2020-12-01 15:29:36 UTC

Post by Clair Grant

We have made multiple efforts to resolve the Ada situation. None have
worked out. We have never stopped looking for a solution, as we
continue to now.

I think there are two things that could make this happen.

1) Significant commercial demand. If enough people call ACT and
ask if they can buy GNAT for VMS then they will deliver the
product.

2) Enough volunteers. If there were a dozen Ada and VMS enthusiasts
willing to work on getting open source GNAT running on VMS,
then they could make it happen.

I believe Gérard Calliet did some work in this area,

But I suspect that neither significant commercial demand nor
enough volunteers exist.

Arne

Hans Bachner

2020-11-27 22:01:11 UTC

Post by Simon Clubley
[I'm posting the following again because the original posting doesn't
appear to have made it out of Eternal September. Apologies if you see
this a second time and those of you who have posted using Eternal
September over the last day or so might want to check that your own
postings have made it out of Eternal September.]

Yup - Eternal September did not show new postings yesterday (less than a
dozen, iirc) which were available on individual.de. They have caught up
in the meantime.

If this is a word-for-word repetition of your original posting, it
didn't make it to the rest of the world. Or not even to Eternal
September (in its current state).

You _still_ don't get it Phillip.
It tells the manager that a major vendor has committed to x86-64 VMS
and that in itself helps give a increased level of confidence.

In other contexts known as vaporware.

You really don't get this marketing and building confidence within end-user
organisations thing do you Phillip ?
It is the job of VSI marketing to convince the end-user organisations
that staying the course with VSI, for however long it takes for x86-64
VMS to become available, is the safest option for the end-user organisation
(and for the manager's company pension!).
So far, VSI marketing don't appear to be doing a very good job of that
(to put it mildly).

Post by Simon Clubley
There's a reason why DEC spent the time maintaining the old application
source books. This stuff matters. Big time.

And what happened to DEC?

For a time, they were the second most powerful computer company around.

Post by Simon Clubley
That information only became available in public very recently and is
still not on the VSI website that I can see.

Rdb engineers have said, publicly, for years now that they expect Rdb to
run on VMS a short time after the first boot. Old news.

Most certainly not old news.
Even if the engineers were saying that (and I didn't see any mention
of that), you cannot trust what they said until their management made
a decision.

It is old news.

If you followed Oracle's OpenVMS Update Sessions (covering both Rdb and
Oracle Server on OpenVMS), Kevin Duffy always mentioned the close
relationship with VSI and Oracle's efforts for the port to x86. Of
course, without a (rudimentary working) OpenVMS implementation on x86,
these efforts were limited.

VSI always contributed presentations to Oracle's OpenVMS Update Sessions.

Post by Simon Clubley
[...]

Hans.

Simon Clubley

2020-11-30 13:21:33 UTC

Post by Hans Bachner

Post by Simon Clubley
Most certainly not old news.
Even if the engineers were saying that (and I didn't see any mention
of that), you cannot trust what they said until their management made
a decision.

It is old news.
If you followed Oracle's OpenVMS Update Sessions (covering both Rdb and
Oracle Server on OpenVMS), Kevin Duffy always mentioned the close
relationship with VSI and Oracle's efforts for the port to x86. Of
course, without a (rudimentary working) OpenVMS implementation on x86,
these efforts were limited.
VSI always contributed presentations to Oracle's OpenVMS Update Sessions.

Post by Simon Clubley
[...]

That makes it old news for those few in the know. It doesn't make it old
news for the rest of the VMS community. Just look at how many people
here considered it news that a port of Rdb to x86-64 VMS was confirmed
when Jan-Erik posted this information.

We've moved on from the days of secret decoder rings to get access to
the hidden knowledge. Given VSI's current position in the marketplace,
this information should be broadcast loud and wide to everyone who will
listen.

VSI is acting like it's still the DEC of the 1980s when bits of information
were released on DEC's terms at places like DECUS. DEC could get away with
that in the 1980s because it was the Apple of the day and because they were
large enough and powerful enough that they could do that.

Those days are long gone and VSI need to change their approach and start
doing marketing the way it is done these days if it wants to survive in
the longer term.

Simon.

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

Phillip Helbig (undress to reply)

2020-11-30 15:45:03 UTC

Post by Simon Clubley
That makes it old news for those few in the know. It doesn't make it old
news for the rest of the VMS community. Just look at how many people
here considered it news that a port of Rdb to x86-64 VMS was confirmed
when Jan-Erik posted this information.

How many were there?

Simon Clubley

2020-11-30 18:25:58 UTC

How many were there?

Enough. And they are the type of people who are tracking VMS on x86-64
developments closely so should have known long ago if VSI marketing
were doing their job properly.

If _they_ didn't know what VSI and Oracle were up to, then what hope
is there that the less committed VMS users know everything they should
about VMS on x86-64 developments when trying to decide whether to stay
with VMS or not ?

Simon.

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

Phillip Helbig (undress to reply)

2020-11-27 19:33:53 UTC

Post by Simon Clubley
It is the job of VSI marketing to convince the end-user organisations
that staying the course with VSI, for however long it takes for x86-64
VMS to become available, is the safest option for the end-user organisation
(and for the manager's company pension!).

Yes.

Post by Simon Clubley
So far, VSI marketing don't appear to be doing a very good job of that
(to put it mildly).

Maybe.

Post by Simon Clubley
There's a reason why DEC spent the time maintaining the old application
source books. This stuff matters. Big time.

And what happened to DEC?

For a time, they were the second most powerful computer company around.

Right. And why did they disappear? Not because they were off the
radar. They went out of fashion, like sideburns and flared trousers.
Not all decisions are rational.

Post by Simon Clubley
That information only became available in public very recently and is
still not on the VSI website that I can see.

Whatever the details of the news (or not) itself, the question remains
how large an effect a big announcement would have.

Phillip Helbig (undress to reply)

2020-11-24 15:18:13 UTC

Post by Arne VajhÃ¸j
But what exactly do you want VSI to say?
"VSI promise that Rdb will be available on VMS x86-64"
then VSI would have a serious problem if Oracle changed their mind
and Oracle may get pretty pissed at VSI.
"Oracle promise that Rdb will be available on VMS x86-64"
Unless Oracle senior management has officially committed then
same issues as above.
"We hear that some smart guys over at Oracle is working on Rdb
VMS x86-64"
And leave it to readers to make their own conclusions.
That could easily sound rather un-enthusiastic.
"We just has a meeting with Oracle and the future
looks bright - see link here ..."
Maybe that would work.
But finding a message that is both without legal/business risk
and enthusiastic is not trivial (unless Oracke has officially
announced).

Right. My guess is that whatever VSI and/or Oracle do, NEW Rdb
customers on x86 will be few and far between. As for old customers, Rdb
engineers have long stated publicly that if there is VMS on x86 then
they will support Rdb on it, so Rdb customers have known that for a long
time.

Bill Gunshannon

2020-11-24 15:44:03 UTC

Post by Phillip Helbig (undress to reply)
As for old customers, Rdb
engineers have long stated publicly that if there is VMS on x86 then
they will support Rdb on it, so Rdb customers have known that for a long
time.

Surely people, even here, know that it is highly unlikely the the
decision is in the hands of the engineers.

bill

Kerry Main (C.O.V.)

2020-11-25 01:03:46 UTC

-----Original Message-----
undress to reply via Info-vax
Sent: November-24-20 11:18 AM
Subject: Re: [Info-vax] Rdb/x86

Post by Arne VajhÃ¸j
But what exactly do you want VSI to say?
"VSI promise that Rdb will be available on VMS x86-64"
then VSI would have a serious problem if Oracle changed their mind and
Oracle may get pretty pissed at VSI.
"Oracle promise that Rdb will be available on VMS x86-64"
Unless Oracle senior management has officially committed then same
issues as above.
"We hear that some smart guys over at Oracle is working on Rdb
VMS x86-64"
And leave it to readers to make their own conclusions.
That could easily sound rather un-enthusiastic.
"We just has a meeting with Oracle and the future looks bright - see
link here ..."
Maybe that would work.
But finding a message that is both without legal/business risk and
enthusiastic is not trivial (unless Oracke has officially announced).

Right. My guess is that whatever VSI and/or Oracle do, NEW Rdb customers
on x86 will be few and far between. As for old customers, Rdb engineers
have long stated publicly that if there is VMS on x86 then they will

support

Rdb on it, so Rdb customers have known that for a long time.

Re: existing Rdb OpenVMS Customers moving to X86-64 ...

Note - Oracle licensing is primarily based on server hardware - not the OS.
Named user is also available.

As a reminder, license costs for Rdb OpenVMS on X86-64 will be 50% of what
they are on Alpha, IA64.

And then there are the normal discounts applied on top of this.

This is because of the Oracle Processor Core Factor (PCF) .. there is a
weighting factor applied to all Oracle licenses (price x PCF) that is based
on your hardware platform.

For most competitive platforms to Oracle (Alpha, Power. IA64 etc.) the
Factor is 1.0

For X86 platforms, the weighting factor is 0.5.

Reference: (slide 23)
https://www.oracle.com/a/ocom/docs/corporate/oracle-software-licensing-basic
s.pdf

Hence, since Oracle licensing and support costs is typically in the hundreds
of thousands USD's for many med-large Customers, the hardware platform they
choose is a really big deal. Often dwarfing the costs of the server
hardware.

Imho, the PCF cost savings is one of the major reasons why many Oracle
Customers flipped from Solaris, AIX and HP-UX to Oracle on Linux/X86-64.

Kerry

--
This email has been checked for viruses by AVG.
https://www.avg.com

Marc Van Dyck

2020-11-14 11:48:17 UTC

Post by Simon Clubley
Many people around here would make excellent VSI marketing employees.
That is not a good thing BTW.
The reason why people are commenting about (the lack of) VSI marketing
is because I suspect they can see the same bigger picture that I can.
After years of broken promises about when x86-64 VMS would become
available, big things are finally starting to happen in the x86-64 VMS
world, and VSI should be shouting that out loud to anyone who will
listen.
VSI should be actively continuing to keep the idea of VMS as a still
viable choice in the minds of people and when something like this comes
along which shows that, after years of broken promises, x86-64 VMS is
_finally_ almost here, VSI should be telling everyone about it as soon
as they are allowed to (which at the latest is when Oracle did their
first public presentation on it).

This passivity of VSI regarding ISV applications is certainly not
limited to RDB... We hear absolutely nothing from VSI about ISVs who
have committed (or not) to port their product to VMS on X86, and for
people like me who are (or, better said, were) actively preparing the
migration, this is a real pain in the neck. When you are using products
like enterprise schedulers, managed file transfer tools, and messaging
products, which are all multi-platform by essence, knowing that your
tool of choice will be supported (or not) on your target platform is
essential information. And here we're left completely in the dark.

I start thinking that VSI, run mainly by ex-Digital people, make the
sames mistakes that Digital did in the past, i.e. focus on technology
only and forget about everything else. We all know how it ended.

--
Marc Van Dyck

Andrew Brehm

2020-11-30 22:54:20 UTC

perhaps VSI could even start creating promotional materials

Yes! Yes! Yesy!

And I kept telling them. In Paris last year and the year before, I kept
telling everyone I could find and talk to that we need swag.

Mouse pads, hats, jackets, biros, possibly bags with OpenVMS and VSI logos.

I see those things all over the place in the office for NetApp, VMware,
Microsoft, IBM and Oracle.

--
Andrew Brehm

Simon Clubley

2020-12-01 13:10:50 UTC

Post by Andrew Brehm

perhaps VSI could even start creating promotional materials

Yes! Yes! Yesy!
And I kept telling them. In Paris last year and the year before, I kept
telling everyone I could find and talk to that we need swag.
Mouse pads, hats, jackets, biros, possibly bags with OpenVMS and VSI logos.
I see those things all over the place in the office for NetApp, VMware,
Microsoft, IBM and Oracle.

Nice to see someone else gets this marketing thing.

It would be nice if VSI did.

And yes, VSI producing promotional materials could be a _really_ good
idea for helping you to get the message out there if you want to try
doing the marketing thing.

Simon.

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

Phillip Helbig (undress to reply)

2020-11-13 16:00:07 UTC

Post by Simon Clubley
I've just checked VSI's website - there's nothing there that I can see
and this is _major_ and _very_ good news for VMS on x86-64.

Right, and I think that was commented on also.

Rdb users probably already knew it. I can't see an announcement
attracting non-Rdb users to VMS.

Post by Simon Clubley
This would send a major signal because VSI have managed to get _Oracle_
to commit to Rdb on x86-64 and it would be a major confidence boost that
x86-64 VMS is less likely to suddenly fail at the last moment.

Rdb was ported before. Maybe they did it right. Maybe it was more or
less compile and go, hence not a big commitment. Not to take away from
Rdb engineering, but trying to spin this as some huge commitment on the
part of Oracle would probably be stretching it. Has Larry heard of Rdb?
Very probably. VSI? Probably. The port? Maybe a word or two. I'm
sure that he is more committed to his yachts than to VMS.

Arne Vajhøj

2020-11-13 18:28:31 UTC

The word is that Rdb is very much Bliss.

A port to a different ISA with same OS, same compiler, same
bitness, same endianess and a simpler memory model should
not be too bad.

Arne

Craig A. Berry

2020-11-13 19:12:12 UTC

The word is that Rdb is very much Bliss.
A port to a different ISA with same OS, same compiler, same
bitness, same endianess and a simpler memory model should
not be too bad.

They generate some query-specific code at run-time and use GEM for the
precompilers, so it's likely a bit more than compile-and-go. But yes,
they have done this before, and appear to have learned a few things and
improved portability in the VAX-to-Alpha and Alpha-to-Itanium ports as
well as in the abortive ports to Windows NT and Tru64:

<https://download.oracle.com/otndocs/products/rdb/pdf/tech_archive/port_rdb_to_itanium.pdf>

By the way, notice the statement of commitment from an Oracle VP on
slide #2 before VMS had even booted on Itanium.

Arne Vajhøj

2020-11-13 19:30:54 UTC

Post by Craig A. Berry

The word is that Rdb is very much Bliss.
A port to a different ISA with same OS, same compiler, same
bitness, same endianess and a simpler memory model should
not be too bad.

They generate some query-specific code at run-time and use GEM for the
precompilers, so it's likely a bit more than compile-and-go.

For code generation ISA becomes important.

Which makes me think about a question: will VMS x86-64 use NX bit?

Post by Craig A. Berry
But yes,
they have done this before, and appear to have learned a few things and
improved portability in the VAX-to-Alpha and Alpha-to-Itanium ports as
<https://download.oracle.com/otndocs/products/rdb/pdf/tech_archive/port_rdb_to_itanium.pdf>
By the way, notice the statement of commitment from an Oracle VP on
slide #2 before VMS had even booted on Itanium.

At the time HP was one of the worlds biggest IT companies and
significantly bigger than Oracle.

Arne

Phillip Helbig (undress to reply)

2020-11-13 19:33:41 UTC

Post by Arne VajhÃ¸j
The word is that Rdb is very much Bliss.

In more ways than one. :-)

gérard Calliet

2020-11-15 17:23:13 UTC