- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've inherited a program that was compiled successfully using a previous version of DVF (version unknown but workspace files were provided). However, the program will not run using the example input file provided with the program and executable. The input file does work with the provided executable. A fatal error occurs when the program attempts an internal read statement:
read(LINE(37:),*,ERR=200) dummy,dlxtmp,dummy !begin at col 37
The line in the input file that causes the error is:
Type RM Length L Ch R = 3 ,20148.80,,,
The error obviously has something to do with reading null values...col 37 begins after "2048.80,"
Why did the program continue to 200 when null values were encountered using an earlier compiler and now results in a fatal error?...and how can I fix this easily...aside from removing null values from the input file before executing the program.
Thanks, Curtis
read(LINE(37:),*,ERR=200) dummy,dlxtmp,dummy !begin at col 37
The line in the input file that causes the error is:
Type RM Length L Ch R = 3 ,20148.80,,,
The error obviously has something to do with reading null values...col 37 begins after "2048.80,"
Why did the program continue to 200 when null values were encountered using an earlier compiler and now results in a fatal error?...and how can I fix this easily...aside from removing null values from the input file before executing the program.
Thanks, Curtis
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Send an example that reproduces the problem to us at vf-support@compaq.com, and we'll take a look. Please pack all the files in a ZIP file and attach that to your message, along with a problem description.
Steve
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You should have an answer for this from vf-support by now - but for the benefit or others, the answer is to read the following excerpt from the CVF 6.5 release notes:
In order to conform with clarified wording in the Fortran standard, the compiler has been changed so that when a READ statement encounters an end-of-file condition, and there is no END= specifier but there is an ERR= specifier, the ERR= branch is NOT taken. Similarly, if an end-of-record condition occurs but there is no EOR= specifier, an ERR= branch is not taken.
A further behavior change, to conform with the standard, has been implemented. If an EOF (or EOR) condition occurs and there is not an IOSTAT= or END= (or EOR= in the case of EOR) specifier, the program is terminated with an error message.
Steve
In order to conform with clarified wording in the Fortran standard, the compiler has been changed so that when a READ statement encounters an end-of-file condition, and there is no END= specifier but there is an ERR= specifier, the ERR= branch is NOT taken. Similarly, if an end-of-record condition occurs but there is no EOR= specifier, an ERR= branch is not taken.
A further behavior change, to conform with the standard, has been implemented. If an EOF (or EOR) condition occurs and there is not an IOSTAT= or END= (or EOR= in the case of EOR) specifier, the program is terminated with an error message.
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