c3703 cannot connect to media 1

[monjul]

I'm getting intermittent errors on our Boston box using Arc 2000 on an 8-slot HP VS80 drive. We cleaned the heads last week and the problem occured Friday night. Does it sound the write head might be going? Thanks

 

[davidmichel]

Usually at the end of the message is an EC=xxxx.
The EC is an error code that will provide more infomration on the nature of the failure. Copy that portion of the activity log into the notes so we can see.

 

[monjul]

Here's another weird thing. It's an erased tape but but after the C3703 error it says Media=10-29-03. It never even formatted the tape. (BTW, I deleted the job last week along with the .asx file and rebuilt the job). Today I manually forced the full to run, as a test after it failed over the weekend, and it formatted with todays date correctly and began to backup data. Unfortunately I can't cut and paste using remote software. I'm in Philly, the server's in Boston but the EC=Bad Device Handle. What does that mean? Thanks.

 

[davidmichel]

Side Note: the logs are just text files and can always be acessed remotly outside of the application as you would any file on that server. The logs are found in the log subdirectory.

Bad Device Handle points to the Tape Engine but does not tell us very much. A tape log of the problem would tell us a lot more, but that is a lot more work especially since it is intermitent. So lets start with the more common and easier. Make sure there are no conflicting applications such as the OS Tape Device drivers, Removable Storage Service, or any other service or driver that is suspected of accessing the tape driver and/or library.

 

[monjul]

The NT driver is not loaded and since this is a BDC, it really has no apps on it that might try to access the tape drive.

 

[davidmichel]

Well a tape log of the error should provide the data to determine the cause. Turn debug on for both the Tape and Job Engines, see faq478-3964 and faq478-4383 for details.

Each day check the activity log to see if the error happened. If it did not happen delete the tape log since it grows very large. If it did happen disable debug and then cross reference the point in time of the failure from the arcserve.log to the tape log and lets see what happens.

 

[monjul]

Yes, I enabled debug yesterday but a full backup ran clean last night and you're right, the log file is huge. I will keep an eye on it and report back what the log indicates in the event of a failure. Thanks for your support David.