Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!skipper!maine From: maine@altair.dfrf.nasa.gov (Richard Maine) Newsgroups: comp.lang.fortran Subject: Re: Direct Unformatted I/O Message-ID: Date: 31 May 89 15:08:25 GMT References: Sender: news@skipper.dfrf.nasa.gov Organization: NASA Dryden, Edwards, Cal. Lines: 49 In-reply-to: brian@radio.astro.utoronto.ca's message of 31 May 89 04:12:14 GMT In article brian@radio.astro.utoronto.ca (Brian Glendenning) writes: > Now obviously I want to put NSIZE reals into LINE and write them out > later. My question is: what is the proper way to do this. On our Sun > 3 it looks like you fill up the last NSIZE elements of LINE and use a > write statement of the form: > WRITE( [...] REC=[...]) LINE(BIG-NSIZE+1) This would write only a single element, not NSIZE of them. Since the file was opened for direct access with a record length corresponding to NSIZE elements, this statement is illegal. I suppose it is possible that some implementation might fill up the record with succeeding elements, but it is certainly neither portable nor standard. > Is this the right thing to do in general? My recollection was that you > filled up the first NSIZE elements of LINE, and used a line like: > WRITE( [...] REC=[...]) LINE > and the fortran io would automatically take the appropriate number of > units of storage (RECL) from the beginning of line. This asks to write the whole line array. It is illegal and non-portable. I have seen implementations that would fill up the record with the first NSIZE elements (if you used err=... or iostat=... to get control back after the error), but you cannot count on it. The only portable way to do this is with an implied do loop as in WRITE( [...] REC=[...]) (LINE(I),I=1,NSIZE) or something equivalent. Hmm, forgot to mention one other approach, somewhat more roundabout, using adjustable array dimensions in subroutines. CALL SUB(LINE,NSIZE) ... SUBROUTINE SUB(LINE,NSIZE) REAL LINE(NSIZE) ... WRITE( [...] REC=[...]) LINE ... This is probably overly complicated unless it fits in naturally with other program structure. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.1.1]