- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am working on a program with a Pascal main program (written by another) which calls a Fortran subroutine with arguments, written by me. On our old Vax machine the complete program worked. I have been translating the Pascal parts into Fortran because there is no Pascal compiler on my PC, only CVF6.5A. I have come across two bugs that puzzle me.
In the main part of the program REAL*8 X(N) is declared in a module PASVAR (included by USE statements in the ex-Pascal parts only) , where N is an earlier integer input. REAL*8 X(3) is declared in a module GTOUT included by a USE statement in rhe subroutine. X is not used in the arguments.
No errors are flagged up on compilation or linking (as expected). However, when running under debug, looking at X in the subroutine shows that it apparently does not change from zero, because the values given by the debugger are those of the PASVAR X. GTOUT::X needs to be typed in the Watch Window to get the values of X in the subroutine. This seems a bit quirky, and worthy of being changed in some future CVF upgrade, but is not the worst of my problems.
The subroutine subsequently failed, and I found that the error lay in the statement
APROJ was being calculated as zero. Now PI4 = pi/4, set as a REAL*8 parameter, APROJ & DSQ were REAL*8, and each of the identifiers was declared only once, so it wasn?t like the problem with X. This subroutine had worked many times before without trouble in other programs, and had been copied into this program without modification.
Because one cannot see the value of a parameter under debug, I then inserted two extra lines, making the program lines:
The correct value of APROJ was calculated in each line, and the subroutine worked normally. I then deleted the first two lines, setting the subroutine back to what it was before I inserted the two extra lines. The correct value of APROJ was calculated in the original line, and of course the subroutine worked normally.
About this time I started tearing what was left of my hair out.
I have not been able to reproduce the error by recalling the original version of the subroutine ? it just works perfectly now. I can?t see what can be done about this, but just hope that it does not happen again.
As a later observation, I noted that in the main program DF and IF were used and declared as LOGICAL*1 (for Direct and Indirect Fire, common ballistic abbreviations). The program did not compain about the use of IF, but I have subsequently changed it to IDF - just in case it was causing the above or any other trouble.
Bear of little brain
In the main part of the program REAL*8 X(N) is declared in a module PASVAR (included by USE statements in the ex-Pascal parts only) , where N is an earlier integer input. REAL*8 X(3) is declared in a module GTOUT included by a USE statement in rhe subroutine. X is not used in the arguments.
No errors are flagged up on compilation or linking (as expected). However, when running under debug, looking at X in the subroutine shows that it apparently does not change from zero, because the values given by the debugger are those of the PASVAR X. GTOUT::X needs to be typed in the Watch Window to get the values of X in the subroutine. This seems a bit quirky, and worthy of being changed in some future CVF upgrade, but is not the worst of my problems.
The subroutine subsequently failed, and I found that the error lay in the statement
APROJ = PI4*DSQ
APROJ was being calculated as zero. Now PI4 = pi/4, set as a REAL*8 parameter, APROJ & DSQ were REAL*8, and each of the identifiers was declared only once, so it wasn?t like the problem with X. This subroutine had worked many times before without trouble in other programs, and had been copied into this program without modification.
Because one cannot see the value of a parameter under debug, I then inserted two extra lines, making the program lines:
APROJ = PI4 APROJ = DSQ APROJ = PI4*DSQ
The correct value of APROJ was calculated in each line, and the subroutine worked normally. I then deleted the first two lines, setting the subroutine back to what it was before I inserted the two extra lines. The correct value of APROJ was calculated in the original line, and of course the subroutine worked normally.
About this time I started tearing what was left of my hair out.
I have not been able to reproduce the error by recalling the original version of the subroutine ? it just works perfectly now. I can?t see what can be done about this, but just hope that it does not happen again.
As a later observation, I noted that in the main program DF and IF were used and declared as LOGICAL*1 (for Direct and Indirect Fire, common ballistic abbreviations). The program did not compain about the use of IF, but I have subsequently changed it to IDF - just in case it was causing the above or any other trouble.
Bear of little brain
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Declaring a variable named IF should not be a problem.
Without seeing a complete example that demonstrates the problem, it's very difficult to say much on the topic. I do wonder if you have a scoping problem, though. This is where program fragments are not helpful.
Steve
Without seeing a complete example that demonstrates the problem, it's very difficult to say much on the topic. I do wonder if you have a scoping problem, though. This is where program fragments are not helpful.
Steve

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page