I was going to post this as a reply but thought a new topic is in order.
(James/Leslie and all other who support this forum should be aware of major
flame warning here).
I read the response about languages used in NetView (like why is there more
than one?). I cannot agree more with this post. I too am an old Mainframe
Netview and OS/2 user. Rexx is a great language. Um, Java is a great
language. Well, TCL is a great langugage hm.... seem to be having an issue
here....
This again falls into the "rant" category, but NetView - as a whole - has
been horribly "integrated" if you can call it that. Language preference is
one example, but there are many more. Like, did you ever wonder why the web
client uses a different directory, different compiler (with different rules)
for its mibs? Why can't you add MIB applications to the web client just as
you add them to the Native GUI? (you need yet another language XML). And why
hasn't that native GUI had any end-user enhancements since before I was
born. You know, things like using the shift key for multiple selections
(rather than the CTRL key) or a sizing grid for icons, accelerator keys for
commonly used functions (the way CTRL-L works) I know that the "Microsoft
Windows-esque" interface wasn't around when the NetView GUI was established,
but that doesn't mean it should get left alone for years. We've all come to
expect certain consistent features in GUIs by now.
I know the answer. I know its "development" effort. Why go back and add
functionality to the NetView GUI when the web interface is already built?
(With apologies to the web client coders - "built" being a subjective term
to mean half-assed kludgy junk). Why go back and rewrite a piece of code in
Java that has been running as a shell script for years? I am here to tell
you that Tivoli's "ROI" is not being measured in terms of customers use of
the product. Sure, it would take some time to re-write the TCL stuff in some
other language and that time would NOT equate to more sales. But it would
equate to more people having better understanding of the product because
(surprisingly) I can find a person who knows Java or who knows script
language or who knows PERL or who knows Rexx, but I will be darned if I can
find one person who is knowledgable on all of these. If they are, I can
assure you the last thing they want to work on is NetView.
Another example? How about the fact that the service point application to
talk to OS/390 NetView doesn't run except under AIX. My team supports about
a dozen Solaris Unix servers as part of the network infrastructure of
routers and switches. You think my managememt wants to buy ONE AIX box to
run the service point application? Let alone send one of us to AIX training.
How about the fact that (from what I hear) the Unix and NT versions of
NetView are so radically different you can't even discuss them in the same
conversation. It boils down to - "if it was a good decision to do it on NT
THIS way, then why shouldn't we do it on Unix?" and "If we can't do it that
way on Unix, why are we doing it that way on NT?" The answer is "its too
hard." or "We've never done it that way before."
The comment that gets me the most angry in the work place is when someone
says "Lets not re-invent the wheel here" and that is exactly what the
development staff at Tivoli uses as their approach. We *SHOULD* reinvent the
wheel, its square, the tire is flat and the spokes are broken. Stop bashing
the beleagured support staff and start questioning the fundamental design
concepts that have been chosen. Stop having a product that has so many
single-threaded interdependant programs that comprise a system more
difficult to trouble shoot than the space shuttle challenger and more
difficult to keep running properly than a cluster of NT servers. Heck, stop
coding fixes for netmon crashes and then don't tell me about them until the
next release and hope I never hit that time-bomb you just fixed.
You know, Tivoli chose the motto "the power to manage anything, anywhere".
Tivoli chose to try and be "everything to everyone" and that in itself is a
GREAT (if-over-ambitous) idea. But when you look at that statement, and you
try and retrofit it into the the hodge-podge of applications, configurations
and customizations it becomes immediately unwieldy. My message to the
developers would be "go back to the drawing board and don't come back until
you've reduced the complexity, disparity, and volume of programs and
features. From a functionality point of view, the enhancments are often
excellent But trying to administrate this product can be a nightmare (and
for no good reason other than development time). I mean, even the syntax of
two seemingly similar commands that absolutely do not use the same sort of
nomenclature:
ovtopodump -rl resourcename
nvUtil l resource name
Mixed case on one command, dash in front of operands on the other command.
Its a little thing, but it clearly demonstrates the fact that the guy who
wrote nvUtil had no involvement with the guy who wrote ovtopodump or
ovobjprint. NO consistency in case or syntax. I can't imagine what it looks
like on the NT platform (how do you guys live without the ruleset editor?).
Just take a look in your /usr/OV/log directory. Can you read all the files?
No. Some of those logs are in binary. Do the log entries from various
applications look the same? No, time stamps differ, message formats differ,
terminology differs, event the logging technique (nvaction.alog and
nvaction.blog vs. netmon.trace) differs from application to application
within NetView (nvaction switches from a to b while netmon appends appends
appends). OH yeah, if you want to turn on tracing of netmon automatically
you code "-m-1" in /usr/OV/conf/ovsuf but if you do it from the command line
it is "netmon -M -1".
I am hoping to send a clear message to development that while they have the
"best-of-breed" product, that ain't saying much compared to Uni-center and
OpenView. Good code, good implementation, and emphasis on usability should
be the keys. Maybe tomorrow I'll talk about documentation. Page 427 of the
"Netview v6.01 and Friends" redbook indicates the example in Chapter 8 of
the Installation guide is wrong. Its still wrong in my v6.02 manuals and the
redbook has been out for about 8 months.
If anyone in a management capacity, development capacity or support capacity
wants to discuss any of this with me, please feel free to contact me. I
don't complain without willing to be part of the solution.
Scott Barr
Network Systems Engineer
CSG Systems
402-431-7939
scott_barr@csgsystems.com
-----Original Message-----
From: owner-nv-l@tkg.com [mailto:owner-nv-l@tkg.com]On Behalf Of Bill
Evans
Sent: Monday, August 06, 2001 11:49 AM
To: IBM NetView Discussion
Subject: Re: [NV-L] Filter events by interface
An interesting metadiscussion where an old codger can put in his
perspective. Thanks for the prompt, Oliver, and apologies to all for
jumping on the soapbox.
The specific reason for using BATCH files on NT is simplicity. No worry
about making sure that all the appropriate directories are specified in
the path when executing programs when you have no native environment.
Two reasons I don't use TCL:
1) After 27 "language of the day/year" efforts I gave up. Tivoli can't
make up its corporate mind on the language of choice among REXX,
BASH/KSH, PERL, TCL and JAVA depending on the product and platform in
use. The only Tivoli product using TCL is NetView so it isn't worth the
effort to me. (NetView for OS/390 uses mostly REXX. Framework is
primarily BASH/KSH. PERL is holding the same ecological niche in
Framework and NV-Unix that TCL does in NV-NT. JAVA is the development
language of choice for almost all new IBM/Tivoli work that I've seen.)
2) Most Tivoli Framework support is BASH on NT and Korn Shell on Unix.
It's easier when working with NetView for both NT and Unix to settle on
one language which will work on both platforms. Most things I do these
days are in BASH/KSH.
My "native" language after twenty plus years of using it is the old IBM
Mainframe and OS/2 standby REXX. It also runs on AIX and NT (using the
Regina interpreter) but I haven't located an open source Solaris version
so I only use in in extremis; i.e. I can't get something to work in
BATCH or BASH. It's a nice language too.
To be honest, TCL appears to be a nice language and so does PERL. The
use of TCL in NetView is quite minor. There are 57 class LIBRARIES and
well over 500 classes for Java in NetView and only 40 TCL scripts. It
makes me wonder why they bothered with the overhead of shipping and
maintaining TCL regardless of how nice it is. It also puts a wet blanket
on any enthusiasm I might work up for learning to write TCL or PERL.
Oliver Bruchhaeuser wrote:
> Why not using "tcl" !
>
> It's a really nice scripting language.
> And the interpreter is NetView NT "on board" because NetView is using it
> itself.
>
--
Bill Evans -- Consultant in Enterprise Systems Management
reply-to: wvevans@prodigy.net (or Bill_Evans@sra.com)
Phone: 919-696-7513
Send short text messages to 9196967513@messaging.sprintpcs.com
_________________________________________________________________________
|