Discussion:
Required core open source libraries on VMS ?, was: Re: Simple menu tool for VT-screen users?
(too old to reply)
Simon Clubley
2020-05-06 17:42:34 UTC
Permalink
On 2020-05-06, Arne Vajhøj <***@vajhoej.dk> wrote:

[I've started a new thread so Jan-Erik doesn't have to wade through the
replies looking for answers to his original question.]
Thanks! One more option to evaluate... :-)
You could always try porting the following from Linux: :-)
https://github.com/daniel64/lspf
I did a search for fun, not expecting to find anything, but was surprised
to see that someone had actually done this. :-)
C++, Boost and ncurses.
When I saw the project I was more amused that someone had done
an ISPF clone for Linux, however you make a good point.

For the compilers, VSI (IIRC) are packaging all the compilers and
other layered products into one product so at least you don't have
to buy an expensive C++ compiler just to port some open source
software.

I don't know if Boost would compile with the current HPE C++ compiler
(Boost is tested back to GCC 4.4.7 according to their notes, but I don't
know how that relates to what is available in the HPE C++ compiler).

That shouldn't be a problem for LLVM based C++ on VMS, but it raises
a more interesting question:

What do people consider to be the required core set of open source
libraries that need to be available on VMS before the application
level open source projects can be ported to 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-05-06 18:10:23 UTC
Permalink
Post by Simon Clubley
You could always try porting the following from Linux: :-)
https://github.com/daniel64/lspf
I did a search for fun, not expecting to find anything, but was surprised
to see that someone had actually done this. :-)
C++, Boost and ncurses.
When I saw the project I was more amused that someone had done
an ISPF clone for Linux, however you make a good point.
For the compilers, VSI (IIRC) are packaging all the compilers and
other layered products into one product so at least you don't have
to buy an expensive C++ compiler just to port some open source
software.
I don't know if Boost would compile with the current HPE C++ compiler
(Boost is tested back to GCC 4.4.7 according to their notes, but I don't
know how that relates to what is available in the HPE C++ compiler).
I would be rather pessimistic.
Post by Simon Clubley
That shouldn't be a problem for LLVM based C++ on VMS, but it raises
True. The future looks much better.
Post by Simon Clubley
What do people consider to be the required core set of open source
libraries that need to be available on VMS before the application
level open source projects can be ported to VMS ?
For C++?

I am sure C++, Java and Python developers will have very different
priorities.

:-)

For C++ I will suggest:
* Boost
* gRPC
* Thrift
* MySQL Connector C++
* libpq++
* ActiveMQ CMS
* RocksDB
* MongODB client
* Xerces and Xalan

But I am sure other people will have different suggestions.

Note that C++ will also need a larger number of C libraries.

Arne
Craig A. Berry
2020-05-07 20:00:13 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
You could always try porting the following from Linux: :-)
https://github.com/daniel64/lspf
I did a search for fun, not expecting to find anything, but was surprised
to see that someone had actually done this. :-)
C++, Boost and ncurses.
When I saw the project I was more amused that someone had done
an ISPF clone for Linux, however you make a good point.
For the compilers, VSI (IIRC) are packaging all the compilers and
other layered products into one product so at least you don't have
to buy an expensive C++ compiler just to port some open source
software.
I don't know if Boost would compile with the current HPE C++ compiler
(Boost is tested back to GCC 4.4.7 according to their notes, but I don't
know how that relates to what is available in the HPE C++ compiler).
I would be rather pessimistic.
Post by Simon Clubley
That shouldn't be a problem for LLVM based C++ on VMS, but it raises
True. The future looks much better.
Post by Simon Clubley
What do people consider to be the required core set of open source
libraries that need to be available on VMS before the application
level open source projects can be ported to VMS ?
For C++?
I am sure C++, Java and Python developers will have very different
priorities.
:-)
* Boost
* gRPC
* Thrift
* MySQL Connector C++
* libpq++
* ActiveMQ CMS
* RocksDB
* MongODB client
* Xerces and Xalan
About half of these have already been released by VSI (see the roadmap).
Post by Arne Vajhøj
But I am sure other people will have different suggestions.
Note that C++ will also need a larger number of C libraries.
There are a pile of libraries, interfaces, and tools that are commonly
expected by various open source packages. Some of the first that come
to mind are, in no particular order:

* libevent or some other modern event-handling interface
* Better and/or lighter weight XML tools, e.g. expat, libxml2
* something for handling configurations, possibly libconfig
* CRTL pipe that is actually stream-oriented
* CRTL pthread_sigsetmask so not all signals get delivered to the main
thread
* CRTL strlcpy and friends or strcpy_s and friends
* CRTL updated stat struct with struct timespec time members rather than
time_t
* A thorough review of all POSIX interfaces to make sure they comply
with current POSIX rather than some 20-year-old version
* select() that works on more than just sockets
* Cmake, which they need anyway if they eventually want to build LLVM
natively
Arne Vajhøj
2020-05-07 20:08:51 UTC
Permalink
Post by Craig A. Berry
Post by Arne Vajhøj
* Boost
* gRPC
* Thrift
* MySQL Connector C++
* libpq++
* ActiveMQ CMS
* RocksDB
* MongODB client
* Xerces and Xalan
About half of these have already been released by VSI (see the roadmap).
Really?

I have the December one.

I guess XML C++ is Xerces and Xalan.

But I would expect ActiveMQ to be ActiveMQ itself without
all the client libs inlcuding CMS.

It has the MariaDB/MySQL and PostgreSQL C libraries but I do
not see the C++ libraries.

Do you have another list?

Arne
Craig A. Berry
2020-05-07 20:16:29 UTC
Permalink
Post by Arne Vajhøj
Post by Craig A. Berry
Post by Arne Vajhøj
* Boost
* gRPC
* Thrift
* MySQL Connector C++
* libpq++
* ActiveMQ CMS
* RocksDB
* MongODB client
* Xerces and Xalan
About half of these have already been released by VSI (see the roadmap).
Really?
I have the December one.
I guess XML C++ is Xerces and Xalan.
Yes.
Post by Arne Vajhøj
But I would expect ActiveMQ to be ActiveMQ itself without
all the client libs inlcuding CMS.
OK. I don't know ActiveMQ meant more than one thing.
Post by Arne Vajhøj
It has the MariaDB/MySQL and PostgreSQL C libraries but I do
not see the C++ libraries.
Why would there be a difference, except possibly some very thin wrapper
around the C libraries?
Arne Vajhøj
2020-05-07 20:33:59 UTC
Permalink
Post by Arne Vajhøj
Post by Craig A. Berry
Post by Arne Vajhøj
* Boost
* gRPC
* Thrift
* MySQL Connector C++
* libpq++
* ActiveMQ CMS
* RocksDB
* MongODB client
* Xerces and Xalan
About half of these have already been released by VSI (see the roadmap).
Really?
I have the December one.
I guess XML C++ is Xerces and Xalan.
Yes.
Post by Arne Vajhøj
But I would expect ActiveMQ to be ActiveMQ itself without
all the client libs inlcuding CMS.
OK.  I don't know ActiveMQ meant more than one thing.
Usually ActiveMQ just means the message queue itself
including the Java client library.

Other client libraries are separate projects/downloads.

The Apache ActiveMQ project are providing a few clients
itself including NMS for .NET and CMS for C++. But
still separate.
Post by Arne Vajhøj
It has the MariaDB/MySQL and PostgreSQL C libraries but I do
not see the C++ libraries.
Why would there be a difference, except possibly some very thin wrapper
around the C libraries?
Except that is is not a very thin wrapper. At least not MySQL.

MySQL C++ API does not look like MySQL C API at all - instead
it is modeled over JDBC.

I don't know anything about libpq++.

Arne
Jan-Erik Söderholm
2020-05-06 23:44:45 UTC
Permalink
Post by Simon Clubley
[I've started a new thread so Jan-Erik doesn't have to wade through the
replies looking for answers to his original question.]
Sure, thanks. I have done a lot of development in MVS/TSO/ISPF
environment many years ago so that was an interesting thing. :-)

At work (at the custumer site) there are also some systems
built on IBm i systems (former AS/400) that is mainly menu
based, even for sysmgr's.

But I'll try to options that has been mentioned here...

Jan-Erik.
Post by Simon Clubley
Thanks! One more option to evaluate... :-)
You could always try porting the following from Linux: :-)
https://github.com/daniel64/lspf
I did a search for fun, not expecting to find anything, but was surprised
to see that someone had actually done this. :-)
C++, Boost and ncurses.
When I saw the project I was more amused that someone had done
an ISPF clone for Linux, however you make a good point.
For the compilers, VSI (IIRC) are packaging all the compilers and
other layered products into one product so at least you don't have
to buy an expensive C++ compiler just to port some open source
software.
I don't know if Boost would compile with the current HPE C++ compiler
(Boost is tested back to GCC 4.4.7 according to their notes, but I don't
know how that relates to what is available in the HPE C++ compiler).
That shouldn't be a problem for LLVM based C++ on VMS, but it raises
What do people consider to be the required core set of open source
libraries that need to be available on VMS before the application
level open source projects can be ported to VMS ?
Simon.
Stephen Hoffman
2020-05-11 18:33:37 UTC
Permalink
Post by Simon Clubley
What do people consider to be the required core set of open source
libraries that need to be available on VMS before the application level
open source projects can be ported to VMS ?
Pondering that somewhat differently, what services are expected?

Integrated IP networking, Apache web services, LDAP, integrated
database support (SQLite and PostgreSQL—and folks with Oracle licenses
or those fully satisfied with RMS, thank you and please back sit down),
passwords and certificates and encryption and two-factor
authentication, etc.

Decisions around implementing and integrating those and other services
then propagates back into (some of) the necessary libraries.

CMake, ncurses, pipes, select(), libxml2, etc., have all been
mentioned. Fewer jackets.

This scatter-shot approach toward networking and network services and
security reminds me of the similarly-scatter-shot host name
implementation, this having just re-encountered the host name that gets
embedded in the queue database.
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2020-05-11 19:59:39 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
What do people consider to be the required core set of open source
libraries that need to be available on VMS before the application level
open source projects can be ported to VMS ?
Different strokes for different folks, probably.
Post by Stephen Hoffman
Integrated IP networking,
Yes.
Post by Stephen Hoffman
Apache web services,
No.
Post by Stephen Hoffman
LDAP,
Probably

