Is there a way to change the RECL= parameter of a unit in a
	middle of a Fortran77 program?

	The PPGF77 [1], AIUI, says that the following /may/ work:

      OPEN (N, RECL = NEWRECL)

	However, it seems that GNU Fortran doesn't allow it:

$ mycode 
…
At line XXX of file SRC (unit = N, file = 'FILE')
Fortran runtime error: Cannot change RECL parameter in OPEN statement
$ 

	The problem is that I have to analyze the version of the data
	file, as stored in its header, and to choose among one of a
	couple possible record lengths to read the rest of the file.

	I'd close the file and reopen the same filename as the last
	resort, but still hope to avoid going this way.

	TIA.

[1] http://www.star.le.ac.uk/~cgp/prof77.html#tth_sEc10.13

-- 
FSF associate member #7257

In article <86boydzp02.fsf@gray.siamics.net>,
 Ivan Shmakov <ivan@gray.siamics.net> wrote:

> Is there a way to change the RECL= parameter of a unit in a
> 	middle of a Fortran77 program?

Is the file opened for formatted or unformatted, direct or 
sequential access?  It would be an extension to f77 in any case. If 
it is unformatted sequential, then you need to read the specific 
fortran manual to know how the recl affects the individual 
sequential records.  It might, for example, correspond to a maximum 
record length which determines the format of the invisible header 
and trailer information associated with each record.  Or, to give 
another example, I once used a compiler that allowed fixed-length 
records with no header info to be written with sequential I/O.

If it is formatted sequential, then you probably do not need to do 
anything with an open statement, you simply start reading records 
with the new size.

All the other combinations are probably possible too, so you need to 
be more specific about what you are doing.

$.02 -Ron Shepard

In article <867h91ziqf.fsf@gray.siamics.net>,
Ivan Shmakov  <oneingray@gmail.com> wrote:
>
>	PPGF77 reads:
>    RECL=integer-expression specifies the record length.  This must be
>    given for a direct-access file but not otherwise.  […]
>
>	Therefore, I've assumed that RECL= isn't possible or meaningful
>	for sequential files.

It ain't what we don't know that causes the trouble; it's what we
know for sure that ain't so.

That ain't so.

Under Unix-derived and Unix-like systems, it is relevant primarily
(but NOT entirely) for unformatted ones, as Ron (or Glen?) said,
but has some function for formatted ones.  Under other systems,
it can be critical.


Regards,
Nick Maclaren.

>>>>> Ron Shepard <ron-shepard@NOSPAM.comcast.net> writes:
>>>>> In article <86boydzp02.fsf@gray.siamics.net>, Ivan Shmakov wrote:

 >> Is there a way to change the RECL= parameter of a unit in a
 >> middle of a Fortran77 program?

 > Is the file opened for formatted or unformatted, direct or 
 > sequential access?

	PPGF77 reads:

--cut: http://www.star.le.ac.uk/~cgp/prof77.html#tth_sEc10.13 --
    RECL=integer-expression specifies the record length.  This must be
    given for a direct-access file but not otherwise.  […]
--cut: http://www.star.le.ac.uk/~cgp/prof77.html#tth_sEc10.13 --

	Therefore, I've assumed that RECL= isn't possible or meaningful
	for sequential files.

 > It would be an extension to f77 in any case.

	ACK.  Thanks.

[…]

 > All the other combinations are probably possible too, so you need to
 > be more specific about what you are doing.

	Specifically, I read an unformatted, direct-access file.

	For now, I've worked-around the problem by re-opening the file
	immediately after reading the header.  (It took me a couple of
	hours to split the header reading code into a separate routine,
	to be called after the file is opened for the first time, and
	debug all the required changes.)

-- 
FSF associate member #7257

Ivan Shmakov <ivan@gray.siamics.net> wrote:

> >>>>> Ron Shepard <ron-shepard@NOSPAM.comcast.net> writes:
> >>>>> In article <86boydzp02.fsf@gray.siamics.net>, Ivan Shmakov wrote:
> 
>  >> Is there a way to change the RECL= parameter of a unit in a
>  >> middle of a Fortran77 program?

>       Therefore, I've assumed that RECL= isn't possible or meaningful
>       for sequential files.

That's so for standard f77. For f90, it indicates the max record length
for a sequential file; this has little effect in most implementations.

>  > It would be an extension to f77 in any case.

