E3537 Failed to connect to media

[JakeCutter]

Hi,

I'm running ARCserve2000 SP4 on a W2K Server in a SAN configuration. My tape library is a Compaq ESL9198DLX, and the system is running the latest device firmware.

For some time now, I've been seeing the error

E3537 Failed to connect to media(Media=MONDAY, EC=196)

Each tape that encounters the problem is returned to its slot as an unreadable media, yet if I re-inventory the library (a 3-hour job) the media shows up as it's supposed to.

The first job run following an inventory works, any subsequent jobs seem to have a problem.

I'm running the database utilities, but it's not showing any errors yet.

Has anyone seen this problem before?

I'd appreciate any advice.

Thanks.

Jake Cutter
IT Operations: Always outnumbered, always outgunned...

 

[databasebaba]

Do the Following:-
1. Stop All the Engines.
2. Close the Arcserve Manager screen on your Desktop.
3. Then go to the Registry on the Arcserve Box.
4. Type Regedt32
5. Goto Hkey Local Machine \ Software \Computer Associates \ArcserveIT \Base \ Tape Engine.
6. Delete the Entire Tape engine Key.
7. Switch off the Tape Drive.
8. RESTART THE SYSTEM.
9. Switch on the system and the tape drive together.

DatabaseBaba...

 

[JakeCutter]

Thanks,

I'll give it a go this evening and see how we get on. Why am I deleting the registry key? Is it somehow corrupt or something?

Jake

Jake Cutter
IT Operations: Always outnumbered, always outgunned...

 

[mohamdr]

Hi
1-Is this problem happen on SAN primary server & distributed?
2-Apply the latest tape Engine update from CA support site
on SAN primary server and distributed servers
3- if this problem happen on distributed I think you have problem
with the comunication between primary server & distributed.

regards,
mohamdr

 

[JakeCutter]

Mohamdr,

Thanks. I haven't noticed this problem on distributed servers because I don't run jobs from them, so I haven't checked.

However, jobs run from the primary work, so I would have thought that comms between servers are OK.

I've tried databasebaba's advice and so far, everything's working out fine.

As it's 0025IST (Irish Summer Time) where I am, I'm going to wait overnight for further results.

I'll post again in the morning...

Thanks again for the input,

Jake

Jake Cutter
IT Operations: Always outnumbered, always outgunned...

 

[xenotec]

If you are running on a Compaq/HP System you may need to disable the Compaq/HP Storage Agents..
1 - Go into the Control Panel and launch the HP or Compaq Management Agents
2 - On the Services Tab find SCSI Information and remove it from Active Agents
3 - When you click OK it will ask if you want to restart the Management Agents, Say “Yes”

NOTE:This is a temporary fix and I advise you to check with HP for a more permanent fix. Also note that they you are losing visibility to the storage hardware for pre-failure warranty

Disable the Compaq Surveyor Service
Ensure that the device drivers for the Units inside the library are not loaded or active.

 

[JakeCutter]

So here's what's happening:

I've followed databasebaba's advice and removed the Registry Key as specified, restarting tape library and system.

And while my first backup completed, the second job failed.

E3537 seems to have gone, but has been replaced by E1307:

Unable to get Device Group Status (DEVGROUP=DGROUP1, EC=3221225477)

My library is configured as DGROUP0, I don't have a DGROUP1.

I've checked out my other 3 SAN clients, but haven't found a DGROUP1, although one client sees the tape resources as GROUP1. Is this significant?

Should I recreate my groups on the Primary or all clients, and should the groups have the same label?

Thanks in advance,

Jake

PS - Mohamdr - I installed CA's latest device patch before the restart yesterday. I should have said in my earlier reply.

PPS - Xenotec - Thanks, I'll talk to our HP Resident Engineer about disabling agents, etc...


Jake Cutter
IT Operations: Always outnumbered, always outgunned...

 

[JakeCutter]

Okay, I've worked out the E1307 problem.

CA's site has an article that applies to V6.5, and the fix seems to work for later versions. Apparently you need to stop your engines, remove the 00000001.QSD folder, then restart the engines.

A new folder will be created and you'll have to resubmit jobs, but the error, which appears every 10 seconds, should be cleared. I've been monitoring my activity log for 20 minutes now and no sign of it.

I'm re-inventorying my tapes again and then I'll run a test and post results.

I might actually get some sleep tonight...

Jake

Jake Cutter
IT Operations: Always outnumbered, always outgunned...

 

[JakeCutter]

Guess I spoke too soon...

Error 1307 resumed following the first backup job, preventing the second from running. The first backup seems fine, with no messages out of the ordinary.

I'd reapply CA's solution, but I imagine I'd have to continue doing it each day.

If anyone has any ideas, I'd appreciate it...

Jake

Jake Cutter
IT Operations: Always outnumbered, always outgunned...

 

[JakeCutter]

Okay, E1307 is gone.

The solution was to reboot one of the distributed servers that had lost sight of the tape library.

I ran a test - all went well.

Until the scheduled backup ran, failing on E6300/E3714. I put the tape engine into debug mode and ran it again, but there was nothing in the log to suggest why it failed.

I'm going to have my HP engineer take a look at it tomorrow and see what turns up...

I'm also investing in coffee futures, seeing how I'm drinking so damn much of it

Watch this space...

Jake

Jake Cutter
IT Operations: Always outnumbered, always outgunned...