integrated
Post by Stephen Hoffman
database support (SQLite and PostgreSQL---and folks with Oracle licenses
or those fully satisfied with RMS, thank you and please back sit down),
How about Rdb shipping with the OS at no extra cost. :-D

Seriously, I can't think of any reason (except, perhaps, in some cases,
cost, but then one does get what one pays for) why anyone would use any
database other than Rdb on VMS.
Post by Stephen Hoffman
passwords and certificates and encryption and two-factor
authentication, etc.
Probably.
Arne Vajhøj
2020-05-11 23:20:18 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
database support (SQLite and PostgreSQL---and folks with Oracle licenses
or those fully satisfied with RMS, thank you and please back sit down),
How about Rdb shipping with the OS at no extra cost. :-D
Seriously, I can't think of any reason (except, perhaps, in some cases,
cost, but then one does get what one pays for) why anyone would use any
database other than Rdb on VMS.
RDB is a pretty good database. Reliable, performant,
good support for the available programming languages.

There are a few "modern" features missing, but my guess
would be that cost is the main reason for not using RDB.

And if someone are curious about the "modern" features,
then we went through them a year ago: newer SQL syntax like
CTE, full text search capability, builtin XML and JSON
support.

I suspect that 95% of people writing code accessing
a database have never used any of those.

Arne
Phillip Helbig (undress to reply)
2020-05-12 06:26:56 UTC
Permalink
Post by Arne Vajhøj
RDB is a pretty good database. Reliable, performant,
good support for the available programming languages.
There are a few "modern" features missing, but my guess
would be that cost is the main reason for not using RDB.
And if someone are curious about the "modern" features,
then we went through them a year ago: newer SQL syntax like
CTE, full text search capability, builtin XML and JSON
support.
I suspect that 95% of people writing code accessing
a database have never used any of those.
Right; they are probably using COBOL or Fortran. Having done both old
and new stuff here, I prefer the old. :-)
Bill Gunshannon
2020-05-12 12:10:30 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
RDB is a pretty good database. Reliable, performant,
good support for the available programming languages.
There are a few "modern" features missing, but my guess
would be that cost is the main reason for not using RDB.
And if someone are curious about the "modern" features,
then we went through them a year ago: newer SQL syntax like
CTE, full text search capability, builtin XML and JSON
support.
I suspect that 95% of people writing code accessing
a database have never used any of those.
Right; they are probably using COBOL or Fortran. Having done both old
and new stuff here, I prefer the old. :-)
It would be really nice if someone took the time to add RDB to the
"Comparison of relational database management systems" wiki page.
It is conspicuous by it's absence. The only other large system I
am aware of that is missing is Unisys DMS-11.

bill
Arne Vajhøj
2020-05-12 12:22:33 UTC
Permalink
Post by Bill Gunshannon
It would be really nice if someone took the time to add RDB to the
"Comparison of relational database management systems" wiki page.
It is conspicuous by it's absence.  The only other large system I
am aware of that is missing is Unisys DMS-11.
This:

https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

?

Several of the tables do have "Oracle RDB" (a few are missing though).

Arne
Jan-Erik Söderholm
2020-05-12 12:44:00 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
It would be really nice if someone took the time to add RDB to the
"Comparison of relational database management systems" wiki page.
It is conspicuous by it's absence.  The only other large system I
am aware of that is missing is Unisys DMS-11.
https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
?
Several of the tables do have "Oracle RDB" (a few are missing though).
Arne
And in some places Oracle Rdb has an "?" where it should be a "Yes".
Bill Gunshannon
2020-05-12 13:10:06 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Bill Gunshannon
It would be really nice if someone took the time to add RDB to the
"Comparison of relational database management systems" wiki page.
It is conspicuous by it's absence.  The only other large system I
am aware of that is missing is Unisys DMS-11.
https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
?
Several of the tables do have "Oracle RDB" (a few are missing though).
Arne
And in some places Oracle Rdb has an "?" where it should be a "Yes".
Then fix it. Can't anyone update a wiki?

bill
Bill Gunshannon
2020-05-12 13:09:04 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
It would be really nice if someone took the time to add RDB to the
"Comparison of relational database management systems" wiki page.
It is conspicuous by it's absence.  The only other large system I
am aware of that is missing is Unisys DMS-11.
https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
?
Several of the tables do have "Oracle RDB" (a few are missing though).
Your right. All these years I have missed it because I was not expecting
to see Oracle in the name. When I see Oracle, I think Oracle. :-)

bill
Arne Vajhøj
2020-05-12 14:15:56 UTC
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
It would be really nice if someone took the time to add RDB to the
"Comparison of relational database management systems" wiki page.
It is conspicuous by it's absence.  The only other large system I
am aware of that is missing is Unisys DMS-11.
https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
?
Several of the tables do have "Oracle RDB" (a few are missing though).
Your right. All these years I have missed it because I was not expecting
to see Oracle in the name.  When I see Oracle, I think Oracle.  :-)
Bob Palmer sold RDB to Oracle in 1994 - and DEC RDB became Oracle RDB.
And they use the name "Oracle RDB".

https://www.oracle.com/database/technologies/related/rdb.html

Arne
Jan-Erik Söderholm
2020-05-12 14:22:33 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
It would be really nice if someone took the time to add RDB to the
"Comparison of relational database management systems" wiki page.
It is conspicuous by it's absence.  The only other large system I
am aware of that is missing is Unisys DMS-11.
https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
?
Several of the tables do have "Oracle RDB" (a few are missing though).
Your right. All these years I have missed it because I was not expecting
to see Oracle in the name.  When I see Oracle, I think Oracle.  :-)
Bob Palmer sold RDB to Oracle in 1994 - and DEC RDB became Oracle RDB.
And they use the name "Oracle RDB".
https://www.oracle.com/database/technologies/related/rdb.html
Arne
No. It is called "Oracle Rdb". Rdb has never (not by DEC nor by Oracle)
been spelled in all upper case.
Arne Vajhøj
2020-05-12 14:25:25 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
It would be really nice if someone took the time to add RDB to the
"Comparison of relational database management systems" wiki page.
It is conspicuous by it's absence.  The only other large system I
am aware of that is missing is Unisys DMS-11.
https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
?
Several of the tables do have "Oracle RDB" (a few are missing though).
Your right. All these years I have missed it because I was not expecting
to see Oracle in the name.  When I see Oracle, I think Oracle.  :-)
Bob Palmer sold RDB to Oracle in 1994 - and DEC RDB became Oracle RDB.
And they use the name "Oracle RDB".
https://www.oracle.com/database/technologies/related/rdb.html
No. It is called "Oracle Rdb". Rdb has never (not by DEC nor by Oracle)
been spelled in all upper case.
Ooops.

I stand corrected.

"Oracle Rdb"

Arne
Bill Gunshannon
2020-05-12 17:32:53 UTC
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
It would be really nice if someone took the time to add RDB to the
"Comparison of relational database management systems" wiki page.
It is conspicuous by it's absence.  The only other large system I
am aware of that is missing is Unisys DMS-11.
https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
?
Several of the tables do have "Oracle RDB" (a few are missing though).
Your right. All these years I have missed it because I was not expecting
to see Oracle in the name.  When I see Oracle, I think Oracle.  :-)
Bob Palmer sold RDB to Oracle in 1994 - and DEC RDB became Oracle RDB.
And they use the name "Oracle RDB".
https://www.oracle.com/database/technologies/related/rdb.html
No. It is called "Oracle Rdb". Rdb has never (not by DEC nor by Oracle)
been spelled in all upper case.
Ooops.
I stand corrected.
"Oracle Rdb"
I thought VMS users were proudly monocase in which case both are
the same. :-)

bill
Jan-Erik Söderholm
2020-05-12 21:00:06 UTC
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
It would be really nice if someone took the time to add RDB to the
"Comparison of relational database management systems" wiki page.
It is conspicuous by it's absence.  The only other large system I
am aware of that is missing is Unisys DMS-11.
https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
?
Several of the tables do have "Oracle RDB" (a few are missing though).
Your right. All these years I have missed it because I was not expecting
to see Oracle in the name.  When I see Oracle, I think Oracle.  :-)
Bob Palmer sold RDB to Oracle in 1994 - and DEC RDB became Oracle RDB.
And they use the name "Oracle RDB".
https://www.oracle.com/database/technologies/related/rdb.html
No. It is called "Oracle Rdb". Rdb has never (not by DEC nor by Oracle)
been spelled in all upper case.
Ooops.
I stand corrected.
"Oracle Rdb"
I thought VMS users were proudly monocase in which case both are
the same.  :-)
bill
It is partly to be less like with "Oracle RDBMS", which sometimes is
used to name the "original" Oracle database.

Anyway, in 1994 he general thought was that Rdb would merge with RDBMS
but that didn't happen. Not fully sure why, but I think that customer
feedback had something to do with it.

At the Oracle/HPE/Itanium debacle some years ago, Rdb was "frozen"
at version 7.3 and the thought was that it was the final version.
But now it sounds like a version 7.4 will be shipped.
Arne Vajhøj
2020-05-12 23:28:36 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Bob Palmer sold RDB to Oracle in 1994 - and DEC RDB became Oracle RDB.
And they use the name "Oracle RDB".
https://www.oracle.com/database/technologies/related/rdb.html
No. It is called "Oracle Rdb". Rdb has never (not by DEC nor by Oracle)
been spelled in all upper case.
Ooops.
I stand corrected.
"Oracle Rdb"
I thought VMS users were proudly monocase in which case both are
the same.  :-)
It is partly to be less like with "Oracle RDBMS", which sometimes is
used to name the "original" Oracle database.
I think Oracle DB is way more common today.
Post by Jan-Erik Söderholm
Anyway, in 1994 he general thought was that Rdb would merge with RDBMS
but that didn't happen. Not fully sure why, but I think that customer
feedback had something to do with it.
I think a fair guess would be the usual: it would break too
many existing applications and that is why there were
little appetite.
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was "frozen"
at version 7.3 and the thought was that it was the final version.
But now it sounds like a version 7.4 will be shipped.
For VMS x86-64?

Arne
Jan-Erik Söderholm
2020-08-19 18:56:44 UTC
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was "frozen"
at version 7.3 and the thought was that it was the final version.
But now it sounds like a version 7.4 will be shipped.
For VMS x86-64?
Arne
Rdb 7.4.1.0 was released today.

