Final Orace release on VMS.

Post by Jan-Erik SÃ¶derholm
We are writing to inform you that Oracle Database 11.2.0.4 will be the
terminal Oracle Database release offered on the OpenVMS platform. MOS
DOC ID 742060.1 has recently been updated to reflect this development.

Not good.

Is this server or client libs or both?

Arne

Jan-Erik Söderholm

2020-10-27 01:23:51 UTC

Post by Jan-Erik SÃ¶derholm
We are writing to inform you that Oracle Database 11.2.0.4 will be the
terminal Oracle Database release offered on the OpenVMS platform. MOS DOC
ID 742060.1 has recently been updated to reflect this development.

Not good.
Is this server or client libs or both?
Arne

I *think* this is about server only.

John H. Reinhardt

2020-10-27 02:38:50 UTC

We are writing to inform you that Oracle Database 11.2.0.4 will be the terminal Oracle Database release offered on the OpenVMS platform. MOS DOC ID 742060.1 has recently been updated to reflect this development.

Not good.
Is this server or client libs or both?
Arne

I *think* this is about server only.

As an Oracle DBA I don't like it, but it kind of makes sense. I doubt they've done any code for OpenVMS since 11gR2 so catching up to Oracle 19 would be a major headache. I haven't dug deeply, but I do not recall seeing any OpenVMS clients for Oracle RDBMS 12cR1, 12cR2 or 18 or 19. I'd have to double check. If there was I'm betting it's Itanium only

--
John H. Reinhardt

Phillip Helbig (undress to reply)

2020-10-27 06:04:17 UTC

Not good.
Is this server or client libs or both?

What fraction of paying VMS customers use Oracle "classic" (which is
what the announcement is about)? What fraction use Rdb? What fraction
use some other database? What fraction use no database (not counting
RMS)?

Scott Dorsey

2020-10-28 13:34:56 UTC

Post by Phillip Helbig (undress to reply)
What fraction of paying VMS customers use Oracle "classic" (which is
what the announcement is about)? What fraction use Rdb? What fraction
use some other database? What fraction use no database (not counting
RMS)?

Probably not many use Oracle Classic. However, if there is any chance of
expanding the customer base at all and get new people to use VMS, having
support for Oracle is a big, big deal. There are a lot of people using
Oracle on their back end systems.
--scott

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

Phillip Helbig (undress to reply)

2020-10-28 13:59:06 UTC

Big users of Oracle Classic probably have an application very tied to
the database. There isn't a huge advantage for them moving to VMS. My
guess is that, among paying customers, more than half use Rdb and less
than 1% Oracle Classic.

Arne Vajhøj

2020-11-12 16:05:36 UTC

Rdb is undoubtedly the most important among those using VMS today.

But VMS should hopefully grow beyond who are using VMS today.

For a certain market segment then Oracle DB (Oracle classic) is
very important.

But:
1) Oracle may be difficult to persuade to change strategy (they are
a huge company and VSI is a small company).
2) There are other market segments than those willing to pay
a 5 digit dollar amount per core for database licenses.

Available relational databases on VMS include:
* Rdb
* MySQL/MariaDB
* SQlite
* Mimer
* HSQLDB
* H2
* Derby

Arne

Jan-Erik Söderholm

2020-11-12 16:19:11 UTC

Rdb is undoubtedly the most important among those using VMS today.
But VMS should hopefully grow beyond who are using VMS today.
For a certain market segment then Oracle DB (Oracle classic) is
very important.
1) Oracle may be difficult to persuade to change strategy (they are
a huge company and VSI is a small company).
2) There are other market segments than those willing to pay
a 5 digit dollar amount per core for database licenses.
* Rdb
* MySQL/MariaDB
* SQlite
* Mimer
* HSQLDB
* H2
* Derby
Arne

Seems as the response from Oracle is to run your applications as
usual using the client kit, but have the server on another platform.

Arne Vajhøj

2020-11-12 16:30:16 UTC

Seems as the response from Oracle is to run your applications as
usual using the client kit, but have the server on another platform.

If the client library is available then that is an option.

But I am sure that VSI would have loved to sell some VMS licenses
for Oracle DB servers ...

Arne

Marc Van Dyck

2020-11-12 16:46:27 UTC

Rdb is undoubtedly the most important among those using VMS today.
But VMS should hopefully grow beyond who are using VMS today.
For a certain market segment then Oracle DB (Oracle classic) is
very important.
1) Oracle may be difficult to persuade to change strategy (they are
a huge company and VSI is a small company).
2) There are other market segments than those willing to pay
a 5 digit dollar amount per core for database licenses.
* Rdb
* MySQL/MariaDB
* SQlite
* Mimer
* HSQLDB
* H2
* Derby
Arne

Seems as the response from Oracle is to run your applications as
usual using the client kit, but have the server on another platform.

With support for the client until end 2022 only, and for the server
end of 2027. And on Itanium only, as there will not be any port to
X86 at all, even not the client.

In other words, start migrating today. WHat's the proportion of VSI
customers who need access to an Oracle database ? If all those cannot
migrate to X86, is the viability of VSI still guaranteed ? Who's going
to bet the farm on that, with one year subscription licenses ?

--
Marc Van Dyck

Arne Vajhøj

2020-11-12 16:55:10 UTC

Seems as the response from Oracle is to run your applications as
usual using the client kit, but have the server on another platform.

With support for the client until end 2022 only, and for the server
end of 2027. And on Itanium only, as there will not be any port to
X86 at all, even not the client.
In other words, start migrating today. WHat's the proportion of VSI
customers who need access to an Oracle database ? If all those cannot
migrate to X86, is the viability of VSI still guaranteed ? Who's going
to bet the farm on that, with one year subscription licenses ?

The consensus here seems to be that while Rdb is critical for VMS
then Oracle DB (Oracle classic) is not,

So VSI may survive. But it is the wrong direction. We need VMS
support in more products not less less products.

But as I listed then there are still plenty of relational databases
available on VMS. It may be better spent effort trying to promote those
than trying to persuade Oracle (oracle seems to be on a Linux focused
path and that is probably a top decision - not easy to change).

Arne

PS: And as I mentioned previously then you can always chose something
J'ish on VMS as Oracle thin JDBC driver is pure Java and does
not care about the OS.

Phillip Helbig (undress to reply)

2020-11-12 18:46:27 UTC

Post by Arne VajhÃ¸j
So VSI may survive. But it is the wrong direction. We need VMS
support in more products not less less products.

I find it strange that people are pushing Oracle Classic on VMS as a way
to more users, but discount my suggestion of a modern web browser. :-|

Arne Vajhøj

2020-11-12 18:59:45 UTC

Post by Arne VajhÃ¸j
So VSI may survive. But it is the wrong direction. We need VMS
support in more products not less less products.

I find it strange that people are pushing Oracle Classic on VMS as a way
to more users, but discount my suggestion of a modern web browser. :-|

Focus on specific market.

VSI want to (and many hear agree with them) focus on servers.

Arne

Phillip Helbig (undress to reply)

2020-11-12 21:02:26 UTC

Post by Arne VajhÃ¸j
VSI want to (and many hear agree with them) focus on servers.

But even so, Oracle Classic seems to be a non-starter. The fraction of
people using it on VMS is very low anyway, and was never high, and VMS
types certainly prefer Rdb. Oracle Classic on VMS is a niche market and
I can't see any new customers coming to VMS because of that. At best
one could keep the few existing ones, at enormous cost.

As for web browsers, what is the difference between a server and a
workstation, these days? Servers no longer have 20 serial ports. The
on-chip graphics is probably better than a graphics card on VAX, Alpha,
or Itanium, and would be sufficient for 99% of users.

Kerry Main (C.O.V.)

2020-11-13 02:09:37 UTC

-----Original Message-----
undress to reply via Info-vax
Sent: November-12-20 5:02 PM
Subject: Re: [Info-vax] Final Orace release on VMS.

Post by Arne VajhÃ¸j
VSI want to (and many hear agree with them) focus on servers.

But even so, Oracle Classic seems to be a non-starter. The fraction of

people

using it on VMS is very low anyway, and was never high, and VMS types
certainly prefer Rdb. Oracle Classic on VMS is a niche market and I can't

see

any new customers coming to VMS because of that. At best one could keep
the few existing ones, at enormous cost.
As for web browsers, what is the difference between a server and a
workstation, these days? Servers no longer have 20 serial ports. The

on-chip

graphics is probably better than a graphics card on VAX, Alpha, or

Itanium,

and would be sufficient for 99% of users.

Fwiw, I believe that the big (and very, very expensive) software makers like
Oracle, IBM, SAP are in for a few tough years ahead.

In the enterprise space, while the last 10 years was all about reducing IT
and hardware costs (x86 virtualization, DC consolidation etc.), the next
10+ years is going to be about reducing IT software costs.

