Cpio on the NCR Tower 32/600

[Greg]

A while ago i posted an article about cpio on the NCR Tower 32 series stuffing
up on multiple volume tapes. We got various replies, including from NCR (yah,
we may have problems getting answers from NCR NZ at times, but NCR US seems
to listen - the net link has paid for itself already).

Reply -
NCR said check the versions, because as far as they new, there were
no problems.  Our version turned out to be 3.8. However, at that time, we
received a 32/400 for a customer, installed the O.S. and discovered that
the version of cpio was 3.10, which did handle multiple volumes correctly.
It seems the 1.03.02 update has the new frec.Problem solved.

We had one reply suggesting a dd script with block numbers which we could
pump data into which would prompt us to change tapes.  However our guru
said that reading from pipes is a bit tricky, as a read off a pipe will
give the calling process all the data that is available NOW - and dd thinks
that it has all the data (ie it gets a read(...) == 0 and thinks it has an
EOF).
 

We had other replies suggesting other backup utilities, but I haven't had time
to check them out yet.

Thanx for all the help.

Other tape problems -

We have been having some strange problems with frec when it gets to the
time to change tapes.  We thought we were having hardware problems as our
friendly local engineer (no arguments with him about software vs hardware -
YAY TEAM) replaced our drive and the problems went away. Then it happened
again, and again. After much experimentation, we found a 1632 would read
the tapes, so we replaced the 68020 version of frec with an 68000 version.
This fixed it! Interestingly enough the engineer told us that rework had
found nothing wrong with the original drives.

A \fIwhat\fR on the 68010 frec gave us

	frec.c	3.6  Compiled: 15:59:48 6/4/86  Delta Date: 15:58:07 6/4/86

and on the 68020 frec :

	frec.c	3.6  Compiled: 11:13:32 8/3/87  Delta Date: 11:33:34 2/16/87

We conclude that something is wrong with either the kernel or the libraries
used during compilation. Of course the flakiness makes it incredibly hard
to pin down.

 ---

The 'dd if=/dev/rstp/0nn bs=100k | cpio -ivc' has some problems. The device
/dev/rstp/0nn should not rewind the streaming tape, and does not in the case
of 'dd if=/dev/rstp/0nn bs=100k of=/dev/null'. However when piping to cpio, the
tape is rewound. This must be some sort of bug with cpio (I presume). Our guru
guesses dd must be getting a broken pipe signal, and thinks it has an error
- causing a rewind.

Anyway, these are annoying, but survivable. However, beware of them. They
can waste a fair amount of time for the uninitiated. I'm sure NCR will look
at these when they this note, but if you have been having funnies, these
may explain a few things.

Rubbish at end of posting :
Disclaimer - The random seed to generate this posting is 2345957475747260003873.

-- 

Greg Calkin                                   Commercial Software N.Z. Limited,
...!uunet!vuwcomp!dsiramd!pnamd!cstowe!greg   PO Box 4030 Palmerston North,
or greg at csoft.co.nz                           New Zealand.    Phone (063)-65955