Configure the application log purge task
To configure the application log purge task, go to the task configuration page in the Services Framework user interface and select the New Task Configuration link.
The following table shows the information that is needed to configure the application log purge task.
| Field | Description | Example |
|---|---|---|
| Task | This field displays a list of all of the registered tasks. Select the name of the application log purge task that was entered during registration. | Application Log Purge Task |
| Configuration | Descriptive name for the configuration. This field is required and can contain up to 60 characters. | Application Log Purge Task |
| Description | A detailed description that explains what the configuration does. This field is optional. If entered, it must be 512 characters or less. | Purge all application log records older than 5 days. |
| Activate task | Identifies whether the configuration is active. When it is active, the task is available to purge records. | Yes, No |
| Process end of day | Set this value to no because the task does not need to run at the end of the day. | No |
| Process cleanup | Set this value to no because the task does not need to process cleanup. | No |
| Keep days | Represents how long to keep the application log records before they are purged from the database. The way that the task uses this field depends on the operating system that the database is running on. | For more information about how this field is used, see Purging records by using business day partitioning. |
| Commit rate | The maximum number of records to delete before a database commit is done. For a z/OS® database, this field applies to both application log records and alert records. When the database is not on z/OS, the field applies only to alert records. | If the commit rate is set to 500, the purge process does a database commit after every 500 application log or alert records deleted. |
Purging records by using business day partitioning
The keep days field and business day partitioning are used to
determine which records are purged from the database. A partial business day cannot be purged because all of
the data for a business day is deleted when its partition is deleted. The operating system that the database
is running on also affects how the records are purged from the database. The way that the purge works for the
different databases is described as follows.
- Databases that are on z/OS.
- Business day partitioning is not available for these databases. The purge process subtracts the keep days
field, which is a number of calendar days, from the date and time that the task runs to determine which
records to purge. Any record that is older than this calculated date is purged.
For example, the task is scheduled to run on 28 February 2020 at 8:00 PM EST and its keep days field is set to 2. The task first converts its run date and time to Coordinated Universal Time, which is 29 February 2020 at 1:00 AM. The task then subtracts the two calendar days from the new date, which makes the purge cut-off date 27 February 2020 at 1:00 AM Coordinated Universal Time. Because business day partitioning is not used, the task purges all data that is older than 27 February 2020 at 1:00 AM Coordinated Universal Time.
- Databases that are not on z/OS.
- Business day partitioning is available for these databases. The purge process subtracts the keep days
field, which is a number of calendar days, from the date and time that the task runs to determine which
records to purge. Depending on the time of day that the task runs, it might need to adjust the purge cut-off
date so that it doesn't purge a partial business day. The following examples show how the records are purged
in these types of databases.
- First example
- The task is scheduled to run on 28 February 2020 at 8:00 PM EST and its keep days field is set to 2. The task first converts its run date and time to Coordinated Universal Time, which is 29 February 2020 at 1:00 AM. The task then subtracts the two calendar days from the new date, which makes the purge cut-off date 27 February 2020 at 1:00 AM Coordinated Universal Time. Because business day partitioning is being used, 27 February 2020 at 1:00 AM cannot be used as the purge cut-off date because it is a partial day. To compensate for the partial day, the task includes one more calendar day as a keep day, which means the new purge cut-off date is 26 February 2020. The task then purges the older data one calendar day at a time, up to and including the data for 26 February 2020.
- Second example
- The task is scheduled to run on 28 February 2020 at 4:00 PM EST and its keep days field is set to 2. The task first converts its run date and time to Coordinated Universal Time, which is 28 February 2020 at 9:00 PM. The task then subtracts the two calendar days from the new date, which makes the purge cut-off date 26 February 2020 at 9:00 PM Coordinated Universal Time. Because 26 February 2020 at 9:00 PM is a partial day, the purge cut-off date is moved back by one calendar day to 25 February 2020. The old data is purged one calendar day at a time, up to and including the data for 25 February 2020.