Prev: converting a character string into a variable name
Next: const argument in C interope with Fortran
From: rfengineer55 on 10 Jun 2010 21:31
The Visual Studio 2008/Intel software is now up and running and
properly compiling my FCC Fortran programs.

Take a look at my AMDIST.FOR source code that I posted to the list
here yesterday, and see if you can find a reason why it would
intermittently not read the am database file called AMDB.DAT. I had
the program reading that file a couple of times. did not change
anything in the source code, and it failed to read the file. the
number that pops out of IOSTAT is 26.

When I first began, I changed the Logical variable Test to True so the
program would be in a perpetual test mode which requires the user to
enter the AM database file name which is AMDB.DAT. I looked at the
file to make sure it was still present and not corrupt, and the file
is OK.

I compiled the program with F77 compatibility, then with VMS
compatibility, and it would read the file with neither compatibility
mode turned on. BTW when the program WAS reading the file initially,
it was compiled with VMS compatibility turned on. There were no
compiler warnings during the build process.

So why would the computer suddenly stop reading the AMDB.DAT data
file? While you're pondering that question, I'll look around in my
books to see if I can find out what an IOSTAT of 26 means :-)

Thanks beforehand for the help and suggestions.

Jeff
RF ENGINEER55

From: dpb on 10 Jun 2010 21:37
rfengineer55 wrote:
....

> So why would the computer suddenly stop reading the AMDB.DAT data
> file? While you're pondering that question, I'll look around in my
> books to see if I can find out what an IOSTAT of 26 means :-)
....

I'd suggest for debugging to get rid of the IOSTAT= and ERR= in the i/o
statements. Doing that will cause the runtime to abort and the error
messages be displayed.

As for why behavior might change, I'd venture possibly inadvertently
wrote to the same file during some test run or other accident.

--
From: glen herrmannsfeldt on 10 Jun 2010 22:16
rfengineer55 <rfengineer55(a)aol.com> wrote:
(snip)

> Take a look at my AMDIST.FOR source code that I posted to the list
> here yesterday, and see if you can find a reason why it would
> intermittently not read the am database file called AMDB.DAT. I had
> the program reading that file a couple of times. did not change
> anything in the source code, and it failed to read the file. the
> number that pops out of IOSTAT is 26.

Without actually looking, a common cause of that effect is
reading it more than once without either close/open or rewind.

Another thing to check is that no other program has the
file open, even another copy of the same program. If you
open in readonly mode, such as ACTION='READ' then more than
one program should be able to read it. Otherwise, the system
file locking might stop you.

-- glen
From: rfengineer55 on 10 Jun 2010 23:35
On Jun 10, 9:37 pm, dpb <n...(a)non.net> wrote:
> rfengineer55 wrote:
>
> ...
>
> > So why would the computer suddenly stop reading the AMDB.DAT data
> > file?  While you're pondering that question, I'll look around in my
> > books to see if I can find out what an IOSTAT of 26 means :-)
>
> ...
>
> I'd suggest for debugging to get rid of the IOSTAT= and ERR= in the i/o
> statements.  Doing that will cause the runtime to abort and the error
> messages be displayed.
>
> As for why behavior might change, I'd venture possibly inadvertently
> wrote to the same file during some test run or other accident.
>
> --

Good suggestion. I have been very careful about typing the correct
data base file name, so no problem there.

When I turned off IOSTAT and ERR, the program terminated saying that
it could not find the file AMDB.DAT on unit 20, and it gave the path
where it was looking. The path was correct, and the dbase file was
where it was supposed to be. So it makes me wonder about the unit
number then. Or, it's something else.

Jeff RF ENGINEER55
From: Richard Maine on 11 Jun 2010 00:03
rfengineer55 <rfengineer55(a)aol.com> wrote:

> When I turned off IOSTAT and ERR, the program terminated saying that
> it could not find the file AMDB.DAT on unit 20, and it gave the path
> where it was looking. The path was correct, and the dbase file was
> where it was supposed to be. So it makes me wonder about the unit
> number then. Or, it's something else.

As a general rule (not at all specific to you), when someone who is
asking for debugging help says that he checked that something was
correct, but doesn't show the data for me to verify that, it immediately
draws my attention to the thing claimed to be correct. That's because it
is so natural for someone to stop looking at a potential problem if they
have concluded that isn't the bug... so if they were wrong about it
being correct, they then never see it because they have stopped looking
there.

It is by no means always the case, but it sure draws my attention. As I
said, this is not at all specific to you. I'd wonder even if the poster
was a recognized expert. The usual mantra goes "show the data instead of
trying to describe it." Saying that "the path was correct" counts as a
description.

In this case, for example, I wonder whether the path might be relative
instead of absolute. It is *VERY* easy to get confused about relative
paths. And yes, a relative path can be vlid one day and then not valid
the next day if something has changed what it is relative to. Just an
off-the wall though. I have no idea whether it is the case; insufficient
data.

Permission problems can also have symptoms like that.

In another post, you ask about an error message saying something like (I
don't have it in front of me now) that irec was not assigned a label
value. That would mean (yes, I know it doesn't help much right at first)
that irec was used in a context that expects it to have the value of a
statement label.

Giving a variable a statement label value is an old f66 thing (and a
nasty hack in the language it was). You do so with an ASSIGN statement
(that's ASSIGN - not assignment; it starts with the keyword ASSIGN). I
can't tell from the data given whether the code actually was using that
old f66 feature or whether something else was misinterpreted as being an
attempt at using it. I'm a bit suspicious of the later, as the irec name
sounds more like a record number than a statement label. There were once
some nonstandard syntax forms used in relation to record numbers. I
wonder if one of those might be in the code and being misinterpreted.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
 |  Next  |  Last
Pages: 1 2 3
Prev: converting a character string into a variable name
Next: const argument in C interope with Fortran