Re: reading more data than the record size (RECL)

On 2008-04-15 18:57:39 -0300, ssheriff <ssheriff3@xxxxxxxxx> said:

On Apr 14, 11:43 am, glen herrmannsfeldt <g...@xxxxxxxxxxxxxxxx>
wrote:
I believe your problem is that you arereadingwith read statements
that don't match the write statement that wrote the appropriaterecord.
This works withg95:
snip
...
end snip

Glenn,

Thanks (again). If you could give me one more tip I'd really
appreciate it.

Your code writes and reads like it should.

My old compiles also write and read correctly with the subroutine I
posted.

But I can't read the files written by the old code with the new g95
compile. Thus I guess you and Richard are correct in that I'd probably
have to recompile all the programs that read write with that
subroutine.

Yet, I know the structure of the files that are wrtten and read:

Here is the header information:
Basic header record (23 4-byte words):

id: 56 ASCII characters of identification (character*56).
pgm: 8 ASCII characters identifying creating program (not all programs
add this information); character*8.
ncol: number of columns (integer*4).
nrow: number of rows (integer*4).
nz: number of words per data element. Normally nz = 1 (integer*4).
x0: position of first column of data, for example, in kilometers or
degrees of longitude (real*4).
dx: delta x, spacing interval of columns, normally in the same units
as x0 (real*4).
y0: position of first row of data (real*4).
dy: delta y, spacing interval of rows, normally in the same units as
y0 (real*4).

Is there some way I can just read the first variable (id) in an
existing file with a new (g95) fortran code without it reading past
the record length and giving me an error? If so, it seems I ought to
be able to rewrite the read form this one program and get what I need
to finish done.

Steve

It appars that you did not understand what you were being told.

The structure that may have (evidently did) change is hidden from you and
only seen the the runtime support. It is the record length (and whatever
else might be there) at the beginning of the record. It is typically repeated
at the end. To see this stuff you would have to do a system level (hex)
dump of the the physical files. This overhead is there to allow Fortran
to support backspacing, partial reads and other RECORD oriented features.
This is also why the "same" records are not compatable with C programs
which do not use a record oriented runtime which adds the required
overhead. C uses a stream notion for I/O. You need F03 or vendor specific
nonportable extensions to play such games from Fortran.

The issue is that the overhead can (and does) change between vendors and
upon occasion versions. Lately there has been a problem with whether the
lengths are to take 4 bytes or 8 bytes. Some systems tried using 8 bytes
on the newer versions but too many compatability complaints lead to switching
back to 4 bytes within a moderately common (but not universal) form. The
betting is you got caught up in this. Some offer compiler switches to
choose exactly which version is in use. So RTFM carefully! All this assume
that your claim of no other changes is actually correct. Too often the claim
is of no important changes but the changes turn out to have been important.







.

Relevant Pages

  • Re: In the Shallow End
    ... You've never used fortran so obviously, again, you don't know what you are ... it wasn't extensions but the 2003 FORTRAN ... standard you were talking about. ...
    (comp.sys.mac.advocacy)
  • Re: In the Shallow End
    ... Not a problem on Fortran. ... I'm vindicated about how crappy M$ products and languages really are. ... Doesn't matter if they are not standard in other languages, ...
    (comp.sys.mac.advocacy)
  • Re: Lighten WinXP ?
    ... dealing with making XP run with the least overhead.", ... Such as a programs written for XP that allows you to install for current ... It sounds more like you want to disable unneeded services. ...
    (microsoft.public.windowsxp.general)
  • Re: In the Shallow End
    ... The best stuff was written on VMS for JSTARS and also the Starwars ... Are Windows backups hard? ... you aren't techically aware of what Fortran is. ...
    (comp.sys.mac.advocacy)
  • Re: OT: FORTRAN
    ... (snip about ENCODE AND DECODE perhaps?) ... did not include internal I/O, mixed-mode arithmetic, any way to detect end-of-file in a read, multiple integer precisions, etc. ... Many compilers had extensions for these, but they were not standard FORTRAN -- nor were the extensions consistent across the various vendors. ...
    (comp.lang.pl1)