Scott Dorsey <kludge@panix.com> wrote:
> Edgar Ulloa <ulloa.edgar@gmail.com> wrote:
>>
>> But in our days, you consider that there will be new jobs
>> will it be just keeping the current one until it is migrated
>> to another operating system? What do you think?
>
> When I was in college, every class pretty much used a different computing
> environment, so I got basic experience in a whole lot of different operating
> systems and programming languages in the process just as a free bonus.

Yeah, but in the 1980s Digital had the smart idea (and too bad
Digital had some not-so-smart ideas later) of giving hefty discounts
to educational institutions, with the idea that students primarily
learning on their hardware and OS would advocate adopting it when
they moved on to the business world. I'd hazard a guess that many
of the diehard-to-this-day VMS advocates were beneficiaries
(or victims) of that strategy.

> So I don't particularly feel bad about moving to one more operating
> system after having spent much of my life moving from one to another.

Ditto. At least, when I was a full-time employee, and potential
employers looked at my overall background, checked my references,
and figured it was well worth their while to bring me up-to-speed
on whatever environment (language, os, dbms) they worked with.
But now, as a consultant (contract programmer) working through
my own one-man S-corp, I can pretty much only get hourly contracts
where I'm productive on day 1. Even fixed-price contracts are hard
to come by if your resume doesn't demonstrate pre-existing expertise
on the client's environment.

> But, that said, I miss commercial grade operating systems that are
> database-centric with the filesystem and database being integrated. I
> think that is a good approach for commercial applications, what we once
> called "ADP." Perhaps the future isn't VMS but I would like to see some
> of the concepts within VMS integrated into future commercial systems.
>
> As software becomes more and more expensive, I think the need to have an
> efficient operating system that provides database features in the kernel
> becomes more important.
> --scott

I gotta disagree there. Decomposing the environment lets you migrate
applications more easily if that becomes necessary or desirable.
Like if mysql or msql provides all necessary dbms functionality,
they're typically pretty easy to install just about anywhere.
Even more generally, I usually try to abstract the dbms needs
of an application by writing a little library of glue functions,
whereby the application never directly makes any dbms calls at all,
just issues calls to the glue functions, which isolate the dbms and
can then be written/rewritten to work with whatever dbms is convenient.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On 11/10/2022 10:47 PM, John Forkosh wrote:
> Scott Dorsey <kludge@panix.com> wrote:
>> But, that said, I miss commercial grade operating systems that are
>> database-centric with the filesystem and database being integrated. I
>> think that is a good approach for commercial applications, what we once
>> called "ADP." Perhaps the future isn't VMS but I would like to see some
>> of the concepts within VMS integrated into future commercial systems.
>>
>> As software becomes more and more expensive, I think the need to have an
>> efficient operating system that provides database features in the kernel
>> becomes more important.
>
> I gotta disagree there. Decomposing the environment lets you migrate
> applications more easily if that becomes necessary or desirable.
> Like if mysql or msql provides all necessary dbms functionality,
> they're typically pretty easy to install just about anywhere.
> Even more generally, I usually try to abstract the dbms needs
> of an application by writing a little library of glue functions,
> whereby the application never directly makes any dbms calls at all,
> just issues calls to the glue functions, which isolate the dbms and
> can then be written/rewritten to work with whatever dbms is convenient.

Most probably pick an existing glue layer instead of writing one.

C: ODBC, C++: ODBC or ADO, Java: JDBC, C#/VB.NET: ADO.NET (IDb*),
PHP: PDO, Python: DB API 2.0 etc..

Arne

On 11/10/2022 7:19 PM, Phillip Helbig (undress to reply) wrote:
> In article <tkk3rr$em$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
> <arne@vajhoej.dk> writes:
>>> Consider the fact that the user submitting the file might not have write
>>> permission to the current directory or to the directory where the
>>> procedure is located, but very probably does to SYS$LOGIN.
>>
>> Not having write access to the dir must be a special case.
>
> I don't know. Certainly there are environments where there is some
> official software or whatever where normal users are not allowed to
> write. Think SYS$SYSTEM. Should every user have access there? Think
> of a company's software package in some directory. Same thing.

I am not saying that such cases does not exist - I am just saying that
they must be rare.