And to f90+. RECL is not one of the things you can change while a file
is open.

>       Specifically, I read an unformatted, direct-access file.
> 
>       For now, I've worked-around the problem by re-opening the file
>       immediately after reading the header.  (It took me a couple of
>       hours to split the header reading code into a separate routine,
>       to be called after the file is opened for the first time, and
>       debug all the required changes.)

That's about what you are stuck with in f77. There is one alternative,
but it is usually messier. You can read the file in "blocks" of whatever
size you choose. Then do your own record management. This is certainly
possible (I've done it), but gets messy and has more caveats than are
handy to describe here. Dealing with the possibility of a partial block
at the end is one of them.

I'd guess that unformatted stream access might be most suitable to the
task. That does not involve a concept of record size. If your file is
direct acess unformatted, you don't really need such a concept anyway;
you can just read the right amount of data from the right place in the
file, which stream can do. Stream is *MUCH* easier than doing your own
record management using fixed-size blocks.

Stream is an f2003 feature, but one fairly widely implemented in earlier
compilers. Even f77 compilers often had something comparable as an
extension, with minor variations in spelling.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

>>>>> Richard Maine <nospam@see.signature> writes:
>>>>> Ivan Shmakov <ivan@gray.siamics.net> wrote:

[…]

 >> For now, I've worked-around the problem by re-opening the file
 >> immediately after reading the header.  (It took me a couple of hours
 >> to split the header reading code into a separate routine, to be
 >> called after the file is opened for the first time, and debug all
 >> the required changes.)

 > That's about what you are stuck with in f77.  There is one
 > alternative, but it is usually messier.  You can read the file in
 > "blocks" of whatever size you choose.  Then do your own record
 > management.  This is certainly possible (I've done it), but gets
 > messy and has more caveats than are handy to describe here.  Dealing
 > with the possibility of a partial block at the end is one of them.

	ACK, thanks.  The problem is that the code is being developed
	“by a third party”, and my intent was to enhance it a bit and
	then be able to provide the resulting patch to both the original
	developers and the users' community.  Thus, I've hoped for a
	smaller diff.  Which isn't apparently possible.

 > I'd guess that unformatted stream access might be most suitable to
 > the task.  That does not involve a concept of record size.  If your
 > file is direct acess unformatted, you don't really need such a
 > concept anyway; you can just read the right amount of data from the
 > right place in the file, which stream can do.  Stream is *MUCH*
 > easier than doing your own record management using fixed-size blocks.

 > Stream is an f2003 feature, but one fairly widely implemented in
 > earlier compilers.  Even f77 compilers often had something comparable
 > as an extension, with minor variations in spelling.

	To be honest, I don't know what compiler or compilers will
	choose the parties interested in the patch.  There, I can use
	GNU Fortran, but I'm not sure that the original developers, or
	the community, will take time to check whether it will work for
	them.

	But, actually, the code that reads the payload section of the
	file looks rather simple.  Perhaps, the solution would be to
	switch to unformatted sequential access.  However, I'm not that
	familiar with Fortran to say whether it will work in advance.

-- 
FSF associate member #7257

Ivan Shmakov <ivan@gray.siamics.net> wrote:

>       ACK, thanks.  The problem is that the code is being developed
>       "by a third party",

If the code is currently "being developed", then I would strongly argue
against using f77. F90 has been out for 2 decades now. You can't even
find supported f77-only compilers any more. That's almost a tautology in
that the vendors that were actively supporting their compilers long ago
updated them to f90/f95. You mention "GNU Fortran". I'm not actually
sure what you mean by that; it could quite plausibly be any of at least
3 different compilers. I'm guessing you are referring to g77, which is
no longer supported.

Though you say the code is being developed "by a third party" (I'm not
quite sure what the quotes you used there signify; I'd normally read
that as implying that it wasn't literally the case). That would make it
seem likely that you don't have much say in the matter.

But I must say that I'd question the judgement of anyone developing new
applications in f77 today.

>       But, actually, the code that reads the payload section of the
>       file looks rather simple.  Perhaps, the solution would be to
>       switch to unformatted sequential access.  However, I'm not that
>       familiar with Fortran to say whether it will work in advance.

I don't know enough about the use in your application to know whether
unformatted sequential can apply or not. Be aware that unformatted
sequential comes with extra portability questions in terms of using the
same file on multiple compilers. It was never designed for such
portability. You can often do so, depending on the particular compilers,
but it does add extra issues.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

In article <ise4g2$k3f$1@dont-email.me>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>
>For IBM system using fixed length records for sequential files,
>the record length (LRECL) goes in the DCB field for JCL, or
>FILEDEF for CMS.  It might not be good to override it in OPEN.

That applied primarily to the first release of VS Fortran.
Later ones had dynamic allocation, and many (most?) other
Fortran 77 systems had that from the beginning.

>A fixed length record file should not change the record length
>in the middle.  I can imagine it in theory, but it isn't the usual
>meaning of fixed length.

It could be done under MVT/MVS, but I agree that it needed
some arcane hacking :-)


Regards,
Nick Maclaren.

nmm1@cam.ac.uk wrote:
> In article <867h91ziqf.fsf@gray.siamics.net>,
> Ivan Shmakov  <oneingray@gmail.com> wrote:

(snip)
>>       Therefore, I've assumed that RECL= isn't possible or meaningful
>>       for sequential files.
 
> It ain't what we don't know that causes the trouble; it's what we
> know for sure that ain't so.
 
> That ain't so.
 
> Under Unix-derived and Unix-like systems, it is relevant primarily
> (but NOT entirely) for unformatted ones, as Ron (or Glen?) said,
> but has some function for formatted ones.  Under other systems,
> it can be critical.

This is my first reply in the thread...

It is needed for formatted direct on most systems, but not so
many people use that.

For systems with variable length records (for sequential files),
any RECL should be a maximum.  It is sometimes needed to set
buffer sizes, which is as applicable for F77 as any other year.

For IBM system using fixed length records for sequential files,
the record length (LRECL) goes in the DCB field for JCL, or
FILEDEF for CMS.  It might not be good to override it in OPEN.

I might imagine a system where the required buffer size was 
specified in the beginning of the file.  You could read that,
close, then reopen with the specified size.

A fixed length record file should not change the record length
in the middle.  I can imagine it in theory, but it isn't the usual
meaning of fixed length.

-- glen

>>>>> Richard Maine <nospam@see.signature> writes:
>>>>> Ivan Shmakov <ivan@gray.siamics.net> wrote:

 >> ACK, thanks.  The problem is that the code is being developed
 >> "by a third party",

 > If the code is currently "being developed", then I would strongly
 > argue against using f77.

	Well, indeed, I should've said “being maintained” instead.  The
	most of the development work on this code was made, IIUC, in
	early 2000's (and, for some parts, all over the 1990's.)

 > F90 has been out for 2 decades now.  You can't even find supported
 > f77-only compilers any more.  That's almost a tautology in that the
 > vendors that were actively supporting their compilers long ago
 > updated them to f90/f95.  You mention "GNU Fortran".  I'm not
 > actually sure what you mean by that; it could quite plausibly be any
 > of at least 3 different compilers.  I'm guessing you are referring to
 > g77, which is no longer supported.

	I'm referring to the version of the Fortran language's compiler,
	which is shipped with current GCC.  The first result for the
	Google search for "GNU Fortran" is:

http://gcc.gnu.org/fortran/

	Which is all about gfortran(1), not g77(1).

 > Though you say the code is being developed "by a third party" (I'm
 > not quite sure what the quotes you used there signify; I'd normally
 > read that as implying that it wasn't literally the case).

	The code in question, AIUI, has passed over many hands, and the
	quotes there were intended to say that I don't know for sure,
	what party or parties are responsible for its maintenance right
	now.

 > That would make it seem likely that you don't have much say in the
 > matter.

	Yes, indeed.

 > But I must say that I'd question the judgement of anyone developing
 > new applications in f77 today.

	Neither will I advocate the use of Fortran77 now.

	That being said, I do have little expertise in Fortran and its
	versions.  OTOH, having written code in 20 (or so) programming
	languages over something like 20 years since I've been first
	introduced into computer programming, I have some doubts
	regardging whether I should invest much time in learning several
	dialects of one another language.  From this point of view,
	Fortran77 has much less features to learn, and PPGF77 was an
	easy reading for me.

 >> But, actually, the code that reads the payload section of the file
 >> looks rather simple.  Perhaps, the solution would be to switch to
 >> unformatted sequential access.  However, I'm not that familiar with
 >> Fortran to say whether it will work in advance.

 > I don't know enough about the use in your application to know whether
 > unformatted sequential can apply or not.  Be aware that unformatted
 > sequential comes with extra portability questions in terms of using
 > the same file on multiple compilers.  It was never designed for such
 > portability.  You can often do so, depending on the particular
 > compilers, but it does add extra issues.

	Do I understand it correctly that unformatted sequential
	introduces some compiler-specific control sequences that are
	automatically added to the output and then some expected to be
	found in input?  If that's the case, then it isn't suitable for
	the task in question, indeed.

-- 
FSF associate member #7257

nmm1@cam.ac.uk wrote:

(snip, I wrote)
>>A fixed length record file should not change the record length
>>in the middle.  I can imagine it in theory, but it isn't the usual
>>meaning of fixed length.
 
> It could be done under MVT/MVS, but I agree that it needed
> some arcane hacking :-)

I was thinking about this, that it could be done, that it would
have to be unblocked, (or the blocking was also part of the
file itself), but then it should be RECFM=U.  

-- glen

Ivan Shmakov <ivan@gray.siamics.net> wrote:

>       Do I understand it correctly that unformatted sequential
>       introduces some compiler-specific control sequences that are
>       automatically added to the output and then some expected to be
>       found in input?  If that's the case, then it isn't suitable for
>       the task in question, indeed.

Yes. Exactly. Many of today's compilers use simillar control sequences -
enough so that the chances of portability between compilers are
reasonably good, but "reasonably good" isn't certain. For example, some
compilers use 32-bit headers and trailers, while others use 64-bit ones.

And if you want to be able to read or write in some pre-defined format
independent of a particular compiler, possibly even independent of
Fortran, the unformatted sequential is just flat out of consideration
because all the compilers add something. They essentally have to do so
in order to work like the standard requires. Non-Fortran-based formats
is an area where stream fits very well. In fact, such interoperability
with other languages (notably C, but others as well) was the stated
reason for adding stream.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

In article <isesgi$ie0$1@dont-email.me>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>>
>>>A fixed length record file should not change the record length
>>>in the middle.  I can imagine it in theory, but it isn't the usual
>>>meaning of fixed length.
> 
>> It could be done under MVT/MVS, but I agree that it needed
>> some arcane hacking :-)
>
>I was thinking about this, that it could be done, that it would
>have to be unblocked, (or the blocking was also part of the
>file itself), but then it should be RECFM=U.  

