In the original design for DP4 resilience the duplex configuration was always used and reconciliation was carried out automatically by the ONLINE program.
The use of this program imposes a lot of additional constraints on database design. ONLINE is no longer often used, as it can prove to be unsatisfactory because of the subtle errors that failing to adhere to these constraints can introduce into a system.
If you want to use a duplex resilience architecture (with or without ONLINE) you need to bear the following in mind:
Records to be insertions must have a guaranteed unique primary key, so that there is no possibility of, say, two different transactions on the two servers having the same key. The conventional way to achieve this is to include the workstation identification in the key of the records to be inserted.
Amendments should not be made that depend on the prior state of the record. For example, an application that attempts to maintain a real-time stock balance is unsafe. If the servers are disconnected, and two workstations attempt to sell one item from the different servers, the stock balances on each will be decremented by one, a simple reconciliation program such as ONLINE will take no action since the records are the same. The remedy for this amendment problem is to have a background program on the servers which carries out the amendments on its own local database using the inserted transaction records.
It is not possible to reliably generate system wide unique numbers, for instance invoice numbers or order numbers, In particular, autoincrement numbers must not be used.