Discussion:
VSI working on alternatives to Oracle Classic database
Add Reply
Simon Clubley
2021-01-20 13:13:22 UTC
Reply
Permalink
VSI have sent out an announcement via email about alternative options
they are working on now that Oracle Classic (including the client) has
been discontinued for VMS.

It's not on their website yet, so I don't know if it is ok to post it
but it talks about various alternatives, some VMS based and some Linux
based and various connection options.

I mention it in case someone is looking for Oracle Classic alternatives,
and have not received the email, so they can contact VSI to ask for
further information.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Jan-Erik Söderholm
2021-01-20 13:39:34 UTC
Reply
Permalink
Post by Simon Clubley
VSI have sent out an announcement via email about alternative options
they are working on now that Oracle Classic (including the client) has
been discontinued for VMS.
It's not on their website yet, so I don't know if it is ok to post it
but it talks about various alternatives, some VMS based and some Linux
based and various connection options.
I mention it in case someone is looking for Oracle Classic alternatives,
and have not received the email, so they can contact VSI to ask for
further information.
Simon.
I replied on that directly to VSI yesterday asking why moving/porting to
Rdb was not one of the bulleted options. Rdb has some optional definitions
and functions that can be installed to an Rdb database to make it look more
like an Oracle Classic database. And there is an OCI interface.

But then, if you have large amounts of PL/SQL routines, porting to
anything might be a challange...
Arne Vajhøj
2021-01-20 14:12:12 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Simon Clubley
VSI have sent out an announcement via email about alternative options
they are working on now that Oracle Classic (including the client) has
been discontinued for VMS.
It's not on their website yet, so I don't know if it is ok to post it
but it talks about various alternatives, some VMS based and some Linux
based and various connection options.
I mention it in case someone is looking for Oracle Classic alternatives,
and have not received the email, so they can contact VSI to ask for
further information.
I replied on that directly to VSI yesterday asking why moving/porting to
Rdb was not one of the bulleted options. Rdb has some optional definitions
and functions that can be installed to an Rdb database to make it look more
like an Oracle Classic database. And there is an OCI interface.
But then, if you have large amounts of PL/SQL routines, porting to
anything might be a challange...
For those that just need *a* relational database, then there
are plenty of alternatives for VMS.

I know of: Rdb, MySQL/MariaDB, Mimer, SQLite, HSQLDB, Derby, H2.

It seems weird that that don't mention Rdb. Of the above list then
it is really the most high end and therefore the most logical
replacement for Oracle DB (Oracle Classic in traditional VMS
terminology). SQLite is a cool database, but I see it more as
replacement for RMS index-sequential files.

For those that depends heavily on Oracle stored procedures
(PL/SQL - as I don't believe the VMS version of the database
ever supported stored procedures in Java), then it is
a totally different situation. They are probably better
of migrating to Oracle DB on Linux.

But then they need the client lib to stay on VMS
(unless they happen to use a JVM language that can use
thin JDBC driver, but that is probably a tiny fraction
of uses).

VSI really should convince Oracle to keep supporting the
client lib including supporting it on VMS x86-64.

I don't think there are many good alternatives as
most third party libs are build on top of OCI.

Arne
gérard Calliet
2021-01-20 15:05:51 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Simon Clubley
VSI have sent out an announcement via email about alternative options
they are working on now that Oracle Classic (including the client) has
been discontinued for VMS.
It's not on their website yet, so I don't know if it is ok to post it
but it talks about various alternatives, some VMS based and some Linux
based and various connection options.
I mention it in case someone is looking for Oracle Classic alternatives,
and have not received the email, so they can contact VSI to ask for
further information.
I replied on that directly to VSI yesterday asking why moving/porting to
Rdb was not one of the bulleted options. Rdb has some optional definitions
and functions that can be installed to an Rdb database to make it look more
like an Oracle Classic database. And there is an OCI interface.
But then, if you have large amounts of PL/SQL routines, porting to
anything might be a challange...
For those that just need *a* relational database, then there
are plenty of alternatives for VMS.
I know of: Rdb, MySQL/MariaDB, Mimer, SQLite, HSQLDB, Derby, H2.
It seems weird that that don't mention Rdb. Of the above list then
it is really the most high end and therefore the most logical
replacement for Oracle DB (Oracle Classic in traditional VMS
terminology).
Absolutly right. It is very strange VSI didn't mention that. I hope it
is not a sign of problems between VSI and Oracle.