Remember the old saying - "80% of the Enterprise Customers use only 20% of
the available features in high end databases like Oracle"?

More and more enterprise Customers are going to be looking for "good enough"
(but exponentially cheaper) DB solutions in the same way that Enterprise
Customers for last 10+ years switched from higher end hardware platforms
(SPARC, ALPHA, PA-RISC etc) because the alternative platforms (X86-64) were
not necessarily better, but rather "good enough", and much cheaper.

Rdb on OpenVMS X86-64 is great news.

However, in future, my $.02 is that VSI is better to create a better and
more competitive platform for alternative App/DB solutions than to spend
significant resources chasing after Oracle Classic.

Kerry

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

Dave Froble

2020-11-13 04:53:16 UTC

Post by Kerry Main (C.O.V.)
Fwiw, I believe that the big (and very, very expensive) software makers like
Oracle, IBM, SAP are in for a few tough years ahead.

Maybe, but some customers like the perceived security blanket.

IBM hasn't been counted out yet, even though some have predicted it many
times.

Post by Kerry Main (C.O.V.)
In the enterprise space, while the last 10 years was all about reducing IT
and hardware costs (x86 virtualization, DC consolidation etc.), the next
10+ years is going to be about reducing IT software costs.
Remember the old saying - "80% of the Enterprise Customers use only 20% of
the available features in high end databases like Oracle"?
More and more enterprise Customers are going to be looking for "good enough"
(but exponentially cheaper) DB solutions in the same way that Enterprise
Customers for last 10+ years switched from higher end hardware platforms
(SPARC, ALPHA, PA-RISC etc) because the alternative platforms (X86-64) were
not necessarily better, but rather "good enough", and much cheaper.
Rdb on OpenVMS X86-64 is great news.
However, in future, my $.02 is that VSI is better to create a better and
more competitive platform for alternative App/DB solutions than to spend
significant resources chasing after Oracle Classic.

I'd think that VSI would do well to have some database products
associated with VMS. I doubt they have the people to do much work on
such, but, just an "approved by VSI" could be helpful.

Which in at least one case gets back to the numeric range locking.

--
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-13 14:08:26 UTC

Post by Kerry Main (C.O.V.)
Rdb on OpenVMS X86-64 is great news.
However, in future, my $.02 is that VSI is better to create a better and
more competitive platform for alternative App/DB solutions than to spend
significant resources chasing after Oracle Classic.

I'd think that VSI would do well to have some database products
associated with VMS. I doubt they have the people to do much work on
such, but, just an "approved by VSI" could be helpful.
Which in at least one case gets back to the numeric range locking.

There are other databases than PostgreSQL.

Besides Rdb then MySQL/MariaDB, SQLite, Mimer, HSQLDB, H2 and Derby
all run on VMS today.

That is a very different bunch of databases, so all of them would
not be applicable to all cases, but one or more of them should be
applicable for most cases.

Arne

Phillip Helbig (undress to reply)

2020-11-13 06:45:14 UTC

Post by Dave Froble
I'd think that VSI would do well to have some database products
associated with VMS. I doubt they have the people to do much work on
such, but, just an "approved by VSI" could be helpful.

If they are developed for VMS, it would be too much work. If they are
VMS ports from elsewhere, someone will have to make sure that VMS
changes get rolled back into the main distribution---probably also too
much work, especially because some of the RMS disciples involved might
not look favourably on supporting VMS which, in the words of VMS, is a
crime against humanity. (Yes, he really used those words, not in
connection with VMS specifically, but in connection with proprietary
software in general.)

I think that both VMS and Rdb could benefit from some sort of license
which would be available to non-hobbyists and non-developers but at an
affordable price point, but set up so that it can't be (ab)used by
people paying the current, much more expensive, license prices. There
are more than a few folks with VMS experience, and some small companies
might want to use VMS and perhaps Rdb, but if they can't even do a trial
run in production without paying license prices which might exceed
their entire revenue, then they won't even consider VMS (and Rdb).

Note that I am not talking about development, for which there are
solutions. However, who will develop something if he knows that in
order to run it in production orders of magnitude more money must be
paid for licenses?

Maybe have a license with a really low cost which expires after a year.
If the same person/company wants to renew it, then the normal price
applies unless they demonstrate that their profit is less than, say, 5
times the license price, in which case they pay the really low fee or,
say, 10 per cent of their profit, whichever is higher.

Arne Vajhøj

2020-11-13 14:04:28 UTC

Post by Kerry Main (C.O.V.)
Fwiw, I believe that the big (and very, very expensive) software makers like
Oracle, IBM, SAP are in for a few tough years ahead.
In the enterprise space, while the last 10 years was all about reducing IT
and hardware costs (x86 virtualization, DC consolidation etc.), the next
10+ years is going to be about reducing IT software costs.

That trend has already existed from several years.

The market share of expensive OS, app servers software, database server
software has dropped sharply. Free open source and low cost commercial
software based on open source has exploded.

But so far Oracle has done OK.The majority goes for the low cost
solutions. Many of Oracle's competitors has gone or are struggling.
But Oracle seems to have a big enough part of the high end market to
still make their numbers.

IBM has sort of prepared for the new world by buying Redhat.

Post by Kerry Main (C.O.V.)
More and more enterprise Customers are going to be looking for "good enough"
(but exponentially cheaper) DB solutions in the same way that Enterprise
Customers for last 10+ years switched from higher end hardware platforms
(SPARC, ALPHA, PA-RISC etc) because the alternative platforms (X86-64) were
not necessarily better, but rather "good enough", and much cheaper.

In the database market MySQL/MariaDB and PostgreSQL are doing
very well.

So are the NoSQL databases.

VMS customers are not known for jumping the latest.

:-)

But some low cost options for new VMS customers could be a very
good thing long term.

Arne

Phillip Helbig (undress to reply)

2020-11-13 06:37:14 UTC

Post by Arne VajhÃ¸j
VSI want to (and many hear agree with them) focus on servers.

But even so, Oracle Classic seems to be a non-starter.

Rdb on OpenVMS X86-64 is great news.
However, in future, my $.02 is that VSI is better to create a better and
more competitive platform for alternative App/DB solutions than to spend
significant resources chasing after Oracle Classic.

I agree; I can't see Oracle Classic worth the time, effort, and money.
Oracle Rdb, on the other hand, is essential.

Bill Gunshannon

2020-11-13 12:51:54 UTC

Post by Arne VajhÃ¸j
VSI want to (and many hear agree with them) focus on servers.

But even so, Oracle Classic seems to be a non-starter.

I agree; I can't see Oracle Classic worth the time, effort, and money.
Oracle Rdb, on the other hand, is essential.

Personally, I think there should be a strong move towards
PostgreSQL. A quick look at the Wiki Database Comparison
page shows it easily exceeds the capabilities of Oracle.
Sadly, Rdb is not included in the chart. it would be very
interesting to see just how it compares to other database
systems.

bill

Arne Vajhøj

2020-11-13 18:36:13 UTC

Post by Arne VajhÃ¸j
VSI want to (and many hear agree with them) focus on servers.

But even so, Oracle Classic seems to be a non-starter.

I agree; I can't see Oracle Classic worth the time, effort, and money.
Oracle Rdb, on the other hand, is essential.

PostgreSQL is a pretty nice database. But there are already
alternatives running on VMS.

1-2 years ago I asked some questions about Rdb capabilities
and as I remember Jan-Erik's answers then Rdb had everything
except the more "exotic" features.

Arne

Bill Gunshannon

2020-11-13 18:44:39 UTC

Post by Arne VajhÃ¸j
VSI want to (and many hear agree with them) focus on servers.

But even so, Oracle Classic seems to be a non-starter.

I agree; I can't see Oracle Classic worth the time, effort, and money.
Oracle Rdb, on the other hand, is essential.

PostgreSQL is a pretty nice database. But there are already
alternatives running on VMS.
1-2 years ago I asked some questions about Rdb capabilities
and as I remember Jan-Erik's answers then Rdb had everything
except the more "exotic" features.

So, why doesn't someone who knows Rdb well add it to the Wiki?
WOuld be interesting and free advertising for VMS as ther is a
column on the OS section for it.

I notice that SQLite has a "NO" under OpenVMS. Isn't that wrong?

bill

Arne Vajhøj

2020-11-13 18:53:06 UTC

Post by Arne VajhÃ¸j
VSI want to (and many hear agree with them) focus on servers.

But even so, Oracle Classic seems to be a non-starter.

I agree; I can't see Oracle Classic worth the time, effort, and money.
Oracle Rdb, on the other hand, is essential.

PostgreSQL is a pretty nice database. But there are already
alternatives running on VMS.
1-2 years ago I asked some questions about Rdb capabilities
and as I remember Jan-Erik's answers then Rdb had everything
except the more "exotic" features.

