Message-Id: <200110071400.f97E0vj96328@postino3.int.prima.com.ar>
From: "Orlando P. Hevia" <heviaop AT ciudad DOT com DOT ar>
To: djgpp AT delorie DOT com
Date: Sun, 7 Oct 2001 10:59:04 -0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: fortran scratch files II
CC: eliz AT is DOT elta DOT co DOT il
X-mailer: Pegasus Mail for Windows (v3.12b)
Reply-To: djgpp AT delorie DOT com

Eli:

Surely I was not clear:

The program I send now is:

C
C PROGRAM TO TEST THE PROBLEM OF NOT CORRECTLY CLOSED FILES
C    C
      DIMENSION X(10)
      OPEN (UNIT=52,STATUS='SCRATCH')
C
C CHANGE BY YOUR TMP DIRECTORY AS DEFINED IN DJGPP.ENV
C
      CALL SYSTEM('DIR G:\\USR\\TMP\\FORT*')
C
C THE FOLLOWING LINES TO HAVE A NON ZERO BYTES FILE
C
      DO I=1,10
      WRITE(52,*)I
      END DO
      CALL FLUSH
C
C SIMILAR TO PAUSE, BUT MORE EASY TO CONTINUE,
C ONLY RETURN IS NEEDED
C
      READ(*,'()')
C
C THE FOLLOWING LINE IS TO PRODUCE AN ABORT OF THIS PROGRAM
C THE CLOSE(52) IS NEVER REACHED C THE FILE FORTA52A WILL
HAVE SOME BYTES DUE TO THE FLUSH C WITHOUT FLUSH, THE FILE
WILL HAVE 0 BYTES, BUT IT WILL C EXIST C
      WRITE(*,*)X(N)
      CLOSE (52)
      STOP
      END

> 
> I don't understand: you are supposed to close the file
> before trying to open unit 52 again.  This program doesn't
> close the file, so it will only be deleted when the
> program exits.  What exactly are you trying to prove?

When you run the program, it aborts because the memory
access violation (X(N) with N not defined) and you will 
have
a forta52a file in your tmp directory. The CLOSE (52) line
is not reached, the file is not correctly closed and it is
not deleted.

This is the first part of the problem I am dealing.

If you run the program more and more times, you will have
forta52b.... etc

In some point, the program will abort, but by another 
reason: it cannot open a new scratch file. This is the
second part (the more important for our users) of the
problem, that was aborting the Alternative Transients
Program (ATP).

Of course, with DJGPP the user must be very unlucky to see
the problem, but it is not impossible: I had this problem
when I was testing a new development.

With Mingw32 the number of chances is small, and some users
reached the limit and the program aborted "without known
reason". We found the reason in this limit of scratch file
number, and solved it by deleting all this residual files.

Regards,

Ing. Orlando P. Hevia   
heviaop AT ciudad DOT com DOT ar
Santa Fe-Argentina