Текст книги "«ВОСХОД» программиста"

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

Вариант получения «привилегированного состояния» сразу подсказал Ратников: нужно было использовать уязвимость, как сейчас говорят, операционной системы. При динамической модульной структуре программы в вызываемой подпрограмме можно было использовать привилегированные команды, такие как SSM – установить маску прерываний системы и LPSW – загрузить слово состояния программы. Это была явная дырка операционной системы.

Разобрался я с этим быстро – уже на второй выход на машинное время этот механизм заработал. Эффект был потрясающий, все устройства переставали работать, только процессор мигал лампочками на пульте. Для управления этим состоянием – опять же, по совету Юрия – оставил открытым прерывание от консоли. Иначе мы имели бы все то же монопольное использование этих многочисленных шкафов одной программой.

Ради справедливости следует сказать, что несколько ошибок я все же допустил: пришлось перезагружаться, что вызвало сдержанное неудовольствие коллег. Но после этого Юрий продемонстрировал, какие штуки можно творить с помощью пульта процессора. С помощью тумблеров и клавиш можно было выбрать одно из нескольких сохраненных PSW, загрузить его в качестве текущего и продолжить работу ЭВМ. Он при этом ориентировался по маске прерываний (прерывания не должны были быть замаскированы) и по адресам (адрЕС-должен быть внутри раздела). Это было так интересно и эффектно, что воспринималось и запоминалось сразу. Через какое-то время я уже сам «разруливал» свои ошибки с пульта процессора, чтобы не мешать коллегам. Осталось только заставить процессор исполнять мелодии, что оказалось делом совсем не сложным.

И вот наступил день, когда программа заработала.

Она измеряла быстродействие, строила в оперативной памяти последовательности команд, повторяла их в соответствии со временем звучания ноты мелодии и исправно откликалась на кнопку прерывания консоли для возврата из привилегированного режима. Из нашей комнаты (мы называли ее чуланом, потому что была в подвале) притащили огромный и тяжелый высокочастотный промышленный радиоприемник производства ГДР (такие применялись для проведения специальных исследований на излучение). В качестве первой мелодии я использовал мелодию песни «Жили у бабуси два веселых гуся».

И вот момент истины! Программа запущена, приемник включен. После раздавшего в первую минуту шипения начали настраивать частоту… И вдруг явственно зазвучала эта мелодия! Радости моей и гордости не было пределов. В тот момент, пожалуй, я был по-настоящему счастлив.

Дальше с понятным энтузиазмом я принялся развивать программу: был сделан вывод на АЦПУ результатов измерений быстродействия, внесен некий набор мелодий, которые можно было выбирать в диалоге с консоли. За мелодиями направился в музыкальный магазин, нашел книжку нот популярных мелодий.

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

Я начал искать возможность запустить программу на других ЭВМ: жажда исследователя тянула меня посмотреть на реальное быстродействие различных машин, ведь программа самонастраивалась для исполнения мелодий за счет проведения измерений. На стенде у нас тогда было несколько машин ЕС-1030 и две ЕС-1020. Так или иначе, я умудрился запустить программу на всех или почти всех.

Оказалось, что быстродействие довольно сильно различалось на разных экземплярах даже одной модели. Еще более поразительным оказалось то, что очень существенно (в разы!) различалось время выполнения команд разных форматов. Команды «регистр – регистр», т. е. оба операнда в регистрах, исполнялись со скоростью, очень близкой к паспортной. Команды формата «память – память», т. е. оба операнда в памяти, исполнялись со скоростью, в разы ниже паспортной. Поскольку у меня в программе уже был отчет об измерениях, я с удивлением обнаружил, что внутри этих команд формата «память-память» самыми медленными оказались команды сравнения: здесь скорость была уже на порядок ниже паспортной.

Интересно, как на заводе определяли быстродействие своих агрегатов? Ведь правильность моих данных подтверждалась тем, что мелодия играла без искажений. Значит, в паспортных данных о быстродействии – вранье? Вот до какой степени я возгордился… В общем, жизнь была мне в кайф.

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

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

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