So, why doesn't someone who knows Rdb well add it to the Wiki?
WOuld be interesting and free advertising for VMS as ther is a
column on the OS section for it.
I notice that SQLite has a "NO" under OpenVMS. Isn't that wrong?

Yes.

It runs on VMS.

https://sourceforge.net/projects/vms-ports/files/SQLITE3/

( and for JDBC http://www.vms2linux.de/sqlitejdbc.html )

Arne

Phillip Helbig (undress to reply)

2020-11-13 12:55:00 UTC

Post by Bill Gunshannon
Personally, I think there should be a strong move towards
PostgreSQL. A quick look at the Wiki Database Comparison
page shows it easily exceeds the capabilities of Oracle.
Sadly, Rdb is not included in the chart. it would be very
interesting to see just how it compares to other database
systems.

I have quite a bit of experience with Rdb and a bit with PostgreSQL.
I'm pretty sure that Rdb can do more, and is almost certainly easier to
use for VMS folks and probably more efficient as well. Rdb is written
in BLISS who know the VMS internals and data structures and I doubt that
any port which is intended to remain part of some official distribution
could even remotely compete.

Wasn't there PostGress on VMS a while back?

Chris Townley

2020-11-13 13:27:09 UTC

That was the earlier one - Ingres (ISTR origiannly RTI?) However CA
completely lost it - I think there is a stil a half-hearted open source
version, Not sure if it still covers VMS.

It seems there is a commercial version from Actian - not sure wherew the
open source version went...

I used Ingres for a few years - not bad, but we were then stuck on Vax,
so performance was pretty carp

Chris

Scott Dorsey

2020-11-14 19:46:34 UTC

Post by Phillip Helbig (undress to reply)
But even so, Oracle Classic seems to be a non-starter. The fraction of
people using it on VMS is very low anyway, and was never high, and VMS
types certainly prefer Rdb. Oracle Classic on VMS is a niche market and
I can't see any new customers coming to VMS because of that. At best
one could keep the few existing ones, at enormous cost.

Oracle Classic is a huge market. Oracle Classic on VMS is a miniscule
market, but a good opportunity for expansion.

I was hoping that by this point in the cycle VSI would be a bit farther
along and that it might be time to start thinking about opportunities
for expansion, but it really isn't yet.

This is a shame, and it looks like the boat has been missed, but that is
how life is sometimes.

Post by Phillip Helbig (undress to reply)
As for web browsers, what is the difference between a server and a
workstation, these days? Servers no longer have 20 serial ports. The
on-chip graphics is probably better than a graphics card on VAX, Alpha,
or Itanium, and would be sufficient for 99% of users.

When I install Red Hat on a server, the web browser is one of the first
things I remove, after gnome, networkmanager, modem manager, avahi, and
another load of unnecessary crap. It's one more thing that exists only
to require patching.
--scott

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

Phillip Helbig (undress to reply)

2020-11-14 21:49:48 UTC

Oracle Classic is a huge market. Oracle Classic on VMS is a miniscule
market,

Right.

Post by Scott Dorsey
but a good opportunity for expansion.

How? Get VMS users to move to Oracle Classic? Those using a database
are probably using Rdb. Get Oracle Classic Users to move to VMS? Why?
What would that bring to them? Rdb works so well on VMS because it
makes use of native VMS features (the DLM and so on). If the database
itself works in failover mode, why does one need a cluster? And so on.
Face it, folks: drumming up support for Oracle Classic on VMS is less
likely to succeed than my dream of a modern web browser. :-|

Simon Clubley

2020-11-13 13:21:31 UTC

Post by Phillip Helbig (undress to reply)
I find it strange that people are pushing Oracle Classic on VMS as a way
to more users, but discount my suggestion of a modern web browser. :-|

In the real world Phillip, no-one cares about a modern web browser
on VMS these days - there's simply no market for it, especially if
the effort involved is more than a simple mostly automated compile
and link of the source code.

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-13 14:11:32 UTC

Post by Phillip Helbig (undress to reply)
I find it strange that people are pushing Oracle Classic on VMS as a way
to more users, but discount my suggestion of a modern web browser. :-|

Yep.

And browsers are bloody huge code wise today.

Like 20-25 million lines of code.

Arne

Phillip Helbig (undress to reply)

2020-11-13 16:01:51 UTC

Post by Phillip Helbig (undress to reply)
I find it strange that people are pushing Oracle Classic on VMS as a way
to more users, but discount my suggestion of a modern web browser. :-|

My guess is that the number who would like Oracle Classic on VMS is much
smaller. Can you point to even one person?

Jan-Erik Söderholm

2020-11-13 16:12:40 UTC

Post by Phillip Helbig (undress to reply)
I find it strange that people are pushing Oracle Classic on VMS as a way
to more users, but discount my suggestion of a modern web browser. :-|

My guess is that the number who would like Oracle Classic on VMS is much
smaller. Can you point to even one person?

I'v got a private message (and I think it was mentioned in the event
yesterday from France) that at least two custerers in France have said
that they will leave VMS due to Oracle "Classic" leaving VMS.

Note that this now also includes the Oracle client, that was earlier
said to be kept on VMS.

I have not heard anyone leaving VMS due to the lack of a browser.

Has anyone requested a browser? I mean, any paying customer?

Marc Van Dyck

2020-11-13 17:09:16 UTC

Post by Phillip Helbig (undress to reply)
My guess is that the number who would like Oracle Classic on VMS is much
smaller. Can you point to even one person?

I'm one of them. Without the Oracle Client, OpenVMS where I work
is dead. Fortunately I'll be retired before that. But VSI can write
off 25 systems that will never be migrated to X86.

--
Marc Van Dyck

Arne Vajhøj

2020-11-13 18:32:02 UTC

Post by Phillip Helbig (undress to reply)
My guess is that the number who would like Oracle Classic on VMS is much
smaller. Can you point to even one person?

I'm one of them. Without the Oracle Client, OpenVMS where I work
is dead. Fortunately I'll be retired before that. But VSI can write
off 25 systems that will never be migrated to X86.

How is Oracle policy regarding client version vs server version?
Does server version N require client version N or do they support
client N-1 to N or N-2 to N or?

Do you need supported client library?

Arne

John Dallman

2020-11-13 19:09:00 UTC

Post by Arne VajhÃ¸j
How is Oracle policy regarding client version vs server version?
Does server version N require client version N or do they support
client N-1 to N or N-2 to N or?

There is significant cross-version compatibility, but you need an Oracle
support contract to get all the details. Here's a version from a couple
of years ago:

<https://oraclefact.wordpress.com/2018/04/05/client-server-interoperabilit
y-support-matrix-for-different-oracle-versions-doc-id-207303-1/>

John

Shael Richmond

2020-11-13 22:30:59 UTC

Post by Phillip Helbig (undress to reply)
My guess is that the number who would like Oracle Classic on VMS is much
smaller. Can you point to even one person?

I'm one of them. Without the Oracle Client, OpenVMS where I work
is dead. Fortunately I'll be retired before that. But VSI can write
off 25 systems that will never be migrated to X86.

Normally the client can talk to n+2.

We have tested both 10.2.0.4 and 11.2.0.4 VMS clients with Oracle 19c and it connects fine. 10g is not officially supported but will work for us until those servers get refreshed with 11g clients. The response I got from Oracle is that we are stuck on the server side at 19c, but that it is a long term version.

We are planning on moving away from OpenVMS but had the x86 version as a fallback in case the replacement application took even longer than expected. Now that is not an option. Hardware support becomes the issue for us.

Shael Richmond
International Paper

Jan-Erik Söderholm

2020-11-13 23:13:31 UTC

Post by Phillip Helbig (undress to reply)
My guess is that the number who would like Oracle Classic on VMS is much
smaller. Can you point to even one person?

I'm one of them. Without the Oracle Client, OpenVMS where I work
is dead. Fortunately I'll be retired before that. But VSI can write
off 25 systems that will never be migrated to X86.

As I understood, the current 11g client kit on VMS will work
(in a supported way) against 188g or 19g on another platform.

Marc Van Dyck

2020-11-14 11:27:18 UTC

Post by Phillip Helbig (undress to reply)
My guess is that the number who would like Oracle Classic on VMS is much
smaller. Can you point to even one person?

I'm one of them. Without the Oracle Client, OpenVMS where I work
is dead. Fortunately I'll be retired before that. But VSI can write
off 25 systems that will never be migrated to X86.

I saw many questions, I'll try to answer them all here.

We are on 11 with the client on OpenVMS and on 12 with the databases
on dedicated Linux servers. Now those servers can migrate to 19 and
compatibility is ensured. But :

- Oracle support for 11 will end in 2022 and we are a regulated
industry
which implies mandatory support for software products. A waiver for a
year or two can be possible, but not more than that;

