Операционные системы для больших ЭВМ

ЛИСТ ДЛЯ ЗАМЕЧАНИЙ

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ 4

1 ИСТОРИЯ И АРХИТЕКТУРА МЕЙНФРЕЙМОВ 5

2 ОПЕРАЦИОННАЯ СИСТЕМА VSE/ESA 8

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

2.2 Управление задачами 11

2.3 Файловая система 11

3 ОПЕРАЦИОННАЯ СИСТЕМА Z/OS 13

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

3.2 Управление процессами 16

3.3 Средства взаимодействия 16

4 ОПЕРАЦИОННАЯ СИСТЕМА Z/VM 18

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

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

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

4.4 CMS 20

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

4.2 CMS Open Extension 22

4.3 GCS 23

ЗАКЛЮЧЕНИЕ 24

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ 25

ВВЕДЕНИЕ

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

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

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

1 ИСТОРИЯ И АРХИТЕКТУРА МЕЙНФРЕЙМОВ

Обычно на русский язык термин "мейнфрейм" переводится как "большая ЭВМ универсального назначения". Однако нам представляется, что в настоящее время такое определение уже не является точным. Современные мейнфреймы не универсальны. Они специализированы как компьютеры для обработки больших и сверхбольших объемов данных или как суперсерверы. Название одного из поколений мейнфреймов IBM ESA (Enterprise System Architecture - архитектура систем масштаба предприятия) достаточно точно отражает такую специализацию.

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

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

Семейство мейнфреймов IBM System/360, появившееся в начале 60-х годов, стало значительной вехой в истории вычислительной техники. Во-первых, это были первые ЭВМ, которые начали выпускаться серийно, а не по индивидуальным проектам, во-вторых, они стали первым семейством ЭВМ, то есть набором моделей с разной производительностью и разной стоимостью, но с переносимостью программного обеспечения с одной модели на другую. Семейство IBM System/360 строилось на базе CISC-процессоров с богатым набором команд и несколькими режимами адресации. Эти процессоры, однако, не поддерживали динамическую трансляцию адресов, поэтому программное обеспечение работало с реальной памятью, привязка адресов осуществлялась при загрузке. (Точнее - во время выполнения, в момент загрузки "базовых" регистров, но загруженная в реальную память программа уже не могла быть перемещена.) Размер адресной шины составлял 24 бит, что позволяло адресовать 16 Мбайт памяти - реальной и виртуальной. Чрезвычайно сильным свойством IBM System/360 явилась архитектура каналов ввода-вывода. Достоинства мейнфреймов IBM System/360 определили ведущее положение этого семейства на рынке вычислительной техники в течение всех 60-х и начала 70-х годов, и первое время конкуренты IBM, вынуждены были делать собственные компьютеры программно совместимыми с IBM System/360.

Следующим поколением мейнфреймов стало семейство IBM System/370. Принципиальным отличием его от предыдущего поколения явилось введение динамической трансляции адресов. Применялась сегментно-страничная модель трансляции, во всех ОС этого поколения каждому процессу выделялся один сегмент адресного пространства (АП), то есть, процесс обладал собственной виртуальной памятью размером в 16 Мбайт. Однако в этом поколении проявилось некоторая "успокоенность" фирмы IBM. Фирма упустила из виду одно из конкурирующих направлений развития вычислительной техники, а именно - мини-ЭВМ, так называемые, Unix-машины, ведущим производителем которых в то время была фирма Digital Equipment. Нововведений семейства IBM System/370 оказалось недостаточно, чтобы сохранить почти монопольное положение на рынке, и именно тогда возникла первая "легенда о смерти мейнфреймов".

Отличие семейства IBM System/370/XA (eXtended Architecture - расширенная архитектура) от предыдущего поколения было достаточно революционным: адресная шина расширилась до 31 бита, что позволило адресовать виртуальную память до 2 Гбайт (при этом сохранилась совместимость и со старыми 24-разрядными моделями). Другим принципиально важным нововведением расширенной архитектуры явилось введение в подсистему ввода-вывода возможности динамического определения пути к устройствам ввода-вывода и поддержка SMP-архитектуры.

