Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!indri!xanth!mcnc!decvax!ryn!russes
From: russes@ryn.DEC.COM (Bob Russes)
Newsgroups: comp.unix.ultrix
Subject: Re: Tape EOF processing
Keywords: read EOF tape failure
Message-ID: <241@ryn.DEC.COM>
Date: 14 May 89 01:50:49 GMT
References: <490@sequoia.UUCP>
Reply-To: russes@ryn.UUCP (Bob Russes)
Organization: DEC Engineering Systems Group - Marlboro, MA
Lines: 28

In article <490@sequoia.UUCP> keith@sequoia.UUCP (Keith Pyle) writes:

>behavior (other than "It's a bug")?  If not a bug, is there a method,
>other than the one I've discovered, to clear the condition to permit
>the next read(2) to succeed as the manual says it should in the first
>place?

	To get around the problem, I simply advance the tape zero files.
Note:  this only seems to work on the VAX, it doesn't seem to work on a
DS3100:

 if (fromtape)
    {
      if ((len = read(fileno(fp), tapebuf, BUFLEN)) > 0)
	{ markcount = 0; return len; }
      if (++markcount == 1)
	then {
	       op.mt_op    = MTFSF;
               op.mt_count =     0;
               ioctl (fileno(fp),MTIOCTOP,&op);
               return TAPE_MARK;
	     }

    }

-----

Bob