Xref: utzoo comp.lang.fortran:5113 alt.sys.sun:3383
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!eng.ufl.edu!math.ufl.edu!math.ufl.edu!wang
From: wang@math.ufl.edu
Newsgroups: comp.lang.fortran,alt.sys.sun
Subject: Re: Sun Fortran Unformatted Write
Message-ID: <1991Apr5.015138.12556@math.ufl.edu>
Date: 5 Apr 91 01:51:38 GMT
References: <769@rocksanne.WRC.XEROX.COM> <1991Apr4.145658.8389@ux1.cso.uiuc.edu> <1991Apr5.000533.26246@odin.corp.sgi.com>
Sender: news@math.ufl.edu
Reply-To: wang@math.ufl.edu
Distribution: usa
Organization: Department of Mathematics, University of Florida
Lines: 24

In article <1991Apr5.000533.26246@odin.corp.sgi.com>, calvin@dinkum.wpd.sgi.com (Calvin H. Vu) writes:
|> 	I don't think there is a size of record limit otherwise some of
|>     the CAD/CAM vendors who have multi-mega byte records would have to
|>     rewrite their programs a long time ago :-).
|> 
|>     My guesses:
|> 
|>     1) There is an enhancement in the new Sun release to recognize pattern
|>     such as (array(k), k=1,kmax) as having single step [and hence
|>     is contiguous] so the whole block of unformatted data can be written
|>     at once instead of one element at a time.
|> 
|>     2) There was a bug in the new runtime I/O library so when your 
|>     unformatted data buffer approaches the 8K size you get a coredump.  
|>     [i.e. you also have problem if you have "WRITE(3) A" where A is
|>     an array of size > 8K]
|> 
|>     3) This has already been reported and Sun has fixed it.  If you call
|>     up its Hotline you may even get a patch.
|> 
|> Hey, it's all guessing.

The limitation of 8K maximum record length is a bug of v.1.3.1. You
can get a patch from the SUN to fix it.