Много часов было уделено супервизору, вызов которого производился по той самой команде svc. Были подробно рассмотрены многочисленные супервизоры IBM – супервизор задач, супервизор содержимого, супервизор памяти, супервизор ввода-вывода. В принципе, многое из того, что преподавали, я уже знал, но курс был несомненно полезен: там я в деталях ознакомился с JCL – Job Control Language. Кроме того, я узнал то, что еще недавно было для меня совершеннейшей тайной. По вечерам мы играли на биллиарде и даже выпивали «со знакомством» от радости бытия.

По окончании учебы я успешно сдал экзамен по курсу и благополучно вернулся в свой НИИ.

Годы работы

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

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

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

Собственно, почему я этим занялся? Оказалось, что мы с Юрием Ратниковым жили недалеко друг от друга, и по дороге домой, а это составляло приличное время на метро, мы беседовали. Одной из тем было обсуждение возможности создать программу, обратную моей «музыкальной». Конечно, было бы очень интересно и эффектно написать программу, которая по электромагнитному излучению процессора восстанавливала бы программу, выполняемую в нем. Но проблема состояла в устройстве, которое бы преобразовывало излучение в цифровые данные, – такого устройства в то время еще не было (или же мы об этом ничего не знали.)

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

Нужно сказать, что операционная система, – точнее, ее авторы, – вызывали у нас огромное уважение, – нам такие проекты тогда, к сожалению, не грозили. Вы спросите: а как же система, разрабатываемая институтом? В том то и дело, что на тот момент я уже хорошо понимал, что сердцем системы являлась операционная система! В ней разворачивалась система CICS (Customer Information Control System), тоже производства IBM, позволявшая инициировать выполнение специально написанных под ней программ с очень широкого множества терминальных устройств.

Таким образом, в то время, в конце 70-х, основные программистские задачи в институте были прикладными, причем многие писались на языках высокого уровня, типа COBOL или PL. Вкусив программирование на Ассемблере и знакомство с операционной системой, я не испытывал никакого интереса к программированию на языках высокого уровня. Более того, в чем-то мы даже испытывали чувство превосходства по сравнению с этими «обычными» программистами.

Здесь надо оговориться. Последующие размышления о языках программирования привели меня к некоторым интересным выводам.

* * *

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

О природе программирования написано немало книг. Что это, обычная профессия инженера или наука? А может, искусство? (Одна из книг так и называлась: «Искусство программирования. Д. Э. Кнута».) Или это ремесло? Собственные размышления на эту тему привели к выводу, что если это и не искусство, то, по меньшей мере, ремесло. Программист подобно ремесленнику пестует свое детище, взращивает свою программу и ревниво следит за отношением к ней своих коллег.

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

Какие признаки обычного мира присущи также миру программирования? Например, тенденции, или мода. Да, в разное время какие-то языки программирования были модными, какие-то устаревали, т. е. «выходили из моды». Элементы моды присутствовали всегда, даже несмотря на то, что языки программирования создавались для различных сфер применения. Зачастую даже большие серьезные программы писались на языках, явно не очень подходящих в данном конкретном случае. Сам в этом грешен.

Другая особенность – это соревновательный момент, или соревнование самолюбий. Какой язык круче? Какие программисты лучше? В то время, например, самым сложным программированием считалось программирование на Ассемблере, потому и самыми крутыми программистами, можно сказать, «элитой», были те (и я в их числе), кто писал на этом языке. Но так ли это в действительности?

Да, Ассемблер стоит особняком, ведь на нем написаны операционные системы IBM 360, IBM 370, CICS.

Является ли он сложным? С моей точки зрения, он прост, ведь каждая его команда соответствует машинной команде.

Напомню, что преобразование исходного кода в объектный производится транслятором, а не компилятором, как в случае других языков.

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

Функции в языках программирования высокого уровня – это инструмент, позволяющий одной строкой произвести сложное вычисление или иное действие.

Макрокоманды в Ассемблере – это всегда обращение к ресурсам операционной системы. Они использовались для ввода-вывода, многозадачности, реализации динамических структур программ и т. д.

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

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

При этом сам Ассемблер прост, как апельсин!

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

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