2 ОПЕРАЦИОННАЯ СИСТЕМА VSE/ESA

Линия ОС, представляемая сегодня VSE/ESA v.2.6, ориентирована на применение на младших, наименее мощных моделях мейнфреймов. Поэтому ей свойственны более простые решения, запаздывающее внедрение новых свойств аппаратной платформы (в частности, она пока не использует новых возможностей z-архитектуры), отсутствие развитых средств управления производительностью. Хотя имеется много примеров успешного построения промышленных информационных систем на базе VSE, ее основное назначение - поддерживать "унаследованное" программное обеспечение, разработанное для предшествовавших версий аппаратуры и ОС. Программисту, воспитанному на ПЭВМ, это может показаться странным, но в сфере промышленной обработки данных достаточно широко применяется программное обеспечение, разработанное 20 и более лет назад. За столь длительный срок эти программы доказали свою полезность и надежность, и у пользователей нет оснований от них отказываться.

Среда выполнения, которую VSE обеспечивает для приложений, показана на рисунке  1. Эта среда обеспечивается отчасти обязательными компонентами в составе ОС, отчасти - опционными компонентами ОС, отчасти - промежуточным программным обеспечением. Ниже вкратце рассматриваются компоненты, создающие эту среду.

Базовые управляющие средства обеспечиваются обязательным компонентом ОС, который  носит название VSE/AF (Advanced Functions). В состав этого компонента входят: ядро ОС - супервизор, обеспечивающее управление памятью, управление задачами (в терминологии IBM задача означает процесс), базовые функции управления заданиями и базовые функции управления файлами, некоторые системные утилиты и т.д.

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

Аббревиатура VSE расшифровывается как  Virtual Storage Extension - расширение виртуальной памяти. Это название сложилось исторически, но сейчас его нельзя считать вполне точным. Первая ОС этой линии - DOS - работала только с реальной памятью. Реальная память разбивалась на разделы фиксированного размера, и в каждом разделе выполнялась одна задача. В DOS/VSE за счет динамической трансляции адреса System/370 создавалось виртуальное АП размером 16 Мбайт, которое затем разбивалось на разделы фиксированного размера - и для такой модели название VSE является вполне справедливым. Однако, уже в VSE/SP и далее - в VSE/ESA появилась возможность создавать для каждого раздела независимое АП размером 16 Мбайт (а позже - 2 Гбайт). Структура памяти для современных версий VSE представлена на рисунке 4.

Нижняя часть виртуальной памяти - общая для всех разделов, в ней  размещается ядро ОС - супервизор. Выше располагается совместно используемая область виртуальной памяти, которая  содержит программы и данные, доступные  для всех разделов. Другая совместно  используемая область находится  в верхней части 2-Гбайтного АП. Разделение совместно используемой области на две части связано  с переходом от 24-разрядного адреса к 31-разрядному. Унаследованные программы  с 24-разрядной адресацией видят только часть АП до 16 Мбайт, в которой  есть все, что им нужно. Программы  же, созданные с учетом 31-разрядной  адресации, видят все 2 Гбайт АП, в  том числе, и расширение разделяемой  области.

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

В части статических разделов, как  правило, уже при старте системы  запускаются системные задачи. Так, в разделе 0, который называется BG, обычно запускается задача связи  с оператором - BG; в разделе 1 - задача POWER и т.д. Разделы этих задач, выполняющих  обязательное общесистемное обслуживание, обычно (но не обязательно) размещаются  в общей части АП, как показано на рисунке 2.

2.2 Управление задачами

