[Info-vax] OpenVMS STARTUP Whitepaper
Jan-Erik Söderholm
jan-erik.soderholm at telia.com
Fri Dec 11 19:42:00 EST 2020
Den 2020-12-12 kl. 01:03, skrev Craig A. Berry:
>
> On 12/11/20 12:35 PM, Arne Vajhøj wrote:
>> On 12/11/2020 11:12 AM, Jan-Erik Söderholm wrote:
>>> Den 2020-12-11 kl. 15:51, skrev Arne Vajhøj:
>
>>>> But will Rdb work properly without the RDMS_MONITOR and RMU processes
>>>> running?
>>>
>>> No, your application will not do anything with the data without having
>>> an "OK" from the monitor. You send an "attach request" (well, the code
>>> in the sharable images does) to the monitor and the monitor says "OK".
>>
>>>> Will it work properly without the Rdb logicals being defined?
>>>
>>> No, you need at least some of the logicals setup by the startup file.
>>
>> That is what I thought.
>>
>> Rdb is not really like SQLite.
>
> Well in general, obviously. But in the specific matter of not running
> as a service, I stand corrected in that it does not run as a service but
> requires a monitor service to be running, which is an odd design, but
> there it is.
It is a highly efficient design. Each user process has direct contact
with the files where the data is stored. No nead to send either the
SQL statements over some process-2-process or network link. And in
the same way, no need to send the resulting data back over the same
P2P or network link. It's all in the hands of your own process.
If the user process is doing some "offline" batch updates, it can start
an "exclusive" transaction and have the tables involved for its own
use with most of the usual locking activity closed down.
And you can configure such a process with very differnt buffers and
such parameters then the default for the actual database. For a design
(the most common one) with a central "DB server" process doing all the
"work", buffers, caches and such are shared in the common process.
All database processing code is run within the user process space.
Well, apart from special cases like a recovery process started when
a user process crashes.
> So it has prerequisites for start-up, which possibly could
> have been overcome in the DEC days when things were more integrated.
It's not really clear what you are calling "start-up" here. There is
no start-up (as when you start up the DB-server processes for an Oracle
"classic" DB). Just start the "monitor" and define some logical names.
The monitor know nothing about any "databases" and at that time, the
files where the database is stored hasn't been touched yet.
The actual "database" (as defined by the files where the data is stored)
does not come into play until some user process opens them and starts
processing the data.
More information about the Info-vax
mailing list