Операционная система z/VM

12.4 Операционная система z/VM

ОС z/VM [21, 24, 42] (последняя версия - V4R2) является высокопроизводительной многопользовательской интерактивной ОС, предоставляющей уникальные возможности в части выполнения различных операционных сред на одном вычислительном комплексе, поддержки интерактивных пользователей и клиент/серверных сред. Существует "легенда" о том, что VM родилась как инструментальное средство, предназначенное для использования только внутри IBM, и попала на рынок вопреки планам фирмы. Хотя IBM и опровергает эту легенду, она выглядит вполне правдоподобно. z/VM представляет интерес для применения прежде всего в таких случаях:

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

как платформа для миграции на новые ОС и новые версии ОС и системного программного обеспечения, обеспечивающая параллельное функционирование как старого, так и нового программного обеспечения;

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

Уникальные свойства z/VM определяются ее архитектурой. Аббревиатура VM расшифровывается как Virtual Machine, и эта ОС в полной мере воплощает концепцию виртуальных машин: интерфейс процесса выглядит как интерфейс оборудования. Ядро z/VM составляет Управляющая Программа CP (Control Program), которая предоставляет для своих конечных пользователей рабочую среду, называемую виртуальной машиной (ВМ). ВМ в z/VM является аналогом процесса в других ОС: это тот "субъект", которому CP выделяет ресурсы. ВМ моделирует реальную вычислительную систему: процессор (или процессоры), память, устройства и каналы ввода-вывода. У пользователя создается впечатление, что в его распоряжении имеется реальная ЭВМ, доступная для него в привилегированном режиме. На самом же деле, в его распоряжении находится только то подмножество ресурсов, которое выделяет или моделирует для ВМ CP. PSW ВМ определяет для выполняющейся на ВМ программы состояние "супервизор" (привилегированное состояние). PSW же реального оборудования при выполнении такой программы определяет состояние "задача" (непривилегированное). При попытке программы, выполняющейся на ВМ, выполнить привилегированную команду происходит исключение, и управление получает CP. CP распознает причину исключения и выполняет для ВМ привилегированную команду или моделирует ее выполнение, после чего возвращает управление ВМ. Исключение и его обработка скрыты от ВМ, ВМ кажется, что ее привилегированная команда выполнилась на реальном оборудовании.

СP на выбор моделирует для ВМ архитектуры нескольких поколений мейнфреймов - от 370/XA до z900, а также виртуальную архитектуру ESA/XC (eXtended Confuguration), в которой ВМ могут быть доступны (при авторизации) адресные пространства других ВМ. В число компонентов архитектуры ВМ входят:

процессор/процессоры;

память;

внешняя память;

операторская консоль;

каналы и устройства ввода-вывода.

Поскольку CP предоставляет ВМ модель, неотличимую для нее от ресурсов реальной вычислительной системы, программа, выполняющаяся на ВМ, может (и должна) осуществлять управление этими ресурсами, то есть, в свою очередь, быть операционной системой. Такие ОС называются в z/VM гостевыми (guest). В документации z/VM CP иногда называют гипервизором, в отличие от супервизоров - управляющих программ гостевых ОС. Гостевая ОС может "знать" о том, что она работает под управлением гипервизора, в этом случае гостевая ОС может использовать обращения к CP (команда DIAGNOSE), а также гостевая ОС и CP могут распределять между собой управление ресурсами: гипервизор работает с интерфейсом оборудования, а гостевая ОС - с интерфейсом процесса. Если же гостевая ОС не знает о присутствии CP, то она выполняет управление созданной для нее моделью ресурсов в полном объеме. С этой точки зрения можно разделить гостевые ОС на четыре категории:

ОС, специально созданные как гостевые, которые могут работать только в среде ВМ под управлением гипервизора - CMS и GCS.

Полнофункциональные другие ОС мейнфреймов (VSE, z/OS и ее предшественники, Linux for zSeries), выполняющиеся "не зная" о существовании гипервизора.

Те же ОС, но адаптированные для выполнения в среде ВМ, адаптация состоит в том, что исключается дублирование функций в гипервизоре и супервизоре.

Гостевой ОС может быть другая (вторичная) CP, которая распределяет выделенное ей подмножество ресурсов между своими ВМ и своими гостевыми ОС, среди которых в свою очередь могут быть CP и т.д.

Рисунок 12.7 CP и виртуальные машины

