From: CSBVAX::MRGATE!@SRI.Com:BOLTHOUSE%MCOPN1%eg.ti.com@RELAY.CS.NET@SMTP 2-AUG-1987 10:45 To: EVERHART Subj: RE: Re: Specific RMS questions Received: from RELAY.CS.NET by KL.SRI.COM with TCP; Thu 30 Jul 87 15:27:38-PDT Received: from [128.89.1.80] by RELAY.CS.NET id ae00273; 30 Jul 87 16:21 EDT Received: from eg.ti.com by RELAY.CS.NET id ae14029; 30 Jul 87 15:51 EDT Date: Thu, 30 Jul 87 09:59 CDT From: BOLTHOUSE%MCOPN1%eg.ti.com@RELAY.CS.NET Subject: RE: Re: Specific RMS questions To: info-vax@KL.SRI.COM X-VMS-To: SKACSL::IN%"info-vax@kl.sri.com" John Weald wrote: >>>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. David L. Bolthouse (me) wrote: >> 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. Jerry wrote: >> 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. John replies: >I do ensure that the same file is opened. The supercede flag is set and >sys$parse followed by a sys$search is called to get the correct version >number. The problem still occurs. Perhaps a better method to test this is >to open a file GET (allow the world to GET, PUT, UPDATE etc) then read >records from the file. In the mean time remove the file via DCL command delete. >The program is happy as a pig in mud to keep reading records. This >behavior does not surprise me. >Cheers! In order to get to the bottom of this, we created a file, STUFF.DAT;1, containing random text. It's FID (found using DIR/FULL) was 13004,70,0. The following VAX MACRO program was then run: ;Really short macro to create STUFF.DAT file with the SUP bit in the ; FOP on... This will delete the previous file and ; create a new one in it's place... .entry main,0 $CREATE fab=fab blbc r0,999$ $CLOSE fab=fab 999$: ret fab: $FAB fnm=,fop= .end main We opened STUFF.DAT;1 for read via DCL, ran the program, did a DIR/FULL, and another DCL read. $ open/read/share=write stuff_file stuff.dat;1 ! Done by partner in crime... $ run stuff.exe $ dir/full stuff.dat;1 Directory U1:[DCATHEY] STUFF.DAT;1 File ID: (12991,95,0) Size: 0/0 Owner: [DCATHEY] Created: 30-JUL-1987 09:42 Revised: 30-JUL-1987 09:42 (1) Expires: Backup: File organization: Sequential File attributes: Allocation: 0, Extend: 0, Global buffer count: 0, Version limit: 10 Record format: Variable length Record attributes: None Journaling enabled: None File protection: System:RWE, Owner:RWED, Group:RE, World:RE Access Cntrl List: None Total of 1 file, 0/0 blocks. Note the file has been 'truncated' to 0 blocks, and that the File ID (FID) is *different*. On the other hand, the 'old' stuff.dat is still around! $ show dev/files $1$dua12: (uninteresting files omitted...) But,It'sMyJob! 21601E58 !!!!!!! NOTE NO FILE NAME !!!!!!! The file that had been previously opened, is still open, but has been removed from the directory. It is marked for deletion by the XQP (which RMS calls via $QIO), but it can't be deleted until all open channels to it are closed. Next, we opened the 'new' file...and then closed the 'old' file, making it finally, truly disappear. $ open/read/share=write new_file stuff.dat;1 $ show dev/files $1$dua12: But,It'sMyJob! 21601E58 But,It'sMyJob! 21601E58 [DCATHEY]STUFF.DAT;1 ! Now we have a file name on 'new' file...still have 'old' one around $ close stuff_file $ show dev/files $1$dua12: But,It'sMyJob! 21601E58 [DCATHEY]STUFF.DAT;1 ! And now it's gone. The moral of this story: File names, types, and version numbers don't entirely describe a file; indeed, they are there only for the convenience of the programmer/user. File IDs, on the other hand, are guaranteed unique by VMS (and therefore RMS). If you *really* want to truncate the file (as opposed to doing 'random access-style' updates), use the $TRUNCATE RMS service. Hope this helps! David L. Bolthouse David L. Cathey Texas Instruments Defense Electronics Information Systems VAX System Support McKinney, TX AT&T: 214.952.2059 (DLB), 214.952.3503 (DLC) Internet: bolthouse%mcopn1@eg.ti.com, dcathey%mcopn1@eg.ti.com