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

On 2008-04-16 02:08:25 -0300, ssheriff <ssheriff3@xxxxxxxxx> said:

On Apr 15, 4:33 pm, Gordon Sande <g.sa...@xxxxxxxxxxxxxxxx> wrote:
On 2008-04-15 18:57:39 -0300, ssheriff <ssheri...@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 repea
ted
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 switch
ing
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 cla
im
is of no important changes but the changes turn out to have been important
.- Hide quoted text -

- Show quoted text -

Not only do I "not understand what you were being told", I'm probably
not explaining it very well either.

But I do know there are two bytes at the start of the 'unformatted'
files because I can read & write them with a v-basic program I wrote
in 1996:

Open FileOut For Binary As #2
Bytes2 = 23627 ' calculated from USGS header description: 75-BOF,
92 bytes of header
Put #2, , Bytes2 ' Start the USGS grid file
Put #2, , idGS
Put #2, , pgm
Put #2, , ncolGS
... etc.

The compiled .exes read those grids from VB, and they read the grids
written by the Fortran code, just fine. I was just hoping I could re-
compile the original source code with g95, make sure it worked (it
doesn't), and then adapt them for larger arrays. Apparently not.

So you are aware of the issue of the Fortran records having extra
information to describe the records. The Fortran manual should have
a section describing the full details. The Fortran may even have
an extension (nonstandard until you get a Fortran 2003) on how to
operate with byte stream notions, often called "transparent" or
"binary" (like everything else on a binary computer - stupid name!).
You will neeed to become an expert is those details and how to manage
them with options in the open and/or compiler switches. Or you could
write a utility to input one format of record and output another.
Once past those you will have to deal with your actual contents of the
records. Repeatedly telling us about your contents will be of no help
in getting past the system level record organization issues.

Once past this serious hiccup of language/vendor/version compatability
it should then become easy going.

Fortran records have a lot of good features if you stick to one
vendor/version but do have this serious gotcha when you try crossing
too many rivers at once. Think of it as a variant on the ASCII vrs
EBCDIC conversions. Or the issue of CR/LF vrs CR vrs LF that is an
ongoing pain for plain text. When was the last time someone sent you
a WordPerfect file without mentioning it and you tried to read it in
Word? Welcome to the real world of actually using computers for any
extended period of time.



.

Relevant Pages

  • Re: Fortran programmerss favorite report-writing tools
    ... preprocessing to compile so it's easy to add to existing code. ... same input method as when fortran was first invented. ... and the compiler is then translating it into machine code. ... a good candidate for a formulat translator seems to be texmacs. ...
    (comp.lang.fortran)
  • Re: what is wrong with this code?can someone walk me through this?
    ... i dont know anything abt fortran or coding..this is my project at ... You CAN get your program to compile if you ... What are reasonable ranges for the input variables? ...
    (comp.lang.fortran)
  • re: Upgrading an OLD (Fortran Powerstation 4.0) compiler
    ... convert and compile as f90 and fix any errors ... compiler options for windows - most vendors have 30 day demo versions. ... ivf - Intel Visual fortran, ... SUBROUTINE FortranCall ...
    (comp.lang.fortran)
  • Re: Toward a Forth thats easier to learn
    ... Barriers cease to be barriers once you're past them. ... For variables, what emerged as a style in the early days was a compromise: LSE users put in more variables than a Forth purist, but fewer than a Fortran programmer. ... Compile a line and either save it or execute it and throw it ...
    (comp.lang.forth)
  • Re: Function pointer as function parameter
    ... > I've developed an application using both Fortran and C languages. ... in the manuals, is to compile both, or the smallest program that ... a pointer to the function pointer. ...
    (comp.lang.fortran)