Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!mcnc!ecsgate!ecsvax!dukeac!wolves!ggw From: ggw@wolves.uucp (Gregory G. Woodbury) Newsgroups: comp.lang.fortran Subject: Re: Fortran OPEN and WRITE Summary: Fortran records and byte counts Message-ID: <1990Apr8.172433.7769@wolves.uucp> Date: 8 Apr 90 17:24:33 GMT References: <962@nisca.ircc.ohio-state.edu> Reply-To: ggw@wolves.UUCP (Gregory G. Woodbury) Followup-To: comp.lang.fortran Distribution: na Organization: Wolves Den UNIX BBS Lines: 96 In article <962@nisca.ircc.ohio-state.edu> (Joe Liu) writes: > I have been troubled by maybe a very simple problem, what I >want to do is: to write a collection of data into a binary file, : > However, it seems >Fortran on the Unix takes 1+8 bytes to write each one byte data, thus >the following will result in a 45 bytes file. > > OPEN (7, FILE='test.dat', FORM='UNFORMATTED') > DO 10 I=1,5 > 10 WRITE (7) I > CLOSE (7) This code generates 5 different records. Each record contains a byte count at the front and back to allow the BACKSPACE statement to work on the file. > if I have a 5 bytes array and write the array as one record, I will >get a 5+8= 13 bytes file on the Unix machine. > > BYTE N(5) > DO 10 I=1,5 > 10 N(I)=I > OPEN (7,FILE='test.dat, FORM='UNFORMATTED') > WRITE (7) N > CLOSE (7) This code generated one record. A WRITE statement will generate (at least) one record for each call. A formatted write can generate multiple records by using the "/" format descriptor. >Although Fortran has no problem to get the right data back when I read >them out, The file is not what I must have, ie, only 1,2,3,4,5 in it. > > On the VAX machine, the bahavior is similar, only difference is that >it has a 4 bytes extra for each record writen instead of 8. If I compile >the above two on the VAX I will get a 25 bytes and a 9 bytes file respectively >instead the 45 bytes and 13 bytes. On the VAX the record counts are limited to a smaller size and only encode the count in a two-octet field. > I did try to play with possible options in the OPEN statements >but did not achieve what I wanted. As I said the FORTRAN itself has >no problem to read back the right data. What's behind this ? Some >one told me this will not happen on an IBM machine but I did not get >the chance to try it on IBM yet. IBM has been known to ignore documented standard behaviour before.. ;-) Actually, in the IBM world, the UNFORMATTED form file is still subject to the mainframe environments storage formats, which require you to tell the OS the size of the record. If you DD the file with a variable record length, the OS i/o services hide the byte counts from the program. It only looks like there are no record counts in the file. To turn the history back into its correct order... The bahaviour of FORTRAN UNFORMATTED WRITE under Unix and VAX/VMS is a deliberate simulation of the variable record formats used in the older mainframe FORTRAN environments. > The same purpose can be very easily >achieved in C. That's what I am doing now, use a C program to pick out >the right bytes from a FORTRAN output and write it into the byte by byte >form, to input this into anthoer graphics application. It will >be nice if I can slightly modify the FORTRAN program to have the compatible >output for the application. Assuming that there is no way to modify the graphics application, this is one of several potential solutions. You probably do not want to modify the fortran compiler or i/o library to change the unformatted i/o format. Other potential solutions: 1. Write a C subprogram to open the file, do the i/o and close the file. The interface between C and FORTRAN is well documented in several places (or should be ;-). This is the solution I have used several times. 2. I have heard that there is a way of telling some Unix FORTRANs to open a file as DIRECT access with a record length of ONE (1) and this allows you to perform certain simulations of simple stream i/o. I haven't tried this, but it was mentioned in an AT&T F77 Reference Manual (with some other caveats that I don't remember.) Since the AT&T and BSD stock F77's are still pretty much the same beast, I suspect that this trick, once perfected, should be pretty portable. > There must be a lot FORTRAN experts on this group. Please enlighten >me. I have sought help from as close as my next door to as far as DEC >technical assitance. But I still do not know how. Just play around, I think there should be some useful information in the above ramblings. > Thanks. >Joe Your welcome. -- Gregory G. Woodbury Sysop/owner Wolves Den UNIX BBS, Durham NC UUCP: ...dukcds!wolves!ggw ...dukeac!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw@ac.duke.edu ggw%wolves@ac.duke.edu Phone: +1 919 493 1998 (Home) +1 919 684 6126 (Work) [The line eater is a boojum snark! ]