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

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

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

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

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

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

Этюд. ППП "Пирамида".

1. Нижний уровень пирамиды — средства для индивидуальной отладки модулей пользователя. Эти и только эти средства (здесь не нужен системный подход) в изобилии имеются в распоряжении любого вц. Требуется только составить ряд каталогизированных процедур языка управления заданиями. Элементом этого уровня является группа поколений последовательного набора данных. Hа каждого пользователя-программиста приходится несколько таких групп.

2. Второй уровень пирамиды — это небольшие библиотеки программ (точнее, пары из исходной и загрузочной библиотек). Одна такая библиотека выделяется на бригаду программистов. Она нужна для комплексной отладки программ. Ввиду прямой заинтересованности небольшого коллектива (один — пятеро) пользователей такой библиотеке особые неприятности не грозят. Ответственность за нее несет бригадир. Системные программисты только выполняют копирование всех библиотек второго уровня на случай сбоев. Копирование выполняется по принципу "все библиотеки одной процедурой". Забытых библиотек не бывает, так как поиск их ведется автоматически через каталог. Если бы не система ответственности, то этот второй уровень был бы не отличим от описанной в предыдущем этюде системы. Дело все как раз в этой системе ответственности. Именно прямая заинтересованность хозяина и обозримость границ владения обеспечивают общественные рефлексы на этом уровне. Благодаря этому, второй уровень пирамиды также может быть обеспечен существующими средствами почти без доработок. За основу может быть принята, например, прекрасная система офап угольной промышленности (перегудов). Требуется, правда, разработка интерфейса между первыми двумя уровнями — несколько каталогизировнных процедур языка управления заданиями.

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