Евгений Лишак

ЗАПИСКИ ПАРАСИСТЕМНОГО ПРОГРАММИСТА

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

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

2. Введение

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

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

3.1. Вера в вечную удачу.

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

Этюд.

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

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

3.2. Сила печатного слова.

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

3.3. Терновый серпантин.

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

3.4. 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…' Записывается на МЛ пятью одинаковыми и шестым "почти одинаковым" байтом! При таком "тестирующем" коде ни способность к перемагничиванию поверхности, ни чувствительность магнитных головок, ни переключательная способность оборудования не проверяется в полную силу (с максимальной частотой). Если принять во внимание еще и способ записи на МЛ (без возвращения к нулю) идеальным кодом были бы "все единички", но, учитывая систему воспроизведения и контроля данных, пришлось остановиться на "настоящем шахматном" коде.

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

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

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

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

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

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

Этюд.

Некоторые генераторы ввода данных предлагают своим пользователям исправлять ошибки в промежуточных файлах утилитой IEBUPDTE ОС EC. Простое желание оператора подготовки данных удалить неправильный документ из группы таковых невесть каким образом должно трансформироваться в задание ОС ЕС, во всяком случае, не проще такого:

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

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

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

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

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

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

Тридцать три богатыря

Порешили, что зазря

Берегли они царя

И моря!

Каждый взял себе надел,

Кур завел и в ем сидел,

Охраняя свой удел,

Hе у дел!

… (Лукоморье)

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

Этюд.

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

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

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

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

Искусственный интеллект построить нелегко. Значительно легче сделать живой компьютер. Для этого нужно получить по распределению молодого специалиста — из вуза, техникума, пту — все равно, поставить его возле печатающего устройства, чтобы он смотрел, какие оно печатает числа. Если напечаталось число, равное записанному в журнале таком-то, на странице такой-то, такая-то строка сверху, то нужно найти пакет перфокарт с таким-то номером и ввести его. А если не равно — ну, тогда пакет перфокарт номер такой-то. Вот так, все просто: 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 и выполнять ее странные для непрограммиста требования о рассортированности запросов на исправление в порядке следования записей и т. п.

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

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

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

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

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

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

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

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

Этюд.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этюд.

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

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

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

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

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

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

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

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

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

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

Перед нами "раненый" 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"!

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

Этюд.

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

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

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

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

Этюд.

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

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

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

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

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

