4. Люди, как они есть.

4.1. Три лица будды.

 Любая система обработки данных, как и любое техническое изделие, имеет три лица. Первое из них обращено к пользователю системы. Для ОС ЕС, например, это язык управления заданиями и языки программирования, инструкции по работе с утилитами обслуживания наборов данных. Если рассматривать, СОД как не операционную систему, а, например, систему управления базами данных, то обращенное к пользователю лицо этой СОД - это языки описания и манипулирования данными. У системы подготовки данных на терминалах обращенное к пользователю лицо - это язык, при помощи которого операторы подготовки данных могут заносить свои данные и исправлять их. Если в системе четко выделены группы пользователей и обращенные к ним лица, то, следовательно, в такой системе может быть определена и максимально допустимая сложность диалога с ними.
Если СОД сама предназначена для создания СОД, как, например, ОС или СУБД, то ее пользователями являются программисты. Лицо, обращенное к пользователю, у такой системы достаточно сурово и неприветливо. Чтобы разговаривать с ним нужно изучить много документации и иметь для этого высокую квалификацию программиста. В этом случае разработчики СОД вправе ожидать высокой квалификации от пользователей системы. Однако, несколько странно видеть сод, которые, будучи ориентированы на неквалифицированного с точки зрения программирования пользователя, тем не менее, обращают к пользователю такое "ужасное" лицо, что в пору вспомнить сказку про аленький цветочек. Разница заключена лишь в том. Что такой СОД в отличие от сказочного чудища трудно рассчитывать на взаимность.
 Этюд. Некоторые генераторы ввода данных предлагают своим пользователям исправлять ошибки в промежуточных файлах утилитой IEBUPDTE ОС EC. Простое желание оператора подготовки данных удалить неправильный документ из группы таковых невесть каким образом должно трансформироваться в задание ОС ЕС, во всяком случае, не проще такого:

// ЕХЕС UРD,D=ZОNТIК
./ СНАNGЕ
./ DЕLЕТЕ SЕQ1=20,SЕQ2=20

 "Что тут непонятного?" - Спросит любой програмист, в том числе и тот, который предложил такой великолепный способ исправления ошибок оператору подготовки данных, увы, этот программист забыл, что созданная им система нужна вовсе не программистам. В таком варианте она, скорее всего, не нужна никому, разве что переодетым в операторов подготовки данных создателям этого ППП.
СОД может иметь несколько "подлиц", обращенных к различным категориям пользователей. Например, система подготовки данных с программным обеспечением типа генератора ввода может предполагать в качестве пользователей персонал подготовки данных с одной стороны и тех, кто эти данные приносит и желает иметь их в машинном виде, с другой стороны. Можно, конечно, отнести персонал подготовки данных и к обслуживающему систему персоналу, но, как правило, такие системы создаются не для тех, кому в конце концов все равно, каким образом "попадут в машину" их данные, а для облегчения работы и повышения производительности труда персонала подготовки данных.
Если система предназначена для лиц, не являющихся профессиональными разработчиками других СОД, то есть, если сод находится на верхних уровнях иерархии СОД, то это ее лицо должно быть не сложнее передней панели телевизора. Все попытки заставить кладовщика, бухгалтера, директора, конструктора, вахтера использовать СОД, документация пользователя которой превышает объем инструкции по эксплуатации пылесоса (исключая профессиональные знания пользователя), заранее обречены на провал. Для каждой профессии потенциального пользователя СОД можно, в принципе, определить верхние границы информационной сложности интерфейса СОД-пользователь. Если на начальной стадии проектирования выясняется, что верхняя граница сложности превзойдена, то продолжать проектирование такой системы дальше нет никакого смысла. Я думаю, что поставлено достаточное количество экспериментов, чтобы можно было определить эти границы, и не только для СОД, но и вообще для всех изделий - технических и организационных. Примером последней системы может служить, скажем, система хозяйственного законодательства.
Второе лицо СОД обращено к обслуживающему ее персоналу. Для ОС - это мы, парасистемные программисты, для СУБД - это администратор баз данных, для АСУ "Кадры", это группа ПО сопровождению задач на ВЦ и т.п. Если продолжить аналогию с телевизором, то обслуживающий его персонал - это мастер из телеателье. У телевизора это лицо находится сзади, а иногда и внутри - множество непонятных для непосвященного любителя Штирлица кнопочек и ручек, подстроечных сопротивлений и конденсаторов, которые не имеющему дома даже тестера телезрителю лучше и не трогать. Однако, механик из телеателье спит дома, а не на коврике, позади вашего телевизора, чего никак нельзя сказать про персонал, обслуживающий СОД. В данном случае его уместнее сравнивать с водителем такси. Итак, чем проще вам удастся сделать это второе лицо, тем больше шансов, что ваша система обретет жизнь. И, наконец, третье лицо СОД, повернуто к самому разработчику. Сюда относятся те параметры СОД, которые ни пользователь, ни обслуживающий персонал изменять не должны. Увы, у последних систем, программное обеспечение которых создается для ЕС ЭВМ, это лицо никак не выражено. Прежде всего, мы обязанны этим той системе, точнее отсутствию той системы сопровождения ПО, которая сложилась в последнее время. Можно только мечтать о тех счастливых временах, когда разработчик будет периодически поставлять свежие версии своего ПО в обмен на информацию об ошибках и предложения о развитии системы. А пока что, каждый волен делать со своей СОД все, что ему захочется, и что не захочется тоже, так как делать это больше некому. Хорошо еще, если есть исходные тексты. Вот и растут, как грибы программы ассемблирования наоборот и специалисты по расшифровыванию чужих программных модулей. Лучше, чем В. Высоцкий, по этому поводу не скажешь:

 Тридцать три богатыря
