Записки парасистемного программиста

1. Предисловие. Вопль к создателям

Мы не пишем программ, или почти не пишем. Мы живем за чужой счет. Мы — паразиты. Вы, наши дорогие коллеги, в тиши кабинетов, попутно печатаясь и защищаясь, создаете один из видов национального продукта — программное обеспечение. Мы же не создаем национальный продукт. Мы лишь пытаемся его хоть как-то использовать в тех вычислительных центрах, в которых мы работаем. Спору нет, вы научились делать надежное программное обеспечение, и мы знаем, чего вам это стоило. Мы, ведь, тоже читаем книги по технологиям программирования, хотя, значительно реже их пишем. Надежное программное обеспечение, то есть соответствующее документации — это уже хорошо. Hо нам этого мало. Этого достаточно там, где нас нет, например, на Луне, там, где программное обеспечение все делает "само", без участия человека. Надежное программирование — панацея от всех бед и там, где программное обеспечение работает независимо от предыстории (трансляторы, библиотеки стандартных программ), то есть, оно не создает и не поддерживает какие-то жизненно важные файлы. Там же, где программное обеспечение включено в одну систему обработки данных (сод) вместе с человеком, там, где поведение системы зависит от предыстории (операционные системы, банки данных, АСУ, например) там надежного программирования оказывается мало. Там уже нужна живучесть и жизнеспособность всей системы обработки данных, что, увы, выходит за рамки традиционного системного программирования. В последнее время вы всерьез занялись анализом качества программ и даже больших программных комплексов [1,8]. Hо если говорить о системах, которые я называю СОД, то этот анализ затрагивает в основном разработчиков ПО, пользователей ПО и тех, кто сопровождает ПО СОД. Вопросы же обслуживания не ПО, а всей СОД, как единого целого, остаются все еще без внимания. Потому-то мы и существуем, парасистемные программисты, приставленные денщиками то к генератору ввода, то к операционной системе, то к системе управления базами данных (СУБД), а то еще и к какой-нибудь АСУ "зарплата" или "подготовка кадров". Чаще всего одна такая система одним денщиком не обходится, а систем этих — великое множество. Hа каждом ВЦ они завязаны в иерархические системы. Hа нижнем их уровне находятся, как правило, операционные системы со своим обслуживающим персоналом и пользователями. Затем, выше, идут СУБД и системы, вроде "Rамы", "PPB", "JEC" и т. п. Со своим обслуживающим персоналом и пользователями. За ними идут всевозможные АСУ и сапр, естественно, со своими пользователями, а главное, с обслуживающим их персоналом. В общем, до безработицы нам, парасистемным программистам далеко. Вот такие системы, как правило, с участием людей (обслуживающего персонала и пользователей самой разной квалификации), допускающие, в основном, перерывы в функционировании на ремонт и восстановительные работы, но абсолютно не допускающие утери текущего состояния (в том числе, файлов или баз данных) я и хочу проанализировать. Проанализировать с точки зрения их жизнеспособности, с точки зрения их, если хотите, угодливости и понятливости, выносливости и живучести, честности и верности. Вы уже поняли, чего я хочу. Я хочу, что бы не я был лакеем при программном обеспечении системы обработки данных, а оно было лакеем при пользователе этой СОД. Как вы уже догадались из названия, этот анализ не претендует на научность. Он лишь представляет собой попытку на отдельных этюдах из жизни парасистемных программистов поставить проблемы. Решать же эти проблемы придется вам, решать настоящими, системными методами.

2. Введение

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

3. Железо, как оно есть

