First off, (depending on the type of your tape drive) you have a pretty good chance of not needing any compress at all because most of the IBM tape drives have a hardware compression built in. If you send a compressed stream down to the tape drive it will be compressed a second time which will usually make the file a little bigger (because of the second compression overhead adding), not smaller.
Second, even if it is justified to use "compress" in your case, you probably have to add "if=-" to the "dd" command. AFAIK "dd" doesn't use stdin per default for incoming data. It also might be necessary to state the blocksize. Use "bs=<some number>" in this case to state the block size in bytes.
A third reason might be that you have to adress the tape drive with another device number, maybe "/dev/rmt0.1". Have a look in the manual for the meaning of the minor device numbers with tape drives.
I do not recognize your first statement "change tape block_size=512", usually this is accomplished using the "tctl" command, alternatively use the "chdev" command on "/dev/rmtn".
I know the client's tape drive are using built in compression. But the problem is that is taking toooo looonnnggggg. Backing up a 10Gb folder's content takes 5 hours. The procedures we use to do the backups (10 database backups between averaging 8Gb spreaded amongst 5 servers with each only one tape drive) have us verify the tapes after we have done the TAR backups. Do do all of this takes 18 hours ! I want to reduce this time as much as possible with 2 ways where one way is using compression before putting on tapes. Using local compression on disk takes 2 hours per DB backups. That is why I was trying to compress to tape using piping.
I'll check the if=- and bs= options.
As for the "/dev/rmt0.1", its probably it. I have seen this in other backups types we do.
The blocksize change command was just a summary of what I did before doing the DD. It is actualy a chdev.
sometimes the backup problem may be coz of the device driver. If proper device driver is not installed then it might cause the problem I have faced it many times.
please check Driver and firmware that might help.
I have no ideas on how to do that. I am only a very basic operator. Our system admin is not a real system admin (lack of knowledge and lack of practic).
This client's system is old and over 20 years old (AIX 4.2).
I assume you want to avoid taxing the file system, right? Colleague shockneck told me that in v5 onwards stdin is the default for dd - i remember vaguely that this was different in 4.x, but you could try. Even if it doesn't work you might create a fifo and pipe it through this pseudofile.
As far as i remember (its been a while) "-a" was introduced with v5. You find the "classical" way of getting detailed version information in the pinned thread at the top of this forum.
The serial number is only printed on the case and you will have to have physical access to the machine to get it. There is no way to find it via a command in a R/6000 machine.
Still i don't think the serial number is of interest here. What would be interesting is the model number which would be a 4-digit number maybe with a 3-digit extension, probably starting with a 7, like "7026-150" or so. Try "uname -M" to get the model number (i am not sure if this is a 5.x command too, but it is worth a try).