Harald_Heidinger_152

How to change the period turnaround for events, so they are restarted and a new RunID is assigned?

Discussion created by Harald_Heidinger_152 on Mar 20, 2017
Latest reply on Mar 21, 2017 by Darren_Sniezak_40
To avoid Fileevents (or any other kind of events) of running forever and are not recognized by any reorganization, the period turnaround for Fileevents is taking place every 14 days per default.

Why this?

The Event as it is started, gets active on the activity window and polling its !Process Tab with the content what to do within the specified period of time. This is causing report lines and these are reported to the database. If the period turnaround, which causes a restart of the fileevent would not take place, it might by time cause a huge report which is never been recognized by any reorganisation, since the event process will still be active.

To avoid this, the period turnaround makes a cut, stores the "old" activation with its runID as a finished task, so the reorganisation can take the report after the specific defined timeframe and put it out of the database.

How to change this period of time?

This parameter is connected to the parameter "CHANGE_LOGGING_DAYS" within the UC_SYSTEM_SETTINGS Variable in Client 0. On Default this is set to 14 days, and also in this period of time, the event log is switched.

Why should I change this?

To consider, important to know:

Please check out Documentation of CHANGE_LOGGING_DAYS first to see its other impact, it also will cause that the logging days of the other components are changed from 14 days to another value. It is not recommended to set this higher than the 14 days (even if it is possible) without considering the effects for the other components which are bound to this parameter:

https://docs.automic.com/documentation/webhelp/english/AWA/12.0/DOCU/12.0/AWA%20Guides/help.htm#AWA/Admin/admin_UC_SYSTEM_SETTINGS.htm?Highlight=UC_SYSTEM_SETTINGS

This might be crucial in case of a Zero Downtime Upgrade (ZDU) since it requires to finish, that all activities are on the MQ Table Set, in case the events are still on the old dataset (and the change of tableset is done while the change logging of the event) they will remain there for a maximum of 14 days, so changing this parameter to a lower value, will bring the events to the new tableset more quick.

Outcomes