Разработчики некоторых систем обработки данных, видимо, работают в идеальных условиях. В тех вычислительных центрах (вц), в которых они изготавливают свои системы, никогда не бывает сбоев и отказов оборудования. Поэтому, они никогда не заглядывали в документацию по аппаратным средствам, в которой указаны те или иные вероятностные характеристики сбоев и отказов. Hу, а если какой-либо сбой все же доставит некоторую неприятность, то виноваты, конечно же, неграмотные и ленивые электронщики. Видимо, те вц, где электронщики столь же плохи, просто недостойны такой замечательной системы. Hу, а в целом, дела идут хорошо. Ведь контрольный пример проходит так быстро, а выполнить правильно его нужно всего лишь один раз… Если передо мной лежит документация на некоторую программную систему, входящую в состав СОД, и в ней нет ни слова о реакции этой системы на те или иные сбои, то я или отказываюсь сразу же от такой системы, либо выясняю возможность доработки и планирую ее. Примерами таких систем являются генераторы ввода [3,4], которые могут применяться лишь там, где они, в общем-то, и не нужны, там где вводится за один прием столь мало данных, что вероятность сбоя невелика.

Этюд.

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

Любопытно, что чем надежнее работает оборудование в вц, использующем такой ППП, тем больший удар ожидает пользователя, когда сбой произойдет, и он потеряет все то, что так долго собирал. Возможно, я не объективен по отношению к разработчикам ППП "оргвыц". Что говорить о них, если даже в книге дж. Мартина [7] проблемам организации баз данных посвященно 660 страниц, а проблемам, связанным с аппаратной надежностью и живучестью (целостностью) баз данных, говорится на 14 строках 45-й страницы и 8-ми строках 309-й. Десять страниц этой книги посвящены индексно-последовательным наборам данных, а о проблемах, связанных с их целостностью, не говорится ни слова.

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

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

Этюд.

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

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

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

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

Это и дефицит обслуживающего персонала (электронщиков и механиков) и отсутствие запасных магнитных головок, и нестабильность питания, отсутствие хорошего заземления и т. п. (Вы, пишущие могучие трансляторы, придумывающие языки программирования и системы управления базами данных, знаете ли вы, как качество заземления влияет на работоспособность ваших детищ?). В результате некоторых раздумий было решено зафиксировать I в определении взаимозаменяемости, то есть разрешить инициализацию только на одном из имеющихся дисководов, как для проверки, так и для работы. Это решение позволило высвободить электронщикам значительную часть своего времени и запасных частей для решения других насущных проблем, а барьер был пробит, и ВЦ стал дальше развивать свою вычислительную мощь… Чтобы — такова жизнь — уткнуться через некоторое время в следующий барьер. Первый барьер был вызван систематическими, регулярными причинами, и они были устранены.

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

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

Этюд.

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

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

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

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

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

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

Этюд.

Некоторые генераторы ввода данных предлагают своим пользователям исправлять ошибки в промежуточных файлах утилитой 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, а они вот уже две недели, как на овощебазе. Впрочем, это все фантастика. Hа таких вц, естественно, вообще нет никаких операторов. Просто в машинном зале одновременнно возле одного пульта оператора толпятся несколько человек, мешая друг другу и не зная, что им делать можно, что — нужно и чего им делать нельзя. Ниже мы рассмотрим некоторые способы упрощения всех трех указанных интерфейсов, независимо от того, к кому они обращены. К разработчику ли системы, к ее пользователю или персоналу.

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

Этюд.

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

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о очень трудно представить себе лифт, в котором стоит дисплей, и мы должны набрать на его клавиатуре фразу на французском языке, количество гласных букв в которой, деленное на тринадцать, даст в остатке номер нашего этажа. Вряд ли нас обрадует такой лифт, даже если в нем на полке будет стоять французско-русский словарь. Так почему же мы так часто делаем подобные программные системы?

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

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

Этюд.

В некотором ВЦ разработали программное обеспечение некоторой СОД в среде ОС ЕС. Все модули этой сод написаны на языке PL/1, оттранслированы и отредактированы с полным разрешением внешних связей. В таком виде загрузочные модули (ЗМ) записаны в библиотеку. Это означает, что, если программы A, B, C и D содержат предложение CALL W в исходном тексте, то в библиотеке зм они будут храниться в следующем виде: AW, BW, CW, DW. Теперь представим себе, что в нашей СОД головных программ — 21 штука, а программ, которые вызываются этими головными — 214. По листингам легко определить, какие программы вызывают программу х, но никак не наоборот: какими программами вызывается программа х.

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

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

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

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

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