Определение ВМ является квазипостоянным: оно создается один раз, а затем используется многократно. Определение ВМ сохраняется в каталоге CP, основным содержанием элемента каталога CP является описание ресурсов, выделяемых ВМ. При запуске ВМ на выполнение CP на основе элемента каталога строит Блок Определения Виртуальной Машины - VMDBLK (Virtual Machine Definition BLocK), в котором содержится описание ресурсов ВМ (либо непосредственно в VMDBLK, либо как ссылки на другие управляющие блоки) и их текущего состояния. Если для ВМ создается несколько виртуальных процессоров, то для каждого процессора создается свой VMDBLK, но только один из VMDBLK каждой ВМ является базовым - тот, который содержит описание памяти ВМ. Свой VMDBLK имеет также и CP. Все VMDBLK связаны в кольцевой список.

Управление памятью

Возможно, главным ресурсом, которым управляет CP, является реальная память, и с этой точки зрения CP может создавать ВМ трех типов:

Тип V=V - ВМ, которой выделяется только виртуальная память, требуемый размер памяти дя ВМ обеспечивается за счет динамической трансляции адресов и страничного свопинга.

Тип V=F - ВМ, которой выделяется непрерывная область реальной памяти. Эта область исключается из страничного обмена, но динамическая трансляция адресов для ВМ V=F применяется, так как виртуальное адресное пространство ВМ начинается с адреса 0, а в реальной памяти область, выделяемая для ВМ V=F, начинается не с 0. ВМ типа V=F обладают преимуществом в производительности перед ВМ V=V.

Тип V=R - ВМ, которой выделяется непрерывная область реальной памяти, начиная с адреса 0. Эта память исключается из страничного обмена и для нее не применяется динамическая трансляция адресов. Кроме того, ВМ V=R может выполнять некоторые привилегированные операции на реальном оборудовании. Очевидно, что производительность ВМ этого типа наивысшая.

ВМ двух последних типов называются привилегированными. В настоящее время CP допускает одновременное функционирование не более шести привилегированных ВМ, из которых только одна может быть типа V=R, тогда как число одновременно работающих ВМ типа V=V может исчисляться десятками тысяч. Работа привилегированных ВМ резко отрицательно сказывается на производительности всех других VM, поэтому эти типы ВМ создаются только при наличии действительной необходимости в них (например, для задач реального времени).

Если под управлением CP работают только ВМ типа V=V, то ядро CP занимает нижнюю часть реальной памяти (начиная с адреса 0). Вся реальная память выше ядра отводится под динамическую страничную область, которая подвергается страничному обмену. Если же под управлением CP работают наряду с ВМ типа V=V и привилегированные ВМ, то нижняя часть реальной памяти отводится под область V=R. Часть этой области, начиная с адреса 0, занимает единственная ВМ типа V=R, остальная часть области распределяется между ВМ типа V=F. Выше области V=R размещается ядро CP, а еще выше - динамическая страничная область.

Динамическая страничная область содержит:

управляющие блоки СP;

нерезидентные модули CP;

блоки управления памятью CP;

буферы для спулинга и файловой системы;

префиксные страниц для реальных процессоров;

свободные страничные кадры;

страницы ВМ типа V=V.

В архитектуре z/VM различаются три уровня памяти:

память первого уровня - реальная память;

для каждой ВМ CP строит виртуальное адресное пространство - память второго уровня;

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

Виртуальная память ВМ состоит из сегментов. Для каждой ВМ строится своя таблица сегментов. При размере виртуальной памяти ВМ до 32 Мбайт таблица сегментов находится непосредственно в VDMBLK, при большем размере - для нее выделяются дополнительные страницы (по 1 странице на каждые 1024 Мбайт виртуальной памяти). С каждой таблицей сегментов связана собственная таблица страниц.

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

Список свободных страничных кадров пополняется при необходимости и обрабатывается по дисциплине LIFO.

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

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

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

Диспетчеризация ВМ

При работе на двух- и более процессорной конфигурации реальной системы для ВМ типа V=R по умолчанию выделяется отдельный процессор. Для ВМ типа V=F отдельный процессор может быть выделен, но по умолчанию это не делается.

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

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

диспетчерскую очередь, d-список (dispatch list), ВМ состоящие в диспетчерской очереди, получают процессор в режиме разделения времени, мы называли такие процессы готовыми;

очередь готовых ВМ, e-список (eligible list), которые исключены из диспетчеризации из-за нехватки ресурса памяти;

список "спящих" ВМ (dormant list).

Готовыми здесь называются те ВМ, которые требуют выполнения какой-либо процессорной транзакции. "Спящие" ВМ процессорного обслуживания не требуют.

Все ВМ распределяются по четырем классам обслуживания:

критические - те, для которых гарантируется отсутствие ожидания в e-списке (класс 0);