Единицей работы в ОС является задание (job). Задание состоит в последовательном выполнении нескольких шагов-задач (task) - программ (в частном случае задание может состоять из единственного шага). Задание характеризуется классом (буква) и приоритетом (число). Для каждого раздела оператором задаются классы заданий, выполняемых в разделе, и приоритет класса в разделе. Задания одного класса выбираются на выполнение в соответствии с числовым приоритетом, а при равенстве приоритетов - в порядке поступления. Классы и приоритеты заданий определяют порядок, в котором задания выбираются на выполнение, но не дисциплину распределения процессорного времени.

2.3 Файловая система

Сочетание структуры файлов на внешней  памяти и способов обработки файлов в программе составляет метод  доступа. В VSE/ESA применяются две группы методов доступа: базисные методы - BAM, "унаследованные" от старых версий и виртуальный последовательный метод - VSAM (применяемый также и  в z/OS как единственная для этой ОС структура файловой системы). Обычно при инсталляции VSE создаются два  дисковых тома. На этих томах устанавливаются  системные файлы и библиотеки, но также остается место и для  пользовательских файлов. Первичное  управление дисковым пространством  выполняется средствами BAM. На каждом диске выделяется пространство - область VSAM. С точки зрения BAM, вся эта область представляется как один файл, но внутри этого файла средства VSAM обеспечивают собственное управление дисковым пространством и создание VSAM-файлов.

В начале каждого диска находится  метка тома (VOL1), содержащая имя тома и указатель на размещение оглавления тома. Оглавление тома - структура VTOC - содержит информацию о размещении на томе BAM-файлов. Средства BAM фактически перекладывают управление дисковым пространством на программиста: при  создании файла программист должен явным образом указать физический адрес файла на диске и его  размер. Это выполняется средствами языка управления заданиями: после  оператора // DLBL, относящегося к создаваемому файлу должен следовать один или несколько операторов // EXTENT, задающих адреса и размеры участков файла. BAM-файл располагается в одном или нескольких (до 16) непрерывных участках дискового пространства. Дисковое пространство выделяется сразу при создании файла и не может быть перераспределено в дальнейшем. Элемент VTOC для каждого файла содержит его имя и до 16 пар "адрес-размер" для каждого участка. - Утилита VTOC помогает программисту вести карту распределения дискового пространства.

3 ОПЕРАЦИОННАЯ СИСТЕМА Z/OS

z/OS (раньше - OS/390, еще раньше - MVS) является  стратегической для IBM ОС мейнфреймов. Именно в этой ОС в первую очередь осваиваются новые свойства аппаратной платформы, именно в этой ОС в первую очередь становятся доступными новые версии стратегических продуктов промежуточного программного обеспечения, именно эта ОС рассчитана на применение в самых мощных и производительных вычислительных комплексах и sysplex'ах (тесно связанных многомашинных комплексах, которые "выглядят" с точки зрения управления и распределения нагрузки как одна вычислительная система). Последняя на сегодняшний день версия этой ОС - z/OS V1R3.

ОС OS/360 MVT, находившаяся "у истоков" этой линии, работала только с реальной памятью, создавая в ней динамические разделы по мере необходимости. В ОС MVS сложились концепции управления виртуальной памятью и другими основными ресурсами, оставшиеся в принципе неизменными и до настоящего времени. Переименование системы в OS/390 было связано с интеграцией в систему ряда программных серверов, ранее существовавших в виде отдельных программных продуктов, а в z/OS - с адаптацией к 64-разрядной z-архитектуре. Длительная история эволюционного развития MVS - OS/390 - z/OS привела к тому, что на сегодняшний день z/OS является системой настолько сложной и богатой возможностями, что описать их все даже на структурном уровне - задача невыполнимая в объеме одной книги. Тем не менее, мы попытаемся (ни в коей мере не претендуя на полноту) дать читателю некоторое представление о компонентах управления теми ресурсами, которые являются предметом нашего основного внимания.

Примерная структура системного программного обеспечения в составе z/OS показана на рисунке 3.

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

