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

Однако, остались случайные, несистематические причины, по которым иногда (правда, теперь уже значительно реже) записанные данные переставали уверенно читаться. Если во-время не принимать меры, то в конце концов с томом прямого доступа будет невозможно работать. В связи с этим, системщики разбили все тома прямого доступа на категории по принципу одинаковой интенсивности записи. Для каждой категории томов были установлены свои сроки копирования со сменой оригинала. Такая "профилактика" производится все на том же "эталонном" дисководе, на котором делается инициализация томов. Теперь в этом ВЦ сбой на устройстве прямого доступа возникает не чаще, чем раз в рабочую смену.

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

Этюд.

Hа ЭВМ м-222 (и вообще на всех ЭВМ типа м-20) магнитные ленты (мл) было принято дефектовать с разметкой на зоны. Для этого имелись программы разметки и дефектовки, которые тестировали поверхность мл, отбраковывая некачественные ее участки. Мне были известны несколько таких программ от официально поставляемых до "народных" (парасистемных), в которых по утверждению авторов поверхность МЛ тестируется шахматным кодом. Увы, этот код оставался шахматным разве что в оперативной памяти. Дело в том, что одна 45-разрядная ячейка памяти этой ЭВМ записывается на МЛ побайтно.

В результате, "шахматная" двоичная комбинация '10101010101010…' Записывается на МЛ пятью одинаковыми и шестым "почти одинаковым" байтом! При таком "тестирующем" коде ни способность к перемагничиванию поверхности, ни чувствительность магнитных головок, ни переключательная способность оборудования не проверяется в полную силу (с максимальной частотой). Если принять во внимание еще и способ записи на МЛ (без возвращения к нулю) идеальным кодом были бы "все единички", но, учитывая систему воспроизведения и контроля данных, пришлось остановиться на "настоящем шахматном" коде.

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

Следуя примеру [1], попытаемся выделить еще несколько существенных для обслуживания СОД свойств ПО. 1. Неприхотливость, то есть способность ПО работать на неисправном оборудовании, пока оно не сломалось до такой степени, что неисправность легко обнаруживается и устраняется. Нужно всегда помнить, что перевести устройство из хорошего состояния в отличное на несколько порядков сложнее, чем из плохого в удовлетворительное. 2. Безопасность, то есть способность при любом сбое не произвести во внешней среде необратимых изменений. Следует отличать это свойство от устойчивости. При внешнем или внутреннем возмущении устойчивое ПО будет стараться выполнить свое назначение. Например, ПО, ответственное за посадку автомата на Луну, постарается хоть криво и не туда, куда хотелось бы, но все же автомат посадить. А вот "криво" исправленная база данных (невосстановимая приемлимыми средствами) — это часто гораздо хуже, чем отказ ПО. Следует различать разницу между отказом ПО и отказом СОД. 3. Дотошность, то есть способность ПО во время функционирования предоставлять информацию, достаточную для последующего ремонта оборудования. Любопытен еще и такой факт. Большинство характеристик качества ПО носит объектный характер, то есть они прямо или косвенно указывают, что с этим ПО можно (нельзя) сделать. Для тех же, кто с этим ПО ничего делать и не собирается, кто хочет спокойно сосуществовать с этим ПО, обслуживая сод, для тех едва ли не менее интересны субъектные свойства ПО. Им важно, что это ПО само сможет (не сможет) сделать. Сравните "прозрачное" — сквозь которое может смотреть (кто-то другой), и "неприхотливое" — которое может (само) терпеть.