очень интерактивные - выполняющие короткие транзакции (класс 1);

интерактивные - выполняющие транзакции средней длительности (класс 2);

неинтерактивные - выполняющие длинные транзакции (класс 3).

Класс с меньшим номером имеет более высокий приоритет в e-списке. В d-списке приоритеты перевычисляются динамически через каждый квант времени. При перевычислении кванта принимается во внимание:

внешний приоритет ВМ;

время ожидания в d-списке;

интерактивная добавка для класса 1;

страничная добавка - единоразовая добавка к приоритету, назначаемая для ВМ класса 2 или 3 при задержке из-за страничного отказа.

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

Кроме того, CP также вычисляет для каждой ВМ квант готовности - общее реальное время пребывания ВМ в d-списке. Для ВМ класса 1 этот квант вычисляется системой таким образом, чтобы за время кванта готовности успели завершить свои транзакции 85% ВМ класса 1. Для классов 0 и 2 этот квант в 6 раз больше, чем для класса 1, для класса 3 - в 48 раз больше, чем для класса 1. Если ВМ исчерпала квант готовности, но не завершила транзакцию, она переводится в следующий класс.

Использование рабочего набора не влияет на приоритет ВМ в e-списке, но влияет на перемещение ВМ между d- и e-списками. Если ВМ, находящейся в d-списке, не хватает памяти для размещения своего рабочего набора, в d-списке блокируются все ВМ того же и большего класса. Если ВМ, находящаяся в d-списке, превысила лимит роста своего рабочего набора (кроме ВМ класса 0), она переводится в e-список. Если в e-списке имеется ВМ класса 1, которая запаздывает с переходом в d-список, CP пытается вытеснить из d-списка последние переведенные в него ВМ классов 2 или 3.

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

Виртуальные устройства

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

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

z/VM также широко использует концепцию спулинга. Каждая ВМ имеет свой виртуальный принтер и виртуальные устройства ввода с перфокарт и вывода на перфокарты. Физически эти устройства моделируются очередями на внешней памяти. Если очередь принтера может быть выведена на реальное устройство, то данные из очередей перфокарточных устройств так и остаются на внешней памяти, так как реальные перфокарточные устройства просто уже не существуют. Но эти данные могут пересылаться из выходных очередей в выходные. Механизмы спулинга используются также для организации, так называемых, именованных сегментов памяти (named storage segment). В таких сегментах в области спулинга сохраняются многократно используемые коды и данные, например, образы гостевых ОС.

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

Примером еще одного подхода к виртуализации устройств в z/VM является виртуальный адаптер канал-канал. Через этот адаптер может осуществляться взаимодействие между ВМ. Управляющие воздействия, которые ВМ формирует для виртуального адаптера, - такие же, как и для реального адаптера. Однако виртуальный адаптер не отображается ни на какое реальное устройство, он моделируется CP, а управляющие воздействия для него интерпретируются CP с использованием буферов в памяти и программных кодов.

CMS

Диалоговая управляющая система СMS (Conversation Monitor System) является гостевой ОС, обязательным компонентом z/VM. Это интерактивная однопользовательская, однозадачная ОС, предназначенная прежде всего для разработчиков программного обеспечения и администраторов системы. CMS разрабатывалась именно как гостевая ОС, поэтому ей не свойственны некоторые функции, типичные для самостоятельных ОС, такие как диспетчеризация и планирование, управление реальной памятью - эти функции выполняет CP. CMS обеспечивает работу с файловой системой, управление виртуальной памятью, управление виртуальными устройствами и интерфейс пользователя.

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

CMS состоит из следующих основных частей:

терминальная система, обеспечивающая коммуникации между пользователем и ОС;

системные службы CMS, в том числе:

команды и утилиты и пакетная служба;

сервис библиотек LIBRARYAN;

сервис редактора XEDIT;

командные интерпретаторы EXEC2, CMS EXEC, REXX;

Open Extention;

файловые системы:

файловая система минидисков;

SFS;

BFS.

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

Сервис библиотек обеспечивает создание и ведение библиотек макроопределений, объектных модулей и загрузочных модулей, а также загрузку и выполнение модулей из библиотек z/OS.

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

Наиболее развитым процедурным языком CMS является язык REXX. Этот язык родился именно в CMS, но сейчас является обязательной составной частью любой операционной системы IBM. В качестве прототипа для REXX был взят язык программирования PL/1, таким образом, REXX обладает полным набором алгоритмических возможностей и возможностью выполнять в программе команды, адресуемые операционной системе (CMS или CP) или другой системной или прикладной среде (например, XEDIT, DB2 и т.д.). В отличие от своего прототипа, REXX является интерпретирующим языком и в полной мере использует это свойство - вплоть до возможности выполнить переменную - строку символов как оператор программы.

