Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!ubc-cs!news-server.csri.toronto.edu!mailrus!ncar!mephisto!udel!nigel.ee.udel.edu!mccalpin From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin) Newsgroups: comp.lang.fortran Subject: Re: record length for direct access files Message-ID: Date: 26 Sep 90 13:06:19 GMT References: <277@cadlab.sublink.ORG> Sender: usenet@ee.udel.edu Organization: College of Marine Studies, U. Del. Lines: 55 Nntp-Posting-Host: perelandra.cms.udel.edu In-reply-to: staff@cadlab.sublink.ORG's message of 25 Sep 90 07:16:34 GMT >>>>> On 25 Sep 90 07:16:34 GMT, staff@cadlab.sublink.ORG (Alex Martelli) said: Alex> mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes: > Silicon Graphics, Sun, Stardent all use RECL=words > IBM RS/6000 uses RECL=bytes Alex> Funny! OUR Sun machines use RECL in bytes, as do HP, Olivetti, and Alex> OS/2. Dec and Sony use (long)words [do all MIPS boxes?]. Ooops, my brain got a bit scrambled there -- Sun does use RECL=bytes. There are two separate issues that I have been working with: (1) RECL=words vs RECL=bytes (2) control words in unformatted sequential files To be specific: (1) Machine RECL=bytes RECL=words -------------------------------------------------- Silicon Graphics 3.1 X Silicon Graphics 3.2+ X Sun 4.0 X Stardent X IBM RS/6000 X -------------------------------------------------- (2) Machine C-W=bytes C-W=words -------------------------------------------------- Silicon Graphics 3.1 X Silicon Graphics 3.2+ X Sun 4.0 X Stardent X IBM RS/6000 X -------------------------------------------------- The control word is a 32-bit integer written before and after each FORTRAN unformatted sequential record which specifies its length. It is not normally visible to the user (from FORTRAN). The fact that Sun, SGI, and IBM all use IEEE and control-word=bytes means that I can read the same FORTRAN unformatted sequential access files transparently on any of those machines. Since they use different RECL conventions however, the *source* requires proprocessing to be portable. How about that --- binary portability but *not* source portability! A simple C program can convert the Stardent files to the more common format, but it would be much nicer if we could convince Stardent to change a few lines of code in their FORTRAN I/O libraries to provide this compatibility. (Any Stardent users out there?) -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@vax1.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET