Problems of running fortran 66 program

Problems of running fortran 66 program

Tony's picture

I am a beginner of the Fortran, I have a very old Fortran program which is written in FORTRAN, and was designed and implemented on the DEC-20 of the University of Chicago Graduate School of Business (FORTRAN-20, version 5, an extension of ANSI FORTRAN-66). I used the visual studio 10 with intel fortran compiler 2013, 1.1.139. My system is window 7 64-bit. <!--break--> I set the property of the old program as following:

/nologo /debug:full /Od /assume:buffered_io /Qopt-matmul- /f66 /d_lines /Qopenmp_stubs /standard-semantics /Qcoarray:shared /convert:ibm /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:ldio_spacing /fpscomp:logicals /fpscomp:general /warn:interfaces /align:sequence /assume:dummy_aliases /Qsafe_cray_ptr /assume:noprotect_constants /assume:byterecl /Qtrapuv /module:"Debug\\" /object:"Debug\\" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c

After I run with debug, there are error message, however I start without debugging. Errors occurred in cmd with following statements:

forrtl: severe (47): write to READONLY file, unit 5, file CONIN$
In coarray image 1

application called MPI_Abort(comm=0x84000000, 3) - process 0
forrtl: severe (47): write to READONLY file, unit 5, file CONIN$
In coarray image 3

application called MPI_Abort(comm=0x84000000, 3) - process 2
forrtl: severe (47): write to READONLY file, unit 5, file CONIN$
In coarray image 2

application called MPI_Abort(comm=0x84000000, 3) - process 1
forrtl: severe (47): write to READONLY file, unit 5, file CONIN$
In coarray image 4

application called MPI_Abort(comm=0x84000000, 3) - process 3

job aborted:
rank: node: exit code[: error message]
0: localhost: 3: process 0 exited without calling finalize
1: localhost: 3: process 1 exited without calling finalize
2: localhost: 3: process 2 exited without calling finalize
3: localhost: 3: process 3 exited without calling finalize
Press any key to continue . . .

I think the problem is come from the input commands. There is a subroutine called OFILE, the original statements are

SUBROUTINE OFILE(IO,FNAME,IAC)
DOUBLE PRECISION FNAME
IF(IAC.NE.0)GO TO 10
OPEN(UNIT=IO,FILE=FNAME,ACCESS='SEQIN')
RETURN
10 OPEN(UNIT=IO,DEVICE='DSK',ACCESS='SEQOUT',FILE=FNAME)
RETURN
END

However, the intel fortran compiler doesn't support the ACCESS='SEQIN/SEQOUT' and DEVICE='DSK'. Therefore, I rewrote these subroutine as following:

IF(IAC.NE.0)GO TO 10
OPEN(UNIT=IO,FILE=FNAME,ACCESS='SEQUENTIAL',STATUS='OLD',READONLY)
RETURN
10 OPEN(UNIT=IO,ACCESS='SEQUENTIAL',STATUS='UNKNOWN',FILE=FNAME)
RETURN
END

I don't know whether it causes the problems as mentioned above. I can upload the fortran program if necessary. Thank you for your help.

37 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
app4619's picture

Did you intentionally want to create a parallel program using co-arrays?  If you did that is trying to run before you can walk... I would suggest removing that option and just getting the program to run in the first instance.

It looks like you have created  multiple threads  that are all trying to open the same file. 

Tony's picture

Thank you for your help. This program is not written by me, I think the main program is correct, since it works before. I think I need to revise DEVICE='DSK' in Intel Fortran Compiler or I need other libraries to handle this problem. 

app4619's picture

You have set compile options using openmp and coarray to create a parallel program. If the  program  is as old as you suggest it will not have been written this way. Remove the parallel options and recompile.

 

Lorri Menard (Intel)'s picture

I agree with app4619; remove the /Qcoarray switch.    Also, remove the /standard-semantics switch.  While it is true that that switch was intended to address only Fortran 90/95/2003 features, it could easily have side-effects with the /f66 support.

All that said, you opened the file as READONLY.   I assume there is another place where you are trying to write to it.

You will be able to find that line of code when you remove the /Qcoarray switch, and simply run the program.  You already have /traceback set, so it will give you more information about *where* in your program you are trying to "write" to the input unit.

               --Lorri

 

