Record Length on Sequential WRITE

[Wiland__Bruce]

I need to be able to write a record to a sequential file that is longer than 1024 characters. I was under the impression that one could increase the record length using RECL= in the OPEN statement. However, the line keeps wrapping at 1024 characters. The following is some sample code. When I run it and open the file in notepad, the line appears as two lines with 1024 characters on one line and 6 on the next.

character*1030 line
do i=1,1030
line(i:i)='x'
enddo
open(1,file='test.txt',access='SEQUENTIAL',recl=1100)
write(1,10) line
10 format(a)
end

Is it possible to write lines to a file that are longer than 1024 characters and not have them wrap?

[mecej4]

Notepad is probably deceiving you. Take the output file and view it in a different text editor with word-wrap disabled.

Alternatively, dump the output file with a suitable utility. You will find that it has 1030+2 bytes (the +2 is for the CR+LF at the end).

[John_Campbell]

As mecej4 states, the problem is with Notepad. Similar problems are common importing and exporting text from Excel.
You could write a program to open the file you have created and read into a character buffer, of say:

[fortran]
character*5000 string
open (unit=11, file='test.txt')
read (11, fmt='(a)') string
write (*,*) len_trim (string)
end
[/fortran]

I would also not use unit 1 for opening files, a number > 10 is safer for most fortran compilers.
I also would not use access='SEQUENTIAL'  or  recl=1100. Use the defaults for a text file.

This problem highlights that long strings in files are not easy to handle. Waste a few CR LF's and shorten the strings you save.

John

[IanH]

John Campbell wrote:
...
I also would not use access='SEQUENTIAL'  or  recl=1100. Use the defaults for a text file.

SEQUENTIAL is the default, so whether to include or exclude is just a matter of personal preference (some might like to include it as an in-source reminder of what the default is).

Formally, without the RECL specifier the maximum length is processor dependent.  There's then a requirement on the programmer that they don't create a record longer than that maximum length.  If you violate that requirement, then technically anything goes - there might be no implications (which I think is practically the case for all typical Fortran implementations), or (perhaps less practically) the processor may turn into a large carnivourous beast and consume the programmer. 

The processor dependent RECL in the absence of the RECL specifier in OPEN for ifort is only 132, so if the OP wants to avoid the infinitessimally small chance that they end up as lunch, then they should leave that RECL in there.  Besides which, it also performs a small in-source documentation role.

[John_Campbell]

Ian,

I am not sure what is the impact of including "RECL=1100" is for a sequential access text file. Sequential access text files are a variable length format. If you make them fixed length, would this imply that each record (line) is padded with blanks ?  Or would ifort just ignore the request?

The definition I have for using RECL in an OPEN statement is:
recl is a scalar default INTEGER expression. It must evaluate to the record length in bytes for a file connected for direct access, or the maximum record length in bytes for a file connected for sequential access.

I am not aware of how RECL= would be implemented for a sequential file ! Would it truncate longer records or pad shorter records, both of which I would expect is a bad outcome.

Hence my recomendation to omit both SEQUENTIAL and RECL.

John

[IanH]

I suspect all that most compilers (that you are likely to encounter today) do for formatted sequential files is save the RECL provided with OPEN in a data structure in memory associated with the logical unit, so that if you ask what the RECL is using INQUIRE they can give that number back.  This means there is no practical reason for most compilers (that you are likely to encounter today) that a correct maximum RECL has to be provided - but there's a distinction between consequences of current implementation and what is formally required.

Do I put RECL in my formatted sequential file open statements?  No.  If someone had worked out what the maximum was previously an whacked it in the OPEN statement, would I remove the specifier during maintenance?  No.

Sensible uses of the maximum RECL with the common implementation of formatted sequential files might be to guide list directed output (I think I read about this on this forum recently), or - for a debugging compiler - to check that actual record lengths don't exceed that maximum.  In some other hypothetical implementation (say a formatted sequential file format that looked more like what you get with unformatted sequential files with ifort) the maximum RECL could be used to select the number of bytes or whatever that you needed to store the record length.

(Why is the default RECL for ifort for formatted sequential files 132?)

[mecej4]

IanH wrote:
(Why is the default RECL for ifort for formatted sequential files 132?)

Assuming that the question was not just rhetorical, the answer is: To match the standard line-printer record length.

Along with 1, 6, 73 and 80, 132 is one of Fortran's sacred numbers.