4. Четвертый уровень пирамиды состоит из следующих составных частей: — Основные библиотеки; — "Копилки предбанников", по одной на каждую основную библиотеку; — Группы поколений резерва, по одной группе на каждую основную библиотеку. Каждая группа поколений резерва — это несколько томов мл, одинаковых по структуре и содержащих следующие наборы данных: — Копия основной библиотеки; — Копия "копилки предбанников", в которой накоплено то, чем эта копия основной библиотеки отличается от предыдущей; — Копия следующей "копилки предбанников". Все это хозяйство защищено от несанкционированного доступа. За него отвечает системный программист. Смена поколений резерва (новое поколение резерва на МЛ самого старого) выполняется автоматически. Создание нового поколения резерва и опустошение "копилки предбанников" воможно лишь при успешном завершении формирования нового тома мл. Опишем подробнее алгоритм выполнения процедуры REZAPAS, которая создает новые поколения резерва.

В приведенном ниже алгоритме каждый пункт выполняется лишь при правильном выполнении всех предыдущих.

— Прочесть старую копию копилки и основной библиотеки на последнем поколении резерва;

— Записать в конец последнего поколения резерва новую копию копилки;

— Проверить записанное чтением;

— Найти через каталог том МЛ с самым старым поколением резерва и распределить его под новое поколение;

— Записать на новое поколение (опять) копию новой копилки;

— Записать следом копию новой (текущей) основной библиотеки;

— Проверить чтением новое поколение резерва;

— Закаталогизировать новое поколение резерва (закаталогизировав якобы находящийся на нем фиктивный набор данных из группы поколений). Только теперь новое поколение резерва перешло из кандидатов в "настоящие";

— Опустошить копилку.

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

Как легко, все-таки, переводить с английского на русский модальные глаголы. По английски "to have to", "to be to", "must", "might", "should", а по русски (не Пушкины же) все одно — "должен".

Этюд.

В документации написано: "В поле операнда должен находиться символ кода дкои, отличный от ъхъ". Как понимать эту фразу? Давайте пофантазируем. Сначала рассмотрим ситуацию, когда поле операнда может быть и пустым, но уж, если оно не пусто, то:

1. Наличие в нем символа ъхъ диагностируется, как ошибка, процесс прекращается;

2. Наличие символа ъхъ диагностируется, как ошибка, он заменяется на 'Y', процесс продолжается;

3. Символ ъхъ допустим, но случай его использования в поле операнда описан в другом месте документации.

4. Эффект от наличия ъхъ в поле операнда неопределен.

5. Символ ъхъ поместить в поле операнда невозможно (отсутствует на клавиатуре);

6. ЪХъ означает конец поля операндов;

7. Написание символа ъхъ в поле операнда — противоправовое действие (как проезд на запрещающий сигнал светофора).

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

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

//АLРНА DDD DСNАМЕ=ВLIN,SРАSЕ=(ТRС,20),UNТ=SYSDА, //

DIРS=(NЕW,САТGL),VОL=SЕR=КОМ

вы узнали его? Hу, конечно же, это практикантка Светочка хотела написать:

//А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.

Hе смейтесь, настоящие системные программисты. Я знаю, сейчас вы скажете, что с таким же успехом DDD можно исправить на DCB, что UCATLG можно исправить на UNCATLG и на CATLG, что этим не поможешь "именам собственным" (ALPHA, BLIN, SYSDA), что SPACE-(TRK, 20) так вообще не исправить на Sрасе=(TRK, 20) и что такие удобства увеличивают вероятность скрытой ошибки. Все это верно, но все-таки, не пора ли нам делать не только языки, замечающие ошибки, но и языки их исправляющие? Если мы должны быть суровы и беспощадны к самим себе, к профессионалам, то не пора ли нам пожалеть практикантку Светочку? Ей, несчастной, и нужно то всего лишь рассчитать один разок поле в ванне с электролитом. Hу какое ей дело до наших с вами "JOB NOT RUN"!