Tony's picture

Thank you for your help. I have remove these options, new the property is

/nologo /debug:full /Od /assume:buffered_io /Qopt-matmul- /f66 /d_lines /Qopenmp_stubs /convert:ibm /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:ldio_spacing /fpscomp:logicals /fpscomp:general /warn:interfaces /align:sequence /assume:dummy_aliases /Qsafe_cray_ptr /assume:noprotect_constants /assume:byterecl /Qtrapuv /module:"Debug\\" /object:"Debug\\" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c

Then the error occurred:

WARPS.exe has triggered a breakpoint
The program '[4708] WARPS.exe: Native' has exited with code 47 (0x2f).

Tim Prince's picture

I don't see any guarantee that any of those switches for compatibility with old compilers are necessarily relevant.  As far as I know, DEC-20 predated the abominations of fpscomp.  

I've never seen the definition of /f66 for ifort, but typically such options set a minimum loop count of 1 for programs which depended on non-standard behavior in that respect.  That was not covered by f66 standard, although some popular compilers worked that way with default options.

As others said, it makes no sense to combine those options with options dealing with later Fortran standards.  There's no way such an old program could have been written to foresee developments of 30 years later.

Tim Prince's picture

As far as I can see, /convert pertains to reading unformatted files which were written on old computers.  If you have one from the DEC, vaxd is a much more likely possibility than ibm.

When you have so many options which are meant to work with a debugger, you will probably need to run under the debugger to see what is happening.

app4619's picture

severe (47): Write to READONLY file

http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/2011Update/fortran/lin/bldaps_for/common/bldaps_rterrs.htm

 

You are trying to write to the file opened for reading. You need to understand what the program is trying to do and follow it in the debugger. Is it a small program? You could post it on the forum perhaps?

Tim Prince's picture

You told us already that you changed an OPEN from default read/write to READONLY.  By the way, OPEN was not in Fortran 66, so it seems that someone already modified the program to run with Fortran 77.

Tony's picture

Thank you for your help. The program contains many subroutines which I don't really understand. Kindly see the attached file and give me some comments. The data.txt should be the input file, I have tried to save it as .dat file, but it still doesn't work. With best regards, Tony

Attachments: 

AttachmentSize
Download WARPS.zip292.66 KB
Jan Jaap's picture

Try to find the spot in the code where IO is set. From the error is appears to be set to 5, that is the default input device.

writing to that device will generate an error.

Change that value from 5 to any number but not 0, 5 or 6. (try 11)

  Jan Jaap

Lorri Menard (Intel)'s picture

Look at line 370.  Change the second "5" to a "6", and that will get you past the initial failure.

That said, you'll have to step through the program in the debugger enough to figure out what it wants; I got as far as it asking for "Model Order", and I have no idea what the correct response is.

             --Lorri

Tony's picture

Thank you for your help. After I enter "Model of Order" as "1", "Drift Parameter" as "N", "Discontinuity" as "N", "How many explanatory variables" as "1" and "Number of Data Points" as 72. Errors occurred: The program '[2392] WARPS.exe: Native' has exited with code 47 (0x2f).

VARIABLES INDEXED 1 THROUGH  3

forrtl: severe (47): write to READONLY file, unit 5, file CONIN$

I think the problems are in the subroutine "RDATA".

With best regards, 

Tony

app4619's picture

This is ancient Fortran code doing all manner of awful things with data that sort of worked in a by gone age on long dead computers, such as storing character data as (35bit???!!!! yes I meant 35) real numbers (Fortran 66 did not have character variables). Large swathes of this code would disappear if it were coded today.

Do you need to use this code? What does it do? There are many sources of much more 'free' routines that would do the sort of stuff discussed in the program header....

 

bmchenry's picture

Just took a look/see at the code. it has some Fortran-66 and/or previous development environment issues, however once you clean it up a bit it should work/run fine on INTEL Fortran. I've moved many programs, thousands of lines of code from Fortran-66 forward and there are only a few issues and then you will be good to go.

the program appears to be well documented so you should be able to figure out what they are doing. and yes, back in the day character data was stored in read (4 characters per Real*4 variable) and using equivalences you can still do it (to get running) and then perhaps update some of the older items.

