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

Этюд.

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

Hа вц, где эксплуатируется СОД, операторы ЭВМ всегда запрещают запись в набор данных, если у них нет письменного распоряжения одноразового действия на разрешение записи. И все было бы очень хорошо, если бы не то обстоятельство, что делать запись в эту библиотеку приходится 10–15 раз в сутки. Пока СОД работала на уровне контрольного примера, и частых модификаций библиотеки не было, все было в порядке. Hо стоило только "выйти на проектную мощность", как началась неразбериха: письменные распоряжения о разрешении и записи не поспевали за запросами. Сначала операторы ЭВМ добросовестно запрещали в таких случаях запись в библиотеку. Их стали за это ругать. — Что вы, не знаете, что ли, что в эту библиотеку запись запрещена просто так, — говорили им.

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

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

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

Работа операторов подготовки данных основана на рефлексах и только на них. Любые попытки заставить их принимать решение встречает с их стороны резкий отпор и увеличивает количество ошибок. Оператору подготовки данных легче занести лишних сто байт информации, чем принять решение, стоимостью в один бит: стоит или не стоит эти 100 байт заносить. Компенсацией однообразного, механического характера работы является возможность думать в это время о чем-то своем, слушать музыку. Hе отнимайте этого у них, иначе вы останетесь без персонала подготовки данных Поэтому, системы подготовки даных, дающие оператору массу альтернативных возможностей тем хуже, чем больше у него этих возможностей. Следующий пример может послужить контрпримером к приведенному в главе "три лица будды" этюду с ГВВ и утилитой IEBUPDTE.

Этюд.

В некоторой системе подготовки данных за единицу данных принят документ (термин, понятный персоналу подготовки данных), который состоит из реквизитов. Первым реквизитом всегда идет номер документа, который может не указываться оператором подготовки данных. Система присвоит ему номер сама так, чтобы документ поместился на хранение вслед за последним из записанных в хранилище. Оператор подготовки данных не знает ни ОС, ни языка управления заданиями, ни даже того, что эти хранилища (их все называют "ячейками") — это наборы данных на устройствах прямого доступа. Вслед за номером документа идет реквизит — признак вычеркивания. Это буква "ы". Затем идут остальные реквизиты. Документы или исправления документов, относящиеся к разным "ячейкам", разделены специальным документом "бирка". Например, документы в потоке ввода системы могут выглядеть так:

@@бирка а25н34е48

::тетрадь:25 7

::чернильница:45 5:ы:

::карандаш:2

::ручка:210:

@@биркар34а56н37

::чехова: ул:25:18:

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

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