HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

bad file number when doing file access in Java

P R Stone_1

bad file number when doing file access in Java

When I run BDBJE I set the environment in the following way:
$@sys$common:[java$142.COM]JAVA$142_SETUP FAST
$ define DECC$efs_case_preserve true
$ define DECC$efs_case_special true
$ define DECC$efs_charset true
$define java$classpath xxx$java:[000000],...
$java -cp $java$classpath "SimpleExample.SimpleExample" "/xxx$java/test/"

I get the following error
com.sleepycat.je.RunRecoveryException: com.sleepycat.je.DatabaseException: Could
n't open file /extel$java/test/00000000.jdb: com.sleepycat.je.RunRecoveryExcepti
on: IOException caught: java.io.IOException: bad file number

I must be missing a setting somewhere
Craig A Berry
Honored Contributor

Re: bad file number when doing file access in Java

What do you get from

$ dir/full extel$java:[test]00000000.jdb
P R Stone_1

Re: bad file number when doing file access in Java

00000000.JDB;1 File ID: (166635,13,0)
Size: 1/3 Owner: [USERS,JAVA]
Created: 20-AUG-2005 13:48:00.40
Revised: 20-AUG-2005 14:22:33.49 (26)
Backup: 22-AUG-2005 04:11:00.45
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 3, Extend: 0, Global buffer count: 0
No version limit
Record format: Stream_LF, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None

Total of 1 file, 1/3 blocks.
Willem Grooters
Honored Contributor

Re: bad file number when doing file access in Java

Found the problem fully described on http://news.gmane.org/gmane.comp.java.bdbje.general ;-)

A few wild shots, since I'm not familiar with this software, but from what I understand from above and subsequent links:
* if the file is to be removed, be sure to have the DELETE privilege set.
* If the file is to be read + write by a number of streams, SHARE must be complete!
* Is the program doing an EXEC: that doesn't work (properly) on VMS (at least, by my latest knowledge)
* Is this the way locks are implemented in Java? SIGH. There must be a better way on VMS, even in JAVA...

Willem Grooters
OpenVMS Developer & System Manager