|
Hiya Sue I've not had to upgrade to this version as yet or on Solaris however I do recall many upgrades to 7.1.4 and the main things were as follows: - hotbackups are now achievable. So I arranged for a cronjob each day to backup NetView and ofcourse the housekeeping to keep it all tidy. - alert levels: TEC alert severity is changed down. To retain the normal settings of 7.1.3 one needs to install FP2. This allows you to add a line in the tecint.conf to retain the previous actions and other options also become available. New options for nvserverd in the tecint.conf file (UNIX only) In conjunction with APARs IY56279 and IY60528, three new options have been added to the tecint.conf file on UNIX to control the behaviour of the internal Tivoli Enterprise Console adapter in nvserverd. By default these options are commented out, but the user may uncomment them by removing the pound sign (#) that precedes them in order to alter nvserverd behaviour as described below. A new man page for tecint.conf has been provided to document these options. NvserverdTraceTecEvents=Yes When set to 'Yes' or "YES', this flag causes nvserverd to create the /usr/OV/log/nvserverd.log of events being sent to the Tivoli Enterprise Console. Also recorded here are startup parameters of the internal adapter itself as well as error messages concerning the internal adapter should any be recorded. This error information was previously only available in the nettl logs. Using this flag in the tecint.conf file removes the need to export an environment variable, NVSERVERD_TRACE_TEC_EVENTS=YES, in /usr/OV/bin/netnmrc.pre to control the logging function. Moreover, it overrides that variable if present. If the "NvserverdTraceTecEvents=" flag is not present in the tecint.conf file or if it is commented out, the default behaviour is that no nvserverd.log is created. NvserverdPrimeTecEvents=No When set to 'No' or "NO', this flag causes nvserverd to open a session with the correlation daemon, nvcorrd, requesting not to be primed with recent events, as event windows are. The default behaviour is that the Tivoli Enterprise Console rule set is primed. Priming it increases the probability that duplicate events will be sent to the Tivoli Enterprise Console when nvserverd is stopped and restarted while nvcorrd remains active. Using this entry removes the need to export an environment variable, NVSERVERD_PRIME_TEC_EVENTS=NO, in /usr/OV/bin/netnmrc.pre to control the priming function. Moreover, it overrides that variable if present. NvserverdSendSeverityTecEvents=Yes When set to 'Yes' or "YES', this flag causes nvserverd to revert to its pre-NetView 7.1.4 behaviour and to send the user-configurable NetView severity on events sent to the Tivoli Enterprise Console. Event severity was dropped in 7.1.4 originally because it interfered with the working of new Tivoli Enterprise Console rules shipped in IBM Tivoli Enterprise Console Version 3.9 (and in FixPacks for versions 3.8 and 3.7.1). These new Tivoli Enterprise Console rules automatically set the event severity of NetView internal events upon receipt at the Tivoli Enterprise Console server, and escalated it or de-escalated it based on event correlation and time open at the Tivoli Enterprise Console server. However, many users are not ready to migrate to using these new rules and require that NetView severity still be sent in order for their own custom rules to work. The new "NvserverdSendSeverityTecEvents=" flag is therefore provided as a migration aid. Using this entry removes the need to export an environment variable, NVSERVERD_SEND_SEVERITY_TEC_EVENTS=YES, in /usr/OV/bin/netnmrc.pre to control the sending of severity. Moreover, it overrides that variable if present. If the "NvserverdSendSeverityTecEvents=" flag is not present in the tecint.conf file, or if it is commented out, the default behaviour is that no severity field is sent on default events. Explicitly coded severity in a slotmap field is not affected by this changes. Solaris users, files in /tmp will be lost during reboot. If there are problems, ensure that the logs are saved, prior to reboot. Community name changes can cause problems after you install the Tivoli(R) NetView(R) program. To correct this situation, use the xnmsnmpconf application to enter the correct community name for the global setting as well as for 127.0.0.1. To do this, enter the following command: /usr/OV/bin/xnmsnmpconf  root:/:]
ovwls -l
X11 settings seem to be overwritten or changed in some way causing the upgrade to not be totally successful. Apologies if this is teaching you to suck eggs. Hope it helps. Best Regards, Lorraine.
Hi, I'm about to upgrade to Netview 7.1.5 from 7.1.3 on our Unix Solaris 9 server. I know I need to go to 7.1.4 first and it appears there is no reason not to go straight to 7.1.5 on the same day. Has anyone else done this or are there any issues I need to know about? I was planning to check that all is running well with 7.1.4, take a backup and then upgrade to 7.1.5. Are there any additional steps I need to take prior to going ahead with upgrading to 7.1.5, eg. merging trapd.conf files, etc. Thanks in advance for your advice. Regards, Unless stated otherwise above:
_______________________________________________ NV-L mailing list NV-L@lists.ca.ibm.com Unsubscribe:NV-L-leave@lists.ca.ibm.com http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to internal IBM'ers only) |
