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

Кроме того, к каждой головной программе редактор связей щедро присоединил программы периода выполнения из библиотеки транслятора PL/1, размножив их, таким образом, в количистве 21 экземпляр. Hо бог с ним, с объемом внешней памяти под библиотеку зм. Пусть разработчики восторгаются количеством команд в своем детище. Радоваться им не долго, так как эту СОД они сделали, что называется, "для себя". В один прекрасный день они нашли ошибку в программе Z, которая используется… Очень трудно сказать точно, где она используется. Примерно в 17 из 21 головных модулей. Ошибочка не очень страшная, почти все работает. Hо, если запятая следует за пробелом, а длина записи больше 72 байт…

В общем, нужно исправлять. Для этого нужно исправить исходный текст программы Z, оттранслировать ее, а затем отредактировать заново все 21 головных модулей, так как трудно сказать, какие из них не пользуются услугами программы Z. Вот тут-то и начинается самое интересное. Исправление пришлось делать, что называется, "на живом теле", в рабочем экземпляре библиотеки зм, чтобы как можно быстрее исправить эту ошибку, хотя бы в тех головных модулях, которые должны использоваться в ближайшее время. Исправление затянулось на две недели. При этом, пользователи несколько раз получали неверные результаты, так как никто не знал, какие модули требуют исходных данных еще в "старом" виде, а какие — в "новом". При редактировании одного модуля произошла ошибка, которую не заметили, и модуль был неработоспособен двое суток. Два других модуля просто забыли отредактировать, и ошибку нашли только через месяц.

Во время исправления одного из модулей отказала ЭВМ, и библиотека зм пришла в негодность. Пришлось восстанавливать ее с позавчерашнего дампа. Hо там было отредактировано на 7 модулей меньше, а может, на 8? Пока продолжалась вся эта эпопея, не смотря на массовый героизм разработчиков и эксплуатационников (успевших переругаться между собой), ВЦ сорвал свой и чей-то еще план, все, кому полагается по штатному расписанию, получили по выговору. Получил свой выговор и начальник ЭВМ, за то, что его любимица нашла не самый удачный момент, чтобы сломаться. Передышка была недолгой. Hе успели страсти утихнуть, как обнаружилась еще одна ошибка. Hа этот раз в программе Y.

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

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

Этюд.

Некоторая система по включению в эксплуатацию новых программных модулей работает следующим образом. Пользователями этой СОД являются программисты, которые отладили свои программные модули и теперь эти модули хотят включить в состав общей библиотеки программ. Общих библиотек несколько: для программ на языке PL/1, оттранслированных обычным транслятором; для программ на языке PL/1, оттранслированных оптимизирующим транслятором и т. п.

Для простоты оставим в стороне вопрос синхронного поддержания пар библиотек (исходных и загрузочных модулей). Когда программист хочет включить свой модуль в библиотеку, он это делает сам в любое время и любыми доступными ему средствами. Отвечают за сохраность и работоспособность общих библиотек системные программисты, которые периодически копируют эти библиотеки, создавая резервные копии на случай сбоев или разрушения оригинала. Здесь возникают следующие опасности.

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

2. Выполняя страховое копирование, системные программисты, естественно, также не застрахованы от ошибок. Проще всего им ошибиться, скопировав неработоспособный оригинал, не заметив того, что его уже кто-то испортил. (Последнее не всегда легко определить. Некоторые ошибки в оглавлении библиотек работают, как мины замедленного действия). Даже если поколений страховых копий несколько, с момента возникновения ошибки до момента ее обнаружения могут смениться все поколения.

3. Если системщики обнаружат некорректность в библиотеке вовремя, они восстановят ее с последнего поколения, но при этом нужно будет как-то определить, какие изменения были в погибшей библиотеке сделаны с момента ее последнего копирования. Если кто-то и ведет по этому поводу какие-то записи, то в них тоже возможны ошибки. В результате, некоторая программная система после проведения восстановительных работ неожиданно для всех оказывается неработоспособной.

4. Пользователи могут перепутать библиотеки и, записав свой модуль в одну из них, ожидать его появления в другой. Прибавьте теперь сюда еще и то, что необходимо поддерживать пары библиотек, то есть обеспечивать синхронную замену в одной библиотеке исходного модуля, а в другой — загрузочного (объектного). Прибавьте сюда и то, что библиотек не две пары, а больше, и в некоторых из них имена модулей могут совпадать, что особенно неприятно при их замене с "перепутыванием" библиотеки. Добавьте сюда и то, что иногда "хороший" модуль меняется на "плохой", после чего "хороший" требуется восстанавливать с дампа, если он еще там существует. После всего этого вы можете подсчитать, сколько требуется парасистемных программистов на поддержание работоспособности всей этой системы. Быть может, существуют системы поддержания всего этого хозяйства в среде ОС ес? Максимум, на что способны такие системы — это красиво исправить и распечатать текст вашей программы. Вся рутина останется людям. Давайте же в качестве следующего этюда рассмотрим некоторую гипотетическую систему поддержания программного хозяйства (ППП "пирамида").