A feature of POSIX (implemented by UNIX/Linux) is that the normal file access behavior is that multiple processes are allowed to write into a file (of course, as long as they have the requisite permission to do so from the operating system). The expectation is that there will be a higher level protocol to ensure coordination / cooperation between multiple writers. GT.M simply incorporates these semantics into its sequential file IO support. So, if there are multiple processes writing to the same file, the contents of the file will include data from all processes. Depending on how buffers get flushed by the operating system, the data may not be cleanly separated.
I strongly recommend that multiple GT.M processes not write to the same file. What exactly is the desired behavior from a functional point of view? -- Bhaskar On Fri, 2005-12-02 at 11:58 -0800, Greg Woodhouse wrote: > That's an interesting one. It's sounds as if though a file wasn't > locked, allowing a second process to come along and write beyond EOF, > confusing the first. > > --- Kevin Toppenberg <[EMAIL PROTECTED]> wrote: > > > OK, It looks like you are onto something: > > > > Here are my running tasks: > > > > 811444: ENTRY^TIUPRPN, CHART copy of OFFICE VISIT. Device > > S121-LAUGHLIN-LASER. > > UCI,VOL. From 7/6/2005 at 16:09, By HENSLEY,TAMMY G. > > Started running 7/6/2005 at 16:09. Error 7/6/2005 at 16:09. > > HEADER+18~TIUPRPN2, Not positioned to EOF on write > > (sequential organiz > > Job #: 23829 [5D15] > > > ------------------------------------------------------------------------------- > > 812914: ENTRY^TIUPRPN, CHART copy of OFFICE VISIT. Device OR > > WORKSTATION. > > UCI,VOL. From 7/18/2005 at 14:42, By BROWN,CAROL. > > Started running 7/18/2005 at 14:42. Error 7/18/2005 at > > 14:42. > > HEADER+18~TIUPRPN2, Not positioned to EOF on write > > (sequential organiz > > Job #: 7144 [1BE8] > > > ------------------------------------------------------------------------------- > > 812917: ENTRY^TIUPRPN, CHART copy of OFFICE VISIT. Device OR > > WORKSTATION. > > UCI,VOL. From 7/18/2005 at 14:45, By BROWN,CAROL. > > Started running 7/18/2005 at 14:45. Error 7/18/2005 at > > 14:45. > > HEADER+18~TIUPRPN2, Not positioned to EOF on write > > (sequential organiz > > Job #: 7527 [1D67] > > > > 830876: MATCH^PSSPOIKA, Matched Orderable Item Report. Device > > GTM-UNIX-HFS. > > UCI,VOL. From 11/5/2005 at 16:58, By you. > > Started running 11/5/2005 at 16:58. Error 11/5/2005 at > > 16:58. > > DHEAD~PSSPOIKA, Not positioned to EOF on write (sequential > > organizatio > > Job #: 12670 [317E] > > > > > > > > I wonder how to fix this "Not positioned to EOF on write" problem? > > The first entry is for that MATCH^PSSPOIKA report. Perhaps that > > started to problem? > > > > Thanks > > Kevin > > > > > > > > > > On 12/2/05, Greg Woodhouse <[EMAIL PROTECTED]> wrote: > > > Well...If one application mysteriously stops printing, one > > possibility > > > is that the print jobs are still in queue (try "List Tasks"). > > You've > > > ruled out a device problem, and if you're able to use CPRS, then > > the > > > Broker and Taskman must be running. Does it matter if you sign in > > as a > > > different user? Do you know which RPC is used to print? > > > > > > If a program fails "quietly", e.g., with something like > > > > > > Q:BAD > > > > > > or > > > > > > G:BAD CLEANUP > > > > > > then no error will be signaled. The default Kernel error trap logs > > > errors when they occur, but if a problem doesn't lead to a MUMPS > > error > > > (think: "if an exception is not raised/thrown"), then the error > > handler > > > is never called. > > > > > > --- Kevin Toppenberg <[EMAIL PROTECTED]> wrote: > > > > > > > I have a mysterious problem. I have been using VistA/CPRS for at > > > > least 6 months, when suddenly today printing from CPRS stopped > > > > working. > > > > > > > > I have tested that the printer test page CAN be printed from the > > > > server, and I CAN print from the text-based OR OE/RR MENU > > CLINICIAN > > > > (the text based chart). But when I print from CPRS, it just > > doesn't > > > > come out. > > > > > > > > I have tried do ^XTER, and there are no errors reported for > > today. > > > > > > > > Any thoughts? > > > > > > > > Kevin > > > > > > > > > > > > > > === > > > Gregory Woodhouse <[EMAIL PROTECTED]> > > > "Interaction is the mind-body problem of computing." > > > --Philip L. Wadler > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through > > log files > > > for problems? Stop! Download the new AJAX search engine that > > makes > > > searching your log files as easy as surfing the web. DOWNLOAD > > SPLUNK! > > > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > > > _______________________________________________ > > > Hardhats-members mailing list > > > Hardhats-members@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through > > log files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD > > SPLUNK! > > http://ads.osdn.com/?ad_idv37&alloc_id865&op=click > > _______________________________________________ > > Hardhats-members mailing list > > Hardhats-members@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > === > Gregory Woodhouse <[EMAIL PROTECTED]> > "Interaction is the mind-body problem of computing." > --Philip L. Wadler > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