SQLite is a cool database, but I see it more as
Post by Arne Vajhøj
replacement for RMS index-sequential files.
For those that depends heavily on Oracle stored procedures
(PL/SQL - as I don't believe the VMS version of the database
ever supported stored procedures in Java), then it is
a totally different situation. They are probably better
of migrating to Oracle DB on Linux.
But then they need the client lib to stay on VMS
(unless they happen to use a JVM language that can use
thin JDBC driver, but that is probably a tiny fraction
of uses).
VSI really should convince Oracle to keep supporting the
client lib including supporting it on VMS x86-64.
No hope. We had a meeting in France with Kevin Duffy and the "no
oracle11g client supported for VMS" is of the category of politic
decisions which cannot be reverted. (And it is also part of the general
choices in Oracle for 11g, not only for VMS).

A customer had said there "so I have to go away from VMS". Kevin
could'nt say anything about that.
Post by Arne Vajhøj
I don't think there are many good alternatives as
most third party libs are build on top of OCI.
Arne
gérard Calliet
2021-01-20 15:13:00 UTC
Reply
Permalink
Post by Arne Vajhøj
SQLite is a cool database, but I see it more as
replacement for RMS index-sequential files.
Yeah?

I understand you think replacing some RMS index-sequential files by
relational database is something not totally impossible.

It is a very unusual opinion. I'd like to hear more from you about that,
examples if you have some, etc,...

It is also a *big* subject for infinite discutions like we can have
here, I hope we'll have.

Gérard Calliet
Arne Vajhøj
2021-01-20 15:40:57 UTC
Reply
Permalink
Post by gérard Calliet
Post by Arne Vajhøj
SQLite is a cool database, but I see it more as
replacement for RMS index-sequential files.
Yeah?
I understand you think replacing some RMS index-sequential files by
relational database is something not totally impossible.
Correct.
Post by gérard Calliet
It is a very unusual opinion. I'd like to hear more from you about that,
examples if you have some, etc,...
I doubt it is that unusual.

SQLite simply has some advantages:
* better API for programmers
* much better tools for management
* fewer restrictions
* more portable
* skills more available

What not to like?

For a new VMS application then it is an easy choice.

For an existing VMS application then converting is most likely a good
thing in the long perspective, but since it means changes, then
it needs some analysis on when to do it. If the application
need major changes for other reasons, then it could be a good time
to convert.

Arne
gérard Calliet
2021-01-20 17:06:43 UTC
Reply
Permalink
Post by Arne Vajhøj
For an existing VMS application then converting is most likely a good
thing in the long perspective, but since it means changes, then
it needs some analysis on when to do it.
My question is just about that.

I received a lot of opinions about conversion from applications based on
indexed-sequential to relational database which are saying it represents
a huge structural transformation, because of the very different
philosophies (for example about how to normalize, how to deal with cobol
redefines or occurs clauses, etc,...).

I think there are been a lot of work done on that in the mainframe
environments, and a lot of commercial proposals. It seems they are
dealing with non trivial issues.

But perhaps something can be done and there are innovative methods for
that. I have not a definitive opinion on that. And because of what you
have told, I was a little bit curious.

Gérard Calliet
Dave Froble
2021-01-20 18:15:49 UTC
Reply
Permalink
Post by gérard Calliet
Post by Arne Vajhøj
For an existing VMS application then converting is most likely a good
thing in the long perspective, but since it means changes, then
it needs some analysis on when to do it.
My question is just about that.
I received a lot of opinions about conversion from applications based on
indexed-sequential to relational database which are saying it represents
a huge structural transformation, because of the very different
philosophies (for example about how to normalize, how to deal with cobol
redefines or occurs clauses, etc,...).
I think there are been a lot of work done on that in the mainframe
environments, and a lot of commercial proposals. It seems they are
dealing with non trivial issues.
But perhaps something can be done and there are innovative methods for
that. I have not a definitive opinion on that. And because of what you
have told, I was a little bit curious.
Gérard Calliet
Well I do have at least one experience doing such, and what happened was
that the old app was used as a guide, the new app was pretty much
totally re-written.

When the basic structure of an app is written around the requirements
for database access, and the new database concepts are totally
different, there is no possibility of making "small" changes.

In many cases, it's truly a case of throwing out the baby with the bath
water.

Arne and others can talk about concepts, but the actual doing most
likely will not fit well with their ideas.

