Thanks Glenn, I found it was working ok, maybe by accident, but also noticed that FINIS often finished with return code 6... So I changed things a bit to use AFTFST and only close files that show as active output files.
I'm having all sorts of fun with stalls, so I don't quit have it 100% right yet. I don't close the file periodically, only a few seconds after writing to the file... The ONCE option on beat controls that. On Fri, Dec 21, 2018 at 6:41 PM Glenn Knickerbocker <[email protected]> wrote: > On 2018-12-20 7:28 PM, Donald Russell wrote: > > Yes I was thinking about beat too. Great minds think alike. (Of course > > there is also the corollary “fools seldom differ”. :-) ) > > The Zappa brothers had something to say about that: > > then baby you and I are doomed to be together > https://www.youtube.com/watch?v=bkeUjftbj6U > > >> > On Thu, Dec 20, 2018 at 12:29 John P. Hartmann <[email protected]> > >> > wrote: > >> > > >> > > > If it is a minidisk file, the reason is that the file is not > closed and > >> > > > hence the FST is not updated on disk. > > That's not what a mode-6 file is waiting for. Looks like MDSKUPDATE is > caching records for the same disk block. If I write a few records at > the start of the file, they don't show up right away, but then if I > write records to another block, the first ones I wrote show up. > > file = 'UPDPLACE FILE' > 'callpipe literal qwer asdf zxcv|dup 500|split|>' file 'A6' > 'addpipe *.out: | diskupdate' file 'A6' > > Address COMMAND 'EXEC VMLINK * 191 <1191 E/E>' > 'callpipe <' file 'e|take 3|literal Before:|cons' > > 'output 0000000001poiu' > 'output 0000000002;lkj' > 'callpipe <' file 'e|take 3|literal During:|cons' > /* not updated yet */ > > 'output 0000000004poiu' > 'output 0000000005;lkj' > 'callpipe <' file 'e|take 3|literal Same block:|cons' > /* still not updated */ > > 'output 0000001501poiu' > 'output 0000001502;lkj' > 'callpipe <' file 'e|take 3|literal Another block:|cons' > /* now they're updated */ > > So instead of periodically closing the file, maybe you could also keep > it open for read with DISKRANDOM, and periodically read and rewrite two > records at least a block apart. (Or, if you have some records that > never change, rewrite two of those that are at least a block apart.) > > When a record spans a block, things get freaky. One block is written > and the other is not. If I write and read record 683 in this file, just > the first two characters are overwritten. > > ¬R >
