Эволюция z/OS

MVS/370 (Multiple Virtual Storage/370)

В соответствии с концепцией MVS, каждая прикладная программа, выполняющаяся на платформе S/370, получает в свое распоряжение виртуальное адресное пространство объемом 16 MB, что существенно увеличивает объем доступной приложению памяти по сравнению с SVS. Это означает также, что может быть увеличено количество одновременно выполняемых приложений. Кроме того, наличие раздельных адресных пространств повышает степень безопасности программ и пользователей, поскольку приложение, работающее в одном адресном пространстве, не имеет возможности (преднамеренно или нет) напрямую обратиться к памяти в других адресных пространствах. Однако в некоторых случаях приложения нуждаются во взаимодействии, когда они обмениваются данными или используют одни и те же общие программы. В MVS/370 для этой цели в каждом виртуальном адресном пространстве была выделена так называемая общая область (common area), в которой резервировалось место для размещения программ (предназначенных в основном для поддержки системных сервисов) и данных, доступных всем приложениям. Остальная часть адресного пространства, защищенная от других приложений, названа приватной областью (private area) (рис. 5.2).

Для того чтобы не расширять объем общей области (и, стало быть, не сокращать объем приватной), для некоторых системных программ MVS выделяются отдельные виртуальные адресные пространства. Для организации взаимодействия с такими программами, а также для взаимодействия между обычными приложениями в архитектуре S/370 был реализован альтернативный механизм межпространственной связи CMF (Cross Memory Facility). Этот механизм основан на специальных процессорных командах, с помощью которых можно передавать данные из одного адресного пространства в другое, а также запускать процедуры из других адресных пространств. При этом используются встроенные средства обеспечения безопасности на основе средств авторизации.

MVS/XA (Multiple Virtual Storage/eXtended Architecture)

К концу 70-х предел в 16 MB для приложений становился все более заметным ограничивающим фактором. Переход на архитектуру S/370-XA (eXtended Architecture) обеспечил расширение разрядности адреса до 31 бит, что дало возможность в новой версии операционной системы MVS/XA (1983) создавать виртуальные адресные пространства размером 2³¹ = 2 GB (рис. 5.3). Этот объем виртуальной памяти, выделяемый приложению, применялся вплоть до перехода на 64-разрядную архитектуру zSeries (z/Architecture).

Для сохранения преемственности структура виртуального адресного пространства MVS/XA в младших 16 MB осталась прежней. Свыше границы 16 MB (как стали говорить "above line" - "над линией") появились расширенная общая область (Extended Common Area), как продолжение общей области MVS/370, и расширенная приватная область (Extended Private Area), дающая дополнительное жизненное пространство для 31-разрядных приложений. Механизм межпространственной связи (CMF) был адаптирован к новому формату адресных пространств.

Следует отметить, что для поддержки "старых" приложений, разработанных для MVS/370, в MVS/XA была сохранена возможность переключения в режим 24-разрядной адресации. В этом случае приложения могли использовать по-прежнему только 16-мегабайтную область адресного пространства.

MVS/ESA (Multiple Virtual Storage/Enterprise System Architecture)

Появление архитектуры ESA/370 в 1988 году привело к созданию операционной системы для этой платформы, получившей название MVS/ESA. Основные нововведения в этой версии были связаны с использованием расширенной памяти (expanded storage), впервые реализованной в системе ES/3090 в 1985 году. Расширенная память, являясь фактически продолжением основной (центральной) памяти, стала использоваться для хранения вытесненных из основной памяти страниц, что позволило существенно уменьшить время на страничный обмен по сравнению с применением для этой цели дисковой памяти. Расширенная память адресуется поблочно (размер блока - 4 KB). Объем расширенной памяти мог достигать 8 GB, в то время как основная память была по-прежнему ограничена 2 GB.

В MVS/ESA появились виртуальные адресные пространства нового типа: пространства данных (Data Spaces) и гиперпространства (от HIgh PERformance Spaces - "высокопроизводительные пространства"). Общая схема адресных пространств MVS/ESA представлена на рис. 5.4. Практически в таком виде эта схема сохранилась в последующих версиях MVS и OS/390 и легла в основу построения z/OS.