You could also change the RECL at a concatenation by taking
an appropriate exit, though I now forget the details.


Regards,
Nick Maclaren.

Richard Maine <nospam@see.signature> wrote:
> Ivan Shmakov <ivan@gray.siamics.net> wrote:
 
>>       Do I understand it correctly that unformatted sequential
>>       introduces some compiler-specific control sequences that are
>>       automatically added to the output and then some expected to be
>>       found in input?  If that's the case, then it isn't suitable for
>>       the task in question, indeed.
 
> Yes. Exactly. Many of today's compilers use simillar control sequences -
> enough so that the chances of portability between compilers are
> reasonably good, but "reasonably good" isn't certain. For example, some
> compilers use 32-bit headers and trailers, while others use 64-bit ones.

Not to mention that different systems have different data formats.
Endianness, size (bytes), and even more for floating point.
 
> And if you want to be able to read or write in some pre-defined format
> independent of a particular compiler, possibly even independent of
> Fortran, the unformatted sequential is just flat out of consideration
> because all the compilers add something. They essentally have to do so
> in order to work like the standard requires. Non-Fortran-based formats
> is an area where stream fits very well. In fact, such interoperability
> with other languages (notably C, but others as well) was the stated
> reason for adding stream.

Well, if you know the header length it isn't hard to read past it
in C, or even read and use them.  