Just my experience.
--
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
2021-01-20 19:23:41 UTC
Reply
Permalink
Post by Dave Froble
Post by gérard Calliet
Post by Arne Vajhøj
For an existing VMS application then converting is most likely a good
thing in the long perspective, but since it means changes, then
it needs some analysis on when to do it.
My question is just about that.
I received a lot of opinions about conversion from applications based on
indexed-sequential to relational database which are saying it represents
a huge structural transformation, because of the very different
philosophies (for example about how to normalize, how to deal with cobol
redefines or occurs clauses, etc,...).
But perhaps something can be done and there are innovative methods for
that. I have not a definitive opinion on that. And because of what you
have told, I was a little bit curious.
Well I do have at least one experience doing such, and what happened was
that the old app was used as a guide, the new app was pretty much
totally re-written.
When the basic structure of an app is written around the requirements
for database access, and the new database concepts are totally
different, there is no possibility of making "small" changes.
In many cases, it's truly a case of throwing out the baby with the bath
water.
If the structure of the app is based on a certain database access
then changing that database access will change the structure
of the app.

No surprise.

That is why it is usually recommended not structuring the
app based on that.

Arne
Stephen Hoffman
2021-01-20 18:27:33 UTC
Reply
Permalink
Post by gérard Calliet
Post by Arne Vajhøj
For an existing VMS application then converting is most likely a good
thing in the long perspective, but since it means changes, then it
needs some analysis on when to do it.
My question is just about that.
I've been migrating key-value to SQLite and ilk as the results are more
flexible, and are far easier to extend.

Key-value store migrates into a relational database trivially.

Have I been migrating everything? No. Some of it. Yes. And using
relational databases with newer code.

The test suite for the SQLite app rivals or surpasses that for OpenVMS
itself. It's extensive. Dr. Hipp and folks are quite good at testing.

And for those that think SQLite is for relatively small environments,
sure, but pragmatically so too is OpenVMS—nowadays. Scales of computing
and of apps have changed. 2 TiB isn't as big as it used to be, etc.
Post by gérard Calliet
I received a lot of opinions about conversion from applications based
on indexed-sequential to relational database which are saying it
represents a huge structural transformation, because of the very
different philosophies (for example about how to normalize, how to deal
with cobol redefines or occurs clauses, etc,...).
Not in my experience. An indexed-sequential migration is direct. Can
you also choose to re-normalize or alter or update your storage, or
your data design? Sure.

There are and can be concerns around the source code, because RMS is
integrated with COBOL, BASIC, etc., and SQLite or Oracle Rdb or
otherwise is not, and there'll either need to be calls replaced, or an
abstraction layer added between the source code and the data store.
Oracle Rdb can implement its own abstraction layer with the precompiler
and which can help with this effort, though that precompiler then ties
you into Rdb. This is an incremental process, and can take a while to
design, deploy, and to then migrate.

Mapping from RMS calls to key-value in a relational database is
straightforward. You have one or more keys, and associated data. That's
one table within the relational database. Maybe a table and a few
singleton tables to hold index values if you're using a particular
local allocation sequence not otherwise supported by your chosen
database. It's also fairly common to see multiple key-value indexed
files and some app-associated configuration data files and related
baggage transition into one database, with multiple tables.
Normalization tends to involve discussions of adding support for UTF-8
encoding or (human-)language-specific sorts or such; more
enhancement-focused.
Post by gérard Calliet
I think there are been a lot of work done on that in the mainframe
environments, and a lot of commercial proposals. It seems they are
dealing with non trivial issues.
Mainframes have some interesting ideas, such as the approach used to
insulate System i from the hardware.

Few ideas of which are arguably within reach of VSI, at its present
scale and budget.

And mainframe sites aren't going to migrate to OpenVMS in sufficient
numbers to matter, if they decide to migrate off IBM at all.
Post by gérard Calliet
But perhaps something can be done and there are innovative methods for
that. I have not a definitive opinion on that. And because of what you
have told, I was a little bit curious.
Mainframes were something DEC marketing was focused on an aeon or three
ago, and IMO that focus was and remains ill-considered; aimed at the
wrong end of the IT market.

Download SQLite or such and try it. Yes, it's more complex than RMS
key-value stores. More flexible, too. Most data design changes are
vastly easier, though. So to is ad-hoc reporting, etc.