Пространства данных могут иметь размер от 4 KB до 2 GB и адресуются побайтно. Они могут создаваться приложениями для размещения данных произвольного типа и доступа к этим данным в процессе выполнения. В отличие от обычных адресных пространств, в пространствах данных не могут размещаться и исполняться программные коды. Для доступа к данным, размещенным в пространствах данных, в архитектуре ESA/370 в качестве базовых регистров применяются специальные регистры доступа (AR), что позволяет приложениям одновременно взаимодействовать с несколькими пространствами данных (до 16), используя стандартные процессорные команды. Следует отметить, что в MVS/ESA появились пространства данных, создаваемые для нужд операционной системы и используемые специальными системными программами, такими как VLF, LLA, DLF и др.

Гиперпространства представляют собой разновидность пространств данных, но с некоторыми специфическими чертами. Главная особенность заключается в том, что данные из гиперпространств могут вытесняться только в расширенную память (никогда во внешнюю!), что обеспечивает повышение производительности при их обработке. Память гиперпространств адресуется поблочно (размер блока 4 KB).

MVS/ESA SP V4 (Multiple Virtual Storage/Enterprise System Architecture, System Product Version 4)

Очередной вехой в развитии технологии MVS стало появление четвертой версии операционной системы MVS/ESA в 1990 году, ориентированной на архитектуру ESA/390 (ES/9000). Основные изменения системного программного обеспечения были связаны с появлением ESCON-каналов и внедрением элементов технологии сисплекс (Sysplex) для построения многомашинных комплексов. В связи с этим появились новые компоненты и функции, такие как XCF (Cross System Coupling Facility) для управления ресурсами в многомашинной среде, APPC (Advanced Program-to-Program Communications) для организации взаимодействия приложений в распределенной системе на базе протокола APPN. Кроме того, была произведена модернизация стандартных функций MVS для работы в сисплексе.

Механизм управления памятью продолжал совершенствоваться за счет внедрения новых алгоритмов страничного обмена (например, был реализован блочный обмен (block paging)), более надежных методов защиты и распределения рабочей нагрузки. В третьем выпуске MVS/ESA SP V4 был сделан первый шаг в сторону интеграции MVS и UNIX и вступления MVS в сообщество открытых систем: реализована поддержка интерфейса прикладного программирования (API) для C/C++ приложений в соответствии с международным стандартом IEEE POSIX 1003.2 (Portable Operating System Interfaces UNIX).

MVS/ESA SP V5 (Multiple Virtual Storage/Enterprise System Architecture, System Product Version 5)

Пятая версия MVS/ESA была выпущена в 1994 году, она предназначалась для установки на серверы 9672 (Parallel Enterprise Server). Данная версия обеспечивала полную поддержку технологии параллельного сисплекса (Parallel Sysplex). В ней впервые был представлен модуль управления рабочей нагрузкой WLM (WorkLoad Manager), дающий возможность рационального распределения системных ресурсов между приложениями на основе сформулированных целей функционирования.

В релизе 2.2 были существенно расширены возможности UNIX-сервиса, получившего в то время название Open Edition ("открытая редакция"). Это название подчеркивало полную поддержку возможностей стандарта открытых систем X/Open Portability Guide, принятого многими разработчиками UNIX-систем. Данный стандарт унифицирует набор функций интерфейса системных вызовов (API) и интерфейс пользователя (shell) для переноса программного обеспечения и повышения мобильности пользователей открытых систем независимо от платформы. Таким образом, в MVS была интегрирована пользовательская оболочка shell UNIX, реализована поддержка иерархической файловой системы UNIX и стало возможным использование приложений на языке С/С++, написанных для UNIX-компьютеров. Одновременно в рамках UNIX-сервиса были представлены компоненты для поддержки распределенных вычислений на основе стандарта DCE (Distributed Computing Environment).

Для повышения эффективности обработки пакетных заданий при обработке последовательных наборов данных был введен компонент BatchPipes/MVS и применена технология Hiperbatch.