1. новый управляющий сервис разрабатывается и внедряется как отдельный программный продукт, продаваемый отдельно от ОС;
2. новый программный продукт включается в комплект поставки ОС;
3. новый продукт интегрируется с ядром ОС, возможно, становится частью ядра.

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

Управление памятью является, возможно, самым интересным свойством z/OS. Аббревиатура первого названия ОС - MVS расшифровывается как Multiply Virtual Storage и отражает именно аспект управления памятью. Каждая задача в MVS (и в ее современных наследниках) обладает собственным виртуальным АП. Размер этого АП составлял 16 Мбайт в ранних версиях ОС (24-битный адрес), 2 Гбайта, начиная с MVS/XA (31-битный адрес) и 16 эксабайт в z/OS (64-битный адрес). Мы рассмотрим сначала первые две модели адресации, а затем отдельно расскажем об "освоении" системой 64-битного адреса.

Распределение виртуального АП для 24- и 31-битого размера адреса показано на рисунке 4.

z/OS предоставляет также приложениям  возможности использовать дополнительные  АП. Хотя реализации всех этих  возможностей используют описанные  выше регистры доступа AR, с  точки зрения приложений их  можно разделить на 4 направления: 

• коммуникации "пересечения памяти" (cross memory communications);
• явное использование дополнительных АП (AR ACS mode);
• пространства данных (data spaces);
• гиперпространства (hiperspaces).

3.2 Управление процессами

АП в z/OS создается для задания. Как и в VSE, задание в z/OS состоит  из нескольких последовательно выполняющихся  программ - шагов задания. Для каждого  шага задания создается задача (процесс). Структурой, представляющей задачу в  системе, является блок управления задачей TCB (Task Control Block). Задача может порождать новые задачи (подзадачи) при помощи системных вызовов ATTACH (подзадача выполняется в первичном режиме AR) или ATTACHX (подзадача выполняется в режиме ASC AR). Порождаемые таким образом подзадачи имеют собственные блоки TCB и, таким образом, представляются как полноценные задачи, но все они выполняются в том же АП, что и породившая их задача. Порожденная подзадача выполняется параллельно с породившей и может порождать собственные подзадачи. Между задачей и ее подзадачами устанавливаются отношения "предок - потомок". Задача и ее подзадачи выполняются асинхронно, но выполнение задачи-предка может быть и синхронизировано с завершением задачи-потомка. Подзадача может порождаться с параметрами ECB или/и EXTR. Первый параметр назначает для подзадачи Блок Управления Событием (Event Control Block), в котором делается отметка о завершении подзадачи. Если подзадача создается с параметром ECB, ее TCB не удаляется с ее завершением, а сохраняется до тех пор, пока информация о завершении не будет востребована задачей-предком. Задача-предок может ожидать завершения потомка и получить информацию о его завершении, применяя системный вызов WAIT, параметром которого является ECB потомка. Параметр EXTR позволяет определить в задаче-предке процедуру, которая автоматически выполняется при завершении данного потомка.

3.3 Средства взаимодействия

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

Для взаимного исключения доступа  к ресурсам из разных программ используются системные вызовы ENQ и DEQ. В первом приближении их можно считать эквивалентным семафорным операциям P и V соответственно. При употреблении этих системных вызовов задается имя ресурса и масштаб. Имя (оно состоит из двух частей) в документации IBM называется именем ресурса, но на самом деле это скорее имя семафора, имена в операциях ENQ/DEQ назначаются произвольно и не имеют никакой связи с действительными именами ресурсов.

4 ОПЕРАЦИОННАЯ СИСТЕМА Z/VM

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

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

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

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

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

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

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

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

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

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

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

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

4.4 CMS

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

4.1 Файловые системы 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К групп памяти, группы могут добавляться к файловому пулу. Размер всех групп памяти одинаков, группа состоит из нескольких минидисков, желательно - находящихся на разных реальных дисках.

4.2 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 приложениям в гетерогенной распределенной среде.

4.3 GCS

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

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

ЗАКЛЮЧЕНИЕ

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