Для меня в языках высокого уровня неким барьером для понимания была их абстрактность. Вы пишете некие конструкции, но что компилятор вставит вместо них в объектный код и что будет делать процессор в этом месте программы – совершенно неизвестно. Вспоминая времена обучения в МАИ и читаемый нам курс по ВУДД, вычислительным устройствам дискретного действия, признаюсь, что тогда я не разобрался с Алголом. Возможно, это моя специфическая особенность – невосприимчивость к абстракциям языков высокого уровня.

Так сложно ли программировать на Ассемблере и какой язык круче? Полагаю, что однозначного ответа здесь нет. Для кого-то это очень сложно и непонятно по сравнению с языком высокого уровня, а для кого-то, наоборот, трудно с языком высокого уровня. Можно утверждать лишь то, что в описываемый период программистов на Ассемблере было меньше, чем на языках высокого уровня. И объяснялось это просто: в нашей стране немногочисленные программисты тогда были сосредоточены в академических вычислительных центрах, а писать сложные математические вычисления явно проще не на Ассемблере.

Те, которых меньше, – всегда ценнее, вот отсюда и чувство превосходства.

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

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

* * *

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

Как-то позвонил Ратников и сообщил, что нам нужно поехать на территорию заказчика, посмотреть CICS. Это было начало нового проекта. Как уже говорил, CICS была основой систем, которые производил наш институт, если так можно выразиться. (Аббревиатура означала Customer Information Control System – система управления информацией пользователя.) Это была грандиозная система! Впрочем, почему «была»? Судя по продуктам IBM, которые предлагаются для CICS в настоящее время, она используется до сих пор.

По сравнению с IBM 360 или IBM 370, это была операционная система более высокого уровня для пользователя. Основу ее составлял ряд управляющих программ: TCP, SCP, KCP и т. д. Две буквы, CP, означали Control Program – Управляющая Программа, а первая задавала область: T – terminal (терминалы), S – storage (память), K – task (задачи). Запускалась она как обычная пользовательская программа в разделе операционной системы и никак не использовала недокументированных возможностей OS IBM 360. Для нее можно было писать программы, которые запускались как транзакции CICS – специфический термин, означавший программу, написанную для работы под управлением CICS.

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

Напомню, что для работы с внешними устройствами в OS 360 нужно было писать программу с использованием соответствующего метода доступа. В то время это считалось самым сложным программированием в операционной системе. Самое интересное, что CICS поставлялась в исходных кодах. Не могу точно сказать, как поставлялась OS 360: для использования ее нужно было сгенерировать, а мы этим никогда не занимались (для этого в институте существовало системное подразделение), но считали, что часть операционной системы была в исходных кодах, а часть в объектных. Естественно, что в СССР не поставлялась ни OS IBM 360, ни тем более CICS. Все, что мы использовали, было фактически украдено или у США, или у других стран, но это был нормальный технический шпионаж. Во всяком случае, мы так считали. В ходу было даже выражение «Спасибо тем ребятам». Под «ребятами» мы подразумевали советских разведчиков, которые каким-то образом выбрали, что добывать, и добыли эти системы.

Итак, Ратников пригласил меня заняться этой самой CICS.

– Саша, завтра нужно приехать на Вернадского, посмотрим CICS.

– Да, Юра, конечно. Что будем смотреть?

– Приезжай, там поговорим.

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

Не знаю, обсуждал ли Ратников свои идеи по CICS с руководителем нашего подразделения. Думаю, что нет. Сегодня это может показаться несколько странным, но тогда это было нормой – руководители ничего не понимали в нашей работе.

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

Выяснилось, что Юра договорился со знакомым программистом, чтобы нам выдали папку с листингами всех управляющих программ CICS. При этом была еще и документация на английском языке по CICS. Уселись в одном из помещений, предоставленных заказчиком для НИИ «Восход», так называемом «греческом зале».

Представьте, читатель, зал, в котором установлено несчитанное количество столов и стульев, – некоторые пустые, за некоторыми сидят сотрудники. Незабываемая атмосфера того времени. Никак не могу понять тех, кто придумал разместить сотрудников для работы в залах на десятки или даже сотни человек! Как там можно было работать? Атмосфера пивного зала, только без пива и захмелевших.

