Well, when constraints and stuff first came out I had some issues where I
had to delete the files and rebuild them. That PMR was open for a long
time. But jeepers that was a LONG time ago.
The database cross reference files used to get corrupted quite regularly
resulting in a demand for RCLSTG *DBXREF.
And part of this depends on your definition of corruption.
- if you don't use journalling and commitment control and your transaction
updates the order header but fails to get to the order detail file because
of a system failure or some such thing, do you count that as corruption?
- if your item master file has two item identical item numbers because the
vendor refuses to use primary keys and refuses to put unique keys on their
indexes do you count that as corruption?
- if you have orphan children records (like order detail records with no
matching order header records) because of a design refusal to have
referential constraints do you count that as corruption?
Or is the criteria for meeting your definition of corruption "must have
never happened on IBM i or it's predecessors"? Granted, decades ago I
worked on PICK OS. And there were times when really weird stuff would
happen (like reading one row and getting the data for another) and you
routinely restored. Often you could save that file and restore it and
that cleaned up the corruption. This is probably more of what you meant.