BTW: there's a new edition (2018) of Fowler's Refactoring book
available, for those familiar. The earlier edition was a good
discussion of how to refactor and how to update an existing code base,
which then makes it easier to further adapt and change and update your
code.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2021-01-20 19:16:43 UTC
Reply
Permalink
Post by gérard Calliet
Post by Arne Vajhøj
For an existing VMS application then converting is most likely a good
thing in the long perspective, but since it means changes, then
it needs some analysis on when to do it.
My question is just about that.
I received a lot of opinions about conversion from applications based on
indexed-sequential to relational database which are saying it represents
a huge structural transformation, because of the very different
philosophies (for example about how to normalize, how to deal with cobol
redefines or occurs clauses, etc,...).
The basic data mapping should not be that difficult.

record type -> table
field -> field

will provide a basic table structure.

Then optionally one can do a bit of normalization and move repeating
items to a separate table to get to 1NF.

Then onto operations.

Reading a record become doing a SELECT.

Writing a new record becomes an INSERT.

Updating an existing record becomes an UPDATE.

It is obviously work. Any software change is work. But it
may not be so bad.

There are also a few potential gotchas:
* no fixed record types in which case a relational database
may not be a good choice and a NoSQL Document Store may be better
* low level persistence structures having leaked high up in
the layers requiring significant code change
Post by gérard Calliet
But perhaps something can be done and there are innovative methods for
that. I have not a definitive opinion on that. And because of what you
have told, I was a little bit curious.
I don't think there is any silver bullet.

Arne
Jeffrey H. Coffield
2021-01-20 19:53:51 UTC
Reply
Permalink
Post by gérard Calliet
I received a lot of opinions about conversion from applications based on
indexed-sequential to relational database which are saying it represents
a huge structural transformation, because of the very different
philosophies (for example about how to normalize, how to deal with cobol
redefines or occurs clauses, etc,...).
Gérard Calliet
As I see it, the problems with Cobol redefines and occurs clauses are
the result of limitations in SQL. We support many Java applications that
access RMS databases used by large Cobol applications and Java has no
problems with redefines (each redefine can be extend of a base class or
a single RMS file can appear as multiple tables with corresponding
entity classes) or occurs (managed entities have no problem with arrays
or even HashMaps.) The trick is to have managed entities that are smart
enough to decode the structures that a SQL query can pass.

My company has developed a JDBC driver for RMS indexed files and a
persistence layer that achieve this and allow effective joins across
both RMS and MySQL tables. We are in the process of packaging both the
driver and persistence layer as open source but are currently uncertain
of the correct license to use.

Any real solution though is certainly non-trivial and requires some very
detailed analysis of the particular application.

Jeff Coffield
www.digitalsynerginc.com
Arne Vajhøj
2021-01-20 20:06:09 UTC
Reply
Permalink
Post by Jeffrey H. Coffield
My company has developed a JDBC driver for RMS indexed files and a
persistence layer that achieve this and allow effective joins across
both RMS and MySQL tables. We are in the process of packaging both the
driver and persistence layer as open source but are currently uncertain
of the correct license to use.
I will suggest Apache License.

Reasons:
* well known
* permissive
* very common in Java world

Arne
Stephen Hoffman
2021-01-21 15:45:40 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Jeffrey H. Coffield
My company has developed a JDBC driver for RMS indexed files and a
persistence layer that achieve this and allow effective joins across
both RMS and MySQL tables. We are in the process of packaging both the
driver and persistence layer as open source but are currently uncertain
of the correct license to use.
I will suggest Apache License.
Apache 2 or BSD/MIT licenses are the most typical choices for source
code where the copyright holder doesn't wish to restrict source code
usage. I've used both licenses for releases, though will typically be
using Apache 2 for newer work.

The various versions of GPL and LGPL and related are so-called copyleft
licenses, and add requirements around certain actions with the source
code. I tend not to use GPL, LGPL, or analog, though comply when
modifying code covered by those.

Related reading:
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licences

https://blog.codinghorror.com/pick-a-license-any-license/
https://haacked.com/archive/2007/04/04/there-are-only-four-software-licenses.aspx/
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2021-01-21 15:59:20 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Arne Vajhøj
Post by Jeffrey H. Coffield
My company has developed a JDBC driver for RMS indexed files and a
persistence layer that achieve this and allow effective joins across
both RMS and MySQL tables. We are in the process of packaging both
the driver and persistence layer as open source but are currently
uncertain of the correct license to use.
I will suggest Apache License.
Apache 2 or BSD/MIT licenses are the most typical choices for source
code where the copyright holder doesn't wish to restrict source code
usage. I've used both licenses for releases, though will typically be
using Apache 2 for newer work.
The various versions of GPL and LGPL and related are so-called copyleft
licenses, and add requirements around certain actions with the source
code. I tend not to use GPL, LGPL, or analog, though comply when
modifying code covered by those.
Besides the differences in license terms there seems to be
a bit of fashion in open source licenses.