-- glen

In article <isfa5m$l2a$1@gosset.csi.cam.ac.uk>,  <nmm1@cam.ac.uk> wrote:
>In article <isesgi$ie0$1@dont-email.me>,
>glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>>>
>>>>A fixed length record file should not change the record length
>>>>in the middle.  I can imagine it in theory, but it isn't the usual
>>>>meaning of fixed length.
>> 
>>> It could be done under MVT/MVS, but I agree that it needed
>>> some arcane hacking :-)
>>
>>I was thinking about this, that it could be done, that it would
>>have to be unblocked, (or the blocking was also part of the
>>file itself), but then it should be RECFM=U.  
>
>You could also change the RECL at a concatenation by taking
>an appropriate exit, though I now forget the details.

Ridiculous!  We used it all the time.  The simple unlike concatenation
exit; nothing arcane at all!  But, of course, in THAT case it was
the file changing the LRECL, and not the program doing so.


Regards,
Nick Maclaren.

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:isfaqv$c3p$1@dont-email.me...
| Richard Maine <nospam@see.signature> wrote:
| > Ivan Shmakov <ivan@gray.siamics.net> wrote:
|
| >>       Do I understand it correctly that unformatted sequential
| >>       introduces some compiler-specific control sequences that are
| >>       automatically added to the output and then some expected to be
| >>       found in input?  If that's the case, then it isn't suitable for
| >>       the task in question, indeed.
|
| > Yes. Exactly. Many of today's compilers use simillar control sequences -
| > enough so that the chances of portability between compilers are
| > reasonably good, but "reasonably good" isn't certain. For example, some
| > compilers use 32-bit headers and trailers, while others use 64-bit ones.
|
| Not to mention that different systems have different data formats.
| Endianness, size (bytes), and even more for floating point.
|
| > And if you want to be able to read or write in some pre-defined format
| > independent of a particular compiler, possibly even independent of
| > Fortran, the unformatted sequential is just flat out of consideration
| > because all the compilers add something. They essentally have to do so
| > in order to work like the standard requires. Non-Fortran-based formats
| > is an area where stream fits very well. In fact, such interoperability
| > with other languages (notably C, but others as well) was the stated
| > reason for adding stream.
|
| Well, if you know the header length it isn't hard to read past it
| in C, or even read and use them.