I don't expect many users to SUBMIT COM files residing in SYS$SYSTEM.

And the two most common cases for software packages must be
system wide install with any batch job started by SYSTEM and
user installs in the users dir tree started by that user.

Leaving only the more unusual cases.

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>On 11/10/2022 9:51 AM, Scott Dorsey wrote:
>> But, that said, I miss commercial grade operating systems that are
>> database-centric with the filesystem and database being integrated. I
>> think that is a good approach for commercial applications, what we once
>> called "ADP." Perhaps the future isn't VMS but I would like to see some
>> of the concepts within VMS integrated into future commercial systems.
>
>How would "database-centric with the filesystem and database being
>integrated" look in real life?
>
>Like VMS index-sequential files (and its equivalence in the mainframe
>world)?
>
>Putting a file system on top of a RDBMS? (like Oracle and MS
>experimented with 20 years ago)

I was thinking the former, like VMS or MPE (although hopefully better designed
than MPE). But now that you bring it up, the latter is a hell of an
interesting idea for a commercial data processing machine.

>> As software becomes more and more expensive, I think the need to have an
>> efficient operating system that provides database features in the kernel
>> becomes more important.
>
>Database in the actual OS kernel or just database shipping with the
>OS distribution?
>
>It is not uncommon to put application functionality in the
>kernel today, but I am not keen on the idea.

I think in the kernel. Maybe not in the top ring, but in a ring below it.
I want fast database access, I want rapid transaction turnover, I don't care
necessarily about realtime operation or any direct UI other than for
administration, or ever specifically making deadline. I'm thinking of a
specialized database engine.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 11/11/2022 7:40 PM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>> On 11/10/2022 9:51 AM, Scott Dorsey wrote:
>>> As software becomes more and more expensive, I think the need to have an
>>> efficient operating system that provides database features in the kernel
>>> becomes more important.
>>
>> Database in the actual OS kernel or just database shipping with the
>> OS distribution?
>>
>> It is not uncommon to put application functionality in the
>> kernel today, but I am not keen on the idea.
>
> I think in the kernel. Maybe not in the top ring, but in a ring below it.
> I want fast database access, I want rapid transaction turnover, I don't care
> necessarily about realtime operation or any direct UI other than for
> administration, or ever specifically making deadline. I'm thinking of a
> specialized database engine.

I don't think I have ever heard about that for database.

But for web server then Tux for Linux and HTTP.sys for
Windows exist.

Arne

On 2022-11-12 00:37:23 +0000, Arne Vajhj said:

> On 11/10/2022 7:19 PM, Phillip Helbig (undress to reply) wrote:
>> In article <tkk3rr$em$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
>> <arne@vajhoej.dk> writes:
>>>> Consider the fact that the user submitting the file might not have
>>>> write permission to the current directory or to the directory where the
>>>> procedure is located, but very probably does to SYS$LOGIN.
>>>
>>> Not having write access to the dir must be a special case.
>>
>> I don't know. Certainly there are environments where there is some
>> official software or whatever where normal users are not allowed to
>> write. Think SYS$SYSTEM. Should every user have access there? Think
>> of a company's software package in some directory. Same thing.
>
> I am not saying that such cases does not exist - I am just saying that
> they must be rare.

Causing logs to be directed into a non-writable directory, or parking a
;32767 version in an otherwise-writable directory, was and remains a
fairly common hack to shut off certain stupid defaults.

DECnet netserver log files were routinely set to ;32767 in some
environments, for instance.

--
Pure Personal Opinion | HoffmanLabs LLC

On 11/11/22 6:37 PM, Arne Vajhøj wrote:
> On 11/10/2022 7:19 PM, Phillip Helbig (undress to reply) wrote:
>> In article <tkk3rr$em$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
>> <arne@vajhoej.dk> writes:
>>>> Consider the fact that the user submitting the file might not have
>>>> write
>>>> permission to the current directory or to the directory where the
>>>> procedure is located, but very probably does to SYS$LOGIN.
>>>
>>> Not having write access to the dir must be a special case.
>>
>> I don't know.  Certainly there are environments where there is some
>> official software or whatever where normal users are not allowed to
>> write.  Think SYS$SYSTEM.  Should every user have access there?  Think
>> of a company's software package in some directory.  Same thing.
>
> I am not saying that such cases does not exist - I am just saying that
> they must be rare.