Порешили, что зазря
Берегли они царя
И моря!
Каждый взял себе надел,
Кур завел и в ем сидел,
Охраняя свой удел,
Не у дел!
. . .
(Лукоморье)

 Очень важно, чтобы создатели СОД в архитектуре системы четко проводили политику разделения этих трех лиц. Иногда при внедрении СОД приходится проводить очень серьезную организационную работу, буквально перекраивая документацию, раздавая ее по листку, то пользователю, то обслуживающему сод персоналу.
Этюд. Оператор ОС ЕС, пользуясь средствами оператора ОС ЕС, запустил три следующих задания: SUBCHIK, GVOZDIK, KADRIK. При этом, он распределил первым двум заданиям (точнее, их маршрутным кодам) вторичные пульты оператора ЭВМ. Третьему же заданию он распределил терминал - внешнее устройство. Все три задания, допустим, работают одновременно. Оператор ОС следит только за правильностью их выполнения с точки зрения ОС. При этом, он руководствуется только документацией ОС и не имеет никакого понятия о том, что SUBCHIK - это СУБД, GWOZDIK - это генератор ввода, а RFDRIK - это АСУ "Кадры".
За пультом оператора ОС, на который выводит свои сообщения СУБД, работает вовсе не какой не оператор ОС, как написано в документации ПО ОС и СУБД, а администратор баз данных. Он следит за правильным использованием ресурсов, но не всей ОС, это дело первого оператора, а только тех ресурсов, которые находятся в распоряжении СУБД, как задачи ОС. Вот, он получил сообщение, что какая-то задача из системы "Кадры" - он даже не знает, что это с точки зрения ОС ЕС задание "КФDRШЛ" - просит его санкционировать доступ к базе данных RFDRCEH1. А вот, он получил сообщение что генератор ввода собирается загружать базу данных KADRCEH2.
За пультом оператора ЭВМ, на который выдает свои сообщения генератор ввода, работает, опять же, не оператор ЭВМ, а администратор генератора ввода. Он обслуживает работу этого генератора. И, наконец, за терминалом в отделе кадров работает пользователь АСУ "кадры", который, хотя и является с точки зрения документации и "здравого смысла" оператором, абсолютно не имеет никакого понятия о СУБД, ОС или генераторе ввода. Он даже не обслуживает АСУ "Кадры", он этой системой пользуется.
Итак, мы видим, что термин "оператор" определяет место человека в СОД ничуть не лучше, чем его фамилия или пол. Тем не менее, почему-то принято собирать все указания о том, какую кнопку нажимать, в одну большую книгу, которая красиво и по-современному называется Инструкцией оператора. Представьте себе "инструкцию оператора телевизора", в которой написано, как его, этот телевизор, покупать, привозить домой на лифте, устанавливать, смотреть и чинить. Причем, все это в порядке расположения кнопок на телевизоре и в лифте справа налево и сверху вниз.
Оператором может быть пользователь СОД, может быть и обслуживающий ее персонал, но уж совсем нехорошо путать обязанности пользователей и персонала разных СОД. В некоторых ВЦ оператор ЭВМ и жнец и швец и на дуде игрец. То он выступает, как персонал подготовки данных, вводя с терминала накладные со склада готовой продукции, то он отключается на время от этой работы, чтобы принять на работу в 7-й цех нового сотрудника, и этому сотруднику нужно присвоить табельный номер, а то и назначить оклад. А вот, вдруг, посреди сообщений о сотрудниках 7-го цеха появляется сообщение о переполнениии очереди каких-то сообщений. То ли это "Интерседан", то ли "ИНЭС", то ли "ОКА"? Хотя "ИНЭС" - вряд ли. Им пользуется отдел 4011, а они вот уже две недели, как на овощебазе.
Впрочем, это все фантастика. На таких ВЦ, естественно, вообще нет никаких операторов. Просто в машинном зале одновременно возле одного пульта оператора толпятся несколько человек, мешая друг другу и не зная, что им делать можно, что - нужно и чего им делать нельзя.
Ниже мы рассмотрим некоторые способы упрощения всех трех указанных интерфейсов, независимо от того, к кому они обращены. К разработчику ли системы, к ее пользователю или персоналу.

4.2. Живые компьютеры.

 Искусственный интеллект построить нелегко. Значительно легче сделать живой компьютер. Для этого нужно получить по распределению молодого специалиста - из вуза, техникума, пту - все равно, поставить его возле печатающего устройства, чтобы он смотрел, какие оно печатает числа. Если напечаталось число, равное записанному в журнале таком-то, на странице такой-то, такая-то строка сверху, то нужно найти пакет перфокарт с таким-то номером и ввести его. А если не равно - ну, тогда пакет перфокарт номер такой-то. Вот так, все просто: IF THEN ELSE. А что будет, если этот живой компьютер ошибется? А ошибаться он не должен. Не должен, и все тут (о модальных глаголах смотри ниже). Если он ошибся - то это значит "халатность", "плохое воспитание", "несознательность", "мы в их годы", "текучесть кадров" и т.п. И все эти слова и слезы вместо того, чтобы это самое IF THEN ELSE один раз запрограммировать и отдать выполнять не живому, а самому, что ни на есть железному компьютеру. Он справится с этой работой быстрее и надежнее, даже если не обладает искусственным интеллектом, высшим образованием и высокой сознательностью.