Why would you do that, when you can do it in Fortran? 

nmm1@cam.ac.uk wrote:

(snip)
>>>> It could be done under MVT/MVS, but I agree that it needed
>>>> some arcane hacking :-)

>>>I was thinking about this, that it could be done, that it would
>>>have to be unblocked, (or the blocking was also part of the
>>>file itself), but then it should be RECFM=U.  

>>You could also change the RECL at a concatenation by taking
>>an appropriate exit, though I now forget the details.
 
> Ridiculous!  We used it all the time.  The simple unlike concatenation
> exit; nothing arcane at all!  But, of course, in THAT case it was
> the file changing the LRECL, and not the program doing so.

There is also that FB data sets are supposed to have all blocks
the same size, except the last one.  (Then they are FBS).
If you append (DISP=MOD), then that might not be true.

It seems, then, that if you change LRECL you can append with
different LRECL and/or BLKSIZE.  You shouldn't, but you could.

At least once I wrote to a PDS with different DCB parameters
from previous members.  To fix it, you have to write with the
correct DCB to get it back again.  (and delete the wrong member).

But I believe that the right way is to make it U.  With U, 
you are supposed to be able to write the blocks (and records)
any size you want.  The system won't help you when reading, though.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Maine <nospam@see.signature> wrote:
> > Ivan Shmakov <ivan@gray.siamics.net> wrote:
>  
> >>       Do I understand it correctly that unformatted sequential
> >>       introduces some compiler-specific control sequences that are
> >>       automatically added to the output and then some expected to be
> >>       found in input?  If that's the case, then it isn't suitable for
> >>       the task in question, indeed.
>  
> > Yes. Exactly. Many of today's compilers use simillar control sequences -
> > enough so that the chances of portability between compilers are
> > reasonably good, but "reasonably good" isn't certain. For example, some
> > compilers use 32-bit headers and trailers, while others use 64-bit ones.
> 
> Not to mention that different systems have different data formats.
> Endianness, size (bytes), and even more for floating point.

Yes. I debated mentioning those, but they are inherent in any
unformatted I/O (unless one has a machine-independent definition of the
data format to use and converts between it and the native format, but
that would then be almost like formatted I/O in that there is a format
conversion, even if not to a character form). The other issues of
sequential unformatted are on top of those.
 
> > And if you want to be able to read or write in some pre-defined format
> > independent of a particular compiler, possibly even independent of
> > Fortran, the unformatted sequential is just flat out of consideration
> > because all the compilers add something. They essentally have to do so
> > in order to work like the standard requires. Non-Fortran-based formats
> > is an area where stream fits very well. In fact, such interoperability
> > with other languages (notably C, but others as well) was the stated
> > reason for adding stream.
> 
> Well, if you know the header length it isn't hard to read past it
> in C, or even read and use them.  

