Yes I was thinking about beat too. Great minds think alike. (Of course there is also the corollary “fools seldom differ”. :-) )
On Thu, Dec 20, 2018 at 14:22 Rob van der Heij <[email protected]> wrote: > On Thu, 20 Dec 2018 at 23:10, Donald Russell <[email protected]> > wrote: > > > Thanks John, > > That’s simpler than what I had in mind. > > > > I may tweak that to close the file less often than on every record, but I > > get the idea. > > > > Or use BEAT to close after some idle time > > > > > Thanks for the tip. :-) > > > > Don > > > > > > 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. Try this: > > > > > > ... | disk update my file x | spec /FINIS MY FILE X/ 1 |command > > > > > > If the file is in SFS, it is on a workunit and things get a bit > trickier. > > > > > > > > > On 12/20/18 20:32, Donald Russell wrote: > > > > I have a server id that has a perpetual pipeline running. Part of the > > > > pipeline uses the DISKUPDATE stage to update individual records in a > > > > fixed-length file. > > > > > > > > What I'm finding is the file is not updated on disk while the > pipeline > > is > > > > running, but when I stop the pipe (with an immcmd and gate stage), > then > > > the > > > > updates are made. > > > > > > > > I was expecting (hoping) the file changes would be reflected in near > > > > real-time so other ids can link to the disk and check it. > > > > > > > > Is there anything I can do to nudge DISKUPDATE? > > > > Maybe turn MDC off for that mdisk? > > > > A specific file mode number? (I'm using 6 for update in place... not > > > > certain about that, I assume it means that if another id has > > > linked/accesed > > > > the disk, they don't have to reaccess to read the same file contents > > > again.) > > > > > > > > Cheers, > > > > Don > > > > > > > > > >