А пока искусственного интеллекта еще нет, человек в системах обработки данных нужен, но лишь для того, чтобы принимать решения, которые заранее не могут быть запрограммированы. Как правило, это реакция на нестандартные ситуации или распределение ресурсов. Кроме того, люди - это самообучающиеся системы. И это тоже надо учитывать.
Этюд. Некоторая СОД хранит жизненно важные для нее данные в библиотеке (наборе данных на магнитных дисках). Некорректные изменения данных в ней или, что еще хуже, уничтожение этой библиотеки приведет к прекращению работы сод. Чтобы застраховаться от такой возможности набор данных защитили сроком хранения (навечно), вверив тем самым, его судьбу в руки операторов ЭВМ. Теперь ОС ЕС перед попыткой записи в этот набор данных стала запрашивать разрешение у оператора. На ВЦ, где эксплуатируется СОД, операторы ЭВМ всегда запрещают запись в набор данных, если у них нет письменного распоряжения одноразового действия на разрешение записи.
И все было бы очень хорошо, если бы не то обстоятельство, что делать запись в эту библиотеку приходится 10-15 раз в сутки. Пока СОД работала на уровне контрольного примера, и частых модификаций библиотеки не было, все было в порядке. Но стоило только "выйти на проектную мощность", как началась неразбериха: письменные распоряжения о разрешении и записи не поспевали за запросами. Сначала операторы ЭВМ добросовестно запрещали в таких случаях запись в библиотеку. Их стали за это ругать.
- Что вы, не знаете, что ли, что в эту библиотеку запись запрещена просто так, - говорили им.
Иначе говоря, IF (библиотека та) THEN (запись разрешать всегда) ELSE (без инструкции не разрешать).
При всем при этом, ни разу не возникала ситуация, когда пришлось запретить запись в какой-нибудь набор данных "за дело". Прошло некоторое время, и в один прекрасный день было обнаружено, что операторы всегда разрешают запись во все наборы данных, защищенные сроком хранения, не зависимо от наличия или отсутствия у них по этому поводу инструкции. Выяснилось это в результате порчи другой, не менее важной библиотеки.
Вышло так, что функция человека по контролю подменилась автоматическим действием, и обесценилось очень важное средство обеспечения надежности - защита данных сроком хранения. Причем, обесценилась надолго. Люди, в отличие от ЭВМ, быстро "наоборот" не перепрограммируются!
Правильно было бы не защищать эту библиотеку сроком хранения. Более того, иногда пытаться записать что-нибудь в другие защищенные наборы данных, не обеспечив письменное распоряжение, а затем похвалить оператора за правильный запрет. Тестировать нужно не только компьютеры, да и память человеческая, в отличие от "железной", требует постоянной "подкачки", которая, как нас учат психологи, эффективнее всего достигается положительными эмоциями.
Ниже нам придется столкнуться и с другими примерами использования человека в качестве живого компьютера, однако, не всегда это плохо. Есть и исключения. Одно такое исключение - это профессия оператора подготовки данных. Есть предположения, что в будущем эта профессия исчезнет. Однако, до этого еще очень и очень далеко. И пока она существует, это самая некомфортабельная профессия в СОД. Разработчики СОД обязаны знать это и стремиться максимально облегчить труд операторов подготовки данных. Но в этом случае, как раз, облегчение их труда заключается в том, что из трудовой деятельности оператора подготовки данных изымаются все элементы принятия решений.
Работа операторов подготовки данных основана на рефлексах и только на них. Любые попытки заставить их принимать решение встречает с их стороны резкий отпор и увеличивает количество ошибок. Оператору подготовки данных легче занести лишних сто байт информации, чем принять решение, стоимостью в один бит: стоит или не стоит эти 100 байт заносить. Компенсацией однообразного, механического характера работы является возможность думать в это время о чем-то своем, слушать музыку. Не отнимайте этого у них, иначе вы останетесь без персонала подготовки даных
Поэтому, системы подготовки даных, дающие оператору массу альтернативных возможностей тем хуже, чем больше у него этих возможностей. Следующий пример может послужить контрпримером к приведенному в главе "три лица будды" этюду с ГВВ и утилитой IEBUPDTE.
Этюд. В некоторой системе подготовки данных за единицу данных принят документ (термин, понятный персоналу подготовки данных), который состоит из реквизитов. Первым реквизитом всегда идет номер документа, который может не указываться оператором подготовки данных. Система присвоит ему номер сама так, чтобы документ поместился на хранение вслед за последним из записанных в хранилище. Оператор подготовки данных не знает ни ОС, ни языка управления заданиями, ни даже того, что эти хранилища (их все называют "ячейками") - это наборы данных на устройствах прямого доступа.
Вслед за номером документа идет реквизит - признак вычеркивания. Это буква "ы". Затем идут остальные реквизиты.
Документы или исправления документов, относящиеся к разным "ячейкам", разделены специальным документом "бирка". Например, документы в потоке ввода системы могут выглядеть так:

@@биркаа25н34е48
::тетрадь:25
7::чернильница:45
5:ы:
::карандаш:2
::ручка:210:
@@биркар34а56н37
::чехова:ул:25:18:

 Этот поток записей означает, что в одну ячейку будут добавлены в ее конец документы про тетрадь, карандаш и ручку, заменен документ с номером 7 и вычеркнут документ с номером 5. В другой же ячейке будет добавлен в ее конец еще один документ - информация про подписчика газеты.
Мы видим, что оператору подготовки данных совсем не нужно знать утилиту IEBUPDTE и выполнять ее странные для непрограммиста требования о рассортированности запросов на исправление в порядке следования записей и т.п.

4.3. Пульт управления зажигалкой.

 Кто не знает утилиты IEBPTPCH ОС ЕС? Вряд ли кому-нибудь из пользователей или системщиков, обслуживающих ОС ЕС удалось без нее обойтись. Хуже всего приходится тем из них, кто встречается с ней реже, чем раз в две недели. Потому что, не смотря на всю скудность действий, которые она может выполнить, язык, при помощи которого приходится управлять этой программой, по своей красоте, сложности и многогранности, количеству подтекстов слегка смахивает на язык великого шекспира.
