Записки парасистемного программиста - [3]

3.3. Терновый серпантин.

Рассмотрим последний пример подробнее, чтобы определить, как должна быть построена программа вывода перфоленты, если она должна выводить ее действительно много (по сравнению с реальной наработкой на сбой). Более того, как она должна работать, даже если сбои в среднем достаточно редки (настолько редки, что после сбоя при повторном пуске программы перфолента скорее всего не будет содержать ошибок). Для построения такой программы нужно учесть следующие соображения. Первое. По-прежнему действует закон "чем лучше — тем хуже". Если возможность сбоя не принимается во внимание, то чем позже он произойдет, тем более потрясающий эффект он произведет среди тех, кто так верил этой системе. Поэтому, если вероятность сбоя в течение некоторого промежутка времени больше вероятности того, что ВЦ сгорит дотла (за тот же промежуток времени). То программа должна его учитывать. Прежде всего, она должна позаботиться о том, чтобы пользователь получил заведомо правильные результаты (с указанной выше вероятностью), либо не получил их вообще. Второе. Пользователя скорее всего не устроит неполучение результатов вообще, хотя это уже лучше, чем получение возможно неправильных результатов. Хорошая программа вывода перфоленты должна либо выдать правильный результат, либо обеспечить возможность ремонта сбоящего устройства (принцип "встроенного теста"). Встроенный тест нужен тогда, когда устройство сломалось еще не настолько, что уже известно, как его чинить (нет явного отказа, а есть пакет сбоев). Действительно, допустим, что частота сбоев превысила указанную в паспорте величину на пол-порядка. "Юридически" устройство сломано (какой ценой обычно доказывается факт такой "полусломанности"!). Hо если обслуживающий персонал будет вынужден его чинить, то он должен будет в течение длительного времени "гонять" на устройстве бесполезные с точки зрения пользователя тесты, занимая не только это устройство, а скорее всего, всю ЭВМ, изводя впустую уйму машинного и рабочего времени и перфоленты. Хорошо еще, если такие тесты существуют. Каждый бит драгоценной для обслуживающего персонала информации будет оплачиваться сотнями килобайт информации, бесполезной для пользователя СОД. Так пусть уж лучше вместо теста работает программа этой СОД. Тогда она, выдавая результат, заодно еще даст информацию о сбоях. Третье. Чтобы результатом, полученным в условиях сбоя можно было пользоваться, программа должна локализовать сбой и принять меры к восстановлению корректности результата. Возможно, ведя диалог с оператором ЭВМ и разбивая всю перфоленту на контролируемые и повторяемые в случае сбоя участки. Для контроля результата она должна использовать устройство ввода перфоленты. Четвертое. Ценность встроенного теста заключена еще и в том, что другие тесты могут не вызывать сбой в устройстве, так как они тестируют устройство в режиме, отличном, от режима его использования.

3.4. Hа нейтральной полосе.

Этюд.

Hа одном ВЦ купили две ЭВМ единой системы и стали постепенно загружать их работой в пакетном режиме в среде ОС ЕС, с общим полем памяти прямого доступа на восьми дисководах (по 29 мегабайт). Сначала объем данных на устройствах прямого доступа был невелик, и сбои на дисках особенно не докучали. Hо по мере наращивания объема данных работать становилось все труднее и труднее, пока ВЦ не подошел к некоторому "информационному барьеру". Стало ясно, что необходимо менять технологию настройки дисководов на взаимозаменяемость. Электронщики, обслуживающие дисководы, заявили, что тесты проверки взаимозаменяемости у них идут. В свою очередь, системные программисты, представили богатый материал, из которого следовало, что при работе с ОС ес взаимозаменяемость отсутствует. Теперь, как это обычно принято в других вц, можно было и подраться.

Hо в этом вц обычно делали по другому. Электронщики и системщики вместе стали разбираться, в чем заключается разница в подходе к взаимозаменяемости у тестового обеспечения и у ОС ЕС. Для выяснения этого вопроса системщикам пришлось отложить бесполезные в этом случае книги по управлению данными ОС ес и взяться за "чужие" для большинства системщиков книги по тестовому программному обеспечению и даже по аппаратуре, благо в этом благородном порыве электронщики помогали системщикам всей душой. Обнаружилось, что электронщики пользовались следующим определением взаимозаменяемости: для любых целых I и K, не больших N, где N — количество дисководов, инициализация на I-том дисководе, запись на I-том же дисководе и чтение на K-том должны закончиться без сбоев с некоторой, близкой к единице вероятностью. Системщики (точнее, те системщики, которые разработали ос ес), понимали под взаимозаменяемостью следующее: для любых целых I, J и K, не больших N, инициализация на I-том, запись на J-том и чтение на K-том дисководах должны закончиться без сбоев с все той же, близкой к единице, вероятностью.

Итак, разница в том, что электронщики во время проверки взаимозаменяемости инициализировали пакет и записывали на него тестовые данные на одном и том же дисководе, а читали на другом. При работе же с ОС, программы управления данными, естественно, записывали данные не на тех дисководах, на которых пакет магнитных дисков инициализировался. Чтобы эта маленькая разница стала очевидной, электронщикам и системщикам пришлось выйти за границы своих знаний на нейтральную полосу. Электронщикам пришлось узнать, как работает ОС ЕС с магнитными дисками, а системщикам пришлось узнать, как выполняются канальные программы и как тестируется аппаратура.