Однако мы просмотрели листинги, документацию, нашли точки выходов в управляющих программах. По сути, задачка была простенькой – выбрать, какие из выходов использовать. Но «простенькой» эта работа может показаться сегодня, а тогда о существовании CICS знали единицы! Помню, как в зале появился один из программистов, чуть ли не тот автор макрокоманд для незабвенного комплекса М-24.

– Что роете, ребята?

– Да нужно кое-что посмотреть в KCP.

Ну, разве это не круто? Для понимания крутизны нужно сказать, что аббревиатура KCP была знакома уже совсем малому количеству людей в стране. KCP – это программа управления задачами в CICS. Мы с Юрой обсуждали, где правильнее использовать «выход» – в KCP или в TCP – программе управления терминалами. Дело в том, что управление задачами инициировало исполнение транзакций в CICS, а управление терминалами обеспечивало весь обмен с внешними устройствами. Сошлись на KCP, хотя, безусловно, Юра был компетентен значительно лучше меня. Вроде бы он даже обмолвился, что ранее уже обсуждал этот вариант с другим сотрудником подразделения программных средств защиты Вадимом Смирновым. Ко времени описываемых событий тот уже перешел в соседнее подразделение.

Рассуждали примерно следующим образом: в TCP «выход» получает управление всякий раз, когда происходит какой-то обмен с терминалом, а в KCP «выход» получает управление всякий раз, когда инициируется создание новой транзакции. Второй вариант, оптимальный, так как не нужно анализировать, что происходит, – инициирование транзакции или диалог в ней. Здесь нужно пояснить, что для инициирования транзакции в CICS нужно было ввести с терминала, который мог быть самым разным, имя этой транзакции.

Выбрали решение – и вперед.

(Внимание! Никакого согласования с заказчиком, а уж тем более с руководителями, – все равно никто из руководства в этом ничего не понимал.).

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

Тем не менее энтузиазм и интерес к работе был сильней этих мрачных мыслей.

Выход в KCP был готов очень быстро. Для проверки я написал «заглушку», которая выводила сообщение. Примерно в это время у нас на стенде появились первые дисплеи ЕС-7920, которые почему-то привлекли наше внимание, и Юра посоветовал с ними разобраться. Для этого у нас имелось несколько дисплеев и американская документация на дисплейный комплекс 3270, полным аналогом которого был ЕС-7920.

Почему было интересно? Во-первых, экран имел более высокое разрешение по сравнению с ЕС-7906 и значительно более современную клавиатуру. Клавиатура уже была похожа на современные клавиатуры для персональных компьютеров. И это в 1979 году! Но особенно меня увлекло присутствие у дисплея «светового пера» – некоего металлического указателя, соединенного с дисплеем шнуром. Этим пером можно было отмечать специальные «поля» на экране и даже выполнять функцию клавиши «Ввод» на клавиатуре путем более сильного нажатия на перо. Фантастика! Все эти возможности реализовывались в программе с помощью форматирования содержимого буфера дисплея. Хорошо помню, что можно было фактически сформировать с помощью управляющих символов что-то вроде современных экранных форм, т. е. поля для ввода данных, названия полей, которые нельзя было редактировать с клавиатуры, и поля, доступные для светового пера. Эти поля можно было использовать для формирования на экране дисплея меню, пункт которых можно было выбирать «пером» или с клавиатуры.

После программирования работы с консолью ЭВМ это было очень интересно и захватывало – очень хотелось попробовать все возможности этих дисплеев.

Не только попробовал, но и нагородил кучу технологий, типа регистрации пользователя, идентификации пользователя, проверки его полномочий в части доступности ему задач CICS, выдачи разовых разрешений на выполнение задач, не входивших в полномочия. Во всем этом я использовал тогда очень богатые возможности форматирования экрана ЕС-7920.

Примерно в то же время в нашем НИИ появилась первая настоящая СУБД. Это была DBMS ADABAS разработки Software AG, не известно какими путями попавшая в нашу страну. Естественным образом было принято решение хранить полномочия пользователя (в виде перечня транзакций) в базе данных. Надо сказать, что знакомство с БД оказало на меня сильное влияние. Я понимал, что базы данных – это надолго и всерьез.

