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

[George Robbins]

In article <190 at larry.sal.wisc.edu> jwp at larry.sal.wisc.edu.UUCP (Jeffrey W Percival) writes:
> In article <6975 at cbmvax.UUCP> grr at cbmvax.UUCP (George Robbins) writes:
> >	No, the bug is most likely that the Ultrix driver *is* playing
> >	the sticky EOF game.  If the program closed/opened the input file
> >	it would probably work fine, though the man pages imply this is
> >	not necessary.
> 
> Just a reminder:  in my original posting I pointed out that we observe
> *two* behaviors here:  the documented one AND the "sticky EOF" one.
> Ultrix 3.0 and 2.2 on a VS2000 worked as TFM says, but the Ultrix 3.0
> on two MVII's had a sticky EOF.
...
> So the phrase "THE Ultrix driver" is not useful.
>1. DEC has created both behaviors.  Is one acknowledged by them to be an error?
>2. If one is an error, which one?
>3. Is a fix in the works?

You haven't provided enough information to determine how the problem factors
across the different machines and operating systems.  Also, without knowing
the program, one can't tell if stdio is involved or just read/write and
whether one of the systems might have had some "System V environment"
conditions set either when the program was compile or run.  Is the Ultrix
workstation stuff still separate from the regular stuff?  If so then it's
3.0 apples and 3.0 oranges anyway.  Is the TK50 on one system attached
thru a differnt controller (i.e. different driver) on the VS2000 than
on the other systems?  SCSI vs. Q-bus, no?

If you want the program to work reliably across the universe of BSD and
System V systems, then you have to do the close/reopen when you get an
EOF indication, consequently requiring that you specify the no-rewind
magtape name.

The sticky EOF is certainly irriating, and in this case seems to disagree
with what the documentation says, though it seems the documentation was
incomplete with respect to writing EOF's.  Right or wrong?  Depends on
which background you're coming from.

I don't know about a fix, have you made an attempt to contact software
suport?  Inconsistant behaviour is as much as "bug" as right or wrong.

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr at uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)