On Mar 29, 2006, at 7:19 AM, Rowles, Steve CIV G25 wrote:

> In this situation, I tend to use unformatted reads as much as  
> possible...

Reasonable advice, except that, please, you are *NOT* talking about  
unformatted reads. You are talking about list-directed reads. List- 
directed is a subset of formatted. You are probably meaning to  
contrast it with explicit formatting. THis is more than just a  
wording quibble. I have had to help multiple people who made mistakes  
like opening a file with form='unformatted' because they intended to  
use what they had heard referred to as unformatted reads.

Lewis Balfour said:

> READ (STRING(29:34),*) BEG(1)
>
> Will probably need to be adjusted to be
>
> READ (STRING(30:35),*) BEG(1)

Yes. I suspect that is most of your problem. Better would be to use a  
start+offset form, with the offset being hard-wired, but the start  
being the variable result of your index function invocation. That  
would allow you to use the same code for both cases. Better still  
would be to either use list-directed reads or parse the line so that  
you don't depend on exact column locations. This isn't hard to parse  
- all you need to do is use scan to skip over the blanks, but that's  
more change than the minimal required.

> But the original question stands: why does the operation
>
> DO WHILE (INDEX(STRING,'Connectivity').EQ.3
>      & 		  .OR.INDEX(STRING,'domain').EQ.6
>      &            .OR.INDEX(STRING,'domain').EQ.7)
>
> fail?

It doesn't. That's why just posting that line wasn't helpful. That is  
not the line the error message is coming from.

>   The error given
>
> Input/Output Error 153: Input file ended
>
>    In Procedure: topobcwrite
>         At Line: 249
>
>       Statement: List-Directed READ
>            Unit: Internal File
>   Record Number: Floating point exception
>
> Suggests that the file has ended,
> but there are approximately 4000 lines
> remaining.

No. You misinterpret the message, It is talking about an *INTERNAL*  
file - not your data file. In all those lines like

   read(string(start:end)...

the string(start:end) is referred to as an internal file because the  
"read" is from the character data, which is internal to your program,  
rather than from an "ordinary" external file. So this is just saying  
that it ran off the end of one of those internal files.


> And line 249 in the code is the DO WHILE statement, not a
> read.

Then either you or the compiler is confused about the line count.  
That error message is not from a DO WHILE. No way. Period. It is from  
a READ statement.

Hmm. Looking slightly deeper, I suspect that the particular error  
comes because, with your hard-wired column numbers being off by 1,  
one of your string(start:end) substrings ends up being from a blank  
part of the line. You (well; the code; I realize you said it isn't  
yours)  are using list-directed (not unformatted) reads as in

   read(string(29:34),*) beg(1)

If there are nothing but blanks in string(29:34), the list-directed  
read will try to skip to the next line to find data to read. There  
isn't a "next line" in the "internal file" string(29:34), thus your  
error message. (I didn't check whether it was the particular 29:34  
one, but it will presumably be one of the ones like that).

-- 
Richard Maine                |  Good judgment comes from experience;
[log in to unmask]       |  experience comes from bad judgment.
                             |        -- Mark Twain