read(2) won't move TK50 past tape file mark

[John Buck]

In article <187 at larry.sal.wisc.edu>, jwp at larry.sal.wisc.edu (Jeffrey W Percival) writes:
> ... I wrote a little
> C program that does a read(2) in a tight loop, and reports the number
> of bytes read.    We expect this:
> 	80 bytes read
> 	80 bytes read
> 	80 bytes read
> 	0 bytes read
> 	8192 bytes read
> 	8192 bytes read
> 	...
> Right?  We get this output on a VS2000 with Ultrix 2.2, and a VS2000

I would not expect it to do what you said.

> with Ultrix 3.0.  However, on 2 of our MicroVAX II's running Ultrix 3.0,
> we see this:
> 	80 bytes read
> 	80 bytes read
> 	80 bytes read
> 	0 bytes read
> 	0 bytes read
> 	0 bytes read
>	...
> Jeff Percival (jwp at larry.sal.wisc.edu)

Generally, most tape drivers I've dealt with, require you to close(2)
the tape device, then re-open it.  Closing the device (on the no-rewind
device) causes the tape to advance past the next EOF mark.  When you
re-open the device, the next read you do will start at the next "file"
on the tape.

Attempting to read(2) past the EOF mark continues to generate "0" byte
reads, as it should.

What you probably want to do is:
	open(no-rewind-tape); read(); read(); read(); close();
	open(no-rewind-tape); while(read() != 0){ ... }
	close();

Perhaps DEC changed the way the tape driver works for different type
machines (tape drives?)?

John Buck
john at polyof.poly.edu