Not at all. It's actually the most common use case in my experience.

> I don't expect many users to SUBMIT COM files residing in
> SYS$SYSTEM.

More likely SYS$MANAGER or a site-specific common directory, but rarely
a directory to which all users have write access.

> And the two most common cases for software packages must be
> system wide install with any batch job started by SYSTEM and
> user installs in the users dir tree started by that user.
> Leaving only the more unusual cases.

What you consider unusual is actually all I've ever seen in a production
environment. And I've seen lots of non-system users submitting batch
jobs from system or site directories to which they do not have write access.

On Sunday, November 6, 2022 at 3:42:16 PM UTC-8, Craig A. Berry wrote:
> On 11/6/22 12:58 PM, Arne Vajhøj wrote:
> > On 11/6/2022 8:55 AM, Scott Dorsey wrote:
> >> First thing: VMS has heavyweight processes. There's a lot of stuff in
> >> the
> >> process, so spawning off new processes takes a good while, and you
> >> don't do
> >> it very often. Conceptually different than Unix and Unixalikes where the
> >> processes are lightweight and the overhead of a fork is minimal so you
> >> fork
> >> off a new process for nearly everything.
> >
> > That was the gospel for many years.
> >
> > But the overhead of creating a process much be a lot less
> > significant on an Itanium or x86-64 today than it was on
> > a VAX 35 years ago.
> >
> > And I believe that for true high performance then even
> > *nix are switching from traditional forking to threads.
> And not everyone thinks fork() is such a great idea anymore even aside
> from performance considerations, e.g.:
>
> https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
>
> This could be good news for VMS if major applications start using
> posix_spawn() instead of fork(); it would map much better to the VMS way
> of doing things, and it might even be reasonable to provide a
> posix_spawn() API on VMS.

I was going to share that paper if someone else hadn't. fork() on UNIX is much slower than people think. I'm testing performance of several shells as part of a hobby project that grew out of hand porting GNU bash from K&R-style C to C++, and if you download "shellbench" from GitHub and run the subshell test, you'd be surprised how few subshells/sec, or external process controls (fork/exec) per second you get.

Solaris ksh / ksh93 uses posix_spawn() and Solaris 11.4 implements in in the kernel instead of using vfork() like it was doing previously. For those who don't know, VMS has vfork() that works more-or-less like BSD vfork(), but implemented with something like setjmp/longjmp, which passes the open file descriptors to the subprocess when you call exec*() using a magic undocumented mailbox (like UNIX pipes).

It would *definitely* make sense for VMS to provide a posix_spawn() API since it would be more efficient than the current method. Getting back to shells, I discovered bash had so many global variables that I needed to put them somewhere if I was going to try my plan to get the VMS port working more reliably by passing subshell data instead of bash (and every other UNIX shell)'s behavior of using fork() and the subshell inheriting stuff.

Bash is too large of a program to refactor into proper C++ quickly, and dash (the default /bin/sh in Debian/Ubuntu) is faster than bash at present, but my theory is that setjmp/longjmp, which bash *also* uses extensively internally, as a poor substitute for C++ exceptions, is slowed down by using that method of error handling, rather than C++ exceptions (which I'm trying to swap in as a replacement).

My theory is Itanium in particular is bad at setjmp/longjmp because it has so much state to save/restore (giant register stack). I'm upgrading all the Gentoo Linux packages on my rx2620 now that I've removed the Radeon 7500 card that I'd added that was causing Linux to freeze (apparently the Radeon "drm" driver doesn't like 2 cards in one Itanium), so I can run benchmarks there and also on the OpenVMS side.

I've decided to take a slightly different route for populating my preferred VMS POSIX environment, which is to start with a subset of the NetBSD userland. That's what MINIX did, and it worked out fine for them. Once I have something that looks acceptable to pkgsrc, as well as NetBSD's /bin/sh and UNIX utilities, BSD make, and C wrappers to make CC/CXX look like cc/c++, then I'll still only have C++03, but I'd also have a NetBSD userland at a fraction of the effort that porting GNU userland has turned out to be. I did learn more than I ever wanted to know about GNU autoconf, automake, libtool, and friends.