Прежде всего, эта утилита пожелает узнать у вас, сколько разделов библиотечного набора данных вы хотите распечатать и сколько полей в строке распечатки вы захотите выделить. Не дай вам бог забыть указать это с помощью операндов MAXNAME и MAXFLDS. Сама она пресчитать ваши разделы и поля не может, а если и вы ленитесь считать, то вы недостойны этой утилиты. Правда, если вы укажете эти величины большими, чем нужно, то так и быть, она до вас снизойдет. Зачем же нужно ей знать заранее такие подробности? Видимо, для того, чтобы сэкономить два десятка байт основной памяти. Впрочем, это только мое предположение, которое очень трудно проверить. Ос ЕС сообщает количество используемой ОП с точностью до пары килобайт. Но это еще не все. С этим еще можно было бы смириться. Совсем непонятно, зачем нужно указывать эти операнды, если требуется распечатать один раздел в виде одного поля на строке. Это самый типовой случай использования этой утилиты.
Но и это не все. Исходя из каких соображений имена этих операндов выбраны такими, а не MAXFIELD и MAXNMS, например? Ну почему в первом операнде английское слово FIELD сокращается с выпусканием гласных и берется в множественном числе, а в другом слово NAME не сокращается и берется в единственном числе? Только вчера я пользовался этой утилитой в последний раз после месячного перерыва. С третьей попытки мне удалось, наконец, получить от нее то, что я хотел (а ведь я знал уже, с чем имею дело), а теперь я уже не помню, правильно ли я пишу операнды MAXGROUPS и MAXLINE. Может, надо MAXGRP и MAXLINES?
Разработчиков этой утилиты в ОС ЕС можно еще понять. Им совсем не обязательно было знать какие-нибудь языки. А программисту фирмы IBM нечего сказать в свое оправдание. Я думаю, что эту утилиту делал двоюродный племянник коммерческого директора этой фирмы.
Он, впрочем, успел и еще кое-что подпортить. Наверное, это он придумал одно и то же действие по управлению данными в разных случаях запрашивать то как UNCATLG, то как UNCTLG. Возможно, это он предложил оператору при запуске программы системного вывода классы задавать так: "ABC", при модификации этой же программы классы задавать так: "CLASS=ABC", а при задерживании очередей классы задавать так: "Q=(A,B,C)".
А вот утилита IEBGENER ОС ЕС выполняет свои самые типовые действия вообще без всяких управляющих операторов. И только, если вам хочется чего-нибудь экзотического, то вам придется посмотреть описание этой утилиты. Принцип умолчания вреден только в языках программирования и лишь в том случае, когда нужно сделать надежную программу. А если нужно всего один раз получить легко проверяемый на корректность результат?
Когда мы садимся в лифт, то мы нажимаем кнопку нужного нам этажа. Можно даже представить себе лифт, где два одинаковых ряда кнопок с одними и теми же номерами этажей, и лифт тронется, лишь если нажаты обе кнопки с одним и тем же номером. Но очень трудно представить себе лифт, в котором стоит дисплей, и мы должны набрать на его клавиатуре фразу на французском языке, количество гласных букв в которой, деленное на тринадцать, даст в остатке номер нашего этажа. Вряд ли нас обрадует такой лифт, даже если в нем на полке будет стоять французско-русский словарь. Так почему же мы так часто делаем подобные программные системы?

4.4. ЕLEPHANT в посудной лавке.

 До чего умна программа сортировки ОС ЕС! Хочешь - рабочие наборы данных размещай на магнитных лентах (МЛ), хочешь - на магнитных дисках (МД). Хочешь - делай их три, а хочешь - все шесть. Хочешь - дай ей 20K основной памяти, а хочешь - все 400. Короче говоря, у вас масса возможностей. Допустим, вам надо рассортировать набор данных из трех логических записей. Что ж, садитесь и пишите задание. Это не займет у вас и получаса. Только не торопитесь, проверьте как следует. Ведь вы помните, что все рабочие наборы данных - три или больше - должны быть размещены на устройствах одного типа. Или на МЛ, или на МД. И если это устройство - МД, то не забудьте, что этим наборам данных должны быть выделены непрерывные участки памяти прямого доступа. Иначе вам ваши три записи никогда не рассортировать.
Ну вот, наконец, вы отладили свое задание, и оно начало выполняться. Теперь дело за ней, за сортировкой. Она-то уж свое дело знает. Прежде всего, она подумает, какой ей выбрать алгоритм, исходя из конкретных условий применения. У нее есть в запасе (о, мудрые создатели!) Несколько алгоритмов. Если от машинного времени, сэкономленного за счет правильного выбора алгоритма, отнять время, которое ушло на выбор этого алгоритма, то возможно получится положительная величина. Возможно даже, что эта разница в мировом масштабе применения настолько велика, что не выходя за поле положительных чисел, нам удастся отнять от нее машинное время, затраченное на разработку всего многообразия этих алгоритмов, исключая из этого числа любой, первый попавшийся. Но оставим эту заботу коммерческим директорам. Нас больше волнует другое. Что нам делать, если:
- Заранее неизвестно, сколько записей придется рассортировать. То ли 3, то ли 300 000. Эти величины вычисляются в том же задании.
- В нашей тесной посудной лавке нет ни трех лишних надежных лентопротяжек, ни трех лишних непрерывных участков дисковой памяти из расчета на максимальный объем сортируемых данных. А ведь у нас мультипрограммный режим, и вероятно, что одновременно "захотят" выполняться две или больше сортировок, хотя и маловероятно, что во всех случаях сортироваться будет много данных.
Увы, наш могучий слон будет бить посуду. Все его умные алгоритмы не рассчитаны на тесноту. Оптимизируется только время сортировки, без учета ограничений на другие ресурсы. Если ресурсов мало, сортировка не будет выполнена, хотя бы и медленнее.
Итак, перед СОД, использующей эту программу сортировки четыре альтернативы.

