ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2017 г.)
2-летний импакт-фактор РИНЦ: 0,500
2-летний импакт-фактор РИНЦ без самоцитирования: 0,405
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,817
5-летний импакт-фактор РИНЦ: 0,319
5-летний импакт-фактор РИНЦ без самоцитирования: 0,264
Суммарное число цитирований журнала в РИНЦ: 6012
Пятилетний индекс Херфиндаля по цитирующим журналам: 404
Индекс Херфиндаля по организациям авторов: 338
Десятилетний индекс Хирша: 17
Место в общем рейтинге SCIENCE INDEX за 2017 год: 527
Место в рейтинге SCIENCE INDEX за 2017 год по тематике "Автоматика. Вычислительная техника": 16

Больше данных по публикационной активности нашего журнале за 2008-2017 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
16 Декабря 2018

Мультиконсольное обеспечение базовой операционной системы

Статья опубликована в выпуске журнала № 2 за 1990 год.[ 25.06.1990 ]
Аннотация:
Abstract:
Авторы: () - , ,
Ключевое слово:
Ключевое слово:
Количество просмотров: 5330
Версия для печати

Размер шрифта:       Шрифт:

Разработчики базовой операционной системы (БОС), одной из подсистем ОС7 ЕС, для реализации мультиконсольного обеспечения выбрали особую виртуальную машину (ВМ), на которой функционирует подсистема мультиконсольного обеспечения (ПМО). ВМ ПМО принимает сообщения базовой ОС и посылает команды операторов для базовой ОС через виртуальный адаптер канал/канал. Дополнительные консоли реализуются на виртуальных пультах (ВП) ВМ, работающих под управлением подсистемы диалоговой обработки (ПДО). Эти ВМ получают сообщения базовой ОС от ВМ ПМО с помощью команды MSGNOH монитора виртуальных машин (МВМ), а команды оператора посылаются командой SMSG МВМ. Указанные ВМ должны быть описаны в особом файле конфигурации дополнительных консолей [1].

Подобная схема организации ПМО имеет некоторые недостатки:

·         наличие дополнительной ВМ ПМО, для которой нужно выполнять регистрацию и загрузку ПДО, а затем загрузку собственно ПМО;

·         необходимость редактирования файла конфигурации консолей при добавлении или замене ВМ для дополнительной консоли;

·         необходимость префиксации команд оператора;

·         отключение ВП ВМ БОС (виртуальным пультом становится виртуальный адаптер канал/канал);

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

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

Предлагается вариант более рациональной организации ПМО для БОС, воплощенный в оригинальной подсистеме мультиконсольного обеспечения "Консоль". Суть его заключается в отказе от особой ВМ ПМО и замене двухступенчатого обмена базовой ОС с дополнительными консолями на одноступенчатый (рис. 1).

Монитор виртуальных машин

пдо

 

1 пдо

* * W

 

ПДО |

1/1

1/1

     

/1

Средство связи виртуальных машин память-память VMCF

   

/1

 
   

Базовая

операционная

система

 
               

Рис. 1. Общая конфигурация подсистемы мультиконсольного обеспечения КОНСОЛЬ

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

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

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

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

Как работает система "Консоль"? На ВМ БОС при загрузке автоматически стартуют две процедуры, остающиеся активными на все время сеанса работы ВМ БОС. На любой другой ВМ, на которой загружена ПДО, пользователь может активизировать консоль БОС, присоединив соответствующий диск и набрав команду МКС. После этого на ВП отображаются 22 строки сообщений консоли БОС, которые обновляются каждые 4 секунды. Команды набираются на командной строке и вводят ся клавишей "Ввод". Для завершения сеанса достаточно нажать клавишу ПФЗ - при этом происходит возврат в среду ПДО.

При более подробном рассмотрении функционирования и взаимной связи компонентов ПМО можно считать, что подсистема мультиконсольного обеспечения представляет собой сеть виртуальных машин типа "звезда", где роль центральной ЭВМ принадлежит ВМ БОС. Это создаст удобство при описании взаимодействия компонентов ПМО в терминах сетевых протоколов [3].

