Евгений Лишак - Записки парасистемного программиста

Вот пример того, как возникают иллюзии. В документации по ОС ЕС написано, что добавление записи по ключу в индексно-последовательный набор данных равносильно для программиста добавлению этой записи на свое место в физической последовательности. Действительно, равносильно, но лишь в том случае если эта операция успешно завершилась. Более того, у меня есть подозрения, что даже и этого мало. В некоторых случаях необходимо еще, чтобы успешно завершилась операция закрытия набора данных. Если какое-то из этих условий не выполнено, то либо весь набор данных, либо некоторая его часть окажутся недоступными для последующего чтения. Если программист пишет программу, которая сама такой набор данных создает, сама его после создания корректирует, а по окончании этой программы набор уже не нужен, то программисту достаточно поверить написанному о том, как просто корректировать индексно-последовательные наборы данных. Если же такой набор данных создается для многократного использования, может быть, в течение нескольких лет после его создания, то разработчику сод, использующей этот набор данных, следовало бы знать, что такая простая с точки зрения написания программы операция, как добавление записи по ключу в индексно-последовательный набор данных представляет собой несколько операций записи в этот набор данных, разнесенных во времени и пространстве (занимаемом этим набором). Окончательная же фиксация изменений происходит по закрытию набора данных. Что прикажете делать пользователю СОД, разработчик которой по своей простоте не подумал о возможности сбоя и не предоставил пользователю никаких средств борьбы с ней? Примером может послужить все тот же ППП "оргвыц". Еще пример доверия к печатному слову: в паспорте на устройство вывода на перфоленту написано, что это устройство обеспечивает так мало сбоев, что на пять тысяч метров перфоленты приходится всего одна неправильная пробивка [5]. Очень трудно позавидовать пользователю СОД, разработчик которой прочел указанный документ и поверил ему. Вместо так нужной ему перфоленты он получит возможность участвовать в многочисленных склоках с обслуживающим персоналом, размахивая вышеуказанным паспортом, который в отличие от волшебной палочки перфоленту не сотворит. Возможно, что пользователь будет писать рекламации на завод-изготовитель ЭВМ, перфоратора или перфоленты. В любом случае, если только ему на самом деле нужна перфолента и он лишен садистских наклонностей, он вряд-ли будет в большом восторге от такой СОД. Хорошо еще, если он поймет, что собака зарыта прежде всего в программном обеспечении, которое не ломается, которое не надо чинить и которое сделать надежным значительно легче, чем перфоратор.

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