Re: Too Many UMAs (60 Views)
Reply
Honored Contributor
Mike McKinlay
Posts: 565
Registered: ‎03-17-1999
Message 1 of 4 (60 Views)

Too Many UMAs

Every night, OB starts up a process that connects the backup device (StorageTek silo) via SCSI on a secondary system (not the OB system itself). The backups are working okay, but the uma is not dying at the end of the process. As a result, we have UMAs running from several days ago.

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 ...

Thanks,
Mike
"Hope springs eternal."
Honored Contributor
Albert E. Whale, CISSP
Posts: 988
Registered: ‎04-24-2000
Message 2 of 4 (60 Views)

Re: Too Many UMAs

Mike,

It sounds to me like you might need the latest OmniBack Patch. Are you current with your Patches?

Sr. Systems Consultant @ ABS Computer Technology, Inc. http://www.abs-comptech.com/aewhale.html & http://www.ancegroup.com
Honored Contributor
Mike McKinlay
Posts: 565
Registered: ‎03-17-1999
Message 3 of 4 (60 Views)

Re: Too Many UMAs

I'm at PHSS_19939 on the CS (not 20084), and PHSS_18681 (not 21334) but there didn't seem to be anything related in the patch descriptions to our particular problem. Otherwise the patches look pretty current.
"Hope springs eternal."
Trusted Contributor
alberto vasquez
Posts: 119
Registered: ‎05-08-2000
Message 4 of 4 (60 Views)

Re: Too Many UMAs

Look for something non-standard - like the use of an alternate shell for ROOT, or perhaps name resolution problems.

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..

stat
bye

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...

Good luck.

-Joseph T. Wyckoff
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.