- Oracle roadmap says end of support for 19 will be in 2027;

- And no client on X86 means that we'll stay on Itanium in any case,
which means 2025 unless promises by HPE to extend the support beyond
that materializes.

Databases run on dedicated servers and are accessed by a lot of
different application systems, running on HP-UX, AIX, Solaris, Linux,
Windows... and VMS.

This diversity is caused by the fact that our company is the result of
a
series of mergers from which we inherited radically different IT
strategies.

Manpower and budget to harmonize all that simply did not exist, and so
we focused on easy gains first, and VMS was not one of them : we have
more than 30 years of continuous application software development
running on those platforms. ACMS, DECforms, FMS, lots of RMS indexed
files, you name it... Last time a migration was estimated, it arrived
at
more than 200 man.years of work.

Migrating, over time, all data to Oracle was one of our most successful
consolidations strategies, and I do not see us abandoning that
direction
any time soon, and certainly not for preserving the OpenVMS platform
which is already seen as a peeble in their shoe by many of our
managers.
So yes, the Oracle support is definitely political, while the survival
of VMS, until now, is more the result of a cost-based decision.

I already had no doubt that OpenVMS would finally disappear from our
IT landscape, but was secretely hoping that the X86 migration would
re-vitalize it a bit, and give it some 10 more years of existence.
Bummer...

And, while I'm at it, VMS on the desktop has never been a thing in this
company, only my team of system managers ever had it (XP900, then
RX2600). All other people accessing VMS hosts do it from Windows
desktops, and this till the end of VT terminals. Most of the work done
by our VMS hosts is batch oriented.

--
Marc Van Dyck

Dave Froble

2020-11-13 18:39:01 UTC

Post by Marc Van Dyck
I'm one of them. Without the Oracle Client, OpenVMS where I work
is dead. Fortunately I'll be retired before that. But VSI can write
off 25 systems that will never be migrated to X86.

Is this worth a discussion? If so, perhaps a new "subject"?

Not about the issue directly, but I do have some questions/curiosity.

I'm assuming you're using the Oracle client on VMS. Is this correct?

If so, then there is non-VMS in use, most likely heavy usage, and I'd
wonder why VMS is still in use at all? Perhaps there is some app(s) on
VMS that it is hard or impossible to implement/easily find on non-VMS?

For some reason you're still running some apps on VMS. Why?

Then the questions turn to, what is more essential, those apps on VMS,
or continuing to use Oracle Classic client?

I'd also expect that there might be political issues, on both sides,
such as some people who demand to use Oracle Classic, and those who
demand to continue using the apps on VMS.

My perceptions for some time now have been that if someone is still
using VMS, considering all the recent (20 yrs) of struggle to use VMS,
then there is some really strong reason to have done so. And if that is
so, then it's going to be no easier to move to something else now than
it's been over the last 20 or so years.

As I may have mentioned, I'm curious, as to how others are approaching
such difficult issues. Other than the "I'll be retired" option of
course. And regardless, it will be someone's problem, regardless.

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

Phillip Helbig (undress to reply)

2020-11-13 19:30:39 UTC

Post by Phillip Helbig (undress to reply)
My guess is that the number who would like Oracle Classic on VMS is much
smaller. Can you point to even one person?

I'm one of them. Without the Oracle Client, OpenVMS where I work
is dead. Fortunately I'll be retired before that. But VSI can write
off 25 systems that will never be migrated to X86.

Blame the "VMS is for servers" crowd who forgot "desktop to datacenter".
:-|

Simon Clubley

2020-11-13 19:33:25 UTC

Post by Phillip Helbig (undress to reply)
Blame the "VMS is for servers" crowd who forgot "desktop to datacenter".
:-|

Well, that's a load of nonsense. This is about one server performing
a role by talking to another server that's performing a different role.

Running VMS on the desktop has nothing to do with this.

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-13 19:34:32 UTC

Post by Phillip Helbig (undress to reply)
My guess is that the number who would like Oracle Classic on VMS is much
smaller. Can you point to even one person?

I'm one of them. Without the Oracle Client, OpenVMS where I work
is dead. Fortunately I'll be retired before that. But VSI can write
off 25 systems that will never be migrated to X86.

Blame the "VMS is for servers" crowd who forgot "desktop to datacenter".
:-|

Not really.

Oracle client is really a server thing not a desktop thing.

Having a desktop application making a direct connection to the
database has not been in fashion in the last 20 years.

And should probably not have been so in the 10 years preceding,
but ...

Arne

Phillip Helbig (undress to reply)

2020-11-13 19:55:40 UTC

Post by Phillip Helbig (undress to reply)
Blame the "VMS is for servers" crowd who forgot "desktop to datacenter".
:-|

Well, that's a load of nonsense. This is about one server performing
a role by talking to another server that's performing a different role.
Running VMS on the desktop has nothing to do with this.

Right. The question is client vs. server. You say that a server can be
a client. One can also run a server on the desktop---if one has a big
enough desk (which, these days, is a pretty low bar, since servers can
be quite small).

Phillip Helbig (undress to reply)

2020-11-13 19:58:17 UTC

Post by Arne VajhÃ¸j
Oracle client is really a server thing not a desktop thing.
Having a desktop application making a direct connection to the
database has not been in fashion in the last 20 years.
And should probably not have been so in the 10 years preceding,
but ...

The same terms are used for different things. With Rdb, there is no
client and server---your process interacts with the database. Similar
functionality on Oracle Classic involves a client/server model. And
many people connect to Rdb and other databases via ODBC or something
similar from a desktop machine.

Phillip Helbig (undress to reply)

2020-11-13 19:28:25 UTC

Post by Jan-Erik SÃ¶derholm
I'v got a private message (and I think it was mentioned in the event
yesterday from France) that at least two custerers in France have said
that they will leave VMS due to Oracle "Classic" leaving VMS.

How many worlwide? How many compared to Rdb?

Post by Jan-Erik SÃ¶derholm
I have not heard anyone leaving VMS due to the lack of a browser.
Has anyone requested a browser? I mean, any paying customer?

The thread was about attracting new customers to VMS. :-|

Simon Clubley

2020-11-13 19:30:51 UTC

Post by Jan-Erik SÃ¶derholm
I have not heard anyone leaving VMS due to the lack of a browser.
Has anyone requested a browser? I mean, any paying customer?

The thread was about attracting new customers to VMS. :-|

Think of VMS as more like z/OS. Do you run a web browser on z/OS ?

Simon.

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

Scott Dorsey

2020-11-14 20:23:49 UTC

Post by Jan-Erik SÃ¶derholm
I have not heard anyone leaving VMS due to the lack of a browser.
Has anyone requested a browser? I mean, any paying customer?

The thread was about attracting new customers to VMS. :-|

Think of VMS as more like z/OS. Do you run a web browser on z/OS ?

//GOOGLE EXEC PGM=MOZILLA,NAME=HTTP://WWW.GOOGLE.COM

--scott

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

Phillip Helbig (undress to reply)

2020-11-13 19:53:37 UTC

Post by Jan-Erik SÃ¶derholm
I have not heard anyone leaving VMS due to the lack of a browser.
Has anyone requested a browser? I mean, any paying customer?

The thread was about attracting new customers to VMS. :-|

Think of VMS as more like z/OS. Do you run a web browser on z/OS ?

I don't run z/OS at all. But why should I think of VMS as more like
z/OS? I do run a web browser on VMS, because it is more convenient than
running one elsewhere for many things. What I miss is some
functionality. There was a time when VMS did have reasonably modern
web browsers. Of course, if you've never run a web browser on VMS, you
don't know what you are missing.

Marc Van Dyck

2020-11-14 11:25:52 UTC

On 2020-11-13, Phillip Helbig (undress to reply)

Post by Jan-Erik SÃ¶derholm
I have not heard anyone leaving VMS due to the lack of a browser.
Has anyone requested a browser? I mean, any paying customer?

The thread was about attracting new customers to VMS. :-|

Think of VMS as more like z/OS. Do you run a web browser on z/OS ?

If I wanted to run a VMS-based web browser on my desktop, I would just
run any of the many Xwindows emulation packages available on the market
(mind you, Excursion still works on Windows 7, I use it) and fire the
browser from any of my datacenter VMS systems with display on my desk.
So that capability still exists if you really need it.

--
Marc Van Dyck

Phillip Helbig (undress to reply)

2020-11-14 11:53:14 UTC

Post by Marc Van Dyck
If I wanted to run a VMS-based web browser on my desktop, I would just
run any of the many Xwindows emulation packages available on the market
(mind you, Excursion still works on Windows 7, I use it) and fire the
browser from any of my datacenter VMS systems with display on my desk.

So your desk is not VMS but the browser is running on a VMS server? If
so, which browser?

