[Info-vax] Multiple File Readers/Writers

[JF Mezei]

chrisj.doran%proemail.co.uk at gtempaccount.com wrote:

> Sorry, forget what I said; I must have been thinking of some other
> problem/system. As you say, the problem is in the reader, as DUMP
> shows the file changing.

Don't underestimate caching.  Dump starts "naked" and reads disk blocks.
Your reader application may already have the desired block in a buffer
and unless that buffer has been somewaht marked as "stale", it won't
read it from disk when the reader wants some info from it.


Ok. I pulled an old program from a backup. These were logging routines
used to write new lines of text at end of the log file and make those
available to other processes at regular intervals.




log_fab = fopen(filenam,"w","ctx=rec","shr=get","rfm=var","rat=cr");


and at regular intervals, I would do:

fflush(log_fab);
fsync(fileno(log_fab);


to write text, I used fwrite(

  fwrite(log_buffer,strlen(log_buffer),1,log_fab);


i believe that fflush does very little. So if you use open instead of
fopen, fsync would use the filenumber provided by open.

as I recall "ctx=rec" was very important. In your case, if you are
writing range of bytes, I am not sure how this behaves.

The fsync was important in updating the end of file pointer (log files
tend to grow, so if the reader doesn't know that 30 bytes were added to
the end of the file, it won't read them even if they are written to disk.


A native VMS guy might suggest you use a global section. Your program
maps the file as a gobal section. The application then has the file
mapped to memory so you can use memory operations to read/write data and
the system eventually flushes the changes to disk. But other processes
access the same global section so when you make a change, that change is
automatically available to other processes even if not already written
to disk.

note that global buffers are not the same as global sections.


> 
> I note that my (rather old)  manual says that "file sharing is not
> supported for stream files" but setting ctx=rec doesn't help. Nor does
> turning off buffering with setvbuf. 

I am not 100% sure how to solve your problem, but I suspect that to
update a random number of bytes in a random location in the file, you
would have to use a "binary" file (such as rfm=fix and lrl=512 and ctx=bin)

To update a line in a text file, you need to have the exact same number
of bytes in the update. (ctx=rec and rfm=var).

If you use ctx=bin, the system won't try to process "records". So in a
stmlf file format, you could easily overwrite a cr-lf combination with
"aa" and cause two lines to be joined when they are typed.

With a variable length record format, you cannot play with this because
mucking about with the 2 byte record header (containing it length) will
screw the whole rest of the file.

remember that normally, the C RTL will synthesize "records" for you when
you write, and will synthesize a "\n" when you read records. This
processing is avoided with ctx=bin.