The C people more often choose BSD and LGPL.

The Java and the Apple people more often chose Apache.

The JS, PHP and .NET people more often chose MIT.

Arne
John Reagan
2021-01-21 16:58:43 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
Post by Arne Vajhøj
Post by Jeffrey H. Coffield
My company has developed a JDBC driver for RMS indexed files and a
persistence layer that achieve this and allow effective joins across
both RMS and MySQL tables. We are in the process of packaging both
the driver and persistence layer as open source but are currently
uncertain of the correct license to use.
I will suggest Apache License.
Apache 2 or BSD/MIT licenses are the most typical choices for source
code where the copyright holder doesn't wish to restrict source code
usage. I've used both licenses for releases, though will typically be
using Apache 2 for newer work.
The various versions of GPL and LGPL and related are so-called copyleft
licenses, and add requirements around certain actions with the source
code. I tend not to use GPL, LGPL, or analog, though comply when
modifying code covered by those.
Besides the differences in license terms there seems to be
a bit of fashion in open source licenses.
The C people more often choose BSD and LGPL.
The Java and the Apple people more often chose Apache.
The JS, PHP and .NET people more often chose MIT.
Arne
FYI, LLVM is Apache 2 with two additional exceptions.

https://llvm.org/docs/DeveloperPolicy.html#new-llvm-project-license-framework
Michael C
2021-01-22 10:21:47 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
Post by Arne Vajhøj
Post by Jeffrey H. Coffield
My company has developed a JDBC driver for RMS indexed files and a
persistence layer that achieve this and allow effective joins across
both RMS and MySQL tables. We are in the process of packaging both
the driver and persistence layer as open source but are currently
uncertain of the correct license to use.
I will suggest Apache License.
Apache 2 or BSD/MIT licenses are the most typical choices for source
code where the copyright holder doesn't wish to restrict source code
usage. I've used both licenses for releases, though will typically be
using Apache 2 for newer work.
The various versions of GPL and LGPL and related are so-called copyleft
licenses, and add requirements around certain actions with the source
code. I tend not to use GPL, LGPL, or analog, though comply when
modifying code covered by those.
Besides the differences in license terms there seems to be
a bit of fashion in open source licenses.
The C people more often choose BSD and LGPL.
The Java and the Apple people more often chose Apache.
The JS, PHP and .NET people more often chose MIT.
Arne
Synergy has a product called SQL Connection. As long as it does not require Oracle client you should be good to go, shouldn't you?


SQL Connection is an API and a set of database drivers that enable Synergy applications to use SQL-based functions to access and manipulate data from various database systems, such as Oracle and SQL Server. The SQL Connection API consists of two types of functions:

Database functions are directly related to SQL-based operations and data access. They greatly simplify application development by reducing the number of calls needed to accomplish a wide variety of SQL functions. See Database Functions.
Utility functions enable you to get information, map error codes, and set date and time options during the execution of a Synergy application. See Utility Functions.

Every SQL Connection function generates a value and can be used any place a literal can be used in a Synergy program. Except where noted, SQL Connection functions work with both traditional Synergy and Synergy .NET.

For an overview of the steps you will need to follow to use SQL Connection in your Synergy program, see Writing an SQL Connection program.

Features and supported databases

SQL Connection conforms to ANSI-standard database communication methods SQLCA and SQLDA (ANSI 89) and supports the following databases:

MySQL (version 5.1 and higher) on supported Windows, Linux, and AIX platforms. (MySQL 8 requires OpenSSL 1.1.1, so on UNIX, it is supported only on platforms that support that version of OpenSSL. See MySQL notes and examples for additional information.)
Oracle® (version 11 and higher) on all supported Windows, UNIX, and OpenVMS platforms
SQL Server accessed via Microsoft ODBC Driver 17.x for SQL Server. For information on SQL Server versions supported by these drivers, see the Microsoft documentation. For more information on SQL Connection support for Microsoft ODBC drivers, see SQL Server notes and examples.
Synergy DBMS (version 10.3.1 and higher) on all supported Windows, UNIX, and OpenVMS platforms