Which is why I was talking about a "pre-defined format" or one that is
"independent of a particular compiler, possibly even independent of
Fortran". You are talking about a different scenario, where you write a
file in whatever form your particular compiler uses and then you expect
the C user to be able to deal with that. Yes, it can be done. But that
is not at all the same thing as writing in a predefined format. If you
are writing in a format that is previously defined, and possibly already
has lots of other programs that use it, you don't have the choice of
saying that you'll redefine it to be whatever your particular compiler
happens to do.

Having to write in such pre-defined formats is a very common problem.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

>>>>> Richard Maine <nospam@see.signature> writes:
>>>>> Ivan Shmakov <ivan@gray.siamics.net> wrote:

 >> Do I understand it correctly that unformatted sequential introduces
 >> some compiler-specific control sequences that are automatically
 >> added to the output and then some expected to be found in input?  If
 >> that's the case, then it isn't suitable for the task in question,
 >> indeed.

 > Yes. Exactly. Many of today's compilers use simillar control
 > sequences - enough so that the chances of portability between
 > compilers are reasonably good, but "reasonably good" isn't
 > certain. For example, some compilers use 32-bit headers and trailers,
 > while others use 64-bit ones.

[…]

        ACK, thanks.

-- 
FSF associate member #7257

glen herrmannsfeldt <gah@ugcs.caltech.edu> schrieb:
> Richard Maine <nospam@see.signature> wrote:
>> Ivan Shmakov <ivan@gray.siamics.net> wrote:
>  
>>>       Do I understand it correctly that unformatted sequential
>>>       introduces some compiler-specific control sequences that are
>>>       automatically added to the output and then some expected to be
>>>       found in input?  If that's the case, then it isn't suitable for
>>>       the task in question, indeed.
>  
>> Yes. Exactly. Many of today's compilers use simillar control sequences -
>> enough so that the chances of portability between compilers are
>> reasonably good, but "reasonably good" isn't certain. For example, some
>> compilers use 32-bit headers and trailers, while others use 64-bit ones.
>
> Not to mention that different systems have different data formats.
> Endianness, size (bytes), and even more for floating point.

These days there is a fair chance of being able to read unformatted
sequential data from another compiler.

- Many compilers use 32-bit record markers, which shold be safe for
  record lengths < 2**31 bytes, but methods for reading and writing
  bigger records differ a lot more.  At least ifort and gfortran
  share a method.

- Endianness issues can often be addressed, for example specifying
  -fconvert=big-endian for gfortran or specifying CONVERT="big_endian"
  in the OPEN statement for ifort and gfortran.

- Floating point these days is usually IEEE. 

- Some (but not all) compilers also support 64-bit record markers with
  a compiler switch (gfortran and XLF come to mind).

No guarantees, but things can often be made to work.

In article <isgsra$qh9$1@newsreader5.netcologne.de>,
Thomas Koenig  <tkoenig@netcologne.de> wrote:
>
>These days there is a fair chance of being able to read unformatted
>sequential data from another compiler.

A fair chance.

>- Many compilers use 32-bit record markers, which shold be safe for
>  record lengths < 2**31 bytes, but methods for reading and writing
>  bigger records differ a lot more.  At least ifort and gfortran
>  share a method.

And many use other methods.  It's easy enough to write a converter,
but only if you are an experienced low-level programmer.

>- Endianness issues can often be addressed, for example specifying
>  -fconvert=big-endian for gfortran or specifying CONVERT="big_endian"
>  in the OPEN statement for ifort and gfortran.

And that is the effectively the only way to do it.

>- Floating point these days is usually IEEE. 

Grrk.  That is serious misleading.  Read data with denormalised
data, NaNs or infinities into a compiler that doesn't generate
them and you are in dead trouble.

It gets much worse when you use any precision beyond 8-byte real
(and 4-byte integer, in different ways) or use derived types.

>No guarantees, but things can often be made to work.

The killer is that it isn't possible to describe a path through the
minefield for an average programmer.  It's easy enough to negotiate
if you have the requisite experience and skills, but too complicated
to describe.

I describe the rules you and I are talking about in one course,
and say "If that doesn't work, get advice (like from me)."

I also tell them how to test for the IEEE gotchas.


Regards,
Nick Maclaren.

