4 ms·
that many years ago it was probably stored on tape and processed on a mainframe by a COBOL program. No database, it was probably stored as a string, and the app
by camiller 10y ago
that many years ago it was probably stored on tape and processed on a mainframe by a COBOL program. No database, it was probably stored as a string, and the application would likely have been fix to handle it before it was a problem.
- acdha 10y agoThat COBOL program almost certainly _is_ a database – not a SQL database but the COBOL language standard specifies structured records and allows you to specify whether a file is sequential or indexed (see e.g. https://en.wikipedia.org/wiki/COBOL#Data_division https://en.wikipedia.org/wiki/COBOL#Data_division). In the case of Y2K, the problem was often that people defined a date filed as three values all declared as PIC 99 (i.e. a two-digit number). If they migrated to 4 digits, we're fine until Y10K. If they added a window (values less n are 19xx, etc.) or switched to Unix timestamps or a SQL database – there are products which let a COBOL runtime transparently map the indexed file semantics to SQL statements – then it requires more information to say whether it's at risk.
- wolfgang42 10y agoI work with a COBOL database, and interestingly all of the dates are declared as four PIC 99 fields, like this: 02 ITM-LAST-CHG-DATE. 03 ITM-LC-DATE-CC PIC 99. 03 ITM-LC-DATE-YY PIC 99. 03 ITM-LC-DATE-MM PIC 99. 03 ITM-LC-DATE-DD PIC 99. I assume this split between 'CC' and 'YY' is a relic of the Y2K updates, so they could add in a whole new field with a default of '19'.