• Разбить вычислительный процесс на следующие автоматические стадии: определение требуемых ресурсов для сортировки; генерация задания на сортировку; выполнение этого задания (и т.д. для каждого случая сортировки).
• Отказаться от средств, критичных к объему дисковой памяти, в том числе и от этой программы сортировки. То есть, написать свою программу, которая "сама" возьмет столько ресурсов, сколько будет возможно, а затем будет сортировать данные столько времени, сколько нужно (быть может, даже целый час!).
• Иметь всегда достаточное, а точнее, избыточное количество дисковой памяти и распределить память заранее для всех одновременно возможных сортировок, что называется, "от души".
• Включить в состав СОД человека, который бы умел оценивать сверху предполагаемые размеры сортируемых данных и модифицировал соответствующие задания. Иногда, правда, после нескольких часов потерянного времени, ему бы пришлось чесать в затылке и говорить: "Эх, промахнулся!"

 Мне приходилось встречать системы, которые выбрали четвертую альтернативу, реже - третью. Но никогда - избравшие первые две. А жаль. Большинство ошибок людей в хорошо организованных системах связано с распределением ресурсов.

 4.5. Зерна и плевелы.

 Но вернемся к ППП Оргвыц. Для всех, кто хочет автоматизировать львиную долю неблагодарной ручной, рутинной работы по организации вычислительного процесса в ВЦ коллективного пользования, этот пакет представляет лакомый кусок. Давайте вкусим его и попробуем немного пожевать, но только осторожно. А то, не успеем мы еще войти во вкус, как послышится хруст сломанного зуба, и будет больно. Это в лакомом куске оказался кусочек гравия. Давайте, вместе рассмотрим его как следует под микроскопом.
ОС ЕС позволяет указывать местонахождение наборов данных двумя способами. Первый способ - через каталог системы, таблицу, где для каждого (каталогизированного) набора данных указаны имя тома, на котором этот набор данных находится, и тип устройства. Второй способ - тип устройства и имя тома указываются в задании каждый раз, когда в нем встречается имя этого набора данных. С точки зрения удобства управления СОД (в данном случае - ППП Оргвыц) лучше всю информацию о том, где какой набор данных находится, сконцентрировать в каталоге, тем самым, уменьшив и избыточность этой информации.
В самом деле, Оргвыц работает с десятком наборов данных, но в разных точках своих процедур на языке управления заданиями (ЯУЗ) ОС ЕС он ссылается на них около пятидесяти раз. Думаете, это делается через каталог? Как бы в насмешку над пользователем, в отдельных случаях это сделано через каталог, но тут же, рядом еще одна ссылка на тот же набор данных, но уже с указанием тома. Нам пришлось основательно порыться в этом лакомом куске, чтобы выковырять из него все кусочки гравия, то есть избыточную информацию.
- Чем же плоха избыточная информация? Какая разница, как ОС "доберется" до набора данных? Главное - результат. Вот, если бы не было информации, и задание закончилось бы аварийно... - Мог бы возразить создатель этого пакета.
Да, все верно. Все процедуры ЯУЗ будут работать, и контрольный пример, несомненно, пройдет. Но что делать бедным, несчастным парасистемным программистам, которым нужно будет перенести какие-то наборы данных с одного тома на другой. В каталоге они, естественно это отметят, а потом - либо просматривай все тексты процедур ЯУЗ на предмет выковыривания гравия, либо ломай зубы.
Избыточная информация нужна для обнаружения и исправления ошибок, а не для расширения штатного расписания подразделения парасистемных программистов.
Этюд. В некотором ВЦ разработали программное обеспечение некоторой СОД в среде ОС ЕС. Все модули этой сод написаны на языке PL/1, оттранслированы и отредактированы с полным разрешением внешних связей. В таком виде загрузочные модули (ЗМ) записаны в библиотеку. Это означает, что, если программы A, B, C и D содержат предложение CALL W в исходном тексте, то в библиотеке ЗМ они будут храниться в следующем виде: AW, BW, CW, DW.
Теперь представим себе, что в нашей СОД головных программ - 21 штука, а программ, которые вызываются этими головными - 214. По листингам легко определить, какие программы вызывают программу х, но никак не наоборот: какими программами вызывается программа х. Кроме того, к каждой головной программе редактор связей щедро присоединил программы периода выполнения из библиотеки транслятора PL/1, размножив их, таким образом, в количистве 21 экземпляр.
Но бог с ним, с объемом внешней памяти под библиотеку ЗМ. Пусть разработчики восторгаются количеством команд в своем детище. Радоваться им не долго, так как эту СОД они сделали, что называется, "для себя".
В один прекрасный день они нашли ошибку в программе Z, которая используется... Очень трудно сказать точно, где она используется. Примерно в 17 из 21 головных модулей. Ошибочка не очень страшная, почти все работает. Но, если запятая следует за пробелом, а длина записи больше 72 байт... В общем, нужно исправлять. Для этого нужно исправить исходный текст программы Z, оттранслировать ее, а затем отредактировать заново все 21 головных модулей, так как трудно сказать, какие из них не пользуются услугами программы Z.
Вот тут-то и начинается самое интересное. Исправление пришлось делать, что называется, "на живом теле", в рабочем экземпляре библиотеки ЗМ, чтобы как можно быстрее исправить эту ошибку, хотя бы в тех головных модулях, которые должны использоваться в ближайшее время. Исправление затянулось на две недели. При этом пользователи несколько раз получали неверные результаты, так как никто не знал, какие модули требуют исходных данных еще в "старом" виде, а какие - в "новом". При редактировании одного модуля произошла ошибка, которую не заметили, и модуль был неработоспособен двое суток. Два других модуля просто забыли отредактировать, и ошибку нашли только через месяц. Во время исправления одного из модулей отказала ЭВМ, и библиотека ЗМ пришла в негодность. Пришлось восстанавливать ее с позавчерашнего дампа. Но там было отредактировано на 7 модулей меньше, а может, на 8? Пока продолжалась вся эта эпопея, не смотря на массовый героизм разработчиков и эксплуатационников (успевших переругаться между собой), ВЦ сорвал свой и чей-то еще план, все, кому полагается по штатному расписанию, получили по выговору. Получил свой выговор и начальник ЭВМ, за то, что его любимица нашла не самый удачный момент, чтобы сломаться.
Передышка была недолгой. Не успели страсти утихнуть, как обнаружилась еще одна ошибка. На этот раз в программе Y.
Можно было бы обойтись и без героизма, если бы все 214 модуля СОД хранились в библиотеках в виде загрузочных модулей с неразрешенными внешними ссылками, а сборка модуля производилась бы каждый раз непосредственно перед его выполнением загрузчиком ОС ЕС. Это позволяет за счет дополнительных затрат машинного времени (около одного процента от основных затрат в среднем) сэкономить внешнюю память (быть может, в несколько раз). Но главное не в этом, а в том, что отсутствует дублирование и распыление управляющей информации. Тем самым, повышается гибкость и простота системы, способность ее к адаптации и совершенствованию, и в конечном счете, экономится то, что стоит дороже всего - труд и нервы высококвалифицированных специалистов.
Может, кто-нибудь думает, что систем, подобных описанной в последнем этюде не бывает? Увы, я вас должен разочаровать. Вы уже догадались, какой я приведу пример? Правильно, один из таких ППП - все тот же "Оргвыц".