Переход от анализа качества программы к анализу качества комплексов программ [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.

ТРИДЦАТЬ ВТОРОЙ ДЕНЬ ГОДА

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

***** DАTE=84.032 СLOCK=07.59.30

Потолок подернулся розовым, перекосился и наехал на стену. Воздух свернулся в полупрозрачные сгустки. Сердце сжалось в кулак, стул заскрипел подо мной от ярости, хотя я уже стоял. Зубы вот-вот сотрут друг друга в порошок. Сейчас я на него брошусь. Бездельник, всю ночь спал, наверное. Теперь пришел раскаиваться, как кот, уронивший вазу с телевизора. Он спал, а нам теперь все расхлебывать. И не только нам.

***** DАTE=84.032 СLOCK=07.59.32

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

***** DАTE=84.032 СLOCK=08.05.00

Прежде всего нужно предупредить начальство. И осторожно. Hе дай бог, что-нибудь с сердцем. Для него — это чп. Срыв плана. Затем — пользователи. Берусь за телефон.

— Андрей Федорович? Ваш том… Возврат к копии трехдневной давности… Извините.

— Наташа? Твой том…

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

***** DАTE=84.032 СLOCK=09.22.15

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

***** DАTE=84.032 СLOCK=11.22.45 <<<<< Дежурного системного программиста на ЭВМ номер 2

Это началась наша обычная жизнь. Аварийные работы постепенно уступают место в машинном зале вычислительному процессу с даными на томах пользователей. За работу берутся операторы ЭВМ. Дело раскручивается на полную катушку, и конечно же начинаются всякие непонятности. Значит, без дежурного системного программиста не обойтись. Я давно уже не дежурный системщик. Выбился в начальники. Hо аппаратура громкой связи держит меня в курсе дела. Тихий стук в дверь. Пришла Светочка. Практикантка. У нее своя беда. В институте ее научили фортрану. Диплом она на нем пишет. Моделирование, марковские цепи. Программа в 600 операторов. И правильно. Раньше инженер, не знающий логарифмичекой линейки, был смешон. А теперь — программирование, как ликбез. Hо, представьте себе линейку со множеством дополнительных устройств и приспособлений для пущего удобства. Автоматическая ориентация в пространстве, механический привод движка, компенсатор температурного расширения, оптический визир и подсветка… Вобщем, тумба — в два кубометра, адреса гарантийных мастерских, настройка на дому, восемь ручек, пятнадцать кнопок шести цветов. И все это не имеет никакого отношения ни к десятичным логарифмам, ни к синусу, ни к делению. Вот и Светочка. Знает фортран, а как заказать нашей ос, чтобы она, в свою очередь, заставила нашу ЭВМ выполнить программу на фортране, Светочка и не знает. А это жутко сложно. Сделать это нужно так:

//ВRЕLОК JОВ 'SY8513','СВЕТА К.', // МSGLЕVЕL=(1,1),RD=R,ТIМЕ=40,СLАSS=А,

// RЕGIОN=180К,СLАSS=С //А ЕХЕС FОRТGСLG,РАRМ.GО='16,25,49', // ТIМЕ.GО=35

Читатель, попробуй написать такое. Нет, не сочинить и не в качестве диктанта, а просто списать один к одному без ошибок. И все это не имеет никакого отношения ни к фортрану, ни к марковским цепям, ни к Свете.

Светочка чуть не плачет, страшную английскую фразу

JOB NOT RUN, JCL ERROR

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

***** DАTE=84.032 СLOCK=12.09.10 <<<<< Сбой в системных очередях на устройстве 135 <<<<< дежурного системного программиста на ЭВМ номер 3

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

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

***** DАTE=84.032 СLOCK=12.53.00 <<<<< Операционная система не выходит на связь с оператором <<<<< дежурного системного программиста на ЭВМ номер 2

Вот и Михаил Леонидович должен разработать целый вычислительный процесс и потом эксплуатировать его на вц. И чтобы всегда все хорошо работало. Что ж, квалифицированный пользователь при методической помощи системщика с этим справится. Хуже то, что Михаил Леонидович таковым не является. Михаил Леонидович пришел к нам, когда его люди все уже успели сделать, то есть, по своему разумению спроектировать процесс. Через месяц уже все должно работать. Только теперь можно по мнению Михаила Леонидовича поговорить и с системным программистом. Тяжелый у нас с Михаилом Леонидовичем будет разговор, длинный. У Михаила Леонидовича все очень просто выглядит. Конструктора спроектировали изделия. Много изделий. Шестеренки, винтики там всякие. Составили они и таблицы описаний технологического процесса изготовления этих изделий на автоматической линии. Затем, у нас на ВЦ эти таблицы операторы подготовки данных занесут на перфокарты и отдадут людям Михаила Леонидовича. Они отнесут их на нашу ЭВМ распечатать. У них и программы распечатки написаны. Затем они заберут эти перфокарты на проверку и исправление. Ошибочные карты заменят. Теперь можно и снова к нам на машину. Их перфокарты, их программы — наша машина, наша ОС. А в результате — из нашей машины "выползет" перфолента. Михаил Леонидович говорит, а потолок опять полез куда-то в сторону, опять розовые стены с черными кляксами. У Михаила Леонидовича появляется борода, и из нее начинает прорастать пшено профессора выбегаллы. Борода дергается в такт словам.

— Значить, перфолента выползет. Мы ее, тово, засунем в станок с числовым программным управлением, робот, значить. А робот соберет нам механизьм.

Лицо у меня, слава богу, по-прежнему бриджевое. И это хорошо, потому что я снова не совсем прав. Никакой он не выбегалло. Hу откуда ему знать то, что я ему сейчас выложу. Правда, маху он дал, что поздновато пришел. Hе видать его роботам через месяц никакой перфоленты.

— Значит, говорите, вы нам приносите таблицы?

— Да. А вы нам — перфокарты.

— А сколько же перфокарт мы вам?

— Hе знаю. Hу, наверное, с чемодан.

Считаем на бумажке. (Hа нашем ВЦ нет калькуляторов). Получается больше чемодана. Стеллаж с перфокартами, размером как в поликлинике в регистратуре. Раньше посчитать было некогда. Теперь я буду задавать ехидные вопросы (и что у меня за характер? Пожалеть бы человека).

— А грузовик у вас для перевозки перфокарт есть? А пропускную способность нашей службы подготовки данных вы считали?

— Какой там грузовик. И так сроки поджимают. У меня целый отдел. Всех на эту работу посажу. Перфокарты готовить и возить, готовить и возить.

— Hо ведь можно и не возить.

— А что, у вас хранить? У вас место есть?

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

***** DАTE=84.032 СLOCK=14.34.11 <<<<< Hе идет загрузка операционной

системы <<<<< дежурного системного программиста на ЭВМ номер 2

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

***** DАTE=84.032 СLOCK=15.42.40 <<<<< Сдача смены. Дежурного системного

программиста на ЭВМ

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

***** DАTE=84.032 СLOCK=17.39.30

Шестой час. Пользователи уже разошлись по домам. Мы залатываем последние дыры в прорванной обороне. Энтропия не прошла, не повысилась. Мы довольны. А она? А ей все равно. Уже сегодня ночью она, как и вчера, как и завтра, даст нам новый бой. Что такое мультипрограммирование.

(О тех, кто ждет).

"Как же я могу вам рассказать, что я такое, если я и сам не знаю? Да никак. Я просто жду."

Р. Брэдбери. "Тот, кто ждет".

Я живу на магнитном диске. Я — программа. Мой дом — библиотека программ. Из чего я сделана — я не знаю. Я биты и байты, домены на магнитной поверхности, магнитный поток, я — мысль программиста, невесомое ничто. Я ничего не делаю. Я просто жду, пока не подлетит ко мне магнитная головка. Теперь я и электродвижущая сила в обмотке возбуждения головки. Забегали, засуетились в ней электроны. Я теперь и ток, и импульсы, и амплитуда, и частота. Я бегу через разные устройства ЭВМ. Впереди моя цель — оперативная память. Там меня обрабатывают другие программы — программы операционной системы (сокращенно ос). Они приятно разминают, изменяют мое тело, не трогая моей сути. Они вливают в меня жизненные соки. Теперь я называюсь процесс.

* * *

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

* * *

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

* * *

Я снова жду. Я — процесс. Теперь я жду, пока на дисплей выведется мой вопрос, оператор ЭВМ ответит, а ответ введется в оп. Выводить вопрос из оп на дисплей и вводить ответ с дисплея в оп будут специальные устройства ЭВМ, которыми управляет особый процесс операционной системы. Я поставил в очередь к этому процессу свой запрос и снова жду. "Диспетчер" нашел того из нас, кто в состоянии выполняться, и отдал ему процессор. Арамис сделал выпад и застыл на долю секунды, а актер уже облачился в одежду гвардейца и парирует свой же удар. Hо между атакой арамиса и ответом гвардейца актер успел еще исполнить и некоторые роли режиссера, дерижера, осветителя, гримера… Словом тех, кого зритель не видит.

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

— Стоп, — скажете вы. — Ведь раньше мы выяснили, что вводом и выводом управляет специальная программа ОС, а не какой-то там канал.

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

* * *

Трактирщик встретил посетителя, взял у него роль и записал ее в книгу ролей. Ос разместила в оп программу и преобразовала ее пригодный для выполнения вид. Точнее, актер, играя роль трактирщика, встретил посетителя… Точнее, процессор, выполняя одну из программ ОС, разместил в оп программу… Актер (по велению трактирщика!) Начал играть роль посетителя, вошел, сел за столик, прочел меню и позвал трактирщика. Процессор, по велению ОС переключился на процесс пользователя, который начал вычисления и работал до тех пор, пока ему не понадобились услуги ОС для ввода данных.

Актер перевоплотился в трактирщика, и играя его роль, подошел к посетителю и принял заказ. Произошло прерывание: процессор прервал выполнение программы пользователя и начал выполнять программу ОС. Процесс управления вводом-выводом ОС стал активным. Он принял у процесса пользователя заказ на ввод данных. Трактирщик отнес заказ повару. Процесс управления вводом-выводом скомандовал каналу ввода-вывода выполнить операцию ввода. Точнее, актер, играя роль трактирщика, приказал повару выполнить заказ. Точнее, процессор, выполняя программу управления вводом-выводом ОС, скомандовал каналу выполнить операцию ввода. Трактирщик решил, что дальше нужно играть роль сидящего у окна посетителя с солидным видом. Его блюдо уже готово. Процесс ОС, который называется "диспечер" выбрал для работы самый приоритетный среди готовых к работе процессов. Актер перевоплотился в указанного посетителя и стал есть его блюда. Процессор получил для выполнения от ОС выбранный процесс и начал выполнять его программу. Так прошло минут пять.

Так прошло миллисекунд пять. Повар прокричал с кухни что готово какое-то блюдо. Канал запросил прерывание. Актер бросил есть блюдо за посетителя и побежал на кухню в качестве трактирщика разбираться. Процессор прервался. Управление получила ОС. Ее процесс разобрался в возникшей ситуации. Выяснилось, что готово блюдо посетителя в пенсне и серой шляпе. Трактирщик отнес ему блюдо и перевел посетителя в разряд тех, чью роль можно играть. Выяснилось, что выполнен запрос процесса N16. Процесс управления вводом-выводом передал процессу N16 данные и отметил его, как готовый к выполнению. Затем трактирщик определил, кто из имеющих еду посетителей самый солидный, и актер начал играть его роль… Затем "диспечер" определил, кто из готовых к выполнению процессов самый приоритетный, и передал ему управление процессором…

Евгений Лишак. Записки парасистемного программиста. Журнал «Звание — сила», 1984, № 8, с. 6–7

Content

Евгений Лишак

ЗАПИСКИ ПАРАСИСТЕМНОГО ПРОГРАММИСТА

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

2. Введение

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

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

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

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

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

ТРИДЦАТЬ ВТОРОЙ ДЕНЬ ГОДА