Cheers,
Jake Hamby

Arne Vajh??j <arne@vajhoej.dk> wrote:
> On 11/10/2022 10:47 PM, John Forkosh wrote:
>> Scott Dorsey <kludge@panix.com> wrote:
>>> But, that said, I miss commercial grade operating systems that are
>>> database-centric with the filesystem and database being integrated. I
>>> think that is a good approach for commercial applications, what we once
>>> called "ADP." Perhaps the future isn't VMS but I would like to see some
>>> of the concepts within VMS integrated into future commercial systems.
>>>
>>> As software becomes more and more expensive, I think the need to have an
>>> efficient operating system that provides database features in the kernel
>>> becomes more important.
>>
>> I gotta disagree there. Decomposing the environment lets you migrate
>> applications more easily if that becomes necessary or desirable.
>> Like if mysql or msql provides all necessary dbms functionality,
>> they're typically pretty easy to install just about anywhere.
>> Even more generally, I usually try to abstract the dbms needs
>> of an application by writing a little library of glue functions,
>> whereby the application never directly makes any dbms calls at all,
>> just issues calls to the glue functions, which isolate the dbms and
>> can then be written/rewritten to work with whatever dbms is convenient.
>
> Most probably pick an existing glue layer instead of writing one.
> C: ODBC, C++: ODBC or ADO, Java: JDBC, C#/VB.NET: ADO.NET (IDb*),
> PHP: PDO, Python: DB API 2.0 etc..
> Arne

Thanks, Arne. Yeah, but I adopted this approach back in the 1980s,
mostly under VMS/C, before that stuff was available. In particular,
under a contract with Chase, developing a trading system for their
treasury desk, where traders couldn't easily determine prices for
off-the-run issues. But I got a good look at, and chance to play
with, trading desks using Sun and Apollo workstations, which just
blew away the 780 I was using, and at maybe one-tenth (just pulling
that number out of my elbow) the price. So it became abundantly
clear, to me, which way the world was turning, and I wanted to be
sure stuff I was developing would be as portable as possible, e.g.,
got rid of all the descrip and rtl stuff, encapsulating them
in little libraries that could be rewritten for unix without
involving the 50,000 or so lines of business logic and front end
stuff. ( Oh, and I still fondly recall that project's vp manager,
Steve Allen... my preceding Chase contract had me reporting to
Kate Smith. Go figure :)
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On 11/11/2022 10:25 PM, Craig A. Berry wrote:
> On 11/11/22 6:37 PM, Arne Vajhøj wrote:
>> On 11/10/2022 7:19 PM, Phillip Helbig (undress to reply) wrote:
>>> In article <tkk3rr$em$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
>>> <arne@vajhoej.dk> writes:
>>>>> Consider the fact that the user submitting the file might not have
>>>>> write
>>>>> permission to the current directory or to the directory where the
>>>>> procedure is located, but very probably does to SYS$LOGIN.
>>>>
>>>> Not having write access to the dir must be a special case.
>>>
>>> I don't know.  Certainly there are environments where there is some
>>> official software or whatever where normal users are not allowed to
>>> write.  Think SYS$SYSTEM.  Should every user have access there?  Think
>>> of a company's software package in some directory.  Same thing.
>>
>> I am not saying that such cases does not exist - I am just saying that
>> they must be rare.
>
> Not at all.  It's actually the most common use case in my experience.
>
>> I don't expect many users to SUBMIT COM files residing in
>> SYS$SYSTEM.
>
> More likely SYS$MANAGER or a site-specific common directory, but rarely
> a directory to which all users have write access.
>
>> And the two most common cases for software packages must be
>> system wide install with any batch job started by SYSTEM and
>> user installs in the users dir tree started by that user.
>> Leaving only the more unusual cases.
>
> What you consider unusual is actually all I've ever seen in a production
> environment.  And I've seen lots of non-system users submitting batch
> jobs from system or site directories to which they do not have write
> access.

OK.

Based on a quick survey on c.o.v then I will conclude that
my assumptions about the usage of batch jobs was wrong.

