Было ли что-то в Коболе, что делает его восприимчивым к проблемам 2000 года?
Я знаю, что многие усилия и нападки Y2K были так или иначе сосредоточены на COBOL, заслуженно или нет. (черт, я видел небольшую ошибку Y2K в скриптах Perl, которая сломалась 1 января 2000 года)
Что меня интересует, было ли что-то особенное для COBOL как языка, который делал его восприимчивым к проблемам 2000 года?
То есть, в отличие от просто возраста большинства программ, написанных на нем, и последующей необходимости экономить на использовании памяти / диска из-за старого оборудования и того факта, что никто не ожидал, что эти программы выживут в течение 30 лет?
Я совершенно счастлив, если ответ "ничего конкретного для COBOL, кроме возраста", - просто любопытно, ничего не зная о COBOL.
12 ответов
Да и нет. В COBOL вы должны были объявлять переменные так, чтобы вы фактически должны были сказать, сколько цифр было в числе, т. Е. YEAR PIC 99 объявил переменную YEAR такой, что он может содержать только две десятичные цифры. Так что да, было легче совершить эту ошибку, чем в С, если бы вы имели int или же short или же char как год и все еще есть много места для лет больше 99. Конечно, это не защищает вас от printfИНГ 19%d в C и по-прежнему возникают проблемы в вашей продукции, или делать другие внутренние расчеты, полагая, что год будет меньше или равен 99.
Это было 80% о емкости хранилища, чисто и просто.
Люди не понимают, что емкость их жесткого диска сегодня стоила бы миллионы в 1980 году. Вы думаете, что экономить два байта глупо? Не тогда, когда у вас есть 100 000 записей о клиентах и жесткий диск размером с холодильник, вмещающий 20 мегабайт и требующий специального помещения для сохранения прохлады.
Увлекательный вопрос. В чем проблема Y2K? Это проблема недостаточного определения вашей вселенной. Не было никаких серьезных попыток смоделировать все даты, потому что пространство было более важным (и к тому времени приложения будут заменены). Поэтому в Cobol на каждом уровне важно: быть эффективным и не перегружать нужную память как на уровне магазина, так и на уровне программы.
Там, где важна эффективность, мы допускаем ошибки Y2Kish... Мы делаем это каждый раз, когда сохраняем дату в БД без часового пояса. Поэтому современное хранилище определенно подвержено ошибкам Y2Kish, потому что мы стараемся быть эффективными с использованием используемого пространства (хотя я держу пари, что во многих случаях он чрезмерно оптимизируется, особенно на уровне корпоративного перерасхода).
С другой стороны, мы избегаем ошибок Y2Kish на уровне приложения, потому что каждый раз, когда вы работаете, скажем, с датой (скажем, в Java), она всегда несет в себе тонну багажа (например, часовой пояс). Зачем? Поскольку Date (и многие другие концепции) теперь являются частью ОС, поэтому умные парни, создающие ОС, пытаются смоделировать полноценную концепцию даты. Поскольку мы полагаемся на их концепцию даты, мы не можем ее испортить... и она модульная и заменяемая!
Более новые языки со встроенными типами данных (и возможностями) для многих вещей, таких как дата, а также с огромной памятью, с которой можно играть, помогают избежать многих потенциальных проблем Y2Kish.
Это было две части. 1- возраст / срок службы программного обеспечения Cobol, и 2- ограничение в 80 символов для записей данных.
Во-первых, большинство программ этого возраста использовали только 2-значные числа для хранения года, поскольку никто не предполагал, что их программное обеспечение будет работать так долго! COBOL был принят банковской индустрией, которая печально известна тем, что никогда не выбрасывает код. Большинство других программ было выброшено, а банки - нет!
Во-вторых, COBOL был ограничен до 80 символов на запись данных (из-за размера перфокарт!), Разработчики были в еще большем давлении, чтобы ограничить размер полей. Потому что они решили, что "2000-го года здесь не будет, пока я не уйду в отставку!" 2 символа сохраненных данных были огромны!
Было ли что-то в Коболе, что делает его восприимчивым к проблемам 2000 года?
Программисты 1. И системы, в которых работают программы на языке COBOL 2.
1: Они не проектировали, ожидая 30 лет. Я не могу винить их на самом деле. Если бы у меня были ограничения памяти, между сжатием 2 байтов в день и обеспечением его работы 30 лет спустя, скорее всего, я бы принял то же решение.
2: у систем могла быть та же самая проблема, если бы аппаратное обеспечение сохраняло год в двух цифрах.
Казалось, что проблема заключается в том, что люди не знают, как долго будет использоваться их код, поэтому они решили использовать 2-значные годы.
Итак, ничего особенного для COBOL, просто программы на COBOL имеют тенденцию быть критическими и старыми, поэтому они более подвержены риску.
Проблема была действительно в ограничениях памяти и хранения в конце 70-х начале 80-х.
Когда ваш компьютер на четверть миллиона долларов имел 128 КБ и 4 диска общим объемом около 6 мегабайт, вы можете либо попросить руководство о другой четверти мельницы для машины 256 КБ с 12 МБ дискового пространства, либо очень эффективно использовать пространство.
Так что были использованы всевозможные приемы экономии места. Моим любимым было сохранить дату YYMMDD как 991231 в упакованном десятичном поле x'9912310C', затем выбить последний байт и сохранить его как'991231'. Таким образом, вместо 6 байтов вы заняли всего 3 байта.
Другие хитрости включали в себя некоторые хоккейные коды типа Hooky для цен - код 12 -> $19,99.
Единственная внутренняя проблема, связанная с Cobol, заключалась в его оригинальном (в конце 1960-х) стандартном заявлении для получения текущей системной даты, которое было:
ACCEPT todays-date FROM DATE
Это вернуло 6-значное число с датой в формате ГГММДД.
Однако даже это не обязательно было проблемой, так как мы написали код в 90-х годах, используя это утверждение, которое просто проверяло, была ли часть года меньше 70, и предполагало, что дата была 20YY, что сделало бы проблему Y2K070.:-)
Стандарт был расширен позже (я думаю, COBOL-85), чтобы вы могли запрашивать дату в разных форматах, например:
ACCEPT todays-date FROM CENTURY-DATE
Который дал вам 8-значный номер с датой CCYYMMDD.
Как вы и другие отмечали, многие другие языки программирования допускают представление даты / года с потерями.
COBOL никогда не поставляется с какой-либо стандартной библиотекой обработки дат.
Таким образом, каждый закодировал свое собственное решение.
Некоторые решения были очень плохими по отношению к тысячелетию. Большинство из этих плохих решений не имели значения, так как приложения не жили более 40 лет. Небольшое количество плохих решений вызывает известную проблему 2000 года в мире бизнеса.
(Некоторые решения были лучше. Я знаю, что системы COBOL, закодированные в 1950-х годах с форматом даты, действительным до 2027 года, должны были казаться вечными в то время; и я разрабатывал системы в 1970-х годах, которые будут хорошими до 2079 года).
Однако у КОБОЛа был стандартный тип даты....
03 ORDER-DATE PIC DATE.
.... Отраслевые решения были бы доступны на уровне компилятора, что сокращало бы сложность любого необходимого исправления.
Мораль: используйте языки со стандартными библиотеками.
Были некоторые вещи о COBOL что усугубило ситуацию.
- он старый, поэтому меньше пользы от библиотечного кода, больше доморощенного всего
- это старый, так что до интернета, до социальных сетей, больше NIH, меньше фреймворков, больше пользовательских вещей
- оно старое, поэтому менее абстрактное, с большей вероятностью имеет решения с открытым кодом
- он старый, так что, вернитесь достаточно далеко, и сохранение 2 байтов, возможно, было важно
- он старый, так что он предшествует SQL. Устаревшее операционное программное обеспечение даже индексировало ориентированные на записи файлы на диске, чтобы немного упростить процесс создания собственной базы данных в каждой программе.
- Строки формата "printf" и объявление типа данных были одинаковыми, все имели n цифр
Я видел гигантские программы на Фортране без реальных подпрограмм. Действительно, одна главная программа из 3000 строк, а не одна небиблиотечная подпрограмма. Я полагаю, что это могло произойти в мире COBOL, поэтому теперь вам нужно прочитать каждую строку, чтобы найти обработку даты.
У COBOL 85 (стандарт 1985 года) и более ранних версий не было никакого способа получить текущий век **, который был одним из факторов, присущих COBOL, который препятствовал использованию 4-значных лет даже после того, как 2-байтовое дополнительное пространство для хранения больше не было проблема.
** Определенные реализации могли иметь нестандартные расширения для этой цели.
Это было гораздо больше связано с сохранением года в элементах данных, которые могли содержать только значения от 0 до 99 (два символа, или две десятичные цифры, или один байт). Это и расчеты, которые сделали аналогичные предположения о значениях года.
Вряд ли это была особенность Кобола. Многие программы были затронуты.