Re: first time using direct access files: recl ??

From: Richard Maine (nospam_at_see.signature)
Date: 03/15/04 

Date: 15 Mar 2004 10:51:10 -0800

pcoelho@usp.br (Paula) writes:

> In the code that writes the binary file, it is said that just one
> record is written. The file size given by 'ls -las' is 6092 while the
> RECL is 24100. Is there a inconsistency here?

Sure is. Odd enough that I'd want to see more of the code to make
*SURE* that the file was actually being written with recl=24100...
as in whether that was the value you expected or the one actually
used if some variable was messed up.. and whether the open was of the
same unit, whether some other open later unexpectedly reeopened the
unit, etc, etc... I'm not sure what would cause this, so my questions
are pretty random, but it sure seems odd and likely relevant.

I suppose the compiler *MIGHT* be omitting non-written trailing
stuff from the record. But if it does that, it better be pretty tricky
about being smart when writing or reading subsequent records or it
will badly violate the standard.

Hmm. I'd sure like to see the OPEN statement for the write. It *DOES*
specify direct access, I hope? Otherwise, a lot of previous statements
in this thread don't apply. Hmm...but you probably wouldn't have gotten
as far as you did.

> WRITE(18,REC=IK)
> IKEYtot,(TIT(I),I=1,5),TETAEF,GLOG,ASALOG,NHE,AMG,
> 1 L0,LF,LZERO,LFIN,ITOT,DPAS,ECHX,ECHY,FWHM,(FL(D),D=I1,I2)
>
> here is the output (intentionally, I'm writing just one record, since
> the problem in READ seems to appear already in the first record):

