24-Jul-2009

Error analysis

I might be repeating what Hoff said on this subject, but I was just asked about it yesterday, and as I have just been through re-installing WEBES, I thought I'd have a bit of a rant about error analysis tools for OpenVMS.

<rant>

Why can't HP come up with one tool that does error analysis on OpenVMS properly? Let's step through some issues.

WEBES installs using a menu driven command procedure. As far as I know, this is the only tool supplied by HP for OpenVMS that isn't encompassed in either a VMSINSTAL-type kit or a PCSI kit. Sure, it uses PCSI for the components, but why does it deviate from the two accepted standards for installing software on OpenVMS?

Because of the amount of confusion surrounding installation (and deinstallation/reinstallation) of the WEBES tool, we need a special cleanup utility to remove old versions. Could it be that older versions of this product were released for OpenVMS without a proper uninstall procedure? And once you download the tool, which happens to be in a completely raw command procedure, you find that it fails to run with a bunch of DCL errors. For the complete novice, this would be rather disconcerting. The problem turns out to be simple: remove the trailing carriage return on each line of the command procedure. But what does this say about quality control and testing? The file was obviously edited on a non-OpenVMS system, and then just dropped on the net without checking that it downloads properly and executes on OpenVMS. Come on guys, at least use something simple like ZIP for OpenVMS.

WEBES (and specifically WSEA, the error analysis tool) has problems decoding errors on my old AlphaServer 800 running OpenVMS 8.2, while DECevent has no issues. Obviously this is due to the age of the AlphaServer I have, but can we have one tool that encompasses all possible errors on all platforms (or at least the ones that occur all the time, like asynchronous device attention events from ethernet adapters, for deity's sake)? Surely the ruleset should be cumlative, rather than dropping support for old systems? HP may no longer want to support these systems, but I own one, and I sure do.

You can tell that OpenVMS Engineering thought that WEBES sucked. They resurrected ANALYSE/ERROR and added a new qualifier called /ELV, standing for "Error Log Viewer". At least this can decode most core errors. But of course it can't decode everything (do we see a similar pattern here?) so newer hardware forces you to use a combination of tools.

All in all, not a very consistent product lineup. Come on HP, you can do better than this.

</rant>

Posted at July 24, 2009 7:47 AM
Tag Set:
Comments

I can but agree with you, having to support a range of systems. For each it's - I see a device error, which tool is going to work on this system?
Did I remember to install them all just in case?

Posted by: Ian at July 24, 2009 8:10 PM

I've tried WEBES once and have removed it as soon as I could. It's hostile on small systems, I found it took over 1GB (!) of virtual memory, most of which is paged back and forth: WEBES seems to be a Java application and the garbage collector keeps the system busy with it's management tasks - where my system is supposed to de USEFUL things.

Get it off the system requires changing the startup database, as I found out.

I can understand that HP prefers a once-written-run-anywhere solution, and it's feasable if you have BIG iron. But small systems seem not to exist, in HP's minds :(

Even worse: DECEvent seems to be phased out - so there is no alternative.

Posted by: SYSMGR at July 26, 2009 8:38 AM

Update: Dispite the "Feedback" link at the bottom of the WEBES page being broken, I have reported the problem with the cleanup utility to HP. Let's hope they fix it.

Posted by: Jim Duff at July 27, 2009 10:26 AM

Comments are closed