first recommendation i'd have is: understand what the program is trying to accomplish, and see if there a better/easier solution available? Spline fitting and Regression Analysis are available free all over the web. also some 'for fee' books/code like Numerical Recipies, whcih will also help you understand Fortran code. (they have an old school version and a Fortran 90 version) and many free math libraries.

Note it also appears to use Hollerith data and that's i believe no longer supported, but no sweat! simply go to those character variables and enclose them in quotes rather than using Hollerith.  So 4HTHIS simply becomes 'THIS'

i believe there are a number of good writeups on the web about moving code from ANSI-66 to modern day Fortran code. I'd get up to speed on them. And don't be one of the lemmings moving all your code to C++, there is no point. It's a waste of time since you can easily link with C++ code if parts would be better accomplished with C++.

I'd suggest you do the minimum changes required to get up and running.

Tony's picture

Thank you for your help. I don't really want to change the code. Do you have any libraries to suggest me for compiling this program? Or any website can help me to rewrite the subroutine "OFILE", "RFLIE", and "RDATA".

With best regards,

Tony

John Campbell's picture

Tony,

You have many things to change to get this program to run and probably more changes to make it run well. From the first example you have posted I can see that:

DOUBLE PRECISION FNAME : this indicates that FNAME is being used as an 8-byte character variable, as Fortran 66 did not have characters. You would be best advised to convert all character use to CHARACTER variables. (You need to check which F66 compiler was used to confirm how many characters were stored in a DOUBLE PRECISION variable). The most significant change from F66 to now is the introduction of character variables. It is much better to change to character variables, if you can identify when integer or real variables were used in this way.

IO appears to have a value of 5. I would change this to 15 ( greater than 10). F66 did not have a interactive / screen option so typically used units 5 and 6 for input and output. More recent compilers can use units 1 or 5 for input and 1 or 6 for output. Units 7 and 8 were also used by some compilers for the tape drive or an error unit.

The arguments (connect-specs) of the OPEN statement are also standardised with F90. READONLY can be replaced by ACTION='READ'. Most of the connect-specs can be omitted, as the defaults usually work. The following is probably all you need. I'd recommend that you always use iostat=.. for an OPEN statement, then check the value.

CHARACTER FNAME*8
OPEN ( unit=IO, file=FNAME, action='READ', iostat=IOSTAT )
 if (iostat /= 0) write (*,*) 'Error opening file :',FNAME,' on unit',IO,' : iostat=',iostat

Knowing what other changes will be needed requires some knowledge of F66 and F90+. Other changes you will need to address have been the use of generic functions and also the standardization of DO loops.

Hopefully this will give you some understanding of what you have to do to fix the errors you have reported. I will look at what you have attached and provide further suggestions.

John

Tony's picture

Thank you for your help. I have changed the open statements as your comments. I have changed the variables 'FNAME' and 'FNUL' from DOUBLE PRECISION to CHACATER FNAME*8,FNUL*8. I find out that XDAT and FMT are also in DOUBLE PRECISION in line 457, I don't know do I need to change them or not. I can't find which line the program set the IO as 5, I can only find the following statement: DATA IO5,IO6,IO20,IO21,IO22/5,6,20,21,22/ in line 374 in my attached file. After that, the same error occurred.

With best regards,

Tony

Attachments: 

AttachmentSize
Download WARPS_1.f265.54 KB
Lorri Menard (Intel)'s picture

Hi Tony -

     Let me introduce you to the wonders of "traceback".    Make sure you still build with the /traceback option, so the feature is enabled.  
When you run your program, and it has a runtime error (like the one you have here) you also get information about where in the program it failed.
    Included in this information is the call stack, starting in the runtime library, and giving information about where in the original source code the runtime error originated.

     And, that is true with  your program.   The traceback lists where in "warps.f" the error occurs, including which routine, and line number.

    So then, please, run your executable, and look for the traceback information.

     It is a stack, where the top address will be in the runtime library, or perhaps Windows system library, but as you look down the list of traceback entries, you'll come across one that comes from source "warps.f", with a line number.

      Look at that line number in the source, and see if there's anything "interesting" there.

mecej4's picture