And as consequence trying to put log file in same
dir as com file is not a good idea.

Arne

On 11/11/2022 11:41 PM, Jake Hamby (Solid State Jake) wrote:
> I did learn more than I ever wanted to know about GNU autoconf, automake, libtool, and friends.

I don't recall ever hearing anyone saying that they
like autoconf/automake.

:-)

Arne

In article <tkmps3$1g3j$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<arne@vajhoej.dk> writes:

> On 11/10/2022 7:19 PM, Phillip Helbig (undress to reply) wrote:
> > In article <tkk3rr$em$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
> > <arne@vajhoej.dk> writes:
> >>> Consider the fact that the user submitting the file might not have write
> >>> permission to the current directory or to the directory where the
> >>> procedure is located, but very probably does to SYS$LOGIN.
> >>
> >> Not having write access to the dir must be a special case.
> >
> > I don't know. Certainly there are environments where there is some
> > official software or whatever where normal users are not allowed to
> > write. Think SYS$SYSTEM. Should every user have access there? Think
> > of a company's software package in some directory. Same thing.
>
> I am not saying that such cases does not exist - I am just saying that
> they must be rare.
>
> I don't expect many users to SUBMIT COM files residing in SYS$SYSTEM.

That's not what I meant. Many large software packages have a directory
like SYS$SYSTEM where the software resides. Like SYS$SYSTEM it is
probably shared by several users. It wouldn't make sense to have the
log files there.

In article <tkn3nv$13e5ä4@dont-email.me>, "Craig A. Berry"
<craigberry@nospam.mac.com> writes:

> >>>> Consider the fact that the user submitting the file might not have
> >>>> write
> >>>> permission to the current directory or to the directory where the
> >>>> procedure is located, but very probably does to SYS$LOGIN.
> >>>
> >>> Not having write access to the dir must be a special case.
> >>
> >> I don't know. Certainly there are environments where there is some
> >> official software or whatever where normal users are not allowed to
> >> write. Think SYS$SYSTEM. Should every user have access there? Think
> >> of a company's software package in some directory. Same thing.
> >
> > I am not saying that such cases does not exist - I am just saying that
> > they must be rare.
>
> Not at all. It's actually the most common use case in my experience.
>
> > I don't expect many users to SUBMIT COM files residing in
> > SYS$SYSTEM.
>
> More likely SYS$MANAGER or a site-specific common directory, but rarely
> a directory to which all users have write access.
>
> > And the two most common cases for software packages must be
> > system wide install with any batch job started by SYSTEM and
> > user installs in the users dir tree started by that user.
> > Leaving only the more unusual cases.
>
> What you consider unusual is actually all I've ever seen in a production
> environment. And I've seen lots of non-system users submitting batch
> jobs from system or site directories to which they do not have write access.

Right.

On 11/11/22 10:41 PM, Jake Hamby (Solid State Jake) wrote:

> It would *definitely* make sense for VMS to provide a posix_spawn()
> API since it would be more efficient than the current method.

It would still have to do some tricks to preserve open file descriptors,
copy the argv and envp arrays to the child, etc. But hopefully it could
be done without the setjmp/longjmp business. For folks not familiar,
it's documented here:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn.html

> Getting back to shells, I discovered bash had so many ... <snip>

> I've decided to take a slightly different route for populating my
> preferred VMS POSIX environment, which is to start with a subset of
> the NetBSD userland. That's what MINIX did, and it worked out fine
> for them. Once I have something that looks acceptable to pkgsrc, as
> well as NetBSD's /bin/sh and UNIX utilities, BSD make, and C wrappers
> to make CC/CXX look like cc/c++, then I'll still only have C++03, but
> I'd also have a NetBSD userland at a fraction of the effort that
> porting GNU userland has turned out to be. I did learn more than I
> ever wanted to know about GNU autoconf, automake, libtool, and
> friends.

This doesn't surprise me. Most of the BSD code I've seen has been
continuously refactored to be readable and use modern practices, which
can make it much easier to port than code that has not been so well
maintained.

Note that on OpenVMS x86_64, the C++ offering will be clang++, so you'll
get some recentish standard, not sure which one initially.