https://www.oracle.com/database/technologies/related/rdb-doc.html

Alpha and IA64. What will be the first version on x86 is still to be seen.

From the email notification:

"Oracle Rdb 7.4.1.0 shipped on August 10, 2020. Some of the features
included in this release have been under development for several years.

A full description of all the new features and enhancements made in this
release and the problems fixed can be found in the release notes. A summary
of those features and fixes is included in the attached readme.

With Oracle Rdb 7.4.1.0 you will be able to continue in Premier Support
past the dates published for 7.3. Details of the 7.4 support dates will be
published in the Oracle Lifetime Support Policies document (see
http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf
) in early September."



Jan-Erik.
Phillip Helbig (undress to reply)
2020-08-19 21:13:06 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was "frozen"
at version 7.3 and the thought was that it was the final version.
But now it sounds like a version 7.4 will be shipped.
Rdb 7.4.1.0 was released today.
The version-freezing stuff was because of the battle between Oracle and
HP, but with HP now out of the picture, that might be moot.

Oracle did something similar itself when 8.0 was renamed 7.3 since
people don't like to install .0 releases. :-| A rose, by any other
name, would smell as sweet.

Dave Froble
2020-05-13 00:12:32 UTC
Permalink
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was "frozen"
at version 7.3 and the thought was that it was the final version.
But now it sounds like a version 7.4 will be shipped.
Last I heard, Rdb support was still in or near Massachusetts, which
sounds like Oracle wasn't dumb and acquired the DEC people who developed
Rdb. Can't remember the one guy's name.

So, if Oracle intended to milk Rdb, they needed qualified people to
provide support. Hey, it's a cash cow, right? Lose that quality
business if they moved support to India and let the experts go, right?
Only HP could be so stupid. (Well, I'd guess HP doesn't have a monopoly
on stupidity, but they keep the average up.)

Now Oracle has those dedicated people, which I'd guess don't work on
anything else. So what to do with them when they're sitting around
doing nothing? Any reasonable business man would have them spending
that time on enhancements, and yes, new versions.

I seem to recall that the "last version" thing was part of the HP /
Oracle spat over the itanic. Which I seem to recall was over HP/UX,
much more so than VMS. The "last version" still got work, just not new
names. What's in a name? Nothing really. Now HP is out of the
picture, and Oracle can use new names, if they so choose.
--
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-05-13 00:28:14 UTC
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was "frozen"
at version 7.3 and the thought was that it was the final version.
But now it sounds like a version 7.4 will be shipped.
Last I heard, Rdb support was still in or near Massachusetts, which
sounds like Oracle wasn't dumb and acquired the DEC people who developed
Rdb.  Can't remember the one guy's name.
So, if Oracle intended to milk Rdb, they needed qualified people to
provide support.  Hey, it's a cash cow, right?  Lose that quality
business if they moved support to India and let the experts go, right?
Only HP could be so stupid.  (Well, I'd guess HP doesn't have a monopoly
on stupidity, but they keep the average up.)
Now Oracle has those dedicated people, which I'd guess don't work on
anything else.  So what to do with them when they're sitting around
doing nothing?  Any reasonable business man would have them spending
that time on enhancements, and yes, new versions.
I seem to recall that the "last version" thing was part of the HP /
Oracle spat over the itanic.  Which I seem to recall was over HP/UX,
much more so than VMS.  The "last version" still got work, just not new
names.  What's in a name?  Nothing really.  Now HP is out of the
picture, and Oracle can use new names, if they so choose.
And while Itanium does not have a future then x86-64 has.

Which changes the business situation for Oracle Rdb in a positive
direction.

Arne
Phillip Helbig (undress to reply)
2020-05-13 05:16:31 UTC
Permalink
Post by Dave Froble
Last I heard, Rdb support was still in or near Massachusetts, which
sounds like Oracle wasn't dumb and acquired the DEC people who developed
Rdb. Can't remember the one guy's name.
Indeed.
Post by Dave Froble
I seem to recall that the "last version" thing was part of the HP /
Oracle spat over the itanic. Which I seem to recall was over HP/UX,
much more so than VMS. The "last version" still got work, just not new
names. What's in a name? Nothing really. Now HP is out of the
picture, and Oracle can use new names, if they so choose.
Right.
Phillip Helbig (undress to reply)
2020-05-13 05:15:28 UTC
Permalink
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was "frozen"
at version 7.3 and the thought was that it was the final version.
But now it sounds like a version 7.4 will be shipped.
Not really. Basically, instead of 7.4, 7.5, etc. there was 7.3.x,
7.3.y, 7.3.z etc. This had a precedent; 7.3 was supposed to be 8.0, and
I think that 8.0 was actually mentioned in a book and/or some
documentation, but it was changed to 7.3 to calm people who didn't want
to install a .0 release. :-)
Richard Maher
2020-05-14 02:55:45 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was "frozen"
at version 7.3 and the thought was that it was the final version.
But now it sounds like a version 7.4 will be shipped.
Not really. Basically, instead of 7.4, 7.5, etc. there was 7.3.x,
7.3.y, 7.3.z etc. This had a precedent; 7.3 was supposed to be 8.0,
and I think that 8.0 was actually mentioned in a book and/or some
documentation, but it was changed to 7.3 to calm people who didn't
want to install a .0 release. :-)
I wondered what the real reason was. I suspected Larry said there'd
never be a version 8?

I had the original release notes watermarked Rdb8 many moons ago
Jan-Erik Söderholm
2020-05-14 06:28:02 UTC
Permalink
At the Oracle/HPE/Itanium debacle some years ago, Rdb was "frozen" at
version 7.3 and the thought was that it was the final version. But now
it sounds like a version 7.4 will be shipped.
Not really.  Basically, instead of 7.4, 7.5, etc. there was 7.3.x, 7.3.y,
7.3.z etc.  This had a precedent; 7.3 was supposed to be 8.0,
and I think that 8.0 was actually mentioned in a book and/or some
documentation, but it was changed to 7.3 to calm people who didn't
want to install a .0 release.  :-)
I wondered what the real reason was. I suspected Larry said there'd never
be a version 8?
I had the original release notes watermarked Rdb8 many moons ago
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)

Version 7.3 (.x.x) was locked by the Oracle document that specified
the final version for Oracle software for Itanium. Rdb was actually
officially at 7.2 at the time, but a quick release of 7.3 to one or
two customers made 7.3 to go into that Oracle document.

Now it seems as this have been relaxed somewhat, maybe they plan
7.4 for X86-64 and that way they can still follow the Itanium
locked-vesions document. I don't know...
Richard Maher
2020-05-15 02:21:05 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Richard Maher
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?=
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was
"frozen" at version 7.3 and the thought was that it was the
final version. But now it sounds like a version 7.4 will be
shipped.
Not really. Basically, instead of 7.4, 7.5, etc. there was
7.3.x, 7.3.y, 7.3.z etc. This had a precedent; 7.3 was supposed
to be 8.0, and I think that 8.0 was actually mentioned in a book
and/or some documentation, but it was changed to 7.3 to calm
people who didn't want to install a .0 release. :-)
I wondered what the real reason was. I suspected Larry said there'd
never be a version 8?
I had the original release notes watermarked Rdb8 many moons ago
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
They were VMS functionality release notes
Jan-Erik Söderholm
2020-05-15 07:03:39 UTC
Permalink
Post by Richard Maher
Post by Jan-Erik Söderholm
Post by Richard Maher
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?=
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was
"frozen" at version 7.3 and the thought was that it was the
final version. But now it sounds like a version 7.4 will be
shipped.
Not really.  Basically, instead of 7.4, 7.5, etc. there was
7.3.x, 7.3.y, 7.3.z etc.  This had a precedent; 7.3 was supposed
to be 8.0, and I think that 8.0 was actually mentioned in a book
and/or some documentation, but it was changed to 7.3 to calm
people who didn't want to install a .0 release.  :-)
I wondered what the real reason was. I suspected Larry said there'd
 never be a version 8?
I had the original release notes watermarked Rdb8 many moons ago
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
They were VMS functionality release notes
Yes, I'm sure there would have been a VMS version of V8.0 also,
but the "big thing" with V8.0 was the Win/NT support.

The third edition of "Rdb, A Comprehensive Guide" by Lilin Hobbs, Ian
Smith and Ken England was updated with a chapter "Rdb/NT Workbench".

To quote from the first paragraph from the book:

"The Rdb/NT Workbench, the version of Rdb which runs on Intel Windows
NT, can be downloaded via the Web from the Oracle Technology Network at
http://technet.oracle.com. Unfortunately, this version may not be used
on a production system. However, since it contains the majority of Rdb
functionality, it is ideal for trying out ideas and testing how Rdb
behaves. Now you can install Rdb on your laptop and always have it
with out."


F
Richard Maher
2020-05-16 02:12:21 UTC
Permalink
Post by Richard Maher
Post by Jan-Erik Söderholm
On 13/05/2020 1:15 pm, Phillip Helbig (undress to reply)
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?=
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was
"frozen" at version 7.3 and the thought was that it was
the final version. But now it sounds like a version 7.4
will be shipped.
Not really. Basically, instead of 7.4, 7.5, etc. there was
7.3.x, 7.3.y, 7.3.z etc. This had a precedent; 7.3 was
supposed to be 8.0, and I think that 8.0 was actually
mentioned in a book and/or some documentation, but it was
changed to 7.3 to calm people who didn't want to install a .0
release. :-)
I wondered what the real reason was. I suspected Larry said
there'd never be a version 8?
I had the original release notes watermarked Rdb8 many moons ago
8.0 was the Rdb/NT version. That was never released due to lack
of support for the BLISS compiler on NT (as it was told)
They were VMS functionality release notes
Yes, I'm sure there would have been a VMS version of V8.0 also, but
the "big thing" with V8.0 was the Win/NT support.
The third edition of "Rdb, A Comprehensive Guide" by Lilin Hobbs,
Ian Smith and Ken England was updated with a chapter "Rdb/NT
Workbench".
"The Rdb/NT Workbench, the version of Rdb which runs on Intel
Windows NT, can be downloaded via the Web from the Oracle Technology
Network at http://technet.oracle.com. Unfortunately, this version may
not be used on a production system. However, since it contains the
majority of Rdb functionality, it is ideal for trying out ideas and
testing how Rdb behaves. Now you can install Rdb on your laptop and
always have it with out."
F
Yes I recall certain Rdb engineers rubbing their hands with glee that
they could abandon VMS.
Jan-Erik Söderholm
2020-05-15 07:43:00 UTC
Permalink
Post by Richard Maher
Post by Jan-Erik Söderholm
Post by Richard Maher
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?=
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was
"frozen" at version 7.3 and the thought was that it was the
final version. But now it sounds like a version 7.4 will be
shipped.
Not really.  Basically, instead of 7.4, 7.5, etc. there was
7.3.x, 7.3.y, 7.3.z etc.  This had a precedent; 7.3 was supposed
to be 8.0, and I think that 8.0 was actually mentioned in a book
and/or some documentation, but it was changed to 7.3 to calm
people who didn't want to install a .0 release.  :-)
I wondered what the real reason was. I suspected Larry said there'd
 never be a version 8?
