greg@cstowe.csoft.co.nz (Greg) (05/05/88)
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@csoft.co.nz New Zealand. Phone (063)-65955