The extreme version of the object revolution was to keep that state abstracted (hidden) inside some object and thus to insure various consistency properties of the data. A relational data base system is perhaps the most advanced general technology in this direction. I wonder how often users of such systems think they must dump out the data to flat ASCII files so that they can be sure that they still can. Relational systems have extensive facilities to change the internal representation while leaving the logical state fixed. Few of the Keykos abstractions had such facility.
I do not understand the details of the technology that IBM uses to guard the abstractions of VSAM files or DB2 but I know it goes beyond those available in Unix. I suspect that there is specific VSAM logic and DB2 logic to ensure that the stable store represents a consistent state of the data base in case of abrupt failure, i.e. crash. It is just such logic that is unnecessary in Keykos, for the code that is midway thru a transaction will resume where it left off upon checkpoint recovery. When the transaction included elements outside the computer, such as an ATM, and those transactions were too frequent to take checkpoints then indeed application logic was required to record the essence of the transaction in a place that was stable and not rolled back upon checkpoint recovery.
Keykos really handled ATM in one such application. The hardware was so reliable that this logic may not indeed have been tested in practice. It was well tested in rehearsed crashes.
Perhaps the angst of the person responsible for the integrity of a mission critical system stems from knowing that there is essential data that he cannot reach to fix. Our faith was that it was just this inability that had some chance of guarding the data so that it didn’t need fixing. In Keykos it is possible to provide capabilities that enable the violation of any particular abstraction. The installer of the abstraction code is in a position to leave such capabilities behind.