Certainly do watch the SMART data (as there are some data points that do tend to predict failure), but do keep your data archives or recovery strategies current.
There are standards for all sorts of things to do with SCSI, too. Some of which sort-of match reality. (The best part of working with storage standards is that there are so many to choose from.)
The quote from Smart Reseller magazine over at that cited web site aside, the SMART monitoring (for disks) has been found to detect and report only a surprisingly small fraction of disk device failures. Prior to catastrophic failure, that is. SMART simply isn't a reliable predictor of failure, based on some large-scale empirical studies from folks at CMU and Google.
As for tools, here's some open source that might well be (reasonably) portable:
http://sourceforge.net/projects/smartmontools/The ioctl() code that's very likely included (I haven't looked at the source code) would need to be switched over to IO$_DIAGNOSE calls to send the SCSI command packets, etc.
With OpenVMS and the specific device timeout case, that's already a failure somewhere in the chain. SMART and related tools likely won't help all that much. HP SIM / HP SEA / WBEM+WEBES / whateverthisstuffiscallednow might be worth a look. But I'd start swapping some SCSI parts here first, and see if or where the bug moved to. That's simpler.
