[comp.lang.fortran] Using END= and ERR= in READs

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