Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!lll-lcc!ames!ucbcad!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA Newsgroups: comp.os.vms Subject: Re: Specific RMS Questions Message-ID: <8707170621.AA15724@ucbvax.Berkeley.EDU> Date: Fri, 17-Jul-87 02:22:16 EDT Article-I.D.: ucbvax.8707170621.AA15724 Posted: Fri Jul 17 02:22:16 1987 Date-Received: Sat, 18-Jul-87 11:36:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To:Distribution: world Organization: The ARPA Internet Lines: 78 We are in the process of dovetailing our filesystem interfaces (indexed files, sequential files and relative files) to RMS (from UNIX).... Our interface has an open mode called "shared output", the definition of which states that if the file is already opened by another user then the open fails. If the open succeeds then the file is truncated (other users can open the file for shared input if they so choose). ...[W]e have them as follows for shared input and shared output. Shared Output: fab$b_fac = FAB$M_PUT - I want to put records fab$b_shr = FAB$M_SHRGET - I will allow shared gets Shared Input fab$b_fac = FAB$M_GET - I want to get records fab$b_shr = FAB$M_SHRPUT - Puts are allowed FAB$M_SHRGET - Others can also read records FAB$M_SHRDEL - Others can delete records FAB$M_SHRUPDATE - Others can update records Thus the following happens: 1) User 1 opens file for shared input. 2) User 2 opens the file for shared output, the open succeeds. The file gets truncated. User 1 still sees the "old" file. The fact that User 1 still sees the "old" file seems to imply that you've managed to create a new version of the file, which User 2 sees; User 1 keeps running merrily along with the old version. You can avoid this by providing an explicit version number. We want the open in 2) to fail, but can see no way to do this with the RMS file sharing flags. The question is then how can we tell if a file is open in RMS (or in VMS in general)? I noticed that the SHOW DEVICE/FILES lists all the open files on a device. Well, you can tell if a file is open "right now" by trying to open it with fab$b_shr = FAB$V_NIL. This is certain to fail if anyone else has the file open, whatever sharing options they've asked for. However, there is no way to change the "allowed sharing" without closing and reopening the file, which leaves a timing window - as does any other method of checking whether the file is open. If you can live with this, or arrange for your code to work around it, this is the simplest approach. (If I understand what you are trying to accomplish - one writer, any number of readers, if the writer finds NO readers it creates a new file - then the sequence for the writer: Open with NIL sharing; if you succeed, truncate the file and close it then open for write allowing read - will work, since at worst it means a truncated file may get truncated again.) Our DEC person suggested we use the lock manager rather than walk through the VMS internal data structures, since we do not want the applications programs to have special privileges to run. Using the lock manager would also imply that our feature of shared output would only work if all accesses to that file is through our interface. The particular set of access constraints you want is different from the ones RMS provides. You can build any access constraints you want with the lock manager, but there's no way around the fact that, if you want what RMS doesn't provide, programs that use RMS and don't use your code can't possibly hew to your constraints. We also have a function that locks a file provided you already have the file open in shared mode. The lock will fail if: 1) Any records are locked by another user 2) The file is already locked by another user 3) The file is open in exclusive mode Any ideas how this might fit into RMS?? The lock manager is probably the only way to do this, again short of closing and re-opening the file. You might be able to hack something up by choosing a distinguished record in the file - like the first - and locking it to indi- cate the file is locked. BTW, I don't understand what condition 3) means, given that you started off by assuming the file was open in shared mode. -- Jerry -------