I have two NCR platforms that are almost two peas in a pod. One is a model 3450 (call it P2); the other a 3455 (P3), and each supports two Sybase System 10 data servers and one backup server. While logical architectures differ from daily usage, they were set up to be parallel, and no conscious differences were instituted.
When beginning an upgrade of SQL Backtrack from Datatools, I have not been able to tar the files to P2. The install notes specify a non rewinding tape device and to mt rewind, mt fsf to the correct file, and tar the files to disk. Results...
/usr/ucb/mt -f /dev/rmt/c0t0d0s0nn rewind -- seemed to work ok if maybe a bit to quickly.
/usr/ucb/mt -f /dev/rmt/c0t0d0s0nn fsf 5 -- reported *no data found* the first time around.
tar -xvf /dev/rmt/c0t0d0s0nn -- reported *Tape blocksize error*
The tar results were the same for two other tapes, and mt fsf seemed to work on one of them.
In the first attempts I may have su'd to root, but in the last attempts it was from a root *login*. All commands have been executed from the console.
The device is routinely used for database dumps and restores, and a simple tar *to* the tape was normal.
I received a tape verified for an NCR machine by the Datatools people, and it also failed on the tar. So I charged off in another direction to tar it to *P3* and copy the files over to *P2*. It complained about problems not being able to read the group entry in /etc/group, but it worked, reporting a blocksize = 20.
There are some other issues to deal with on the rcp and NFS options yet, so I'm back to the tar issue for P2.
What's do I need to do to get my tar to work?