Important things that you did not print out include IK (just because
this is the only write, that doesn't mean IK is necessarily 1 - direct
access I/O doesn't require that), I1, and I2. I see you printed
out fl(i1) and fl(i2), but... hmm... do you understand what the
implied DO loop means? That doesn't mean just fl(i1) and fl(i2);
instead it means all the elements of fl starting with i1 and up
to i2. Without knowing the values of I1 and I2, I can't tell how
many that is (and this how long a record it is trying to write).

...
> nhe= 0.100000001
> amg= 0.
> l0= 4990.
> lf= 5020.
> lzero= 4980.
> lfin= 5100.
> itot= 1501
...

> Then I run the following diagnostic code that I wrote today:

Ah. Excellent. Short complete proggram to study, guaranteeing
that there isn't any important stuff overlooked. Not having the
data file, I can't constructively run it, but I can study it
carefully (and it is sshort enough for that to be pretty easy to
do).

> character*20 tit

Someone else commented about the discrepancy between writing this as 5
reals (using old Hollerith conventions) and reading it as 20
characters. This will work in many cases and probably isn't your
problem at the moment... but it is certainly nonstandard and is
the kind of thing that might cause you problems in the future.

> nhe= 0.100000001
> amg= 0.
> l0= 5020.
> lf= 4980.
> lzero= 5100.
> lfin= 1.3766763E-16
> itot= 1084227584
> dpas= 1.
> echx= 0.119999997
> echy= 0.0124483509
> fwhm= 0.0124728074
> l1= 0.0124887275
> l2= 0.0124952113
>
> I'm puzzled!!! From variable 'l0' on it is a mess!

Ah! This might not be the only problem, but this looks like
a major hint. The "mess" has a pretty clear pattern.

   variable read value looks like what was written as
     L0 LF
     LF LZERO
     LZERO LFIN
     LFIN typical of bits misinterpreted as a real,
                             so possibly the 8 bytes from itot and dpas
                             (I didn't bother to go down to
                             the bit level to check the exact value).
     ITOT typical of bits misinterpreted as an integer,
                             so possibly echx
     DPAS ECHY
     ECHX FWHM
     ECHY FL(I1)
     FWHM can't tell, but plausibly FL(I1+1)
     L1 can't tell, but plausibly FL(I1+2)
     F2 can't tell, but plausibly FL(I1+3)

Looks quite consistent with getting off by 4 bytes between AMG and L0,
that is 8 bytes less than you expected were written around there.
The L0 seems to have "dissappeared".

Hmm... Time to put the thinking cap on more seriously. Glad I didn't
try last night. :-( Hmm... Bingo!

Recall that James Van Buskirk was griping about the code not being
consistently *EXACTLY* copied from the source into the postings, and
he was particularly metioning source form issues. James is a pretty
smart guy (and has often turned out to be right on things that I
initally argued about with him). His gripe is right on target
enough that I almost wonder whether he saw the problem... Nah;
he'd have given the answer instead of being coy, but still...

Looking *VERY* carefully at

> WRITE(18,REC=IK) IKEYtot,(TIT(I),I=1,5),TETAEF,GLOG,ASALOG,NHE,AMG,
> 1 L0,LF,LZERO,LFIN,ITOT,DPAS,ECHX,ECHY,FWHM,(FL(D),D=I1,I2)

and ignoring the obviously wrong indentation, my editor counts 67
characters starting with the W of the write and ending with the last
comma of that line. If the W were in column 7, as seems likely, that
would put the comma in column 7+67-1=73. Old fixed source form allows
statements only in columns 6-72. If you have something past column
72, what happens to it varies a lot. Some compilers just quietly alow
longer lines and accept it as part of the statement. Maybe the
compiler that this worked on did that. Other compiler follow old
punched card tradition and quietly ignore it (columns 73-80
traditionally had card number data for card sorting machines).
On a compiler that does that, your comma will be ignored, spaces
will also be ignored (another bad thing about old source form),
and what you intended as two variables "AMG,L0" will end up looking
like just one AMGL0. There probably isn't an AMGL0, but with
implicit typing (evil), the compiler will just make one up anyway.
With implicit zero initialization (another evil), it has the value
zero, which looks unfortunately plausible as AMG, even though it
really isn't.

Looks to me like you have gotten bit by the combination of two "evils",
fixed source form (both the strict column limits and the blank
insignificance contribute here) and implicit typing. You are far
from the first to have been bitten by that combination. The third
evil of implicit zeroing disguised the symptoms by giving the
implicitly typed AMGL0 a plausible value.

Note, as an aside, that once you read the wrong data, things will go
rapidly downhill if you don't have plausibility and array limit
checks on the data (as most code doesn't). In particular, if you
read an incorrect (and way too large) value for ITOT, and later
use ITOT in a form like your (FNU(D),D=1,ITOT), this will attempt
to read an unreasonaably large number of elements from FNU,
exceeding both the size of FNU and of the record. This seems
quite consistent with your initial problem.

If this isn't *THE* problem, it sure looks like at least a
major contributor; could well be the whole thing.

Most compilers have an option to allow longer lines in fixed
source form, but I'd advise fixing the code instead - certainly
if it is just one or two cases. 

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Relevant Pages

  • Re: Scope of implicit none
    ... compatible with both f77 and f90 because, as I said before, IMPLICIT ... you seem to be equating f90 with free source form. ...
    (comp.lang.fortran)
  • Re: Ada exception block does NOT work?
    ... The parameter/formal declarations are like ... the compiler would guess for you how to call puts. ... > * implicit declaration of external functions. ... > K&R probably where good assember programmers but they where lousy compiler ...
    (comp.lang.ada)
  • Re: Program Fails When Parameter Fixed Constants are Changed (F77) ??
    ... This looks to be in some kind of nonstandard source form. ... I don't know whether that got messed up in posting or whether this ... The compiler didn't bitch about that? ... </begin standard universal rant> ...
    (comp.lang.fortran)
  • Re: Program Fails When Parameter Fixed Constants are Changed (F77) ??
    ... This looks to be in some kind of nonstandard source form. ... I don't know whether that got messed up in posting or whether this ...   Error: End of nonblock DO statement at is within another block ... The compiler didn't bitch about that? ...
    (comp.lang.fortran)
  • Re: trim(string) problems
    ... >> Together these make me think it is a compiler problem ... >> but correctly finds size with both explicit and implicit ... that makes my test program with the module work and should ...
    (comp.lang.fortran)