Hi Fabio,
Currently CEM does not have the ability to modify the actions taken when DB2 goes down to adjust from writing event information to DB2 over to writing to a file and then switching back to DB2 when DB2 comes back up. We can see the value in terms of recoverability and continuous monitoring – but this would be a substantial engineering effort (we would also need a service to port event information from that file back into DB2, for example, in order for CEM reporting to function).
We would like to also point out that CEM currently has the ability to fire off multiple actions per statement, so if you were interested in event information being captured when DB2 shuts down, you could also have a secondary action that would remain functional (even in the event of a DB2 shut down). If you are interested in that approach, we would be happy to walk you through it (contact me at Thomas.Melzer@Broadcom.com to set up a block of time to review).
Thanks,
Tom
Original Message:
Sent: Jan 28, 2025 11:08 AM
From: Fabio Hisatsugu
Subject: SQL ERROR SQLCODE: FFFFFC65 Crashes CEMMON.
Recently we had a scenario where our DB2 was taking on maintenance in our sandbox environment and it caused CEMMON to take a SQL ERROR SQLCODE: FFFFFC65, and subsequent abend.
It raised the concern that should the respective DB2 abend, need maintenance or a simple restart for whatever reason, specially on a production environment, it would have the same effect on CEMMON, causing loss of data for that timeframe.
Would it be possible to buffer data to a DD and have CEMMON checking on the DB2 availability thru a WTO or something similar, to ensure we will not have a gap eventually?
#ComplianceEventManager