SCU reserve/release device

[Javier García_1]

Hello.

I have a problem without solution.
We have a MSL5052 tape library. This library have a robot "/dev/changer/mc0" and four drives "/dev/ntape/tape11_d1, /dev/ntape/tape12_d1, /dev/ntape/tape13_d1 and /dev/ntape/tape14_d1".

We have two ES40 in a Tru64 Cluster, version 5.1 and many Windows 2000. All these machines use the tape library.

The problem occurs when the Cluster Tru64 is doing the daily backup with the VDUMP command. My script is like this, first i move the control of the tape library to the member who is going to do the copy. Second I reserve the driver that I am going to use. Third I VDUMP the filesets. Fourth I release the driver because anyone can use it after the copy. I use these commands:

/sbin/drdmgr -a server=sc01ud0601 /dev/changer/mc0
scu -f /dev/ntape/tape14_d1 reserve device
/sbin/vdump -0 -Nu -f /dev/ntape/tape14_d1 /cluster/members/member1/boot_partition
/sbin/vdump -0 -Nu -f /dev/ntape/tape14_d1 /cluster/members/member2/boot_partition
...
...
/sbin/vdump -0 -Nu -f /dev/ntape/tape14_d1 /oracle/8i/orasoft
scu -f /dev/ntape/tape14_d1 release device

I don't know wher is the problem because when i see the log of the backup i see this error
vdump: unable to write to device ; [5] I/O error
vdump: unable to prompt input for retry on device; [25] Not a typewriter

This is the log of the VDUMP:

path : /cluster/members/member1/boot_partition
dev/fset : root1_domain#root
type : advfs
advfs id : 0x3c0c8b5f.00045b74.1
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vdump: Dumping 69084752 bytes, 3 directories, 23 files
vdump: Dumping regular files

vdump: Status at Thu Dec 11 22:24:42 2003
vdump: Dumped 69084752 of 69084752 bytes; 100.0% completed
vdump: Dumped 3 of 3 directories; 100.0% completed
vdump: Dumped 23 of 23 files; 100.0% completed
vdump: Dump completed at Thu Dec 11 22:24:42 2003


path : /cluster/members/member2/boot_partition
dev/fset : root2_domain#root
type : advfs
advfs id : 0x30e79943.01078bcc.1
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vdump: Dumping 69089343 bytes, 3 directories, 23 files
vdump: Dumping regular files

vdump: Status at Thu Dec 11 22:24:47 2003
vdump: Dumped 69089343 of 69089343 bytes; 100.0% completed
vdump: Dumped 3 of 3 directories; 100.0% completed
vdump: Dumped 23 of 23 files; 100.0% completed
vdump: Dump completed at Thu Dec 11 22:24:47 2003


path : /oracle/8i/orasoft
dev/fset : orasoft_domain#orasoft
type : advfs
advfs id : 0x30e79bcf.0107cca6.1
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vdump: Dumping 4238913419 bytes, 2598 directories, 46374 files
vdump: Dumping regular files

vdump: unable to write to device ; [5] I/O error
vdump: unable to prompt input for retry on device; [25] Not a typewriter

I don't know what more do and i am going crazy about this.
¿Can somebody help me?

Thanks in advance and i am sorry about my englis

[Ralf Puchner]

I've found a similar case and the problem was solved by checking binary.errlog and fixing hardware issues.

[Mohamed K Ahmed]

The scrippt you have is controlling tape14, but the message is regarding tape13.
This error message comes out if there is a script that wants to access tape13 and there is no tape there or the tape is full.

Check your scripts and also check the error log

HTH
Mohamed

[Javier García_1]

All right, i have a mistake in the post of the error. The only driver i am using is the tape14. I have a mistake when i copy the error to post in the forums.

[Mohamed K Ahmed]

OK,
from your log it looks like you haven't exceeded the size of the tape, unless you have used the tape before and appending your dump to its contents, this might lead to suspect that the tape got full.

Then I think it is one of 2 options, the tape got unloaded so the script didn't find it, or you got an error with the SCSI connections.
My suggestions is try to use a new tape and dump a lot of save sets to it, maybe try to dump /usr directory several times and see if this problem persists. Also check the errorlog file, it will tell you if there was a SCSI CAM bus error or something like that.

HTH
Mohamed