Значительные изменения коснулись коммуникационных сервисов. eNetwork Communication Server объединил средства поддержки вычислительных сетей на базе двух протоколов: SNA и TCP/IP. Для доступа пользователей локальной сети NetWare к ресурсам S/390 добавлен компонент LANRES, а для реализации функций файл-сервера для пользователей, использующих рабочие станции OS/2, DOS, Windows, UNIX-компонент LAN Server for MVS.

OS/390

Появление OS/390 в 1995 году означало коренное изменение принципов построения архитектуры операционной системы по сравнению с предшествующими версиями. MVS/ESA SP рассматривалась как совокупность программных продуктов (компонентов), каждый из которых распространялся, устанавливался и обслуживался отдельно от других. К тому же продукты имели различные циклы обновления версий, что не только вызывало проблемы при сопровождении системы, но и снижало общий уровень надежности ее работы.

В основу OS/390 легла концепция интеграции всех ее компонентов, которые, во-первых, разрабатываются и тестируются как единый программный комплекс и, во-вторых, поставляются покупателям в виде единого пакета. Все множество компонентов системы делится на две категории - базовые и опциональные. Базовые компоненты (base elements) обеспечивают поддержку основных системных функций и являются обязательными в любой конфигурации OS/390. Дополнительные возможности системы представлены в виде опциональных компонентов (optional features), необходимость присутствия которых в той или иной конфигурации определяется заказчиком. Таким образом, при планировании закупки OS/390 существует возможность оплатить только необходимые компоненты в составе пакета (все базовые и некоторые опциональные), потеряв, таким образом, возможность использовать остальные. Однако в дальнейшем при необходимости можно активизировать отключенные опциональные компоненты, оплатив заказ и выполнив предусмотренную IBM стандартную процедуру "динамического включения" (dynamic enablement).

Представленная архитектура и установленная технология поставки существенно облегчают процесс инсталляции и сопровождения операционной системы. Обновления для всех компонентов, а также новые компоненты каждые полгода выпускались IBM в виде нового релиза OS/390. Первые три релиза вышли в первой версии (OS/390 V1 R1-R3), остальные - во второй (OS/390 V2 R4-R10).

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

Подробно сервисы и компоненты OS/390 будут рассмотрены далее в настоящей главе, поскольку большая часть из них полностью или с небольшими изменениями вошла в состав z/OS.

OS/390 может использоваться для установки на все модели S/390 Parallel Enterprise Server G5 и G6, IBM ES/9000 Processor Unit 9021 и 9121, S/390 Multiprise 2000 и Multiprise 3000 Enterprise Server, а также на серверы z900 (только V2R6 и старше), и поддерживает 24-разрядный и 31-разрядный режимы адресации MVS. Отметим, что версия OS/390 V2R10 при установке на серверы z900 поддерживает также 64-разрядный режим адресации и играет особую роль при переходе на операционную систему z/OS, о чем пойдет речь ниже.

z/OS

z/OS - новая операционная система семейства MVS, выпущенная в октябре 2000 года для поддержки 64-разрядной архитектуры (z/Architecture) на платформе zSeries (z900, z990, z800 и др.). Размер адресуемой памяти в z/OS достиг 2⁶⁴=16 EB (экзабайт), что дает возможность выделить приложениям соответствующее виртуальное адресное пространство, а также увеличить объем основной памяти (в z900 можно использовать до 64 GB). Расширенная память в 64-разрядном режиме z/OS не поддерживается, в ней нет необходимости, так как для снижения интенсивности страничного обмена теперь можно просто увеличить объем основной памяти. Для обеспечения преемственности сохранена полная поддержка "старых" 31- и 24-разрядных приложений, в том числе заложена возможность для их взаимодействия с 64-разрядными приложениями. В режиме 31-разрядной адресации z/OS можно использовать на платформах S/390 Parallel Enterprise Server G5/G6 и S/390 Multiprise 3000 Enterprise Server.

