error 112

The iostat statement in line 8 delivers the value 0, but the write statement in line 10 provides an error 112. Is there any chance to check the error before line 10 ?

winapp 0,0
program test
include<windows.ins> 
integer*4 iknot(20),ierr
open(20,file='test.dat',access='direct',recl=80)
do 100 i=1,20,2
100  write(20,rec=i)i
read(20,rec=2,iostat=ierr)iknot
write(*,*) ierr
write(*,*) iknot
stop
end

You have called the record size as 80 bytes, but only have written 4 bytes per record. The remainder of the record is 'undefined'; the actual contents might match the pattern used to mark UNDEFINED/UNINITIALIZED values.

Compile/run as RELEASE so that undefined variables are not trapped and see if it runs. I think you'll find that it runs with no errors.

That said, the WRITE of iknot to the console may show odd values.

Thank you for your reply. Sorry I did not describe the situation completely. I get the file “test.dat” from another program and I do not know, how many and which records are filled (or described) with values. Unfortunately I have no possibility to pre-fill all records with values, for example with zero. But when a record is filled, it is always filled with 20 values (rec-length = 4*20=80). That means, I only should need if a record is filled with values or not. Is there a possibility to proof, if a record is filled (or described) or not to avoid the error 112 and abend of the program?

Thanks

Just an idea:

(1) Read the file record by record as character*80 string (2) Parse the string for character values between 48 and 57 (= the digits 0 ... 9) (3) If you find digits, try to read the iknot values from the string

I'd still compile as RELEASE to see if there is a difference in execution and/or errors. Here's why.

If, for any variable, the in-memory value is 80 (hex), or 80808080 (hex) in the case of the integer*4 values, then you will get flagged with an UNDEFINED error when you attempt to display that value.

Reading it in as an 80 character string might work as long as ALL 80 bytes are not 80 (hex). Any one character will not cause the UNDEFINED to occur.

Thanks for help, the problem seams not to be easy.

Wilfried: After a first test it seams that your idea works. I still will make some tests.

Wahorger: What do you mean with “compile as RELEASE”? I am also interested in your proposal.

You stated: I get the file “test.dat” from another program and I do not know, how many and which records are filled (or described) with values.

Then you provide an open statement: open (20,file='test.dat',access='direct',recl=80)

From this OPEN, you are expecting that the file test.dat contains fixed length records of 80 characters. Is that consistent with 'I do not know, how many and which records are filled (or described) with values' ?

I think the solution would be to open the file “test.dat” in a more flexible way, say access='transparent', and try to see what information you can find, then write it to a new more structured file, that is easier for your program to manage.

Also, I am not a fan of formatted, direct access files, although the default for 'direct' is 'unformatted'.

If I was receiving a direct access file, I would want the file to have a more formal structure and not records that are possibly filled with values'.

Note, if you are creating a fixed length record, direct access file, it is possible to rewrite the first record, with key measures of the file structure after the file has been completed. This initial indexing makes the file a lot easier to use when re-opened. All you need is a well defined record/data structure.

John

John, the errors occurs rarely (the first time in 6 month by nearly daily usage) and results obviously from an unknown software error or handling error on the other side. Fact is, that one record of the file was filled with hex(80808080……) and the iostat parameter in the read statement in line 8 delivers no error (I do not understand why).

Therefore I only will check the file to avoid abnormal termination of my program (unknowingly why for my colleagues) and say the other side to send new files.

With the idea of Wilfried and Wahorger I can do this check now and print a clear error message.

I also tried your proposal but was not successful until now. Problem is that I never used access=’transparent’ before but I will work on it. Perhaps you could me give a short example.

Thank you very much