BOLTHOUSE%MCOPN1@eg.ti.COM (07/14/87)
John Weald says (sort of): I want to have a shared read request succeed, and have a subsequent shared write request fail. I'm using RMS from C. >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. > >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 believe the problem is due to the fact that RMS is opening a new file. If you could coerce RMS into attempting to open the same file, it should behave as you want. So, use the $PARSE service to determine the version number of the most recent file and open *it* for shared output. This should fail, since you're attempting to perform incompatible operations on the same file. If you don't specify the exact version number, RMS uses x.y;0. The default action of this file specification when opening for write access is "Make me a new file". Ergo, the problem you have noticed when trying to emulate UNIX-style I/O. Note I haven't tested this theory, but that's my experience with RMS. Good luck! David L. Bolthouse Texas Instruments Defense Electronics Information Systems VAX System Support McKinney, TX AT&T: 214.952.2059 Internet: bolthouse%mcopn1@eg.ti.com