Следует отметить, что в первых выпусках z/OS шло постепенное развитие и расширение возможностей 64-разрядной адресации. Это касалось как базовых механизмов и отдельных функциональных компонентов операционной системы, так и языковых компиляторов и средств разработки приложений. Параллельно шла модернизация систем промежуточного слоя (например, СУБД DB2, Websphere Application Server и др.), ориентированных на платформу zSeries.

В первом выпуске z/OS V1R1 (Version 1 Release 1) 64-разрядная адресация была реализована только для обращения к физической памяти, а виртуальное адресное пространство по-прежнему ограничивалось 2 GB. Во втором выпуске z/OS V1R2 у приложений появилась возможность использовать виртуальную память свыше 2 GB для размещения данных (но не программных кодов!). Сказанное относится в том числе и к 31-разрядным приложениям, поскольку изменились (стали 64-разрядными) соответствующие системные функции. Кроме того, в данном релизе появилась возможность разрабатывать 64-разрядные приложения на языке ассемблера (High Level Assembler), а также на языках высокого уровня. В наиболее полном виде возможности 64-разрядной адресации при использовании виртуальной памяти были реализованы в версии z/OS V1R4, вышедшей в 2003 году.

Что касается архитектуры, то операционная система z/OS сохранила основные принципы организации и большинство компонентов, использованных в OS/390. Изменения коснулись функциональности отдельных модулей системы, но главное, что следует отметить, это появление новых важных компонентов:

С 2002 года в рамках семейства операционных систем z/OS выпускается специальная версия под названием z/OS.e, предназначенная для установки только на серверы серии z800. Сохраняя базовые возможности и преимущества z/OS, z/OS.e ориентирована на поддержку информационных систем электронного бизнеса, построенных исключительно на Internet-протоколах и технологиях Websphere Application Server и DB2 и использующих приложения, написанные только на языках Java и C/C++. Выбор z/OS.e является экономичным решением для многих бизнес-приложений.

В ответ на пожелания пользователей периодичность выпуска новых релизов z/OS и z/OS.e была увеличена по сравнению с OS/390 с 6 до 12 месяцев, что позволило снизить затраты на проведение обновления.

Рекомендации по переходу на z/OS

Для организаций, использующих большие серверы IBM, чрезвычайно актуальной является проблема перехода с платформы G5/G6, работающей под управлением OS/390, на серверы zSeries и операционную систему z/OS. IBM рекомендует плавную пошаговую процедуру перехода, в основе которой лежит принцип: при смене платформы сохранять некоторое время старую операционную систему, а замену операционной системы производить на старой платформе , , . Во всех случаях перед установкой z/OS рекомендуется сначала установить OS/390 V2R10 для более плавной и безболезненной миграции. Дело в том, что IBM выпускает специальный пакет обновления z/OS V1R1 Upgrade Package (PUP) для OS/390 V2R10, позволяющий произвести обновление автоматически.

На рис. 5.5 представлены два основных варианта перехода при стартовой позиции А (G5/G6+OS/390 R6-R9). Первый вариант включает шаги A-B-D-G, где сначала производится последовательное обновление операционной системы до z/OS на "старой" платформе G5/G6. Во втором варианте (шаги A-C-E-(F)-G) предлагается сначала обновить сервер, а затем приспосабливать к нему операционную систему, возможно, с включением 64-разрядного режима в OS/390 R10 (F).

Сосуществование версий OS/390 и z/OS

Проблема сосуществования версий заключается в возможности использования различных версий операционной системы в мультисистемных конфигурациях с разделением общих ресурсов, таких как LPAR и Parallel Sysplex. Обычная практика компании IBM заключается в поддержке сосуществования на уровне четырех последовательных релизов. Однако в период перехода к z/OS это правило нарушается для создания более благоприятных условий для такого перехода (таблица 5.2). Так, например, z/OS V1R1 может взаимодействовать со всеми релизами OS/390 второй версии (V2R6-V2R10). Начиная с z/OS V1R5, возобновляется действие ограничения сосуществования в рамках четырех релизов и, таким образом, из списка исключается последний выпуск OS/390.