The attached zip file contains a fixed-up version of the source, your data file, "data.txt", and a file "dat" with keyboard input that I think is reasonable. With this data as input, I find that the program reads the data successfully and processes it, but ends with the message "0**ERROR IN LSREG--IE =  1**". That is as far as I am able to help, given that I do not know what the calculation is supposed to do and what the data file contains. If you know what is correct/reasonable input to the program, you may be able to take the calculations farther. Do you have any documentation of the program that may help in deciding what input is to be provided?

As others have suggested, I think that it would be worthwhile for you to reason out what the calculation is supposed to do, and look for more modern software that will do that task.

Attachments: 

AttachmentSize
Download warpsf.zip23.09 KB
iliyapolak's picture

>>>WARPS.exe has triggered a breakpoint>>>

It seems that the program was compiled as a debug build.Usually in debug build stack will be filled with 0xcc opcodes which are used to pass control to currently registered debugger.

Tony's picture

Thanks for your help, and happy new year.

To Lorri, I find the stack frame: libifcoremdd.dll!1001fb60(), does it mean that I miss some libraries for this program.

To mecej4, thank you for your revised version, I still can't input the file, I enter Model Order as 3, drift parameter as "n", discontinue as "n", number of explanatory variable as "1", number of data as "72", and File name? "Return" To enter data here as data.txt, how many variables in this file as "2", enter 2 indices for variables as y x, then error occurred: forrtl: severe (64): input conversion error, unit 5, file CONIN$. I don't know whether I miss some libraries that you have.

To illyapolak: Thank you.

With best regards,

Tony

 

app4619's picture

Tony,

There is zero i/o error handling in this program. The error is that it is expecting one type e.g integer and you have entered a different type e.g real or character. Ignore the stack frame entries for the system stuff after the point of failure,  look down the traceback list for the last entry that actually relates to the code you compiled.  

iliyapolak's picture

@Tony

Does the breakpoint exception occur  when you compile your program as a release build?

mecej4's picture

Tony, to run the program with the modifications that I gave above, open an Intel Fortran command window, change to the directory containing the files extracted from the zip file, compile the Fortran source to build warps.exe. Then run using "warps < dat". The output that I got is given below.

S:langwarps>warps < dat

	0            W A R P

	             =======
 WECKER-ANSLEY REGRESSION PROGRAM

	 =      =      =          =
0ORDER OF MODEL?

	0DRIFT PARAMETER?

	0DISCONTINUITY?

	0HOW MANY LINEAR EXPLANATORY VARIABLES?

	0NUMBER OF DATA POINTS?

	0VARIABLES INDEXED 1 THROUGH  2

	 1=DEPENDENT VARIABLE, 2=NON-LINEAR EXPLANATORY VARIABLE

	0FILE NUMBER  1

	0FILE NAME?   "RETURN" TO ENTER DATA HERE  0HOW MANY VARIABLES IN THIS FILE?

	0ENTER  2 INDICES FOR VARIABLES

	0FORMAT?

	0MODEL SUMMARY
0MODEL ORDER M:                   1

	0DRIFT PARAMETER INCLUDED:       NO

	0DISCONTINUITY:                  NO

	0LINEAR EXPLANATORY VARIABLES:    0

	0SAMPLE SIZE:                    72

	0NUMBER OF DISTINCT VALUES:      72

	0STARTING VALUE FOR LAMBDA?

	0MAXIMUM ITERATIONS?

	0MAXIMUM 100 ITERATIONS WILL BE USED

	0STANDARD CONVERGENCE CRITERIA?

	0**ERROR IN LSREG--IE =  1**

You cannot change the data without breaking things. In particular, the number of columns in the data file have to match the number of variables. I believe that for a data file with two columns, there is one independent and one dependent variable. The format string input to the program has to match the format of the two-column data in the data file.

At any rate, you will need to go elsewhere to find what type of input the program expects. Questions about what the program does and why it runs with error messages are unlikely to be answered by people who have little or no knowledge of the program.

iliyapolak's picture

>>>The program '[4708] WARPS.exe: Native' has exited with code 47 (0x2f)>>>

Cannot find the description of 0x2f error code.

I suppose that during the program execution somehow instruction pointer referenced(on the stack) 0xcc instruction thus triggering software breakpoint.

