Xref: utzoo comp.lang.fortran:5106 alt.sys.sun:3374
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!dinkum!calvin
From: calvin@dinkum.wpd.sgi.com (Calvin H. Vu)
Newsgroups: comp.lang.fortran,alt.sys.sun
Subject: Re: Sun Fortran Unformatted Write
Message-ID: <1991Apr5.000533.26246@odin.corp.sgi.com>
Date: 5 Apr 91 00:05:33 GMT
References: <769@rocksanne.WRC.XEROX.COM> <1991Apr4.145658.8389@ux1.cso.uiuc.edu>
Sender: news@odin.corp.sgi.com (Net News)
Distribution: usa
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 50

In <1991Apr4.145658.8389@ux1.cso.uiuc.edu> edotto@ux1.cso.uiuc.edu (Ed Otto) writes:

| jeyadev@WRC.XEROX.COM (Surendar Jeyadev) writes:
| 
| >write(3) (((array(i,j,k), k=1,kmax), j=1,jmax), i=1,imax)
| >.......
| > 
| >While the version 1.2 did not seem to mind, version 1.3.1 declares
| >a segmentation fault and quits. Using dbx I got
| > 
| >signal SEGV (no mapping at the fault address) in w4cp at 0xf76f0724
| >w4cp+8: ld  [%o0 + %o1],  %o4
| > 
| >The user of this program used to run it on a VAX and the write 
| >statement was tailored to take into account the fact that the maximum
| >number of records that could be written is 8191. After playing around
| >a bit with the values of imax, jmax and kmax, I found that the program
| >works fine for small values of the 3 numbers, but crashes when their
| >product reaches a critical value.
| 
| My bet is that you aren't running into # of record limit so much as a SIZE of
| record limit...
| 
	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.

- calvin
--
-----------------------------------------------------------------------------
Calvin H. Vu			   | "We are each of us angels with only one
Silicon Graphics Computer Systems  | wing.  And we can only fly embracing
calvin@sgi.com   (415) 962-3679	   | each other."