I had the original release notes watermarked Rdb8 many moons ago
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
They were VMS functionality release notes
Yes, I'm sure that Rdb v8 would run on VMS also. But the big thing with
Rdb v8 was the support for Intel Windows NT.

The "Rdb A comprehensive Guide", third edition, was updated with a last
chapter called "Rdb/NT Workbench". It clearly says in the book that it
is more or less complete in functionallity but should not be used in
production use.
Phillip Helbig (undress to reply)
2020-05-15 06:59:35 UTC
Permalink
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Post by Jan-Erik Söderholm
Version 7.3 (.x.x) was locked by the Oracle document that specified
the final version for Oracle software for Itanium. Rdb was actually
officially at 7.2 at the time, but a quick release of 7.3 to one or
two customers made 7.3 to go into that Oracle document.
Yes, the idea being that new versions could come out as long as they
started with "7.3", thus fulfilling the letter of the agreement.
Post by Jan-Erik Söderholm
Now it seems as this have been relaxed somewhat, maybe they plan
7.4 for X86-64 and that way they can still follow the Itanium
locked-vesions document. I don't know...
We'll see.

A rose, by any other name, would smell as sweet.
Bill Gunshannon
2020-05-15 11:46:53 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Am I the only one who sees this and laughs? A number, in reality,
has absolutely nothing to do with how a program runs. If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.

Has IT become as superstitious as religion and baseball?

bill
Jan-Erik Söderholm
2020-05-15 11:51:39 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Am I the only one who sees this and laughs?  A number, in reality,
has absolutely nothing to do with how a program runs.  If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.
Has IT become as superstitious as religion and baseball?
bill
Usually a "dot-zero" release involves more and larger changes than
a minor release. So it is usual to take a little more care with them.
That has nothing to do with superstition. Of course, if you skip .0
and instead the .1 would be the first release, the same applies.
Bill Gunshannon
2020-05-15 13:14:16 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Am I the only one who sees this and laughs?  A number, in reality,
has absolutely nothing to do with how a program runs.  If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.
Has IT become as superstitious as religion and baseball?
bill
Usually a "dot-zero" release involves more and larger changes than
a minor release. So it is usual to take a little more care with them.
That has nothing to do with superstition.
Of course it does. The numbers are arbitrary. I could re-release
version 7.9 as version 8.0 with no change but the banner. It would
have no new bugs in it at all. And then, 6 months later I release
8.1 which is a major upgrade.
Post by Jan-Erik Söderholm
Of course, if you skip .0
and instead the .1 would be the first release, the same applies.
If you skipped .0 people might catch on. :-)

You have to fool them, it's part of the marketing game. Like the hotel
and 13th floor everyone believes it's OK.

bill
Dave Froble
2020-05-15 15:07:04 UTC
Permalink
Post by Bill Gunshannon
Post by Jan-Erik Söderholm
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Am I the only one who sees this and laughs? A number, in reality,
has absolutely nothing to do with how a program runs. If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.
Has IT become as superstitious as religion and baseball?
bill
Usually a "dot-zero" release involves more and larger changes than
a minor release. So it is usual to take a little more care with them.
That has nothing to do with superstition.
Of course it does. The numbers are arbitrary. I could re-release
version 7.9 as version 8.0 with no change but the banner. It would
have no new bugs in it at all. And then, 6 months later I release
8.1 which is a major upgrade.
Post by Jan-Erik Söderholm
Of course, if you skip .0
and instead the .1 would be the first release, the same applies.
If you skipped .0 people might catch on. :-)
You have to fool them, it's part of the marketing game. Like the hotel
and 13th floor everyone believes it's OK.
bill
Usually, when there are major changes, the choice is to change the major
release number. Just the way things seem to happen.

But yeah, it's stupid. The testing and such is the same.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2020-05-15 18:58:44 UTC
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Am I the only one who sees this and laughs?  A number, in reality,
has absolutely nothing to do with how a program runs.  If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.
Has IT become as superstitious as religion and baseball?
bill
Usually a "dot-zero" release involves more and larger changes than
a minor release. So it is usual to take a little more care with them.
That has nothing to do with superstition.
Of course it does.  The numbers are arbitrary. I could re-release
version 7.9 as version 8.0 with no change but the banner. It would
have no new bugs in it at all.  And then, 6 months later I release
8.1 which is a major upgrade.
Post by Jan-Erik Söderholm
                                              Of course, if you skip .0
and instead the .1 would be the first release, the same applies.
If you skipped .0 people might catch on.  :-)
You have to fool them, it's part of the marketing game.  Like the hotel
and 13th floor everyone believes it's OK.
bill
Usually, when there are major changes, the choice is to change the major
release number.  Just the way things seem to happen.
But yeah, it's stupid.  The testing and such is the same.
And Hoff just said that 8.0 was pulled back and released as 7.3.
Isn't that what I just said? Dave, you are right. In a decent
shop the testing required before use should be the same. So,
the fear of .0 releases really is just superstition. :-)

bill
Jan-Erik Söderholm
2020-05-15 21:26:47 UTC
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Am I the only one who sees this and laughs?  A number, in reality,
has absolutely nothing to do with how a program runs.  If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.
Has IT become as superstitious as religion and baseball?
bill
Usually a "dot-zero" release involves more and larger changes than
a minor release. So it is usual to take a little more care with them.
That has nothing to do with superstition.
Of course it does.  The numbers are arbitrary. I could re-release
version 7.9 as version 8.0 with no change but the banner. It would
have no new bugs in it at all.  And then, 6 months later I release
8.1 which is a major upgrade.
Post by Jan-Erik Söderholm
                                              Of course, if you skip .0
and instead the .1 would be the first release, the same applies.
If you skipped .0 people might catch on.  :-)
You have to fool them, it's part of the marketing game.  Like the hotel
and 13th floor everyone believes it's OK.
bill
Usually, when there are major changes, the choice is to change the major
release number.  Just the way things seem to happen.
But yeah, it's stupid.  The testing and such is the same.
And Hoff just said that 8.0 was pulled back and released as 7.3.
He said 7.1. Which is also what the page says Hoff linked to.
Post by Bill Gunshannon
Isn't that what I just said?  Dave, you are right. In a decent
shop the testing required before use should be the same.
Not really. An Rdb release that only change in the third and forth
position like 7.3.3.0 to 7.3.3.1, requires less testing and efforts
then say 7.2.5.8 to 7.3.0.0 which will also mean a "convert" of the
database files and more work to back out the update. Very different.
Post by Bill Gunshannon
So, the fear of .0 releases really is just superstition.  :-)
Having different testing strategies depending in the differences in
the actual update is not superstition. Is it just proper planning.
Post by Bill Gunshannon
bill
Bill Gunshannon
2020-05-15 21:41:48 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Bill Gunshannon
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of
installing a .0
release.
Am I the only one who sees this and laughs?  A number, in reality,
has absolutely nothing to do with how a program runs.  If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.
Has IT become as superstitious as religion and baseball?
bill
Usually a "dot-zero" release involves more and larger changes than
a minor release. So it is usual to take a little more care with them.
That has nothing to do with superstition.
Of course it does.  The numbers are arbitrary. I could re-release
version 7.9 as version 8.0 with no change but the banner. It would
have no new bugs in it at all.  And then, 6 months later I release
8.1 which is a major upgrade.
Post by Jan-Erik Söderholm
                                              Of course, if you
skip .0
and instead the .1 would be the first release, the same applies.
If you skipped .0 people might catch on.  :-)
You have to fool them, it's part of the marketing game.  Like the hotel
and 13th floor everyone believes it's OK.
bill
Usually, when there are major changes, the choice is to change the
major release number.  Just the way things seem to happen.
But yeah, it's stupid.  The testing and such is the same.
And Hoff just said that 8.0 was pulled back and released as 7.3.
He said 7.1. Which is also what the page says Hoff linked to.
Your right, but the point is the same. According to posts here if
it had been released as 8.0 therw would have ben trepidation about
using it. It was released as 7.1. But, in reality, it was still
a .0 release.
Post by Jan-Erik Söderholm
Post by Bill Gunshannon
Isn't that what I just said?  Dave, you are right. In a decent
shop the testing required before use should be the same.
Not really. An Rdb release that only change in the third and forth
position like 7.3.3.0 to 7.3.3.1, requires less testing and efforts
then say 7.2.5.8 to 7.3.0.0 which will also mean a "convert" of the
database files and more work to back out the update. Very different.
Post by Bill Gunshannon
So, the fear of .0 releases really is just superstition.  :-)
Having different testing strategies depending in the differences in
the actual update is not superstition. Is it just proper planning.
Sorry, but to my way of thinking the testing should be the same
noi matter what the number says. And assuming that . 0 release
is somehow different from any other is just superstition.

bill
Jan-Erik Söderholm
2020-05-15 21:54:13 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Bill Gunshannon
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Am I the only one who sees this and laughs?  A number, in reality,
has absolutely nothing to do with how a program runs.  If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.
Has IT become as superstitious as religion and baseball?
bill
Usually a "dot-zero" release involves more and larger changes than
a minor release. So it is usual to take a little more care with them.
That has nothing to do with superstition.
Of course it does.  The numbers are arbitrary. I could re-release
version 7.9 as version 8.0 with no change but the banner. It would
have no new bugs in it at all.  And then, 6 months later I release
8.1 which is a major upgrade.
Post by Jan-Erik Söderholm
                                              Of course, if you skip .0
