Outage report for device is incorrect

Document ID : KB000106745
Last Modified Date : 16/07/2018
Show Technical Document Details
CABI/Jaspersoft Availability Report is incorrect at all. Used OC-weblogon / Administration / ReportManager / Outage editor options - does not show any "current" data (but aged data month ago)CABI Outage report for device is incorrect. So showing device down for "many days" which is incorrect and it appears "current" device status is not honored and therefore the "outage" continues for one month.
CA Spectrum "Availability" report makes use of OC/SRM-ReportManager "reporting" database info - here most important the ModelOutage tables. 
The model-outages (Availability) is calculated on events indicating the device is "down" or "alive". So it appears the "down" event triggering a modeloutage "start" is part of the processing but the event "alife"(back responding to polls) is not honored and is therefore not closing the "outage". 
CA Spectrum on Linux or Windows shows same behaviour. Symptom here seen for CA Spectrum R10.2.3 hosted on Linux
Validate following details:
- when opening the OC-weblogon / Administration / ReportManager -> Archive Expert:  Here to check for status and recent update on ModelOutage table
- when going to OC/SRM host - here to check for *bucket* files under directory ./mysql/data/reporting - there should be only "few" and with current date/time.
- check for MYSQL.OUT under ./mysql/bin - to see if "mysql"-service will report errornous conditions.  

In this case the MYSQL.OUT did cover info "modeloutage" table is "full". 
Checked the disk-space - which was recently "increased" as Administrators saw disk-full condition (covering the ./mysql/data related partition too).

It appears the mysqld/service did not recognized the available disk-space as it was not recycled.  Doing a OC/SRM stop down - plus then processd-stop 
to force also a mysqld-service recycle then resolved the "table full" conditions (was seen on modeloutage and alarminfo table). 

After this recycle the OC/SRM starts working on the "*bucket* files(tables) (which did hold most current SpectroSERVER update info) and we then 
saw modeloutage table updates did come in again  - also AlarmInfo. After one day processing all 700 bucket-files under ./mysql/data/reporting are
processed and reports are again "current" showing correct info.