Precise control of file sharing per Java file open

[BenAArmstrong]

While I am aware that OpenVMS Java provides crude means to change file sharing modes via logical names, I have not been able to find a nice mechanism to change these controls exactly when I need them, something along the same lines as decc$feature_set_value(), except for the java$ controls. Am I missing something?

Here's the scenario: because we are used to VMS file open semantics, we may have code that depends on the default that if a file is open for writing, it is locked against access by other processes. Such code would typically poll until the file became available. We are unsure how many places we've made this assumption it is likely to have crept into our sizable Ruby codebase now, which recently we have started to run on JRuby on the Itanium platform, as it lacks any other viable ruby port. However, for certain files we *do* want to share the file. In our C-based Ruby implementation on alpha, we could simply call the extended open to specify shr=get,shr=put, etc. In Java, it appears we have to set some logical name, but we don't want that name globally defined. Hence the desire for a more precise way to control this behaviour.

Are we expected to bracket each file open requiring sharing with code to query, set and restore the value of the java$file_open_mode logical (to 3, and back to its original value afterwards)? Will that even work? If so, does it need to be a job logical? Couldn't that inadvertently affect other threads in a multithreaded app and therefore require the use of a mutex? And yes, I'm aware of the other logical, java$filename_match_list, for more precise control ... but we don't even want to set that globally, as sometimes we may want sharing allowed and sometimes not for the same files, depending on context.

This whole file sharing thing seems to be a bit of a mess, and it doesn't look like any progress has been made to make it better in the past couple of years. Is there any hope of improvement anytime soon?

Ben

[H.Becker]

>>> ... set and restore the value of the java$file_open_mode logical (to 3, and back to its original value afterwards)? Will that even work?

No. It looks like the "logical" is translated once. But it isn't a logical, it is a C environment variable. Instead of defining these logicals try a DCL symbol with the same name and you should see it has the same effect. I suspect - no I can't prove it and I have an old Java version, anyway - that the Java VM uses getenv(), which by default looks for DCL symbols and logicals. For C environment variables there is a putenv() as well. That doesn't change the DCL symbol nor the logical but it changes what the next getenv() (in the same program) will return. I tried an JNI with putenv(), but it seems to have no effect. It seems,  Java does only one getenv for the open_mode.

>>> And yes, I'm aware of the other logical, java$filename_match_list, for more precise control ... but we don't even want to set that globally, as sometimes we may want sharing allowed and sometimes not for the same files, depending on context.

If  the context is known before running Java - in a DCL command procedure - I would set up a user-mode logical, for example define/user JAVA$FILENAME_MATCH_LIST "*.log=shr=get,put,upi/rop=rea". This way it should not affect any other program in the job tree or the system. If the context is known in Java, it may be too late. Java may save the pattern as it seems to save the open_mode. But it is easy to test this with a simple JNI. Sorry, I can't test this on my system, Java 1.3.1 doesn't have the filename-match-list feature.

[BenAArmstrong]

I was afraid it would be like this. That makes it rather difficult to solve in a general way. I now need to review every single possible instance of this problem and solve it on the outside in the calling procedures rather than deploying some seamless wrapper inside my JRuby code to deal with the issue. I really wish HP would fix this properly, as it is a gross hack.

Ben