'Over Time' (Copyright - Tom Phillips)

Solving problems with computers since 1972
( and always looking for new opportunities)

Take any database (or any file key) and change where it points: instead of to the current item - change it to point to an 'index' with the original name. Re-key the 'old' item to 'anything' and store it in a new location. The index will point to the new identifier and location. This index may include many entries representing 'changes' to the database or file items.

The actual 'new' item identifier (and location)

A date/time in true GMT

A sequence number

Flags (or user defined data for various application)

Default access is with the current time-of-day and GMT offset - returning the latest item (the one with closest date [and highest sequence number]).

This company is an insurance broker. They package and sell to other companies various insurance policies, provide a single monthly bill and a single source for filing insurance claims. These policies are purchased from a wide variety of “regular” insurance companies and “re-sold”. Many of these policies require employee monthly co-pay for a portion of the premium on the insurance they require.

As life is not static, changes occur and prior bills and eligibility must be adjusted:

A covered employee leaves and is no longer covered.

An employee retires and now has different coverage.

New employees are added.

An employee has a change in dependents.

An employee provided the wrong SSN or identifier and maybe 2 sets of records need to be adjusted.

An employee adds or removes coverage.

These actions all require an agent of the insurance broker to calculate adjustments to prior bills and/or make changes to various claims.

Additionally, marketing needs to meet with the customer and discuss renewal requirements. They need to discuss the monthly premium if changes in benefits are made. Maybe they need to discuss adding or dropping a policy. Or maybe they just need to be made aware of a change in the premium. New customer business also has the same set of "how much" / "what if" questions to answer.

Many computer systems have various tools to assist employees in these situations. Most are probably very useful by themselves but my sense is that it’s a complicated process.

Suppose that all data entry operations had an additional piece of data: “as of when” they could enter when accessing a 'key'. In this manner, changes could be made to data - past, present and future. Then billing programs could later query data entry “adjustments” made to prior period data and calculate adjustments by “rebilling” the item, compare to the amount billed and produce the corrected adjustment amount. Eligibility issues would be handled in a similar manner.

Marketing could enter future policy dates, key the customer changes required and then provide to customers a future pro-forma bill. If the terms were acceptable to the customer, then no more work is necessary. When the new billing period rolls around, well, all the works has already been completed. If for some reason the deal fell through, then the future data is simply deleted. Mistakes not caught in time could be entered/fixed and the next bill would have all adjustments.

A typical file record has a key - a very static piece of information. But suppose that this key pointed to an index of other records keyed with the original key. Items in the index contain a date/time value. There are two flavors for this data/time value: user supplied and system supplied. Each index item also contains processing flags. For example: a bill date which would 'lock' an item and 'force' changes to that item to use a next higher sequence number.

Individual files and/or databases could be 'current state' or use the new indexing.

Since all current computer systems are 'as of now', this proposal offers many, many new processing options, as a new system could/would operate in a past, present or future mode.

I envision many database/file I/O access exit points available to various programs.

... Before access and after access
... Passed item, key, flag area, user area
... Return actions: “ignore/quit”, “proceed as is”, “proceed with modified item”

These subroutines assist searching the index for the desired item. They can also assist in determining how updates are performed handling old/new 'keys' and changes to the 'index'.

All data stamps are GMT with the local offset passed when accessing these DIAM/ TIAM (Date/Time Indexed Access Method) files.

Oops - I made a mistake:

The change made was incorrect.

The change made was to the wrong record.

The change was made using the wrong 'date/time'.

The index flags and user exit points can determine if a single record can be deleted forever or if the original must be preserved and a “deleted”/null record added. There are many situations where a record can be removed, and just as many where it cannot.

General database queries are always made with a “as of when” date and optional flags.

I use “date/time” loosely - It may in fact be a date, a date/time value, true GMT or GMT with a user offset. It may also be user defined/supplied or in some cases could be a 'true' current system supplied value.