and instead the .1 would be the first release, the same applies.
If you skipped .0 people might catch on.  :-)
You have to fool them, it's part of the marketing game.  Like the hotel
and 13th floor everyone believes it's OK.
bill
Usually, when there are major changes, the choice is to change the
major release number.  Just the way things seem to happen.
But yeah, it's stupid.  The testing and such is the same.
And Hoff just said that 8.0 was pulled back and released as 7.3.
He said 7.1. Which is also what the page says Hoff linked to.
Your right, but the point is the same.  According to posts here if
it had been released as 8.0 therw would have ben trepidation about
using it.  It was released as 7.1.  But, in reality, it was still
a .0 release.
Post by Jan-Erik Söderholm
Post by Bill Gunshannon
Isn't that what I just said?  Dave, you are right. In a decent
shop the testing required before use should be the same.
Not really. An Rdb release that only change in the third and forth
position like 7.3.3.0 to 7.3.3.1, requires less testing and efforts
then say 7.2.5.8 to 7.3.0.0 which will also mean a "convert" of the
database files and more work to back out the update. Very different.
Post by Bill Gunshannon
So, the fear of .0 releases really is just superstition.  :-)
Having different testing strategies depending in the differences in
the actual update is not superstition. Is it just proper planning.
Sorry, but to my way of thinking...
Maybe try to understand instead of having some weird own way of thinking.
the testing should be the same
not matter what the number says.  And assuming that . 0 release
is somehow different from any other is just superstition.
bill
Well, it depends on the routines and processes that the developers
of each application follows. And I have showed that for Rdb (it is
in the thread title) there are large differences on changes and
testing depending on the actual version change.

But since you probably have used Rdb for a longer time then I have,
I guess that I must simply be wrong. But, it actually sounds like
you doesn't know much of the technical details regarding Rdb.
Bill Gunshannon
2020-05-15 23:28:54 UTC
Permalink
Post by Jan-Erik Söderholm
But since you probably have used Rdb for a longer time then I have,
I guess that I must simply be wrong. But, it actually sounds like
you doesn't know much of the technical details regarding Rdb.
I have no experience with Rdb at all. But, I see it as just another
product. I have been doing this for over 40 years (over 50 if you
ignore the break in the mid-70's when I went back into communications
for a few years). There are no super companies. While there have
been some really bad ones the majority are who survive and stick
around are all pretty much the same. No software is bug free.
Trusting that you can do less testing because "it's a minor update"
as opposed to "it's a major update" is courting disaster.


bill
Dave Froble
2020-05-16 00:34:19 UTC
Permalink
Post by Bill Gunshannon
Sorry, but to my way of thinking the testing should be the same
noi matter what the number says. And assuming that . 0 release
is somehow different from any other is just superstition.
1973 was how long ago? My feeble minded math says something like 47
years in this business.

I have, through the years, heard stories about some mishaps with major
releases of software products. Won't say it happens all the time. But
since the true test of any software is production, sometimes things slip
through.

While such could happen in any release, the more changes, the more
chance for a bug.

Not total superstition. Just the odds.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2020-05-16 00:48:32 UTC
Permalink
Post by Bill Gunshannon
Sorry, but to my way of thinking the testing should be the same
noi matter what the number says.  And assuming that . 0 release
is somehow different from any other is just superstition.
1973 was how long ago?  My feeble minded math says something like 47
years in this business.
I beat you. I started in 1971. But didn't stay with it the whole time.
Wasn't so sure them computer things were gonna succeed. :-)
I have, through the years, heard stories about some mishaps with major
releases of software products.  Won't say it happens all the time.  But
since the true test of any software is production, sometimes things slip
through.
And I have seen major failures with minor releases. Seems to be
quite common with a certain company we are all familiar with from
out on the left coast.
While such could happen in any release, the more changes, the more
chance for a bug.
That's true, but one bug can bring you to a complete standstill. And it
could be in that one piece you decide not to test because "it's only a
minor update."
Not total superstition.  Just the odds.
Most superstitions can be traced back to something that actually went
wrong. But when it becomes stereotypical rather than based on proof
each time it becomes superstition.

bill
Stephen Hoffman
2020-05-19 16:22:37 UTC
Permalink
Post by Dave Froble
I have, through the years, heard stories about some mishaps with major
releases of software products. Won't say it happens all the time. But
since the true test of any software is production, sometimes things
slip through.
While such could happen in any release, the more changes, the more
chance for a bug.
Not total superstition. Just the odds.
Coincidentally, VSI has indicated they're adopting a
continuous-deployment model for their upcoming update-related for
OpenVMS work. Though they're not calling it that.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2020-05-19 16:48:30 UTC
Permalink
Post by Stephen Hoffman
Post by Dave Froble
I have, through the years, heard stories about some mishaps with major
releases of software products.  Won't say it happens all the time.
But since the true test of any software is production, sometimes
things slip through.
While such could happen in any release, the more changes, the more
chance for a bug.
Not total superstition.  Just the odds.
Coincidentally, VSI has indicated they're adopting a
continuous-deployment model for their upcoming update-related for
OpenVMS work. Though they're not calling it that.
It seems like VSI is going for many modern approaches.

One can wonder whether that is because:
A) they think these approaches are better than the old
B) they want to give an impression of being modern
C) they want to understand the mindset of their future new customers
D) all of the above

:-)

Arne
John Reagan
2020-05-15 13:44:48 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Am I the only one who sees this and laughs?  A number, in reality,
has absolutely nothing to do with how a program runs.  If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.
Has IT become as superstitious as religion and baseball?
bill
Usually a "dot-zero" release involves more and larger changes than
a minor release. So it is usual to take a little more care with them.
That has nothing to do with superstition. Of course, if you skip .0
and instead the .1 would be the first release, the same applies.
Maybe we should version like TeX which additional digits of Pi. Numerically larger and alphabetically larger than the prior release.
Jan-Erik Söderholm
2020-05-15 14:23:35 UTC
Permalink
Post by John Reagan
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Am I the only one who sees this and laughs?  A number, in reality,
has absolutely nothing to do with how a program runs.  If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.
Has IT become as superstitious as religion and baseball?
bill
Usually a "dot-zero" release involves more and larger changes than
a minor release. So it is usual to take a little more care with them.
That has nothing to do with superstition. Of course, if you skip .0
and instead the .1 would be the first release, the same applies.
Maybe we should version like TeX which additional digits of Pi. Numerically larger and alphabetically larger than the prior release.
There are also such things such as an Rdb database (the physical files)
are compatible within some version updates and not within others. So
the "rollback" from, say a 7.x database to a 6.x is harder and takes
more time than from a 7.y database to 7.x.

Again, it has nothing to do with the ".zero" as such or superstition.
Jan-Erik Söderholm
2020-05-15 14:31:07 UTC
Permalink
Post by Jan-Erik Söderholm
Post by John Reagan
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Am I the only one who sees this and laughs?  A number, in reality,
has absolutely nothing to do with how a program runs.  If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.
Has IT become as superstitious as religion and baseball?
bill
Usually a "dot-zero" release involves more and larger changes than
a minor release. So it is usual to take a little more care with them.
That has nothing to do with superstition. Of course, if you skip .0
and instead the .1 would be the first release, the same applies.
Maybe we should version like TeX which additional digits of Pi.
Numerically larger and alphabetically larger than the prior release.
There are also such things such as an Rdb database (the physical files)
are compatible within some version updates and not within others. So
the "rollback" from, say a 7.x database to a 6.x is harder and takes
more time than from a 7.y database to 7.x.
Again, it has nothing to do with the ".zero" as such or superstition.
Look at the "Compatibility Matrix" page:

https://www.oracle.com/database/technologies/related/rdb-pmatrix.html

The physical files are compatible with 7.1.x.x, 7.2.x.x and 7.3.x.x.

The "versioning" of the Rdb applications are also compatible with each
X.X release:

$ show log RDBVMS$VERSION
"RDBVMS$VERSION" = "7.3" (LNM$SYSTEM_TABLE)
$

You can have both 7.2.x.x and 7.3.x.x installed and used at the same
time, but not 7.3.2.x and 7.3.3.x.

So there is a lot of logic built-in in the version numbers and not
that much superstition.
Stephen Hoffman
2020-05-15 14:37:41 UTC
Permalink
Post by John Reagan
Maybe we should version like TeX which additional digits of Pi.
Numerically larger and alphabetically larger than the prior release.
Joke, I know, but the pain from these messes is a little too fresh, as
there are already enough bogus version numbers around OpenVMS-related
apps. Yes, it's getting better. Yes, OpenSSL isn't helping.
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2020-05-15 13:18:48 UTC
Permalink
Post by Jan-Erik Söderholm
Usually a "dot-zero" release involves more and larger changes than
a minor release. So it is usual to take a little more care with them.
Right.
Post by Jan-Erik Söderholm
That has nothing to do with superstition. Of course, if you skip .0
and instead the .1 would be the first release, the same applies.
Indeed. I think that some 7.x release was originally planned to be 8.0
then renamed.
Stephen Hoffman
2020-05-15 15:04:37 UTC
Permalink
I think that some 7.x release was originally planned to be 8.0 then renamed.
Oracle Rdb 8.0 was renamed to 7.1 right at its release.

There are still references to Rdb 8.0 scattered around. Here's one, and
the obvious web searches will find others. (Yes, web searching is
seemingly an anathema for some comp.os.vms posters, I know.)
https://download.oracle.com/otn_hosted_doc/rdb/pdf/stats_hdbk_v1.pdf

Here's a scrounged copy of the official announcement of the Oracle Rdb
re-versioning:
https://web.archive.org/web/20021017011829/http://www.oracle.com/rdb/product_info/html_documents/index.html?rdb_80_to_71_announcement.html


The official announcement referenced perceived adoption rates of .0
releases. The scuttlebutt differed, as scuttlebutt does.

As for core development and network services on OpenVMS, SQLite and
PostgreSQL are far more likely to be available for integration with
OpenVMS than would Rdb.

This given the relatively permissive software licenses on SQLite and
PostgreSQL, and also given longstanding Oracle business practices.

But who knows, HPE transferred products and folks to VSI. Maybe Oracle
does, too. But I wouldn't bet that way.