Post by Marc Van Dyck
So that capability still exists if you really need it.

I don't follow you. I want to be able to directly download from the web
to VMS and upload from VMS to the web. I want to type on my LK411 when
typing something in a web form. And so on.

Jan-Erik Söderholm

2020-11-14 15:21:55 UTC

So your desk is not VMS but the browser is running on a VMS server? If
so, which browser?

I think he was just speculating around a hypotetical setup. No one would
run the browser on VMS in real life, of course.

Post by Marc Van Dyck
So that capability still exists if you really need it.

I don't follow you. I want to be able to directly download from the web
to VMS and upload from VMS to the web.

There are several non-browser tools to automate that, if you need.

For tasks like patch download and similar it is much easier to use
a browser on a standard desktop environment and then transfer the
patch files using any file transfer tool, usually FTP based.

Read my lips, there will *never* be a "modern" browser running on VMS
servers having features up to date with browsers on desktop systems.

Post by Phillip Helbig (undress to reply)
I want to type on my LK411 when typing something in a web form.

To this I can just say, "no comment".

John Dallman

2020-11-14 19:36:00 UTC

Post by Jan-Erik SÃ¶derholm
Read my lips, there will *never* be a "modern" browser running on
VMS servers having features up to date with browsers on desktop

systems.

Is there some fundamental impossibility to porting Chromium or Firefox?
Or do you simply reckon nobody will go to sufficient effort?

John

John Reagan

2020-11-14 20:56:23 UTC

Post by Jan-Erik SÃ¶derholm
Read my lips, there will *never* be a "modern" browser running on
VMS servers having features up to date with browsers on desktop

systems.
Is there some fundamental impossibility to porting Chromium or Firefox?
Or do you simply reckon nobody will go to sufficient effort?
John

Firefox has large pieces of Rust.

I'll guess that both C++ used by both Rust and Chromium wouldn't get through the Alpha or Itanium C++ compilers.

I suppose you can build them on Linux try to move objects over but that has all sorts of issues with headers, RTL name prefixing, calling convention differences (VMS wants an arg-count).

And all of that is before you have to deal with whatever libraries are used Xorg, GTK+, GDK, and the latest X11.

Phillip Helbig (undress to reply)

2020-11-14 21:46:20 UTC

Post by Jan-Erik SÃ¶derholm
Read my lips, there will *never* be a "modern" browser running on
VMS servers having features up to date with browsers on desktop

systems.
Is there some fundamental impossibility to porting Chromium or Firefox?

Anything which runs on one Turing machine can run on another. :-)

Post by Scott Dorsey
Or do you simply reckon nobody will go to sufficient effort?

The latter.

Phillip Helbig (undress to reply)

2020-11-14 18:39:35 UTC

So your desk is not VMS but the browser is running on a VMS server? If
so, which browser?

I think he was just speculating around a hypotetical setup. No one would
run the browser on VMS in real life, of course.

It seems a strange sort of speculation, though, since it is much easier
to have a graphics monitor directly on VMS than to have a web browser
running on VMS.

Post by Jan-Erik SÃ¶derholm
There are several non-browser tools to automate that, if you need.
For tasks like patch download and similar it is much easier to use
a browser on a standard desktop environment and then transfer the
patch files using any file transfer tool, usually FTP based.

I don't get it. My way, it goes directly. Your way, there is an extra
step. How can that be easier?

Post by Jan-Erik SÃ¶derholm
Read my lips, there will *never* be a "modern" browser running on VMS
servers having features up to date with browsers on desktop systems.

I remember when people said that VMS would never, ever run on x86. :-)

Phillip Helbig (undress to reply)

2020-11-14 11:55:11 UTC

So your desk is not VMS but the browser is running on a VMS server? If
so, which browser?

Post by Marc Van Dyck
So that capability still exists if you really need it.

I don't follow you. I want to be able to directly download from the web
to VMS and upload from VMS to the web. I want to type on my LK411 when
typing something in a web form. And so on.

Yes, that would work, but a) there is no modern browser which runs on
VMS and b) I can have the display on VMS as VSI has said that on-chip
graphics will be supported, which is more than sufficient for my needs.

John Dallman

2020-11-12 16:52:00 UTC

Post by Arne VajhÃ¸j
1) Oracle may be difficult to persuade to change strategy (they are
a huge company and VSI is a small company).

The things that I reckon are likely to convince them are (a) plenty of
paying customers for Rdb on VMS, which will show them that VMS is
thriving, and (b) Rdb customers wanting Oracle DB. The latter seems
counter-intuitive, but Rdb customers have demonstrated to Oracle that
they have money to spend, and that's even more important to Oracle that
to most companies.

John

Simon Clubley

2020-10-27 13:33:04 UTC

Not good.

