Prev: converting a character string into a variable name
Next: const argument in C interope with Fortran
From: rfengineer55 on 11 Jun 2010 02:08
On Jun 10, 11:03 pm, nos...(a)see.signature (Richard Maine) wrote:
> rfengineer55 <rfenginee...(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

Richard,

You are very close to the actual root problem that I found. I don't
understand why it was working one minute, and stopped the next, but
Intel Visual Fortran puts the project files in your personal folder in
a sub folder valed Visual studio. Then in this case the tree continues
Project, AM_alloc, AM_alloc, Debug. the AMDB.dat file is in the Debug
folder. Keep that in mind for a minute.

OK, then when the executable terminated, the path was docs and
settings and all of that, then personal folder as above etc, AM_Alloc,
AM_alloc, AMDB.dat. See the problem? It was not looking in the Debug
folder, and I forgot tat I put two copies of AMDB.dat in this
particular folder tree. So once I put the dat file in that second
AM_Alloc folder, my program happily read it.

My program has logic errors because of the way it's eading the data
base. A few weeks ago I tried compiling this devil and got an error
that the file open structure was a VMS construct not supported and I
forgot that I put in a Fortran 77 supported Open stetement just to get
the program to compile. So I put the original staement back in, and
got the sme error with Intel Visual Fortran compiler even with VMS
compatibility set.

I can't find that statement at the moment. Probably because it's way
past bed time :-) I'll find that and post it tomorrow both here and
at the Intel Forum.
From: Steve Lionel on 11 Jun 2010 09:43
On 6/11/2010 2:08 AM, rfengineer55 wrote:
> You are very close to the actual root problem that I found. I don't
> understand why it was working one minute, and stopped the next, but
> Intel Visual Fortran puts the project files in your personal folder in
> a sub folder valed Visual studio. Then in this case the tree continues
> Project, AM_alloc, AM_alloc, Debug. the AMDB.dat file is in the Debug
> folder. Keep that in mind for a minute.

Visual Studio, by default, creates new projects in a folder under My
Documents. This is standard behavior for Microsoft applications. You
can change the "Location" setting to whatever you want and it will
remember it for the future.

> OK, then when the executable terminated, the path was docs and
> settings and all of that, then personal folder as above etc, AM_Alloc,
> AM_alloc, AMDB.dat. See the problem? It was not looking in the Debug
> folder, and I forgot tat I put two copies of AMDB.dat in this
> particular folder tree. So once I put the dat file in that second
> AM_Alloc folder, my program happily read it.

When Visual Studio executes a program, it sets the default directory to
be the project directory, not the directory that contains the executable
file. This does trip up those new to Visual Studio.

You can, if you wish, set the default "working" directory to be
something else. That is done by right clicking on the project in Visual
Studio, selecting Properties > Debugging. You'll find a field for
Working Directory there.

By the way, I do agree that it is Intel's responsibility to document
using Fortran in Visual Studio. We do, extensively, and I pointed you at
it yesterday. My guess is that you had not yet read the documentation
we provide. I also agree that we need more tutorial content for those
unfamiliar with Visual Studio, and we're developing that.


--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran
From: mecej4 on 11 Jun 2010 10:42
rfengineer55 wrote:

<--- CUT --->
> My program has logic errors because of the way it's eading the data
> base. A few weeks ago I tried compiling this devil and got an error
> that the file open structure was a VMS construct not supported and I
> forgot that I put in a Fortran 77 supported Open stetement just to get
> the program to compile. So I put the original staement back in, and
> got the sme error with Intel Visual Fortran compiler even with VMS
> compatibility set.

And there, ladies and gentlemen, is the smoking gun.

I suspected that this (attempting to open an ISAM file for sequential
unformatted access) was the major cause of all the problems. DPB wrote up
his assessment along similar lines with great clarity and added high
quality advice.

If the 'database' is in a VMS ISAM file, and contains VAX (non IEEE)
floating point variables, there is so much work to do in terms of adding
missing functionality that the simplest answer to give to a customer with
limited resources is: "it cant' be done".

I hope that, in view of this issue, at least a few readers will see my
recommendation to the OP to find a VAX (or Glen H's recommendation to find
a VAX emulator) as less than 100 percent facetious.