Файловые системы CMS

На минидисках, предоставляемых ВМ, CMS организует файловую систему с плоским каталогом, распределением пространства блоками по 512 байт и планом размещения файлов в виде B+-дерева. Минидиски идентифицируются буквами от A до Z, полное имя файла состоит из собственно имени, типа (аналог расширения в MS DOS, Windows или OS/2) и идентификатора диска. Файлы CMS - записеориентированные с постоянным или переменным размером записи.

Файловая система на минидисках была первой файловой системой для CMS, однако ее существенный недостаток состоит в том, что дисковое пространство для минидисков ВМ должно выделяться все сразу и, таким образом, реальное дисковое пространство используется нерационально. Поэтому для CMS была разработана Разделяемая Файловая Система SFS.

SFS обеспечивает совместное управление дисковым пространством для всех ВМ и динамическое выделение внешней памяти для ВМ в пределах установленной для нее квоты. Управление обеспечивается сервером SFS, выполняющимся на отдельной ВМ и обслуживающим все остальные ВМ в системе. Для каждой ВМ сервер SFS обеспечивает собственную структуру хранения файлов в виде дерева каталогов глубиной до 8 уровней. Корнем дерева является имя файлового пула и имя ВМ. Пользователь ВМ может давать права доступа к своим файлам и каталогам другим пользователями, в том числе, и право PUBLIC. SFS обеспечивает также алиасы и автоматическую защиту совместно используемых файлов от одновременной записи. Специальные команды CMS обеспечивают возможность представления каталога SFS как минидиска или наоборот - минидиска как каталога SFS.

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

Остальные минидиски сервера составляют пользовательские данные, которые для удобства управления разбиваются на группы памяти. Всего возможно до 32К групп памяти, группы могут добавляться к файловому пулу. Размер всех групп памяти одинаков, группа состоит из нескольких минидисков, желательно - находящихся на разных реальных дисках.

CMS Open Extension

Чрезвычайно важным компонентом CMS является Open Extension, позволяющий CMS функционировать как Unix-системе. Open Extension обеспечивает выполнение ряда спецификаций стандартов POSIX, Single Unix Specification и DCE, как в части интерпретатора shell и утилит, так и в части API и файловой системы.. Для соблюдения стандарта POSIX в иерархическую файловую систему в SFS добавлено расширение, называемое Байтовой Файловой Системой BSF (Byte File System). BFS, в отличие от SFS, обеспечивает байориентированное представление файлов, иерархическую структуру каталогов без ограничений на глубину вложенности, связи и символьные связи, права доступа к файлам. Open Extension позволяет разрабатывать в CMS POSIX-совместимые приложения и портировать таковые в CMS, а также функционировать выполняемым в CMS приложениям в гетерогенной распределенной среде.

GCS

Групповая Управляющая Система GCS (Group Control System), как и CMS, является гостевой ОС - компонентом z/VM. GCS не конкурирует с CMS, они предназначены для разных задач. Если CMS - система для поддержки интерактивной работы, разработки и администрирования, то GSC - среда для выполнения приложений, прежде всего - приложений, тесно взаимодействующих друг с другом и приложений в архитектуре IBM SNA (System Network Architecture).

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

Специфической функцией GCS в составе z/VM является является поддержка архитектуры SNA как части z/VM без помощи какой-либо другой ОС. Эта поддержка выполняется продуктом ACF/VTAM (Advanced Communication Functiom/Virtual Telecommunications Access Method). Версия VTAM для GCS выполняется на одной из ВМ группы и управляет потоками данных, проходящими между сетевыми устройствами и программами, выполняющимися на других ВМ группы. VTAM также предоставляет сетевой интерфейс другим программным продуктам, обеспечивающим коммуникации, таким как:

APPC (Advanced Program-to-Program Communications)/VM Support, обеспечивающий высокоуровневый интерфейс взаимодействия программ по протоколу APPC, независящий от того, являются взаимодействующие программы локальными или удаленными;

RSCS (Remote Spooling Communications Subsystem), обеспечивающая передачу информации через сеть SNA, работу с файлами спулинга и передачу сообщений через связи не-SNA;

NetView - средство управления сетями SNA.

Виртуальное АП, создаваемое GCS для выполняющихся в ней приложений, отчасти напоминает АП приложений CMS: 16-Мбайтное пространство распределяется следующим образом (от меньших адресов к большим):

