Доклад

«Итоги освоения ОС ЕС (заметки пользователя)»

Дата: 29.08.1983

Автор: Григорий Самуилович Цейтин

Источник: архив академика А. П. Ершова

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

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

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

Из чисто технических особенностей ОС следует отметить применяемый в разных её частях подход к описанию разнообразия предоставляемых возможностей — метод ключевых слов и умолчаний, который, как представляется, позволяет проще описать разнообразные потребности пользователей, чем некоторые кабинетные построения теоретиков «структурного программирования».

2. С другой стороны, необходимо иметь в виду, что заимствованное программное обеспечение, в отличие от «железа» (оборудования), нельзя считать «неодушевлённым»; оно несёт в себе определённые знания, традиции и предпочтения, заложенные в него его авторами и не всегда уместные в наших условиях, а в некоторых случаях прямо выражает коммерческие интересы фирмы-разработчика.

Следует начать с того, что фирма, основной продукцией которой является оборудование, в условиях отсутствия равных по силе конкурентов вообще не заинтересована в том, чтобы её программное обеспечение использовало оборудование экономно. Чем больше ресурсов машины (времени, оперативной и внешней памяти) израсходует программное обеспечение, тем выше будет потребность в оборудовании, тем шире будет рынок его сбыта. (При этом, разумеется, расточительное использование ресурсов не должно быть слишком очевидным и легко устранимым.)

В структуре операционной системы бросается в глаза, так сказать, иерархия уровней обслуживания. Предлагается много вариантов системы с включением или без включения тех или иных дополнительных средств и каждый раз подчёркивается, что дополнительное средство повлечёт за собой дополнительные затраты. В конце концов, где-то на «высоких уровнях сервиса» можно получить действительно полезные и удобные средства, но, поскольку во многих случаях они не предусматривались первоначально, их реализация носит характер «заплат» к прежней системе и далеко не так эффективна, как могла бы быть.

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