4.6. Память в муравейнике.

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

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

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

Этюд. ППП "Пирамида".
1. Нижний уровень пирамиды - средства для индивидуальной отладки модулей пользователя. Эти и только эти средства (здесь не нужен системный подход) в изобилии имеются в распоряжении любого ВЦ. Требуется только составить ряд каталогизированных процедур языка управления заданиями. Элементом этого уровня является группа поколений последовательного набора данных. На каждого пользователя-программиста приходится несколько таких групп.
2. Второй уровень пирамиды - это небольшие библиотеки программ (точнее, пары из исходной и загрузочной библиотек). Одна такая библиотека выделяется на бригаду программистов. Она нужна для комплексной отладки программ. Ввиду прямой заинтересованности небольшого коллектива (один - пятеро) пользователей такой библиотеке особые неприятности не грозят. Ответственность за нее несет бригадир. Системные программисты только выполняют копирование всех библиотек второго уровня на случай сбоев. Копирование выполняется по принципу "все библиотеки одной процедурой". Забытых библиотек не бывает, так как поиск их ведется автоматически через каталог. Если бы не система ответственности, то этот второй уровень был бы не отличим от описанной в предыдущем этюде системы. Дело все как раз в этой системе ответственности. Именно прямая заинтересованность хозяина и обозримость границ владения обеспечивают общественные рефлексы на этом уровне. Благодаря этому, второй уровень пирамиды также может быть обеспечен существующими средствами почти без доработок. За основу может быть принята, например, прекрасная система ОФАП угольной промышленности (Перегудов). Требуется, правда, разработка интерфейса между первыми двумя уровнями - несколько каталогизировнных процедур языка управления заданиями.
3. Третий уровень пирамиды - это "предбанник", который должен компенсировать существенный недостаток библиотечного набора данных - возможность гибели при записи в него. В предбанник - библиотеку небольших размеров - свои модули записывают сами программисты-пользователи. После записи в такую библиотеку модуль оказывается включенным в эксплуатацию. При этом, в основной библиотеке еще существует "вытесненный" из эксплуатации одноименный модуль, который еще не поздно снова задействовать, уничтожив одноименный ему модуль в предбаннике.
По просьбе пользователей или периодически, либо все содержимое предбанника, либо часть его "выливается" в основную библиотеку. Одновременно с этим (в той же процедуре) содержимое этого предбанника "выливается" еще в одну библиотеку, где все такие "добавки" накапливаются до следующего страхового копирования.
Ответственность за правильность записи в предбанник несут пользователи. Предбанник невелик по размерам. Пользователям предписано хранить у себя экземпляры своих модулей до тех пор, пока они не получат официальное уведомление (в виде листинга, а не "испорченного телефона") о том, что их модуль "вылит" в основную библиотеку.
4. Четвертый уровень пирамиды состоит из следующих составных частей:
- Основные библиотеки;
- "Копилки предбанников", по одной на каждую основную библиотеку;
- Группы поколений резерва, по одной группе на каждую основную библиотеку.
Каждая группа поколений резерва - это несколько томов мл, одинаковых по структуре и содержащих следующие наборы данных:
- Копия основной библиотеки;
- Копия "копилки предбанников", в которой накоплено то, чем эта копия основной библиотеки отличается от предыдущей;
- Копия следующей "копилки предбанников".
Все это хозяйство защищено от несанкционированного доступа. За него отвечает системный программист. Смена поколений резерва (новое поколение резерва на МЛ самого старого) выполняется автоматически. Создание нового поколения резерва и опустошение "копилки предбанников" возможно лишь при успешном завершении формирования нового тома МЛ.
Опишем подробнее алгоритм выполнения процедуры REZAPAS, которая создает новые поколения резерва. В приведенном ниже алгоритме каждый пункт выполняется лишь при правильном выполнении всех предыдущих.
- Прочесть старую копию копилки и основной библиотеки на последнем поколении резерва;
- Записать в конец последнего поколения резерва новую копию копилки;
- Проверить записанное чтением;
- Найти через каталог том МЛ с самым старым поколением резерва и распределить его под новое поколение;
- Записать на новое поколение (опять) копию новой копилки;
- Записать следом копию новой (текущей) основной библиотеки;
- Проверить чтением новое поколение резерва;
- Закаталогизировать новое поколение резерва (закаталогизировав якобы находящийся на нем фиктивный набор данных из группы поколений). Только теперь новое поколение резерва перешло из кандидатов в "настоящие";
- Опустошить копилку.
Таким образом, в ведении системного программиста (и только в его) находятся всегда как минимум два экземпляра любого модуля. Вся эта система, кроме того, поддерживает пары библиотек, обеспечивая их взаимо-однозначное соответствие.
Из вышеприведенного этюда можно заметить, что такая система может облегчить жизнь подразделению системных программистов. Защищенность ее от ошибок и гибкость базируемых на ней программных систем значительно выше, чем у традиционной. Несчастье заключено лишь в том, что в полном объеме такой системы нет. Ос ЕС ЭВМ не обеспечивает автоматически ни предбанника, ни поколения раздела библиотеки (или хотя бы "призрака" раздела библиотеки). Организация такой системы в рамках ОС ЕС требует от ее пользователя выдерживания такого большого количества дополнительных ограничений на способ организации программных систем, базирующихся на "пирамиде", что легче, наверное, заставить всех пассажиров трамвая сортироваться по номеру своей остановки, а всех покупателей называть у кассы сначала номер отдела, а потом сумму.
Как видно из описанного выше, "пирамида" базируется практически на следующих идеях: разделение ответственности; локализация во времени и пространстве процессов модификации крупного файла (слияние с "предбанником"); автоматизация рутинной работы по ведению поколений резерва. А в результате, все могут спать спокойно, болеть, когда им хочется и - чего уж лицемерить - даже попадать под трамвай.

 4.7. С точностью до наоборот.

 Как легко, все-таки, переводить с английского на русский модальные глаголы. По-английски "to have to", "to be to", "must", "might", "should", а по-русски (не Пушкины же) все одно - "должен".
