| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 49:51:11 |
| Calls: | 583 |
| Files: | 1,138 |
| Messages: | 111,303 |
I received this email from Oracle yesterday.-a If there is anyone here
that wants Rdb and related products on x86 then make your wishes known
to Oracle now!
https://www.oracle.com/webfolder/dms/prod/d1/nsl400413400-na-us-nl- rwnl1-nsl1-ev.html
Call to Action rCo Oracle Rdb on x86-64
If you are interested in running any of the Oracle Rdb family of
products on the x86-64 platform, now is the time to let us know! The products that have been ported to x86-64 or are in the process of being ported are:
rCo Oracle Rdb Server
rCo Oracle CODASYL DBMS
rCo Oracle CDD/Repository
rCo Oracle Trace
rCo Oracle SQL/Services and OCI Services for Oracle Rdb
rCo Oracle JDBC for Rdb
rCo Oracle Replication Option
Before we can make these products available, either as Beta kits or production releases, we will need our senior management approval to
ship. That approval will depend, in part, on a business case showing
strong customer demand. So far, *we have only heard from approximately
20 customers expressing interest in moving to x86-64!* Our assumption
has been that all our customers will want to make the move since Itanium
is at end-of-life but maybe that is not the case.
Our assumption
has been that all our customers will want to make the move since Itanium
is at end-of-life but maybe that is not the case.
On 8/7/2025 11:15 AM, John H. Reinhardt wrote:
#Oracle quote:
Our assumption
has been that all our customers will want to make the move since Itanium
is at end-of-life but maybe that is not the case.
Rdb on Itanium is a dead end. Hardware will eventually fail due to age.
There are no Itanium emulators.
So either they migrate to Rdb on x86-64 or they migrate to
another database.
Rdb on Alpha has a better chance due to the existence of
Alpha emulators.
I am seriously surprised that VSI have not already repeated this
announcement on their general announcements mailing list so that
anyone with _any_ possible interest in VMS is make aware of it. :-(
On 8/8/2025 8:16 AM, Simon Clubley wrote:
I am seriously surprised that VSI have not already repeated this
announcement on their general announcements mailing list so that
anyone with _any_ possible interest in VMS is make aware of it. :-(
I suspect Oracle does not care about the general
VMS enthusiast only about those paying for Rdb and other
Oracle product licenses.
So the message need to reach them and they need to get
in touch with Oracle.
A few decades ago there were a Rdb mail-list - it would have
been prefect for this, but I believe it is gone now.
I am also a little concerned about the impact of oursourcing.
If employee XYZ responsible for a Rdb production system hear
this, then XYZ will likely feel inclined to write Oracle. But
what if consultant XYZ from a big US/India based consulting
company temporarily responsible for a Rdb production system
hear this? A) I will write Oracle to protect the customers
interest. B) I would like to write Oracle but company policy
forbid me to get involved in such matters. C) I don't care if
Rdb goes away - I will just be sent out to customers with
Oracle DB on Linux. D) Let me try and sell the customer
a migration project.
Arne
On 8/8/2025 8:16 AM, Simon Clubley wrote:
I am seriously surprised that VSI have not already repeated this
announcement on their general announcements mailing list so that
anyone with _any_ possible interest in VMS is make aware of it. :-(
I suspect Oracle does not care about the general
VMS enthusiast only about those paying for Rdb and other
Oracle product licenses.
So the message need to reach them and they need to get
in touch with Oracle.
You would think that Oracle would have details of customers who have
bought RDB licenses in the past
On 8/8/2025 11:05 AM, Chris Townley wrote:
You would think that Oracle would have details of customers who have
bought RDB licenses in the past
But then, you also might think that Oracle would just much like
to see them all go away so they could stop spending resources on
something that is not a profit maker.
On 8/8/2025 1:42 PM, bill wrote:
On 8/8/2025 11:05 AM, Chris Townley wrote:
You would think that Oracle would have details of customers who have
bought RDB licenses in the past
But then, you also might think that Oracle would just much like
to see them all go away so they could stop spending resources on
something that is not a profit maker.
I am rather confident that Rdb is making a profit. The list
price of Rdb is pretty high and even with a solid discount
to good customers, then Oracle should be able to make
a profit.
The problem is that it is a very small area within a very
big company.
Oracle DB, Oracle ERP & CRM (whatever its current name is),
Oracle cloud etc. are huge business areas making tens
of billions in revenue and billions in profit.
So if Rdb talk about growing revenue by 10 M$ and Oracle cloud talk
about growing revenue by 10 B$, then senior management will not
spend many seconds on Rdb.
On 8/8/2025 1:42 PM, bill wrote:
On 8/8/2025 11:05 AM, Chris Townley wrote:
You would think that Oracle would have details of customers who have
bought RDB licenses in the past
But then, you also might think that Oracle would just much like
to see them all go away so they could stop spending resources on
something that is not a profit maker.
I am rather confident that Rdb is making a profit. The list
price of Rdb is pretty high and even with a solid discount
to good customers, then Oracle should be able to make
a profit.
The problem is that it is a very small area within a very
big company.
Oracle DB, Oracle ERP & CRM (whatever its current name is),
Oracle cloud etc. are huge business areas making tens
of billions in revenue and billions in profit.
So if Rdb talk about growing revenue by 10 M$ and Oracle cloud talk
about growing revenue by 10 B$, then senior management will not
spend many seconds on Rdb.
On 8/8/2025 1:42 PM, bill wrote:
On 8/8/2025 11:05 AM, Chris Townley wrote:
You would think that Oracle would have details of customers who have
bought RDB licenses in the past
But then, you also might think that Oracle would just much like
to see them all go away so they could stop spending resources on
something that is not a profit maker.
I am rather confident that Rdb is making a profit. The list
price of Rdb is pretty high and even with a solid discount
to good customers, then Oracle should be able to make
a profit.
The problem is that it is a very small area within a very
big company.
Oracle DB, Oracle ERP & CRM (whatever its current name is),
Oracle cloud etc. are huge business areas making tens
of billions in revenue and billions in profit.
So if Rdb talk about growing revenue by 10 M$ and Oracle cloud talk
about growing revenue by 10 B$, then senior management will not
spend many seconds on Rdb.
In article <1075dda$qq7j$2@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 8/8/2025 1:42 PM, bill wrote:
On 8/8/2025 11:05 AM, Chris Townley wrote:
You would think that Oracle would have details of customers who have
bought RDB licenses in the past
But then, you also might think that Oracle would just much like
to see them all go away so they could stop spending resources on
something that is not a profit maker.
I am rather confident that Rdb is making a profit. The list
price of Rdb is pretty high and even with a solid discount
to good customers, then Oracle should be able to make
a profit.
Define "profit". If Oracle feels that the engineering resources
being devoted to Rdb would make more money if devoted to
something else, then they may take that delta into account when
calculating profits. So even if they felt like the total
engineering cost were strictly less than total generated
revenue, they may view it as a loss due to missed revenue
opportunity.
Oracle DB, Oracle ERP & CRM (whatever its current name is),
Oracle cloud etc. are huge business areas making tens
of billions in revenue and billions in profit.
So if Rdb talk about growing revenue by 10 M$ and Oracle cloud talk
about growing revenue by 10 B$, then senior management will not
spend many seconds on Rdb.
USD $10M is not a lot of money when amortized over the amount of
time required to bring Rdb for x86_64 to market. How many
people are working on this thing? How many will be required for
maintenance? How long do they project those revenue numbers to
hold?
Opportunity cost is not profit for alternative development, but extra
profit from having them do the alternative development compared to other developers.
Which I expect to be approx. zero. I would expect the Rdb team to be 10X developers on Rdb, but not on any of the other Oracle database products.
Rdb is very different. Different database architecture, different
programming language, different platform,
some very old stuff (RDO etc.).
Oracle DB, Oracle ERP & CRM (whatever its current name is),
Oracle cloud etc. are huge business areas making tens of billions in
revenue and billions in profit.
So if Rdb talk about growing revenue by 10 M$ and Oracle cloud talk
about growing revenue by 10 B$, then senior management will not spend
many seconds on Rdb.
USD $10M is not a lot of money when amortized over the amount of time
required to bring Rdb for x86_64 to market. How many people are
working on this thing? How many will be required for maintenance? How
long do they project those revenue numbers to hold?
Customers pay annual software update license on Alpha and Itanium today.
And if they get the x86-64 port out the door, then customers will pay
pay annual software update license on x86-64.
So annual revenue and annual cost. Hopefully with a profit.
But point being that the profit is relative small in the bigger Oracle picture.
If they don't get the x86-64 port out the door then both annual revenue
and annual cost will eventually move to zero.
Arne
On 8/9/2025 5:39 AM, Dan Cross wrote:
In article <1075dda$qq7j$2@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 8/8/2025 1:42 PM, bill wrote:
On 8/8/2025 11:05 AM, Chris Townley wrote:
You would think that Oracle would have details of customers who have >>>>> bought RDB licenses in the past
But then, you also might think that Oracle would just much like
to see them all go away so they could stop spending resources on
something that is not a profit maker.
I am rather confident that Rdb is making a profit. The list
price of Rdb is pretty high and even with a solid discount
to good customers, then Oracle should be able to make
a profit.
Define "profit". If Oracle feels that the engineering resources
being devoted to Rdb would make more money if devoted to
something else, then they may take that delta into account when
calculating profits. So even if they felt like the total
engineering cost were strictly less than total generated
revenue, they may view it as a loss due to missed revenue
opportunity.
Opportunity cost is not profit for alternative development, but
extra profit from having them do the alternative development
compared to other developers.
Which I expect to be approx. zero. I would expect the Rdb team
to be 10X developers on Rdb, but not on any of the other
Oracle database products.
Rdb is very different. Different database architecture,
different programming language, different platform,
some very old stuff (RDO etc.).
Oracle DB, Oracle ERP & CRM (whatever its current name is),
Oracle cloud etc. are huge business areas making tens
of billions in revenue and billions in profit.
So if Rdb talk about growing revenue by 10 M$ and Oracle cloud talk
about growing revenue by 10 B$, then senior management will not
spend many seconds on Rdb.
USD $10M is not a lot of money when amortized over the amount of
time required to bring Rdb for x86_64 to market. How many
people are working on this thing? How many will be required for
maintenance? How long do they project those revenue numbers to
hold?
Customers pay annual software update license on Alpha and Itanium
today.
And if they get the x86-64 port out the door, then customers
will pay pay annual software update license on x86-64.
So annual revenue and annual cost. Hopefully with a profit.
But point being that the profit is relative small in the
bigger Oracle picture.
If they don't get the x86-64 port out the door then
both annual revenue and annual cost will eventually
move to zero.
On Tue, 12 Aug 2025 19:46:18 -0400, Arne Vajh|+j wrote:
Customers pay annual software update license on Alpha and Itanium today.
And if they get the x86-64 port out the door, then customers will pay
pay annual software update license on x86-64.
So annual revenue and annual cost. Hopefully with a profit.
But point being that the profit is relative small in the bigger Oracle
picture.
If they don't get the x86-64 port out the door then both annual revenue
and annual cost will eventually move to zero.
I'll speculate that part of Oracle's interest is to move OpenVMS/Rdb workloads to OCI, in addition to any Rdb licensing that they hope to earn.
In article <107gjob$3ir9s$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 8/9/2025 5:39 AM, Dan Cross wrote:
In article <1075dda$qq7j$2@dont-email.me>,
I am rather confident that Rdb is making a profit. The list
price of Rdb is pretty high and even with a solid discount
to good customers, then Oracle should be able to make
a profit.
Define "profit". If Oracle feels that the engineering resources
being devoted to Rdb would make more money if devoted to
something else, then they may take that delta into account when
calculating profits. So even if they felt like the total
engineering cost were strictly less than total generated
revenue, they may view it as a loss due to missed revenue
opportunity.
Opportunity cost is not profit for alternative development, but
extra profit from having them do the alternative development
compared to other developers.
Which I expect to be approx. zero. I would expect the Rdb team
to be 10X developers on Rdb, but not on any of the other
Oracle database products.
Rdb is very different. Different database architecture,
different programming language, different platform,
some very old stuff (RDO etc.).
Your statement is predicated on the assumption that Oracle cares
about the engineers rather than the engineering resources (which
are simply a cost function).
Evidence of their actions, as a company, do not support that
assumption.
So if Rdb talk about growing revenue by 10 M$ and Oracle cloud talk
about growing revenue by 10 B$, then senior management will not
spend many seconds on Rdb.
USD $10M is not a lot of money when amortized over the amount of
time required to bring Rdb for x86_64 to market. How many
people are working on this thing? How many will be required for
maintenance? How long do they project those revenue numbers to
hold?
Customers pay annual software update license on Alpha and Itanium
today.
And if they get the x86-64 port out the door, then customers
will pay pay annual software update license on x86-64.
So annual revenue and annual cost. Hopefully with a profit.
I wouldn't have asked how long they expect those revenue numbers
to hold if I hadn't understood that, so sorry, but this really
doesn't change the point at all: USD $10M/an is a tiny amount of
money relative to costs, and again, how long do they expect
those revenue numbers to hold?
On 8/13/2025 7:55 AM, Robert B. Carleton wrote:
On Tue, 12 Aug 2025 19:46:18 -0400, Arne Vajh|+j wrote:
Customers pay annual software update license on Alpha and Itanium today. >>>
And if they get the x86-64 port out the door, then customers will pay
pay annual software update license on x86-64.
So annual revenue and annual cost. Hopefully with a profit.
But point being that the profit is relative small in the bigger Oracle
picture.
If they don't get the x86-64 port out the door then both annual revenue
and annual cost will eventually move to zero.
I'll speculate that part of Oracle's interest is to move OpenVMS/Rdb
workloads to OCI, in addition to any Rdb licensing that they hope to
earn.
Yes.
In another post I wrote:
# Note that both Rdb team and VSI seems to have been
# trying to build an alliance by pushing Oracle cloud
# for Rdb and VMS in general.
#
# The competition OCI vs AWS vs Azure vs GCP is hard. And
# anything giving more customers for Oracle cloud could
# get at least some support from Oracle cloud team.
On 8/14/2025 7:48 PM, Arne Vajh|+j wrote:
On 8/13/2025 7:55 AM, Robert B. Carleton wrote:
On Tue, 12 Aug 2025 19:46:18 -0400, Arne Vajh|+j wrote:
Customers pay annual software update license on Alpha and Itanium
today.
And if they get the x86-64 port out the door, then customers will pay
pay annual software update license on x86-64.
So annual revenue and annual cost. Hopefully with a profit.
But point being that the profit is relative small in the bigger Oracle >>>> picture.
If they don't get the x86-64 port out the door then both annual revenue >>>> and annual cost will eventually move to zero.
I'll speculate that part of Oracle's interest is to move OpenVMS/Rdb
workloads to OCI, in addition to any Rdb licensing that they hope to
earn.
Yes.
In another post I wrote:
# Note that both Rdb team and VSI seems to have been
# trying to build an alliance by pushing Oracle cloud
# for Rdb and VMS in general.
#
# The competition OCI vs AWS vs Azure vs GCP is hard. And
# anything giving more customers for Oracle cloud could
# get at least some support from Oracle cloud team.
OCI is practically the only choice for cloud if running Rdb
due to Oracle license policy.
But even for non-Rdb customers then OCI would be first choice
if that is what VSI recommend and/or test first on.
On 8/14/2025 8:02 PM, Arne Vajh|+j wrote:
On 8/14/2025 7:48 PM, Arne Vajh|+j wrote:
On 8/13/2025 7:55 AM, Robert B. Carleton wrote:
On Tue, 12 Aug 2025 19:46:18 -0400, Arne Vajh|+j wrote:
Customers pay annual software update license on Alpha and Itanium
today.
And if they get the x86-64 port out the door, then customers will pay >>>>> pay annual software update license on x86-64.
So annual revenue and annual cost. Hopefully with a profit.
But point being that the profit is relative small in the bigger Oracle >>>>> picture.
If they don't get the x86-64 port out the door then both annual
revenue
and annual cost will eventually move to zero.
I'll speculate that part of Oracle's interest is to move OpenVMS/Rdb
workloads to OCI, in addition to any Rdb licensing that they hope to
earn.
Yes.
In another post I wrote:
# Note that both Rdb team and VSI seems to have been
# trying to build an alliance by pushing Oracle cloud
# for Rdb and VMS in general.
#
# The competition OCI vs AWS vs Azure vs GCP is hard. And
# anything giving more customers for Oracle cloud could
# get at least some support from Oracle cloud team.
OCI is practically the only choice for cloud if running Rdb
due to Oracle license policy.
But even for non-Rdb customers then OCI would be first choice
if that is what VSI recommend and/or test first on.
But for those that by principle don't buy anything
Oracle, then I suggest reaching out to David Cathey.
He is now senior solution architect at AWS and I think
he would be just the right person to move some VMS
systems to AWS.
Arne
On 15/08/2025 01:06, Arne Vajh|+j wrote:
On 8/14/2025 8:02 PM, Arne Vajh|+j wrote:
On 8/14/2025 7:48 PM, Arne Vajh|+j wrote:
On 8/13/2025 7:55 AM, Robert B. Carleton wrote:
On Tue, 12 Aug 2025 19:46:18 -0400, Arne Vajh|+j wrote:
Customers pay annual software update license on Alpha and Itanium >>>>>> today.
And if they get the x86-64 port out the door, then customers will pay >>>>>> pay annual software update license on x86-64.
So annual revenue and annual cost. Hopefully with a profit.
But point being that the profit is relative small in the bigger
Oracle
picture.
If they don't get the x86-64 port out the door then both annual
revenue
and annual cost will eventually move to zero.
I'll speculate that part of Oracle's interest is to move OpenVMS/Rdb >>>>> workloads to OCI, in addition to any Rdb licensing that they hope
to earn.
Yes.
In another post I wrote:
# Note that both Rdb team and VSI seems to have been
# trying to build an alliance by pushing Oracle cloud
# for Rdb and VMS in general.
#
# The competition OCI vs AWS vs Azure vs GCP is hard. And
# anything giving more customers for Oracle cloud could
# get at least some support from Oracle cloud team.
OCI is practically the only choice for cloud if running Rdb
due to Oracle license policy.
But even for non-Rdb customers then OCI would be first choice
if that is what VSI recommend and/or test first on.
But for those that by principle don't buy anything
Oracle, then I suggest reaching out to David Cathey.
He is now senior solution architect at AWS and I think
he would be just the right person to move some VMS
systems to AWS.
I thought VSI were working with AWS
Given that Oracle is a software company with a market cap over 600 B$,
then I would think they know something about software engineering.
Given that Oracle is a software company with a market cap over 600 B$,
then I would think they know something about software engineering.
On 8/14/2025 7:48 PM, Arne Vajh|+j wrote:
In another post I wrote:
# Note that both Rdb team and VSI seems to have been
# trying to build an alliance by pushing Oracle cloud
# for Rdb and VMS in general.
#
# The competition OCI vs AWS vs Azure vs GCP is hard. And
# anything giving more customers for Oracle cloud could
# get at least some support from Oracle cloud team.
OCI is practically the only choice for cloud if running Rdb
due to Oracle license policy.
But even for non-Rdb customers then OCI would be first choice
if that is what VSI recommend and/or test first on.
On 2025-08-14, Arne Vajhoj <arne@vajhoej.dk> wrote:
Given that Oracle is a software company with a market cap over 600 B$,
then I would think they know something about software engineering.
Size does not equal engineering skill.
Anything from Microsoft over the last 25 years.
Anything from Intel. x86 is a crap, power hungry architecture that
should have been consigned to history. Intel just got very very lucky
and we have all suffered since. For example, Motorola would have been
a far better starting point.
On 8/14/25 7:02 PM, Arne Vajh|+j wrote:
On 8/14/2025 7:48 PM, Arne Vajh|+j wrote:
In another post I wrote:
# Note that both Rdb team and VSI seems to have been
# trying to build an alliance by pushing Oracle cloud
# for Rdb and VMS in general.
#
# The competition OCI vs AWS vs Azure vs GCP is hard. And
# anything giving more customers for Oracle cloud could
# get at least some support from Oracle cloud team.
OCI is practically the only choice for cloud if running Rdb
due to Oracle license policy.
But even for non-Rdb customers then OCI would be first choice
if that is what VSI recommend and/or test first on.
Which is kind of a death knell for Rdb on VMS and can only hurt the
prospects of VMS more generally if someone tells VMS customers that
Oracle Cloud is preferred over the other cloud vendors.-a Last I checked, Oracle was a very distant fifth place among cloud vendors, with AWS
having 10 times the market share that Oracle has.
The whole point of the x86 port was to be able to run VMS on the same platform people were already using for all their other systems, which
usually means KVM or VMWare in some mix of on-premises and in the cloud,
with the folks wanting bare metal x86 already having to make other plans
or run unsupported. You can get a VMWare instance in Azure, and AWS is
now based on KVM; I don't know if anyone has successfully booted VMS on
them, but that is the "hardware" that almost everyone already has these
days.
On a Venn diagram showing people already running Oracle cloud and people possibly interested in running VMS on x86, the overlap will be very
small.-a Add Rdb to the diagram and it may well be that the overlap
consists of the 20 customers who have already replied to Oracle.
On 2025-08-14, Arne Vajhoj <arne@vajhoej.dk> wrote:
Given that Oracle is a software company with a market cap over 600 B$,
then I would think they know something about software engineering.
Size does not equal engineering skill.
Anything from Microsoft over the last 25 years.
Anything from Intel.
x86 is a crap, power hungry architecture that
should have been consigned to history. Intel just got very very lucky
and we have all suffered since. For example, Motorola would have been
a far better starting point.
On 2025-08-14, Arne Vajh|+j <arne@vajhoej.dk> wrote:
Given that Oracle is a software company with a market cap over 600 B$,
then I would think they know something about software engineering.
Size does not equal engineering skill.
Anything from Microsoft over the last 25 years.
Anything from Intel. x86 is a crap, power hungry architecture that
should have been consigned to history. Intel just got very very lucky
and we have all suffered since.
For example, Motorola would have been
a far better starting point.
On 8/15/2025 8:40 AM, Simon Clubley wrote:
If you consider it lucky to be overtaken by another company for
their good and yours was only an unavoidable fluke.
For example, Motorola would have been
a far better starting point.
Motorola was supposed to be the original starting point.
For non-Rdb usage there are no license or technical reasons to prefer
OCI over AWS, Azure or GCP.
On Fri, 15 Aug 2025 09:48:25 -0400, Arne Vajh|+j wrote:
For non-Rdb usage there are no license or technical reasons to prefer
OCI over AWS, Azure or GCP.
As an aside, How many non-Rdb users never moved off of using RMS in their applications? It seems like some of those would be candidates for moving
to the cloud.
On 8/16/2025 2:00 PM, Robert B. Carleton wrote:I did.
On Fri, 15 Aug 2025 09:48:25 -0400, Arne Vajh|+j wrote:
For non-Rdb usage there are no license or technical reasons to prefer
OCI over AWS, Azure or GCP.
As an aside, How many non-Rdb users never moved off of using RMS in
their applications? It seems like some of those would be candidates for
moving to the cloud.
I assume you mean RMS index-sequential files.
There must be a lot. If I were to guess then it is still the most common
VMS persistence technology.
But there are other solutions available as well.
Summary:
RMS index-sequential files : ready Rdb
: waiting SQLite : ready external MySQL/MariaDB : ready MySQL/MariaDB : waiting external any database via SQLRelay : ready Mimer
: ready Derby/H2/HSQLDB : ready
Arne
It would not make sense for Oracle to port if they expect
customers to migrate away in a few years.
And it would not make sense for customers to move to x86-64
and migrate away in a few years.
Arne Vajh|+j <arne@vajhoej.dk> wrote:
It would not make sense for Oracle to port if they expect
customers to migrate away in a few years.
And it would not make sense for customers to move to x86-64
and migrate away in a few years.
Why not? Succesful platform migration may take a lot of time.
When migration is done in incremental way important part is
increasing portability of source code. During that production
runs on existing system, in this case VMS. Assuming that x86-64
part is succesful, that is VSI customers can easily move
software to x86-64 VMS, it make sense to use x86-64 as intermedite
step. Namely, one has gain on hardware side, that is ability to
retire old hardware and run on new one. And move to x86-64 can
test some aspects of migration, before it is fully done.
Also, customer using Rdb now and migrationg to x86-64 may plan
migration off Rdb to a different database while staying on VMS.
OTOH, I would not expect much sense in platform choices. Migration
off VMS may be triggered by retirement of VMS-proponent or promotion
of VMS-enemy. There could be IT personel who wants to deal with
popular platforms and at some more or less random time management
may follow reccomendation given by IT personel.
On Sat, 16 Aug 2025 16:06:50 -0400, Arne Vajh|+j wrote:
On 8/16/2025 2:00 PM, Robert B. Carleton wrote:I did.
On Fri, 15 Aug 2025 09:48:25 -0400, Arne Vajh|+j wrote:
For non-Rdb usage there are no license or technical reasons to prefer
OCI over AWS, Azure or GCP.
As an aside, How many non-Rdb users never moved off of using RMS in
their applications? It seems like some of those would be candidates for
moving to the cloud.
I assume you mean RMS index-sequential files.
There must be a lot. If I were to guess then it is still the most common
VMS persistence technology.
I'm not much of a coder, but I assume that rewriting code already using index-sequential files would be a non-starter for some. Maybe VSI can maneuver this situation into something like IBM has with their data sets.
New development incrementally modernizing these systems, rather than replacing them.
On 8/16/2025 4:29 PM, Robert B. Carleton wrote:
On Sat, 16 Aug 2025 16:06:50 -0400, Arne Vajh|+j wrote:
On 8/16/2025 2:00 PM, Robert B. Carleton wrote:I did.
On Fri, 15 Aug 2025 09:48:25 -0400, Arne Vajh|+j wrote:
For non-Rdb usage there are no license or technical reasons to prefer >>>>> OCI over-a AWS, Azure or GCP.
As an aside, How many non-Rdb users never moved off of using RMS in
their applications? It seems like some of those would be candidates for >>>> moving to the cloud.
I assume you mean RMS index-sequential files.
There must be a lot. If I were to guess then it is still the most common >>> VMS persistence technology.
I'm not much of a coder, but I assume that rewriting code already using
index-sequential files would be a non-starter for some. Maybe VSI can
maneuver this situation into something like IBM has with their data sets.
New development incrementally modernizing these systems, rather than
replacing them.
Index-sequential files in Pascal, Basic and Cobol are pretty
slick in my opinion.
What type of modernization do you want?
I can a few things:
1) A decent C API (direct RMS calls sucks as API)
2) Get rid of 32K limit - but that will likely require a new file system
3) Add transaction support begin/commit/rollback to API
I'm not much of a coder, but I assume that rewriting code already using
index-sequential files would be a non-starter for some. Maybe VSI can
maneuver this situation into something like IBM has with their data
sets.
New development incrementally modernizing these systems, rather than
replacing them.
Index-sequential files in Pascal, Basic and Cobol are pretty slick in my opinion.
What type of modernization do you want?
On Sat, 16 Aug 2025 19:24:48 -0400, Arne Vajh|+j wrote:
I'm not much of a coder, but I assume that rewriting code already using
index-sequential files would be a non-starter for some. Maybe VSI can
maneuver this situation into something like IBM has with their data
sets.
New development incrementally modernizing these systems, rather than
replacing them.
Index-sequential files in Pascal, Basic and Cobol are pretty slick in my
opinion.
What type of modernization do you want?
I actually meant more like updating code without dramatically changing the underlying storage. Keeping up with compiler and API changes, maybe taking advantage of new features in both. Adding API access for web and phone
apps if it doesn't already exist, or updating it if that kind of access
needs improvement.
Oracle license policy in general including Oracle DB (sometimesApparently Oracle has also made some deal with AWS.
called Oracle Classic in VMS circles) is that customers pay
per physical core with the exception that it is by VCPU if it is in
Oracle environment: KVM on Oracle Linux on-prem or in OCI. I believe
recently Oracle made some agreement with MS about Oracle DB in Azure,
so maybe that will work as well - those interested should talk to
their friendly Oracle sales person about that.
On 8/16/2025 6:46 PM, Waldek Hebisch wrote:
Arne Vajh|+j <arne@vajhoej.dk> wrote:
It would not make sense for Oracle to port if they expect
customers to migrate away in a few years.
And it would not make sense for customers to move to x86-64
and migrate away in a few years.
Why not? Succesful platform migration may take a lot of time.
When migration is done in incremental way important part is
increasing portability of source code. During that production
runs on existing system, in this case VMS. Assuming that x86-64
part is succesful, that is VSI customers can easily move
software to x86-64 VMS, it make sense to use x86-64 as intermedite
step. Namely, one has gain on hardware side, that is ability to
retire old hardware and run on new one. And move to x86-64 can
test some aspects of migration, before it is fully done.
If they were to migrate it would be lower cost to stay
on Itanium and just do one migration instead of two. From
VMS Itanium to VMS x86-64 may not require any code changes, but
planning, project management, test etc. still make it expensive.
Any incremental increase of code portability could just as
well be done on Itanium.
Unless support for newer C++ standards
is important.
In article <107r3h2$1vod3$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 8/16/2025 6:46 PM, Waldek Hebisch wrote:
Arne Vajh|+j <arne@vajhoej.dk> wrote:
It would not make sense for Oracle to port if they expect
customers to migrate away in a few years.
And it would not make sense for customers to move to x86-64
and migrate away in a few years.
Why not? Succesful platform migration may take a lot of time.
When migration is done in incremental way important part is
increasing portability of source code. During that production
runs on existing system, in this case VMS. Assuming that x86-64
part is succesful, that is VSI customers can easily move
software to x86-64 VMS, it make sense to use x86-64 as intermedite
step. Namely, one has gain on hardware side, that is ability to
retire old hardware and run on new one. And move to x86-64 can
test some aspects of migration, before it is fully done.
If they were to migrate it would be lower cost to stay
on Itanium and just do one migration instead of two. From
VMS Itanium to VMS x86-64 may not require any code changes, but
planning, project management, test etc. still make it expensive.
Any incremental increase of code portability could just as
well be done on Itanium.
Well, except that Itanium hardware is becoming increasingly
unobtainium.
On 8/18/2025 6:31 PM, Dan Cross wrote:
In article <107r3h2$1vod3$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 8/16/2025 6:46 PM, Waldek Hebisch wrote:
Arne Vajh|+j <arne@vajhoej.dk> wrote:
It would not make sense for Oracle to port if they expect
customers to migrate away in a few years.
And it would not make sense for customers to move to x86-64
and migrate away in a few years.
Why not? Succesful platform migration may take a lot of time.
When migration is done in incremental way important part is
increasing portability of source code. During that production
runs on existing system, in this case VMS. Assuming that x86-64
part is succesful, that is VSI customers can easily move
software to x86-64 VMS, it make sense to use x86-64 as intermedite
step. Namely, one has gain on hardware side, that is ability to
retire old hardware and run on new one. And move to x86-64 can
test some aspects of migration, before it is fully done.
If they were to migrate it would be lower cost to stay
on Itanium and just do one migration instead of two. From
VMS Itanium to VMS x86-64 may not require any code changes, but
planning, project management, test etc. still make it expensive.
Any incremental increase of code portability could just as
well be done on Itanium.
Well, except that Itanium hardware is becoming increasingly
unobtainium.
If the plan is to migrate off VMS in let us say 5-8 years, then
they would go to IslandCo and buy a bunch of spare servers and
various spare parts and put it on the shelf.
I have been there. Early 00's. Old mid 90's Alpha's with disks that occasionally went bad. Gray and green StorageWorks for those that are interested. We bought a pile of disks from IslandCo. Did a disk go bad,
then pull it out and put a new one in and the RAID controller rebuilt.
On 8/16/2025 6:46 PM, Waldek Hebisch wrote:
Arne Vajh|+j <arne@vajhoej.dk> wrote:
It would not make sense for Oracle to port if they expect
customers to migrate away in a few years.
And it would not make sense for customers to move to x86-64
and migrate away in a few years.
Why not? Succesful platform migration may take a lot of time.
When migration is done in incremental way important part is
increasing portability of source code. During that production
runs on existing system, in this case VMS. Assuming that x86-64
part is succesful, that is VSI customers can easily move
software to x86-64 VMS, it make sense to use x86-64 as intermedite
step. Namely, one has gain on hardware side, that is ability to
retire old hardware and run on new one. And move to x86-64 can
test some aspects of migration, before it is fully done.
If they were to migrate it would be lower cost to stay
on Itanium and just do one migration instead of two. From
VMS Itanium to VMS x86-64 may not require any code changes, but
planning, project management, test etc. still make it expensive.
Any incremental increase of code portability could just as
well be done on Itanium. Unless support for newer C++ standards
is important.
On 2025-08-15, bill <bill.gunshannon@gmail.com> wrote:
On 8/15/2025 8:40 AM, Simon Clubley wrote:
If you consider it lucky to be overtaken by another company for
their good and yours was only an unavoidable fluke.
For example, Motorola would have been
a far better starting point.
Motorola was supposed to be the original starting point.
And the sad thing is most people don't realise what they could have
had instead of x86. Intel should have been a footnote in history as
an extinct calculator CPU and memory chip manufacturer.
Simon.
On 8/15/2025 1:47 PM, Simon Clubley wrote:
On 2025-08-15, bill <bill.gunshannon@gmail.com> wrote:
On 8/15/2025 8:40 AM, Simon Clubley wrote:
If you consider it lucky to be overtaken by another company for
their good and yours was only an unavoidable fluke.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a For example, Motorola would have been
a far better starting point.
Motorola was supposed to be the original starting point.
And the sad thing is most people don't realise what they could have
had instead of x86. Intel should have been a footnote in history as
an extinct calculator CPU and memory chip manufacturer.
Simon.
I consider it all the fault of short sighted people at DEC.
The VAX would have made a really nice PC, and follow-ons such as Alpha
would have happened.-a But no, DEC was stuck on small volume with large profit margins. -aProbably the high overhead of all those support people
had something to do with that.-a But, that plan was doomed.