nmm1@cam.ac.uk <nmm1@cam.ac.uk> schrieb:
> In article <isgsra$qh9$1@newsreader5.netcologne.de>,
> Thomas Koenig  <tkoenig@netcologne.de> wrote:

>>- Floating point these days is usually IEEE. 

> Grrk.  That is serious misleading.  Read data with denormalised
> data, NaNs or infinities into a compiler that doesn't generate
> them and you are in dead trouble.

Doesn't this apply to formatted as well as unformatted?

Thomas Koenig <tkoenig@netcologne.de> wrote:
> nmm1@cam.ac.uk <nmm1@cam.ac.uk> schrieb:
>> In article <isgsra$qh9$1@newsreader5.netcologne.de>,
>> Thomas Koenig  <tkoenig@netcologne.de> wrote:
 
>>>- Floating point these days is usually IEEE. 
 
>> Grrk.  That is serious misleading.  Read data with denormalised
>> data, NaNs or infinities into a compiler that doesn't generate
>> them and you are in dead trouble.
 
> Doesn't this apply to formatted as well as unformatted?

It might, but at least you can see what it is doing.  

Also, the READ might fail if it doesn't recognize the input.

Unformatted will read the bits, whatever the meaning.

IEEE doesn't standardize the meaning of most of the bits
in a NaN.

-- glen

In article <iskbgn$8n5$1@dont-email.me>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>Thomas Koenig <tkoenig@netcologne.de> wrote:
> 
>>>>- Floating point these days is usually IEEE. 
> 
>>> Grrk.  That is serious misleading.  Read data with denormalised
>>> data, NaNs or infinities into a compiler that doesn't generate
>>> them and you are in dead trouble.
> 
>> Doesn't this apply to formatted as well as unformatted?
>
>It might, but at least you can see what it is doing.  
>
>Also, the READ might fail if it doesn't recognize the input.

Actually, it's required to by the Fortran standard.  So at least
you will get an I/O error and not complete chaos.

>Unformatted will read the bits, whatever the meaning.
>
>IEEE doesn't standardize the meaning of most of the bits
>in a NaN.

That's not usually the problem, as the far more serious ones hit
first!


Regards,
Nick Maclaren.

In article <1k2hgvt.5wjb0r1pcjk2uN%nospam@see.signature>,
Richard Maine <nospam@see.signature> wrote:
>
>> >Also, the READ might fail if it doesn't recognize the input.
>> 
>> Actually, it's required to by the Fortran standard.  So at least
>> you will get an I/O error and not complete chaos.
>
>Some decades ago, I discovered, to what was then my surprise, that this
>isn't so. ...

Absolutely.  Exactly why I suffered from a brain malfunction and
posted that nonsense, I can't imagine.  Possibly I am trying to
juggle too many things at once and dropped the ball.


Regards,
Nick Maclaren.

<nmm1@cam.ac.uk> wrote:

> In article <iskbgn$8n5$1@dont-email.me>,
> glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:

> >Also, the READ might fail if it doesn't recognize the input.
> 
> Actually, it's required to by the Fortran standard.  So at least
> you will get an I/O error and not complete chaos.

Some decades ago, I discovered, to what was then my surprise, that this
isn't so. The Fortran standard does not specify anything at all about
what constitutes an I/O error. It specifies that some things would be
nonstandard, and it specifies what happens when you get an I/O error,
but it does not specify a link between those two things. It is up to the
compiler to define what constitutes an I/O error.

Some nonstandard forms of input could be treated as compiler extensions.
Examples I've seen of that include Q exponents and commas to force early
termination of fixed-width fields.

Somewhat more surprising to me when I discovered it was the way that
some IBM compilers used to handle invalid characters in a field. Instead
of treating that as an error, the compiler would do a "fixup", which
usually involved substituting a zero or a blank for the offending
character. This caused havoc with some code of mine that tried to do
something like (I forget the exact details now, but something at least
along this line) read a field first with an I format to see if it held
an integer, retrying with an F format if the first read failed. The IBM
behavior caused a field like 12.34 to be read as 12034 in the I format,
with no error status being set. I later discovered that this IBM
behavior could be controlled with a suitable option setting (with some
caveats that I'll avoid detouring into here). I also think that the
default subsequently changed to act more like I expected. But the
experience lead me to be aware of the pitfalls of actually depending on
nonstandard input to cause an error condition.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain