jerry@violet.berkeley.edu ( Jerry Berkman ) (11/07/89)
In article <8911031050.AA02617@reason.psc.edu> ZRTA@DS0RUS1I.BITNET (Bernhard Bauer) writes: > Yesterday, 11.02.89 we switched from unicos 4.0. to unicos 5.0.7 >and we did also a compiler switch from cft77.3.0 to cft77.3.1. >A user, who had the following peace of fortran code which >was running well with cft77.3.0 claimed that his program >resulted in an error after we had switched the compiler. > OPEN(10,FILE='ERGEB',STATUS='OLD') > READ (10,*,END=25) (LES(J),J=1,1000000) > 25 CONTINUE > CLOSE (10) >obviously the user wants to read a lot of data and he does'nt know >how much records his file contains. Therfore he uses the end-clause. >I told the user to change the READ-statement in the following way: > READ (10,*,END=25,ERR=25) (LES(J),J=1,1000000) >and it worked. There must have been a change in the I/O library. The FORTRAN standard states: "If an error condition of an end-of-file condition occurs during execution of a READ statement, execution of the READ statement terminates and the entities specified by the input list and implied-DO-variables in the input list become undefined." (ANSI X-3.9-1978, section 12.6) So you shouldn't use J or the values in LES after an end-of-file termination of the read. There are two safe ways to do it: 1. Since you are using a list directed read, you can add a "/" after the data in file ERGEB to stop the read without using the ERR= and END= branches. or: 2. Read one element at a time: OPEN(10,FILE='ERGEB',STATUS='OLD') do 20 j=1,1000000 READ (10,*,end=25) LES(j) 20 continue 25 CLOSE (10) > Another Problem: >Another user has an INPUT file which contains 10 records. >He reads five records and then he writes an end of file. >However, if you have a look at that file, you have the original >ten records. The file appeares to be unchanged. > Are there more cray users who have observed such I/O problems? Cray does not truncate files if you write less than already existed in a file, at least for ASCII text files. We submitted a Software Problem Report to Cray a while ago and are still waiting for a response. Truncating involves setting the byte count correctly and releasing unneeded disk blocks. Currently neither is done (we are running UNICOS 4.0). For FORTRAN programs to work correctly, only the byte count need be set correctly. We have submitted a software problem report and have been waiting for an answer. >Bernhard Bauer >systems programmer >at the university of stuttgart >germany >Acknowledge-To: <ZRTA@DS0RUS1I> - Jerry Berkman
heiser@iis.UUCP (Gernot Heiser) (11/11/89)
In article <8911031050.AA02617@reason.psc.edu> ZRTA@DS0RUS1I.BITNET (Bernhard Bauer) writes: } } On our site at stuttgart university we have a cray2 running unicos. } Yesterday, 11.02.89 we switched from unicos 4.0. to unicos 5.0.7 }and we did also a compiler switch from cft77.3.0 to cft77.3.1. }It was our second try. }A user, who had the following peace of fortran code which }was running well with cft77.3.0 [ ... ] already professionally addressed by another poster. } Another Problem: }Another user has an INPUT file which contains 10 records. [ ... ] } Are there more cray users who have observed such I/O problems? As above. Except I might add that I experienced a few problems with I/O on the Cray-2 even with cft77 version 3.0. I haven't had the time yet to try with version 3.1 yet, but in general I/O on the Cray-2 seems to be a bit flaky to say the least. (I never had any problems on the X-MP, nor on a Y I tested recently in the US. Needless to say, the code runs without problems on various smaller sytems.) } A third problem I wish to notice is the following: }A recursive subroutine is called by a main program. It ran very well }with the compiler version cft77 3.0.0.14. In fact in ran properly }even with the 2.0 compiler version. But now it results in an error. }This kind of code is very usefull in the case of developing }multi-grid programs. In fact a multigrid program will not work }any longer. } I have been told that this program is not standard fortran }(I know it) and that I am using dynamical field allocation which }is not allowed in standard fortran. However, if I can not program }in this manner, I have do change the language! Well put! The only reasonable thing to do with FORTRASH under all circumstances. } Here is the fortran code. } } program tst } parameter (nmax=5,ndim=33) } integer ifeld(nmax) } real a(ndim) ... } call up(n,ifeld,a) }c } stop } end }c } recursive subroutine up(n,ifeld,a) } integer ifeld(n) } real a(ifeld(n)) } real b(ifeld(n-1)) this is most certainly not FORTRAN. Firstly, the parameter declaration is wrong. To quote ANSI X3.9-1978, section 5.1.1.1: "A dimension bound expression must not contain a function or array element reference." the proper way to do this would be: CALL UP (N, NDIM, IFELD, A) ... RECURSIVE SUBROUTINE UP (N, NDIM, IFELD, A) INTEGER N, NDIM, IFELD(N) REAL A(NDIM) The dynamic allocation is an absoulte no-no in standard F. What you can do is managing your own little heap: INTEGER HUGE PARAMETER (HUGE=10000) c ... or whatever may be required REAL HEAP (HUGE) ... CALL UP (N, NDIM, IFELD, A, HEAP) ... RECURSIVE SUBROUTINE UP (N, NDIM, IFELD, A, HEAP) INTEGER N, NDIM, IFELD(N) REAL A(NDIM), HEAP(*) ... CALL UP (N, NDIM, IFELD, A, HEAP(NDIM+1)) ... Yes, it's awful, but that is what FORTRAN is all about. Alternatively, if you don't care about portability, you can hack around with Cray-FORTRAN pointers. Or (as I do) write an interface to the C memory managment routines (malloc(3) & Co), which is at least portable throughout the UNIX world. >>> BEGIN FLAME And people keep telling "we have to use FORTRAN because of all our running codes...". If you see how expensive FORTRAN programming is due to the insufficient and error-prone language features, rewriting in a programming language would certainly be cheaper in the long run in almost all these cases. >>> END FLAME }Bernhard Bauer }systems programmer }at the university of stuttgart }germany }Acknowledge-To: <ZRTA@DS0RUS1I> -- Gernot Heiser Phone: +41 1/256 23 48 Integrated Systems Laboratory CSNET/ARPA: heiser%iis.ethz.ch@relay.cs.net ETH Zuerich UUCP (new): heiser@iis.uucp CH-8092 Zuerich, Switzerland UUCP (old): {uunet,mcvax,...}!iis!heiser