Этюд.

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

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

Энтропия — грозный противник любой СОД. Вооруженная случаем, она наносит свои удары в самых непредвиденных местах, стремясь прорвать нашу оборону, сорвать планы нашего наступления, и если удастся, то уничтожить нашу СОД. Она не так слепа, как кажется, на ее стороне законы больших чисел, естественного, если хотите, отбора самых удачных каверз. Законы больших чисел приводят к законам "бутерброда", "где тонко, там и рвется" и т. п. Первую линию обороны — автоматическую реакцию программного обеспечения на сбои людей и техники мы уже рассмотрели. Когда эта линия обороны прорвана, в бой вступают люди. Рассмотрели мы и еще одну линию обороны, ее силы и средства — системы страхового копирования и восстановления программ и данных. Чаще всего — это вторая линия обороны, но я считаю, что эта линия должна быть третьей. А что же во второй линии? Там должны стоять проверенные в боях, прошедшие сквозь огонь и воду, пусть даже и поредевшие от потерь войска. Эти так просто не отступят.

Этюд.

В программы АСУ "кадры" вкрались ошибки. Одна из них была вызвана тем, что не была учтена возможность приема на работу лиц, родившихся в прошлом веке. В результате, бабушка 1899 года рождения попала в несоюзную молодежь. Еще из-за одной ошибки генеральный директор объединения попал в молодые специалисты. Были и еще кое-какие мелочи. Наконец, ошибки были исправлены и новая версия системы была сдана в эксплутацию. А дальше было вот что. В 23 часа 30 мин. Hа работу после занятий на вечернем факультете пришла девочка оля. Она — так называемый диспетчер СОД. В ее обязанности входит "держать" вторую линию обороны. К утру ВЦ должен выдать результаты работы некоторых СОД, в том числе и АСУ "кадры".

В 2 часа 25 минут оля получает из машинного зала распечатку, из которой следует, что один из шагов задания по "кадрам" закончился аварийно с кодом завершения 0с5. Что это такое — оля не знает. Она ведь только на третьем курсе. Hо оля четко знает, как использовать последний шанс получить результат. Она знает, где лежит инструкция в которой написано на понятном для оли языке, что нужно сделать, чтобы вернуться к предыдущей версии программного обеспечения АСУ "Кадры". Все действия оли сводятся к нажатию нескольких кнопок на устройстве подготовки данных или терминале. Остальное довершит программное обеспечение. Оля принимает решение — и вот уже из засады на перерез прорвавшемуся врагу вылетели проверенные в боях эскадроны.

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

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

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

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

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

1) Все экземпляры ПО одинаковые, а все экземпляры СОД — разные. Поэтому обслуживание ПО можно производить централизовано, в отличие от обслуживания СОД.

2) Обслуживание ПО — это работа прежде всего с математическими абстракциями, а обслуживание СОД — это работа с реальным оборудованием, реальными данными и людьми.

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

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

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

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

1. Липаев В.В. Качество программного обеспечения. М. 1983.

2. Фуксман А.Л. Технологические аспекты создания программных систем. М. 1979. 3. ППП ГDВ ОС. Центрпрограммсистем. Калинин 1980.

4. Генератор программ ввода данных для ЕС ЭВМ. М. 1976.

5. 1Ф3.049.015 Фо. ЕС-7903. Формуляр.

6. Комплекс программных средств "организация работ вычислительного центра". ЦФАП АСУ, рег. Номер 260.

7. Мартин Дж. Организация баз данных в вычислительных системах. Пер. С англ. М. 1980 8. Боэм Б. И др.

8. Характеристики качества программного обеспечения. Пер. С англ. М. 1981. 9. Пентковский В.М. Автокод Эльбрус. М. 1982.