The questions there inevitably involve the skills and scope and focus
and funding of the organizations involved, and of which we likely won't
hear about.

And various databases including SQLite and PostgreSQL are well suited
to many of the tasks that OpenVMS app developers now have.

Better suited, in various cases. SQLite in particular is nowhere near
as heavyweight as Rdb, having used both.

There are cases where I'd absolutely pick Oracle Rdb, yes. But there
are just as many cases where I'd pick SQLite.

This whole database discussion skews differently for different folks,
particularly given that OpenVMS clustering (and Oracle Rdb) are priced
out of usefulness in many installations, and given that hardware
capabilities and scale and scope and reliability have also all changed
over the decades. The lack of entry-level options for OpenVMS and for
features including clustering being a long-standing refrain around
here, of course.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2020-05-15 15:29:12 UTC
Permalink
Post by Stephen Hoffman
As for core development and network services on OpenVMS, SQLite and
PostgreSQL are far more likely to be available for integration with
OpenVMS than would Rdb.
This given the relatively permissive software licenses on SQLite and
PostgreSQL, and also given longstanding Oracle business practices.
But who knows, HPE transferred products and folks to VSI. Maybe Oracle
does, too. But I wouldn't bet that way.
The questions there inevitably involve the skills and scope and focus
and funding of the organizations involved, and of which we likely won't
hear about.
And various databases including SQLite and PostgreSQL are well suited to
many of the tasks that OpenVMS app developers now have.
Better suited, in various cases.  SQLite in particular is nowhere near
as heavyweight as Rdb, having used both.
There are cases where I'd absolutely pick Oracle Rdb, yes. But there are
just as many cases where I'd pick SQLite.
I think it will be extremely rare that Rdb and SQLite are relevant
alternatives.

I see SQLite as an obvious alternative to RMS index-sequential files.

PostgreSQL could be an alternative to Rdb, but last I heard it
was not running on VMS yet.

Arne
Dave Froble
2020-05-16 00:49:35 UTC
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
As for core development and network services on OpenVMS, SQLite and
PostgreSQL are far more likely to be available for integration with
OpenVMS than would Rdb.
This given the relatively permissive software licenses on SQLite and
PostgreSQL, and also given longstanding Oracle business practices.
But who knows, HPE transferred products and folks to VSI. Maybe Oracle
does, too. But I wouldn't bet that way.
The questions there inevitably involve the skills and scope and focus
and funding of the organizations involved, and of which we likely
won't hear about.
And various databases including SQLite and PostgreSQL are well suited
to many of the tasks that OpenVMS app developers now have.
Better suited, in various cases. SQLite in particular is nowhere near
as heavyweight as Rdb, having used both.
There are cases where I'd absolutely pick Oracle Rdb, yes. But there
are just as many cases where I'd pick SQLite.
I think it will be extremely rare that Rdb and SQLite are relevant
alternatives.
I see SQLite as an obvious alternative to RMS index-sequential files.
PostgreSQL could be an alternative to Rdb, but last I heard it
was not running on VMS yet.
"Yet" is always subject to change.

Rdb is too expensive for many VMS users. At least that is my
perception. Too expensive means less usage. Not good for anybody.

It is my memory that Oracle paid rather little for Rdb. Not sure about
that. But if a really good database product is available for VMS, and
if it is rather compatible with Rdb, Oracle will be in a difficult
position. Sure, there will be those who will not consider changing.
The number of such will be important to Oracle.

Might be a bit like the possibility of VMS Cluster fate. Yes, it can be
disaster tolerant. But if the usage was to add compute nodes to a
system, today's chips with many cores might in some cases replace such
functionality. So VSI might have "worthless" software, if nobody will
pay the price. Ot very few. A real dilemma. Bundle it in with the OS,
or, make big bucks from a few customers. In time, maybe none.

The people making $20 CD and DVD drives are still around. Quantity has
a quality all it's own.

If the support revenue drops enough, Oracle might not want Rdb.
--
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-05-16 08:11:52 UTC
Permalink
Post by Dave Froble
Rdb is too expensive for many VMS users. At least that is my
perception. Too expensive means less usage. Not good for anybody.
Good for people who can sell it at a high price. But if the VMS pricing
structure changes with VSI, maybe the Rdb pricing structure will as
well, since everyone who runs Rdb runs VMS, and many large VMS customers
run Rdb, so the two are closely related. While Rdb is expensive, for a
shop paying high prices for hardware, software, licenses, maintenance,
support, etc., it was par for the course. The advantage is that it is
very VMS like and works well with VMS features like real clustes and so
on.
Post by Dave Froble
It is my memory that Oracle paid rather little for Rdb. Not sure about
that.
The story I remember is that Larry said that if he couldn't buy Rdb from
DEC at a good price, then he would stop supporting Oracle classic on VMS
(which still exists, but I think has always been a minority on VMS
compared to Rdb).
Post by Dave Froble
Might be a bit like the possibility of VMS Cluster fate. Yes, it can be
disaster tolerant. But if the usage was to add compute nodes to a
system, today's chips with many cores might in some cases replace such
functionality. So VSI might have "worthless" software, if nobody will
pay the price. Ot very few. A real dilemma. Bundle it in with the OS,
or, make big bucks from a few customers. In time, maybe none.
My guess is that adding nodes while the cluster is running, though nice,
is not the reason people run it, but rather in order to have several
nodes in different datacentres far apart.
Stephen Hoffman
2020-05-19 16:19:23 UTC
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
As for core development and network services on OpenVMS, SQLite and
PostgreSQL are far more likely to be available for integration with
OpenVMS than would Rdb.
This given the relatively permissive software licenses on SQLite and
PostgreSQL, and also given longstanding Oracle business practices.
But who knows, HPE transferred products and folks to VSI. Maybe Oracle
does, too. But I wouldn't bet that way.
The questions there inevitably involve the skills and scope and focus
and funding of the organizations involved, and of which we likely won't
hear about.
And various databases including SQLite and PostgreSQL are well suited
to many of the tasks that OpenVMS app developers now have.
Better suited, in various cases.  SQLite in particular is nowhere near
as heavyweight as Rdb, having used both.
There are cases where I'd absolutely pick Oracle Rdb, yes. But there
are just as many cases where I'd pick SQLite.
I think it will be extremely rare that Rdb and SQLite are relevant
alternatives.
The market for apps and databases isn't a fixed size. This isn't a
horse race. This is a market here for apps to update and upgrade and
adopt and enhance.

Rdb is heavyweight, expensive, quite capable, cluster-able,
non-portable, and far less than all OpenVMS sites have access to that
Oracle product. And no, I don't expect Oracle will ever offer Rdb at
prices competitive to SQLite and PostgreSQL.

When an app needs the features and scope and support of Rdb, go for it.
But I'd wager that sites with smaller and/or more numerous cases won't
purchase Rdb.

They'll slog through with RMS as that's what is available and
integrated, and emphasis on "slog".

There's a ginormous opportunity that exists between the
increasingly-limited RMS support, and Rdb.

Back to my core open source library comment that started this whole
side-thread, relational databases are now a common part of an operating
system. RMS started out being a common file access and database
mechanism and one that was unusual and useful in the last millennium.
In this more recent era, RMS is limited in comparison, and using RMS is
awkward in comparison to SQLite, PostgreSQL, and Rdb.

And as someone here will undoubtedly misinterpret this as a request to
replace RMS with a relational database, it is not. Again, this isn't a
fixed-size market, different apps have different needs, RMS solves some
problems quite well, and there are app developers with limited
requirements or limited expectations, too. And apps that use RMS can
and should and will continue to operate. And hopefully RMS will also
get extended, as the current record sizes and file sizes and storage
sizes are all, well, limited.

When some of the current RMS apps get reworked, or when new apps are
written, maybe a database is a better fit than an RMS file. Indexed
file definitions are a slog to create and access and update,
particularly in a clustered and mixed-version environment. These sorts
of database operations, updates, and enhancements are vastly easier
with SQLite or PostgreSQL or Rdb. App-defined fixed-sized record fields
are... far too reminiscent of punched cards. Yes, Oracle CDD can be a
help, but the whole approach is still a code-slog.

And yes, maybe some DTR-like app reappears as a front-end for an
integrated relational database, and maybe also language support for
accessing a relational database appears in Fortran, BASIC, and such.
Eventually.

But for now, simply having copies of SQLite or PostgreSQL integrated in
the distribution would be a workable option for many apps.
Post by Arne Vajhøj
I see SQLite as an obvious alternative to RMS index-sequential files.
If by "alternative" you mean "vastly more capable than", sure.
Post by Arne Vajhøj
PostgreSQL could be an alternative to Rdb, but last I heard it was not
running on VMS yet.
It's wedged behind the lack of SSIO within the C RTL.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2020-05-19 17:12:20 UTC
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
And various databases including SQLite and PostgreSQL are well suited
to many of the tasks that OpenVMS app developers now have.
Better suited, in various cases.  SQLite in particular is nowhere
near as heavyweight as Rdb, having used both.
There are cases where I'd absolutely pick Oracle Rdb, yes. But there
are just as many cases where I'd pick SQLite.
I think it will be extremely rare that Rdb and SQLite are relevant
alternatives.
The market for apps and databases isn't a fixed size. This isn't a horse
race. This is a market here for apps to update and upgrade and adopt and
enhance.
True.
Rdb is heavyweight, expensive, quite capable, cluster-able,
non-portable,
Rdb itself may be non-portable, but the application using Rdb could
be made reasonable portable (VMS COBOL and C embedded SQL, Java
and other JVM languages JDBC, C/C++ ODBC, C#/VB.NET ADO.NET over ODBC).
and far less than all OpenVMS sites have access to that
Oracle product. And no, I don't expect Oracle will ever offer Rdb at
prices competitive to SQLite and PostgreSQL.
Oracle does not have a reputation for being low cost.

:-)
There's a ginormous opportunity that exists between the
increasingly-limited RMS support, and Rdb.
I agree.
Back to my core open source library comment that started this whole
side-thread, relational databases are now a common part of an operating
system.
I don't see that.

I am not aware of a standard RDBMS for Linux or Windows or any Unix.

MySQL and PostgreSQL are usually both available.