(For information on supported Windows, UNIX, and OpenVMS platforms, see System Requirements.)

SQL Connection has limited support for the following database systems. Support for these databases may require assistance from Synergex Professional Services Group and additional support fees. Contact your Synergex account executive for details.

IBM DB2®
Informix® on UNIX
ODBC-compliant databases on Windows
Oracle Rdb on OpenVMS
PostgreSQL on Windows
Sybase® on Windows and UNIX
Simon Clubley
2021-01-22 13:05:37 UTC
Reply
Permalink
Post by Michael C
Synergy has a product called SQL Connection. As long as it does not require Oracle client you should be good to go, shouldn't you?
[snip]

Can this product be used from code written in C++/Cobol/Fortran/Pascal/etc ?

Will this product be available on 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
2021-01-22 13:51:41 UTC
Reply
Permalink
Post by Michael C
Synergy has a product called SQL Connection. As long as it does not require Oracle client you should be good to go, shouldn't you?
But it seems to do.

Look at:

https://www.synergex.com/docs/index.htm#sql/sqlChap1Componentsandconfigurations.htm#Components_and_configurations%3FTocPath%3DSQL%2520Connection%2520Reference%7CGetting%2520Started%2520with%2520SQL%2520Connection%7C_____2

Figure 1

It uses OCI to connect to Oracle.

But maybe interesting is figure 2 which seems to do the same
as the previously mentioned SQL Relay aka:

app VMS
SQL OpenNet client
|
(SQL OpenNet protocol) -----
|
SQL OpenNet server Linux
Oracle client
|
(Oracle protocol) -----
|
Oracle DB Linux

Arne
Arne Vajhøj
2021-07-05 23:56:25 UTC
Reply
Permalink
Post by gérard Calliet
Post by Arne Vajhøj
SQLite is a cool database, but I see it more as
replacement for RMS index-sequential files.
Yeah?
I understand you think replacing some RMS index-sequential files by
relational database is something not totally impossible.
It is a very unusual opinion. I'd like to hear more from you about that,
examples if you have some, etc,...
It is also a *big* subject for infinite discutions like we can have
here, I hope we'll have.
I just posted a link to some text and code examples on
the topic.

Arne
k***@gmail.com
2021-07-11 14:13:16 UTC
Reply
Permalink
-----Original Message-----
Info-vax
Sent: July-05-21 8:56 PM
Subject: Re: [Info-vax] a cool database... as replacement for RMS index-
sequential files:: Was: VSI working on alternatives to Oracle Classic
Post by gérard Calliet
SQLite is a cool database, but I see it more as replacement for RMS
index-sequential files.
Yeah?
I understand you think replacing some RMS index-sequential files by
relational database is something not totally impossible.
It is a very unusual opinion. I'd like to hear more from you about
that, examples if you have some, etc,...
It is also a *big* subject for infinite discutions like we can have
here, I hope we'll have.
I just posted a link to some text and code examples on the topic.
Arne
As a general fyi, stay tuned for another database and host integration
technology options for OpenVMS.

- SharkSQL - 100% cluster compliant database, full ACID properties support,
OpenVMS is reference platform, later releases will include Windows, Windows
- CSQL - host program integration, combines C and SQL specification
- STR - service and transaction router, provides capability to address
requirement where services must find the way to the server where the initial
request processed has been processed and the execution state is stored

Documentation is in the process of being updated, but here is a previous
OpenVMS bootcamp presentation.
http://www.sharksql.com/DOCUMENTATION/SharkSQL%20Bootcamp%202017.pdf