Этот подход распространяется не только на построение системы, но и на её эксплуатацию. Функции различных участников процесса эксплуатации сильно разобщены, для каждого из них составлено отдельное руководство (руководство программиста для такого-то языка, руководство системного программиста, руководство оператора), предполагающее, что никто из них не знает того, что должен знать другой. В зарубежных газетных объявлениях упоминается даже такая особая «специальность», как «JCL writer», т. е. составитель заданий для операционной системы на запуск конкретных программ. (Вообще, руководства по эксплуатации весьма пространны, содержат повторы и рассчитаны на низкий уровень подготовки читателя; напрашивается аналогия с сообщавшимся в нашей печати фактом, что в связи с общим снижением культурного уровня некоторые военные уставы в США приходится снабжать иллюстрациями в виде комиксов.) Ясно, что в наших условиях мы не можем, подобно ИБМ, ориентироваться на привлечение большого количества низкоквалифицированных работников, стимулируемых лишь высокой зарплатой. (Следует заметить, что ИБМ экспериментировала и с интенсивными методами организации разработок, такими, как «бригада главного программиста», но к операционной системе это не относится.

Нужно учитывать также различие между нами и США в структуре научно-технического потенциала в области вычислительной техники. Мы отставали и продолжаем отставать в отношении производства собственно оборудования, но в области разработки программного обеспечения, разработки архитектуры ЭВМ, уровня квалификации специалистов по программному обеспечению положение несколько иное. Мы обладаем в этой области давними научными традициями и достаточно квалифицированными кадрами теоретиков и практиков программирования. У нас, как и у программистов западноевропейских стран, есть традиции систематического программирования, ориентированного на ясность структуры программы и на экономное использование ресурсов; в США же программирование испытало сильное влияние установки на «грубую силу» — большой объём памяти и большие затраты машинного времени. Преимущества европейских традиций в программировании проявились, в частности, в том, что на конкурсе на новый язык программирования, объявленном Министерством Обороны США, победила европейская группа (включавшая французов, немцев и англичан) с языком Ада.

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

Более естественным для нас решением было бы сотрудничество с западноевропейскими фирмами — вариант, который в своё время как будто бы рассматривался и который мог бы стать достойным предшественником нынешнего соглашения о газопроводе в Западную Европу.

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

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

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

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

Бичом существующих машин ЕС стала ненадёжная работа дисководов, частые сбои, неполная взаимозаменяемость между однотипными устройствами (запись, сделанная на одном устройстве, ненадёжно читается на другом), иногда выход дисковода из строя на длительное время. Одна из причин этого, видимо, в том, что были заимствованы количественные параметры дисководов ИБМ (размеры, плотность записи, скорость вращения и т. п.) без возможности воспроизвести тот же уровень технологии, снабжения запчастями и т. п. В наших условиях имело бы смысл, не прекращая усилий, направленных на повышения качества изготовления, учесть уровень, достижимый на сегодня при массовом выпуске дисководов и пакетов дисков, и компенсировать ненадёжность оборудования изменением количественных параметров (например, снижением плотности записи), а также такими средствами, как использование кодов, исправляющих ошибки (при небольших дополнительных затратах памяти они во много раз повышают надёжность); всего этого нельзя было почерпнуть в пресловутом «прототипе».

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

3. Остановимся на некоторых технических недостатках системы. Прежде всего, бросается в глаза значительный объём и громоздкость системы. Это не только следствие технологии её разработки, но связано и с исходной постановкой задачи. Чуть ли не по каждому вопросу система предлагает пользователю широкий выбор вариантов для достижения примерно одной и той же цели. Для хранения информации на внешних носителях предлагаются форматы F, FB, U, V, VS и другие комбинации (кстати, метод хранения информации на магнитных дисках с членением на записи разной длины в пределах одной дорожки является производным от методов, разработанных для более старого носителя — магнитной ленты). Для работы с последовательными наборами данных предлагаются методы BSAM, QSAM с разными вариантами пересылки и буферизации, однако же, несмотря на это разнообразие, приходится обеспечивать ещё и метод EXCP с непосредственным построением команд для внешнего устройства. Для запроса оперативной памяти предлагаются варианты с регистровым запросом, с запросом на одну область или на много, с указанием того или иного подпула. Для перехода задачи в ожидание некоторого условия, необходимого для продолжения работы, существуют разнотипные методы WAIT, ENQ, STIMER. Для обработки ошибок и аномальных ситуаций — SPIE и STAE. Даже на уровне операционной системы в целом помимо системы ОС существует несовместимая с ней система ДОС, предназначенная как будто бы для машин с малым объёмом оперативной памяти (на практике это приводит к тому, что в вычислительном центре, эксплуатирующем ОС, ради пропуска одной программы, написанной в ДОС, приходится останавливать всю работу и весьма непроизводительно использовать мощную машину).

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

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

Обеспечение разнообразия вариантов, в том числе и действительно необходимых, основывается обычно на построении «универсальных» управляющих блоков, где заранее представлены все возможности (и оставлен небольшой резерв на будущее развитие). Однако таким образом будущие потребности предвидеть не удаётся. Для управляющих блоков создаются дополнительные вынесенные части, а введение новых функций сопровождается организацией дополнительных проверок и выходов в старых модулях. Следовало бы с самого начала предусмотреть более гибкую структуру управляющих блоков, а варианты функционирования в случаях, где вероятно расширение, изображать не битами, а адресами вынесенных подпрограмм. Сейчас же блок DCB, предусматривающий всевозможные типы периферийных устройств, нельзя стандартным образом перестроить на использование вместо периферийного устройства моделирующей его пользовательской программы (впрочем, какие-то возможности появляются вместе с ОТМД (TCAM)).

Сам языковой аппарат, основанный на использовании ключевых и позиционных параметров (и подпараметров) с умолчаниями, без которого пользователь вообще не смог бы воспользоваться системой, не имеет в системе систематической реализации. Естественно было бы ожидать, что система обеспечит единый механизм хотя бы для синтаксического разбора текстов с такой структурой, но его нет, и каждый блок системы производит разбор текста кустарным образом, что сильно удлиняет программы. Например, при анализе операторской команды типа M 130,VOL=(SL,DLIB01) производится проверка на группу символов 'VOL=(SL,' . Кроме того, в результате нет полного единства в синтаксисе и в написании ключевых слов между разными компонентами системы (программа системного вывода требует указывать умолчания ключевых параметров в операторе PROC без знака & и не обязательно для всех ключевых параметров, а ассемблер в макроопределениях — наоборот; сокращение DSN вместо DSNAME допускается на языке управления заданиями, но не для системных утилит). Свободный формат, основанный на ключевых словах, беспорядочным образом чередуется с жёстким форматом 80‑байтовых «карт», разделённых на поля, (ещё один пережиток использования устарелых носителей данных) и особыми (неодинаковыми в разных случаях) правилами «переноса» на следующую карту. В результате при обращении к процедуре языка управления заданиями ключевые параметры можно заменять в произвольном порядке, а DD-предложения — только в порядке их следования в процедуре; в предложении EXEC параметры, относящиеся к разным пунктам процедуры, можно заменять только в порядке следования этих пунктов, хотя запись этих замен использует свободный формат. Выдача операторской команды START с очень длинным полем PARM приводит к ошибке языка управления заданиями из-за того, что главный планировщик первоначально преобразует эту команду в задание в 80‑байтовом формате (откуда это знать оператору?). Эти и подобные курьёзы хорошо знакомы тем, кто повседневно работает с ОС ЕС.

Реализация многих часто встречающихся функций операционной системы довольно неэкономна. Это относится даже к таким часто встречающимся функциям, как WAIT и GETMAIN, для которых основная часть команд SVC-программ посвящена контролю допустимости параметров (аппаратный контроль при переходе в режим супервизора частично отключается), подготовке учётной информации и рассмотрению специфических случаев. Не случайно даже реализация языка ПЛ‑1, выполненная тем же разработчиком, избегает пользоваться командой GETMAIN для каждого запроса на память и создаёт собственную систему. А в SVC-программах, равно как и в стандартных рекомендациях по организации входа в реентерабельный модуль, GETMAIN широко используется даже для получения маленьких блоков памяти.

Ряд ограничительных установок, принятых в начале разработки прототипа ОС ЕС, и, возможно, уместных в тот период (более 20 лет назад), оказались совершенно неприемлемыми в период широкого освоения этой системы у нас в стране. Это прежде всего отсутствие динамического распределения ресурсов (наборов данных, периферийных устройств) и отсутствие диалогового режима обращения к наборам данных и запуска заданий. («Официальные» решения части этих проблем пришли лишь в последний момент и, как всегда, в виде громоздких надстроек над старой системой.) Эти ограничения системы привели к своеобразному взрыву инициативы пользователей, которые в разных местах, независимо друг от друга и в условиях жестокого недостатка информации о внутренних механизмах ОС разработали и внедрили ряд диалоговых систем, полностью или частично решающих эти проблемы (в МИФИ — PRIMUS, в Ленинградском университете — JEC, в ДВНЦ АН — DED, и т. п.). Эти системы широко распространились за пределами первоначально разработавших их коллективов и оказались во многих случаях лучше приспособленными к потребностям пользователей, чем появившиеся поздней системы, адаптированные с прототипа. (Достаточно заметить, например, что одной из первых решавшихся при этом задач было сохранение информации в случае сбоя операционной системы.) Эту инициативу пользователей можно было бы только приветствовать, пожалев лишь, что с самого начала не было координации этих работ (хотя соревнование разработок имеет свои преимущества). Однако надо учесть, что препятствия, на преодоление которых было затрачено столько усилий, были всего лишь результатом устарелых исходных установок при разработке ОС ЕС, вернее, OS/360; пользователи других операционных систем не могут сдержать улыбки, слыша о наших «великих проблемах».

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

Ещё одна «проблема», вызвавшая взрыв самодеятельности, это отсутствие в ОС ЕС средств подготовки текстовых документов (хотя ИБМ для подготовки своих руководств таким средством пользовалась). В условиях дефицита машинисток эта проблема сразу дала себя знать и вызвала к жизни огромное число параллельных разработок разного качества. Аналогичное положение имеет место для средств запуска системных утилит с консоли оператора.

Представляются недостаточными средства защиты программ и данных, предусмотренные оборудованием и операционной системой ЕС. Большая часть средств защиты основана на неосведомлённости пользователя, которому не сообщается, например, структура загрузочного модуля и от которого рекомендуется прятать программу IMASPZAP, корректирующую загрузочные модули. Если же речь идёт о хорошо подготовленном злоумышленнике, то здесь аппаратура обеспечивает лишь один уровень защиты — ключ памяти. Тот, кто сможет получить для своей программы нулевой ключ памяти, сможет любым образом нарушить функционирование системы, например, вывести её из строя, заодно уничтожив сборный протокол, или, не создавая видимых нарушений, перенести в выдачу своей программы таблицу паролей в преобразованном для неузнаваемости виде, или же, наконец, внести желательные для себя изменения в операционную систему на будущее. Получение же нулевого ключа памяти также не является трудной задачей. В системе с MFT сведения о ключе программы, вызвавшей другую программу, хранятся в блоке PRB в незащищённой области памяти и их там легко изменить. В системе с MVT такой возможности до последнего времени как будто бы не было (хотя достаточно было произвести незначительное изменение, скажем, в библиотеке процедур — и оператор, не зная того, вместо программы системного ввода запустил бы в привилегированном режиме совсем другую программу). В последних же изданиях системы присутствует команда MODESET, которая позволяет законным образом произвести любое изменение режима (и это, возможно, оправдано для некоторых системных программ). В описании блока JSCB содержится «успокаивающая» информация о том, что один из битов определяет право задания на выдачу команды MODESET. Но это не соответствует действительности: команда MODESET никаких проверок не делает и работает независимо от этого бита. Здесь не просто отсутствие контроля, а лживая информация о его присутствии. Заметим попутно, что другие компроненты системы, например, команда OPEN, затрачивают значительное время на проверку законности запроса.

Впрочем, на защищённость наборов данных, в том числе, библиотек самой операционной системы, нельзя полагаться и потому, что информация о защите содержится в оглавлении тома, которое можно изменить программно (как набор данных с именем 44X'04'); при существующей степени запутанности системы трудно рассчитывать на удовлетворительную организацию защиты.

Разумеется, никакие аппаратурные и программные средства сами по себе не могут обеспечить защиты от злоумышленника. Однако защита от посягательств, осуществляемых в течение долей секунды, невозможна без аппаратурных и программных средств.

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

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

4. Немалые издержки связаны с тем, что ОС ЕС задумана как точная копия зарубежного образца.

Изучение и «адаптация» зарубежной разработки, к тому же «по безлицензионному методу» отвлекли от оригинальных разработок значительные программистские силы. В этих условиях появилась постоянная необходимость следить за всеми нововведениями в зарубежном прототипе, ничего не упуская. Если в некотором заимствованном варианте системы есть недостатки и ошибки, то самым верным средством исправления стало казаться заимствование следующего зарубежного варианта, где обещано исправление этих ошибок, и так без конца. Совершенствовать систему самостоятельно стало опасным: вдруг самостоятельно внесённые изменения окажутся несовместимыми со следующим вариантом «оттуда».

Объём разрабатываемого за рубежом программного обеспечения растёт, и с ним растёт необходимый объём работ по адаптации. Помимо системного программного обеспечения необходимо приобретать и адаптировать прикладное программное обеспечение (без него не имело бы смысла заимствовать операционную систему); кстати, каждый прикладной пакет имеет меньшее распространение, чем системное обеспечение, и приобрести его «безлицензионным» методом труднее. В целом при таком положении темпы адаптации могут отстать от темпов зарубежных разработок. Уже сейчас некоторые системные программисты, которым удаётся получить оригинальный вариант зарубежной системы, начинают использовать его, не дожидаясь адаптации его нашими разработчиками. В любом случае при условии адаптации наш пользователь получает вариант примерно десятилетней давности.

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

Сама адаптация, как предполагается, состоит в подробном разборе полученных программ, в доскональном понимании принципов их функционирования, а также во включении в программы наших обозначений операционной системы и аппаратуры и составлении руководств на русском языке (обычно путём перевода с английского). К сожалению, степень понимания полученных программ невозможно точно оценить и проверить. На вопрос о назначении той или иной детали не всегда возможно разумно ответить. При этих условиях (учитывая также дефицит времени и сил на адаптацию) возможны и необнаруженные ловушки, специально устроенные противником. (Недавняя операция ФБР США против японских фирм Хитати и Мицубиси, стремившихся получить материалы о последних разработках ИБМ, делает такое предположение правдоподобным.) Не принадлежит ли к числу таких ловушек упомянутая выше команда MODESET? (Если говорить конкретно об этой команде, то её появление объясняется, скорее всего, не диверсией, а неаккуратным сочетанием модулей, заимствованных из разных версий прототипа.)

Вот ещё один пример, более старый. В аварийных дампах ОС ЕС в режиме MFT обращало на себя внимание неоднократно встречавшееся странное слово RENZTIEW. Как выяснилось при более внимательном изучении, оно всегда стояло в конце блока SVRB, связанного с SVC-командой аварийного завершения, и засылалось туда специально одним из модулей этой SVC-программы. Чем мотивировано это слово? (Кстати, иногда такие слова служат ориентиром для других модулей ОС ЕС.) Был проделан эксперимент — в соответствующем модуле SVC-программы это слово было заменено на совсем другое — на фамилию одного сотрудника. Система продолжала работать как ни в чём не бывало, выдавая теперь на всех дампах эту фамилию. Итак, на эту роль может быть выбрано любое слово, и оно будет появляться на всех аварийных дампах, поэтому оно может быть использовано для идентификации экземпляра операционной системы, незаметной для не очень внимательного пользователя. Первые четыре буквы слова RENZTIEW входят также в название фирмы LORENZ, сыгравшей роль в получении нашими разработчиками сведений об OS/360. Не было ли это слово меткой экземпляра OS/360, переданного из ИБМ этой фирме?

Другим отрицательным эффектом распространения заимствованной системы стал своего рода культ заимствования. Для многих разработчиков и пользователей стало привычным считать, что всякая наша разработка является копией какой-то зарубежной, вопрос лишь в том, какой именно. Дело доходит до курьёзов. Упомянутые выше оригинальные диалоговые системы доступа к машине принимают за заимствованные («где уж нашим!»); встретив необычный термин, спрашивают, как это было по-английски; знакомясь с проспектом новой разработки, стараются вежливо выяснить, какой тут зарубежный «аналог» (чтобы не спросить прямо, с чего «слизано»), и даже поверив в отсутствие «аналога», удивляются и дружески советуют не ломать голову, а использовать уже испытанные образцы. Авторы оригинального программного обеспечения теперь испытывают затруднения, когда в документах или статьях необходимо указать, что данная разработка не является копией зарубежной, так как работы по адаптации обычно обозначаются в документах как новые разработки. Стало престижным щеголять английскими терминами в русской транскрипции, даже если за ними не стоит нового содержания. Был случай, когда литовский программист, адаптировавший для себя одну отечественную разработку и, в частности, переведший её выходные сообщения с русского языка на литовский, счёл необходимым «для солидности» придумать ей название на английском языке.

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

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

Между тем этот подход стал непреодолимым препятствием для официальной приёмки и распространения многих отечественных программных средств, особенно тех, которые созданы инициативно, под влиянием текущих потребностей эксплуатации ЭВМ высококвалифицированными программистами, работающими в непрофильных организациях. Редкий вычислительный центр не имеет хотя бы чего-нибудь из подобных программных средств, системные программисты списывают их друг у друга, как песни любимых ансамблей. И в то же время с официальной точки зрения это всего лишь нестоящие мелкие «поделки», не имеющие даже статуса рацпредложений, а их авторы (зачастую анонимные) низведены до уровня «умельцев-кустарей». Пренебрежительное отношение к «умельцам» связано, возможно, с тем, что их путают с известной из нравоучительных переводных книг по программированию одиозной фигурой «суперпрограммиста» — неуправляемого маньяка, быстро пишущего программы и скрывающего от окружающих их секреты (скорее всего, это даже и не маньяк, а просто рвач). Реальные разработчики инициативного программного продукта у нас обычно ориентируются на потребности пользователя и хорошо понимают, что и в каком объёме надо объяснять и документировать (средства технологической поддержки и документирования разработок тоже часто создаются инициативно). Эти разработчики создают документацию, достаточную для толкового пользователя (обычно на машинном носителе, чего ГосФАП до сих пор не допускает, несмотря на существование соответствующего ГОСТа), но, конечно, они не станут составлять инструкцию о режиме транспортировки и хранения магнитной ленты с программами или, скажем, давать подробное объяснение логики программы, рассчитанное на малоквалифицированного программиста из посторонней организации, которому, быть может, захочется изменить программу (квалифицированный программист воспользуется для этого текстом программы).

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

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

Сказанное не означает, что разработка программного обеспечения очень большими коллективами с расчленением продукта на малые части и подробными описаниями для неподготовленных пользователей не нужна ни в каком случае. Речь идёт о том, что односторонняя ориентация на этот, заимствованный у ИБМ, стиль разработки лишает нас значительной части наших резервов производства программного обеспечения.

6. Критикуя принятое когда-то решение о следовании разработкам фирмы ИБМ, многие задаются вопросом: как это могло случиться? Что это было: непростительная безответственность и близорукость? торжество чьих-то узкоэгоистических интересов? или, по выражению голландского учёного Э. В. Дейкстры, победа США в холодной войне с СССР?

Вероятно, ответ на этот вопрос не столь прост и прямолинеен. Наверняка среди тех, кто начинал эти работы, были люди, понимавшие негативные последствия подражания и принимавшие такое решение с тяжёлым сердцем, как вынужденный шаг и единственное, по их представлению, средство радикально улучшить положение с вычислительной техникой в нашей стране. Возможно, сказались слишком оптимистические оценки сроков освоения заимствованной системы: существовали надежды, что к середине семидесятых годов мы выйдем из полосы подражания и сможем развиваться самостоятельно. Оглядываясь назад, непросто выяснить, где и когда был сделан тот ложный шаг, который привёл нас на столь неудачный путь.

Прежде всего, нельзя отрицать достигнутого прогресса в производстве оборудования. К тому же, развитие производства — это не адаптация программного обеспечения: завод, и даже технологию, не спишешь с магнитной ленты, это надо создавать самим. В использовании архитектуры Системы/360 ИБМ самом по себе тоже нет ничего плохого (хотя, вероятно, и с нашим опытом конца шестидесятых годов, мы могли бы выбрать лучший образец для подражания). Далее, если воспроизводится архитектура машины, естественно испытать на ней и заимствованную операционную систему. Это даже необходимо, чтобы проверить функционирование аппаратуры в реальных условиях и ознакомиться с проблемами эксплуатации новых машин. Что же, нужно было и дальше следовать этим путём?

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

Во всяком случае, урок освоения ОС ЕС ясен: можно, и иногда нужно осваивать отдельные образцы зарубежного программного обеспечения, но нельзя становиться на путь постоянного следования за ними.

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

Но необходимо не только поддерживать разработку и производство других типов машин и операционных систем, но и делать усилия для выхода из порочного круга подражания «прототипу». Надо учесть, что и некоторые зарубежные фирмы, производящие аналоги ИБМ-овского оборудования, вносят в него изменения, так что получаются системы, лишь частично совместимые с продукцией ИБМ. Надо прилагать усилия к самостоятельным разработкам, в том числе и на базе существующей операционной системы, не заботясь о совместимости с будущими разработками ИБМ. Можно продолжать использовать существующую производственную базу для выпуска машин ЕС, разрабатывая для тех же машин новые операционные системы и даже (для машин Ряда-2 с микропрограммированием) новые системы команд. Трудно обойтись без соревнования различных направлений в этой области, лишь опыт может показать, что лучше.

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