NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/sgi/11132

Internet Message Format | 1992-07-21 | 6.0 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!mp.cs.niu.edu!fnnews!fnsony.fnal.gov!shah
From: [e-mail] (Hemant Shah)
Newsgroups: comp.sys.sgi
Subject: Re: trouble with f77 and named pipes
Message-ID: <[e-mail]>
Date: 21 Jul 92 20:33:17 GMT
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Fermi National Accelerator Laboratory, Batavia, IL
Lines: 165
Nntp-Posting-Host: fnsony.fnal.gov

In article <[e-mail]>, [e-mail] (Burkhard Burow) writes:
|>
|> I'm having trouble using named pipes with SGI's f77. My troubles get worse
|> with the newer software releases.
|>
|> SUMMARY: I'd like SGI f77 to behave like DECFortran w.r.t. named pipes.
|>          i.e. - The READONLY specifier in the OPEN allows Fortran to read from
|>                 a named pipe and recognize the EOF when the partner program has
|>                 closed the pipe.
|>               - Without the READONLY specifier Fortran can write to a named
|>         pipe, blocking etc. as usual.
|>
|> My observations of SGI and Ultrix Fortran with named pipes follows.
|> If I'm doing something goofy please tell me!
|>
|> I'm currently running a simulation program on ~40 DECstations in parallel and
|> the main input and output streams for each instance of the program go through
|> named pipes and on to the manager-program. In a month I'll have access to
|> 32 4D/35's.
|> [Not using named pipes is NOT an option. I'm using an application written for
|>  one proccessor, and use named pipes to allow the unmodified application to
|>  continue to think that it is running on a single processor.]
|>
|> thanks,
|> burkhard   [e-mail]
|>
|> -------begin observations from Fortran/named pipe tests------------------
|>
|> Ultrix  == DECFortran 3.1 running under Ultrix 4.2 on a DECstation.
|> 4D/25   == f77 (versions says ftn 90/10/02) under IRIX 3.3.1 on a 4D/25
|> Crimson == f77 (versions says ftn 06/01/92) under IRIX 4.0.4
|>
|> Fortran reading from a named pipe:
|> ----------------------------------
|>
|> unix> cat > i.f
|>       program i
|>       open (unit=11,status='unknown',form='formatted',file='pipe'
|>      +      ,readonly)
|>       do 100 i=1,10000
|>          read (unit=11,fmt=*,end=999) n
|>          print *, n
|>  100  continue
|>  999  continue
|>       close (unit=11)
|>       end
|> ^D
|> unix> f77 -o i i.f
|> unix> cat > data
|> 1
|> 2
|> 3
|> 4
|> ^D
|> unix> mknod pipe p
|>
|> Then,
|>
|> unix> cat data > pipe & i
|>  and
|> unix> i >& temp & cat data > pipe && cat temp
|>
|> work as expected on the 4D/25 (not the Crimson) and Ultrix.
|> i.e. It doesn't matter which process connects first, and the Fortran program
|>      can read from the named pipe.
|>
|> Ultrix -
|> If I remove the READONLY specifier from the OPEN, DECFortran will never see EOF
|> from the named pipe when the writing process closes its connection. The 4D/25
|> doesn't care about the READONLY and continues to work normally without it.
|>
|> Crimson -
|> I can't get Fortran to recognize 'EOF' for a named pipe. The only way I can get
|> the program to stop reading from the pipe is to send 'bad' input data so that
|> the program exits. e.g.
|> Crimson> i >& i.log&
|> [2] 24448
|> Crimson> cat data > pipe&
|> [3] 24449
|> Crimson>
|> [3]    Done                   cat data > pipe
|> Crimson> echo junk > pipe
|> Crimson>
|> [2]    Exit 112               i >& i.log
|> Crimson> cat i.log
|> list input: incomprehensible list input
|> apparent state: unit 11 named pipe
|> last format: list io
|> lately reading sequential formatted external IO
|>             1
|>             2
|>             3
|>             4
|> Crimson>
|>
|> Again, this behavior is independent of using the READONLY specifier in OPEN.
|>
|>
|> Fortran writing to a named pipe:
|> --------------------------------
|>
|> unix> cat > o.f
|>       program o
|>       open (unit=11,status='unknown',form='formatted',
|>      +      file='pipe')
|>       write (unit=11,fmt=*) 'hi, how are you ?'
|>       end
|> ^D
|> unix> f77 -o o o.f
|> unix> mknod pipe p
|>
|>
|> Now,
|>
|> Ultrix> o & cat pipe > temp
|>  and
|> Ultrix> o & cat pipe > temp
|>
|> works, but on the 4D/25
|>
|> 4D/25> o&
|> 4D/25> cat pipe > temp&
|> 4D/25> echo > pipe
|>
|> 'works'. i.e. A third process has to write to the pipe, and hangup, before the
|> original processes will. Note that if you switch the order of the processes
|> connecting to the pipe,
|>
|> 4D/25> cat pipe > temp&
|> 4D/25> o&
|>
|> nothing will be transferred through the pipe.
|>
|> The Crimson doesn't write to a named pipe. It makes the connection, but doesn't
|> ouput anything. e.g.
|> Crimson> mknod pipe p
|> Crimson> cat pipe >& o.log&
|> [2] 24408
|> Crimson> o
|> [2]  - Done                   cat pipe > & o.log
|> Crimson> cat o.log
|> Crimson>
|>
|> -------end observations from Fortran/named pipe tests------------------

I had similar problem with pipes using C. My code worked under SUN (SunOS
4.1.x) IBM RS/6000 (AIX3.1.5 and AIX 3.2) and SGI (IRIX 3.3.x) but failed
under IRIX 4.0.x. SGI has changed implementation of pipes under IRIX 4.0.x.
The pipes should be opened as READONLY by one process and WRITEONLY by another
process (uni-directional pipe) or both processes should open the pipe
READWRITE (bi-directional) otherwise the system gets confused.

You may want to check your code and make sure that you open pipes in correct
manner.

Hope this help :-)
--
-------------------------------------------------------------------------------
Hemant Shah                            | All the opinions expressed are my own
Fermi National Accelerator Laboratory  | and does not necessarily reflect
Systems Integration Group              | those of Fermilab.
E-mail :[e-mail]             |
 Voice : [phone]                   | I haven't lost my mind
   Fax : [phone]                | it's backed on tape somewhere.
-------------------------------------------------------------------------------