Tony's picture

Thank you for your help,

To illiyapolak, no breakpoint exception occurred.

To mecej4, I still can't open the file with commands "warps<dat", I try to input the information as like as your dat file, I get stuck at "Enter 2 indices for variables", I enter "1 2(2f8.2) 0.01 1000 y" which is given in the "dat" file then the same error occurred.

To app4619 and illiyapolak, the last three codes in call stack: ntdll.dll!_NtReleaseMutant@8() + 0x15 bytes, KernelBase.dll!_ReleaseMutex@4() + 0x10 bytes,  and 0100cc8b(). I don't understand what's these mean.

With best regards,

Tony 

Tony's picture

Thank you for your help,

To mecej4, I still can't open the warps file with the command "warps<dat", I use the Microsoft Visual Studio 2010 and intel fortran compiler 2013 to compile the program. I enter the information as like as your "dat" file, I get stuck at "Enter 2 indices for variables" as "1 2(2f8.2) 0.01 1000 y", but same error occurred. Thank you.

To app4619 and iliyapolak: The last three codes in call stack: 1. ntdll.dll!_NtReleaseMutant@8()+0x15 bytes, 2. KernelBase.dll!_ReleaseMutex@4()+0x10 bytes, and 3. 0100cc8b() . I don't understand what's this means.

With best regards,

Tony

iliyapolak's picture

>>>To app4619 and iliyapolak: The last three codes in call stack: 1. ntdll.dll!_NtReleaseMutant@8()+0x15 bytes, 2. KernelBase.dll!_ReleaseMutex@4()+0x10 bytes, and 3. 0100cc8b() . I don't understand what's this means.>>>

These are function calls which are dealing with Mutex(internally called Mutant) synchronization object.Put it simply KernelBase.dll calls ntdll.dll stub which in turn calls internal Mutant implementaion located in Ntoskrnl file.Regarding the function call no.3 you posted  probably unresolved function(opcode) of the call site.

mecej4's picture

Quote:

Tony wrote:

 I enter the information as like as your "dat" file, I get stuck at "Enter 2 indices for variables" as "1 2(2f8.2) 0.01 1000 y", but same error occurred. 

If you are entering the data from the keyboard, rather than redirecting the file to standard input, note that you need to press "ENTER" between lines. The data should be as follows, with the ENTER key pressed at the end of each line of input:

1
n
n
0
72
data.txt
2
      1      2
(2f8.2)
0.01
1000
y

 

Tony's picture

To mecej4, Thank you for your help, I can get the same error as you mentioned, I find the error is the independent variable "x" is not full rank, I don't know the error is because the data or the type of input, since the type is character*10. 

mecej4's picture

Quote:

Tony wrote:

I don't know the error is because the data or the type of input, since the type is character*10. 

The only variables of type CHARACTER are file names and a format string. None of these are used in the calculation itself, but, as I stated earlier, you need to know what data the program expects in order to run it successfully. Furthermore, I would not expect such a program to behave reasonably when given incorrect data. Do you have any documentation for the program?
Anthony Richards's picture

IMHO, there is no point in continuing the struggle here unless you have, and can make available to the forum, an input data set that satisfies the requirements of and properly exercises the program as it was originally written in Fortran 66.

The Wecker-Ansley method of extracting a signal using a model dependant on a set of parameters in the presence of noise on the signal measurements (data) is described in several places on the Web if you do a search for 'Wecker-Ansley'. Their original paper was apparently published by the Journal of the American Statistical Society in 1983 and is frequently cited.

Tony's picture

To all, thank you for your help.

Tony's picture

To mecej4: I found out the problem of LSREG error =1 and have been revised. Kindly see the attached file. However I found out another problem, when I try to do the prediction, an error occurred: error(65) floating invalid. Thank you for you help again. With best regards, Tony 

Attachments: 

AttachmentSize
Download WARPS_2.f83.07 KB
mecej4's picture

There is nothing surprising about floating point errors occurring when a program that uses input data to perform calculations is given incorrect data. So far, you have not shown us what data you input to the program. Without that information in front of us, it is pointless to discuss the reasons why the floating point errors occurred.

Login to leave a comment.