RS/6000 Tape questions

[Ruth Milner]

In article <709 at curly.appmag.com> pa at curly.UUCP (Pierre Asselin) writes:
>In article <1991Apr30.201002.24679 at nmt.edu>
>rmilner at zia.aoc.nrao.edu (Ruth Milner) writes:
>> Also, this doesn't explain why the IBM can't append to its own tapes.
>> If it is truly a restriction in the hardware, then it is a restriction
>> that IBM has added, not one that Exabyte put in. This *severely*
>> restricts the usefulness of the drive.
>
>I pulled the following from IBMLink (APAR IX18487).  I didn't try it
>myself.  Hope it helps.  Does it do any good with the Sun?
[ code deleted]

This is no doubt a useful workaround at the command-line level, but from 
within an application, it is completely impractical to say "if this is an IBM,
do an extra read before writing the real data". It can't be considered a
real solution - especially since you might be running on a Sun at the time.
There is no way to know what system wrote the tape originally.

As stated before, the Sun has *no problems whatsoever* appending after
existing data, *unless* that data was written by the RS/6000. I.e., this
"hardware restriction" does not apply to generic Exabyte drives. And whatever 
causes the problem appears to be something the IBM writes, because it goes 
with the tape. (But it isn't the tape itself, because you can overwrite it on 
the Sun and go back and it will append again). It may be possible to read
past it, but the point is to *fix* the problem.

It is totally absurd not to be able to skip to the end of a file and start 
writing a new one. It is a basic function in a tape drive. Even when tapes 
only held 150MB, it was important to be able to write files at different 
times, to make use of the full capacity. It is absolutely *vital* when a
tape can hold 2GB.
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                    Socorro NM
Computing Division Head      rmilner at zia.aoc.nrao.edu