Этюд. В документации написано: "В поле операнда должен находиться символ кода дкои, отличный от "X" Как понимать эту фразу? Давайте пофантазируем. Сначала рассмотрим ситуацию, когда поле операнда может быть и пустым, но уж, если оно не пусто, то:

 1. Наличие в нем символа "X" диагностируется, как ошибка, процесс прекращается;
2. Наличие символа "X" диагностируется, как ошибка, он заменяется на 'Y', процесс продолжается;
3. Символ "X" допустим, но случай его использования в поле операнда описан в другом месте документации.
4. Эффект от наличия "X" в поле операнда неопределен.
5. Символ "X" поместить в поле операнда невозможно (отсутствует на клавиатуре);
6. "X" означает конец поля операндов;
7. Написание символа "X" в поле операнда - противоправное действие (как проезд на запрещающий сигнал светофора).

 Теперь вспомним еще одну возможность: "поле операнда "должно" быть не пустым". Фантазировать над этим последним "должно" мы не будем, а просто возведем число предыдущих вариантов в квадрат, чтобы учесть, например, такую комбинацию: "отсутствие символов в поле операнда приводит к аварийному окончанию, а наличие в нем символа "X" к замене его на 'Y' с продолжением обработки".
Не имея ничего против модальных глаголов, могу посоветовать потенциальным пользователям каких-либо программных систем, не искушать свою судьбу, связав ее с системой, документация которой не раскрывает неопределенностей своих императивных высказываний.

4.8. Живая вода.

 Перед нами "раненый" DD-оператор языка управления заданиями ОС ЕС:

//АLРНА DDD DСNАМЕ=ВLIN,SРАSЕ=(ТRС,20),UNТ=SYSDА,
// DIРS=(NЕW,САТGL),VОL=SЕR=КОМ
вы узнали его? Ну, конечно же, это практикантка Светочка хотела написать:

//АLРНА DD DSNАМЕ=ВLIN,SРАСЕ=(ТRК,20),UNIТ=SYSDА,
// DISР=(NЕW,САТLG),VОL=SЕR=КОМ

 Вы его узнали, а программа системного ввода, почему-то, не может. Это, видите ли, ниже ее достоинства. Она, видите ли, предупреждала, что ошибаться - плохо. Теперь же она наступит хладнокровно на раненого и пойдет себе дальше, не оглядываясь, сказав хорошо знакомую не знающей английского Светочке фразу "JOB NOT RUN! JСL ERROR!" Постой, программа системного ввода, не спеши. Вот тебе кувшин с живой водой, окропи раненого. Прежде всего, живая вода проверит, какие слова отличаются от наших на один символ. И вот уже исправлены DCNAME на DSNAME, а SPASE на SPACE. От мелких ран не осталось и рубцов, можно приниматься и за ранения средней тяжести. Сделаем это так: разделим число символов в "неправильном" слове пополам с недостатком. Полученное число даст нам длину сравниваемой левой (правой) части нашего слова с левой (правой) частью возможных ключевых слов. И вот уже исправлены DDD на DD, CATGL на CATLG, DIPS на DISP.
Не смейтесь, настоящие системные программисты. Я знаю, сейчас вы скажете, что с таким же успехом DDD можно исправить на DCB, что UCATLG можно исправить на UNCATLG и на CATLG, что этим не поможешь "именам собственным" (ALPHA, BLIN, SYSDA), что SPACE-(TRK, 20) так вообще не исправить на Sрасе=(TRK, 20) и что такие удобства увеличивают вероятность скрытой ошибки.
Все это верно, но все-таки, не пора ли нам делать не только языки, замечающие ошибки, но и языки их исправляющие? Если мы должны быть суровы и беспощадны к самим себе, к профессионалам, то не пора ли нам пожалеть практикантку Светочку? Ей, несчастной, и нужно-то всего лишь рассчитать один разок поле в ванне с электролитом. Ну какое ей дело до наших с вами "JOB NOT RUN"!

