Manipulating calendars

Changing the number of periods of an existing calendar

• Decreasing the number of periods of a calendar cuts off the oldest periods.
• Increasing the number of periods creates new periods in the past

Adding outputs to an existing calendar

New calendar outputs can be added at any point in time, even when they refer to past periods. This is possible because calendar outputs are evaluated on every incoming transaction by using the values that are stored in the period buckets. For example:

A daily calendar has 30 periods and so far we have only one output attribute that selects period 0. Nevertheless, the frequency and total amounts of all 30 periods are available. Adding a new output and selecting period 29 will give us correct results for the amount and frequency 29 days ago.

Remarks: The new output attribute will show n/a in query results for all transactions that arrived before creating the new calendar output. This is a general remark that applies to all kinds of newly created attributes that are stored in MDC/DDC: The values are not available for past transactions and IBM® Safer Payments will never update transactions that are already stored. Not even a merge will allow to set the values, because IBM Safer Payments allocates the MDC/DDC for new transactions since the go-live of the change.

Creating new calendars, no transactions in the system

IBM Safer Payments creates new calendars with period 0, -1, -2, etc when there is no transaction in the system that would allow to derive the actual period from the transactions’ timestamp.

1 2019-01-17 14:21:09.940156 I 0250 DDC for calendar profile
'New cal' created with 1,000 entries for calendar period 0 using 0.000 GB
disk
1 2019-01-17 14:21:09.940507 I 0250 DDC for calendar profile
'New cal' created with 1,000 entries for calendar period -1 using 0.000 GB
disk
1 2019-01-17 14:21:09.940564 I 0243 MDC calendar profile 'New
cal' created with 1,000 entries for 2 calendar periods using 0.000 GB RAM

The moment that the first transaction ever arrives, a rollover of period 0 can be observed, along with the creation of new periods:

1 2019-01-15 15:37:45.099396 I 0237 Rollover of calendar
profile 'Test Calendar 2' from calendar period 0 to 17,912
1 2019-01-15 15:37:45.101155 I 0250 DDC for calendar profile
'Test Calendar 2' created with 1,000 entries for calendar period 17912 using
0.000 GB disk
1 2019-01-15 15:37:45.119378 I 0250 DDC for calendar profile
'Test Calendar 2' created with 1,000 entries for calendar period 17911 using
0.000 GB disk
1 2019-01-15 15:37:45.119755 I 0250 DDC for calendar profile
'Test Calendar 2' created with 1,000 entries for calendar period 17910 using
0.000 GB disk

It can also be observed that calendars that already existed before the golive (there are still no transaction in the system), generate the following log messages:

1 2019-01-17 14:21:09.939682 I 0242 MDC calendar profile 'Test
Calendar' is taken unchanged with 1,000 entries for 2 calendar periods using
0.000 GB RAM
1 2019-01-17 14:21:09.939771 I 0248 DDC for calendar profile
'Test Calendar' taken unchanged with 1,000 entries for calendar period n/a
using 0.000 GB disk
1 2019-01-17 14:21:09.939846 I 0248 DDC for calendar profile
'Test Calendar' taken unchanged with 1,000 entries for calendar period 0
using 0.000 GB disk

All periods less than 0 seem to change to n/a. This might be a bug during the creation of the log messages, but it is irrelevant for the functionality.

Creating new calendars, where transactions exist

When transactions already exist, the periods for new calendars can be easily determined. In this case the memory in RAM and disk will be allocated for the correct periods, starting with the current, going into the past. The example shows an excerpt of log messages during the golive of a new calendar:

1 2019-01-15 14:51:08.047121 I 0250 DDC for calendar profile
'Test Calendar' created with 1,000 entries for calendar period 17866 using
0.000 GB disk
1 2019-01-15 14:51:08.047449 I 0250 DDC for calendar profile
'Test Calendar' created with 1,000 entries for calendar period 17865 using
0.000 GB disk

Please be aware that the calendars will be empty after creation. They will fill up gradually with incoming transactions. This process can be sped up by using one of the rebuild index maintenance functions. For more information, see Maintenance functions that have an impact on calendars.

Changing the Timestamp setting of calendars

Changing to a newer timestamp:

When changing the current timestamp attribute to a timestamp attribute whose latest transaction is newer than the latest transaction of the previous setting, all new periods that were not covered by the old timestamp will be created, unused periods will be purged, values of overlapping periods will be preserved.

Changing to an older timestamp:

When changing to a timestamp attribute whose latest transaction is older than the timestamp of the previous timestamp attribute, the values of overlapping periods will be preserved, but the latest period will not be adjusted to the new latest transaction. The periods will stay as they are, until the timestamps catch up with the periods. This can be considered as a bug. A fix could either update the periods and make aware that all periods that don’t overlap with the previous periods will be empty or update the periods and run a rebuild (at least partly) to fix the calendar periods.