Get record lengths from unformatted sequential access file

[PierU]

@RonShepard

I would say that the use of 9-track tapes as an exchange medium began to decline once FTP over the internet became widely available. Since then, there are other network protocols such as curl, scp, svn, and git that are available to share and broadcast data, but I think even these days FTP is still used. But before all that, 9-track tape reels, mailed or carried by hand, were the common denominator, and fortran was sufficient to do almost anything the programmer needed with those tapes.

curl, git, and I guess svn, are higher level softwares, which use transfer protocols such as FTP, HTTP, etc, under the hood.

Tapes (cartridges actually) are still used nowadays to send huge volumes of data.

@RonShepard

Some vendors and users wanted fortran to go in the direction of C, where everything (files, fifo pipes, interprocess communication, etc.) was treated as a sequential stream of bytes, while others wanted to transform fortran i/o into a full-featured database language.

The former eventually made its way into the language with the stream access. And the stream allows reading/writing about any file format.

[msz59]

@PierU

Nonetheless, the capability to inquire the current record length could be added to the language. Just without garantee that the information is available (inquire(unit=lu,recl=length) could possibly possibly return -1).

That would probably require a new specifier, as ‘recl=’ is well defined by the Standard both for direct (actual record length, always user-specified at open) and sequential (maximal possible record length) files. F2023 Draft 12.10.2.27.
As the info about record lengths in sequential files is written in the files themselves, the new specifier should allow to operate on unconnected files (by-file-name inquire) also.

[RonShepard]

@msz59

As the info about record lengths in sequential files is written in the files themselves, the new specifier should allow to operate on unconnected files (by-file-name inquire) also.

The required information is not just associated with the file, but, at least for sequential files, it changes record by record. I would imagine it would be implemented within the read statement, not with the inquire statement, for this reason.

My suggestion above to extend the language to read an arbitrary-length allocatable array could be used for both purposes. If the allocatable array and the optional record_length argument are both present, then the length could be returned and the array could be filled with the data in the same operation. If the array is not present, then just the record_length value would be returned, presumably to allow the programmer to make multiple allocations, or to allocate a multidimension array, or to use that value in other ways prior to the actual data read operation. If only the array is present, then that (presumably 1D) array would be allocated, or reallocated, as appropriate for the record length, and that length could then be determined from the returned array with size().