And lots of applications comes bundled with an embedded RDBMS. SQLite
being by far the most widely used. In the Java world H2 is widely used.
And as someone here will undoubtedly misinterpret this as a request to
replace RMS with a relational database, it is not.  Again, this isn't a
fixed-size market, different apps have different needs, RMS solves some
problems quite well, and there are app developers with limited
requirements or limited expectations, too. And apps that use RMS can and
should and will continue to operate. And hopefully RMS will also get
extended, as the current record sizes and file sizes and storage sizes
are all, well, limited.
Amen.
When some of the current RMS apps get reworked, or when new apps are
written, maybe a database is a better fit than an RMS file. Indexed file
definitions are a slog to create and access and update, particularly in
a clustered and mixed-version environment. These sorts of database
operations, updates, and enhancements are vastly easier with SQLite or
PostgreSQL or Rdb. App-defined fixed-sized record fields are... far too
reminiscent of punched cards.
Yes. A RDBMS is simple easier to use and has better tooling. And while
the additional overhead may have been a problem 30 years ago, then
today it is insignificant.
And yes, maybe some DTR-like app reappears as a front-end for an
integrated relational database, and maybe also language support for
accessing a relational database appears in Fortran, BASIC, and such.
Eventually.
Question is: how many of the new application will be made in
those languages?

Fortran: probably very few.

Basic: if VSI does to VMS Basic what MS did for VB to VB.NET then
sure, but if not then it will fall in same category as Fortran.
Post by Arne Vajhøj
I see SQLite as an obvious alternative to RMS index-sequential files.
If by "alternative" you mean "vastly more capable than", sure.
By alternative I mean that it is two options that will be considered
by the developer.
Post by Arne Vajhøj
PostgreSQL could be an alternative to Rdb, but last I heard it was not
running on VMS yet.
It's wedged behind the lack of SSIO within the C RTL.
.

Arne
IanD
2020-05-20 21:38:47 UTC
Permalink
This post might be inappropriate. Click to display it.
Simon Clubley
2020-05-21 12:46:29 UTC
Permalink
Post by IanD
One might even contemplate the queue manager getting a spruce up and being replaced by sqlite under the hood? Who wouldn't like to see F$getqui meeting it's end ;-)
Let me know when SQLite is fully VMS-style cluster aware with integrated
cluster-wide DLM support and can carry on as normal without loss of data
when a node suddenly fails... :-)
Post by IanD
What about the accounting file, audit file and others embracing sqlite?
Probably the same limitation (at least for the audit file) although the
accounting file could benefit from being indexed.

The thing which could really benefit from a change is the recording of
OPCOM messages. That's the kind of thing which could really benefit from
messages being recorded in a structured format in a database which is both
indexed and searchable by various criteria.

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-05-21 15:38:27 UTC
Permalink
Post by Simon Clubley
Post by IanD
One might even contemplate the queue manager getting a spruce up and being replaced by sqlite under the hood? Who wouldn't like to see F$getqui meeting it's end ;-)
Let me know when SQLite is fully VMS-style cluster aware with integrated
cluster-wide DLM support and can carry on as normal without loss of data
when a node suddenly fails... :-)
I would expect SQLite to handle a system crash fine as it is my
understanding that it uses a transaction log.

Regarding clustering then I guess it depends on the VMS port.

SQLite does use locks.

Docs say:

<quote>
SQLite uses POSIX advisory locks to implement locking on Unix. On
Windows it uses the LockFile(), LockFileEx(), and UnlockFile() system
calls. SQLite assumes that these system calls all work as advertised.
</quote>

If the VMS port use VMS lock manager, then clustering should work.

I have no idea what it does.

Arne
Stephen Hoffman
2020-05-21 16:38:03 UTC
Permalink
Post by Simon Clubley
Post by IanD
One might even contemplate the queue manager getting a spruce up and
being replaced by sqlite under the hood? Who wouldn't like to see
F$getqui meeting it's end ;-)
Let me know when SQLite is fully VMS-style cluster aware with
integrated cluster-wide DLM support and can carry on as normal without
loss of data when a node suddenly fails... :-)
That'd be ~five years ago, then. os_vms.c has been around for quite a while.

That with DLM and $qio. As for contending with cluster failovers
(fallovers? 🤪), I'd suspect SQLite would do better there than apps
using RMS, absent RMS journaling. Haven't checked on a DECdtm
distributed transaction manager tie-in, but less than all apps on
OpenVMS were integrated with that, and parts of that were and likely
still are undocumented.

Other details to ponder: Clustering is a less-than-robustly-maintained
and arcane corner of OpenVMS, and a whole lot of folks using OpenVMS
don't use clustering.

Usage (or lack of) which has implications for both end-users, and for
VSI with discussions around revenues and features and app lock-in, and
documentation and user interface designs.

I'd like for that cluster usage to be different and far more common,
and clustering to be vastly easier to setup, and for more apps to be
integrated with clustering, but the OpenVMS doc and the OpenVMS user
interface here is most charitably referred to as scatter-shot, and the
cluster setup is a hilariously manual and fussy—yes, I've de-conflicted
UAF and RIGHTSLIST files and ACLs and users and other giblets—and an
error-prone process all around. Getting a ~couple dozen files all
properly shared. Getting UICs and usernames de-conflicted.

Or maybe this whole morass eventually migrates to LDAP and maybe
SQLite, who knows?

And I know how to configure a cluster. And I still mess up a protection
once in a while.

And as for customers and for VSI, clustering costs a whole lot, such
that many folks simply fail over production to a backup server.

Which in aggregate also means a whole lot of OpenVMS apps don't become
dependent on distributed-shared-write clustering, and which is still a
decent lock-in for the vendor.

But I digress.

A whole lot of OpenVMS installations don't use clustering.

And RMS journaling lacks a commonly-used abbreviation akin to HBVS for
Host-based Volume Shadowing—that's OpenVMS jargon for software
RAID-1—so I have to wonder 🤔 how often and how widely "RJ" is used,
among those folks that even know that product exists. Lots of parts of
OpenVMS exist, but are either little known, or difficult to integrate
and use.

But I digress again.
Post by Simon Clubley
Post by IanD
What about the accounting file, audit file and others embracing sqlite?
Probably the same limitation (at least for the audit file) although the
accounting file could benefit from being indexed.
The thing which could really benefit from a change is the recording of
OPCOM messages. That's the kind of thing which could really benefit
from messages being recorded in a structured format in a database which
is both indexed and searchable by various criteria.
CMS, PCSI, and a pile of other apps all have their own home-grown
non-transactional databases. Once you realize how many of these apps
are around both third-party apps and OpenVMS components, and realize
that multi-part updates and a lack of rollbacks and of complex
multi-file configurations causes issues around corruptions and around
upgrades... You start seeing stability and functional enhancements all
over the place. And for RMS-using apps and in the absence of RJ 😉,
better robustness.
--
Pure Personal Opinion | HoffmanLabs LLC
Richard Maher
2020-05-22 02:36:43 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
Post by IanD
One might even contemplate the queue manager getting a spruce up
and being replaced by sqlite under the hood? Who wouldn't like to
see F$getqui meeting it's end ;-)
Let me know when SQLite is fully VMS-style cluster aware with
integrated cluster-wide DLM support and can carry on as normal
without loss of data when a node suddenly fails... :-)
That'd be ~five years ago, then. os_vms.c has been around for quite a while.
That with DLM and $qio. As for contending with cluster failovers
(fallovers? 🤪), I'd suspect SQLite would do better there than apps
using RMS, absent RMS journaling. Haven't checked on a DECdtm
distributed transaction manager tie-in, but less than all apps on
OpenVMS were integrated with that, and parts of that were and likely
still are undocumented.
Fully documented just that the document was never released :-) Someone
could the file up on the Web. Used an old paper copy to implement the
Transaction Internet Protocol back in the day.
Simon Clubley
2020-05-22 13:04:14 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
Post by IanD
One might even contemplate the queue manager getting a spruce up and
being replaced by sqlite under the hood? Who wouldn't like to see
F$getqui meeting it's end ;-)
Let me know when SQLite is fully VMS-style cluster aware with
integrated cluster-wide DLM support and can carry on as normal without
loss of data when a node suddenly fails... :-)
That'd be ~five years ago, then. os_vms.c has been around for quite a while.
Thanks, I didn't know that. I still don't think that using it for
the queue manager database would be that good of an idea however. :-)
Post by Stephen Hoffman
Other details to ponder: Clustering is a less-than-robustly-maintained
and arcane corner of OpenVMS, and a whole lot of folks using OpenVMS
don't use clustering.
OTOH, VMS clustering was such an advanced implementation when it was
introduced that even today, it's still comparable with what else is
available for true multi-site disaster tolerant clustering and it
was used as the source of ideas for how other people went about
implementing proper clustering.