-- mecej4
From: Ron Shepard on 11 Jun 2010 11:30
In article <huti13$u3t$1(a)news.eternal-september.org>,
mecej4 <mecej4.nyetspam(a)operamail.com> wrote:

> If the 'database' is in a VMS ISAM file, and contains VAX (non IEEE)
> floating point variables, there is so much work to do in terms of adding
> missing functionality that the simplest answer to give to a customer with
> limited resources is: "it cant' be done".
>
> I hope that, in view of this issue, at least a few readers will see my
> recommendation to the OP to find a VAX (or Glen H's recommendation to find
> a VAX emulator) as less than 100 percent facetious.

It might be a good idea to find a vax or a vax emulator in order to
aid in convertng the program to standard form. However, I disagree
with the "it can't be done" part of this reply.

I don't remember all the details, but I have converted code like
this in the past. If the ISAM file has fixed-length records (which
I think was either required, or very common), then it is reasonably
straightforward to convert this to fixed-length direct access
records. The programmer needs to write code that converts from the
character labels to the integer record numbers. For small files,
this can be something as simple as making an array of the character
labels and searching that array when necessary. For larger files,
something more scalable may be necessary, such as creating a hash
table. That is what the vax i/o software was doing, creating a hash
table for the programmer.

The vax software might also have handled other data types as the
record keys (times or dates, for example), but the idea is the same
regardless. My conversions used character strings, so that is what
I remember using.

To give an example, suppose there are three records that are indexed
with the keys 'peter', 'paul', and 'mary'. The vax I/O statement
would have looked something like

crec = 'peter'
read(unit,crec) peter_record

The variable crec here is some character variable. So this would
need to be replaced with something like

keys(1:3) = (/ 'peter', 'paul ', 'mary ' /)

irec = match_key( 'peter' ) ! this should return the value 1
read(unit,rec=irec) peter_record

It is the match_key() function that does the hash resolution, or the
linear search, or whatever. It should return 1 with the argument
'peter', 2 for 'paul', and 3 for 'mary'.

If the ISAM file had variable length records, or if it changed the
database structure dynamically during a run, adding or deleting
information from the various records, then this is a more difficult
programming challenge. I do not remember what the vax i/o library
allowed. However, in my limited experience, it was common to see
more simple fixed-length data records, and those map relatively
easily with the above approach to standard direct-access records
(which may be either formatted or unformatted).

BTW, this was one of several issues that were contested during the
decade of the 1980's that caused the delay in the approval of the
fortran 84-->fortran 88-->fortran 8x-->fortran 90 standard. One
camp within the standards committee wanted to replace all of the
fortran I/O with this high-level database stuff. The other camp
wanted to go more in the direction of C/unix where all files were
simply byte strings, and all higher-level structure had to be
maintained by the programmer.

$.02 -Ron Shepard
From: Ian on 11 Jun 2010 11:57
Have a look at

http://deathrow.vistech.net/

They may be able to help.

Ian Chivers

On Jun 11, 3:42 pm, mecej4 <mecej4.nyets...(a)operamail.com> wrote:
> rfengineer55 wrote:
>
> <--- CUT --->
>
> > My program has logic errors because of the way it's eading the data
> > base. A few weeks ago I tried compiling this devil and got an error
> > that the file open structure was a VMS construct not supported and I
> > forgot that I put in a Fortran 77 supported Open stetement just to get
> > the program to compile. So I put the original staement back in, and
> > got the sme error with Intel Visual Fortran compiler even with VMS
> > compatibility set.
>
> And there, ladies and gentlemen, is the smoking gun.
>
> I suspected that this (attempting to open an ISAM file for sequential
> unformatted access) was the major cause of all the problems. DPB wrote up
> his assessment along similar lines with great clarity and added high
> quality advice.
>
> If the 'database' is in a VMS ISAM file, and contains VAX (non IEEE)
> floating point variables, there is so much work to do in terms of adding
> missing functionality that the simplest answer to give to a customer with
> limited resources is: "it cant' be done".
>
> I hope that, in view of this issue, at least a few readers will see my
> recommendation to the OP to find a VAX (or Glen H's recommendation to find
> a VAX emulator) as less than 100 percent facetious.
>
> -- mecej4

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: converting a character string into a variable name
Next: const argument in C interope with Fortran