Хочется отметить стремительность развития событий: за год-полтора я прошел от программирования «музыкальной программы» до приличного знания CICS, разработки технологий защиты информации и освоения СУБД. Вместе с Ратниковым (он снова меня привлек) мы занялись уже выходами в операционной системе для реализации технологий защиты.

Начали с визита в НИЦЭВТ (Научно-исследовательский центр электронной вычислительной техники), который в то время был безусловным авторитетом по операционным системам ЕС-ЭВМ, то есть OS 360, а впоследствии – и OS 370.

Несмотря на то что НИЦЭВТ к тому времени (конец 1979 – начало 1980 гг.) уже освоил MVT, наш институт продолжал использовать MFT. Казалось бы, MVT более прогрессивная система с переменным числом «разделов» памяти в отличие от MFT, где при загрузке нужно было задать «разделы» с указанием их величины. Но для таких систем, разработкой которых занимался НИИ «Восход», использование MFT мы считали оправданным, так как пользовательские задачи исполнялись в CICS, для которого создавался большой «раздел» с наивысшим приоритетом. Собственно, многозадачность операционной системы использовалась только нами, программистами, а в эксплуатируемой системе работа программистов на «боевых» ЭВМ, естественно, не предполагалась.

Итак, мы пришли в НИЦЭВТ для прояснения технических вопросов использования выходов и консультаций по ним. По дороге Юра счел необходимым предупредить меня о некоторых «особенностях» сотрудников НИЦЭВТ: они считали себя «особами, приближенными к императору» во всем, что касалось систем IBM 360 и 370. Но оказалось, что НИИ «Восход» был также достаточно известен в определенных кругах, причем помимо некоторого авторитета имел и иную репутацию. В частности, в этом самом НИЦЭВТ наш НИИ называли почему-то «краем непуганых дураков». «Как же так? – думал я. – Мы делаем такие крутые системы!» (К этому моменту институт получил даже заказ на систему для ЦК КПСС.)

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

Конечно, у меня, как и у многих сотрудников института, присутствовал патриотизм относительно нашего НИИ «Восход». Это была забавная смесь чувства превосходства и успешности. Ведь наши сотрудники постоянно бывали в Совете Министров СССР! (На этом фоне поездки в Совет Министров РСФСР и союзных республик и в министерства уже для многих были обыденными). Помимо весьма ощутимой ежемесячной надбавки к окладам в размере 25 % за секретность, нам даже командировочные оплачивали по-министерски – вместо стандартных по стране 2 руб. 60 коп. – 3 руб. 50 коп. суточных. А какие бывали квартальные премии… До 100 % и более от оклада!

На этом фоне весьма отчетливо проступал особый корпоративный дух причастности к чему-то высокому. Чего стоит, например, наше внутреннее название территории заказчика – «Рамбуйе» (правительственный замок во Франции, летняя резиденция президентов Франции – ред.) Произошло это название территории заказчика от действительного названия «Ромб». Но разве фраза «поехал на «Ромб» звучит? И совсем иное дело, когда на вопрос «Ты куда?» давался этакий небрежный ответ – «Я на Рамбуйе».

Чувствуете разницу, читатель? И ведь не скажешь, что это название придумано без особого русского изящества. Ведь действительно объект особый и название придумано тонко. Мне, правда, не довелось побывать в Совете Министров, но уже у следующего заказчика наших систем – ЦК КПСС – я бывал довольно часто.

Помню, перед первым посещением ЦК у нас в НИИ проводился особый инструктаж, как себя вести. Мы безукоснительно должны были соблюдать, например, следующие требования: при встрече сотрудника ЦК КПСС у лифта – вежливо уступить ему дорогу и ни в коем случае вслед за ним в лифт не входить; женщинам запрещалось появляться у заказчика в брюках – только в юбках или платьях; и т. д. и т. п. Не скрою, меня такой инструктаж коробил. Но с другой стороны, а существовал ли в нашей стране еще какой-нибудь НИИ, сотрудники которого регулярно посещали бы ЦК КПСС? Я все еще утешал себя тем, что мы разрабатывали действительно уникальные системы. Но сомнения все же оставались.