bernhold@qtp.ufl.edu (David E. Bernholdt) (02/22/89)
I am writing a chunk of code in which I want to trap I/O errors. I use END= and ERR= specifiers to do this. Logic tells me that an end-of-file condition should be handled by an ERR= iff no END= is present. The '77 standard tells me that "The set of input/output error conditions is processor dependent." That seems to give someone the leeway to *not* handle end-of-files with ERR= if no END= is present, and (of course) I have a case in which this occurs (SunOS 3.4 f77). Can anyone tell me if this "hole" was intentional, or an oversight? If it was intentional, what is the logic? It seems rather inane to have to put in "END=8800, ERR=8800" into every READ statement. Dave -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365
jerry@violet.berkeley.edu ( Jerry Berkman ) (02/22/89)
In article <436@orange19.qtp.ufl.edu> bernhold@qtp.ufl.edu (David E. Bernholdt) writes: >I am writing code in which I want to trap I/O errors.... Logic tells me that >an end-of-file condition should be handled by an ERR= iff no END= is present. >The '77 standard tells me that "The set of input/output error >conditions is processor dependent." That seems to give someone the >leeway to *not* handle end-of-files with ERR= if no END= is present, >and (of course) I have a case in which this occurs (SunOS 3.4 f77). >Can anyone tell me if this "hole" was intentional, or an oversight? >If it was intentional, what is the logic? It seems rather inane to >have to put in "END=8800, ERR=8800" into every READ statement. There is no support in the standard for your "logic" that an end-of-file condition should cause a branch via the "ERR=" label if no "END=" is present. Sections 12.6 and 12.7 discuss error conditions and end-of-file conditions as distinct entities. A processor which takes the "ERR=" branch for an end-of-file condition would be non-standard. - Jerry Berkman U.C. Berkeley Computing Services jerry@violet.berkeley.edu
gilmore@vax1.acs.udel.EDU (Scott Gilmore) (02/23/89)
In article <20692@agate.BERKELEY.EDU> jerry@violet.berkeley.edu ( Jerry Berkman ) writes: >In article <436@orange19.qtp.ufl.edu> bernhold@qtp.ufl.edu (David E. Bernholdt) writes: > >>I am writing code in which I want to trap I/O errors.... Logic tells me that > >There is no support in the standard for your "logic" that an >end-of-file condition should cause a branch via the "ERR=" label >if no "END=" is present. Sections 12.6 and 12.7 discuss error >conditions and end-of-file conditions as distinct entities. >A processor which takes the "ERR=" branch for an end-of-file >condition would be non-standard. > > - Jerry Berkman > U.C. Berkeley Computing Services > jerry@violet.berkeley.edu > I have a related problem for READs from the keyboard, as well as OPEN and INQUIRE statements. On an IBM 3090 running VM/CMS, I do in fact trap my errors with END= and ERR= parameters. However, the 3090 insists on producing a traceback dump when an end/error is encountered. After wading through all of the (many) pages of traceback, the program continues at the branch statement that I have specified in the END= or ERR= line. I know there is an error ... that's why I'm trapping it and handling it myself. I don't want the system to produce a traceback so that I can recover gracefully and transparently to the user!!! So, does anyone know how I can suppress these tracebacks? (I know that IBM VM is not the best Fortran environment. In fact, the codes I am speaking were developed on a VMS Vax and MUST be ported to the IBM machine without making them machine-specific. That is, I need to have the exact same code running on both machines.) Thanks. ------------------------------------------------------------------------------ Scott Gilmore Research Assistant University of Delaware gilmore@vax1.acs.udel.edu Center for Composite Materials gilmore@oscar.ccm.udel.edu Dept. of Mechanical Engineering gilmore@minnie.me.udel.edu ------------------------------------------------------------------------------
bill@hcx2.SSD.HARRIS.COM (02/23/89)
> The '77 standard tells me that "The set of input/output error > conditions is processor dependent." That seems to give someone the > leeway to *not* handle end-of-files with ERR= if no END= is present, > and (of course) I have a case in which this occurs (SunOS 3.4 f77). > > Can anyone tell me if this "hole" was intentional, or an oversight? > If it was intentional, what is the logic? It seems rather inane to > have to put in "END=8800, ERR=8800" into every READ statement. There is _no_, repeat _no_, leeway in this matter. I refer you to Section 12.6 of X3.9-1978: "... or if an end-of-file condition occurs during execution of a READ statement that contains neither an input/output status specifier nor an end-of-file specifier (12.7.2), execution of the executable program is terminated." In other words, if you don't have a STATUS= nor an END=, an end-of-file condition is _not_ handled by the ERR=; the program terminates. Any implementation that takes the ERR= branch in this situation is a non-conforming implementation. Bill Leonard, Member X3J3 Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or bill%ssd.harris.com@eddie.mit.edu
urjlew@ecsvax.UUCP (Rostyk Lewyckyj) (02/24/89)
gilmore@vax1.acs.udel.EDU (Scott Gilmore) writes: > > I have a related problem for READs from the keyboard, as well as OPEN and > INQUIRE statements. On an IBM 3090 running VM/CMS, I do in fact trap my > errors with END= and ERR= parameters. However, the 3090 insists on producing > a traceback dump when an end/error is encountered. After wading through all of > the (many) pages of traceback, the program continues at the branch statement > that I have specified in the END= or ERR= line. I know there is an error ... > that's why I'm trapping it and handling it myself. I don't want the system to > produce a traceback so that I can recover gracefully and transparently to the > user!!! So, does anyone know how I can suppress these tracebacks? In the Language Reference manual and Programming guides read the section on the extended errorhandling facility. There is a subroutine that you can call, to which you pass the error code and how you want to handle it. call errset(ierno,inoal [,inomes][,itrace][,iusadr][,irange]) The inomes parameter controls whether the system will put out error messages for this condition. The itrace parameter controls whether there will be a traceback issued. Inoal controls how many times this error will be allowed before aborting the program. Iusadr is the name of a user supplied subroutine called to handle the error. Perhaps you might wish to post a sample of your code that is causing problems, then people might offer specific solutions. > > (I know that IBM VM is not the best Fortran environment. In fact, the codes I > am speaking were developed on a VMS Vax and MUST be ported to the IBM machine > without making them machine-specific. That is, I need to have the exact same > code running on both machines.) > Of course the extended error handling facility of IBM Fortran is system specific and so will not meet your requirements. From the tone of that last sentence I gather that you believe the VMS VAx system allows you to develop programs that are "not machine specific", and that the program you aere working on is "not machine specific", But its just that IBM doesn't see it as such?? ;-). ----------------------------------------------- Reply-To: Rostyslaw Jarema Lewyckyj urjlew@ecsvax.UUCP , urjlew@tucc.bitnet or urjlew@tucc.tucc.edu (ARPA,SURA,NSF etc. internet) tel. (919)-962-9107
cdb@hpclcdb.HP.COM (Carl Burch) (03/01/89)
> > The '77 standard tells me that "The set of input/output error > > conditions is processor dependent." That seems to give someone the > > leeway to *not* handle end-of-files with ERR= if no END= is present, > > and (of course) I have a case in which this occurs (SunOS 3.4 f77). > > > > Can anyone tell me if this "hole" was intentional, or an oversight? > > If it was intentional, what is the logic? It seems rather inane to > > have to put in "END=8800, ERR=8800" into every READ statement. > There is _no_, repeat _no_, leeway in this matter. I refer you to Section > ... > In other words, if you don't have a STATUS= nor an END=, an end-of-file > condition is _not_ handled by the ERR=; the program terminates. Any > implementation that takes the ERR= branch in this situation is a > non-conforming implementation. > Bill Leonard, Member X3J3 You know, I really hate to agree with Bill Leonard (we have so much fun disagreeing), but it looks like his interpretation is pretty clear - though it's difficult to absolutely swear that anything you did in the presence of an ERR= specifier is wrong, given the very strong processor-dependence clause in 12.6. At this point, I'd be more interested in asking if the net feels that the behavior Jerry expects (or desires) may well constitute the dreaded (in standards circles, anyway) COMMON PRACTICE (echo on...). I know of several implementations that do as Jerry asks - maybe they are the majority. Anyone want to try out their vendor's libraries and post the results? The next public review of Fortran 8x will probably start this fall, maybe we could get it changed. - Carl Burch
rogerk@mips.COM (Roger B.A. Klorese) (03/01/89)
In article <436@orange19.qtp.ufl.edu> bernhold@qtp.ufl.edu (David E. Bernholdt) writes: > >Logic tells me that an >end-of-file condition should be handled by an ERR= iff no END= is >present. No, your experience with VMS FORTRAN tells you this. End-of-file is not considered an error in FORTRAN 77, but an expectable condition; it is not necessarily subject to handling via ERR=. -- Roger B.A. Klorese MIPS Computer Systems, Inc. {ames,decwrl,pyramid}!mips!rogerk 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@servitude.mips.COM (rogerk%mips.COM@ames.arc.nasa.gov) +1 408 991-7802 "I majored in nursing, but I had to drop it. I ran out of milk." - Judy Tenuta
bernhold@qtp.ufl.edu (David E. Bernholdt) (03/02/89)
In article <14166@admin.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes: >In article <436@orange19.qtp.ufl.edu> bernhold@qtp.ufl.edu (David E. Bernholdt) writes: >>Logic tells me that an >>end-of-file condition should be handled by an ERR= iff no END= is >>present. > >No, your experience with VMS FORTRAN tells you this. End-of-file is not >considered an error in FORTRAN 77, but an expectable condition; it is not >necessarily subject to handling via ERR=. Actually, VMS FORTRAN has nothing to do with it. Can you show me a FORTRAN compiler that does NOT produce and ERROR message on an end-of-file if it is not trapped? I haven't yet seen one. I understand what the standard says about EOF and error conditions. I also understand how to use IOSTAT. The point I was trying to make when I asked the question is why does and EOF have to be trapped separately in all cases, when as far as the computer is concerned one is just as much an error as the other? -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365
jlg@lanl.gov (Jim Giles) (03/03/89)
From article <448@orange19.qtp.ufl.edu>, by bernhold@qtp.ufl.edu (David E. Bernholdt): > > Actually, VMS FORTRAN has nothing to do with it. Can you show me a > FORTRAN compiler that does NOT produce and ERROR message on an > end-of-file if it is not trapped? I haven't yet seen one. > From ANSI X3.9-1978 FORTRAN 77, Page 12-9, lines 22-25: ... if an end-of-file condition occurs during execution of a READ statement that contains neither an input/output status specifier nor an end-of-file specifier (12.7.2), execution of the executable program is terminated. This does not say anything about an error message. In fact, a Fortran environment which produces an error message in this case can be considered non-standard. Many programs may rely on this behaviour to correctly terminate when their input file is exhausted. In point of fact, most systems _do_ issue a message on this condition. It would be incorrect for the message to imply that the condition was an error. J. Giles Los Alamos
rogerk@mips.COM (Roger B.A. Klorese) (03/03/89)
In article <448@orange19.qtp.ufl.edu> bernhold@orange19 (David E. Bernholdt) writes: >In article <14166@admin.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes: >>No, your experience with VMS FORTRAN tells you this. End-of-file is not >>considered an error in FORTRAN 77, but an expectable condition; it is not >>necessarily subject to handling via ERR=. >Actually, VMS FORTRAN has nothing to do with it. Can you show me a >FORTRAN compiler that does NOT produce and ERROR message on an >end-of-file if it is not trapped? I haven't yet seen one. The runtime (not the compiler) produces an END-OF-FILE message, which is usually handled by terminating the program. This is *not* an error message. >I understand what the standard says about EOF and error conditions. I >also understand how to use IOSTAT. The point I was trying to make >when I asked the question is why does and EOF have to be trapped >separately in all cases, when as far as the computer is concerned one >is just as much an error as the other? "As far as the computer is concerned", a record number which produces an overflow condition when computed would be "just as much an error as the other"; would you have this handled by the ERR= clause as well? -- Roger B.A. Klorese MIPS Computer Systems, Inc. {ames,decwrl,pyramid}!mips!rogerk 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@servitude.mips.COM (rogerk%mips.COM@ames.arc.nasa.gov) +1 408 991-7802 "I majored in nursing, but I had to drop it. I ran out of milk." - Judy Tenuta