View previous topic :: View next topic |
Author |
Message |
AKS
Joined: 19 Mar 2008 Posts: 29
|
Posted: Mon Jun 15, 2020 6:55 pm Post subject: Creation of New Variable in Plato Debugging. |
|
|
I am running Plato with a conditional break point set. The program executes this statement many times:
IF (XKG2 .LT. XKG) XKG = XKG2
The values of the variables listed on the right-hand side of the debugger are fine, until it fails. The error upon failure is:
....variable XKG2391LIN is UNDEFINED. The variable name XKG2391LIN is not a variable that I have in the program. However, I did input a filename called 391LINX when the program starts. How is it possible to commingle these 2 variables?? Is there any way to troubleshoot this?
Thank you.
E.J. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8037 Location: Salford, UK
|
Posted: Mon Jun 15, 2020 7:33 pm Post subject: |
|
|
There must be a variable of that name in your program. The line where the error occurs will provide its approximate location.
It may be that you are using a continuation line when not realising or maybe it is an error relating to strings that are not correctly terminated.
As a general rule I recommend that you use IMPICIT NONE in your code in order to reveal variables that were not intended or misspelled. |
|
Back to top |
|
|
AKS
Joined: 19 Mar 2008 Posts: 29
|
Posted: Mon Jun 15, 2020 7:58 pm Post subject: Renaming variables in Plato debugger. |
|
|
Thanks for your response. The continuation line fault does not seem likely as those 2 character strings are not located anywhere near each other in the code. Nevertheless I'll check on it. There may be an issue with not correctly terminating a string. However, the string 391LINX is the name of an input file and is entered exactly as shown here. Is there some other way this string should be entered? It does after all accept the name and utilizes the file. I do use IMPLICIT NONE, but I believe I've written to you previously about that. This is old Fortran code and it uses TRIM and RANGE as variables whereas in Fortran 95, they are keywords. And while one can do TRIM = 5 without an error, if you write X=TRIM, there will be an error since it's looking for an argument to TRIM. Consequently, whenever TRIM and RANGE were used, I changed them to TRIMY and RANGEY. Thanks again for your help and your quick turnaround time. Regards, E.J. Yoerger |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1897
|
Posted: Tue Jun 16, 2020 1:30 am Post subject: Re: Renaming variables in Plato debugger. |
|
|
AKS wrote: | ...And while one can do TRIM = 5 without an error, if you write X=TRIM, there will be an error since it's looking for an argument to TRIM. |
It is a good practice to avoid using keywords as variable names, but the above statement is incorrect, and assuming that it is correct can land one in confusion.
Counterexample:
Code: | program xtrm
trim=2.5
x=1.3
x=trim+x
print *,x
end |
You have shown only fragments of code, and that is an obstacle to diagnosing the problem. Please show the code in question or post a link to a zip file containing all the code needed to build, run and exhibit the symptoms claimed.
The unexpected creation of a variable such as XKG2391LIN is unlikely to have anything to do with using Plato or the debugger. Compile with /lis /xref and look in the resulting listing and cross-reference files for XKG2391LIN. Note the line numbers and track down the source of the error. |
|
Back to top |
|
|
AKS
Joined: 19 Mar 2008 Posts: 29
|
Posted: Tue Jun 16, 2020 2:54 pm Post subject: Creation of New Variable in Plato Debugging. |
|
|
1000 Pardons. You were right about that variable already existing. It is not a variable name that I initially used. Somehow on a copy (or something else) the characters 391LIN were appended to XKG2. This was never intended and probably happened due to my hitting a "hot" key. I'm sorry that I can't provide the code as it is proprietary and it is too big. That's why I try to make up examples which simulate the problem. I believe that I've isolated the problem. The issue is that XKG2 gets set in an IF...ELSE...ENDIF statement. If it doesn't meet the IF condition, if falls through to ELSE. There is another IF in that statement which must be met to set XKG2. If not, it simply exits without being defined. Unfortunately, I inherited this code and there are many pitfalls in it. Nevertheless, I appreciate your remarks and your time to look at my problem. Our time is always valuable. Thanks. E.J. Yoerger |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1897
|
Posted: Tue Jun 16, 2020 3:04 pm Post subject: |
|
|
Quote: | The issue is that XKG2 gets set in an IF...ELSE...ENDIF statement. If it doesn't meet the IF condition, if falls through to ELSE. There is another IF in that statement which must be met to set XKG2. If not, it simply exits without being defined. |
On many old mainframe computers, variables in Fortran program were automatically initialised to zero. If your program was developed based on assuming that such initialisation would be done, you may wish to try using the /zero compiler option.
On the other hand, it would be definitely worthwhile to locate and fix all instances of undefined variables, and FTN95 is one of the best tools for such a task. |
|
Back to top |
|
|
|