On Saturday, November 12, 2022 at 4:52:41 PM UTC-5, Craig A. Berry wrote:

> Note that on OpenVMS x86_64, the C++ offering will be clang++, so you'll
> get some recentish standard, not sure which one initially.
Well, I'd like to say C++17 (clang certainly supports that) but we still need to work on some of the STL packages. So syntax wise, C++17, STL wise, stick to C++14.

On Sunday, November 13, 2022 at 4:30:30 AM UTC-5, John Dallman wrote:
> In article <6f314de0-5d15-416c...@googlegroups.com>,
> xyzz...@gmail.com (John Reagan) wrote:
>
> > Well, I'd like to say C++17 (clang certainly supports that) but we
> > still need to work on some of the STL packages. So syntax wise,
> > C++17, STL wise, stick to C++14.
> OK, so not a cutting-edge clang at first.
>
> John
Uh, almost the current version and we'll upgrade to the latest sometime next year once
we get the other compilers in place. Current clang does not fully support C++20 or C++2b

https://clang.llvm.org/cxx_status.html

What's your real question?

On 2022-11-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/11/2022 7:40 PM, Scott Dorsey wrote:
>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>> On 11/10/2022 9:51 AM, Scott Dorsey wrote:
>>>> As software becomes more and more expensive, I think the need to have an
>>>> efficient operating system that provides database features in the kernel
>>>> becomes more important.
>>>
>>> Database in the actual OS kernel or just database shipping with the
>>> OS distribution?
>>>
>>> It is not uncommon to put application functionality in the
>>> kernel today, but I am not keen on the idea.
>>
>> I think in the kernel. Maybe not in the top ring, but in a ring below it.
>> I want fast database access, I want rapid transaction turnover, I don't care
>> necessarily about realtime operation or any direct UI other than for
>> administration, or ever specifically making deadline. I'm thinking of a
>> specialized database engine.
>
> I don't think I have ever heard about that for database.
>

Rdb ? :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/14/2022 1:59 PM, Simon Clubley wrote:
> On 2022-11-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/11/2022 7:40 PM, Scott Dorsey wrote:
>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>>> On 11/10/2022 9:51 AM, Scott Dorsey wrote:
>>>>> As software becomes more and more expensive, I think the need to have an
>>>>> efficient operating system that provides database features in the kernel
>>>>> becomes more important.
>>>>
>>>> Database in the actual OS kernel or just database shipping with the
>>>> OS distribution?
>>>>
>>>> It is not uncommon to put application functionality in the
>>>> kernel today, but I am not keen on the idea.
>>>
>>> I think in the kernel. Maybe not in the top ring, but in a ring below it.
>>> I want fast database access, I want rapid transaction turnover, I don't care
>>> necessarily about realtime operation or any direct UI other than for
>>> administration, or ever specifically making deadline. I'm thinking of a
>>> specialized database engine.
>>
>> I don't think I have ever heard about that for database.
>
> Rdb ? :-)

I thought that was in user space not kernel space (P0 vs S0 in
more VMSish teminology).

Arne

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj
> via Info-vax
> Sent: Monday, November 14, 2022 8:53 PM
> To: info-vax@rbnsn.com
> Cc: Arne Vajhøj <arne@vajhoej.dk>
> Subject: Re: [Info-vax] What does VMS get used for, these days?
>
> On 11/14/2022 1:59 PM, Simon Clubley wrote:
> > On 2022-11-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
> >> On 11/11/2022 7:40 PM, Scott Dorsey wrote:
> >>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
> >>>> On 11/10/2022 9:51 AM, Scott Dorsey wrote:
> >>>>> As software becomes more and more expensive, I think the need to
> >>>>> have an efficient operating system that provides database features
> >>>>> in the kernel becomes more important.
> >>>>
> >>>> Database in the actual OS kernel or just database shipping with the
> >>>> OS distribution?
> >>>>
> >>>> It is not uncommon to put application functionality in the kernel
> >>>> today, but I am not keen on the idea.
> >>>
> >>> I think in the kernel. Maybe not in the top ring, but in a ring below it.
> >>> I want fast database access, I want rapid transaction turnover, I
> >>> don't care necessarily about realtime operation or any direct UI
> >>> other than for administration, or ever specifically making deadline.
> >>> I'm thinking of a specialized database engine.
> >>
> >> I don't think I have ever heard about that for database.
> >
> > Rdb ? :-)
>
> I thought that was in user space not kernel space (P0 vs S0 in more VMSish
> teminology).
>
> Arne