Уровень канала передачи данных в такой системе обеспечивается протоколом SENDN стандартного средства связи ВМ память-память [4]. Это наиболее быстрый протокол, который предусматривает синхронизацию приема данных с помощью внешнего прерывания. Блок обработки внешних прерываний включен как в процедуру МКС, так и в драйвер консоли.

На транспортном уровне управление обеспечивается следующим протоколом. После запуска (на ВМ ПДО) драйвер консоли посылает в ВМ БОС регистрационное сообщение. Процедура МКС распознает тип сообщения и запоминает идентификатор ВМ в таблице имен дополнительных консолей (при наличии свободного места). Так устанавливается логический канал для новой консоли. Уничтожение логического канала (исключение идентификатора ВМ из таблицы имен консолей) происходит тогда, когда в ответ на посылку буфера с данными процедура МКС получает определенный код возврата, указывающий на то, что пользователь остановил драйвер консоли. Выбор очередного логического канала процедура МКС осуществляет последовательным периодическим просмотром (каждые 4 секунды) таблицы имен консолей и посылкой на все зарегистрированные дополнительные консоли образа буфера главной дисплей-консоли БОС. Частотой просмотра можно управлять, меняя тем самым трафик обмена с ВМ дополнительных консолей. Взаимодействие программных средств БОС, управляющих обменом с дополнительными консолями, представлено на рис. 2.

На время обработки сообщений операторов и посылки буфера на ВМ дополнительных консолей внешние прерывания на ВМ БОС маскируются, предотвращая утерю очередных сообщений при работе нескольких консолей.

На пользовательском уровне процедура МКС выполняет действия, определяемые типом поступившего сообщения. Сообщения либо передаются обработчику команд базовой ОС через SVC-34 (если это команда оператора), либо поступают на ВП ВМ БОС и все дополнительные консоли (если это сообщение оператору).

Основные функции драйвера консоли:

прием буфера дисплей-консоли но соответствующему внешнему прерыванию и отображение принятого буфера на ВП;

прием данных, вводимых оператором с клавиатуры ВП и посылка их на ВМ БОС;

завершение работы по команде оператора (рис. 3).

Эти функции базируются на перехвате прерываний ввода/вывода и внешних прерываний на ВМ дополнительных консолей и реализуются с помощью стандартных макрокоманд ПДО.

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

Рис. 2. Конфигурация программных средств, поддерживающих мультиконсольное обеспечение со стороны БОС

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

Подсистема мультиконсолыюго обеспечения "Консоль" предоставляет пользователю и оператору БОС более удобные по сравнению со стандартными средствами условия запуска и использования ПМО:

·         независимость активизации ПМО и загрузки базовой ОС;

·         сохранение ВП ВМ БОС в качестве основной консоли БОС;

·         произвольный выбор ВМ для дополнительной консоли БОС;

·         естественную форму набора команд на ВП ВМ дополнительной консоли.

Рис. 3. Конфигурация программных средств, поддерживающих мультиконсольное обеспечение со стороны ПДО

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

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

СПИСОК ЛИТЕРАТУРЫ

Вейцман К. Распределенные системы мини и микроЭВМ.-М.: Финансы и статистика, 1983 г.

Давыдов А.В. Программная поддержка буфера главной дисплей-консоли в базовой ОС/ Статья принята к публикации журналом "Электронная промышленность".

Единая система электронных вычислительных машин: Базовая операционная система. Управление работой. Руководство оператора. Ц5.20049-03 34 01. 1988 г.

Единая система электронных вычислительных машин: Система виртуальных машин. РСП. Средства взаимодействия виртуальных машин. Е1.00О05-02 32 01-5. 1986 г.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=1412
Версия для печати
Статья опубликована в выпуске журнала № 2 за 1990 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: