Проблема 2000

До наступления 2000 года остается все меньше времени. Все более заметны усилия компаний и государственных организаций, стремящихся найти за оставшиеся месяцы адекватное решение проблем, вызванных наступлением нового тысячелетия. Вполне очевиден резко возросший в последнее время интерес к технической стороне дела. Он, видимо, объясняется тем, что в нашей стране началась (по крайней мере, в наиболее ответственных и технически подготовленных организациях) реальная работа по тестированию информационных систем на предмет их готовности к наступлению 2000 года.

В ряде случаев успешному проведению этих работ препятствует слабая информированность руководителей отделов информационных технологий и технических специалистов в той части, которая касается степени готовности используемого программного обеспечения к приходу 2000 года. Материалы данного номера Jet Info призваны восполнить этот пробел.

В первой части статьи мы попытались сделать некоторое теоретическое введение в Проблему 2000 года, обратив особое внимание на критерии Британского Института Стандартов. Во второй части акцент сделан на практических рекомендациях, которые помогут правильно сориентироваться при решении Проблемы-2000.

2. Проблема 2000

Известная трактовка проблемы 2000 года звучит следующим образом. При выполнении операций с датами, в которых год представлен двумя последними цифрами (например, 1987 год представлен как «87»), может возникнуть ошибка в вычислениях, связанная с неоднозначной трактовкой столетия.

Поскольку во множестве компьютерных систем обработка дат является одной из наиболее критичных частей вычислительного процесса, данная ошибка может привести к существенным сбоям в энергетических, финансовых, военных системах, что чревато непредсказуемыми последствиями.

Разумеется, подобная трактовка далеко не исчерпывает всего многообразия проблемы. Необходимо понимать, что, несмотря на название, сама по себе это не проблема 2000 года, но проблема, вызванная неаккуратным обращением с представлением времени в компьютерных системах. Одним из примеров небрежного описания даты является двузначное обозначение года. Понятно, что указание только двух последних цифр года создает неоднозначность в трактовке года. Запись «12 февраля 54 года» не может трактоваться однозначно, так как непонятно, какое столетие и тысячелетие имеется в виду. Вся беда в том, что существующие информационные массивы содержат значительную часть дат именно в такой форме. В текущем столетии даты в такой «короткой» записи интерпретировались однозначно – по умолчанию считалось, что все даты принадлежат двадцатому столетию. На рубеже веков такая интерпретация уже не проходит, так как в вычислениях над датами могут встретиться даты как текущего, так и следующего столетий.

Вообще говоря, запись года двумя последними цифрами – всего лишь один из примеров неаккуратного обращения со временем, которое в практике программистов весьма распространено. Приходилось сталкиваться с системами, в которых год, месяц и день хранились обособленно как целые неотрицательные числа, причем для обозначения неизвестного дня использовалось значение «0», а верхняя граница для значений дней не отслеживалась, что создавало любопытные эффекты вроде «нулевого марта» или «сорок пятого апреля».

Необходимо также понимать, что уже после наступления «роковой» даты придется выполнить огромный объем работы по приведению информационных систем в состояние, которое позволит им правильно обрабатывать даты. Парадокс в том, что сейчас мы просто плохо представляем себе масштаб и объемы предстоящей работы, а окончательно мы сможем его оценить уже в новом году. Поэтому ошибаются те, кто думает просто «пересидеть» 1 января 2000 года в расчете на то, что, миновав эту дату, системы продолжат работу в прежнем режиме.

3. Критерии Британского Института Стандартов

Очевидно, что невозможно спланировать и осуществить какие-либо реальные действия по подготовке информационных систем к наступлению нового столетия, если исходить из бытового, утилитарного понимания «Проблемы 2000 года». Напротив, практические действия предполагают выработку определенных критериев соответствия информационных систем требованиям, вытекающим из проблемы 2000 года (далее для простоты мы будем называть их попросту требованиями 2000 года). Эти критерии представляют собой нормативную базу для всей дальнейшей работы. Без них говорить о каком-либо успехе вряд ли имеет смысл.

Британский Институт Стандартов (British Standards Institution) в ответ на многочисленные запросы промышленных и финансовых организаций Великобритании разработал критерии соответствия, сформулировав их в документе DISC PD-2000-1:1998 «A Definition of Year 2000 Conformity Requirements». Лаконичные и исчерпывающие, они могут послужить хорошей теоретической и практической основой для организаций, всерьез озабоченных работоспособностью своих информационных систем в контексте наступления нового столетия.

Критерии сформулированы в виде четырех правил нормальной работы компьютерных систем. Вначале мы приведем все четыре правила, затем рассмотрим их более детально.

Первое правило. «Не должно существовать значений текущей даты, способных вызвать нарушения в работе [системы]» или «Значение текущей даты не должно вызвать нарушений в работе [системы].

Второе правило. «Функции, оперирующие с датами, должны правильно выполняться для дат, предшествующих 2000 году, дат 2000 года и дат после него».

Третье правило. «Даты должны храниться и быть определены во всех интерфейсах таким образом, чтобы столетие было задано однозначно либо вычислялось по алгоритмам или правилам вывода, исключающим двусмысленное толкование [столетия].

Четвертое правило. «2000-й год должен считаться високосным».

Теперь остановимся на данных правилах более подробно.

3.1. Общая целостность

Первое правило известно как Общая целостность (General Integrity).

Соответствие этому правилу заключается в том, что операции прокрутки (roll-over), выполняемые над составными элементами-полями даты (день, месяц, год, столетие), должны выполняться корректно, то есть получаемые в результате операций прокрутки даты должны соответствовать общепринятому Григорианскому календарю.

Для объяснения этого правила воспользуемся удобным сравнением. Рассмотрим пример встроенного таймера с электронным табло, учитывающего даты в формате «день – месяц – год». То есть полями даты являются:

поле дня;
поле месяца;
поле года.

Операция прокрутки означает увеличение (прокрутка вперед) или уменьшение (прокрутка назад) на единицу значения одного, двух или трех полей даты, то есть значений дня, месяца, года. По аналогии с обычными электронными бытовыми приборами со встроенным таймером операция прокрутки инициируется нажатием кнопки up и down.

Операция прокрутки, выполненная над граничными значениями полей, приводит к изменению и других полей даты.

Так, при достижении граничных значений по порядковому номеру дня (тридцатое или тридцать первое число месяца при прокрутке вперед и первое число месяца при прокрутке назад) должно корректно измениться соответственно значение месяца, например:

day_up (28 февраля 1999 года) –> 1 марта 1999 года;

day_down (1 января 2000 года) –> 31 декабря 1999 года.

Пользуясь этим правилом, можно на практике убедиться, соответствует ли Ваш компьютер требованиям 2000 года.

3.2. Целостность по датам

Второе правило известно как Целостность по датам (Date Integrity).

Это правило означает, что все оборудование и все программные продукты должны корректно осуществлять вычисления и манипуляции с датами и корректно представлять даты для достижения тех целей, для которых они (оборудование и программные продукты) предназначены.

В определении правила под функциями, оперирующими с данными, подразумевается как сами функции (то есть процессы, операции), так и результаты функций, то есть имеется в виду то, что обычно обозначается термином «функциональность».

Важным дополнением к правилу является следующее требование. Никакое оборудование и никакие программные продукты не должны использовать специфические значения дат в ином, нежели значения даты, смысле. Часто, например, значение ‘99’ используется в качестве метки конца файла, значение ‘00’ – в качестве метки начала файла и так далее. Считается, что это недопустимо.

3.3. Исчерпывающее/Подразумеваемое определение столетия

Третье правило известно как Исчерпывающее/Подразумеваемое определение столетия (Explicit/Implicit Century).

Его суть заключается в применении правил, однозначно определяющих столетие, к которому относится рассматриваемый год. В нормальной четырехсимвольной записи представление года содержит два поля:

поле столетия (две первых цифры);
поле года (две последние цифры).

Так, в записи «1965-й год» число «19», представленное первыми двумя цифрами – это порядковый номер столетия (девятнадцатое столетие); число «65», представленное двумя последними цифрами, – это порядковый номер года в столетии (шестьдесят пятый год). Необходимо понимать, что, говоря о номере столетия, мы имеем в виду именно порядковый номер столетия, начиная с Рождества Христова. В этой трактовке начальное столетие имело номер «ноль» (0036-й год – тридцать шестой год нулевого столетия). Напомним, что традиционная трактовка века подразумевает, что начальное столетие имело порядковый номер один – именно поэтому мы говорим о текущем столетии «двадцатый век».

Удовлетворение третьему правилу достигается при использовании одно из двух возможных подходов:

(a). Исчерпывающее представление столетия в дате: достигается, например, за счет использования четырех цифр или посредством включения индикатора столетия. Первый вариант понятен (кстати, представление года четырьмя цифрами рекомендовано стандартом ISO 8601:1998), второй предполагает запись «ZZ-й год YY-го столетия», где YY – это индикатор столетия.

Индикатор столетия вместо представления года четырьмя цифрами может быть использован в тех случаях, когда национальные стандарты (например, стандарты электронного обмена данными), предписывающие двузначное представление года, имеют приоритет перед международными стандартами.

(b). Использование правил вывода. Например, год, представленный числом ZZ из двух цифр, где ZZ > 50, относится к девятнадцатому столетию, то есть это год 19ZZ-й; если ZZ <= 50, то год относится к двадцать первому столетию и это год 20ZZ-й. Правила вывода столетия должны быть применимы в любом контексте, где может быть использована дата, хотя различные правила вывода могут применяться к различным наборам дат.

Везде, где элемент даты – номер года – представлен без номера столетия, необходимо однозначное определение столетия, выводимое из номера года ZZ и текущего контекста.

3.4. Правило високосного года

Четвертое правило известно как правило високосного года. Високосный год определен в стандарте ISO 8601:1988 следующим образом:

«Год, високосный: В Григорианском календаре год, имеющий 366 дней. Високосным считается год, делящийся на 4 без остатка, за исключением ситуации, когда это – год столетия, который не делится на 400 без остатка».

Иными словами, високосным считается год, который делится на четыре без остатка, если при этом он не делится без остатка на сто (то есть годы столетий – 1800-й, 1900-й – не являются високосными). Однако из этого правила есть исключение. Если год делится на четыре без остатка, делится на сто без остатка, но при этом еще и без остатка делится на 400, то он считается високосным. Именно таким годом, встречающимся раз в 400 лет, и будет 2000-й год.

4. Требования корпорации Oracle

Специалисты корпорации Oracle, опираясь на критерии Британского Института Стандартов, разработали собственный набор требований, который расширяет и конкретизирует базовые критерии. Эти требования приведены в документе «Oracle Products and Year 2000 Compliance». Данный документ содержит также исчерпывающую информацию о степени соответствия всех без исключения программных продуктов Oracle требованиям 2000 года; новый релиз документа выходит ежемесячно. Скопировать документ (в формате PDF) можно, обратившись по адресу http://www.oracle.com/year2000/white_paper.html.

Согласно точке зрения корпорации Oracle, в понятие «Соответствие требованиям 2000 года» включается выполнение пяти основных требований к программному обеспечению, касающихся обработки данных типа DATE:

(1) Программы должны корректно обрабатывать даты до наступления 1-го января 2000 года, саму дату 1-е января 2000 года, и все последующие даты при вводе даты, при выводе даты и при выполнении вычислений с датами и/или их частями.

(2) Функции, оперирующие с датами, должны одинаково корректно выполняться до 1 января 2000 года, непосредственно в день 1 января 2000 года и после 1 января 2000 года

(3) При вводе значения года в виде двух последних цифр столетие должно трактоваться однозначно.

(4) Программы должны обеспечивать хранение и вывод дат в таком виде, который исключает двусмысленность толкования относительно используемого столетия.

(5) Программы должны обрабатывать данные в соответствии с правилом определения високосных лет, согласно которым 2000-й год будет високосным.

Ниже на примерах будет, каким образом указанные требования учтены в программных продуктах Oracle.

4.1. Тестирование на соответствие

Корпорация Oracle тщательно следует разработанным критериям соответствия. Во-первых, все вновь разрабатываемые продукты Oracle создаются с учетом требований 2000 года. Во-вторых, все без исключения программные продукты Oracle подвергаются комплексной процедуре тестирования на предмет соответствия требованиям 2000 года. Тестирование продуктов выполняется в следующих категориях тестов.

Анализ продукта – все продукты, так или иначе взаимодействующие с СУБД Oracle (то есть практически все), были подвергнуты анализу на зависимость от дат. Проще говоря, если продукт работал с данными типа дата, то он попадал в следующую категорию по регрессионным тестам.

Регрессионные тесты подтверждают тот факт, что программные продукты корректно работают с датами, начиная с 1-го января 2000 года. Ранее для многих продуктов Oracle уже были разработаны регрессионные тесты, которые и использовались для определения зависимости от даты 2000-го года.

Для комплексного тестирования были использованы сценарные тесты. Эти тесты доказывают, что конкретный программный продукт корректно (то есть в соответствии с документацией) функционирует в некоторый временной период, охватывающий последние часы 1999 года и первые часы 2000-го года. Например, для процесса резервирования и восстановления был выполнен сценарный тест, который эмулировал временной интервал с 1999 по 2000 год. Согласно условиям теста, процесс резервирования стартовал в 23:45 31 декабря 1999 года. После этого было выполнено несколько обновлений базы данных. Сервер баз данных был остановлен в 23:55 и корректно рестартовал в 00:05 уже в 2000 году.

