Lucy -

Not every answer is tailored to your situation personally.    People assume
that you share many of the same assumptions they do.

Let me see if I can net it out for you.

(1) NetView  V5 introduced the use of the Tivoli Framework to assist in
Installation and Configuration.  It had to, because there was nothing like
SMIT on Solaris or DEC, and they had to have one common user interface
across those platforms and to also provide integration with other Tivoli
products.  So the Framework is now the preferred method for Config changes.
But all the old SMIT stuff is still there and still works on AIX.  But it
will not be enhanced.  And you cannot use it to install maintenance any
more.  But parts of it still work fine.

(2) If your Framework is broken, then you cannot use it to perform config
changes or apply maintenance, so sooner or later you MUST get it fixed.
Your cloned NetView is at risk in the long term if you do not.   So the
sooner you fix it, the  better.  Your summation of the suggested fix
procedure is correct.

The alternative is to wipe the whole mess out on the cloned box and start
over.   You would install the Framework and the Framework patches just as
you did on the first one, but before you install NetView, make a migration
backup of the first one and move the migration directory over to the new
box.  Then when you install NetView, the installation procedure will find
the migration files and merge them.  End result -- two boxes, different
Frameworks, identical NetViews.  Then you can copy the databases over as
often as you like.  This procedure has been discussed here many times, but
if you don't understand it, just ask.

(3) Forwarding traps from one NetView to another is a matter of customizing
trapd and trapd.conf.  You can do that in a variety of ways on AIX.  You
can use the Framework, the new preferred method.  You can still use SMIT
for now.  Or you could do it manually, using documented commands.    But
the Framework or SMIT are just a means to an end, namely, changing trapd's
operating parms.   You could just edit the ovsuf file, but I don't
recommend that alone, because then you have no backup for it, as you do if
you change the lrf files and do ovdelobj/ovaddobj.  Do you follow me here?


Hope this helps

James Shanks
Tivoli (NetView for UNIX) L3 Support



Lucy Premus <lpremus AT METLIFE DOT COM> on 06/15/99 01:31:56 PM

Please respond to Discussion of IBM NetView and POLYCENTER Manager on
      NetView <NV-L AT UCSBVM.UCSB DOT EDU>

To:   NV-L AT UCSBVM.UCSB DOT EDU
cc:    (bcc: James Shanks/Tivoli Systems)
Subject:  Re: Forwarding events/traps from one NetView to another





Ok.  Now I'm completely confused.  I'm not sure if you had seen my note
last
week regarding our problem with TME Framework.  We have 2 NetView systems
in our
environment (axscnv1 and axscnv2).  The axscnv2 system was cloned from
axscnv1.
Because of this TME desktop was hosed on axscnv2 because all of its
database
pointers are referencing axscnv1.  I had received several responses back as
to
how this needs to be cleaned up.  Basically, its done by de-installing and
re-installing Framework and then running a script to fake out Framework
into
thinking your re-installing NetView , but you're really not.  As a result,
the
Frameworks pointers are all updated correctly.

In any event, regardless of that issue.  If its still possible to configure
event forwarding to TEC, via smit, then I don't need to be concerned with
the
problem between Framework and NetView right?  I know I have to get the
Framework/NetView stuff fixed because NetView release upgrades and patches
need
to be installed via Framework, but do I need to be concerned just to
configure
event forwarding to TEC?