управляющие блоки GCS, создаваемые для каждой ВМ;

частное АП приложений;

коды ядра общие управляющие блоки GCS (совместно используемые группой);

общая область данных, общие управляющие блоки GCS (только чтение);

общая область памяти (чтение и запись).

При расширении АП выше 16 Мбайт в верхней части АП создаются дополнительные порции частного АП и области данных и памяти.

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

GSC поддерживает многозадачность на одной ВМ. Следует, однако, помнить о том, что распределение процессорного обслуживания между программами GSC ведется в рамках того кванта времени, который выделяется виртуальной машине CP. GSC распределяет обслуживание по принципу абсолютных приоритетов, число градаций приоритета - 256 (приоритет 255 - наивысший). Задача, выбранная на выполнение, вытесняется только тогда, когда она переходит в состояние ожидания или в состояние готовности приходит задача с более высоким приоритетом. Если, однако, имеется несколько задач с одинаковым наивысшим приоритетом, они получают обслуживание в режиме квантования времени. Приоритет задачи/подзадачи устанавливается при ее порождении и может быть изменен только явным образом - системным вызовом CHAP. Механизмы управления задачами в GCS - те же, что и в z/OS:

системные вызовы ATTACH и DETACH - для порождения и уничтожения задач;

системные вызовы WAIT и POST и блоки ECB - для синхронизации выполнения;

системные вызовы ENQ и DEQ - для взаимного исключения доступа к ресурсам.

Linux в z/VM

В разделе, посвященном z/VM, будет уместно упомянуть и Linux for 390, и Linux for zSeries. ОС Linux была портирована на мейнфреймы в рамках Advanced Technology Project, и этот проект активно поддерживается IBM. Linux не является чисто гостевой ОС для z/VM, эта ОС может работать и непосредственно на вычислительном комплексе, однако мощности ОС Linux, разумеется, недостаточно для управления ресурсами полноценного мейнфрейма. Поэтому Linux применяется как самостоятельная ОС в небольшом логическом разделе мейнфрейма или (чаще всего) как гостевая ОС в z/VM. Использование Linux в таком качестве позволяет обеспечить конечных пользователей мейнфрейма рабочими станциями, обладающими гибкостью, надежностью и способностью работать в тесном взаимодействии с другими системами. Немаловажным является то обстоятельство, что виртуальные рабочие станции Linux делают мейнфреймы доступными для огромного числа пользователей, которые не знакомы со спецификой работы в их ОС. Поскольку ОС мейнфреймов поддерживают стандарты работы в Открытой распределенной среде, многие мощные сервисы, обеспечиваемые другими ОС мейнфреймов, являются доступными и для виртуальных рабочих станций Linux.

Глава 13. Платформа Java как операционная среда

Похожие работы

Сравнительный анализ и оценка эксплутационных характеристик различных терминальных устройств информации в вычислительных системах

Скачать

129632

2

0

... , выдачей и приёмом лицензий). В условиях крупных сетей рекомендуется выделение под сервер лицензий отдельного компьютера (или нескольких - для резервирования). 1.1 Архитектура терминальных устройств В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (по англ. three-tier или Multitier architecture) предполагает наличие следующих компонентов приложения: ...

Сети, операционная система Netware

Скачать

116709

11

1

... ФС в разделе MS-DOS. Это конфигурационный файл в котором содержится информация о драйверах используемых в процессе запуска ФС. Пункт доступен супервизору или его эквивалентам. «Система учета» NetWare обладает очень гибкой системой учета ресурсов, предоставляемых в общее пользование. Используя данный пункт меню можно просмотреть, а так же имея определенные права настроить плату за использование ...

Системы управления базами данных

Скачать

41540

0

0

... числе на промышленных предприятиях, больше подходят клиент-серверные СУБД. Мы рассмотрим особенности таких распространенных СУБД, как Oracle и MS SQL Server. Глава 4. Язык SQL в системах управления базами данных SQL (англ. Structured Query Language — язык структурированных запросов) — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных ...

Программа защиты объектов операционной системы Windows95, работающей в многопользовательском режиме под управлением сервера Novell NetWare

Скачать

111441

18

8

... ОС Windows 95, необходимость выбора тех конкретных объектов, к которым необходимо ограничить доступ. Настоящая работа посвящена разработке программы защиты объектов операционной системы WINDOWS95 работающей в многопользовательском режиме под управлением сервера Novell NetWare (Windows NT, Unix), позволяющей проводить защиту объектов ОС на уровне пользователя. Под защитой объектов ОС Windows 95 ...