Expect to hear more on the beta release this Sept-Oct timeframe.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
Jan-Erik Söderholm
2021-01-20 16:23:41 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Simon Clubley
VSI have sent out an announcement via email about alternative options
they are working on now that Oracle Classic (including the client) has
been discontinued for VMS.
It's not on their website yet, so I don't know if it is ok to post it
but it talks about various alternatives, some VMS based and some Linux
based and various connection options.
I mention it in case someone is looking for Oracle Classic alternatives,
and have not received the email, so they can contact VSI to ask for
further information.
I replied on that directly to VSI yesterday asking why moving/porting to
Rdb was not one of the bulleted options. Rdb has some optional definitions
and functions that can be installed to an Rdb database to make it look more
like an Oracle Classic database. And there is an OCI interface.
But then, if you have large amounts of PL/SQL routines, porting to
anything might be a challange...
For those that just need *a* relational database, then there
are plenty of alternatives for VMS.
I know of: Rdb, MySQL/MariaDB, Mimer, SQLite, HSQLDB, Derby, H2.
It seems weird that that don't mention Rdb. Of the above list then
it is really the most high end and therefore the most logical
replacement for Oracle DB (Oracle Classic in traditional VMS
terminology). SQLite is a cool database, but I see it more as
replacement for RMS index-sequential files.
For those that depends heavily on Oracle stored procedures
(PL/SQL - as I don't believe the VMS version of the database
ever supported stored procedures in Java), then it is
a totally different situation. They are probably better
of migrating to Oracle DB on Linux.
But then they need the client lib to stay on VMS
(unless they happen to use a JVM language that can use
thin JDBC driver, but that is probably a tiny fraction
of uses).
VSI really should convince Oracle to keep supporting the
client lib including supporting it on VMS x86-64.
I don't think there are many good alternatives as
most third party libs are build on top of OCI.
Arne
Actually, what the option list starts with is "For customers wishing
to move away from Oracle, we are able to....."

Now, it is not fully clear from the context if "Oracle" refers to
“Oracle Inc” or “Oracle Classic”... :-)

If it refers to "Oracle Inc", then Rdb is not an option, I guess...
Dave Froble
2021-01-20 17:11:04 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Actually, what the option list starts with is "For customers wishing
to move away from Oracle, we are able to....."
Now, it is not fully clear from the context if "Oracle" refers to
“Oracle Inc” or “Oracle Classic”... :-)
If it refers to "Oracle Inc", then Rdb is not an option, I guess...
Perhaps the understanding that one's perceptions is one's reality.
However, those perceptions can vary widely.

To me, personally, Rdb and Oracle anything are pretty much separate,
other than the fact that Oracle owns Rdb. Perhaps I'm unique, perhaps
this is a common perception. I have no way of knowing. But, why not
guess that I am correct? As good as any other option.

I'd guess that most using VMS also know about Rdb. If so, not much
ambiguity for them when considering Rdb and Oracle classic. So
addressing options for Oracle users really does not need to mention Rdb.

What I found interesting is the SQL Relay software. Without knowing
much about it, it still seems to be a solution, for those willing to use
third party software.

My first thought when I got the announcement from VSI was "another issue
to slow down the completion of the port to x86".
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Craig A. Berry
2021-01-20 19:51:40 UTC
Reply
Permalink
What I found interesting is the SQL Relay software.  Without knowing
much about it, it still seems to be a solution, for those willing to use
third party software.
It's a library that speaks its own network protocol to a remote proxy
agent that in turn talks to the remote database. It might not have been
that hard to port the client. For people already calling a C API or
something built on one, it could be a solution that is not too painful.
But for people using a SQL precompiler for one of the traditional
languages, there's a lot of pain headed their way.
Arne Vajhøj
2021-01-20 20:30:40 UTC
Reply
Permalink
Post by Craig A. Berry
What I found interesting is the SQL Relay software.  Without knowing
much about it, it still seems to be a solution, for those willing to
use third party software.
It's a library that speaks its own network protocol to a remote proxy
agent that in turn talks to the remote database.  It might not have been
that hard to port the client.  For people already calling a C API or
something built on one, it could be a solution that is not too painful.
But for people using a SQL precompiler for one of the traditional
languages, there's a lot of pain headed their way.
So it would be:

app VMS
SQL Relay client
|
(SQL Relay protocol) -----
|
SQL Relay proxy Linux
Oracle client
|
(Oracle protocol) -----
|
Oracle DB Linux

?

Arne
Craig A. Berry
2021-01-20 20:44:54 UTC
Reply
Permalink
Post by Craig A. Berry
What I found interesting is the SQL Relay software.  Without knowing
much about it, it still seems to be a solution, for those willing to
use third party software.
It's a library that speaks its own network protocol to a remote proxy
agent that in turn talks to the remote database.  It might not have been
that hard to port the client.  For people already calling a C API or
something built on one, it could be a solution that is not too painful.
But for people using a SQL precompiler for one of the traditional
languages, there's a lot of pain headed their way.
       app              VMS
 SQL Relay client
        |
(SQL Relay protocol)   -----
        |
 SQL Relay proxy       Linux
  Oracle client
        |
 (Oracle protocol)     -----
        |
    Oracle DB          Linux
?
That is my understanding. Read all about it here:

