30 и 31 марта в Иркутске будет проходить конференция "Компьютерные технологии на пороге третьего тысячелетия", посвященная главным образом способам решения Проблемы 2000 года. Как бы мы не отмахивались от бесчисленных напоминаний со стороны производителей и средств массовой информации о существовании и значимости Y2K, сама собой эта проблема не исчезнет. Видимо, нам придется смириться с тем, что весь оставшийся год мы будем продолжать видеть цифру 2000 в строчках новостей со зловещими предостерагающими интонациями; с тем, что с наступлением 2000 года мы будем свидетелями самых разных по масштабу нанесения ущерба событий; с тем, что в 1999 году мы будем вынуждены протестировать свои системы со работу в "нулевом" году; с тем, что, возможно, мы приложим некоторые усилия и потратим некоторую сумму денег на устранение предсказанных нежелательных последствий. Придется - как бы нам все это не нравилось!
Большинство специалистов по информационным технологиям в различных организациях, а также индивидуальные пользователи знают о существовании Проблемы 2000. В большинстве своем они представляют себе эту проблему как нечто совершенно непредсказуемое, что может произойти с их компьютерными системами в ночь с 31 декабря 1999 на 1 января 2000 года. При этом их ожидания разнятся от отсутствия какого-либо воздействия до полного разрушения самих компьютеров.
Сегодня огромное количество компаний и консультантов во всем мире пытаются помочь в решении Проблемы 2000. Для России очень актуальна проблема адаптации к 2000 году настольных систем на базе ПК, поскольку в нашей стране именно ПК широко используются для выполнения критически важных приложений самого различного уровня. Организации используют программы для ПК для финансовых расчетов, а также для анализа и прогнозирования. Некорректная интерпретация календарных данных в таких приложениях, безусловно, приведет к существенным потерям.
Потенциальные проблемы перехода на 2000 год для настольных и мобильных компьютеров можно объединить в 4 основные группы:
Аппаратное обеспечение;
Операционные системы;
Прикладное ПО, включая индустриальное, малотиражное и уникальное;
Данные, включая базы данных, электронные таблицы, неструктурированные, а также передаваемые данные, т.е. данные в форматах коммуникационных программ.
В большинстве их этих групп, особенно Данных, проблемы глубоко скрыты и трудно обнаруживаемы. В некоторых случаях эффект 2000 года может начать проявляться далеко за пределями точки перехода.
Аппартное обеспечение
Аппратные проблемы ПК сосредоточены в Базовой системе ввода/вывода (BIOS) и системных часах реального времени (real time clock, RTC). Большинство BIOSов, выпущенных до 1997 не адаптированы к 2000 и пользователи таких компьютеров будут испытывать соответствующие проблемы.
Вне зависимости от заявлений изготовителей самих BIOS-микросхем или сборщиков персональных компьютеров никто достоверно не может сказать, являются ли BIOS и часы данного конкретного компьютера совместимыми с 2000 годом, пока не проведет соответствующие тесты, которые, безусловно, не проводились при создании этих компонентов. Самые грубые оценки, сделанные в США, говорят о том что до 60% систем на базе Pentium и до 85% более старых моделей могут быть подвержены аппаратной составляющей Проблемы 2000.
BIOS поддерживает внутримашинную дату и время. У ПК с Year 2000 Ready BIOS первые две цифры внутреннего календаря установлены в 19. Последующие две цифры представляют собой счетчик, увеличивающийся на единицу один раз вгод. Когда счетчик перейдет через 00, такие компьютеры автоматически переведут первые две цифры даты с 19 на 20 и, таким образом, корректно обработают переход 2000 года.
Подобно ПК, готовым к 2000 году, в устаревших моделях первые две цифры даты установлены в 19, а последующие являются счетчиком. В этих компьютерах, однако, первые две цифры зафиксированы жестко и не могут быть обновлены. Как следствие, при переходе последних двух цифр через 00 BIOS не переведет первые две цифры на 20. Некоторые из таких машин автоматически установят новую дату в 1980 (год, который в базовых продуктах Microsoft считается точкой "всеобщего начала времени"). Другие машины просто установят новую дату в 1900 год.
Некорректная дата в BIOS влияет не только на операционную систему, но также и на все приложения, которые запрашивают текущие дату и время. Это происходит потому, что операционная система ПК считывает текущую дату из BIOS и поддерживает ее независимо, обычно, вплоть до момента отключения питания.
Хотя подобные аппаратные особенности могут создавать существенные проблемы, их достаточно легко идентифицировать и исправить на большинстве ПК - либо через программное обновление BIOS, либо путем замены необходимых аппаратных компонентов. Лишь небольшая часть наиболее "старых" ПК не может быть исправлена и потребует полной замены.
Сегодня в Интернете находится довольно много бесплатных тестов, которые помогут ответить на вопрос, сможет ли компьютер перейти через 2000 год. Например, ПК такие тесты проверяют работу функций BIOS и DOS, проводя тест перехода через первое января 2000 и 2001 года, а также то, хранит ли BIOS даты после 2000 года.
Операционные системы
Пакеты исправлений Проблемы 2000 в настоящее время предоставлены большинством производителей устаревших операционных систем, таких как Windows 3.1 или NetWare 3.x. Организации и индивидуальные пользователи могут легко реализовать эти обновления, хотя в крупных распределенных организациях с большим числом ПК подобные мероприятия потребуют существенных затрат времени и трудовых ресурсов.
Производители заявляют, что Windows 95, Windows 98, Windows NT и NetWare 4.x полностью совместимы с 2000 годом. Однако, до сих пор в прессе появляются отчеты, отмечающие возможность существования проблем и в "благополучных" операционных средах.
Приложения
Огромное количество приложений для ПК выполняют внутренние вычисления относительных дат, и многие из них используют для этого двухзначный формат представления даты. Это, безусловно, может создавать проблемы. Программа кредитных расчетов, например, может вычитать в двузначном формате из даты окончания кредитного периода начальную или текущую дату для определения параметров погашения или овердрафта, а также для расчета даты инвойсирования клиента. Если кредитный период переходит через 2000 год, такая программа будет генерировать ошибочные результаты с реальными финансовыми потерями. Кроме того, зачастую результаты календарных вычислений зависят от метода, которым приложение интерпретирует двухзначные даты.
Некоторые приложения априори полагают первые две цифры равными 19. Другие используют метод "точки перегиба". Например, Lotus 1-2-3 97 использует точку перегиба 49/50, то есть предполагает, что даты с последними цифрами от 00 до 49 представляют 2000-2049 годы, а с цифрами 50-99 - годы с 1950 по 1999 соответственно.
Усложняет данную проблему тот факт, что даже разные версии тех же самых приложений могут имет разные точки перегиба. Например: MS Excel 95 интерпретирует числа от 00 до 19 как 2000-2019 годы, а все остальные - как 19yy, в то время как MS Excel 97 интерпретирует 00-29 как 2000-2029, а все остальные - как 19yy. MS Access 95 интерпретирует все двухзначные даты как 19yy, в то время как MS Access 97 интерпретирует 00-29 как 2000-2029, а все остальные - как 19yy.
Особо хочется остановиться на отечественных разработках. Наши программисты зачастую придумывали совершенно фантастический код для обработки дат. Естественно, о 2000 годе несколько лет назад никто не думал. Для отечественных программ появляется еще один тип проблемы - возможность различной реакции на 2000 год различных участков внутри одной и той же версии.
Таким образом, организации, использующие одновременно различные версии одного и того же приложения, например, в силу аппаратных или лицензионных ограничений, и обменивающиеся данными внутри организации, подвергаются опасности генерации и распространения непредсказуемых результатов. А так как подобных приложений может быть достаточно много, нетрудно представить себе достаточно хаотичные последствия.
Поэтому организации должны составить полный реестр используемых приложений и их версий и определить наличие исправляющих их обновлений. Затем они должны выработать выравнивания и обновления своих приложений к 2000 году.
Данные
Аномалии данных, хранящихся и обрабатываемых персональными компьютерами, представляют одну из наиболее важных и трудно идентифицируемых проблем. Эти аномалии могут проявляться, в основном, в двух областях:
1) В файлах баз данных и электронных таблиц;
2) В файлах данных, используемых для передачи информации из централизованных приложений на ПК.
СУБД и электронные таблицы обычно хранят даты в формате внутреннего представления. Как правило, они используют при этом т.н. "безопасный формат". В отличие от электронных таблиц, форма представления даты в СУБД обычно способна хранить даты до 1900 года, а также далеко вперед за 2000 год. Однако, зачастую в них остается возможность хранения даты и в текстовом формате. Фактически, MS Access и другие "персональные" СУБД неявно поощряют использование текстового формата, предоставляя большое количество встроенных функций работы с датами в текстовой форме. Так же, как и в случае электронных таблиц, подобные функции используют внутренние методы установки столетия при интерпретации двухзначных дат.
Различные СУБД делают это по-разному. Некоторые из них просто помещают все двухзначные даты в наше столетие. Другие используют метод точки перегиба. Многие приложения СУБД имеют дополнительную проблему, когда данные внутренне хранятся в четырехзначном формате, а представляются на экране или в отчетах как двухзначные для экономии места. В результате пользователь даже не может определить, существует ли в его приложении проблема 2000 года.
Эта проблема является прямым следствием стремления создавать экранные формы, в максимальной степени соответствующие их печатным аналогам. Все мы помним, что еще несколько лет назад одним из основных требований заказчиков финансовых, банковских и других систем к разработчикам было точное следование бумажным стандартам, что заставляло программистов и дизайнеров проявлять чудеса изобретательности и миниатюризации, втискивая полностраничные
документы в экран VGA монитора. И первое, что подвергалось усечению, это цифры 19 в поле "год".
Многие приложения баз данных используют маски ввода, предоставляя пользователю возможность ввода только двух цифр даты, хотя внутри приложения дата может храниться в четырехзначном формате. В результате пользователь может не иметь возможности ввода правильной даты даже вручную.
Самое смешное, что некоторое время существовала целая индустрия средств автоматизации и дизайна таких масок ввода. Достаточно вспомнить многочисленные дополнительные библиотеки визуальных классов для систем разработки Borland или Microsoft. Как всегда, наши программисты не отставали от своих зарубежных коллег и создавали собственные библиотеки экранных элементов. Интересно, какие алгоритмы обработки дат были в них реализованы?
Передача данных с одного компьютера на другой представляет еще одну, и, может быть, еще более сложную проблему. В организациях данные часто передаются из централизованных приложений (работающих в технологии мэйнфрейм или клиент-сервер) на ПК для использования в электронных таблицах, приложениях баз данных и других. При этом даты зачастую передаются в текстовом виде. И даже если оба приложения, центральное и локальное, корректны по отношению к переходу через
2000 год, они могут интерпретировать даты по-разному (например, используя различные точки перегиба), что в результате может привести к появлению расхождений и ошибок. При этом постоянный обмен данными между системами будет постоянно воспроизводить проблемы на машинах, которые перед этим были проверены и исправлены.
Критические дни
Большинство людей во всем мире проблему 2000 года воспринимают как переход через "дьявольское число" 1 января 2000 года. И это верно. Однако, специалистам известны еще, как минимум, 4 "дьявольских числа", имеющих непосредственное отношение к Проблеме 2000.
9 сентября 1999 года. Наиболее близкое к нам "дьявольское число". В традиционной компьютерной нотации 9999. Многие приложения воспринимают это число как "конец всего", "конец времени", "нет больше данных" и так далее. В сущности, преодоление этого числа - скорее вопрос изменения критических параметров и сигналов внутри программы, а не проблемы обработки или представления дат. Основная опасность 9 сентября состоит в том, что его влияние крайне трудно идентифицировать.
29 февраля 2000 года. Да, пресловутый 2000 год к тому же еще и високосный. А високосные годы и в прежние времена нередко приводили к ошибкам в приложениях. В 2000 году они только добавят головной боли разработчикам и пользователям.
1 января 2001 года. Реальное наступление нового столетия и нового тысячеления одновременно. Не стоит забывать, что представление, обработка и отображение информации о столетии зачастую является самостоятельной компонентой приложений.
29 февраля 2004 года. Первый високосный год нового века. Все предыдущие проблемы в "одном флаконе". Остается только надеяться, что до 2004 года очень многое может измениться.
Безусловно, проверка соответствия компьютера, приложения или файла данных на соответствие Проблеме 2000 обязательно должна включать проверку для всех критических дней.
План 2000
Чтобы избежать проблем, связанных с несовместимостью персональных компьютеров с 2000 годом в самом широком смысле, организации должны с самого начала включить их в свои административно-технологические планы подготовки к 2000 году, а пользователи самостоятельно проводить подобные мероприятия. Грамотно составленный план и использование правильно подобранных средств, в том числе программных, позволит тщательно и быстро распознать проблемы, минимизировать влияние мероприятий на пользователей и общую производительность систем и своевременно подготовить информационные системы к вступлению в новое тысячелетие.
В следующем номере "CR" читайте о том, каким программным обеспечением воспользоваться для проверки корректности системы на работу в 2000 году, какие конкретные меры предпринимать конечным пользователям и ответственным лицам по устранению проблемы 2000.
|
.gif){kind=small}
