07-03-2000 11:48 AM
I can certainly kill the process with no apparent ill-effects, but what I'd like to understand is why the uma process continues to run in the first place. What is it waiting for that it doesn't get? Again, the backups seem to be running just fine ...
07-03-2000 12:04 PM
It sounds to me like you might need the latest OmniBack Patch. Are you current with your Patches?
07-03-2000 01:15 PM
07-05-2000 03:45 PM
From the command prompt of the machine in question can you start and stop UMA without any problems?
./uma -ioctl /dev/robotic
--replace /dev/robotic with the path for your scsi changer file..
Try starting and stopping it several times - look for delays...
Remember that applying the patches to the cell server isn't the whole story...the patch also must be pushed from the cell server (or depot server) out to where the (MEDIA) agent is installed...it is easy to forget this step - so try re-pushing the media agent.
Is this a new symptom after patching or upgrades? Try and identify what changed.
On some systems we can have problems with the automatically installed SCHGR (/dev/rac/...) drivers - consider using SCTL (or SPT -depending on the hardware configuration...)
Look in /var/opt/omni/log/debug.log for hints as to what might have glitched.
Is this a SAN/storage area network?- you have to be careful configuring these.
Do you have one tape library defined multiple times within Omniback? Be sure and use LOCK NAMES and configure things carefully.
Is it a supported tape drive or library? Has firmware changed? If you upgraded - is it STILL supported?
As always - watch for Omniback patches...
-Joseph T. Wyckoff