The fix for APAR IZ80477 is 'non-reversible' and can greatly increase the size of your TSOM database. Contact TSOM Support for advice and assistance enabling this fix.
The fix for APAR IZ80477, (the fix for truncated event 'info' field data in stored TSOM events), is being released as part of Fix Pack 13. This fix is NOT activated by installing Fix Pack 13: It must be enabled manually. (Contact TSOM support for assistance on enabling this fix.)
BE AWARE: The fix for APAR IZ80477 is not reversible. [It cannot be backed out]. Therefore, carefully consider the fix before implementation.
BE AWARE: Activating the fix can substantially increase the size of your current TSOM database. Worst case, this fix could triple the size of your TSOM database.
- The fix for APAR IZ80477 is not activated just by applying Fix Pack 13. It must be manually activated. (You should coordinate with IBM Support on how/when to implement the fix.)
- You should be aware that the problem being fixed only affects events AFTER they are stored. (The info field is truncated when written to the database. Therefore, processing of real-time events has not been a problem, and is not affected by this fix.)
- The underlying problem is: The info field in the database table EVENT_DATA is a 2000 Character field. However, the CMS only stores the first 667 bytes of the information field. [In other words: the info field in the database was never fully used.] The fix changes the CMS to correctly save up to 2000 characters of information. THIS FACT IS IMPORTANT BECAUSE activating this fix may greatly increase how much data is written to your database. (Read: Activating this fix may greatly increase the size of your database, even though you retain the same number of events.
The nature and type of events you store greatly affect how much this fix changes the size of your database. Not every event you save uses more than the previous maximum of 667 characters. For most syslog events, the info field will not be any larger than before. However, some Check Point events are greater than 667 bytes. Also, many Windows 2008 events can be substantially larger than 667 bytes. (This is because they are stored in XML format.) In general, event INFO field sizes vary greatly.
Because the EVENT_DATA table is by far the largest table in your TSOM database, and because the effect of turning on the fix for APAR IZ80477 depends greatly on what type events you store; we recommend you test this fix before implementing it in your production environment. Worst case scenario testing performed by development shows that if ALL your events have info strings over 2000 characters, THIS FIX CAN INCREASE THE SIZE OF YOUR DATABASE BY A FACTOR OF 3.4.
TSOM Support can help you plan testing for applying this fix: From a high level, testing would involve creating a test TSOM database, then redirecting your CMS to this test database. You will then enable the fix and let the CMS run until a sample number of events are written to the database. Then you can see the size of your database and determine by what factor your database is being affected by typical events from your environment.
Open a PMR if you wish to explore enabling this fix.
ALSO IMPORTANT: Testing shows that your TSOM database's 'page size' greatly affects to what extent this change increases database utilization. If you originally set up your database to use 8K pages (as is recommended in the installation guide) than the EVENT_DATA table winds up using physical storage at about 75% utilization. However, if you used the default page size of 4K, the worst case scenario would mean your physical storage would only be at around 50% utilization, greatly increasing the physical storage used by your database.