Operating System - OpenVMS
1753414 Members
7242 Online
108793 Solutions
New Discussion юеВ

bad file number when doing file access in Java

 
P R Stone_1
Advisor

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/job JAVA$ENABLE_ENVIRONMENT_EXPANSION TRUE
$ define DECC$efs_case_preserve true
$ define DECC$efs_case_special true
$ define DECC$efs_charset true
$ define JAVA$FILE_OPEN_MODE 3
$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
3 REPLIES 3
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
Advisor

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)
Expires:
Backup: 22-AUG-2005 04:11:00.45
Effective:
Recording:
Accessed:
Attributes:
Modified:
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
Willem Grooters
OpenVMS Developer & System Manager