4.9. Пуганые вороны и стреляные воробьи.

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

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

4.10. Эшелонированная оборона.

 Энтропия - грозный противник любой СОД. Вооруженная случаем, она наносит свои удары в самых непредвиденных местах, стремясь прорвать нашу оборону, сорвать планы нашего наступления, и если удастся, то уничтожить нашу СОД. Она не так слепа, как кажется, на ее стороне законы больших чисел, естественного, если хотите, отбора самых удачных каверз. Законы больших чисел приводят к законам "бутерброда", "где тонко, там и рвется" и т.п. Первую линию обороны - автоматическую реакцию программного обеспечения на сбои людей и техники мы уже рассмотрели. Когда эта линия обороны прорвана, в бой вступают люди. Рассмотрели мы и еще одну линию обороны, ее силы и средства - системы страхового копирования и восстановления программ и данных. Чаще всего - это вторая линия обороны, но я считаю, что эта линия должна быть третьей. А что же во второй линии? Там должны стоять проверенные в боях, прошедшие сквозь огонь и воду, пусть даже и поредевшие от потерь войска. Эти так просто не отступят.
Этюд. В программы АСУ "Кадры" вкрались ошибки. Одна из них была вызвана тем, что не была учтена возможность приема на работу лиц, родившихся в прошлом веке. В результате, бабушка 1899 года рождения попала в несоюзную молодежь. Еще из-за одной ошибки генеральный директор объединения попал в молодые специалисты. Были и еще кое-какие мелочи. Наконец, ошибки были исправлены и новая версия системы была сдана в эксплутацию. А дальше было вот что.
В 23 часа 30 мин. На работу после занятий на вечернем факультете пришла девочка Оля. Она - так называемый диспетчер СОД. В ее обязанности входит "держать" вторую линию обороны. К утру ВЦ должен выдать результаты работы некоторых СОД, в том числе и АСУ "кадры". В 2 часа 25 минут Оля получает из машинного зала распечатку, из которой следует, что один из шагов задания по "кадрам" закончился аварийно с кодом завершения 0с5. Что это такое - Оля не знает. Она ведь только на третьем курсе. Но Оля четко знает, как использовать последний шанс получить результат. Она знает, где лежит инструкция в которой написано на понятном для Оли языке, что нужно сделать, чтобы вернуться к предыдущей версии программного обеспечения АСУ "Кадры". Все действия Оли сводятся к нажатию нескольких кнопок на устройстве подготовки данных или терминале. Остальное довершит программное обеспечение. Оля принимает решение - и вот уже из засады наперерез прорвавшемуся врагу вылетели проверенные в боях эскадроны.

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

4.11. Заметки по поводу.

 Переход от анализа качества программы к анализу качества комплексов программ [1] - это шаг вперед. Еще один шаг - это учет качества документации комплексов программ. Но и этого уже мало.
Первое. Часто оказывается полезным рассматривать группы независимых комплексов программ в среде их обитания - операционной системе, ВЦ, коллективе специалистов.
Второе. Документация на комплексы программных средств должна не только описывать, как этими средствами можно пользоваться, но и предлагать систему правил, технологию [2], указывающую, как этими средствами должно пользоваться.
Третье. То, что разработчик ПО считает высокой удобочитаемостью, информативностью и т.п., для пользователя сод, непрограммиста, может оказаться чем-то прямо противоположным.
Четвертое. Человеческий фактор, учитываемый в последних работах по качеству ПО, должен стоять одним из первых в ряду оценок качества.

5. Заключение.

 СОД - это комплекс программ, данных, людей, оборудования. Это обуславливает разницу между сопровождением (обслуживанием) ПО, и обслуживанием СОД. Причин здесь несколько. 1) Все экземпляры ПО одинаковые, а все экземпляры СОД - разные. Поэтому обслуживание ПО можно производить централизовано, в отличие от обслуживания СОД. 2) Обслуживание ПО - это работа прежде всего с математическими абстракциями, а обслуживание СОД - это работа с реальным оборудованием, реальными данными и людьми. Именно эта разница существенно снижает ценность литературы по качеству ПО для тех, кто имеет дело с системами, которые я здесь называю "СОД". Можно и нужно восполнить этот пробел.
В последнее время операционные системы делаются не для ЭВМ, а, наоборот, ЭВМ делаются для операционных систем [9]. А для чего делаются операционные системы? Только ли для программистов, которые делают операционные системы? Не стоит ли сделать еще один шаг вперед и задать вопрос: кому еще и для чего еще нужны операционные системы.

6. Послесловие.

 Ну как, дорогие настоящие системные программисты, я еще не открутил пуговицу на вашем пиджаке? Что ж, я заканчиваю. ОС ЕС, конечно, дело прошлое. Мы как-нибудь со старушкой домучаемся, а вы уж, там, за сияющими горизонтами программного изобилия не подкачайте. А не то из-за дефицита кадров придется и вам переквалифицироваться в парасистемщики.

7. Литература.

1. Липаев В.В. Качество программного обеспечения. М. 1983.
2. Фуксман А.Л. Технологические аспекты создания программных систем. М. 1979.
3. ППП ГDВ ОС. Центрпрограммсистем. Калинин 1980.
4. Генератор программ ввода данных для ЕС ЭВМ. М. 1976.
5. 1Ф3.049.015 Фо. ЕС-7903. Формуляр.
6. Комплекс программных средств "организация работ вычислительного центра". ЦФАП АСУ, рег. Номер 260.
7. Мартин Дж. Организация баз данных в вычислительных системах. Пер. С англ. М. 1980
8. Боэм Б. И др. Характеристики качества программного обеспечения. Пер. С англ. М. 1981.
9. Пентковский В.М. Автокод Эльбрус. М. 1982.