I thought VSI were talking to Oracle to stop things like this from
happening ? :-(

Given that normal Oracle is now history on VMS, the question becomes
is anything negative going to happen to Rdb over the next 2-3 years ?

At the moment, for how many years in the future have Oracle _guaranteed_
that Rdb will be supported on VMS, including x86-64 ?

I would guess that a minimum of 5 years guaranteed support for Rdb at
an absolute minimum is going to be required in order for people to
continue being comfortable investing in Rdb based applications and
investing in buying new machines to support them.

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-10-27 13:46:55 UTC

Not good.

I thought VSI were talking to Oracle to stop things like this from
happening ? :-(

This is in line with that Oracle has said for many years. The server
part will leave VMS but you can still use the client part to build
VMS application that runs against an Oracle database server.

Post by Simon Clubley
Given that normal Oracle is now history on VMS, the question becomes
is anything negative going to happen to Rdb over the next 2-3 years ?

Don't think so. Rdb has nothing to do with the current Oracle letter.

Post by Simon Clubley
At the moment, for how many years in the future have Oracle _guaranteed_
that Rdb will be supported on VMS, including x86-64 ?

Has Oracle ever _guaranteed_ anything?

Post by Simon Clubley
I would guess that a minimum of 5 years guaranteed support for Rdb at
an absolute minimum is going to be required in order for people to
continue being comfortable investing in Rdb based applications and
investing in buying new machines to support them.
Simon.

It is quite different situations. Oracle "classic" has to be ported to
VMS for each update. Rdb has its primary (and only) code base on VMS.

But if you really are in need for an answer, ask Oracle.

Arne Vajhøj

2020-10-27 14:00:25 UTC

Not good.

I thought VSI were talking to Oracle to stop things like this from
happening ? :-(

This is in line with that Oracle has said for many years. The server
part will leave VMS but you can still use the client part to build
VMS application that runs against an Oracle database server.

Does Oracle DB (Oracle classic) share network protocols with
Oracle Rdb?

I seem to remember that somebody at some time said that Rdb SQL Services
borrowed lots of code from Oracle DB (Oracle classic).

Arne

Jan-Erik Söderholm

2020-10-27 14:24:47 UTC

Not good.

I thought VSI were talking to Oracle to stop things like this from
happening ? :-(

This is in line with that Oracle has said for many years. The server
part will leave VMS but you can still use the client part to build
VMS application that runs against an Oracle database server.

Does Oracle DB (Oracle classic) share network protocols with
Oracle Rdb?
I seem to remember that somebody at some time said that Rdb SQL Services
borrowed lots of code from Oracle DB (Oracle classic).
Arne

Probaly from

Probaly from SQL*Net in that case.

Rdb <-> Oracle Classic
SQL/Services <-> SQL*Net

Basic SQL/Services has its own protocol, but there is also an OCI
option for SQL/Services that uses the Oracle SQL*Net protocol. That
makes an Rdb database to look like an Oracle Classic DB form a client.

Shael Richmond

2020-10-27 16:13:30 UTC

I verified with Oracle - this applies to both the client and the database on OpenVMS. 11.2.0.4 is certified to connect to 19c databases but may not connect to anything newer.

This was a bit of a surprise because I thought the 12c migration was pretty far along.

No port of any kind for x86 OpenVMS.

Shael Richmond
International Paper

Jan-Erik Söderholm

2020-10-27 17:48:55 UTC

Post by Shael Richmond
I verified with Oracle - this applies to both the client and the database on OpenVMS. 11.2.0.4 is certified to connect to 19c databases but may not connect to anything newer.
This was a bit of a surprise because I thought the 12c migration was pretty far along.
No port of any kind for x86 OpenVMS.
Shael Richmond
International Paper

Yes, that is weird. The client API code should not be that complicated.
At least the older SQL*net client kist wasn't...

Simon Clubley

2020-10-27 18:33:17 UTC

So no Ada users for x86-64 VMS and now no Oracle users other than Rdb either.

I think it's now reasonable to ask if Rdb will still be available for
x86-64 VMS in 5 years from now.

Given previous comments about how many people still use Rdb, I would
hope that VSI have got a clear agreement from Oracle to continue Rdb
support on VMS for a number of years. I couldn't see anything on their
website however.

Post by Shael Richmond
Shael Richmond
International Paper

Yes, that is weird. The client API code should not be that complicated.
At least the older SQL*net client kist wasn't...

If that's the case, why do you think Oracle have dropped the client ?

Simon.

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

Simon Clubley

2020-10-27 19:00:07 UTC

So no Ada users for x86-64 VMS and now no Oracle users other than Rdb either.
I think it's now reasonable to ask if Rdb will still be available for
x86-64 VMS in 5 years from now.
Given previous comments about how many people still use Rdb, I would
hope that VSI have got a clear agreement from Oracle to continue Rdb
support on VMS for a number of years. I couldn't see anything on their
website however.

Just to make this more clear, what I am asking here is if Oracle have
legally committed to port Rdb to x86-64 VMS and to support it on
x86-64 VMS for their normal full 5 years of mainstream support.

Having Rdb on Itanium is not much good if everyone wants to move
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.

Arne Vajhøj

2020-10-27 20:54:18 UTC

So no Ada users for x86-64 VMS and now no Oracle users other than Rdb either.
I think it's now reasonable to ask if Rdb will still be available for
x86-64 VMS in 5 years from now.
Given previous comments about how many people still use Rdb, I would
hope that VSI have got a clear agreement from Oracle to continue Rdb
support on VMS for a number of years. I couldn't see anything on their
website however.

Just to make this more clear, what I am asking here is if Oracle have
legally committed to port Rdb to x86-64 VMS and to support it on
x86-64 VMS for their normal full 5 years of mainstream support.

I suspect Oracle is a bit reluctant to legally commit to
anything in this area given the history.

Arne

Dave Froble

2020-10-28 22:55:18 UTC

So no Ada users for x86-64 VMS and now no Oracle users other than Rdb either.
I think it's now reasonable to ask if Rdb will still be available for
x86-64 VMS in 5 years from now.

Vendor: if you buy it, we will sell it
Vendor: if no one buys it, we won't be here

That's sort of the bottom line in business.

Post by Simon Clubley
Given previous comments about how many people still use Rdb, I would
hope that VSI have got a clear agreement from Oracle to continue Rdb
support on VMS for a number of years. I couldn't see anything on their
website however.

People on this venue keep speculating about the use of Rdb, many times
based upon their own experience. A rather poor method of guessing.

The people who might know aren't saying.

Even the circumstances are rather vague. For total VMS systems, is it
just those with support? I doubt anyone can come up with a valid number
for the total VMS systems in use.

Oracle has a better idea of their customers.

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

Richard Maher

2020-10-27 22:56:55 UTC

Post by Shael Richmond
I verified with Oracle - this applies to both the client and the
database on OpenVMS. 11.2.0.4 is certified to connect to 19c
databases but may not connect to anything newer.
This was a bit of a surprise because I thought the 12c migration was pretty far along.
No port of any kind for x86 OpenVMS.
Shael Richmond International Paper

Can no one to to Kevin Duffy about this? Has he retired?

Arne Vajhøj

2020-10-27 13:53:18 UTC

Not good.

I thought VSI were talking to Oracle to stop things like this from
happening ? :-(

VSI can talk - they cannot force Oracle to listen.

:-)

Post by Simon Clubley
Given that normal Oracle is now history on VMS, the question becomes
is anything negative going to happen to Rdb over the next 2-3 years ?

Very different business context.

But long term VMS support is a relevant question for any VMS product.

Arne

Simon Clubley

2020-10-27 18:40:36 UTC

Not good.

I thought VSI were talking to Oracle to stop things like this from
happening ? :-(

VSI can talk - they cannot force Oracle to listen.
:-)

Post by Simon Clubley
Given that normal Oracle is now history on VMS, the question becomes
is anything negative going to happen to Rdb over the next 2-3 years ?

Very different business context.

Given the news now reported here that the client has also now been
dropped, I wonder if Oracle are embarking on a period of product
consolidation towards mainstream platforms only.

I wonder if VSI have talked to Oracle about continuing support for the
client and if Oracle dropped support for it anyway.

Post by Arne VajhÃ¸j
But long term VMS support is a relevant question for any VMS product.

Yes it is, given the nature of the VMS world, and that makes it
reasonable to ask if there are guarantees about continuing support
for Rdb now that normal Oracle has been dropped on VMS.

Simon.

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

Chris Townley

2020-10-27 19:57:11 UTC

Not good.

I thought VSI were talking to Oracle to stop things like this from
happening ? :-(

VSI can talk - they cannot force Oracle to listen.
:-)

Post by Simon Clubley
Given that normal Oracle is now history on VMS, the question becomes
is anything negative going to happen to Rdb over the next 2-3 years ?

Very different business context.

Given the news now reported here that the client has also now been
dropped, I wonder if Oracle are embarking on a period of product
consolidation towards mainstream platforms only.
I wonder if VSI have talked to Oracle about continuing support for the
client and if Oracle dropped support for it anyway.

Post by Arne VajhÃ¸j
But long term VMS support is a relevant question for any VMS product.

Yes it is, given the nature of the VMS world, and that makes it
reasonable to ask if there are guarantees about continuing support
for Rdb now that normal Oracle has been dropped on VMS.
Simon.

I can understand dropping the server, but dropping the client amazes me,
and strikes me as rather short-sighted.

If I was developing anything new on VMS with oracle, my first thought
would be to host the DB on Linux, as my former company mostly did for a
while.

Chris

Bill Gunshannon

2020-10-28 00:21:36 UTC

Post by Chris Townley

Not good.

I thought VSI were talking to Oracle to stop things like this from
happening ? :-(

VSI can talk - they cannot force Oracle to listen.
:-)

Post by Simon Clubley
Given that normal Oracle is now history on VMS, the question becomes
is anything negative going to happen to Rdb over the next 2-3 years ?

Very different business context.

Given the news now reported here that the client has also now been
dropped, I wonder if Oracle are embarking on a period of product
consolidation towards mainstream platforms only.
I wonder if VSI have talked to Oracle about continuing support for the
client and if Oracle dropped support for it anyway.

Post by Arne VajhÃ¸j
But long term VMS support is a relevant question for any VMS product.

Yes it is, given the nature of the VMS world, and that makes it
reasonable to ask if there are guarantees about continuing support
for Rdb now that normal Oracle has been dropped on VMS.
Simon.

I can understand dropping the server, but dropping the client amazes me,
and strikes me as rather short-sighted.

Short-sighted on who's part? I expect they do not have much faith in
the long term continued existence of VMS.

bill

Arne Vajhøj

2020-10-28 13:51:52 UTC

Post by Chris Townley

Post by Simon Clubley
Given the news now reported here that the client has also now been
dropped, I wonder if Oracle are embarking on a period of product
consolidation towards mainstream platforms only.

I can understand dropping the server, but dropping the client amazes
me, and strikes me as rather short-sighted.

Short-sighted on who's part? I expect they do not have much faith in
the long term continued existence of VMS.

Or they do not expect to sell more Oracle licenses for other
platforms due to client libraries being available on VMS.
Zero revenue expected and some cost can be a tough sell.

Note that any numbers for interest for client libraries
for VMS may be artificial low, because AFAIK then they
are not available for free download - unlike for most other
platforms.

Arne

Arne Vajhøj

2020-10-28 14:44:05 UTC

Post by Chris Townley

I can understand dropping the server, but dropping the client amazes
me, and strikes me as rather short-sighted.

Short-sighted on who's part? I expect they do not have much faith in
the long term continued existence of VMS.

Or they do not expect to sell more Oracle licenses for other
platforms due to client libraries being available on VMS.
Zero revenue expected and some cost can be a tough sell.
Note that any numbers for interest for client libraries
for VMS may be artificial low, because AFAIK then they
are not available for free download - unlike for most other
platforms.

Of course the Oracle type 4 JDBC driver will still be available.

:-)

Arne

John Dallman

2020-10-27 20:34:00 UTC

Oracle are fairly aggressive about pruning platforms. They seem to be
giving up on Solaris, and I expect dropping VMS is part of the "At last
we can get rid of Itanium!" process they've been planning for years.
They'll have seen VMS as part of HP's Itanium portfolio for a long time,
and have been locked into supporting Itanium against their will since
2012.

https://en.wikipedia.org/wiki/Oracle_Corporation#HP_and_Oracle_lawsuit

I seriously doubt they are bothered about VMS on x86-64 at present. If it
becomes a significant market success, they'll be able to support it.

John

Simon Clubley

2020-10-28 13:21:32 UTC

Post by John Dallman
I seriously doubt they are bothered about VMS on x86-64 at present. If it
becomes a significant market success, they'll be able to support it.

The problem with that is the delay it causes before Rdb users can
move to x86-64 VMS. It also causes additional uncertainty about whether
people will wait around to see how things work out with x86-64 VMS or
whether they start a move elsewhere now.

For the people who continue to wait for x86-64 VMS to become production
ready, they will still need to see Rdb is working correctly on x86-64
before they trust their production data to it so that is at least an
extra year or so after release of x86-64 Rdb until people trust it enough.

It has been stated here that Rdb is still in heavy use on VMS and that
having it available on x86-64 VMS is required to make the port of VMS
to x86-64 viable. Do the people who made that statement still think
that is the case ?

Also, does anyone know at what point during the port of VMS to Itanium
did Rdb become available on Itanium ?

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-10-28 13:57:16 UTC

Post by John Dallman
I seriously doubt they are bothered about VMS on x86-64 at present. If it
becomes a significant market success, they'll be able to support it.

The problem with that is the delay it causes before Rdb users can
move to x86-64 VMS. It also causes additional uncertainty about whether
people will wait around to see how things work out with x86-64 VMS or
whether they start a move elsewhere now.
For the people who continue to wait for x86-64 VMS to become production
ready, they will still need to see Rdb is working correctly on x86-64
before they trust their production data to it so that is at least an
extra year or so after release of x86-64 Rdb until people trust it enough.
It has been stated here that Rdb is still in heavy use on VMS and that
having it available on x86-64 VMS is required to make the port of VMS
to x86-64 viable. Do the people who made that statement still think
that is the case ?

Yes, I still think so.

Post by Simon Clubley
Also, does anyone know at what point during the port of VMS to Itanium
did Rdb become available on Itanium ?

I have never had any VMS environment that was migrated to IA64, but I
cannot remember that there was any significant delay. As soon as there
was a bootable VMS/IA64, Oracle begun building Rdb for it using cross
compilers on Alpha. When compilers was avilable, they switch to native
builds of Rdb. Google for a powerpoint called "Porting Rdb to Itanium".

It would surprice me a lot if Oracle is not one of the partners that
are looking at V9 on x86 at the moment.

Post by Simon Clubley
Simon.

Simon Clubley

2020-10-28 18:20:19 UTC

Post by Simon Clubley
Also, does anyone know at what point during the port of VMS to Itanium
did Rdb become available on Itanium ?

Very, very interesting Jan-Erik. Thank you. That search came up with
a number of very interesting results.

Why can't Oracle and VSI publish something like this:

https://www.sciinc.com/remotedba/techinfo/articles/ui10a1.asp

Oracle had made a public commitment to port Rdb to Itanium, along with
detailed timelines, even before they had working Alpha-based cross-compilers
for Itanium!

Post by Jan-Erik SÃ¶derholm
It would surprice me a lot if Oracle is not one of the partners that
are looking at V9 on x86 at the moment.

Given what you have said, I would hope so, but I am surprised about
the lack of a public statement along the lines of the above statement
for Itanium.

BTW, the slides you mentioned above for the port to Itanium can be
found here:

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

Also very interesting.

Simon.

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

John Dallman

2020-10-28 19:43:00 UTC

Post by Simon Clubley
Oracle had made a public commitment to port Rdb to Itanium, along
with detailed timelines, even before they had working Alpha-based
cross-compilers for Itanium!

At the time, they were quite friendly with HP, and they were solidly
focused on databases.

Nowadays, cloud services are the hot thing within Oracle, and VMS is in
the hands of a small company, rather than HP. Oracle don't like HP, but
they have to take some notice of them.

John

Simon Clubley

2020-10-29 13:27:58 UTC

Post by John Dallman

Post by Simon Clubley
Oracle had made a public commitment to port Rdb to Itanium, along
with detailed timelines, even before they had working Alpha-based
cross-compilers for Itanium!

At the time, they were quite friendly with HP, and they were solidly
focused on databases.
Nowadays, cloud services are the hot thing within Oracle, and VMS is in
the hands of a small company, rather than HP. Oracle don't like HP, but
they have to take some notice of them.

In that case, it's even _more_ important for VSI to show that Rdb
will be ported to x86-64 VMS and to let _all_ customers, not only
the Rdb customers know that.

Simon.

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

John Dallman

2020-10-29 14:03:00 UTC

Post by Simon Clubley
In that case, it's even _more_ important for VSI to show that Rdb
will be ported to x86-64 VMS and to let _all_ customers, not only
the Rdb customers know that.

The hard part of that is getting Oracle to (a) do it and (b) announce a
commitment. After HP's lawsuit against them, they're going to be very
cautious about announcing commitments to something HP-connected,
especially since it's not core business for them.

They have good reason for this IMHO: the grounds on which the court held
that they'd committed to supporting HP-UX Itanium indefinitely seemed to
me to be stretching an informal commitment too far. My employers, who
provide back-end software components, which I port to new platforms, have
been very careful about making commitments since that case.

The things Oracle will see here are that the matter is Itanium-related
and HP-related, both of which they have bad experiences with. They aren't
interested in VMS as such, and won't see much advantage for themselves in
supporting Rdb on x86-64 VMS. "Why not use OracleDB on Linux?" will be
the obvious question from their point of view.

The most certain way to get Rdb on x86-64 VMS would be for VSI to make a
deal with Oracle like the one they have with HP for VMS: take over the
servicing and support, with the permission to port it to new platforms.

John

Robert A. Brooks

2020-10-29 14:41:59 UTC

Post by Simon Clubley
In that case, it's even _more_ important for VSI to show that Rdb
will be ported to x86-64 VMS and to let _all_ customers, not only
the Rdb customers know that.

We don't speak for Oracle; they don't speak for us.

--
-- Rob

Chris

2020-10-29 15:06:33 UTC

Post by Robert A. Brooks

Post by Simon Clubley
In that case, it's even _more_ important for VSI to show that Rdb
will be ported to x86-64 VMS and to let _all_ customers, not only
the Rdb customers know that.

We don't speak for Oracle; they don't speak for us.

Disappointing response and hardly likely to reassure customers. Not
really saying anything. Candour, trust and respect are everything,
right ?...

Chris

Arne Vajhøj

2020-10-29 15:23:33 UTC

Post by Chris

Post by Robert A. Brooks

Post by Simon Clubley
In that case, it's even _more_ important for VSI to show that Rdb
will be ported to x86-64 VMS and to let _all_ customers, not only
the Rdb customers know that.

We don't speak for Oracle; they don't speak for us.

Disappointing response and hardly likely to reassure customers. Not
really saying anything. Candour, trust and respect are everything,
right ?...

It may be disappointing to some.

But it is an obvious truth.

VSI cannot commit to anything on Oracle's behalf. And vice versa.

Arne

Phillip Helbig (undress to reply)

2020-10-28 13:57:25 UTC

Post by Simon Clubley
It has been stated here that Rdb is still in heavy use on VMS and that
having it available on x86-64 VMS is required to make the port of VMS
to x86-64 viable. Do the people who made that statement still think
that is the case ?

Probably "yes" to both.

I wouldn't be surprised if Rdb is already running on x86.

Simon Clubley

2020-10-28 18:23:42 UTC

Post by Phillip Helbig (undress to reply)
I wouldn't be surprised if Rdb is already running on x86.

If that had happened, I would have expected a major press release
from VSI by now. It would be a major step towards showing that VMS
is working on x86-64 VMS and would be excellent publicity for VSI.

Simon.

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

Dave Froble

2020-10-28 23:09:45 UTC

Post by Phillip Helbig (undress to reply)
I wouldn't be surprised if Rdb is already running on x86.

If that had happened, I would have expected a major press release
from VSI by now. It would be a major step towards showing that VMS
is working on x86-64 VMS and would be excellent publicity for VSI.

Your expectations might not be the expectations of others.

I didn't see VSI issuing any press releases when WASD was ported to x86
VMS. Nor was I looking, so perhaps such do exist.

Then there is the concept of waiting for the best time for such
information, when it will have the best effect.

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

Jan-Erik Söderholm

2020-10-28 23:29:07 UTC

On 2020-10-28, Phillip Helbig (undress to reply)

Post by Phillip Helbig (undress to reply)
I wouldn't be surprised if Rdb is already running on x86.

If that had happened, I would have expected a major press release
from VSI by now. It would be a major step towards showing that VMS
is working on x86-64 VMS and would be excellent publicity for VSI.

Your expectations might not be the expectations of others.

Or in touch with reality.

I'm not sure that VMS has all the bits needed to run Rdb yet.
I'm confident that there is a close contact between VSI and
the Rdb group at Oracle. No need to shout out about that.
And I think that any customer that relies on this combo have
made sure that they know very well what is happening.

If mr Clubley knows or doesn't know is irrelevant, if he isn't a major
Rdb customer. But if he is, he would know.

Post by Dave Froble
I didn't see VSI issuing any press releases when WASD was ported to x86
VMS. Nor was I looking, so perhaps such do exist.

No, it doesn't. WASD is "just" a third part open source "thing" that
doesn't generate any income for VSI or anyone else. Not much to
shout about.

Post by Dave Froble
Then there is the concept of waiting for the best time for such
information, when it will have the best effect.

Dave Froble

2020-10-28 23:42:58 UTC

Post by Jan-Erik SÃ¶derholm
No, it doesn't. WASD is "just" a third part open source "thing" that
doesn't generate any income for VSI or anyone else. Not much to
shout about.

I don't think I agree with that. According to Mark, the port was rather
simple. For VSI, being able to show users who had an easy time of
porting would be a good thing. The profitability of the specific
product really isn't important, in this context.

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

Jan-Erik Söderholm

2020-10-28 23:46:37 UTC

Post by Jan-Erik SÃ¶derholm
No, it doesn't. WASD is "just" a third part open source "thing" that
doesn't generate any income for VSI or anyone else. Not much to
shout about.

I don't think I agree with that. According to Mark, the port was rather
simple. For VSI, being able to show users who had an easy time of porting
would be a good thing. The profitability of the specific product really
isn't important, in this context.

Right, it was nice, good news and maybe even rather simple, as a port.
But maybe that was also rather unexpected, I'm not sure...

Arne Vajhøj

2020-10-29 00:10:25 UTC

Post by Jan-Erik SÃ¶derholm
No, it doesn't. WASD is "just" a third part open source "thing" that
doesn't generate any income for VSI or anyone else. Not much to
shout about.

We need to distinguish between communicating to the technical
people and communicating to the decision making people.

For the technical people wondering how they get their
Alpha/Itanium application running on x86-64 then
all porting stories are relevant no matter the
products importance.

But it is different for the decision making people.
Some companies have application tied to Rdb, so
they need Rdb, so they buy a VMS system that Rdb can
run on. Rdb availability translates to VMS sales.
My guess is that there are nobody that buys a VMS
system because they want to run WASD. They need
a VMS system for some reason (Rdb or otherwise)
and they need a web server on what they are running
(VMS) and they pick WASD as a feature rich
and very VMSish web server.

Arne

Simon Clubley

2020-10-29 13:24:51 UTC

On 2020-10-28, Phillip Helbig (undress to reply)

Post by Phillip Helbig (undress to reply)
I wouldn't be surprised if Rdb is already running on x86.

If that had happened, I would have expected a major press release
from VSI by now. It would be a major step towards showing that VMS
is working on x86-64 VMS and would be excellent publicity for VSI.

Your expectations might not be the expectations of others.

Or in touch with reality.

I am way in touch with reality. It's some others around here who are not.

It is now 6 years since VSI announced that VMS was being ported to x86-64
and we _still_ don't have a usable x86-64 VMS port.

It is at least 2-3 years past when we were originally told that VMS would
be fully available and working on x86-64.

It is now a couple of months until Itanium hardware support starts to be
dropped.

How long until those who really want to continue running VMS end up saying
"sod this" (or their bosses say "sod this") and start to move on (and away
from VMS) ?

Post by Jan-Erik SÃ¶derholm
I'm not sure that VMS has all the bits needed to run Rdb yet.
I'm confident that there is a close contact between VSI and
the Rdb group at Oracle. No need to shout out about that.
And I think that any customer that relies on this combo have
made sure that they know very well what is happening.

You want to keep those customers committed to VSI for a little longer
while work continues on the port to x86-64 VMS ?

Then start making some major announcements that show things are finally
happening in the VMS world and that VMS (and VSI) will still be viable
in a few years.

So yes, there's a massive need for VSI to start shouting out about
things like this (assuming that the port of Rdb to x86-64 is actually
happening at the moment).

Post by Jan-Erik SÃ¶derholm
If mr Clubley knows or doesn't know is irrelevant, if he isn't a major
Rdb customer. But if he is, he would know.

VMS customers know that Rdb on x86-64 is apparently vital to the future
of VMS, even if they don't use Rdb themselves.

Those are _exactly_ the kind of customers that VSI should be letting know
about things like this in order to keep them as VSI customers.

(Assuming once again that Rdb is actually being ported to x86-64 VMS at
the moment.)

Talking only gets you so far. At some point, you have to start backing
up your talk with actions. After 6 years and still no completed port
of VMS to x86-64, that time has arrived for VSI.

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-10-29 17:20:36 UTC

Post by Phillip Helbig (undress to reply)
I wouldn't be surprised if Rdb is already running on x86.

If that had happened, I would have expected a major press release
from VSI by now. It would be a major step towards showing that VMS
is working on x86-64 VMS and would be excellent publicity for VSI.

Running somewhere internally. Obviously, a press release creates
expectations and questions. These have to be thought about before doing
a press release.

Certainly one wouldn't do a press release before the product is
complete.

Simon Clubley

2020-10-29 18:27:15 UTC

Post by Phillip Helbig (undress to reply)
I wouldn't be surprised if Rdb is already running on x86.

If that had happened, I would have expected a major press release
from VSI by now. It would be a major step towards showing that VMS
is working on x86-64 VMS and would be excellent publicity for VSI.

Running somewhere internally. Obviously, a press release creates
expectations and questions. These have to be thought about before doing
a press release.

Do you _know_ that Rdb on x86-64 VMS is running internally or is that
just a guess based on no evidence ?

We are currently 6 years into a port which was originally promised
to be completed 2-3 years ago. VSI have got to start doing _something_
to keep customer interest or people are going to start drifting away
regardless of how much they would like to run applications on x86-64 VMS.

We also don't know if the current schedule is accurate or if it
is going to slip further (through _no_ fault of the VSI engineers,
I would like to make clear).

And before _everyone_ jumps on me for saying that, consider this:

How much time elapsed between when the initial first boot contest
on x86-64 was announced and when the first boot was finally achieved ?

VSI clearly believed at the time they were very close to first boot
in order to announce the initial first boot contest.

Post by Phillip Helbig (undress to reply)
Certainly one wouldn't do a press release before the product is
complete.

When the Rdb port to Itanium was done, there was an expected porting
schedule published even before Oracle had access to the cross-compilers.

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-10-29 20:24:25 UTC

Post by Phillip Helbig (undress to reply)
I wouldn't be surprised if Rdb is already running on x86.

If that had happened, I would have expected a major press release
from VSI by now. It would be a major step towards showing that VMS
is working on x86-64 VMS and would be excellent publicity for VSI.

Running somewhere internally. Obviously, a press release creates
expectations and questions. These have to be thought about before doing
a press release.

Do you _know_ that Rdb on x86-64 VMS is running internally or is that
just a guess based on no evidence ?

To quote "I wouldn't be surprised". I don't know it, otherwise I would
have said so since I am not involved in any non-disclosure agreements.
(If I were, could I say so? Not worth thinking about because I am not.)

Scott Dorsey

2020-10-31 15:34:27 UTC

Post by Phillip Helbig (undress to reply)
Running somewhere internally. Obviously, a press release creates
expectations and questions. These have to be thought about before doing
a press release.
Certainly one wouldn't do a press release before the product is
complete.

That never stopped Microsoft.
--scott

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

Dave Froble

2020-10-28 23:04:27 UTC

Post by John Dallman
I seriously doubt they are bothered about VMS on x86-64 at present. If it
becomes a significant market success, they'll be able to support it.

Now that's rather funny. Nice joke.

Anybody that could have moved from VMS easily is in most cases long gone.

Anybody so locked into VMS will be happy to see x86 VMS.

Post by Simon Clubley
For the people who continue to wait for x86-64 VMS to become production
ready, they will still need to see Rdb is working correctly on x86-64
before they trust their production data to it so that is at least an
extra year or so after release of x86-64 Rdb until people trust it enough.

Perhaps you revisit Mark Daniel's short write-up on the port of WASD to
x86 VMS V9.0, which used cross compilers. Somehow, I've got to think
that x86 VMS V9.2 will be much easier to use.

Perhaps define just who those people are ?????

Post by Simon Clubley
Also, does anyone know at what point during the port of VMS to Itanium
did Rdb become available on Itanium ?

When the port was finished ?????

--
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-10-28 23:58:21 UTC

Perhaps you revisit Mark Daniel's short write-up on the port of WASD to
x86 VMS V9.0, which used cross compilers. Somehow, I've got to think
that x86 VMS V9.2 will be much easier to use.

Rdb may be a bit more complex than WASD.

But if VSI does not make any breaking changes in various
libraries or the Bliss compiler, then Rdb team may also
start by just building and see how it works.

If they have any Alpha & Itanium assembler they
maywill need to write some new code.

They may also need to do something in the code
generating tools.

But probably not too bad.

Arne

Richard Maher

2020-10-27 22:56:21 UTC