For historical purposes, before it was sold to Oracle, I believe the Rdb runtime was included with the OpenVMS distribution.

Can't remember what licensing terms were.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 11/14/2022 9:16 PM, kemain.nospam@gmail.com wrote:

> For historical purposes, before it was sold to Oracle, I believe the Rdb runtime was included with the OpenVMS distribution.
>
> Can't remember what licensing terms were.

Yeah, which is why various layered products (the defragger, DEC/EDI, CDD+,
etc...) used Rdb as their database.

Rdb RTO was part of all of the NAS license packages in the early-to-mid-90's

--

--- Rob

Den 2022-11-15 kl. 03:16, skrev kemain.nospam@gmail.com:
>
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj
>> via Info-vax
>> Sent: Monday, November 14, 2022 8:53 PM
>> To: info-vax@rbnsn.com
>> Cc: Arne Vajhøj <arne@vajhoej.dk>
>> Subject: Re: [Info-vax] What does VMS get used for, these days?
>>
>> On 11/14/2022 1:59 PM, Simon Clubley wrote:
>>> On 2022-11-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 11/11/2022 7:40 PM, Scott Dorsey wrote:
>>>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>>>>> On 11/10/2022 9:51 AM, Scott Dorsey wrote:
>>>>>>> As software becomes more and more expensive, I think the need to
>>>>>>> have an efficient operating system that provides database features
>>>>>>> in the kernel becomes more important.
>>>>>>
>>>>>> Database in the actual OS kernel or just database shipping with the
>>>>>> OS distribution?
>>>>>>
>>>>>> It is not uncommon to put application functionality in the kernel
>>>>>> today, but I am not keen on the idea.
>>>>>
>>>>> I think in the kernel. Maybe not in the top ring, but in a ring below it.
>>>>> I want fast database access, I want rapid transaction turnover, I
>>>>> don't care necessarily about realtime operation or any direct UI
>>>>> other than for administration, or ever specifically making deadline.
>>>>> I'm thinking of a specialized database engine.
>>>>
>>>> I don't think I have ever heard about that for database.
>>>
>>> Rdb ? :-)
>>
>> I thought that was in user space not kernel space (P0 vs S0 in more VMSish
>> teminology).
>>

The Rdb code is not in the kernel as such. But of course, Rdb has a quite
close integration with and dependencies on VMS features usch as DLM and
locking functions.

>> Arne
>
> For historical purposes, before it was sold to Oracle, I believe the Rdb runtime was included with the OpenVMS distribution.
>

What has that to do with kernel vs. user space?

> Can't remember what licensing terms were.
>
> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com
>
>
>
>

Den 2022-11-15 kl. 03:55, skrev Robert A. Brooks:
> On 11/14/2022 9:16 PM, kemain.nospam@gmail.com wrote:
>
>> For historical purposes, before it was sold to Oracle, I believe the Rdb
>> runtime was included with the OpenVMS distribution.
>>
>> Can't remember what licensing terms were.
>
> Yeah, which is why various layered products (the defragger, DEC/EDI, CDD+,
> etc...) used Rdb as their database.
>
> Rdb RTO was part of all of the NAS license packages in the early-to-mid-90's
>

Right. The VMS pre-compilers was missing. And no interactive SQL interface.

We developed a PC Windows frontend that used SQL/Services that gave us
all interactive SQL functions (well, not the HELP...).

So we used that to create our databases for our VB6 applications
on our Rdb-RTO installation (MV-3100/90 at that time and Rdb 4.x).

Actually made a presentation on a Swedish Decus meeting on that...

According to Oracle Rdb support, we were among the first world-wide
to write PC/Windows applications using the DLL's (at that time
undocumented) to wrote VB6 applications with Rdb backend.
This was before ODBC had been released.
Sold a copy of our VB6/Rdb interface to a guy in US (or Canada).