Специальным подразделением корпорации Oracle (Oracle's Development Organization) были подготовлены и проведены тесты различных операционных сценариев развития событий в связи с наступлением 2000 года. В эти сценарии были включены тесты по репликации баз данных, восстановлению баз данных по состоянию на заданное время, распределенным транзакциям, а также управлению системой и сетевыми характеристиками при смене часовых поясов и столетия. Тестирование новых версий продуктов Oracle осуществляется по мере их появления.

4.2. Информация о соответствии

Информация о соответствии периодически публикуется в виде новых релизов документа «Oracle Products and Year 2000 Compliance». Фактически это – официальное сообщение о соответствии текущих продуктов Oracle требованиям 2000 года.

Согласно принятой в документе классификации, все продукты Oracle разделены на две группы. В первую – текущие продукты (current products) – попадают все продукты, техническая поддержка которых проходит по категории OracleMETALS. Это – все поставляемые в настоящий момент программные продукты Oracle.

Вторая группа объединяет устаревшие продукты (mature products). Дело в том, что программные продукты, которые поставлялись несколько лет назад, а затем по различным причинам были исключены из официального списка поставляемых, все еще используются некоторыми организациями. В эту группу попадают продукты, для которых уже опубликованы уведомления о снятии с поддержки и/или продукты, относящиеся к категории «Требуют расширенной поддержки».

Табл. 1. Уровни соответствия требованиям 2000 года.

Выделено четыре уровня соответствия требованиям 2000 года (см. табл. 1).

В официальном сообщении для каждого продукта или набора продуктов указывается номер версии и уровень соответствия. Практически все текущие продукты Oracle ПОЛНОСТЬЮ СООТВЕТСТВУЮТ требованиям 2000 года, что подтверждается тестами, выполненными по приведенной выше методике. Разумеется, в рамках небольшой статьи мы не можем опубликовать все таблицы соответствия. Заинтересованные читатели имеют возможность обратиться к автору, и им будут высланы все официальные материалы.

Обратим особое внимание на то, что часть устаревших продуктов не удовлетворяет требованиям 2000 года, или удовлетворяет им не полностью. В эту категорию попадают Oracle RDBMS Version 6, SQL*Forms Version 3.0 & SQL*Menu Version 5.0, SQL*Forms Version 2.0/2.3, SQL*ReportWriter Version 1.1, SQL*Report Version 1.0 (RPT), Oracle Forms Version 4.0, Oracle Reports 2.0 & Oracle Graphics 2.0 (CDE1), Oracle Data Query Version 3.0, Oracle CASE / Dictionary Version 5.1, Oracle Core Applications Version 9, Oracle Applications Rel. 10.5/10.6, CDDPLUS.

Организациям, использующим устаревшие продукты, предлагается как можно скорее рассмотреть вопрос об их модернизации до уровня поддержки OracleMETALS с тем, чтобы обновить версии используемых продуктов Oracle, свести к минимуму все работы по преобразованию дат и получить требуемый уровень технического сопровождения продуктов.

5. Oracle Server

Так как подавляющее большинство клиентов корпорации Oracle в нашей стране из всего спектра программных продуктов Oracle используют именно сервер баз данных, в этой статье мы решили обратить на него особое внимание.

Семейство продуктов Oracle Server ПОЛНОСТЬЮ СООТВЕТСТВУЕТ требованиям 2000 года. Приложения, которые используют СУБД Oracle (серверы Oracle7 и Oracle8), а также тип данных DATE (только для дат и/или для дат и времени) будут корректно выполнять операции с данными типа DATE, извлеченными из баз данных Oracle.

Для хранения данных типа DATE серверы Oracle7 и Oracle8 используют формат, предусматривающий четыре позиции для года, две

позиции для месяца и так далее для всех остальных компонентов вплоть до секунд (общий вид «YYYY:MM:DD:HH24:MI:SS»). Фактически, это прямое следование требованию (4), упомянутому выше. По сути, дата должна быть представлена исчерпывающе, то есть в таком виде, который исключал бы двусмысленность толкования значения любого из ее компонентов. Oracle обеспечивает четырехзначное представление даты, следуя требованиям стандарта ISO 8601:1988.

Формат «YYYY/MM/DD HH24:MI:SS» имеет следующие достоинства:

он не зависит от языковой среды, так как месяцы хранятся в числовом виде;
в него заложено полное четырехразрядное представление года, так что не может возникнуть никакой двусмысленности со столетиями;
время представлено полностью, причем более значимые элементы записываются первыми, так что при операциях сортировки по символьным полям даты будут отсортированы в требуемом порядке.

Единственным недостатком этого представления дат следует признать отсутствие поддержки дат до рождества Христова.

5.1. Формат дат «RR»

5.1.1. Определение формата

Требование (3) состоит в однозначной трактовке столетия при вводе и передаче серверу даты, в которой год представлен двумя последними цифрами (двузначное представление года). Согласно критериям соответствия Британского Института Стандартов, должен быть разработан алгоритм, однозначно идентифицирующий столетие в случае двузначного представления года. Однозначная трактовка столетия достигается при использовании формата дат «RR». Ввиду исключительной важности формата для практической работы рассмотрим его подробнее.

Применение формата «RR» дает предписание интерпретировать столетие, к которому относится дата с двузначным представлением года, в соответствии с правилами, приведенными в табл. 2.

Следовательно, независимо от того, какое столетие было текущим во время ввода данных, использование формата «RR» гарантирует, что год будет загружен в базу данных в следующем виде:

Если текущий год (на момент загрузки) – во второй половине столетия (50 – 99)

и введен двузначный год между «00» и «49», то год будет загружен как год следующего столетия. Например, год «02», введенный в 1996 году, будет загружен как «2002».
и введен двузначный год между «50» и «99», то год будет загружен как год текущего столетия. Например, год «97», введенный в 1996 году, будет загружен как «1997».

Если текущий год (на момент загрузки) – в первой половине столетия (00 – 49)

и введен двузначный год между «00» и «49», то год будет загружен как год текущего столетия. Например, год «02», введенный в 2001 году, будет загружен как «2002».
и введен двузначный год между «50» и «99», то год будет загружен как год предыдущего столетия. Например, год «97», введенный в 2001 году, будет загружен как «1997».

Формат даты «RR» пригоден для добавления в базу данных и обновления данных типа DATE. Он не требуется для выборки уже загруженных в БД данных, так как Oracle всегда загружает компонент даты YEAR в четырехзначном виде.

5.1.2. Примеры использования формата «RR»

Впервые формат данных «RR» введен еще в 1992 году для Oracle 7. Описание формата приведено в Oracle Technical Bulletin Reference 104296.626.

В этом документе приведен простой пример использования формата, который мы используем в Листинге 1.

Ниже рассмотрены примеры употребления формата RR. Для постоянного применения формата «RR» необходимо установить значение ‘DD-MM-RR’ параметра ‘NLS_DATA_FORMAT’.

Листинг 2 иллюстрирует эффектом от установки значений ‘DD-MM-YY’ и ‘DD-MM-RR’ параметра NLS_DATA_FORMAT.

Запрос (1) означает получение последнего дня месяца, указанного в запросе. По умолчанию параметр NLS_DATA_FORMAT имеет значение ‘DD-MM-YY’, следовательно, дата с двузначным представлением года будет интерпретироваться обычным образом, то есть как дата двадцатого века. Результатом запроса будет дата 28 февраля 1900 года (этот год не был високосным). Разумеется, подобный эффект будет иметь место только в случае «короткого» формата даты (год представлен двумя цифрами). В случае нормального представления даты, как это сделано в запросе (2) (год представлен четырьмя цифрами), результат будет верным – 29 февраля 2000 года (2000 год – это високосный год). Запрос даты в нормальном виде влечет за собой и вывод даты также в нормальном виде.

Листинг 1. Пример использования формата дат ‘RR’.

Листинг 2. Эффект от установки NLS_DATA_FORMAT.

Теперь установим значение ‘DD-MM-RR’ параметра NLS_DATA_FORMAT (это можно сделать, используя оператор ALTER SESSION, как это показано в запросе (3)). После этого запрос (4), аналогичный запросу (1), будет давать правильный результат. То есть год будет интерпретирован корректно, в соответствии с приведенными выше правилами, что мы видим по выдаваемому результату (29 февраля).

Обратим особое внимание на этот пример, так как в некоторых статьях (см., например, PC WEEK/RE, N48, 8 декабря 1998 года, «Готова ли ваша СУБД к 2000 году?») дается технически неверная трактовка поддержки дат в СУБД Oracle.

Листинг 3. Значение ‘DD-MM-YY’ параметра NLS_DATA_FORMAT.

Запрос (1) выполняется абсолютно правильно; приближение 2000 года диктует необходимость установки и постоянного применения (если имеется возможность ввода года в двузначном формате) формата ‘RR’.

При всей кажущейся простоте формата «RR» его нужно использовать аккуратно и осмысленно. Так, необходимо понимать, что, установив значение ‘DD-MM-RR’ параметра NLS_DATA_FORMAT на компьютере-сервере баз данных (в файле init.ora), мы выполнили только часть работы. Следует установить это же значение этого же параметра в регистрации на всех компьютерах-клиентах, где установлен SQL*Net Client (для Oracle7) или Net8 (для Oracle8). Необходимо иметь в виду, что данная установка параметра NLS_DATA_FORMAT изменяет значения только добавляемых в таблицу записей и никак не действует на записи, уже хранящиеся в таблицах.

Например, использование формата «RRRR» в операторе SELECT фактически не изменяет даты, которые не были введены (добавлены) в таблицу как даты двадцатого столетия, как это показано в Листинге 3. Дело в том, что в данном примере на сервере параметр NLS_DATA_FORMAT имеет значение ‘DD-MM-YY’. В этом случае неважно, используется ли маска ‘YYYY’ или ‘RRRR’ в функции TO_CHAR, так как последняя не выполняет актуальных преобразований.

Детали правильного применения формата дат ‘RR’ можно найти в статье «Get Compliant or Take Cover» (Rich Niemiec), опубликованной в журнале Oracle Magazine за январь/февраль 1999 года (статью можно прочесть на Web-сервере http://www.oramag.com).

5.1.3. Oracle RDBMS Version 6

Подобно Oracle7 и Oracle8, в СУБД Oracle версии 6 год представлен четырьмя цифрами. Единственная причина, по которой данная версия не может быть классифицирована, как полностью соответствующая требованиям 2000 года, заключается в том, что СУБД Oracle версии 6 не позволяет однозначно интерпретировать столетие при вводе даты с двузначным представлением года. То есть отсутствует механизм, аналогичный формату «RR» в версиях 7 и 8.

6. Инструментарий для тестирования

Корпорация Oracle рекомендует использовать для верификации кода приложений и выполнения регрессионных тестов для приложений набор продуктов третьих фирм. В этот набор входят:

Средства анализа исходного кода;
Средства регрессионного тестирования.

6.1. Средства анализа исходного кода

Средства (общее название UNRAVEL 2000 Tools for Oracle) реализованы в виде набора программных продуктов фирмы Ravel Software. Продукты позволяют анализировать исходные коды приложений, разработанных с помощью:

Oracle SQL*Forms 2.3;
Oracle SQL*Forms 3.0;
Oracle SQL*Forms 4.5/5.0;
Oracle PL/SQL;
Oracle RPT;
Oracle Report Writer 1.1;
Oracle Report Writer 2.5/3.0.

Программный продукт UNRAVEL 2000 Tools for Oracle включает следующую функциональность:

Impact Analysis: верификация исходного кода приложения с целью поиска «подозрительных» переменных и зависимости от них других переменных, сохранение найденной информации в репозитории и генерация статистического отчета.

Compliance Browser: визуализация исходного кода в виде логического дерева с данными и переменными, возможность добавления и исключения переменных и мониторинга прогресса исправления кода.

Semantics Matching. Продукт UNRAVEL 2000 является результатом совместных усилий Oracle Corporation и Ravel Software. Разработчики Oracle идентифицировали ключевые ошибки в датах, а специалисты Ravel Software обеспечили их учет в данном программном продукте методом семантического соответствия. Опытным путем было установлено, что от 80% до 90% ошибок, связанных с проблемой 2000-го года, идентифицируется с помощью данной технологии.

Delta Analysis является ключевой возможностью продукта UNRAVEL 2000. Он позволяет разработчикам Oracle отслеживать изменения, вносимые в код Oracle Applications и помещать информацию о них в репозиторий, который используется всеми модулями продукта.

Информация для контактов:

Ravel Software, Inc. 150 River Oaks Parkway, 2nd Floor, San Jose, CA 95134

Tel: 408-955-1990

Fax: 408-955-1991,

Sales: 800-526-0707

Support: 408-955-1990 http://www.unravel.com/oracle2

e-mail:y2ktools@us.oracle.com

6.2. Средства регрессионного тестирования

В качестве стандартного средства для регрессионного тестирования приложений корпорация Oracle выбрала программный продукт TestSuite 2000 компании Mercury Interactive.

Регрессионное тестирование выполняется после анализа и модификации исходного кода приложений средствами UNRAVEL 2000 Tools. Оно проводится для того, чтобы убедиться, правильно ли работает приложение в интересующий временной фрейм и, возможно, идентифицировать неисправленные еще ошибки.

Продукт Test Suite 2000 позволяет по указанным параметрам сгенерировать скрипты, осуществляющие жесткое тестирование в критичные временные фреймы.

Продукт WinRunner 2000, основной продукт набора, запускает разработанные тестовые скрипты. Набор скриптов поддерживает Oracle Smart Client и приложения, функционирующие в режиме терминального доступа.

Информация для контактов:

Mercury Interactive 1325 Borregas Avenue, Sunnyvale, CA 94089

Tel. 408-822-5200

Fax. 408-822-5300 http://www.merc-int.com

e-mail: y2ktools@us.oracle.com

7. Программа Обзор 2000

Программа Обзор2000 реализует на практике политику помощи Oracle по решению проблемы 2000 года. Целью создания набора сервисов Обзор2000 является минимизация рисков деловой активности наших заказчиков и партнеров, обусловленных проблемой 2000 года.

Обзор 2000 – это программа, которая осуществляется Всемирной Службой Поддержки Пользователей Oracle (ВСПП). Локальный центр Службы расположен в Москве. Обзор 2000 дополняет уже существующий набор сервисов Oracle Expert PACKAGES.

Программа предполагает:

Выезд к заказчику инженера Oracle;
Обзор информационной системы заказчика;
Диагностику информационной системы и приложений, использующих технологии Oracle;
Получение заказчиком рекомендаций по устранению имеющимся недостатков, могущих повлечь за собой проблемы функциональности системы с наступлением 2000 года;
Помощь и консультации администратору баз данных заказчика;
Предоставление отчета о проделанной работе с рекомендациями;
Предоставление официальных материалов по соответствию продуктов Oracle решению проблемы 2000 года.

Информация для контактов

Oracle Support Service Center

Москва, 119435, Саввинская набережная, д.15 Сергей Задорожный,

Менеджер по продаже технической поддержки

тел. 258-41-80, 721-32-75

e-mail: szadorozh@ru.oracle.com

hotline@ru.oracle.com

8. Заключение

Если организация использует продукты Oracle и намерена решить проблему 2000 года, то мы рекомендуем следующую последовательность действий.

1. Произвести инвентаризацию всех используемых программных продуктов Oracle, точно установить номера версий и релизов, определить степень их соответствия требованиям 2000 года по документу «Oracle Products and Year 2000 Compliance».

2. Оформить техническую поддержку Oracle (если это еще не сделано) и выполнить обновление версий всех программных продуктов Oracle до категории Текущие.

3. Выполнить детальный анализ системы с использованием программы Обзор 2000 и получить детальный технический отчет с указанием потенциально опасных мест и рекомендаций по исправлению ошибок.

4. В соответствии с отчетом и рекомендациями выполнить настройку системы и модифицировать коды приложений, работающих с СУБД Oracle.

5. Выполнить комплексное тестирование информационной системы (по регрессионной и/или сценарной методике).

BIOS и Проблема 2000 года

Чем ближе новое тысячелетие, тем настойчивее звучит тема возможных сбоев вычислительных средств в 2000 году. По оценке Garthner Group, затраты на решение «проблемы тысячелетия» оцениваются в 600 млрд. долл., что по своим масштабам сравнимо для человечества с крупными военными конфликтами – например, войной во Вьетнаме, на ведение которой было израсходовано 500 млрд. долл. Впрочем, так ли уж критична ситуация — вопрос весьма спорный.

В этой статье «Проблема 2000» рассматривается применительно к персональным компьютерам (ПК).

В ПК значения даты и времени устанавливаются на основании показаний микросхемы часов реального времени (Real Time Clock – RTC).

Изначально эта микросхема разрабатывалась для того, чтобы пользователь имел возможность установить эти параметры при первом запуске системы, а затем RTC автоматически их поддерживала. RTC, а также связанная с ней область памяти, называемая CMOS-RAM, запитываются от отдельной батарейки, что позволяет сохранять жизненно важные параметры, в том числе дату/время, и после выключения питания компьютера.

При загрузке операционная система (ОС) устанавливает значения системного времени/даты на основании показаний RTC, используя соответствующее программное прерывание – вызов BIOS (рис. 1). Вот эта трехуровневая схема RTCBIOS-ОС (приложения) и позволит объяснить суть Проблемы 2000 для ПК.

Рис.1. Механизм модификации значения даты/времени в ПК.

Дело в том, что оригинальная микросхема RTC автоматически поддерживает только две последние цифры в поле текущего года. Как результат, при переходе от 1999 к 2000 году, значение столетия, а именно первые две цифры («19») останутся неизменными. Таким образом, значение года будет 1900 или 1980 (зависит от того, какой год принят за начало отсчета в конкретной реализации RTC).

В начале девяностых в энергонезависимой CMOS-RAM был выделен байт для хранения текущего столетия (Сentury Byte). До этого времени соответствующее прерывание BIOS – «Прочитать дату из RTC» – всегда подставляло «19» в качестве столетия. Например, компания Award Software заявила, что все AwardBIOS, выпущенные до 31 мая 1995 года, имеют этот недостаток. Можно считать, что с этого времени ответственность за правильность представления даты была переложена на BIOS. И даже без усовершенствованных обработчиков прерывания от RTC такой BIOS давал пользователю возможность установить правильную дату вручную (например, через Setup – программу установки параметров BIOS или используя средства операционной системы).

BIOS – это внутреннее программное обеспечение ПК, которое хранится в ПЗУ, и лишь с недавнего времени в перезаписываемых микросхемах флэш памяти. Важной задачей BIOS является предоставление доступа ОС и пользовательских приложений к аппаратуре. Этот доступ организован по прерываниям. Описание параметров этих прерываний известно и доступно. В частности, описаны прерывания для работы с RTC. Только при помощи вызова BIOS «Прочитать дату из RTC» ОС может установить системную дату при загрузке и, соответственно, только при помощи вызова «Установить дату в RTC» модифицировать RTC (например, при завершении работы).

Следовательно, от того, насколько правильно написан обработчик прерывания BIOS, модифицирующий Сentury Byte, и зависит одно из возможный решений «Проблемы 2000».

Существуют как минимум три способа обновления Сentury Byte и, следовательно, решения «Проблемы 2000».

Аппаратный способ

Этот способ заключается в том, что используется материнская плата с Y2K-совместимой микросхемой RTC, которая напрямую обновляет Сentury Byte. Такие платы появились сравнительно недавно и их очень немного.

Еще одной разновидностью аппаратного способа является использование дополнительной платы-расширения основного BIOS.

При включении питания BIOS материнской платы проводит так называемую процедуру ROMscan, которая заключается в поиске в определенном адресном пространстве модулей со своим собственным внутренним программным обеспечением. При обнаружении такого модуля по известной сигнатуре, BIOS передает ему управление. Таким образом, происходит замена стандартных обработчиков прерываний BIOS на обработчики, учитывающие все особенности конкретных модулей.

В НИИСИ РАН разработана ISA-плата, которая заменит вызов BIOS для работы с RTC.

Программный способ

К нему можно отнести использование специальных драйверов и резидентных программ (например, набор программ January2000! v1.5 компании Hughes Technologies для операционных систем DOS, Windows, OS/2 и Linux) для отслеживания изменения даты. Пожалуй, к этому пункту можно отнести и замену BIOS (это же программа!) на Y2K-совместимый. Компания American Megatrends заявила, что начиная с версии 6.31.01 AmiBIOS полностью Y2K-совместим. Другой крупнейший производитель BIOS – компания Phoenix Technologies, поглотившая в сентябре 1998 года третью в мире по количеству инсталлированных BIOS компанию Award Software, считает краеугольной версию 4.0.5 PhoenixBIOS.

На уровне ОС для ПК «Проблема 2000» решена довольно давно. Полноформатное хранение даты, в том числе и в качестве атрибутов файлов, было заложено уже в самые первые версии MS DOS. Точнее, там предусмотрено хранение года в диапазоне 1980-2099. Тем не менее, по заявлениям компании Microsoft, все версии MS-DOS, до пятой включительно, не совместимы с Y2K.

Windows 3.x правильно работает с 2000-м годом, но некоторые важные приложения, в частности, «Диспетчер файлов» (File Manager), неверно обрабатывают даты («заплаты» для решения этой проблемы доступны на WWW-сервере компании Microsoft).

ОС Windows 95 совместима с Y2K, если ее устанавливали с нуля, а не в качестве обновления для Windows 3.x. Тем не менее, ряд независимых

тестов обнаружили проблемы. После 2000 года часть утилит может некорректно работать, например «Поиск» (Find) («заплаты» для решения этой проблемы доступны на WWW-сервере компании Microsoft).

Windows NT совместима с Y2K только начиная с версии 4.0. В более ранних версиях также были обнаружены ошибки при обработке дат («заплаты» для решения этой проблемы доступны на WWW-сервере компании Microsoft).

8 декабря 1998 г. корпорация Microsoft выпустила пакет Year 2000 Update for Windows 98.

Выпуск этого продукта, по заявлению представителей корпорации, не связан с наличием «ошибок 2000 года» в самой системе, но он позволяет устранить некорректное отображение дат и неправильную их обработку в некоторых программах, входящих в состав OC или функционирующих под ее управлением. Как было отмечено, обнаруженные ошибки не приводят к потере данных, а пользователи, работающие днем, могут и вовсе не столкнуться с этими ошибками.

К числу проблем, устраняемых с помощью Year 2000 Update, относятся, например, следующие:

ошибочное отображение времени или даты при загрузке системы в последнюю секунду перед сменой даты;
неправильное отображение 29 февраля в программе установки даты/времени (Date/Time Control Applet) панели управления (Control Panel);
возможность некорректной записи в протоколе программы Dialer;
неправильная интерпретация ключа /D:date в программе XCOPY;
усечение введенного четырехзначного обозначения года до первых двух цифр при выполнении Java-аплетов на виртуальных Java-машинах, построенных с использованием Sun Microsystems JDK (v.1.1.1 — v.1.1.5) и класса java.txt.SimpleDateFormat;
неправильная интерпретация функциями MFC класса COleDateTime даты после 1 марта 2000 г.;
интерпретация даты до 2060 как времени суток при использовании функций работы с датами, входящими в состав ADO или OLE DB.

Как показывает предыдущее изложение, на уровне ОС и базовых приложений для ПК «Проблема 2000» вызовет в худшем случае некоторые неудобства, но не катастрофические ошибки. Тем не менее, если Вы хотите самостоятельно проверить готовность своего ПК, то из свободно распространяемых программ можно порекомендовать AMI2000 Tester компании American Megatrends – одного из крупнейших производителей BIOS.

Продукты Sun и Проблема 2000

Информация о соответствии продуктов фирмы Sun требованиям 2000 года публикуется на web-странице фирмы по адресу http://www.sun.com/y2000/cpl.html.

Продукты Sun делятся на следующие категории (в скобках приведены соответствующие обозначения в таблице):

продукты не использующие даты (0);
продукты, готовые к переходу даты уже при выпуске (1);
продукты, требующие модификации (2);
продукты, проходящие проверку (3);
продукты, требующие замены (4);
продукты, поставляемые в виде исходных текстов, которые могут быть изменены без участия Sun (5).

В табл. 1 приведены сведения об основных

программных и продуктах компании Sun Microsystems, а в табл. 2 о наиболее популярных моделях серверов и рабочих станций, а также их компонентов. Практически для продуктов Sun Проблемы 2000 не существует; лишь в некоторых, некритичных случаях требуются несложные модификации.