Conference turris::fortran

1192.0. "ACCVIO with INDEXED read." by CSC32::EHA (Flip) Fri Feb 21 1997 17:52

    Hello,
    
    I have a customer that sent in a problem with indexed files.  He is
    getting an ACCVIO when he should be getting an error on a read.  I know
    this code is not something one would normaly see, but...
    
    I reproduced this problem on a VAX VMS 6.2 system, with FORTRAN
    6.4-165.  The following is a log of the run:
    
$ on warning then goto clean_up
$ create prob_demo.for
C  PROB_DEMO - This routine demonstrates a suspected VMS I/O system problem.
C
C
      PROGRAM  PROB_DEMO
C
C	The problem is as follows:
C
C	1. READ a file that is not OPEN.
C	2. Note that an I/O error code 29 is returned.
C
C	3. Create the default name: FOR002.DAT
C	4. Ensure the file is not OPEN.
C
C	5. Again READ the un-OPEN file.
C
C	6. Note the fatal SYSTEM-F-ACCVIO error.
C
C
C	Note that the read must be KEYed for this error to occur.
C
C
C***************************************************************************

C
      IMPLICIT NONE
C
C
C  Local Variable Declarations
C
      INTEGER*4     LUN             ! Logical Unit Number used for file I/O
      INTEGER*4     IOSTT           ! VMS I/O Status
      INTEGER*4     KEY_VAL
C
      CHARACTER*80  GARBAGE         ! A READ Input buffer
C
C
      DATA          LUN /2/
C
C  Perform a Keyed Read of a file without OPENing it.
C
      PRINT 1000
 1000 FORMAT (/,' Preparing to READ an unOPENed file '
     &          'that does not exist.')
      READ (LUN, KEY=KEY_VAL, IOSTAT=IOSTT)  GARBAGE
C
C  Display the VMS I/O status.  It should be 29.
C
      PRINT 1001, IOSTT
 1001 FORMAT (/,' READ COMPLETED.  I/O STATUS = ', I4)
C
C  Read a file without OPENing it.  This creates FOR002.DAT/
C
      PRINT 1002
 1002 FORMAT (/,' Creating the default named file FOR002.DAT ')
      WRITE (LUN, IOSTAT=IOSTT)  GARBAGE
      CLOSE (LUN, IOSTAT=IOSTT)
C
C  Now perform a Keyed Read of the file, again without OPENing it.
C
      PRINT 1003
 1003 FORMAT (/,' Preparing to READ an unOPENed file '
     &          'where the default fine name does exist.')
      READ (LUN, KEY=KEY_VAL, IOSTAT=IOSTT)  GARBAGE
C
 999  CALL EXIT
      END
$ fortran prob_demo
$ link prob_demo
$ if f$search("for002.dat") .nes. "" then delete for002.dat;*
$ run prob_demo

Preparing to READ an unOPENed file that does not exist.

READ COMPLETED.  I/O STATUS =   29

Creating the default named file FOR002.DAT 

Preparing to READ an unOPENed file where the default fine name does exist.
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000, PC=00050FB6, PSL=03C00004
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC

                                                           00050FB6  00050FB6
PROB_DEMO       PROB_DEMO                          63      000000D9  000006D9
$clean_up:
    
    I have looked at the other notes in here, but I don't see anything like
    this.  Is there a reason for the program giving an ACCVIO instead of a
    iostat value?
    
    Thank you!
    Al

    Looks like an RTL bug - something's not getting cleaned up
    thoroughly.  I'll take a look at it.
    
    				STeve

    Any word on this yet?
    
    Al

Ok, I've looked at it some more.  How very interesting - this is the first
time in 15 years or more that someone's tripped over this (and let us know).

What's happening is that when an I/O statement is started, it checks to see if
the statement type conflicts with the file attributes.  For example, it will
disallow a keyed read on a file open for sequential access.  The problem is
that it does this BEFORE doing a default open if the file is not already
open, thus it doesn't correctly do the check and lets it go.  A bit later,
when the KEY= processing is looking for the "key directions array" to check,
it doesn't find one and ACCVIOs.  Since the only kind of "default open" that
would get in trouble is one caused by a keyed read/write, and most applications
doing keyed I/O take care to open the file first, this doesn't come up.

I'll fix it, but the result will be a different error message (I assume the
user knows that).  I'll probably be creating an ECO kit for the VAX RTL
sometime in the next month or two with this fix in it, and will check it in
for VMS 7.1.  Let me know if the customer is anxious for a fix earlier.

It seems so obvious in hindsight....  Works ok on Alpha.

				Steve

    Wow!  What a nasty conbination of events.  I am going to recomment that
    they do not use the default keyed open and open the file specificaly. 
    
    Thank you for your description of the problem.
    Al
    

    They can't use a default keyed open, since the default access mode is
    SEQUENTIAL.  (Hmm, I suppose we could make the default KEYED for a
    keyed I/O statement - never thought about that.  But that would only
    work for READs...)  Without the bug, they get a OPEDEFREQ (OPEN or
    DEFINE FILE required) error.  But at least it's a Fortran error,
    catchable with an ERR= or IOSTAT=, and not an ACCVIO.
    
    				Steve

    Good point.  Thanx!