<http://sqlrelay.sourceforge.net>
Jan-Erik Söderholm
2021-01-20 22:46:03 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Craig A. Berry
What I found interesting is the SQL Relay software.  Without knowing
much about it, it still seems to be a solution, for those willing to
use third party software.
It's a library that speaks its own network protocol to a remote proxy
agent that in turn talks to the remote database.  It might not have been
that hard to port the client.  For people already calling a C API or
something built on one, it could be a solution that is not too painful.
But for people using a SQL precompiler for one of the traditional
languages, there's a lot of pain headed their way.
        app              VMS
  SQL Relay client
         |
(SQL Relay protocol)   -----
         |
  SQL Relay proxy       Linux
   Oracle client
         |
  (Oracle protocol)     -----
         |
     Oracle DB          Linux
?
<http://sqlrelay.sourceforge.net>
Very much like the "Rdb Transparent Gateway to ODBC data" that is
(was) part of the "Database Integration" (DBI) kit, that is still
available unsupported from Oracle for Alpha.

That gateway (that had a standard Rdb SQL interface so it could
be called from any VMS language using the Rdb SQL precompiler, the
application did not now it was not accessing a real Rdb database)
connected to a Windows box where you can access any database (or
"data source") that had a ODBC driver.
Arne Vajhøj
2021-01-20 23:55:04 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Craig A. Berry
Post by Craig A. Berry
What I found interesting is the SQL Relay software.  Without
knowing much about it, it still seems to be a solution, for those
willing to use third party software.
It's a library that speaks its own network protocol to a remote proxy
agent that in turn talks to the remote database.  It might not have been
that hard to port the client.  For people already calling a C API or
something built on one, it could be a solution that is not too painful.
But for people using a SQL precompiler for one of the traditional
languages, there's a lot of pain headed their way.
        app              VMS
  SQL Relay client
         |
(SQL Relay protocol)   -----
         |
  SQL Relay proxy       Linux
   Oracle client
         |
  (Oracle protocol)     -----
         |
     Oracle DB          Linux
?
<http://sqlrelay.sourceforge.net>
Very much like the "Rdb Transparent Gateway to ODBC data" that is
(was) part of the "Database Integration" (DBI) kit, that is still
available unsupported from Oracle for Alpha.
That gateway (that had a standard Rdb SQL interface so it could
be called from any VMS language using the Rdb SQL precompiler, the
application did not now it was not accessing a real Rdb database)
connected to a Windows box where you can access any database (or
"data source") that had a ODBC driver.
The concept is pretty well-known.

Just in the J world I know of:
* type 3 JDBC drivers
* Apache ShardingsSphere proxy
* PHP JDBC Bridge

But it will be a new client API. The applications will need
to be changed.

That may be a small thing or a big thing depending on how
well the database access is encapsulated.

Arne
Jan-Erik Söderholm
2021-01-21 00:05:57 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Craig A. Berry
Post by Craig A. Berry
What I found interesting is the SQL Relay software.  Without knowing
much about it, it still seems to be a solution, for those willing to
use third party software.
It's a library that speaks its own network protocol to a remote proxy
agent that in turn talks to the remote database.  It might not have been
that hard to port the client.  For people already calling a C API or
something built on one, it could be a solution that is not too painful.
But for people using a SQL precompiler for one of the traditional
languages, there's a lot of pain headed their way.
        app              VMS
  SQL Relay client
         |
(SQL Relay protocol)   -----
         |
  SQL Relay proxy       Linux
   Oracle client
         |
  (Oracle protocol)     -----
         |
     Oracle DB          Linux
?
<http://sqlrelay.sourceforge.net>
Very much like the "Rdb Transparent Gateway to ODBC data" that is
(was) part of the "Database Integration" (DBI) kit, that is still
available unsupported from Oracle for Alpha.
That gateway (that had a standard Rdb SQL interface so it could
be called from any VMS language using the Rdb SQL precompiler, the
application did not now it was not accessing a real Rdb database)
connected to a Windows box where you can access any database (or
"data source") that had a ODBC driver.
The concept is pretty well-known.
* type 3 JDBC drivers
* Apache ShardingsSphere proxy
* PHP JDBC Bridge
But it will be a new client API. The applications will need
to be changed.
Right.
The good thing with the DBI gateway was that it was *transparent*.
No new client API and no changes to applications.

Ah well, water under the bridges, I guess... :-)
Post by Arne Vajhøj
That may be a small thing or a big thing depending on how
well the database access is encapsulated.
Arne
Loading...