[Info-vax] Oracle Database vs Oracle/Rdb

[Jan-Erik Söderholm]

Den 2019-06-24 kl. 13:39, skrev Neil Rieck:
> On Saturday, June 22, 2019 at 6:29:48 PM UTC-4, Jan-Erik Söderholm
> wrote:
>> Den 2019-06-22 kl. 18:52, skrev Neil Rieck:
>>> On Wednesday, June 19, 2019 at 1:18:05 AM UTC-4, DTL wrote:
>>>> from application/VMS--(local)--RDB/VMS to 
>>>> application/VMS--(local)--OraDB/VMS.
>>>> 
>>>> The Customer wants (why? dunno yet) to "move from Rdb to Oracle"
>>>> (sic) in the same environment, with no modifications whatsoever.
>>> 
>>> That may not be possible depending upon how the customer is using 
>>> Oracle-RDB. Recall that RDB was developed by DEC as a successor to
>>> RMS. Certain DEC languages, like COBOL and BASIC, have builtin
>>> support for RMS while other DEC languages provide indirect RMS
>>> support via the linker.
>>> 
>>> To the best of my knowledge, no so-called DEC languages provide
>>> builtin support of RDB...
>> 
>> Not for Oracle either.
>> 
>>> ...but some very cool developer tools exist which will allow you to 
>>> compile-in RDB support.
>> 
>> It is the standard Embedded SQL compiler (similar to what Oracle has)
>> for the usual languages and the SQL Modular Language compiler (I do
>> not think there is something similar for Oracle) that compiles pure
>> SQL files into standard VMS object (OBJ) files.
>> 
>> Now, the main difference between Rdb and Oracle is the architecture.
>> 
>> Oracle has one (or multiple) central "database engine(s)" that does
>> all the physical database file accesses, all the "DB-work". User
>> processes sends their SQLs over to this central process to have it
>> executed.
>> 
>> Rdb links the database handling code into each application and thus
>> is running in the user process space. So after the locks has been got,
>> all processing can be done in parallel from each process. And if that
>> is against different storage areas (DB files), there is close to no
>> resources shared between the different processes. One process can have
>> fewer local buffers to cope with normal work and some other can have
>> more buffers to cope with a larger batch run. All that (buffer and
>> other configurations) is central in the DB engines in Oracle.
>> 
>> There is a central "Rdb Monitor" process, but that doesn't do any
>> work, it just monitors Rdb and starts rollback processes if a user
>> process dies, and similar servicing tasks.
>> 
>>> If your customer is not doing this then RDB is no different than 
>>> Oracle-db or any other SQL product which means you will access the 
>>> engine with a connector.
>>> 
>> 
>> It would be highly surpricing if a long time Rdb user does not use
>> either embedded SQL or the SQL Modular Language compiler. You can
>> write calls using the SQL/Services (similar to SQL*Net in Oracle), but
>> there is no reason as long as you stay within the local system.
>> 
>> 
>>> Neil Rieck Waterloo, Ontario, Canada 
>>> http://neilrieck.net/docs/openvms_notes_rms_rdb.html#rdb
>>> 
> 
> It's been more than a decade since I played with Oracle-Rdb but I seem
> to remember inserting all the requisite RDB statements into the
> VMS-BASIC source then running a pre-compiler.

Now, SQLPRE pre-compiler HELP says: "The host language qualifier
values are ADA, CC, CC=VAXC, CC=DECC, COBOL, FORTRAN, PASCAL, and PLI."


> IIRC, that step created one, or more, object files which contained all
> the glue necessary to link VMS-BASIC (or any language) to RDB.

 From the HELP:

SQLPRE

  The SQL precompiler provides special keywords and syntax that
  allow you to include (embed) simple and compound statements
  directly into host language programs. Then you can use the SQL
  precompiler to process the combined embedded statements and
  host language code to produce an object file for linking and
  execution.

We use embedded SQL in Cobol .SCO source files and they (or the OBJ
files produced) are then called from our main .COB applications.

Note that SQLPRE doesn't have support for BASIC, I'm surpriced
but I have never used BASIC (on VMS)...

There is also an older tool RDBPRE to include RDO commands supporting:

BASIC, input=.RBA, output=.BAS
COBOL, input=.RCO, output=.COB
FORTRAN, input=.RFO, output=.FOR

Maybe that was what you used for our BASIC programs? The available
manual is still at the V4.x level...

You could also have used Modular Language and sepratately compiled
your SQL's and then linked that to your BASIC applciations...


> 
> On a related note, I cam currently moving a huge amount of data from RMS
> to MariaDB. Since we have at least 100 VMS-BASIC programs are not able
> to be renovated at this time, I wrote my own API in "C" which I call
> from VMS-BASIC.
> 
> Has anyone here played with Python on any OS?

We use Python on VMS (Alpha) in production use since some years back.
Also available for Itanium.

> Python has builtin support to easily connect to MySQL or MariaDB...

And in the case of the VMS port, an easy to use Rdb interface.

> One of my colleagues rewrote one
> of our server programs (written in VMS-BASIC then saving data data to
> RMS) to Python. Surprisingly, the Python program is smaller while yet
> faster.

Probably only verifying that the BASIC program wasn't particulary
clever written... :-) I expect no Python program to be faster then
any similar program witten in a 3G compiled langauge. But it has
other benefits, of course. Like the huge amount of built-in tools.


> 
> http://neilrieck.net/demo_vms_html/openvms_demo_index.html#hybrid_basic_c_mariadb
>
>  This shows the hoops anyone will need to go through if something like
> an RDB pre-compiler is not available.
> 

Many tools today (in particulary scripting tools like Python, PHP and
so on) has a form of embedded SQL that is not pre-compiled. The raw
SQL is simply sent to the DB enginge for compilation and execution.

In the Rdb case, the pre-compiler does all the SQL compilation and calls
to the relevant Rdb runtime routines are instered into the source code
and a lot of glue-code is alrady (pre-) compiled into object/machine code.




> Neil Rieck Waterloo, Ontario, Canada. http://neilrieck.net
>