joa@uklirb.UUCP (10/28/87)
I have some difficulties using files for reading and writing at the same time. The problem is the following: I'd like to write to a file with some program and at the same time to display this file with the DM call 'cv <file>'. But if the writing program does the first access to the file, it is locked and can't be shown by the DM. The same happens if I try to read the file with a second program. All tries with stream calls (STREAM_$REDEFINE) changing the attribute "concurrency at open" failed. Anyone who has a solution for this problem, and with time to help? Joachim Hassdenteufel-Koehler University of Kaiserslautern D-675 Kaiserlautern Tel.: (..631) 205-2647 e-mail: ...!mcvax!unido!uklirb!joa
mishkin@apollo.uucp (Nathaniel Mishkin) (10/30/87)
In article <41600002@uklirb.UUCP> joa@uklirb.UUCP writes: >I have some difficulties using files for reading and writing at the >same time. The problem is the following: I'd like to write to a file >with some program and at the same time to display this file with >the DM call 'cv <file>'. But if the writing program does the first >access to the file, it is locked and can't be shown by the DM. The >same happens if I try to read the file with a second program. > >All tries with stream calls (STREAM_$REDEFINE) changing the attribute >"concurrency at open" failed. I'm afraid you're out of luck. The DM wants "n-readers xor 1-writers" concurrency rules and wants read access. Its desire conflicts with the existing open your program has for write access. The DM is trying to be a good citizen (some would say paternalistic) by ensuring that it doesn't ever show you something that might not be the "truth". Other editors (perhaps "vi") are probably less obsessive in this area and perhaps you could use them to view your file. (Note that your writing program still must use "cowriters" concurrency rules, which is what Unix open/creat give you by default.) -- -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {decvax,mit-eddie,umix}!apollo!mishkin
mkhaw@teknowledge-vaxc.UUCP (10/31/87)
+ I have some difficulties using files for reading and writing at the
+ same time. The problem is the following: I'd like to write to a file
+ with some program and at the same time to display this file with
+ the DM call 'cv <file>'. But if the writing program does the first
+ access to the file, it is locked and can't be shown by the DM. The
+ same happens if I try to read the file with a second program.
+
+ All tries with stream calls (STREAM_$REDEFINE) changing the attribute
+ "concurrency at open" failed.
Oh great, just like VMS. Yecchh!
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303mishkin@apollo.UUCP (11/02/87)
From an engineer at Apollo who wishes to remain nameless, on the topic
of viewing files that are open for write:
----------------------------------------
There are many reasons beyond concurrency that prevent your approach
from working. However, you may find the following to be an acceptable
substitute: instead of creating your output file normally, create it
using pad_$create, asking for a transcript of relative size zero, and
passing the same pathname you would normally use. Then write to this
stream normally. The zero size request tells the DM to not make a window
at all, but to keep track of the output. Then the CV command can later
be used to make a window to view the output. When you close the stream,
and all the windows are gone, the end result is a normal ascii file.
The drawbacks to this approach are as follows: 1) you must have a DM
transcript pad somewhere to begin with, to pass to pad_$create as the
related pad -- if you are running in a normal shell you can just use
standard out -- if you are running via CPO or equivalent, this can be
a problem -- you can call pad_$create_window, but then that really creates
a window. 2) you can only append to the file -- you cannot seek and write
at other places.
----------------------------------------
--
-- Nat Mishkin
Apollo Computer Inc.
Chelmsford, MA
{decvax,mit-eddie,umix}!apollo!mishkinram-ashwin@YALE.ARPA (Ashwin Ram) (11/02/87)
> Date: 30 Oct 87 19:34:00 GMT > From: apollo!mishkin@eddie.mit.edu (Nathaniel Mishkin) > > In article <41600002@uklirb.UUCP> joa@uklirb.UUCP writes: > >I have some difficulties using files for reading and writing at the > >same time. The problem is the following: I'd like to write to a file > >with some program and at the same time to display this file [...] > > I'm afraid you're out of luck. The DM wants "n-readers xor 1-writers" > concurrency rules and wants read access. Its desire conflicts with the > existing open your program has for write access. The DM is trying to > be a good citizen (some would say paternalistic) by ensuring that it > doesn't ever show you something that might not be the "truth". You could, of course, open a transcript window using PAD_$CREATE_WINDOW, passing it the name of the file you want to write into (and the other arguments appropriately). You can now write to this object and have the output appear in the window as well as be written to the file. I have code to do this in T (a Scheme dialect) if you want to peek at it, but it should be pretty straightforward in other languages as well. I'm not sure I understand why the DM needs nR xor 1W. When you create a copy of an edit window, don't you now have two objects (windows) that are both writing to and displaying the same file (at least conceptually)? Why could the same thing not be made to work for a window displaying a file that's being written to by another process? -- Ashwin Ram -- ARPA: Ram-Ashwin@cs.yale.edu UUCP: {decvax,linus,seismo}!yale!Ram-Ashwin BITNET: Ram@yalecs