Fun times! :-)

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 11/11/2022 7:40 PM, Scott Dorsey wrote:
>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>>> On 11/10/2022 9:51 AM, Scott Dorsey wrote:
>>>>> As software becomes more and more expensive, I think the need to have an
>>>>> efficient operating system that provides database features in the kernel
>>>>> becomes more important.
>>>>
>>>> Database in the actual OS kernel or just database shipping with the
>>>> OS distribution?
>>>>
>>>> It is not uncommon to put application functionality in the
>>>> kernel today, but I am not keen on the idea.
>>>
>>> I think in the kernel. Maybe not in the top ring, but in a ring below it.
>>> I want fast database access, I want rapid transaction turnover, I don't care
>>> necessarily about realtime operation or any direct UI other than for
>>> administration, or ever specifically making deadline. I'm thinking of a
>>> specialized database engine.
>>
>> I don't think I have ever heard about that for database.
>>
>
>Rdb ? :-)

RDB is a start, and RDB is about as tight integration as you can get today.
It was state of the art in the 1980s and allowed better database performance
than anything else on comparable hardware.

I'd like to see that sort of design moved forward into the 21st century with
even tighter integration, maybe a microkernel with very low overhead, and a
special purpose system that does nothing but serve databases out.

We already have some special purpose systems that do nothing but serve web
pages out but for the most part the web frontend can be distributed so there
is little need for the ultimate performance on a single box. For database
use there is.

Anyone remember the Britton-Lee machine?
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2022-11-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/14/2022 1:59 PM, Simon Clubley wrote:
>> On 2022-11-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 11/11/2022 7:40 PM, Scott Dorsey wrote:
>>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>>>> On 11/10/2022 9:51 AM, Scott Dorsey wrote:
>>>>>> As software becomes more and more expensive, I think the need to have an
>>>>>> efficient operating system that provides database features in the kernel
>>>>>> becomes more important.
>>>>>
>>>>> Database in the actual OS kernel or just database shipping with the
>>>>> OS distribution?
>>>>>
>>>>> It is not uncommon to put application functionality in the
>>>>> kernel today, but I am not keen on the idea.
>>>>
>>>> I think in the kernel. Maybe not in the top ring, but in a ring below it.
>>>> I want fast database access, I want rapid transaction turnover, I don't care
>>>> necessarily about realtime operation or any direct UI other than for
>>>> administration, or ever specifically making deadline. I'm thinking of a
>>>> specialized database engine.
>>>
>>> I don't think I have ever heard about that for database.
>>
>> Rdb ? :-)
>
> I thought that was in user space not kernel space (P0 vs S0 in
> more VMSish teminology).
>

I thought the core Rdb components ran in Executive mode. Was I wrong
about that ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Den 2022-11-15 kl. 15:11, skrev Simon Clubley:
> On 2022-11-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/14/2022 1:59 PM, Simon Clubley wrote:
>>> On 2022-11-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 11/11/2022 7:40 PM, Scott Dorsey wrote:
>>>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>>>>> On 11/10/2022 9:51 AM, Scott Dorsey wrote:
>>>>>>> As software becomes more and more expensive, I think the need to have an
>>>>>>> efficient operating system that provides database features in the kernel
>>>>>>> becomes more important.
>>>>>>
>>>>>> Database in the actual OS kernel or just database shipping with the
>>>>>> OS distribution?
>>>>>>
>>>>>> It is not uncommon to put application functionality in the
>>>>>> kernel today, but I am not keen on the idea.
>>>>>
>>>>> I think in the kernel. Maybe not in the top ring, but in a ring below it.
>>>>> I want fast database access, I want rapid transaction turnover, I don't care
>>>>> necessarily about realtime operation or any direct UI other than for
>>>>> administration, or ever specifically making deadline. I'm thinking of a
>>>>> specialized database engine.
>>>>
>>>> I don't think I have ever heard about that for database.
>>>
>>> Rdb ? :-)
>>
>> I thought that was in user space not kernel space (P0 vs S0 in
>> more VMSish teminology).
>>
>
> I thought the core Rdb components ran in Executive mode. Was I wrong
> about that ?
>
> Simon.
>

Maybe so, but the question was if Rdb run in the kernel, wasn't it?