======================================================================
Halcyon PrimeAlert (R) EventAction
Version 2.5.0
Release Notes
======================================================================
Copyright (c) 1998-2008 Halcyon Monitoring Solutions, Inc.
Note: For the latest information on this product, visit:
http://www.HalcyonInc.com
Refer to the README file(s) for all other information.
Versions Documented Below: 2.5.0 2.4.0a 2.4.0 2.3.0 2.2.0b 2.2.0a 2.2.0
2.1.0 2.0.0b 2.0.0a 2.0.0 1.2 1.1.2a
======================================================================
VERSION/DATE: 2.5.0/2008-11-14
ENHANCEMENTS
----------------------------------------------------------------------
- Once a minute a list of all pending events are written to the
HALEAPendingEvents.log logfile
BUG FIXES
----------------------------------------------------------------------
- For Sun MC 4.0 running on Solaris 10, EventAction could not properly
determine the end of historical alarms. From this release onwards,
historical alarms are now defined to be those alarms which occurred
before EventAction was started. EventAction will act only on those
alarms which occur after EventAction started.
- EventAction disconnects from the Sun MC Event Manager alarm feed
before process termination under the following conditions:
- the agent restarts
- the module is disabled, unloaded, or scheduled off
As a result, there will be no orphaned Sun MC eventmgr process.
- JAVA_HOME no longer needs to be left justified in ESDIR/cfg/java.home
for EventAction.
- The Java EventBridge will do Garbage Collection a bit more and use
significantly less virtual memory.
- If either EventAction does not find Java binary or the version of
Java is less than 1.5, an alarm will be raised in the EventAction
Status node:
"ERR No EventBridge shell service. See eventBridge.log file for details."
KNOWN PROBLEMS
----------------------------------------------------------------------
- When EventAction could not find the correct version of Java, disabling/
re-enabling the module does not restart EventAction using the newer
version of Java that user installs afterwards. See TroubleShooting
file for workaround.
- If you use one of the default hardware specific 'module identifiers'
presented in the drop down list for filtering "Config Reader"
alarms, then alarms from other types of systems may be missed.
The user is advised to manually type "Config-Reader" into the "ID"
field in the "Module Specification" part of the EventAction filter.
- The EventBridgeConfig.properties file may not be upgraded properly
if there are any backslashes in the user password for EventAction.
- The "Last Execution Time" field may take up to 2 minutes to update
on it's own after an execution. This does not mean that the
execution has been un-necessarily delayed, it is simply a display
delay. This does not affect users with the Java Console who press
the "refresh" button. It will be more noticeable for individuals
using the Halcyon PrimeAlert WebPortal.
- Only the close event may be pushed to EventAction by the Sun MC
server layer should an alarm open and close within a single 30
second interval.
- If the local event manager stops sending alarm data to the module,
the module will detect this and restart data acquisition, but it
will not process the missed alarms from the time the data acquisition
stopped and then restarted.
- There will be a delay of up to 30 seconds after an event occurs
before PrimeAlert EventAction will process the event and perform
actions.
- Sun MC 3.0 has a status message maximum length of 128 characters.
If an alarm status message is longer than 128 characters it will
be truncated by the Sun MC database. The maximum status
message length in Sun MC 3.5 and up is 1024 characters.
- EventAction may take a long time before it executes actions for
alarms. This will happen whenever the EventBridge component
connects to a SunMC server that has a large number of historical
alarms in its database. The EventBridge component has to wait until
all historical alarms have been received before it starts to process
the current alarms. Every batch of 1000 alarms in the database will
cause a delay of approximately 45 seconds. For example, if there
are 100K alarms in the SunMC database, then it will take about 1.25
hours before any action is taken for newly created alarms. The
workaround to this issue is to tune the noisy alarms and/or to
shorten the alarm retention period in the SunMC database. See
TroubleShooting file for more details.
- If EventAction is installed on SunMC server version 3.5 or higher,
then it cannot be used to collect alarm data from a remote SunMC
server that is version 3.0. The exception "InvalidClassException"
will be reported in the eventBridge.log.
- The SunMC API reports a maximum of 24 characters for the hostname
field of an alarm. Any hostnames longer than this value will be
truncated. See TroubleShooting file for workaround.
- The details page in the web interface of the PrimeAlert Reporter
product is blank. See TroubleShooting file for workaround.
UPGRADE STRATEGY
----------------------------------------------------------------------
- If you are upgrading from older versions of EventAction, please refer
in to the Upgrade Strategies in sequence subsequent from your version.
======================================================================
VERSION/DATE: 2.4.0a/2008-02-26
ENHANCEMENTS
----------------------------------------------------------------------
- Adjusted an eventBridge timeout value to correspond to recently
observed Sun MC API behaviour. Expect reduced incidences of
failures to reconnect to the Sun MC Server alarm API.
UPGRADE STRATEGY
----------------------------------------------------------------------
- If you are upgrading from older versions of EventAction, please refer
in to the Upgrade Strategies in sequence subsequent from your version.
- This version is intended to benefit "new installs". If you already
have v2.4.0 installed, you may instead simply refer to item #2 in
the best practice link below. Installing this version will NOT
have an effect.
All customers please also refer to items #3 and #4 in the following
best practices:
http://forums.halcyoninc.com/showthread.php?p=116
KNOWN PROBLEMS
----------------------------------------------------------------------
- If you use one of the default hardware specific 'module identifiers'
presented in the drop down list for filtering "Config Reader"
alarms, then alarms from other types of systems may be missed.
The user is advised to manually type "Config-Reader" into the "ID"
field in the "Module Specification" part of the EventAction filter.
- The EventBridgeConfig.properties file may not be upgraded properly
if there are any backslashes in the user password for EventAction.
- The "Last Execution Time" field may take up to 2 minutes to update
on it's own after an execution. This does not mean that the
execution has been un-necessarily delayed, it is simply a display
delay. This does not affect users with the Java Console who press
the "refresh" button. It will be more noticeable for individuals
using the Halcyon PrimeAlert WebPortal.
- Only the close event may be pushed to EventAction by the Sun MC
server layer should an alarm open and close within a single 30
second interval.
- If the local event manager stops sending alarm data to the module,
the module will detect this and restart data acquisition, but it
will not process the missed alarms from the time the data acquisition
stopped and then restarted.
- There will be a delay of up to 30 seconds after an event occurs
before PrimeAlert EventAction will process the event and perform
actions.
- Sun MC 3.0 has a status message maximum length of 128 characters.
If an alarm status message is longer than 128 characters it will
be truncated by the Sun MC database. The maximum status
message length in Sun MC 3.5 and up is 1024 characters.
- EventAction may take a long time before it executes actions for
alarms. This will happen whenever the EventBridge component
connects to a SunMC server that has a large number of historical
alarms in its database. The EventBridge component has to wait until
all historical alarms have been received before it starts to process
the current alarms. Every batch of 1000 alarms in the database will
cause a delay of approximately 45 seconds. For example, if there
are 100K alarms in the SunMC database, then it will take about 1.25
hours before any action is taken for newly created alarms. The
workaround to this issue is to tune the noisy alarms and/or to
shorten the alarm retention period in the SunMC database. See
TroubleShooting file for more details.
- If EventAction is installed on SunMC server version 3.5 or higher,
then it cannot be used to collect alarm data from a remote SunMC
server that is version 3.0. The exception "InvalidClassException"
will be reported in the eventBridge.log.
- The SunMC API reports a maximum of 24 characters for the hostname
field of an alarm. Any hostnames longer than this value will be
truncated. See TroubleShooting file for workaround.
- The details page in the web interface of the PrimeAlert Reporter
product is blank. See TroubleShooting file for workaround.
- If the Sun MC agent only is stopped and restarted, or if the
EventAction module is disabled and re-enabled, or if the EventAction
module is unloaded and re-loaded - an orphaned Sun MC eventmgr process
will be left running. There are no negative implications other than
the memory used, which will not be significant unless the agent is
restarted on a frequent schedule or the module is frequently disabled
on a schedule. The eventmgr processes will exit upon restart of the
Sun MC event manager daemon, which happens when the Sun MC server
layer processes are restarted.
======================================================================
VERSION/DATE: 2.4.0/2007-11-09
ENHANCEMENTS
----------------------------------------------------------------------
- Added support for Sun Management Center (Sun MC) 4.0.
BUG FIXES
----------------------------------------------------------------------
- PrimeAlert EventAction will no longer store user passwords in
clear text in the EventBridgeConfig.properties file. Instead,
it stores encoded user passwords to improve security.
KNOWN PROBLEMS
----------------------------------------------------------------------
- If you use one of the default hardware specific 'module identifiers'
presented in the drop down list for filtering "Config Reader"
alarms, then alarms from other types of systems may be missed.
The user is advised to manually type "Config-Reader" into the "ID"
field in the "Module Specification" part of the EventAction filter.
- The EventBridgeConfig.properties file may not be upgraded properly
if there are any backslashes in the user password for EventAction.
- The "Last Execution Time" field may take up to 2 minutes to update
on it's own after an execution. This does not mean that the
execution has been un-necessarily delayed, it is simply a display
delay. This does not affect users with the Java Console who press
the "refresh" button. It will be more noticeable for individuals
using the Halcyon PrimeAlert WebPortal.
- Only the close event may be pushed to EventAction by the Sun MC
server layer should an alarm open and close within a single 30
second interval.
- If the local event manager stops sending alarm data to the module,
the module will detect this and restart data acquisition, but it
will not process the missed alarms from the time the data acquisition
stopped and then restarted.
- There will be a delay of up to 30 seconds after an event occurs
before PrimeAlert EventAction will process the event and perform
actions.
- Sun MC 3.0 has a status message maximum length of 128 characters.
If an alarm status message is longer than 128 characters it will
be truncated by the Sun MC database. The maximum status
message length in Sun MC 3.5 and up is 1024 characters.
- EventAction may take a long time before it executes actions for
alarms. This will happen whenever the EventBridge component
connects to a SunMC server that has a large number of historical
alarms in its database. The EventBridge component has to wait until
all historical alarms have been received before it starts to process
the current alarms. Every batch of 1000 alarms in the database will
cause a delay of approximately 45 seconds. For example, if there
are 100K alarms in the SunMC database, then it will take about 1.25
hours before any action is taken for newly created alarms. The
workaround to this issue is to tune the noisy alarms and/or to
shorten the alarm retention period in the SunMC database. See
TroubleShooting file for more details.
- If EventAction is installed on SunMC server version 3.5 or higher,
then it cannot be used to collect alarm data from a remote SunMC
server that is version 3.0. The exception "InvalidClassException"
will be reported in the eventBridge.log.
- The SunMC API reports a maximum of 24 characters for the hostname
field of an alarm. Any hostnames longer than this value will be
truncated. See TroubleShooting file for workaround.
- The details page in the web interface of the PrimeAlert Reporter
product is blank. See TroubleShooting file for workaround.
UPGRADE STRATEGY
----------------------------------------------------------------------
- None, if PrimeAlert EventAction is upgraded from version 2.3.0 to
2.4.0.
======================================================================
VERSION/DATE: 2.3.0/2007-02-26
ENHANCEMENTS
----------------------------------------------------------------------
- Added heartbeat support. EventAction now creates heartbeat events
that are used to assess the availability of the event feed. If
the heartbeat events are not received by the EventBridge component
of EventAction, then the event feed from the SunMC server is
determined to be broken (timeout). EventBridge will then reconnect
and re-subscribe for alarms. Users have the ability to specify
actions for heartbeat alarms. See the "Monitor EventAction Status"
section of the help documentation for more details.
- Made the EventAction Status property visible. Users now have the
ability to specify alarm actions when the status of the EventAction
is compromised. See the "Monitor EventAction Status" section of the
help documentation for more details.
- Fixed the console help files link.
- EventAction is resilient to event storms.
BUG FIXES
----------------------------------------------------------------------
- Fixed minor documentation issues.
- The EventBridge component will not incorrectly determine that it
has lost it's connection to the SunMC Server. As a result, it will
not reconnect sporadically.
- When the EventBridge component reconnects to the SunMC Server due
to a timeout, actions will not be re-executed for historical alarms.
NOTES
----------------------------------------------------------------------
- EventAction Table has been renamed to Actions Table.
KNOWN PROBLEMS
----------------------------------------------------------------------
- If you use one of the default hardware specific 'module identifiers'
presented in the drop down list for filtering "Config Reader"
alarms, then alarms from other types of systems may be missed.
The user is advised to manually type "Config-Reader" into the "ID"
field in the "Module Specification" part of the EventAction filter.
- The EventBridgeConfig.properties file may not be upgraded properly
if there are any backslashes in the user password for EventAction.
- The "Last Execution Time" field may take up to 2 minutes to update
on it's own after an execution. This does not mean that the
execution has been un-necessarily delayed, it is simply a display
delay. This does not affect users with the Java Console who press
the "refresh" button. It will be more noticeable for individuals
using the Halcyon PrimeAlert WebPortal.
- Only the close event may be pushed to EventAction by the Sun MC
server layer should an alarm open and close within a single 30
second interval.
- If the local event manager stops sending alarm data to the module,
the module will detect this and restart data acquisition, but it
will not process the missed alarms from the time the data acquisition
stopped and then restarted.
- There will be a delay of up to 30 seconds after an event occurs
before PrimeAlert EventAction will process the event and perform
actions.
- Sun MC 3.0 has a status message maximum length of 128 characters.
If an alarm status message is longer than 128 characters it will
be truncated by the Sun MC database. The maximum status
message length in Sun MC 3.5 and up is 1024 characters.
- EventAction may take a long time before it executes actions for
alarms. This will happen whenever the EventBridge component
connects to a SunMC server that has a large number of historical
alarms in its database. The EventBridge component has to wait until
all historical alarms have been received before it starts to process
the current alarms. Every batch of 1000 alarms in the database will
cause a delay of approximately 45 seconds. For example, if there
are 100K alarms in the SunMC database, then it will take about 1.25
hours before any action is taken for newly created alarms. The
workaround to this issue is to tune the noisy alarms and/or to
shorten the alarm retention period in the SunMC database. See
TroubleShooting file for more details.
- If EventAction is installed on SunMC server version 3.5 or higher,
then it cannot be used to collect alarm data from a remote SunMC
server that is version 3.0. The exception "InvalidClassException"
will be reported in the eventBridge.log.
- The SunMC API reports a maximum of 24 characters for the hostname
field of an alarm. Any hostnames longer than this value will be
truncated. See TroubleShooting file for workaround.
- The details page in the web interface of the PrimeAlert Reporter
product is blank. See TroubleShooting file for workaround.
UPGRADE STRATEGY
----------------------------------------------------------------------
- The following steps must be taken to upgrade to this version of
EventAction:
1) The user(s) specified in the file EventBridgeConfig.properties
must be assigned a minimum of SunMC Operator (esops) level
privileges. Otherwise, the module cannot periodically delete
EventAction's heartbeat events.
2) SunMC 3.0 ships with java version 1.2.2.x which is not supported
with this version of the module. See README file for supported
java versions. If you are using SunMC 3.0, then you must install
a compatible version of java in either of the following locations:
a) As specified by the JAVA_HOME variable in the file
/var/opt/SUNWsymon/cfg/java.home.
b) In the directory /usr/j2se.
c) In the directory /usr/java.
======================================================================
VERSION/DATE: 2.2.0b/2006-09-25
ENHANCEMENTS
----------------------------------------------------------------------
- Added Solaris 10 whole root zone support.
BUG FIXES
----------------------------------------------------------------------
- Adding Remote Acknowledgement support during installation will not
cause the agent to become unresponsive due to incorrect seeding.
- With SunMC 3.6 and higher, the 'check_status' feature in the
EventBridgeConfig.properties file was causing EventAction to
lose connections. This feature has been disabled by default.
KNOWN PROBLEMS
----------------------------------------------------------------------
- None.
UPGRADE STRATEGY
----------------------------------------------------------------------
- None. This release is compatible with the previous version.
======================================================================
VERSION/DATE: 2.2.0a/2006-03-10
ENHANCEMENTS
----------------------------------------------------------------------
- Added SunMC 3.6 support.
BUG FIXES
----------------------------------------------------------------------
- Modified install script to conform to Solaris 10 packaging
standards.
KNOWN PROBLEMS
----------------------------------------------------------------------
- None.
UPGRADE STRATEGY
----------------------------------------------------------------------
- None. This release is compatible with the previous version.
======================================================================
VERSION/DATE: 2.2.0/2005-10-07
ENHANCEMENTS
----------------------------------------------------------------------
- Module now supports Solaris 10.
- Improved initial connection status checking.
- The %trapspecs parameter now includes the WebPortal URL.
- Modify user interface to include WebPortal URL description.
- Maximum size of eventBridgeHistory.log has been increased to
accommodate more alarms.
- Restarting EventAction due to broken connection is now logged
in eventBridge.log.
- Module help will now be served from the server layer. There is no
need to install on each console host.
BUG FIXES
----------------------------------------------------------------------
- WebPortal URL format in documentation has been updated to work with
the newest release.
- The Pipeline character ("|") is no longer specified under the list
of valid regular expressions in the documentation.
- Deleting an alarm is no longer logged as "Unknown" in
EventActionHistory.log.
- Fixed minor documentation issues.
- The remote acknowledgement feature will work with or without
a username.
KNOWN PROBLEMS
----------------------------------------------------------------------
- The EventBridgeConfig.properties file may not be upgraded properly
if there are any backslashes in the user password for EventAction.
UPGRADE STRATEGY
----------------------------------------------------------------------
- None. This release is compatible with the previous version.
======================================================================
VERSION/DATE: 2.1.0/2004-08-23
ENHANCEMENTS
----------------------------------------------------------------------
- EventAction now allows the remote acknowledgement of alarms
via an SNMP set to the EventAction module. Alarms can be
referenced by either their Event Id or URL.
- The length of the eventBridgeHistory.log can now be customized.
- The length of the eventActionHistory.log and eventBridgeHistory.log
are now double their previous size.
- Users can now tune the startup time allowed for EventAction to
connect to the Sun MC server. An alarm is now raised informing
the user if this connection takes longer than this time.
- Added support for Sun Management Center's Agent Update feature.
- Added support for Sun Management Center's new 1024 character
alarm status message length capability.
BUG FIXES
----------------------------------------------------------------------
- EventAction now reports the time an event occurred rather
the time it was received by EventAction.
- Topology alarms (alarms on Host or Agent not responding) which were
previously acted on by a 'Module' type filter will be properly
filtered out.
UPGRADE STRATEGY
----------------------------------------------------------------------
- If EventAction has been acting on topology alarms (alarms on Host
or Agent not responding) using a Module type filter, then
you must add a Host type filter to act on these alarms.
NOTES:
----------------------------------------------------------------------
- The filesize changes mentioned in the enhancements section will only
take effect if the old copies of the files are deleted first.
- In the event an agents clock is not in sync with the server clock,
EventAction may mistake acknowledgements on closed alarms events for
close events.
KNOWN PROBLEMS
----------------------------------------------------------------------
- If you use one of the default hardware specific 'module
identifiers' presented in the drop down list for filtering
"Config Reader" alarms, then alarms from other types of
Sparc systems may be missed.
The user is advised to manually type "Config-Reader" into the
"ID" field in the "Module Specification" part of the EventAction
filter.
- The "Last Execution Time" field may take up to 2 minutes to update
on it's own after an execution. This does not mean that the
execution has been un-necessarily delayed, it is simply a display
delay. This does not affect users with the Java Console who press
the "refresh" button. It will be more noticeable for individuals
using the Halcyon PrimeAlert WebPortal.
- Only the close event may be pushed to EventAction by the Sun MC
server layer should an alarm open and close within a single 30
second interval.
- If the local event manager stops sending alarm data to the module,
the module will detect this and restart data acquisition, but it
will not process the missed alarms from the time the data acquisition
stopped and then restarted. Note that EventAction will disconnect
and reconnect itself to all of the the server layers it is connected
to, even though alarm data only stopped from one of them.
- There will be a delay of up to 30 seconds after an event occurs
before PrimeAlert EventAction will process the event and perform
actions.
- Sun MC 3.0 has a status message maximum length of 128 characters.
If an alarm status message is longer than 128 characters it will
be truncated by the Sun MC database. The maximum status
message length in Sun MC 3.5 and up is 1024 characters.
- Some special characters may appear incorrectly in the Help Window
for some Window Managers, including Windows NT.
======================================================================
VERSION/DATE: 2.0.0b/2003-08-22
BUG FIXES
----------------------------------------------------------------------
- EventBridge will not disconnect if there are more than 800 events
in the Event Manager database.
UPGRADE STRATEGY
----------------------------------------------------------------------
- None. This release is compatible with the previous version.
======================================================================
VERSION/DATE: 2.0.0a/2003-06-06
ENHANCEMENTS
----------------------------------------------------------------------
- Support for Sun MC 3.5.
UPGRADE STRATEGY
----------------------------------------------------------------------
- None. This release is compatible with the previous version 2.0.0
NOTES:
----------------------------------------------------------------------
- Removal of Solaris 2.5.1 support
- Removal of Sun Management Center 2.x support.
======================================================================
VERSION/DATE: 2.0.0/2002-11-29
ENHANCEMENTS
----------------------------------------------------------------------
- Solaris 9 support.
- Documentation upgrades.
- Added capability to run actions for acknowledgements.
BUG FIXES
----------------------------------------------------------------------
- If the eventBridge.log becomes corrupted, then the module will not
not load properly. This corruption is now being detected and the
log file is moved aside.
- If the local event manager stops sending alarm data to the module,
it will detect this and reconnect to restart the data acquisition.
- Sporadic agent hanging issue when module was being unloaded or
disabled.
KNOWN PROBLEMS
----------------------------------------------------------------------
- If the local event manager stops sending alarm data to the module, the
module will detect this and restart data acquisition, but it will
not process the missed alarms from the time the data acquisition
stopped and then restarted.
- If the local event manager stops sending alarm data to the module, the
module will detect this and restart data acquisition, but in the
process it will disconnect from all connected server layers. Some
alarms may be missed during the reconnection.
- The status messages that are received by PrimeAlert EventAction from
a SunMC server have a maximum length of 128 characters; if an alarm
status message is longer than 128 characters, it will be truncated.
- There will be a delay of up to 30 seconds after an event occurs
before PrimeAlert EventAction will process the event and perform
actions.
- Events generated by sub-modules in version 1.0.1 or earlier of
PrimeAlert for Oracle and PrimeAlert for Sybase will not be detected
properly by PrimeAlert EventAction. If you are using PrimeAlert
EventAction to detect events from PrimeAlert for Oracle and
PrimeAlert for Sybase, please contact Halcyon for the newest
versions of these modules.
NOTES:
----------------------------------------------------------------------
- Removal of Solaris 2.5.1 support
- Removal of Sun Management Center 2.x support.
UPGRADE STRATEGY:
----------------------------------------------------------------------
- None.
======================================================================
VERSION/DATE: 1.2/2001-05-24
BUG FIXES:
----------------------------------------------------------------------
- When a SunMC 3 server host is used, PrimeAlert EventAction will now
detect all close events, and provide complete details for each
close event. Close events have always been properly detected by
PrimeAlert EventAction for SunMC 2.x.
- When PrimeAlert EventAction is disabled, all rows in the EventAction
Table will now have 'Pending' set to zero.
ENHANCEMENTS:
----------------------------------------------------------------------
- The new 'Event Bridge' component has been implemented. This new
feature allows more than one SunMC server layer to be monitored at
the same time by a single instance of PrimeAlert EventAction. See
the README file for more details.
KNOWN PROBLEMS:
----------------------------------------------------------------------
- The status messages that are received by PrimeAlert EventAction from
a SunMC server have a maximum length of 128 characters; if an alarm
status message is longer than 128 characters, it will be truncated.
- There will be a delay of up to 30 seconds after an event occurs
before PrimeAlert EventAction will process the event and perform
actions.
- The following bug only applies to SunMC 2.1.1 or earlier; it does not
occur under SunMC 3.x. If the EventAction module is disabled, and you
try to add a new row to the EventAction table, you will get an error
message when you add the row, but a row is added to the EventAction
table. The new row will contain values for all fields except for the
'Execution Schedule'. The following error message is received when
the EventAction is added:
'Error Adding Action - An EventAction with this name already exists.
Please specify a different EventAction name.'
If the new, incomplete EventAction is edited, the following error
message is displayed:
'The specified script () was not found in the list of valid scripts.
Please choose a different script.'
The problematic row in the EventAction table should be deleted, and
then re-added, after the module has been enabled.
- For the included module(s), certain tables with more than 50 rows of
data may no longer display properly when using a SunMC 2.1.1 console.
This problem does not occur when using a SunMC 2.1 or 3.x console. If
you are still using the SunMC 2.1.1 console, and you are experiencing
the table display problem, then please contact Halcyon for a patch
(info@HalcyonInc.com).
- Assume that a user installs Sun Management Center in the /opt
directory, and then decides to relocate some of the installed
directories (located below /var/opt/SUNWsymon or below
/opt/SUNWsymon) after SunMC is installed. For example, assume that
the directory /opt/SUNWsymon/modules is moved to /export1/SUNWsymon,
and then a symbolic link is created to link /opt/SUNWsymon/modules to
/export1/SUNWsymon/modules. In this case, if the current distribution
attempts to install any files in or below the directory
/opt/SUNWsymon/modules, the symbolic link will be replaced by a real
directory. This problem does not occur under Solaris 2.5.1.
- Events generated by sub-modules in version 1.0.1 or earlier of
PrimeAlert for Oracle and PrimeAlert for Sybase will not be detected
properly by PrimeAlert EventAction. If you are using PrimeAlert
EventAction to detect events from PrimeAlert for Oracle and
PrimeAlert for Sybase, please contact Halcyon for the newest
versions of these modules.
- Some special characters may appear incorrectly in the Help Window for
some Window Managers, including Windows NT.
- The parameter description in the Alarms tab of the Attribute Editor
for a cell within the Time Window or Script columns displays the key
path. The keys for the entries are not defined.
- The Sun Management Center 2.1.x event manager (a server layer
process) has a known bug that may cause PrimeAlert EventAction to
trigger multiple events, even for old or closed alarms. This should
be fixed in the next version of SunMC. Please contact Halcyon for a
temporary work-around (info@HalcyonInc.com).
UPGRADE STRATEGY:
----------------------------------------------------------------------
- This version of PrimeAlert EventAction no longer supports Sun
Enterprise SyMON 2.0.x; only Sun Management Center 2.1 or higher is
supported.
- In order to obtain the full benefit of the new features included in
this version of PrimeAlert EventAction, EventAction packages should
be upgraded on the SunMC server host, and on all SunMC console hosts.
- The EventAction packages on the SunMC server host should be upgraded
first. Then, according to any user defined schedule, the console
hosts should be upgraded to ensure that the module help documentation
is up-to-date.
- CAVEAT: If EventAction is being upgraded from version 1.0.* to
version 1.2, then the file /var/opt/SUNWsymon/cfg/HALEventAction.dat
will be updated such that it is no longer compatible with pre-1.1
versions of EventAction; thus, prior to being updated, the file
HALEventAction.dat is copied to HALEventAction.dat.old. If one wishes
to downgrade from version 1.2 of EventAction to a pre-1.1 version,
the file /var/opt/SUNWsymon/cfg/HALEventAction.dat.old can be copied
over /var/opt/SUNWsymon/cfg/HALEventAction.dat after the pre-1.1
version of EventAction is installed; this will restore PrimeAlert
EventAction back to the state it had prior to the upgrade to version
1.2.
=======================================================================
VERSION/DATE: 1.1.2a/2001-04-03
BUG FIXES:
----------------------------------------------------------------------
- PrimeAlert EventAction now works properly when a SunMC 3 server host
has one of the following Solaris patches installed:
110971-02 (Solaris 2.6)
110972-02 (Solaris 2.7)
110973-02 (Solaris 2.8)
110936-02 (Solaris 2.6)
110937-02 (Solaris 2.7)
110938-02 (Solaris 2.8)
ENHANCEMENTS:
----------------------------------------------------------------------
- None.
---//---