Фуглевич Петр
В середине 1984 г. в Научно-производственном Центре систем управления (CNPSS) MERASTER в Катовице (1977–1990), одном из крупнейших производителей компьютерных систем в Польше, было решено создать оборудование и программное обеспечение, позволяющее реализовать многопользовательские системы на микрокомпьютере – аналоге LSI 11/03 компании DEC, изготовленном на основе процессора, произведенного в Советском Союзе. На реализацию проекта отводилось 15 месяцев. В статье описываются руководящие принципы проектирования, производства, организация и ход работ по созданию системы. Чтобы оценить амбициозность задачи, скажем, что процессор микрокомпьютера имел оперативную память 56 килобайт, а требования к памяти современных операционных систем (Windows, Linux) на порядок выше. Задача была решена в течение 15 месяцев командой в несколько человек. В настоящее время реализация подобной системыпотребовала бы больших ресурсов. Итогом проекта стали финансовые и нефинансовые последствия. CNPSS MERASTER продавалась, в основном, в СССР, где спрос составил примерно сто систем в течение трех лет, что было выгодно для производителя. Нефинансовым результатом были опыт и навыки сотрудников, приобретенные за время работы над системой. Он был высоко оценен на Всепольской ярмарке программирования SOFTARG’86, где работа получила Первую премию. Руководитель отдела научно-технического развития и внедрения в ранге министра ПНР присудил проекту Перваю специальнаю премию для авторов программного обеспечения. По результатам проекта было получено несколько патентных заявок на компоненту системы «Полупроводниковая внешняя память» (PPZ-60).
До присоединения к проекту Единой системы электронных вычислительных машин (ЕС ЭВМ) Польша разработала ряд компьютерных моделей семейства ODRA, совместимых по программному обеспечению, но не всегда по аппаратному. Это были различные модификации IBM/360 и ICL-1900.
В проекте ЕС ЭВМ Польша производила машины ЕС-1032 (R-32), ЕС-1034 (R-34), а также периферийные устройства. Программное и аппаратное обеспечение на уровне интерфейса внешних устройств соответствовало их американским прототипам –System/360 и System/370 IBM. Комплексы ЕС представляли собой большие установки, для которых требовались специально приспособленные помещения (с кондиционерами и воздушными фильтрами) площадью не менее нескольких десятков квадратных метров. Они отличались высоким энергопотреблением, имели подключение к внешним устройствам: устройства для чтения перфокарт, блоки магнитной ленты ½ дюйма, линейные принтеры. Эти системы работали в пакетном режиме, для их обслуживания требовалось несколько человек (операторов, техников по обслуживанию, операторов по подготовке перфокарт). Стоимость покупки и развертывания таких систем была достаточно высока.
Вторая серия – компьютеры СМ (система малых ЭВМ) были созданы на рубеже 1970-х и 1980-х годов при участии стран-членов СЭВ. В разработке приняли участие более 30 институтов и предприятий из Болгарии, Венгрии, ГДР, Кубы, Польши, Румынии и Чехословакии. В 1974 г. решением Межправительственной комиссии по сотрудничеству социалистических стран в области вычислительной техники (МПК по ВТ) головной организацией был назначен Институт Электронных Управляющих Машин (ИНЭУМ). Производились мини- и микрокомпьютерные системы, характеризующиеся небольшими размерами и оснащенные более современными внешними устройствами (гибкие диски 8”, жесткие диски, экранные мониторы, мозаичные принтеры)
Компьютер MERA-60 (СМ-1633), производимый MERASTER с использованием зеленоградского процессора M-2, имел два аналога, широко применяемых в научно-исследовательских институтах СССР: «Электроника-60» и Диалоговый вычислительный комплекс (ДВК). Стоит отметить, что для ДВК-11 Новочеркасским политехническим институтом была разработана система MASTER-11, с которой программное обеспечение, описанное в этой статье, не имело ничего общего.
Компьютеры, произведенные в странах СЭВ, не отвечали рыночным потребностям этих стран, а западные решения более высокого качества и производительности в значительной степени попадали под эмбарго КОКОМ (Coordinating Committee for Multilateral Export Controls). Этот комитет должен был помешать странам Восточного блока получить современные товары и технологии двойного назначения.
Система контроля экспорта из западных стран, разработанная КОКОМ, работала чрезвычайно эффективно, однако большинство попадающих под ограничения электронных компонентов или компьютеров было практически свободно доступно у посредников, но по гораздо более высокой цене. Ситуация была такова, что местного производства не хватало, а западные компьютеры были очень дорогими.
Научно-производственный центр систем управления MERASTER был создан в Катовице по указу Министра машиностроения от 19 марта 1977 года из нескольких предприятий электроники, производящих измерительное оборудование. Ему был подчинен Институт систем управления. Создателем и первым директором этой структуры был Рышард Прегиэль. Целью Центра было развитие компьютерной индустрии для металлургической промышленности, а затем и для всей машиностроительной отрасли в Верхнесилезском промышленном районе. Слияние производственного и исследовательского подразделения по образцу объединения Варшавского института математических машин и компьютерной фабрики MERA-ERA должно было ускорить процесс внедрения современных решений. Во время своего расцвета MERASTER стал одним из трех крупнейших производителей компьютерной техники в Польше. MERASTER и ERA выпускали мини- и микрокомпьютеры, третий вроцлавский производитель Elwro – компьютеры серии ЕС ЭВМ.
Центр, в котором работало более пятисот выпускников университетов, в основном производил микрокомпьютеры, логически совместимые с PDP-11 Digital Equipment Corporation, известные под маркой MERA-60/СМ-1633 и построенные с применением полупроводниковых компонентов средней и высокой интеграции и микропроцессора серии K-590 советского производства. Значительная часть продукции экспортировалась, главным образом в СССР. Стоимость экспорта, выраженная в миллионах злотых, составляла: 1983 г. – 1 154, 1984 –1 626, 1985 – 3 119, 1986 – 2 620, 1987 – 4 186, 1988 – 10 655.
В 1984 году была выпущена модель MERA-60 с процессором, который был функциональным эквивалентом LSI-11/03. Этот компьютер давал мало возможностей для реализации систем многопользовательского доступа, главным образом из-за малого объема памяти, адресуемой процессором – всего 64 Кб, из которых только 56 Кб были практически доступны, поскольку восемь старших килобайт были адресами регистров прямой адресации внешних устройств. Операционной системой, как правило, была RT-60. Это был клон оригинальной RT-11. Русская версия системы называлась РАФОС.
Отечественные и зарубежные потребители настойчиво требовали разработки инструментальных средств, позволяющих внедрять многопользовательские системы. Их развитие сдерживалось технологической отсталостью стран социалистического лагеря. В частности, отсутствие современной элементной базы, включающей все виды памяти большой емкости: СППЗУ, ПЗУ, ОЗУ, магнитные носители и т.д. Появление процессора М6 с возможностью адресации ОЗУ до 4 МБ не решило эту проблему.
Во время одного из визитов директора Яна Важговского на технические и коммерческие переговоры в Москве, Данута Табацка и Роман Якубча предложили создать в MERASTER быструю внешнюю полупроводниковую память объемом до 20 МБ на основе карты памяти, разработанной в Институте систем управления (ISS) объемом 2 МБ. Разработка структуры схемы памяти была поручена ISS, а системное программное обеспечение – подразделению программного обеспечения MERASTER. Была сформирована команда из тринадцати человек под руководством Тадеуша Корняка чтобы инструментальное средство, позволяющее создавать системы многопользовательского доступа. В сентябре 1984 года началась работа по созданию концепции комплекса аппаратных и программных средств для компьютера MERA-60. Предполагались следящие области применения:
массовое обслуживание в банках, кассах, офисах, турагентствах и т. д.,
автоматические системы поддержки учебного процесса,
системы сбора и первичной обработки данных,
автоматические системы обработки файлов в больницах, складах, библиотеках и т. д.
В указанных системах важнейшую роль играли следящие функциональные особенности:
многопользовательский доступ, то есть поддержка одновременной работы множества пользователей на многих терминалах,
многозадачность, то есть одновременное выполнение нескольких разных задач с использованием разных терминалов,
разделение процессорного времени между выполняемыми задачами,
поддержка базы данных пользовательской системы,
обмен информацией между различными задачами и терминалами в системе,
совместное использование некоторых последовательных устройств (принтеры, магнитные ленты), для многих задач.
Предполагалось, что полупроводниковая внешняя память (PPZ-60), в дальнейшем называемая буферной памятью, будет средством увеличения используемой памяти. Емкость такой памяти должна была составлять от 0,5 до 4 МБ (т.е. во много раз больше, чем память самого микрокомпьютера). Нижний предел предполагаемого объема был результатом предварительных оценок потребностей программного обеспечения для параллельной разработки, верхний – элементной базы, доступной при проектировании.
Предполагалось, что эта память будет работать в двух режимах:
в качестве дискового эмулятора СМ 5400 (эквивалент CDC-9427)
в качестве расширения оперативной памяти, то есть устройства, обеспечивающего переключение области памяти, видимой процессором, в заданную область адресов оперативной памяти.
Первый режим работы должен был ускорить выполнение программ, которые интенсивно обменивались с накопителем массовых данных. Копирование данных, обрабатываемых программой, на электронный диск многократно ускоряло работу программы.
Для программного обеспечения, описываемого в этой статье, был интересен только второй режим работы. В оперативной памяти микрокомпьютера было выделено 8 КБ в области самых высоких адресов. Эта область представляла собой «окно», которое посредством соответствующих аппаратных механизмов (регистров) было четко отображено на определенную страницу буферной памяти. Это позволило работать с заданной страницей буферной памяти аналогично работе с адресами оперативной памяти. Механизм переключения страниц буферной памяти позволял работать на разных страницах, в разное время используя одни и те же адреса из области «окна». Общая схема работы буферной памяти показана на рисунке 1.
Рис. 1. Общая схема работы буферной памяти
В описанных условиях стало целесообразным создание такой программной среды, которая позволяла создавать прикладные системы с использованием буферной памяти для обеспечения параллельной и эффективной работы большего числа пользователей. Этой средой стала созданная Система множественного доступа для эффективного использования ресурсов с разделением времени (Multi-Access System for Timesharing Efficient Resources usage) MASTER.
Система MASTER представляла собой среду для создания многопользовательских прикладных систем, в которых задачи, выполняемые на разных терминалах, имели схожий характер и использовали общую базу данных. Во время работы системы рабочая память была разделена на так называемую «нижнюю» память, то есть область оперативной памяти от 0 до 48 КБ, и «верхнюю» память, то есть восьмибайтовое буферное окно.
Основными функциями системы MASTER были:
поддержка многопользовательского доступа: предоставление возможности одновременной работы нескольких пользователей через несколько терминалов,
деление времени: управление распределением такта процессора для готового к выполнению задания,
управление буферной памятью: выделение и освобождение страниц буферной памяти для задачи и управление переключением текущей страницы,
управление задачами: управление работой многих прикладных задач, связанных с временным разделением и множественным доступом; сохранение и извлечение страниц задач,
управление базой данных: поддержка системных файлов для индексно-последовательного доступа,
последовательное управление файлами: обслуживание, выделение и освобождение устройств для последовательных файлов; устройства могут быть зарезервированы для задачи или использованы для многих задач (журнал),
синхронизация задач: поддержка передачи сообщений и данных между задачами приложения,
служба очередей: управление очередями готовых, приостановленных и других задач с целью оптимального использования системных ресурсов,
обработка прерываний и ошибок: получение некоторых прерываний от устройств и ошибок прикладных программ для предотвращения сбоя системы,
отображение и формирование цепочек: управление выполнением некоторых задач; загрузка последующих фрагментов задач или последующих отображений на соответствующие страницы верхней памяти,
загрузка программ: замена целевой программы,
поддержка внешних устройств: управление распределением и передачей с / на внешние устройства системы,
задача супероператора: выполнение специальной системной задачи, выполнение заказов от оператора, уполномоченного вмешиваться в работу системы, и возможность изменять конфигурацию и состояние системы в зависимости от условий окружающей среды.
Основной программной единицей в системе MASTER была задача. На практике это была программа на языке PASCAL, которой был назначен терминал в системе MASTER. Задачи во время работы системы находились в буферной памяти, а модуль управления системой переключал страницы буферной памяти и распределял задачи по времени процессора. В системе MASTER задача состояла из трех частей: программа, терминал и страница буферной памяти. Также могли работать задачи, которые не взаимодействовали ни с одним терминалом. Такие задачи назывались автономными и могли использоваться, например, для связи системы MASTER с инструментальным компьютером. Программы, составляющие задание, хранились на внешнем носителе (жестком диске). Поскольку область буферной памяти, выделенная для задачи, имела только 8 КБ, система обеспечивала два независимых механизма для обмена программами: цепочка и отображение. Благодаря этим механизмам задачи могли быть практически неограниченного размера.
В системе MASTER была сохранена файловая структура системы RT-11, поскольу некоторые пользователи системы MASTER ранее использовали микрокомпьютер MERA-60, работающий под управлением системы RT-60, и у них были программы или файлы, созданные в этой системе. Следует добавить, что единственный метод организации файлов, существовавший тогда в системе RT-60 – последовательный, был недостаточен для создания баз данных, которые должны были стать основой прикладных систем, реализованных в системе MASTER. В структуру системы были встроены и более продвинутые методы организации файлов: индексно-последовательный и прямого доступа, что позволяло формировать картотеки или другие организованные информационные массивы.
Вместе с системой MASTER поставлялся набор программ, работающих под управлением RT-60. Они позволяли упорядочивать, просматривать и исправлять файлы, содержащие информационные массивы, организованные последовательным образом. В самой системе был набор системных процедур и функций, вызываемых из прикладной программы, которые разрешали доступ к существующим последовательным индексам или позволяли создавать новые. Файлы с прямым доступом поддерживались программами, написанными на PASCAL, с использованием информации о внутренней организации доступа к файлам в системе MASTER. Эти программы поставлялись с системой MASTER в исходном виде.
В системе MASTER было два типа последовательных файлов для специальных целей. Первый – журнал, позволявший создавать отчеты из системной сессии приложения. К этому файлу имели доступ все работающие в системе задачи. Задачи могли записывать в файл журнала информацию, которая по какой-то причине должна была храниться на внешнем носителе в том порядке, в котором она была получена (например, завершенные транзакции в банке). Второй тип файлов – файлы печати, то есть последовательные файлы, поддерживались механизмом очереди печати. Применение этих файлов значительно ускорило работу прикладных программ, использующих медленные или единичные устройства вывода, такие как принтер или магнитная лента. Информация выводилась в промежуточную область в буферной памяти, откуда она передавалась на устройство соответствующей системной задачей.
Проблема разделения времени между задачами была решена просто: был принят алгоритм циклического перебора с двумя уровнями приоритета (системные задачи, прикладные задачи). Это было результатом предположения, что задачи, работающие под управлением системы MASTER, будут служить для решения одной общей для всех задач данной прикладной системы задачи класса.
Задачи, проходящие через систему MASTER, взаимодействовали двумя способами. Первый был эквивалентом семафоров. Задание, отправляющее сообщение, приостанавливалось до тех пор, пока сообщение не было получено заданием, которому было адресовано сообщение. Точно так же задача, запрашивающая сообщение, оставалась приостановленной до его получения. С сообщением было связано целое число, что позволило различать более 60 000 типов сообщения. Механизм сообщений позволял организовать синхронизацию задач в рамках одной прикладной системы и использовался там, где был важен порядок действий. Для передачи данных между задачами использовался механизм, эквивалентный «почтовому ящику» и позволял передавать набор данных, адресованный любой задаче, в частном случае и самой себе.
Прикладная система представляла собой библиотеку программ, написанных на языке PASCAL, для которых система MASTER была рабочей средой. Библиотека функций и процедур на языке PASCAL (в среде исполнения) была частью ядра операционной системы, находящегося в «нижней» памяти, благодаря чему скомпилированная исполняемая программа была ограничена набором вызовов процедур и их параметров, что значительно уменьшало ее размер в байтах. Набор программ в библиотеке мог иметь различный характер и функциональное назначение, но условием их правильного выполнения был правильный способ их написания и запуска. Принятие такого решения позволило системе MASTER работать с различными наборами прикладных программ в зависимости от требований конкретного приложения.
Система MASTER работала в среде системы RT-60. Это означало, что для запуска системы MASTER и обеспечения реализации основных функций системы (прерывания, работа внешних устройств) использовалась минимальная форма системного монитора RT-60. Система MASTER также брала на себя многие функции и задачи системы RT-60, обеспечивая, среди прочего, защиту ее от сбоев из-за ошибки пользователя или плохой работы устройства. Кроме того, операционная система RT-60 являлась средой исполнения при подготовке прикладных программ и их тестировании в режиме моделирования перед включением в библиотеку, работающую в системе MASTER.
Перечисленные особенности рабочей среды системы также повлияли на использование языка программирования для прикладных программ. Это был язык, структура которого позволяла легко и быстро разрабатывать прикладное программное обеспечение, легко обрабатывать данные, обеспечивая при этом возможность выполнения программы в соответствии с внутренней организацией системы MASTER. Единственным языком программирования для прикладных программ был принят язык MASTER-PASCAL. Он был основан на языке PASCAL, для которого был расширен набор стандартных процедур и функций. Каждая прикладная программа должна была в конечном состоянии работать под управлением системы MASTER. В связи с трудностями, возникающими во время проверки правильности работы программы под управлением этой системы, был создан специальный инструмент для отладки. Прикладная программа, предназначенная для работы под управлением системы MASTER, могла быть предварительно протестирована с использованием «имитационной версии системы MASTER».
Характерной особенностью этой версии была возможность проверки правильности прикладной программы с использованием стандартных средств, доступных при работе под управлением системы RT-60. Это стало возможным благодаря прикладной программе, использующей процедуры, имитирующие систему MASTER и расположенные в библиотеке, созданной специально для этой цели. Было принято естественное в этом случае правило, что программа, отлаженная с использованием версии моделирования, в неизменном виде должна работать под управлением системы MASTER с учетом различий, возникающих из характерных особенностей системы многопользовательского доступа. Однако способы подготовки программы к работе в каждой из этих систем отличались.
В ходе работы прикладной программы под управлением имитационной версии системы MASTER могло появиться много сообщений оператора, направленных программисту, облегчающих последнему процесс тестирования прикладной программы и принятия решений относительно внесения исправлений в программу. Прикладные программы системы MASTER готовились и запускались с использованием операционной системы RT-60, стандартных программ RT-60 и пакета дополнительных программ и файлов библиотек, что позволяло адаптировать прикладную программу к требованиям системы MASTER.
Из-за существенных различий между системой RT-60, с помощью которой прикладные программы готовились и предварительно тестировались («имитационная версия системы MASTER»), и системой MASTER, в которой они в конечном итоге исполнялись, прикладные программы запускались в два этапа:
под управлением системы RT-60 с использованием библиотеки, имитирующей работу в системе MASTER,
под управлением системы MASTER.
Работа над описываемым аппаратно-программным комплексом началась с обсуждения в среде руководителей, ответственных за продажу продуктов компании, а также конструкторов и программистов. Такой состав команды, определяющей будущие функциональные возможности продукта, позволил избежать ошибки, часто совершаемой создателями тиражируемого программного обеспечения, когда большая часть очень сложных функций вообще не используется, но не хватает элементарных функций.
Затем, уже среди системных аналитиков, была определена структура системы с точки зрения ее архитектуры. На момент принятия решения о создании системы MASTER и начала ее разработки существовало множество ограничений, влияющих на способ работы. Основным ограничением была необходимость выполнить всю работу в течение 15 месяцев, причем начинать приходилось практически «с нуля» (концепция системы программного обеспечения и концепция вспомогательного оборудования). Это короткое время для создания аппаратного модуля PPZ и сложной системы, основанной на его использовании, заставило принять особый режим создания системы.
Первое решение касалось максимального распараллеливания работ, обычно выполняемых последовательно. Это касалось как одновременного создания аппаратного и программного обеспечения, так и раннего начала последующих этапов работы (до окончания предыдущих). На рисунке 2 приведена временная диаграмма основных этапов работы.
Рис. 2. Временная диаграмма основных этапов работы
Распараллеливание работы потребовало принятия организационных и технических решений, которые до сих пор не использовались ни одним из исполнителей. Чтобы ускорить работу над системой и повысить ее последующую надежность, вначале были приняты следующие допущения и соглашения:
В качестве метода организации работы был принят Метод команды главного программиста. Это метод разработки программного обеспечения, при котором один человек обладает полными и всеобъемлющими знаниями о создаваемой системе, второй – после дополнения своих знаний может выполнять задачи Главного программиста, и существует команда сотрудников, которые разрабатывают свои фрагменты системы практически независимо. Такая организация работы требовала разработки системного проекта с максимальной точностью и принятия того факта, что с определенного момента разработки программного обеспечения любые изменения (даже незначительные) не могут быть внесены в проект.
Слоисто-модульная структура создаваемой системы – с высокой изоляцией отдельных ее модулей. Это привело к некоторой неоптимальности системы в целом, но значительно повысило ее надежность.
Вся системная документация создавалась только на магнитном носителе, что в те годы еще не было стандартом.
Процесс запуска отдельных модулей и интеграции системы поддерживался специализированными инструментальными средствами запуска.
Было введено индивидуальное расписание рабочего дня для разработчиков системы.
Нестандартная тема требовала нестандартного подхода, поэтому было довольно легко убедить начальство в том, что повседневное рабочее место не является оптимальным для первоначальных обсуждений концепции системы. Каждый из восьми участников обсуждения получил задание по подготовке и представлению предложения по реализации одного аспекта системы. Затем предложения по фрагментам системы были занесены на цифровой носитель. Так возникла первоначальная концепция системы. В конце первого месяца работы было доступно шестнадцать экземпляров нулевой версии проекта. Использование редактора текстов DOC-60 имело ключевое значение для успеха всей темы. В течение первых пяти месяцев работы были созданы пять последующих версий технического проекта системы, все более последовательных и подробных. Последующие версии проекта дополнялись и перепечатывались после каждого пересмотра непосредственными разработчиками программного обеспечения. Параллельно закладывался проект создания пользовательской документации.
Первая работа по программированию, предпринятая сразу после определения внутренней структуры системы, заключалась в создании специализированных инструментов разработки. Стандартные средства исполнения, используемые в системе RT-60, не могли быть применены, по крайней мере, из-за требования многозадачности системы.
Основным инструментом при исполнении системных программ была специализированная программа исполнения, которая в дополнение к типичным возможностям также обеспечивала учет внутренних структур системы. Она позволяла:
Проверять и изменять значение глобальных системных переменных,
Регистрировать в реальном времени проходы через установленные контрольные точки в тестируемых программах,
Записывать любые изменения глобальных системных переменных (время и модуль, вносящий изменения, исходный и измененный контент),
Воссоздавать в любой момент окончательный фрагмент истории системы, который состоял из записанных проходов через контрольные точки и изменений глобальных системных переменных.
Отдельные программные модули взаимодействовали с программой исполнения с помощью набора микроинструкций. При исполнении и тестировании отдельных модулей использовались избранные функции программы исполнения. Это позволило выбирать используемые в настоящее время механизмы, а после достаточного тестирования модуля – отказаться от них.
Для ускорения работы над системным программным обеспечением также использовались нестандартные организационные решения. Самым важным из них был отказ от обычного рабочего распорядка для разработчиков системы. На заключительной стадии создания это позволило команде из десятка или более сотрудников работать с единственным образцом оборудования, который использовался практически 24 часа в сутки и семь дней в неделю. Базовый интервал времени доступа к единственному образцу с буферной памятью составлял два часа.
Наличие десятка и более копий нескольких последующих редакций «Технического проекта» привело к необходимости создания должности Секретаря проекта, то есть лица, ответственного за изъятие устаревших редакций из тиража и хранение всех последующих редакций.
Были разрешены только необходимые исправления или изменения в отношении окончательной версии проекта. Необходимость определялась в двухстороннем или многостороннем порядке, в зависимости от того, скольких модулей касалась данная поправка, в то время как любое малейшее отклонение от проекта требовало согласия Главного программиста.
Идеи существенных изменений, которые возникли в процессе написания и запуска системы, были перечислены в приложении к проекту, благодаря чему, наряду с внедрением первой версии системы, был разработан технический проект второй версии.
Основной причиной успеха проекта, помимо тщательной подготовки базовых положений и их последовательной реализации, стал отказ от стремления к идеалу. С точки зрения программирования промышленных систем было бы ошибкой вводить даже самые совершенные дополнения за счет конечного результата. Команда, возможно, реализовала бы «лучшую в мире систему на все случаи жизни», вместо работающей, законченной системы MASTER. Еще одной причиной успеха проекта был вызов, связанный с масштабом новизны системы. Следует предположить, что реализация задачи аналогичной организационной сложности, но рутинной, не высвободила бы такие интеллектуальные резервы и не создала бы подобную мотивацию среди исполнителей. Важным фактором успеха стало то, что разработчики системы стали его первыми пользователями. Во время внедрения системы те из ее исполнителей, которые завершили свое участие в работе, тут же начали создавать прикладную систему, заказанную внешней организацией. Такой подход, хотя и связанный с риском не выполнить обе работы одновременно, оправдал себя. Каким бы невероятным это не показалось, но сработал метод устранения последствий законов Мерфи, заключающийся в том, чтобы рутинно хранить результаты работы на резервном носителе, сохраняя последние две (но не более) копии, поскольку это было время, когда еще не было никаких компьютерных вирусов. Эта стратегия архивирования позволила избежать серьезных проблем при создании системы.
Создание системы MASTER было «лебединой песней» MERASTER. Крах экономического сотрудничества в рамках СЭВ сделал продукты Центра менее привлекательными из-за ослабления эмбарго и экспансии западных ИТ-корпораций на рынки под запретом КОКОМ. Кроме этого, с середины 1980-х годов в Польше галопировала инфляция, экспорт был не прямым, а через так называемые Центры внешней торговли. Проходило несколько месяцев, иногда даже год от производства оборудования до получения за него денег, что вызвало нарастание проблем для всей экономики, а в описываемом случае – крах компании в начале девяностых годов двадцатого века. Описанные проекты оказали значительное влияние на дальнейшее развитие ИТ-индустрии в Силезии. Были подготовлены квалифицированные кадры, которые в условиях свободной экономики создали один из самых сильных ИТ-центров в Польше.
Budka Marian, Jakóbiec Romuald, Microcomputers and microcomputer systems manufactured by the MERASTER Research and Development Center of Control Systems, Mech. Automat. Gorn.; (Poland), vol. 25:7, Jul 1987
Korniak Tadeusz, Fuglewicz Piotr W., MASTER zaawansowany system operacyjny stworzony w warunkach przemysłowych, Analecta – Studia i Materiały z Dziejów Nauki [Analecta – Studies and Materials on the History of Science] XXIV, 2015, 2, 179-194
Mastanduno, M. Economic containment: CoCom and the politics of East-West trade. Cornell paperbacks. Cornell University Press, Ithaca, N.Y., 1992, ISBN 978-0801499968
Yasuhara, Y. The myth of free trade: the origins of COCOM 1945–1950 // The Japanese Journal of American Studies
Валикова Л.И., Вигдорчик Г.В. и др. Операционная система СМ ЭВМ РАФОС. М.: Финансы и статистика, 1984.
Дедов Ю.А., Островский М.А., Песелев К.В., Полин X., Сейфи И.Т., Соколов А.Я., Филин А.В. Малые ЭВМ и их применение / Под общ. ред. Б. Н. Наумова. М.: Статистика, 1980.
Об авторе:
Музей истории компьютеров и информатики, Катовице, Польша piotrwf@gmail.com
