- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- About JAVA$FILENAME_MATCH_LIST
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2009 06:56 AM
тАО01-22-2009 06:56 AM
The problem is that the log files are locked for TYPE or EDIT until the application is shut down. But sometimes it is appropriate to see the content of the log files without stopping the application.
I tried the logical DECC$FILE_SHARING and set it to ENABLED. That avoided the "file is locked by another user" if trying to type it, but no content was shown, obviously no flushing took place, a $dir/size=all always shows something like 0/123.
The next approach was to use the logical JAVA$FILE_OPEN_MODE. Using the value 3 for this logical gave sharing, but the behaviour was identical to DECC$FILE_SHARING ENABLED.
Setting JAVA$FILE_OPEN_MODE to 2 gave a good result. Now we are able to type or edit the log files without shutting down the application. But I read that JAVA$FILE_OPEN_MODE = 2 needs many IOs which might impact the performance dramatically.
In http://h18012.www1.hp.com/java/documentation/1.4.2/ivms/docs/release_notes.html#sdk142-5newfeatures I have read this:
$ define JAVA$FILENAME_MATCH_LIST "*.*=shr=get,put,upi/rop=rea"
This is the equivalent of:
$ define java$file_open_mode 3
I tried many different keywords for JAVA$FILENAME_MATCH_LIST (the full list is here:
http://h71000.www7.hp.com/doc/83final/5763/5763pro_027.html#fab_rab_keywords_1 ) but I didn't find any equivalence of $define java$file_open_mode 2. Using JAVA$FILENAME_MATCH_LIST instead of JAVA$FILE_OPEN_MODE might enable me to restrict the sharing for my *.log files - if I could find the needed keywords to get the same behaviour as with JAVA$FILE_OPEN_MODE = 2.
Does anybody know whether this is possible and if, which keywords for JAVA$FILENAME_MATCH_LIST I shall use?
Regards,
Wolfgang
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2009 08:05 AM
тАО01-22-2009 08:05 AM
Re: About JAVA$FILENAME_MATCH_LIST
alternatively you could use backup/ign=inter to take a temporary point in time copy and check that with edit or typ and delete after.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2009 08:29 AM
тАО01-22-2009 08:29 AM
Re: About JAVA$FILENAME_MATCH_LIST
$ dir /siz=all
MYLOG.LOG;1 0/69
$ ty MYLOG.LOG
-RMS-E-FLK, file currently locked by another user
$ backup/ignore=interlock MYLOG.LOG x.log
%BACKUP-W-ACCONFLICT, MYLOG.LOG;1
is open for write by another user
$ dir /siz=all
MYLOG.LOG;1 0/69
X.LOG;1 0/69
$ ty x.log
$
Wolfgang
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2009 08:52 AM
тАО01-22-2009 08:52 AM
Re: About JAVA$FILENAME_MATCH_LIST
:-(
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2009 09:18 AM
тАО01-22-2009 09:18 AM
SolutionJAVA$FSYNC_INTERVAL
RMS buffers are not usually flushed to disk until the buffer is full or the program exits. If you want to view the contents of the file before the buffer is full (e.g., monitoring a logfile for output), the JAVA$FSYNC_INTERVAL logical allows you to define an interval after which all pending output is flushed to the disk with the command:
$ define/job JAVA$FSYNC_INTERVAL
For example,
$ define/job JAVA$FSYNC_INTERVAL 60 ! flush any pending output to disk every 60 seconds.
Note: Defining the logical to a very low value could cause performance degradation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2009 09:29 AM
тАО01-22-2009 09:29 AM
Re: About JAVA$FILENAME_MATCH_LIST
If you're in a relative hurry (and can have OpenVMS-specific code), consider punting on this and going direct to C here for your logs. We all know that works.
As for shr= options for testing, I'd likely go for just "get" here since you likely don't want to have other folks writing to the logs.
It might be feasible to use SET WATCH FILE /CLASS=ALL (with a small reproducer) to see what Java is doing with the file open processing. What options it is using, and allowing. RMS options such as SQO can affect sharing.
Given your apparent employer, I'd suggest using that position and checking with some of the "usual suspects" more directly. (You're probably in a better position to access point fixes and point updates and to lobby for changes than most of the rest of the readers here.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2009 08:23 PM
тАО01-22-2009 08:23 PM
Re: About JAVA$FILENAME_MATCH_LIST
Actually... most data may well be 'flushed' (write behind) on the disk. Specifically every fully filled 'buffer' will have been written. The buffer size is likely equal to what $SHOW RMS indicated for MULTI-BLOCK-COUNT, typically 32 (16KB). The last/current buffer is not flushed, and more importantly, the EOF marker (and lock value block) is not updated to allow say $TYPE or $SEARCH to work.
Mark wrote>> alternatively you could use backup/ign=inter to take a temporary point in time copy and check that with edit or typ and delete after.
Actually... Did you ever try that? backup will happily ignore the interlock, but it will honor the EOF. Even with a file say 0/6432, with 6400 nicely written out blocks, it will not copy anything.
I have lobbied for /ignore=EOF but alas.
And yes $DUMP also needs a /ignore=(interlock, eof) but does not have one.
For desperate case I wrote a tool to 'clone' a file header, set eof on the clone, copy the cloned file, and remove the evidence. Works (for one header), but it is better to look for a 'real' solution with DECCRTL / JAVA settings if at all possible.
Cheers,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2009 08:28 PM
тАО01-22-2009 08:28 PM
Re: About JAVA$FILENAME_MATCH_LIST
Ah, I did not notice this comment at first.
What Hoff means, is talk to Norm and perhaps Thilo and take it from there. :-).
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2009 02:13 AM
тАО01-23-2009 02:13 AM
Re: About JAVA$FILENAME_MATCH_LIST
thanks a lot for pointing me to the JAVA$FSYNC_INTERVAL logical. Using
$ define java$file_open_mode 3
$ define java$fsync_interval 10
is giving a good result, like java$file_open_mode 2, but a little bit less risky for the performance.
Still not any progress with JAVA$FILENAME_MATCH_LIST, will do some more tests, but if that will not work I'll be happy with the other solution.
Wolfgang
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-29-2009 02:43 PM
тАО01-29-2009 02:43 PM
Re: About JAVA$FILENAME_MATCH_LIST
The JDBC drivers have the ability to close and re-open the logfiles online and this can be done so the old log can be typed but is a bit clunky to say the least.
I have tried the suggestions but
I must be doing something wrong as I tried
JAVA$FSYNC_INTERVAL = 10 and
java$file_open_mode = 3
(using JDK 1.5) but still could not TYPE the log file from the application.
Thanks for the other suggestions but we would prefer to have a solution to this problem that is supported by HP.
As for the suggestions of writing a C routine to log it, I am sorry but this wont fly, we use the DriverManager logging so that other JAVA applications may register interest in the log contents and would rather use a supported logging mechanism than roll our own.
I suppose I could investigate creating a stand-alone application that might use the DriverManager logging to capture the output as it is being written to the log file. Seems an overkill to solve something that should be fairly straight forward as SHARED READ.
Does anybody know if the JAVA$FILENAME_MATCH_LIST problem is a known bug ?
It certainly would be advantageous to be able to place the RMS attributes specifically on the one file we are interested rather than across the board.
Anyone know of any programmatic way within JAVA to do the same. I tried all sorts of things with open streams and file with/without locking etc in JAVA but could not find any combination that would allow the appropriate read sharing.
surely this cant be that difficult to do!
jim