If the disaster-tolerant video was created today, I wonder how VMS
would compare to the solutions available in 2020 ?
Post by Stephen Hoffman
Usage (or lack of) which has implications for both end-users, and for
VSI with discussions around revenues and features and app lock-in, and
documentation and user interface designs.
It would probably be used more if it wasn't priced in a way that might
make even an IBM mainframe site manager think twice... :-)
Post by Stephen Hoffman
I'd like for that cluster usage to be different and far more common,
and clustering to be vastly easier to setup, and for more apps to be
integrated with clustering, but the OpenVMS doc and the OpenVMS user
interface here is most charitably referred to as scatter-shot, and the
cluster setup is a hilariously manual and fussy?yes, I've de-conflicted
UAF and RIGHTSLIST files and ACLs and users and other giblets?and an
error-prone process all around. Getting a ~couple dozen files all
properly shared. Getting UICs and usernames de-conflicted.
I get the feeling that if true VMS-style clustering was implemented
from the ground up today it would still have all the capabilities of
the existing VMS clusters but would be a lot cleaner to use and manage.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2020-05-22 17:37:24 UTC
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
Post by Simon Clubley
Post by IanD
One might even contemplate the queue manager getting a spruce up and
being replaced by sqlite under the hood? Who wouldn't like to see
F$getqui meeting it's end ;-)
Let me know when SQLite is fully VMS-style cluster aware with
integrated cluster-wide DLM support and can carry on as normal without
loss of data when a node suddenly fails... :-)
That'd be ~five years ago, then. os_vms.c has been around for quite a while.
Thanks, I didn't know that. I still don't think that using it for
the queue manager database would be that good of an idea however. :-)
Post by Stephen Hoffman
Other details to ponder: Clustering is a less-than-robustly-maintained
and arcane corner of OpenVMS, and a whole lot of folks using OpenVMS
don't use clustering.
OTOH, VMS clustering was such an advanced implementation when it was
introduced that even today, it's still comparable with what else is
available for true multi-site disaster tolerant clustering and it
was used as the source of ideas for how other people went about
implementing proper clustering.
If the disaster-tolerant video was created today, I wonder how VMS
would compare to the solutions available in 2020 ?
Post by Stephen Hoffman
Usage (or lack of) which has implications for both end-users, and for
VSI with discussions around revenues and features and app lock-in, and
documentation and user interface designs.
It would probably be used more if it wasn't priced in a way that might
make even an IBM mainframe site manager think twice... :-)
Post by Stephen Hoffman
I'd like for that cluster usage to be different and far more common,
and clustering to be vastly easier to setup, and for more apps to be
integrated with clustering, but the OpenVMS doc and the OpenVMS user
interface here is most charitably referred to as scatter-shot, and the
cluster setup is a hilariously manual and fussy?yes, I've de-conflicted
UAF and RIGHTSLIST files and ACLs and users and other giblets?and an
error-prone process all around. Getting a ~couple dozen files all
properly shared. Getting UICs and usernames de-conflicted.
I get the feeling that if true VMS-style clustering was implemented
from the ground up today it would still have all the capabilities of
the existing VMS clusters but would be a lot cleaner to use and manage.
Simon.
Anything that grows over time is most likely to be a bit more messy than
any clean implementation. Going back and cleaning up things has some
issues, even though it really should be done.
--
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-05-22 18:40:59 UTC
Permalink
Post by Simon Clubley
OTOH, VMS clustering was such an advanced implementation when it was
introduced that even today, it's still comparable with what else is
available for true multi-site disaster tolerant clustering and it
was used as the source of ideas for how other people went about
implementing proper clustering.
Indeed. Like file versions, it's there at the bottom and things are
built on top of it, as opposed to other "cluster" and "file-version
systems" which are pulled over from the top.
Phillip Helbig (undress to reply)
2020-05-21 12:57:47 UTC
Permalink
Post by IanD
Post by IanD
One might even contemplate the queue manager getting a spruce up and
being replaced by sqlite under the hood? Who wouldn't like to see
F$getqui meeting it's end ;-)
Let me know when SQLite is fully VMS-style cluster aware with integrated
cluster-wide DLM support and can carry on as normal without loss of data
when a node suddenly fails... :-)
Indeed. Note the "Lite". Nomen est omen.
Arne Vajhøj
2020-05-21 15:45:22 UTC
Permalink
Post by IanD
Sqlite as a minimum would certainly be a nice inclusion on VMS and I
suspect some VMS folks may start using it instead of going to RMS to
process data. Firefox I believe uses sqlite under the hood doesn't
it?
FireFox and ThunderBord use SQLite.

Android and iOS use SQLite.

Skype use SQLite.

Some Adobe products use SQLite.

There are probably a 2 digit number of billions SQLite databases
in existance.

Arne
Dave Froble
2020-05-21 19:19:03 UTC
Permalink
Post by Arne Vajhøj
Post by IanD
Sqlite as a minimum would certainly be a nice inclusion on VMS and I
suspect some VMS folks may start using it instead of going to RMS to
process data. Firefox I believe uses sqlite under the hood doesn't
it?
FireFox and ThunderBord use SQLite.
Android and iOS use SQLite.
Skype use SQLite.
Some Adobe products use SQLite.
There are probably a 2 digit number of billions SQLite databases
in existance.
Guess it's not worth the bandwidth to ask for SQLite on VAX?

Is it available for Alpha?

Where can I get it? Too lazy to look.

Where can I get documentation and examples to learn the product?
--
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-05-21 19:34:19 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by IanD
Sqlite as a minimum would certainly be a nice inclusion on VMS and I
suspect some VMS folks may start using it instead of going to RMS to
process data. Firefox I believe uses sqlite under the hood doesn't
it?
FireFox and ThunderBord use SQLite.
Android and iOS use SQLite.
Skype use SQLite.
Some Adobe products use SQLite.
There are probably a 2 digit number of billions SQLite databases
in existance.
Guess it's not worth the bandwidth to ask for SQLite on VAX?
Is it available for Alpha?
I believe so.
Post by Dave Froble
Where can I get it?  Too lazy to look.
https://sourceforge.net/projects/vms-ports/files/SQLITE3/
Post by Dave Froble
Where can I get documentation and examples to learn the product?
https://www.sqlite.org/index.html

http://neilrieck.net/docs/openvms_notes_sqlite.html

Arne
o***@gmail.com
2020-05-22 02:39:22 UTC
Permalink
Post by Dave Froble
Guess it's not worth the bandwidth to ask for SQLite on VAX?
Internally it uses 64-bit integers for things like row-ids, so that would hobble
a VAX executable right away. The bigger issue is that the file format assumes the FLOAT data type is IEEE 64-bit floating point.
Bill Gunshannon
2020-05-22 12:17:15 UTC
Permalink
Post by o***@gmail.com
Post by Dave Froble
Guess it's not worth the bandwidth to ask for SQLite on VAX?
Internally it uses 64-bit integers for things like row-ids, so that would hobble
a VAX executable right away. The bigger issue is that the file format assumes the FLOAT data type is IEEE 64-bit floating point.
HPE seems to have gotten around that one as they recently announced
JAVA on the VAX. :-)

bill
Stephen Hoffman
2020-05-21 17:13:36 UTC
Permalink
Post by IanD
Firefox I believe uses sqlite under the hood doesn't it?
iPhone iOS, iPad iPadOS, and Mac running macOS all have integrated
SQLite underneath Core Data, among other uses.

SQLite is... quite commonly used.

https://sqlite.org/famous.html
--
Pure Personal Opinion | HoffmanLabs LLC
o***@gmail.com
2020-05-21 22:36:09 UTC
Permalink
Post by IanD
Sqlite is great for quickly loading up of data and performing relational queries
on and it scales better than Excel (Excel used to have a 1 million row limit, not
sure if this still applies)
...
One might even contemplate the queue manager getting a spruce up and being replaced by sqlite under the hood? Who wouldn't like to see F$getqui meeting it's end ;-)
What about the accounting file, audit file and others embracing sqlite?
Replacing the queue database with SQLite would be a bad idea. SQLite is
optimized for being an application's private data store. There is essentially
one lock on the entire file (i.e. no row locks), so multiple concurrent writers
see a lot of contention and a lot of I/O to make sure the next guy getting the
lock sees a consistent database. (I think they added the WAL-mode locking option
help performance where the issue is critical.)

Otherwise, it's fun to play with. The command line program lets you rummage
through the data so your application doesn't have to include as many tools for
maintaining the data file. On my home cluster, I drive my disk mounts from an
SQLite database (physical disks, shadow sets, NFS mounts).
e***@gmail.com
2020-05-22 08:18:55 UTC
Permalink
Post by o***@gmail.com
Replacing the queue database with SQLite would be a bad idea. SQLite is
optimized for being an application's private data store. There is essentially
one lock on the entire file (i.e. no row locks), so multiple concurrent writers
see a lot of contention and a lot of I/O to make sure the next guy getting the
lock sees a consistent database. (I think they added the WAL-mode locking option
help performance where the issue is critical.)
I would have thought that having multiple queue managers would be the exception rather than the rule, and otherwise it's all IPC, isn't it. It's not like pre 5.x when there was a queue manager on each node and queue database corruption was just Monday.
Phillip Helbig (undress to reply)
2020-05-15 13:17:40 UTC
Permalink
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
8.0 was the Rdb/NT version. That was never released due to lack of
support for the BLISS compiler on NT (as it was told)
But I think that there were plans to release an 8.0 for other systems
but it was renamed so that people wouldn't be afraid of installing a .0
release.
Am I the only one who sees this and laughs? A number, in reality,
has absolutely nothing to do with how a program runs. If you call
it if it follows 7.3 and you call it 8.1, wouldn't it still be 8.0?
It's like skipping the number 13 in an elevator, there is still a
thirteenth floor even if the number isn't there.
Has IT become as superstitious as religion and baseball?
I think it was more to do with conforming to the letter of the agreement
between HP and Oracle and at the same time being able to upgrade, fix
bugs, etc.

Since x86 is a new architecture for VMS and no longer owned by HP,
hopefully things will improve in the future.
Phillip Helbig (undress to reply)
2020-05-14 06:25:59 UTC
Permalink
Post by Richard Maher
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
At the Oracle/HPE/Itanium debacle some years ago, Rdb was "frozen"
at version 7.3 and the thought was that it was the final version.
But now it sounds like a version 7.4 will be shipped.
Not really. Basically, instead of 7.4, 7.5, etc. there was 7.3.x,
7.3.y, 7.3.z etc. This had a precedent; 7.3 was supposed to be 8.0,
and I think that 8.0 was actually mentioned in a book and/or some
documentation, but it was changed to 7.3 to calm people who didn't
want to install a .0 release. :-)
I wondered what the real reason was. I suspected Larry said there'd
never be a version 8?
Right; that refers to the second reason.
Post by Richard Maher
I had the original release notes watermarked Rdb8 many moons ago
That refers to the first reason.
Phillip Helbig (undress to reply)
2020-05-12 14:27:21 UTC
Permalink
Post by Arne Vajhøj
Bob Palmer sold RDB to Oracle in 1994 - and DEC RDB became Oracle RDB.
And they use the name "Oracle RDB".
https://www.oracle.com/database/technologies/related/rdb.html
The "Oracle" in "Oracle Rdb" is pronounced the same as the "Open" in
"OpenVMS". :-)
Arne Vajhøj
2020-05-12 12:18:44 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
RDB is a pretty good database. Reliable, performant,
good support for the available programming languages.
There are a few "modern" features missing, but my guess
would be that cost is the main reason for not using RDB.
And if someone are curious about the "modern" features,
then we went through them a year ago: newer SQL syntax like
CTE, full text search capability, builtin XML and JSON
support.
I suspect that 95% of people writing code accessing
a database have never used any of those.
Right; they are probably using COBOL or Fortran. Having done both old
and new stuff here, I prefer the old. :-)
None of these things depend on the programming language used.

Even people using a newer language often stick to a subset
of SQL-92 when accessing a database.

Arne
Loading...