Unable to open the Global Database (until rebooting)

[Alex Taylor]

(I tried to post this last week but it doesn't appear to have made it
through. Reposting with some modifications.)


I've created a large WarpIN package (for Gutenprint) which installs
around 3600 files, then runs a REXX script via EXECUTE (which does
several things depending on the circumstances, including potentially
calling a Perl script, and also starting a detached server daemon).

Although the install works fine, for some reason, any attempt to run
WarpIN again afterwards results in the popup error:

WarpIN was unable to open the Global Database at
"C:\ECS\INSTALL\WARPIN\datbas_C.ini": Error 00000020.

This persists until I reboot, after which WarpIN works properly again.

I've seen this on multiple systems, and it happens consistently after
installing this WarpIN package.

At a guess, it looks as though some resource or other isn't getting
freed up properly, but what could I be doing wrong?

Any ideas?

The WPI in question is over 30 MB large, and is part of my CUPS
collection (it requires the cupsbase package as well); I did upload
it to my website at http://users.socis.ca/~ataylo00/os2/printing/ecups/
(the WPI is gutenprint-5_2_7.wpi), but unfortunately the web server is
down at the moment, and may be for a while.

I can however provide the WIS and/or the REXX script that runs via
EXECUTE as needed...

[Paul Ratcliffe]

Post by Alex Taylor
I've created a large WarpIN package (for Gutenprint) which installs
around 3600 files, then runs a REXX script via EXECUTE (which does
several things depending on the circumstances, including potentially
calling a Perl script, and also starting a detached server daemon).
Although the install works fine, for some reason, any attempt to run
WarpIN was unable to open the Global Database at
"C:\ECS\INSTALL\WARPIN\datbas_C.ini": Error 00000020.

That's a hex. code (annoying not formatted properly - I'll fix that),
so 32 decimal - sharing violation.
Something has got the database file open, which is rather anti-social.
Try PSFILES or similar to see if you can tell what.
I'd get it's a PM app. using the Prf*() functions, which are now
incompatible with how WarpIN opens the file (requires exclusive
access).

Post by Alex Taylor
This persists until I reboot, after which WarpIN works properly again.

Whatever had the file open has not now got it open.

Post by Alex Taylor
I've seen this on multiple systems, and it happens consistently after
installing this WarpIN package.

Have you tried taking stuff out of your REXX script bit by bit?
Or just not running it in the first place.

Post by Alex Taylor
At a guess, it looks as though some resource or other isn't getting
freed up properly, but what could I be doing wrong?

Dunno.

[Paul Ratcliffe]

Post by Paul Ratcliffe

Post by Alex Taylor
"C:\ECS\INSTALL\WARPIN\datbas_C.ini": Error 00000020.

That's a hex. code (annoying not formatted properly - I'll fix that),

I can't find that's ever been wrong. It's always had a leading 0x on
the code.
I still think it ought to be decimal though.

[Pete Brown]

Hi Alex

Post by Alex Taylor
(I tried to post this last week but it doesn't appear to have made it
through. Reposting with some modifications.)
I've created a large WarpIN package (for Gutenprint) which installs
around 3600 files, then runs a REXX script via EXECUTE (which does
several things depending on the circumstances, including potentially
calling a Perl script, and also starting a detached server daemon).
Although the install works fine, for some reason, any attempt to run
WarpIN was unable to open the Global Database at
"C:\ECS\INSTALL\WARPIN\datbas_C.ini": Error 00000020.
This persists until I reboot, after which WarpIN works properly again.
I've seen this on multiple systems, and it happens consistently after
installing this WarpIN package.
At a guess, it looks as though some resource or other isn't getting
freed up properly, but what could I be doing wrong?
Any ideas?

I saw this with the ecups003.wpi package.

I can only guess that it was caused by the install routine which started
the cups daemon (cupsd.exe) opened a browser and the ecups HowTo in inf
format.

I suspect starting cupsd.exe from within Warpin may have been the cause
of the problem as that was the only app left running after the ecups003
install.

Regards

Pete

Post by Alex Taylor
The WPI in question is over 30 MB large, and is part of my CUPS
collection (it requires the cupsbase package as well); I did upload
it to my website at http://users.socis.ca/~ataylo00/os2/printing/ecups/
(the WPI is gutenprint-5_2_7.wpi), but unfortunately the web server is
down at the moment, and may be for a while.
I can however provide the WIS and/or the REXX script that runs via
EXECUTE as needed...

[Paul Ratcliffe]

Post by Pete Brown
I suspect starting cupsd.exe from within Warpin may have been the cause
of the problem as that was the only app left running after the

ecups003

Post by Pete Brown
install.

Ah, this is a good clue. The WarpIN database is not being opened with
the NOINHERIT flag, so anything you execute inherits the file handle of
the database, which stops you opening it subsequently (at least while
whatever you executed is still running) in another process.
I thought I'd been through all instances of these years ago, but
obviously missed that one.

[Paul Ratcliffe]

Post by Paul Ratcliffe
Ah, this is a good clue. The WarpIN database is not being opened with
the NOINHERIT flag, so anything you execute inherits the file handle of
the database, which stops you opening it subsequently (at least while
whatever you executed is still running) in another process.

Anyone who wants to fix this until the next release can do the
following in the directory WarpIN is installed in:

copy WPIRTL.DLL WPIRTL.DLL.BAK
lxlite /x WPIRTL.DLL
patch /a WPIRTL.PAT

where WPIRTL.PAT contains the following text:

file wpirtl.dll
ver ccb76 6a0068122100006a11
cha ccb79 92

If you are satisfied it has worked, you can delete the .BAK and .PAT
files.

[Alex Taylor]

Post by Paul Ratcliffe

Post by Pete Brown
I suspect starting cupsd.exe from within Warpin may have been the
cause of the problem as that was the only app left running after the
ecups003 install.

Ah, this is a good clue. The WarpIN database is not being opened with
the NOINHERIT flag, so anything you execute inherits the file handle of
the database, which stops you opening it subsequently (at least while
whatever you executed is still running) in another process.

That was indeed it!

I modified the REXX script and changed
'detach' cupsroot'\cups\sbin\cupsd.exe'
to
rc = SysOpenObject('<ECUPS_DAEMON>', 'DEFAULT', 'TRUE')

And everything seems to work now!

Thanks, guys.