topic Re: Why SQLite does not work on OpenVMS in Operating System - OpenVMS

Why SQLite does not work on OpenVMS

Ph Vouters — Tue, 20 Nov 2012 21:21:29 GMT

Sure facts: http://vouters.dyndns.org/tima/OpenVMS-SQLite-A_possible-reason_why_SQLite_does_not_work_under_OpenVMS.html

Untested: SQLite executed in a threaded environment

Re: Why SQLite does not work on OpenVMS

H.Becker — Wed, 21 Nov 2012 19:12:28 GMT

Running one instance of the pointed-to example test-fcntl for about 2 seconds (elapsed) results in

...

Locking x.db ...

Unlocking x.db ...

Locking x.db ...

Unlocking x.db ...

Could not unlock x.db. Error : error 0

From what I conclude that this test program does show a problem but it very likely is not a - and seems unrelated to a (possible) SQLite3 or CRTL - deadlock problem. However, if I modify the sources to lock and unlock the very same range (no matter whether I set a reasonable file offset into l_start or not) two instances run and run and run and ... happily taking over the 2 CPUs of a DS20 running V8.3.

$ mc GNV$GNU:[bin]diff -u test-fcntl.c~ test-fcntl.c

--- test-fcntl.c~ Wed Nov 21 12:33:30 2012

+++ test-fcntl.c Wed Nov 21 12:47:35 2012

@@ -10,16 +10,7 @@

static int unixFileLock(int fd,int action)

{

int rc;

- struct flock lock;

- lock.l_whence = SEEK_SET;

- if (action == F_UNLCK){

- lock.l_start=0;

- lock.l_len = 0;

- } else {

- lock.l_start=SHARED_SIZE;

- lock.l_len = 1;

- }

+ static struct flock lock = {0, SEEK_SET, 0, SHARED_SIZE};

lock.l_type = action;

rc = fcntl(fd, F_SETLK, &lock);

return rc;

Re: Why SQLite does not work on OpenVMS

Craig A Berry — Wed, 21 Nov 2012 20:20:23 GMT

Does SQLite work any better with the SSIO beta kit installed? See http://www.openvms.org/stories.php?story=12/10/15/5186309?

Re: Why SQLite does not work on OpenVMS

Ph Vouters — Thu, 29 Nov 2012 09:50:37 GMT

Harmut,

As usual you do not give your test conditions. In consequence, your conclusions are always unexploitable and subject to caution. I ran the code on several three different VMS IA64 computers. When the test reproducer runs on VMS IA64 V8.4 with latest UPDATE patch, the test reproducer runs forever in a single VMS process. When in a second process you run sqlite> .read sqllite.cmd then the two VMS processes hang. This means even when non-threaded, the test reproducer hangs in such conditions. If you run the test reproducer in one process and sqlite> .read sqllite.cmd in parallel you will notice the hang even on a single CPU running OpenVMS IA64 V8.3 UPDATE 12. If you run the test reproducer in two VMS processses under OpenVMS IA64 V8.4 latest UPDATE, you will notice an apparent hang for a few seconds and one process will display errno = 0 and the other will continue in sequence.

The bug is NOT in the code I show on my Web site. There is a bug within your CRTL/VMS for it to return fcntl set to - 1 and errno set to 0.

For Craig,

I won't beleive SQLite will run much better on OpenVMS whichever the SQLite code is. SQLite depends too much upon file locks. As long as this problem is not cured, SQLite won't run much better on OpenVMS. My guess is that this smells a race condition within the VMS kernel.

Re: Why SQLite does not work on OpenVMS

H.Becker — Thu, 29 Nov 2012 15:55:45 GMT

>> taking over the 2 CPUs of a DS20 running V8.3.

> As usual you do not give your test conditions.

What else do you need?

$ prod show hist

%PCSIUI-E-PRIVCLASS1, operation requires SYSLCK privilege

%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition

$ set proc/priv=SYSLCK

%SYSTEM-W-NOTALLPRIV, not all requested privileges authorized

$ analyze/image decc$shr/sel=(id,b,l)

SYS$COMMON:[SYSLIB]DECC$SHR_EV56.EXE;1

"V8.3-01"

"XBCA-0080070010"

1-MAY-2007 07:04:56.15

Your test-fcntl.c ran into a resource problem: not enough pgflquota, which as you probably know is a shared quota. (Does it ring a bell or what do you mean by "and sqlite> .read sqllite.cmd in parallel"?)

But you can avoid that problem with just locking and unlocking the very same range, as I tried to point out.

It seems SQLite isn't doing this. And with what I have for testing, I can't reproduce the problem other than running into the pagefile limit.

> this smells a race condition within the VMS kernel.

What do you mean, the system image locking.exe? Possible but unlikely: it's not new and used almost everywhere in VMS. Or rather DECC$SHR aka CRTL, which for user applications is not in the "kernel"? Possible, more likely. But what I see so far is a resource problem.