On Wed, 3 May 2000, I wrote:
> I just went through the installation of Compaq Analyze on our DS-20,
> (for those not familiar with this package, it replaces Dec_Event (dia)
> which replaced uerf. Neither of the predecessors are able to read the
> binary error log file on the DS-10, DS-20, ES-40, and other newer Alpha
> systems.)
I've received about a dozen replies, all of which indicate agreement
that Dec_Event and UERF were better products than Compaq Analyze. I'm
going to quote some of the replies here, but since I haven't asked any
of the authors for permission to quote their text, I'm doing so without
identifying who wrote what:
The first reply I got started with:
"I agree with everything you say about CA. ... You've said
it much better than I."
One really good lead I got from the person who wrote that was to contact
Compaq directly. I ended up in a telephone and email exchange (which I
don't believe is fully closed yet) with Dan Watt, the product manager
for Compaq Analyze. Not surprisingly Mr. Watt informs me that the older
products simply can't handle the log data from the new hardware (so
produce new versions that can???). He does confirm that new versions of
Dec_Event can read logs from the 8400 series of new machines, but for
the DS10, DS20, DS20e, ES40, (and a few other models which I can't
remember) he states that Compaq Analyze is the only available solution.
One person wrote, in response to my question of "does anyone know of a
better alternative than Compaq Analyze?", "Alpha Linux".
I know that was probably stated more lightly than seriously, but to be
honest, if Alpha Linux could provide me with AdvFS and the hardware
error logging that DEC^H^H^HCompaq Unix does, it would certainly be
considered an option.
Another useful message I received contained the following:
> Compaq Analyze is the most wasteful piece of software I've seen
> in some time. It sucks up tons of memory, and I suspect that it
> is loaded with security flaws so I keep it completely disabled
> until I need to look at the error log. Also BEWARE: it defaults
> to writing it's logs on the /usr partition, rather than /var (just
> plain dumb).
Folks that are using Compaq Analyze should certainly watch out. This
person is right about the bloat also. This is a *large* package (well,
Webes is, but ca requires that to run), and it's not at all clear how
much care has been taken in its creation. I would certainly consider it
good advice to run the "director" (desta) process only when it's needed.
The same author continues:
> Incidentally, that text input box wants you to input the system
> serial number. You only need to do it once, and then the text
> interface should work. But you must have 'desta' running, even
> for the text interface.
Another message reads:
> BTW, DecEvent *will* run on a DS20, well enough to read the message
> headers and return basic error codes; it just can't decipher the
> event details. I still use it in the crontab on our DS20. If any
> errors occur, *then* I use ca to get the rest of the information.
I also received a note from someone that there was a Dec_Event-3.2 which
works with the new machines, and a post was made to the list indicating
that Dec_Event-3.1 does. I suspect that 3.2 was a typo, as I could not
find that version. If it *wasn't* a typo, somebody please tell me where
I can get that version.
Dec_Event-3.1 *does* seem to *mostly* work on my system (a dual processor
DS20). However, it reports that a particular entry has an "invalid event
header type", and reports only on events that occurred before that one
(I'm assuming). I suspect that the event in question was generated by
hardware that isn't known to this version of Dec_Event.
One message that made me feel a little bit better read:
> Don't feel all alone...they hosed the OpenVMS version of this utility
> just as badly!
Another:
> I entirely agree with everything you have said here.
> I simply gave up after my first attempt to use ca.
> Way too much stuff between me and the problem.
That person continued:
> Curiously, uerf still more-or-less works for me
> (ES40/TU5/PK1 and DS20/TU4.7F)
Definitely on my DS20 with DU4.0e, uerf doesn't produce anything even
remotely useful. :-(
> Maybe if Compaq published the format of binary.errorlog
> we could do our own thing...
That's wishful thinking, I'm sure, but it *is* a nice thought!
Another wrote:
> It seems to me you have spent some fruitless hours of trying to
> implement Compaq Analyze. I just wanted to say thanks for a splendid
> analysis. I am sure I won't be using it for some time until someone
> comes up with some heavy reasons why we should. Is this WEBES v2.1 ?
Yes, I believe that's the version (WEBES_U210_BL13).
> Also, it seems to me that this is a Compaq product, not a 'Digital' one
> because undocumented use of ports etc. was a rare problem in the DEC
> days.
That may be the case, but I still remember "dop" ... :-(
One person wrote:
> I agree. As of yet (Its entirely possible that I may be trying to
> use it incorrectly) I think CA is the worst 'new version' product
> replacement yet. I've never seen a product with such a large set of
> 'features', changes, and such a huge install footprint give so little
> real end user value.
>
> If anyone from Compaq feels inclined to port Dec_Event you will have
> a willing, happy, and I guess large audience waiting to use it.
I'm quite sure we all agree, (I know I do).
The same person noted that the serial number asked for in the GUI dialog
box is the machine's serial number, and that this is documented in the
readme file. I must have missed it.
Another person recommended that I try "collect"
(
ftp://gatekeeper.dec.com/pub/DEC/collect/). I had a look at it, and I
can say it certainly looks like a useful product, but not as an
alternative to Dec_Event. Think more like "monitor" on steroids.
Definitely a useful package, though. People should check it out.
I wrote in my original message:
> One thing which caught my eye was installing this added to my inetd.conf
> file (without warning, comment, or any indication that this file was
> being changed!) the following line (wrapped for legibility)
>
> dsn_tunnel stream tcp nowait root
> /usr/bin/DsnTunnelServer.sh DsnTunnelServer.sh
Dan Watt confirmed that this entry could be removed if DSNlink is not
used on the host. I replied to him that I feel that the entry's
*addition* should be optional, not its removal.
> So when a connection to the "dsn_tunnel" port, (non-existent in my
> services file -- the installation seems to have missed that) is made,
> the DsnTunnelServer is run as root. It sure would be nice to know what
> this thing does, and it would be even nicer to have been forewarned
> about that change so the "TunnelServer" can be wrapped with
> tcp_wrappers!
I'm told that "DSNlink's authentication procedures ensure secure
communications between the DSNlink system at your site and the DSNlink
host systems at Compaq Customer Support Centers." I was also told that
DSNlink works over encrypted sessions (though no details were given). If
these are true, and both the authentication and encryption are good and
strong, it's probably less of a concern. I don't use DSNlink on my
systems at all, though, so for me it's not really a problem, though I
still object to the installation adding to my inetd.conf without
warning.
> Furthermore, the WEBES involves a "director" process, which itself sets
> up TCP connections on ports 7901, 7902, 7903, and 7904. Are the uses of
> these ports documented anywhere?
I'm told that the port numbers used can be changed (documented in
chapter 7 of the Compaq Analyze V2.1 Users Guide) "and additional
modifications are planned to the tool in future releases to limit
visibility from non-sanctioned systems."
Of course that doesn't help make the *current* version usable.
> I think this is a real shame. We have a machine-room nearly full of
> DEC/Compaq equipment, and are periodically buying new machines. That
> means we're ultimately going to run out of systems where we can use
> Dec_Event effectively, and I'd certainly prefer not to use the only
> alternative. :-(
I'm told that the new product was developped based on input from users.
Alright, who here asked for a point-n-clicky, doesn't scale to large
numbers of hosts, graphical Dec_Event???
> Does anyone know the "ca" equivalent to the following:
>
> dia -R -o summary -t s:${YESTERDAY} e:${YESTERDAY} \
> -x software_informationals > ${TEMPDIR}/dia.out 2>&1
Dan Watt suggested (using appropriate dates, of course):
ca trans filename.ext filter "dtb=30-jul-1998 & dte=01-aug-1998 &
sort=revtime" outtext trans.txt
I haven't tried that command yet, but I certainly will. He states that
"The software_informationals are automatically filtered out." This may
at least provide the information I'm looking for.
Thanks to all who replied. I'm still hoping Compaq will come up with
something better... :-(
--
----------------------------------------------------------------------
Sylvain Robitaille syl_at_alcor.concordia.ca
Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Received on Thu May 11 2000 - 18:38:33 NZST