Эволюция z/OS

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

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

Пакетное задание (batch job) - внешняя единица работы z/OS. Выглядит как текст, написанный на специальном языке управления заданиями JCL (Job Control Language), в котором указано, какие программы (загрузочные модули), в какой последовательности и с какими данными должны быть исполнены в рамках задания. Задания формируются и направляются в систему пользователями через терминальные устройства, консоли, ранее запущенные программы и т.п.

Адресное пространство (address space) - совокупность ячеек виртуальной памяти, выделяемой под размещение кода и данных принятой к выполнению программы. В z/OS включает также вспомогательные системные таблицы и код. Программа до начала выполнения должна либо размещаться в собственном адресном пространстве, либо получить место в "чужом".

Задача (task) - внутренняя единица работы z/OS. Любая программа может быть представлена программистом как совокупность задач - фрагментов кода, которые могут выполняться параллельно, получая кванты процессорного времени независимо от других задач. Если задание состоит из последовательности вызываемых на выполнение программ, то программа состоит из множества (как минимум - одной) параллельно выполняемых задач. Синонимом задачи в других операционных системах (Windows, UNIX) является термин "поток" (thread).

Набор данных (data set) - термин, означающий именованную совокупность связанных элементов данных, размещаемых во внешней памяти или иных устройствах. Для большинства читателей это не что иное, как файл.

MVS/370 (Multiple Virtual Storage/370)

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

Рис. 5.2. Виртуальные адресные пространства MVS/370

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

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.

Рис. 5.4. Виртуальные адресные пространства MVS/ESA

Пространства данных могут иметь размер от 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.

MVS/XA (Multiple Virtual Storage/eXtended Architecture)

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

Рис. 5.3. Виртуальные адресные пространства MVS/XA

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

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

в 1995 году означало коренное

Появление 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 сервисов можно выделить:

системный сервис: базовые функции операционной системы;коммуникационный сервис: сетевое взаимодействие с пользователями и устройствами в гетерогенной вычислительной среде на базе протоколов SNA и TCP/IP;LAN-сервис: функции сервера данных и печати в локальных вычислительных сетях;разработка приложений (application enablement): поддержка объектной технологии и графического интерфейса для конечных пользователей;UNIX-сервис: полная поддержка приложений и пользовательской среды UNIX в рамках стандарта открытых систем XPG4.2;сервис распределенных вычислений: поддержка приложений и управление данными в распределенных вычислительных системах на основе промышленного стандарта DCE;Web-сервис: поддержка http-сервера и сервера приложений Java;сервис безопасности: авторизация пользователей, защита системных ресурсов, сетевая безопасность, криптография.

Подробно сервисы и компоненты 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 связана в первую очередь с изменениями, которые касаются методов управления основной памятью. В период "младенчества", связанный с платформой S/360, операционные системы использовали технологию распределения памяти между параллельно выполняющимися программами на основе прямого "деления" физической памяти (OS/MFT и OS/MVT).

В начале 70-х годов, с появлением новой модели S/370, произошел переход на технологию виртуальной памяти. Концепция виртуальной памяти обеспечивает более эффективное использование основной памяти ЭВМ благодаря реализации следующих принципов:

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

Первой ласточкой, возвестившей в 1972 году эпоху виртуальной памяти, стала операционная система Virtual Storage 2 (OS/VS2), более известная сегодня как SVS (Single Virtual Storage). SVS обеспечивала поддержку единого виртуального адресного пространства размером 16 MB (при 24-разрядной адресации) для всех параллельно работающих программ. При этом реальный объем физической памяти мэйнфрейма в то время едва мог достигать 1-2 MB.

В 1974 году SVS уступила место операционной системе MVS (Multiple Virtual Storage), в которой были реализованы архитектурные принципы, на десятилетия определившие направление развития операционных систем и сохранившиеся с некоторыми изменениями в современных системах OS/390 и z/OS. Поэтому имеет смысл более подробно рассмотреть основные этапы развития технологии MVS [1].

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

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

Таблица 5.2. Допустимые варианты сосуществования версий OS/390 и z/OS

z/OS	OS/390					z/OS
z/OS	V2R6	V2R7	V2R8	V2R9	V2R10	V1R1	V1R2	V1R3	V1R4	V1R5
V1R1	+	+	+	+	+	+	-	-	-	-
V1R2	-	-	+	+	+	+	+	-	-	-
V1R3	-	-	-	+	+	+	+	+	-	-
V1R4	-	-	-	-	+	+	+	+	+	-
V1R5	-	-	-	-	-	-	+	+	+	+

Z/OS

z/OS - новая операционная система семейства MVS, выпущенная в октябре 2000 года для поддержки 64-разрядной архитектуры (z/Architecture) на платформе zSeries (z900, z990, z800 и др.). Размер адресуемой памяти в z/OS достиг 264=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. Изменения коснулись функциональности отдельных модулей системы, но главное, что следует отметить, это появление новых важных компонентов:

менеджера ресурсов Intelligent Resource Director (IRD) для динамического управления ресурсами в режиме LPAR с учетом рабочей нагрузки;msys for Setup - мастера по установке и конфигурированию z/OS и ее компонентов, использующий графический диалоговый интерфейс;менеджера лицензий IBM License Manager (ILM), обеспечивающего удобный интерфейс для управления лицензиями на программные продукты на основе стратегии ценообразования IBM Workload License Charges и упрощающего постепенное наращивание возможностей системы.

С 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

Ориентация на поддержку систем электронного бизнеса на базе технологии "клиент-сервер" определила взгляд на функциональную структуру z/OS как совокупность модулей, каждый из которых обеспечивает реализацию сервисов определенного типа и включает некоторую совокупность базовых и опциональных элементов. В составе z/OS выделено 10 функциональных модулей, показанных на рис. 5.6.

Рис. 5.6. Функциональная структура z/OS

Базовые системные функции и средства представлены тремя модулями:

системные сервисы;сервисы администрирования и управления системой;системные сервисы UNIX.

Элементы этих модулей создают основу для функционирования остальных модулей системы, которые в свою очередь связаны со вспомогательными сервисами и с поддержкой ключевых технологий современных информационных систем, включая коммуникационный сервис, сервис безопасности, Web-сервис и др. Предоставляемая z/OS возможность развертывания вспомогательных сервисов на одной машине и в одной среде обеспечивает снижение расходов на настройку и эксплуатацию программного обеспечения, повышает устойчивость работы и эффективность взаимодействия всех компонентов.

Рассмотрим состав и функции отдельных модулей z/OS, принимая во внимание, что некоторые элементы с таким же успехом можно было бы отнести к другим модулям (т.е. границы модулей условны).

Элементы z/OS

Операционная система z/OS построена в соответствии с концепцией интеграции компонентов, реализованной впервые в OS/390, и включает базовые и опциональные элементы. Данная концепция означает, что все программные компоненты системы разрабатываются и тестируются как единый программный комплекс, а распространение и установка системы производится одним пакетом.

Базовые элементы (base elements) являются необходимой и неотъемлемой частью программного обеспечения z/OS, поскольку служат для поддержки наиболее важных функций и сервисов системы. К ним относятся средства управления аппаратными ресурсами, средства управления данными, пользовательские и программные интерфейсы, поддержка коммуникаций и др. Базовые элементы всегда включаются в установочный пакет z/OS.

Опциональные элементы (optional feature) расширяют возможности базовых элементов и обеспечивают поддержку дополнительных функций операционной системы, таких как, например, средства отладки и библиотеки для языков программирования, некоторые средства администрирования и управления хранением данных, средства защиты, аудита и шифрования и т.п. У заказчика есть возможность выбора необходимой ему совокупности опциональных элементов, которые он оплачивает отдельно. Различают два типа опциональных элементов: интегрированные (в документации определяются как priced) и неинтегрированные (unpriced). Все интегрированные опциональные элементы присутствуют в установочном пакете z/OS, однако доступными для установки и использования будут только элементы, выбранные и оплаченные заказчиком. В дальнейшем всегда существует возможность активизировать не заказанные ранее опциональные элементы на основе процедуры динамического включения (dynamic enablement) без необходимости обновления установочного пакета. Неинтегрированные опциональные элементы не входят в установочный пакет z/OS и требуют отдельного заказа и специальной установки.

Следует отметить, что z/OS включает ряд компонентов, которые в то же время либо существуют и распространяются как самостоятельные программные продукты, либо входят в состав других операционных систем (например, z/VM). Такие элементы называют неэксклюзивными (nonexclusive). К ним относятся ассемблер HLASM и связанные с ним инструментальные средства, графические библиотеки и утилиты GDDM, средства создания и просмотра документов в формате BookManager и некоторые другие. Остальные элементы, доступные только в составе z/OS, называют эксклюзивными (exclusive).

Обновляя версии и выпуская новые релизы системы, разработчики вносят постоянные изменения в состав, функции и статус тех или иных элементов. К счастью, эти изменения не столь радикальны и касаются, как правило, лишь небольшого числа компонентов. Это обеспечивает плавность перехода на новые версии, но не избавляет пользователей от необходимости внимательно изучать новшества и изменения, связанные с таким переходом. Приводимый далее обзор функциональной структуры и элементов z/OS дается в соответствии со спецификацией релиза V1R4 [3]. Полный перечень элементов z/OS V1R4 и z/OS.e V1R4 представлен в приложении 3.

Коммуникационные сервисы

Данная группа сервисов содержит средства интеграции компьютеров zSeries в распределенные многомашинные вычислительные системы на базе современных сетевых протоколов. Базовый элемент z/OS коммуникационный сервер (Communications Server) обеспечивает защищенную поддержку основных коммуникационных решений для корпоративных сетей и включает два сервиса: IP и SNA.

Сервис IP предназначен для реализации взаимодействия на базе широко распространенного сегодня благодаря Internet протокола TCP/IP. В рамках IP-сервиса, помимо базовых средств передачи данных, поддерживаются все важнейшие протоколы прикладного уровня, включая Telnet, FTP, SMTP, RPC и др. На основе TCP/IP функционируют и некоторые другие сервисы z/OS (например, сервис поддержки электронного бизнеса), а также различные системы промежуточного слоя, такие как CICS, IMS, Websphere и др.

Сервис SNA предназначен для поддержки вычислительных сетей, построенных на базе разработанного IBM стандарта SNA (System Network Architecture), известного ранее как виртуальный телекоммуникационный метод доступа VTAM. В рамках данного стандарта реализован протокол APPN (Advanced Peer-to-Peer Networking), обеспечивающий интерфейс между приложениями хоста и ресурсами сети SNA и связывающий пользователей сети. В рамках SNA реализована технология AnyNet (известная также по названием MPTN - multiprotocol transport networking), обеспечивающая прозрачное взаимодействие пользователей и приложений, находящихся в сегментах сети, использующих различные протоколы (IP и SNA). Так, например, приложения SNA без каких-либо изменений могут обмениваться данными и управлять удаленными устройствами через IP-сеть (режим AnyNet SNA over IP). В то же время приложения, использующие функции библиотеки IP сокетов (С socket API), могут взаимодействовать между собой через сеть SNA/APPN (режим Sockets over SNA), а также получать простой и быстрый доступ к ее ресурсам.

Оба коммуникационных сервиса могут использовать встроенные средства шифрования данных на основе 56-разрядного алгоритма DES. Для расширения возможностей шифрования в составе z/OS предусмотрен опциональный неинтегрированный компонент Communications Server Security Level 3, использующий 64-разрядные ключи и алгоритм TDES.

Кроме сервисов IP и SNA, коммуникационный сервер поддерживает функции управления сетевой печатью (Communications Server NPF (Network Print Facility)), а также некоторые функции сетевой защиты на базе технологии Firewall, включая фильтрацию IP-пакетов, трансляцию адресов (NAT), виртуальные сети (VPN).

Вторым базовым элементом коммуникационных сервисов является средство поддержки OSA (OSA Support Facility (OSA/SF)). OSA/SF обеспечивает дружественный интерфейс для контроля состояния адаптеров OSA (OSA Express и OSA-2) - аппаратуры сетевого взаимодействия с устройствами IP и SNA/APPN сетей на базе различных протоколов (Gigabit, Token Ring, Ethernet/Fast Ethernet, ATM, FDDI и др.).

Более подробно коммуникационные сервисы рассмотрены в главе 4.

Сервис электронных публикаций

Для создания и распространения электронных документов IBM использует собственный формат, получивший название BookManager по имени семейства соответствующих программных продуктов. В составе z/OS представлен полный комплект электронной документации в указанном формате, а также три компонента для работы с ней:

BookManager BUILD - опциональный элемент, служащий для создания электронных документов в формате IBM BookManager;BookManager READ - базовый элемент, служащий для просмотра электронных документов, поддерживает функции поиска;BookManager BookServer - базовый элемент, преобразующий документы, созданные в формате BookManager, в формат HTML для последующего отображения через Web-браузер.

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

Сервис печати

Для управления печатью и организации сетевого доступа к принтерам z/OS служит опциональный элемент сервер печати Infoprint Server. Сервер печати состоит из следующих компонентов:

Print Interface - принимает запросы вывода на печать от системных сервисов UNIX и от удаленных систем в IP-сети, формирует выходные наборы данных печати в спуле JES2 или JES3 и, наконец, последовательно выводит данные на локальный или удаленный принтер;Windows Client - клиент Windows, используемый для передачи документов и атрибутов заданий серверу печати z/OS;IP Printway - передает наборы данных печати из спула JES2 или JES3 на удаленные принтеры в IP или SNA сети;NetSpool - переадресует потоки вывода на печать, формируемые VTAM-приложениями, и размещает их в спуле JES2 or JES3 для последующей печати.

Сервер печати поддерживает множество различных форматов представления документов, включая PostScript, PCL, ASCII, а при установке дополнительных расширителей - PDF, XML и SAP OTF.

Сервисы администрирования и управления системой

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

Базовый компонент конфигуратор оборудования HCD (Hardware Configuration Definition) предназначен для описания начальной конфигурации, а также динамической реконфигурации аппаратного обеспечения и устройств ввода-вывода. Опциональный элемент HCM (Hardware Configuration Manager) представляет собой дополнение к HCD, позволяющее конфигурировать оборудование с помощью графического пользовательского интерфейса.

Программа модификации системы SMP/E (System Modification Program/Extended) является базовым элементом и представляет собой инструментарий, предназначенный для установки и обновления программных продуктов z/OS, а также инвентаризации установленного программного обеспечения системы.

Ранее отмечалось, что в z/OS V1R1 появился новый компонент msys for Setup (Managed System Infrastructure for Setup) - мастер для настройки параметров z/OS и приложений, выполняемых под z/OS на основе графического интерфейса в стиле Web. Вызов мастера может производиться авторизованными пользователями непосредственно с рабочей станции. Диалог настройки рекомендует пользователю наилучшие сочетания параметров, которые он может изменить, либо согласиться с ними. Обновление параметров осуществляется автоматически. Продолжением и развитием технологии msys стало появление в z/OS V1R2 нового базового компонента msys for Operation, предназначенного для автоматизации решения задач сопровождения и администрирования системы в сисплексе.

Подсистема управления данными DFSMS, упоминавшаяся при рассмотрении системных сервисов, представлена в сервисах администрирования четырьмя опциональными компонентами:

DFSMSdss (data set service) - средства администрирования данных и устройств внешней памяти на магнитных дисках (резервное копирование, восстановление, дефрагментация);DFSMShsm (hierarchical storage manager) - средства оптимизации хранения наборов данных на различных носителях в зависимости от интенсивности использования и обеспечения сохранности данных;DFSMSrmm (removable media manager) - средства управления сменными ленточными и оптическими носителями;DFSMStvs (transactional VSAM service) - поддержка параллельной обработки наборов данных VSAM для пакетных заданий и транзакций CICS.

Следующие два компонента из рассматриваемой группы сервисов относятся к разряду опциональных, однако пользователи редко отказываются от них. Компонент SDSF (System Display and Search Facility), используя диалоговые панели ISPF, обеспечивает контроль и предоставляет информацию о текущем состоянии всех заданий в системе, а также поддерживает средства управления системой с помощью консольных команд. Компонент RMF (Resource Measurement Facility) - менеджер сбора данных о ресурсах - предоставляет диалоговый интерфейс и средства для получения отчетов об использовании любых ресурсов z/OS и о параметрах производительности как в текущий момент, так и за указанный период времени.

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

Сервисы для разработки и поддержки приложений

В состав базового программного обеспечения z/OS входят компиляторы множества высокоуровневых языков программирования (HLL, High Level Languages), включая C, C++, COBOL, Fortran и PL/1, а также два редактора связей для получения загрузочного кода приложений (Linkage Editor и Binder). У разработчиков есть возможность производить компиляцию и редактирование связей как в пакетном, так и в интерактивном режиме, используя интерфейс TSO/ISPF или UNIX shell. В то же время на рынке существуют внешние продукты, позволяющие разрабатывать приложения для z/OS на рабочих станциях с использованием визуального графического интерфейса (например, IBM Visual Age).

Важнейшим базовым элементом, обеспечивающим поддержку универсальной среды выполнения программ, созданных на различных языках программирования, является так называемая языковая среда LE (Language Environment). LE включает единые для всех HLL приложений средства управления запуском и завершением программ, формирования сообщений времени выполнения, распределения памяти, а также обеспечивает универсальный программный интерфейс для взаимодействия "разноязыких" приложений. Кроме того, LE содержит набор общих статических и динамических библиотек, используемых различными HLL-приложениями, а также специфические библиотеки для каждого HLL.

Для разработки быстродействующих и экономичных приложений для платформы zSeries поддерживается высокоуровневый ассемблер HLASM (High Level Assembler), включающий компилятор, макросредства и необходимые библиотеки. Дополнительные инструментальные средства разработки ассемблерных программ, расширяющие возможности HLASM, поставляются вместе с опциональным компонентом HLASM Toolkit. Отметим, что HLASM является неэксклюзивным элементом z/OS, поскольку используется в составе других операционных систем (z/VM, VSE)

Для разработчиков C/C++ приложений z/OS поддерживает специальную среду разработки, включающую компилятор C, компилятор C++, библиотеки классов, набор утилит и средства отладки. Библиотеки классов C++ представлены базовым элементом C++ IBM Open Class Library.
Остальные возможности реализованы с помощью опционального элемента C/C++ with Debug Tool ( с модификацией, не содержащей средств отладки C/C++ without Debug Tool). Все средства разработки C/C++ приложений ориентированы на использование библиотек и сервисов языковой среды Language Environment.

Для создания и использования графических приложений в составе z/OS присутствует базовый элемент, называемый менеджером отображения графических данных GDDM (Graphical Data Display Manager). GDDM представляет собой мощный набор API-функций для создания, отображения и хранения векторных и растровых изображений и шрифтов. GDDM поддерживает вывод на различные графические устройства, включая дисплейные терминалы, принтеры, плоттеры, и содержит соответствующий набор драйверов и служебных утилит. Расширенные возможности по работе с графикой представлены опциональными компонентами GDDM-PGF2 (Presentation Graphics Feature) и GDDM-REXX2.

Более подробно средства разработки приложений будут рассмотрены в п. 5.1.8.

Сервисы поддержки электронного бизнеса

В настоящее время ядро информационных систем в сфере электронного бизнеса строится на основе Web-технологий. z/OS включает в качестве базового элемента масштабируемый высокопроизводительный защищенный HTTP сервер (IBM HTTP Server), обеспечивающий поддержку множества тонких клиентов, использующих стандартные браузеры для доступа к корпоративным данным. Помимо основных функций, IBM HTTP сервер поддерживает протокол SSL, динамический кэш страниц, выполняет функции proxy-сервера, ведет статистику обращений к Web-узлу.

В состав сервисов поддержки электронного бизнеса включен также базовый элемент текстового поиска (Text Search), выполняющий функции поисковой машины для баз данных и Web. Поисковая машина обеспечивает поддержку сложных запросов для различных национальных языков1), использует алгоритмы нечеткого поиска, ранжирует результаты поиска по релевантности. Кроме того, в состав Text Search входит компонент NetQuestion Solution, производящий полнотекстовый поиск документов, хранящихся в операционной системе z/OS.

Сервисы поддержки распределенных вычислений

Сервисы поддержки распределенных вычислений обеспечивают взаимодействие приложений и управление данными в распределенных вычислительных системах на основе промышленного стандарта DCE 1.1 (Distributed Computing Environment). Фактически DCE представляет собой сетевую операционную систему, обслуживающую работу клиент-серверных приложений в гетерогенных средах (включая IP и SNA сети). В составе z/OS в рамках рассматриваемых сервисов представлено три базовых элемента.

Базовые службы DCE (DCE Base Services) предназначены для разработки и поддержки выполнения клиент-серверных приложений и включают:

службу вызова удаленных процедур (RPC, Remote Procedure Call) - взаимные вызовы программ, работающих на различных платформах, в формате вызова локальных процедур;службу каталога (Directory Services) - ведение общего каталога имен всех ресурсов распределенной системы;службу времени (Distributed Time Services) - синхронизация часов на всех узлах распределенной системы;службу безопасности (Security Services) - идентификация и аутентификация пользователей, приложений и узлов распределенной системы.

Служба поддержки распределенных файлов DFS (Distributed File Service) обеспечивает приложениям прозрачный защищенный доступ к файлам, размещенным на различных узлах сети. Фактически DFS объединяет файловые системы различных ОС в единую глобальную файловую систему, доступную для множества пользователей сети. Одним из новшеств z/OS стало появление файловой системы zFS (zSeries File System), которая может быть использована в дополнение к файловой системе HFS UNIX. zFS, используя аналогичную HFS структуру, обеспечивает значительное увеличение производительности и устойчивости к системным сбоям. Кроме того, в рамках DFS реализована поддержка SMB сервера для доступа клиентов ОС Windows к наборам данных z/OS.

Сетевая файловая система NFS (Network File System) выполняет функции файл-сервера для рабочих станций, персональных компьютеров и других авторизованных систем в сети TCP/IP. NFS-сервер дает возможность удаленным пользователям (клиентам) получить доступ к наборам данных z/OS и файлам UNIX-сервиса, которые могут быть смонтированы как часть файловой системы клиента.

Системные сервисы

В состав системных сервисов входит более десятка базовых и опциональных компонентов, обеспечивающих поддержку фундаментальных функций операционной системы и предназначенных в первую очередь для управления ресурсами и организации вычислительного процесса. Наиболее важными среди них являются компоненты BCP, DFSMSdfp, JES2, TSO/E и ISPF, которые, находясь в тесном взаимодействии, определяют основные технологические принципы функционирования z/OS (рис. 5.7).

Рис. 5.7. Взаимодействие базовых элементов системных сервисов z/OS

Центральную роль в системе играет базовая управляющая программа BCP (Base Control Program), являющаяся ядром системных сервисов и z/OS в целом.

Базовая управляющая программа осуществляет:

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

В литературе при описании функций BCP часто используют понятие "супервизор" (supervisor), которое можно считать синонимом базовой управляющей программы. В составе BCP выделен ряд важнейших компонентов, таких как программа конфигурирования ввода-вывода IOCP (I/O Configuration Program), менеджеры управления виртуальной, физической и вспомогательной памятью VSM, RSM, ASM (Virtual, Real, Auxiliary Storage Managers), менеджер управления рабочей нагрузкой WLM (Workload Manager), модуль управления системой (сбора статистики) SMF (System Management Facilities), модуль синхронизации задач GRS (Global Resource Serialization), программа связывания (Binder) и некоторые другие. Познакомиться с большинством этих компонентов нам предстоит в данной главе.

Необходимо отметить, что в базовую управляющую программу z/OS интегрировано ядро системных сервисов UNIX, выполняющее ключевую роль при поддержке приложений и некоторых системных компонентов, ориентированных на эту операционную среду.

Вторым важнейшим элементом системных сервисов является подсистема управления данными DFSMSdfp (Data Facility Storage Management System - data facility product), реализующая базовые функции управления данными, хранящимися во внешней памяти, и устройствами хранения данных. Фактически этот компонент поддерживает необходимые низкоуровневые средства для создания, размещения на носителях и последующей обработки наборов данных. DFSMSdfp является базовым элементом, но в то же время существует еще ряд опциональных компонентов семейства DFSMS, которые будут рассмотрены в разделе, посвященном сервисам системного администрирования. Подробное описание всех средств управления данными и внешней памятью будет представлено в п. 5.1.4.

Для обработки пакетных заданий (напомним, что задание представляет собой внешнюю единицу работы z/OS) служит подсистема управления заданиями JES2 (Job Entry System 2). Этот базовый компонент принимает и регистрирует задания, поступающие в систему от различных источников; осуществляет анализ и формирует очереди заданий, а затем передает задания на выполнение базовой управляющей программе. После завершения выполнения задания и получения результатов от BCP, JES2 формирует отчет по заданию (листинг), передает его пользователю или выводит на печать. Альтернативой JES2 является опциональный компонент JES3, который, в отличие от JES2, может использоваться для централизованного управления заданиями в многомашинной системе. Более подробно о подсистеме управления заданиями будет рассказано в п. 5.1.5.

Для организации взаимодействия с пользователями в составе системных сервисов присутствуют два базовых компонента: TSO/E и ISPF. Система разделения времени TSO/E (Time Sharing Option/Extensions) обеспечивает поддержку интерактивного терминального пользовательского интерфейса в режиме командной строки. TSO/E располагает своей системой команд, позволяющих запускать программы и задания, манипулировать наборами данных, контролировать вычислительный процесс и управлять системой с удаленного терминала. Полноэкранный диалоговый интерфейс пользователя

ISPF (Interactive System Productivity Facility) представляет собой среду для разработки и реализации диалога с пользователем на основе стандарта CUA как в текстовом, так и в графическом режиме. ISPF включает текстовый редактор, утилиты для работы с наборами данных, средства разработки и удаленного запуска программ и заданий, а также другие полезные средства для удобного и эффективного взаимодействия с системой. Многие системные компоненты (WLM, HCD, RACF, RMF и др.) используют интерфейс ISPF для настройки и конфигурирования. Описание элементов поддержки пользовательского интерфейса z/OS будет представлено в п. 5.1.7

Системные сервисы UNIX

Сегодня невозможно представить себе z/OS без встроенных возможностей операционной системы UNIX. Базовый компонент UNIX System Services включает системное ядро UNIX (UNIX System Services Kernel) и прикладные сервисы (UNIX Application Services). Ядро UNIX интегрировано в базовую управляющую программу z/OS и поддерживает интерфейс прикладного программирования (API) для всех UNIX-приложений в соответствии со стандартом XPG 4.2.

Прикладные сервисы UNIX включают поддержку классического пользовательского интерфейса UNIX - командного интерпретатора shell и набора стандартных утилит, благодаря которым пользователь UNIX может получить доступ к ресурсам мэйнфрейма привычным для него способом. Кроме того, поддерживается интерактивный отладчик UNIX, который могут использовать разработчики приложений на языке C.

Подробное описание системных сервисов UNIX и примеры использования прикладных сервисов будут представлены в п. 5.1.6.

Службы безопасности

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

Сервер защиты (Security Server) является опциональным интегрированным элементом, служащим для конфигурирования и управления доступом к ресурсам z/OS, и состоит из следующих компонентов:

Средства управления доступом к ресурсам RACF (Resource Access Control Facility) являются базовым звеном сервера защиты и обеспечивают централизованное управление доступом к ресурсам системы на основе авторизации пользователей и приложений в многомашинных и мультисистемных средах. С помощью RACF администратор осуществляет регистрацию всех пользователей системы, настраивает индивидуальные и групповые права и проводит аудит по использованию тех или иных ресурсов (устройств, данных, системных и прикладных программ).

Средства сетевой защиты (Firewall Technologies) предназначены для обеспечения защиты от внешних атак в IP-сети (совместно с коммуникационным сервером), включая поддержку FTP proxy, демона SOCKS, встроенных процедур шифрования на основе алгоритма DES, интерфейса администратора для настройки и конфигурирования.

Сервер LDAP обеспечивает защищенный доступ пользователей к сетевым приложениям на основе стандарта LDAP (Lightweight Directory Access Protocol). Этот индустриальный стандарт служит для создания и ведения каталога пользователей масштаба предприятия, используемого для получения общей информации о пользователях и их атрибутах при аутентификации. LDAP-сервер применяет компонент System SSL, входящий в состав криптографических сервисов.

Служба сетевой аутентификации (Network Authentication Service) осуществляет аутентификацию пользователей на основе стандарта Kerberos Version 5, с использованием криптографических ключей.
Включает программный интерфейс API, известный пользователям Internet под названием GSS-API.

Сервер защиты DCE (DCE Security Server) служит для аутентификации пользователей и серверов сети при использовании клиент-серверных приложений в распределенных системах на основе тесной интеграции с RACF.

Служба PKI (Public Key Infrastructure Services) служит для создания инфраструктуры общих ключей и авторизации сертификатов для внешних и внутренних пользователей на основе Web-интерфейса.

Дополнительные криптографические модули OCEP (Open Cryptographic Enhanced Plug-ins) реализуют прикладной интерфейс (API) для управления серверными сертификатами и защиты серверных ключей.

Отметим, что сервер LDAP, служба сетевой аутентификации, служба PKI и OCEP являются частью базового программного обеспечения z/OS и не требуют специального заказа и установки сервера защиты. В качестве опционального элемента, расширяющего возможности шифрования данных на основе 64-разрядных ключей и алгоритма TDES для службы сетевой аутентификации в состав z/OS входит Security Server Network Authentication Security Level 3.

Криптографические сервисы (Cryptographic Services) являются базовым элементом z/OS. С их помощью реализуют различные методы шифрования данных для обеспечения защиты хранящейся в системе и передаваемой по сети информации от несанкционированного использования. Криптографические сервисы в базовой конфигурации не поддерживают ключи размером более 56 бит и включают следующие компоненты: ICSF, OCSF и System SSL.

Опциональный компонент OCSF Security Level 3 расширяет стандартные возможности шифрования данных за счет использования 64-разрядных битных ключей и алгоритмов TDES, DES, RC2/RC4/RC5.

Опциональный компонент System SSL Security Level 3 обеспечивает конфиденциальность обмена данными между клиентом и сервером на основе протокола SSL и шифрования с использованием ключей длиной свыше 64 бит на основе алгоритмов TDES, AES, RC2/RC4.

Средства поддержки криптографических сервисов представлены в главе 4.

Начальная загрузка и инициализация z/OS

Начальная загрузка z/OS производится с помощью универсальной программы начальной загрузки IPL (Initial Program Load), которая находит и считывает в память модули ядра операционной системы и запускает программу инициализации ядра NIP (Nucleus Initialization Program) [5], [6].

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

Базовый системный код (ядро z/OS) представлен в библиотечном наборе данных SYS1.NUCLEUS, который всегда размещается на так называемом системном резидентном томе (SYSRES), где должна находиться и программа начальной загрузки IPL. SYS1.NUCLEUS может включать несколько различных вариантов загрузки ядра, каждый из которых представлен в разделе IEANUC0n (n=1-9), а также программу инициализации ядра (NIP) и указатель на главный каталог. Главный каталог (Master Catalog) должен содержать информацию о размещении всех наборов данных, используемых в процессе загрузки.

Дальнейшая загрузка осуществляется под управлением программы инициализации ядра NIP, которая работает в режиме диалога с оператором и использует информацию, представленную в библиотечном наборе данных SYS1.PARMLIB. Этот набор данных состоит из множества разделов, каждый из которых содержит описание параметров конфигурации и настройки операционной системы в виде позиционного текста. Например, в разделе IEASYS содержатся значения основных системных параметров z/OS, в разделе BPXPRM - параметры настройки z/OS UNIX, в CONSOL - характеристики консолей и т.п. Набор данных SYS1.PARMLIB можно назвать системным реестром z/OS. Необходимые при загрузке параметры аппаратной конфигурации системы и характеристики устройств ввода-вывода извлекаются из VSAM набора данных IODF (Input/Output Definition File). Этот набор данных используется для создания в COMMON области блоков управления устройствами (UCB), а также таблицы назначения групповых имен устройствам (Eligible Device Table, EDT).

Кроме указанных наборов данных, на этапе загрузки формируются или используются следующие системные наборы данных:

страничные наборы данных для временного хранения данных, вытесненных при страничном обмене и свопинге;SYS1.PROCLIB - системная библиотека каталогизированных процедур (содержит готовые программы на языке управления заданиями);SYS1.LINKLIB - системная библиотека загрузочных модулей, а также другие библиотеки, описанные в разделе LNKLST набора данных SYS1.PARMLIB (содержат нерезидентные системные программы: утилиты, программы обслуживания, редактор связей и др.);SYS1.LPALIB - библиотечный набор данных, содержащий дополнительные модули z/OS, загружаемые в область LPA, включая системные процедуры, SVC-программы, базовые системные программы методов доступа, некоторые TSO-модули и др. Для загрузки в LPA возможно использование других библиотек, описанных в разделе LPALST набора данных SYS1.PARMLIB;SYS1.MANx - VSAM набор данных, служащий для хранения статистической информации, собираемой модулем SMF (x=A-Z,0-9);SYS1.LOGREC - системный журнал ошибок и сбоев оборудования;SYS1.DUMPxx - системный дамп (содержимое виртуальной памяти), формируемый в случае ошибок при выполнении системных программ (хх=00..99).

На заключительном этапе инициализации системы создается первое виртуальное адресное пространство Master Scheduler ("главный планировщик"), которое, в частности, служит для создания новых системных адресных пространств с помощью специальной программы ACS (Address Space Create). Системные адресные пространства создаются с целью разместить системный код не в общей области, а в приватной. Можно выделить четыре группы системных адресных пространств в зависимости от способа их создания и использования (рис. 5.11):

SYSTEM - системные адресные пространства, создаваемые на этапе инициализации автоматически с помощью главного планировщика;START - адресные пространства, создаваемые по команде оператора START, вводимой с системной консоли или формируемой автоматически для запуска процедур JCL;TSO - адресные пространства, создаваемые для каждого сеанса пользователя TSO, открываемого по команде LOGON;Batch Job - адресные пространства, принадлежащие пакетным инициаторам подсистемы управления заданиями JES и используемые для выполнения пакетных заданий.

Рис. 5.11. Адресные пространства z/OS

Список основных системных, а также запускаемых автоматически при инициализации операционной системы адресных пространств представлен в таблице 5.3.

Таблица 5.3. Основные системные адресные пространства z/OSНаименованиеНазначение

MASTER	Главный планировщик Master Scheduler
ALLOCAS	Создание адресных пространств и пространств данных
APPC, ASCH	Поддержка сетевого протокола APPC
CATALOG (CAS)	Функции каталога
BPXOINIT	Инициализация системного сервиса UNIX
CONSOLE	Поддержка консольных устройств
DFM, DFMCAS, GDEDFM	Управление распределенными файлами (Distributed File Manager)
DLF	Средства использования гиперпространств
DUMPSRV	Средства формирования дампов
HSM, ABARS, ABARxxxx	Менеджер иерархической памяти DFSMShsm, средства резервного копирования и восстановления
FTPSERVE	FTP-сервер
GRS	Средства глобальной синхронизации ресурсов
IOSAS	Супервизор ввода-вывода, поддержка ESCON
IXGLOGR	Системный регистратор
JES2, JES2AUX, JES2MON	Подсистема управления заданиями JES2
LLA	Средства кэширования оглавлений библиотек в виртуальной памяти
NFS	Сетевая файловая система NFS
OAM	Сервер данных для ленточных библиотек IBM 3494 и IBM 3495
OMVS	Системный сервис UNIX
PCAUTH	Поддержка межпространственной связи
RASP	Менеджер реальной памяти RSM
RMM	Менеджер управления сменными носителями DFSMSrmm
RRS	Служба восстановления ресурсов
SMF	Средства управления системой SMF (статистика и измерение производительности)
SMS	Подсистема управления внешней памятью
SMXC, SYSBMAS	Дополнительные средства управления PDSE наборами данных
TCPIP	Средства поддержки TCP/IP
TRACE	Трассировка системы
VLF	Средства кэширования наборов данных в виртуальной памяти
XCFAS	Средства Parallel Sysplex
VTAM	Средства поддержки сети SNA/VTAM
WLM	Менеджер управления рабочей нагрузкой

Управление созданными адресными пространствами и выполняющимися в них приложениями осуществляется на основе создаваемых z/OS управляющих блоков (control blocks). Управляющие блоки представляют связанные между собой структуры данных определенного формата, которые используются для описания всех ресурсов и процессов z/OS и хранятся в виртуальной памяти.

Важнейшим из них является так называемая таблица векторов связей CVT (Communications Vector Table), которая хранится в области ядра и содержит указатели на основные управляющие блоки и системные таблицы, используемые базовой управляющей программой BCP. Местоположение CVT определяется по указателю, записанному в области PSA. Одним из векторов в таблице CVT является указатель на таблицу векторов адресных пространств ASVT (Address Space Vector Table), которая хранится в подпуле 245 и содержит список указателей на управляющие блоки ASCB всех доступных адресных пространств. Как уже отмечалось ранее, блок управления адресным пространством ASCB содержит информацию и указатели, необходимые для управления адресным пространством.

После того как произведен начальный запуск операционной системы z/OS, поддерживается три варианта перезагрузки:

холодная перезагрузка (cold start) - выполняется как начальная загрузка с полной перестройкой содержимого областей виртуальной памяти;быстрая перезагрузка (quick start) - не перестраивается содержимое PLPA; временные наборы данных, размещенные в виртуальной памяти (так называемые VIO), не сохраняются;теплая перезагрузка (warm start) - содержимое PLPA не перестраивается, наборы данных VIO сохраняются.

Реализация базовых функций z/OS

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

область ядра - Nucleus;область системных очередей - SQA (System Queue Area);область загрузки модулей - LPA (Link Pack Area);область общих сервисов - CSA (Common Service Area);область префиксации - PSA (Prefix Save Area).

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

Область ядра Nucleus/Extended Nucleus содержит базовый системный код и дополнительные элементы ядра z/OS, формируемые в процессе начальной загрузки системы (IPL) на основе набора данных SYS1.NUCLEUS. Состав ядра определяется системным программистом путем настройки раздела NUCLST системного реестра SYS1.PARMLIB. Виртульные страницы области ядра являются неперемещаемыми, то есть всегда загружены в основную память и в страничном обмене не участвуют.

Область системных очередей SQA/ESQA служит для размещения общесистемных таблиц, блоков управления и очередей, состав и содержание которых определяется конфигурацией системы и общим количеством создаваемых в процессе работы адресных пространств. Настройка размера области SQA (ESQA) осуществляется с помощью параметра SQA в разделе IEASYS реестра SYS1.PARMLIB или с консоли оператора. При нехватке памяти для SQA система пытается "занять" необходимое пространство в области CSA. Страницы SQA (ESQA) также являются неперемещаемыми и всегда остаются в основной памяти.

Область загрузки модулей LPA/ELPA предназначена для размещения дополнительных реентерабельных загрузочных модулей ядра, включая SVC-программы и методы доступа, а также некоторые пользовательские приложения. Все указанные программы могут одновременно вызываться множеством задач, работающих в различных адресных пространствах. Модули, загружаемые в LPA/ELPA, должны быть предварительно записаны в библиотечный набор данных SYS1.LPALIB или другие наборы данных, определяемые в разделе LPALST реестра SYS1.PARMLIB.
Таким образом, размер области LPA/ ELPA зависит от количества размещаемых модулей. Учитывая особую роль модулей LPA, система требует их авторизации на основе технологии APF (Authorized Program Facility). Авторизованные модули получают право обращаться к защищенным областям системной и приватной памяти.

Область LPA/ELPA в свою очередь делится на три подобласти:

Pageable LPA (PLPA/EPLPA) - содержит перемещаемые модули;Fixed LPA (FLPA/EFLPA) - содержит неперемещаемые модули;Modified LPA (MLPA/EMLPA) - может использоваться на этапе начальной загрузки системы для временного хранения модифицируемых или обновляемых модулей PLPA.

Область общих сервисов CSA/ECSA служит для размещения общих данных, используемых несколькими активными адресными пространствами, и в том числе для организации обмена (межпространственной связи) между адресными пространствами. Размер области CSA/ECSA устанавливается с помощью параметра CSA в разделе IEASYS реестра SYS1.PARMLIB или с консоли оператора. По умолчанию страницы CSA являются перемещаемыми.

Область префиксации PSA служит для хранения содержимого регистра PSW (старого и нового) при реализации механизма обработки прерываний, а также содержит указатели на важные системные управляющие блоки и таблицы. Данная область поддерживается аппаратно, всегда привязана к началу виртуального адресного пространства и имеет размер 4 KB в системах с архитектурой S/370, 370/XA, ESA/390 и 8 KB в системах с z/Architecture.

Для знакомства со структурой приватной области сначала рассмотрим, как она выглядит в OS/390, то есть в режиме 31-разрядной адресации (рис. 5.9). Мы уже отмечали, что часть виртуальной памяти в пределах первых 2 GB сохранила свою структуру в z/OS. В приватной области выделяются следующие элементы:

регион пользователя - User Region и Extended User Region;область локальных системных очередей - LSQA (Local System Queue Area) и ELSQA (Extended Local System Queue Area);область планировщика работ - SWA (Scheduler Work Area) и ESWA (Extended Scheduler Work Area);подпулы (Subpools) 229, 230 и 249;системный регион - System Region.

Рис. 5.9. Структура 31-разрядного виртуального адресного пространства

Регион пользователя предназначен для размещения пользовательских приложений и данных. После загрузки программ в регион пользователя система исключает из использования оставшиеся незанятыми страницы до поступления запроса на выделение дополнительных страниц в данном регионе. У пользователя есть возможность управлять размером региона с помощью одноименного параметра REGION операторов языка управления заданиями JOB и EXEC (см. п. 5.1.5).

Область локальных системных очередей LSQA/ELSQA содержит таблицы и очереди, ассоциируемые с текущим адресным пространством и выполняемыми в нем приложениями. В частности, здесь хранятся таблицы страниц, сегментов и регионов, формируемые менеджером физической памяти RSM. Отметим, что указанные таблицы участвуют в страничном обмене наряду с прочими перемещаемыми страницами.

Область планировщика работ SWA/ESWA служит для размещения блоков управления задачами (TCB) и других блоков управления, создаваемых для обслуживания приложений адресного пространства. Назначение блоков управления будет рассмотрено позднее.

Подпулы (Subpools) 229, 230 и 249 предоставляют локальную память, доступ к которой реализуется на основе запрашиваемых ключей защиты. Эта область служит для размещения управляющих блоков, которые могут использовать только авторизованные программы, имеющие соответствующее значение ключа. Эти управляющие блоки создаются системными компонентами для нужд пользовательских приложений.

LSQA, SWA и подпулы фактически разделяют одну область виртуальной памяти, которая примыкает к границе области CSA, а ELSQA, ESWA - к границе 2 GB. Эти области могут увеличиваться за счет незанятых страниц региона пользователя. Следует отметить, что подпулы могут выделяться и в других областях виртуальной памяти. Они служат для группирования логически связанных между собой блоков виртуальной памяти, например по значению ключа защиты, по возможности откачки или свопинга и т.п.

Системный регион System Region резервирует 16 KB виртуальной памяти для хранения служебной информации при выполнении некоторых системных функций.

Рассмотрим далее, какова структура 64-разрядного виртуального адресного пространства, впервые реализованного в z/OS, начиная с версии V1R2. В 64-разрядных пространствах исполняемый программный код по-прежнему может размещаться только в границах младших 2 GB, однако данные, к которым эти программы обращаются, могут быть загружены в виртуальную память свыше 2 GB. В настоящий момент при запуске приложения первоначально создается адресное пространство размером 2 GB, однако по запросу программы оно может быть увеличено (для этого предусмотрена специальная макрокоманда IARV64).

Рис. 5.10. Структура 64-разрядного виртуального адресного пространства

На рис. 5.10 представлена структура 64-разрядного виртуального адресного пространства, которая включает следующие области:

от 0 до 2 GB - сохраняет ранее рассмотренную структуру (см. рис. 5.9) и служит для размещения программного кода и данных для всех типов приложений;от 2 GB до 4 GB - не используемая по архитектурным соображениям область, получившая название Bar1);от 4 GB до 2 TB - нижний регион пользователя (low user region). Используется первым для предоставления памяти свыше границы 2 GB под данные;от 2 TB до 512 TB - разделяемая область (shared area) для совместного использования различными адресными пространствами. В настоящее время не поддерживается;от 512 TB до 16 EB - верхний регион пользователя (high user region). Используется при нехватке памяти в нижнем регионе.

При освоении новых объемов памяти полезно напомнить используемые единицы измерения: 1 терабайт (TB) равен 240 байт или 1024 GB, 1 петабайт (PB) равен 250 байт или 1024 TB, 1 экзабайт (EB) равен 260

байт или 1024 PB.

Для управления объемом выделяемой виртуальной памяти свыше 2 GB в рамках языка управления заданиями для операторов JOB и EXEC реализован новый параметр MEMLIMIT.

Как отмечалось ранее, при переходе к 64-разрядной виртуальной памяти z/OS механизм динамического преобразования адресов DAT модернизируется путем расширения иерархической модели сегментации за счет образования наряду с сегментами более крупных разделов виртуальной памяти.

Эти разделы получили название первый (RF), второй (RS) и третий (RT) регионы ( region first, region second, region third). Самый маленький по размеру третий регион объединяет 2048 мегабайтных сегментов и, таким образом, имеет объем 2 GB. Второй регион объединяет 2048 третьих регионов и имеет объем 4 TB. И наконец, регионы первого типа объединяют 2048 вторых регионов и занимают объем 8 PB каждый. Всего в 64-разрядном виртуальном адресном пространстве может быть создано 2048 первых регионов.

Для управления виртуальной памятью в каждом из дополнительных регионов z/OS формирует три типа таблиц: RTT, RST и RFT. Таблицы третьего региона (RTT) содержат 2048 указателей на размещение "своих" таблиц сегментов (SGT), таблицы второго региона (RST) - указатели на таблицы третьего региона, таблица первого региона (одна на 64-разрядное виртуальное адресное пространство) - указатели на таблицы второго региона. Очевидно, что пятиступенчатый механизм преобразования адресов требует значительных накладных расходов (памяти и времени). В связи с этим разработчики предусмотрели гибкую схему создания и использования таблиц регионов, реализуемую менеджером физической памяти RSM. Если приложение не требует больше 2 GB памяти, то таблицы регионов не используются вообще, и применяется "старая" 31-разрядная процедура DAT, в которой используются только таблица сегментов и таблицы страниц. Когда приложение запрашивает виртуальную память свыше 2 GB ("за барьером") но не более 4 TB, создается таблица третьего региона (RTT) и соответствующее количество таблиц сегментов. Теперь первой в процедуре DAT будет обрабатываться RTT. Менеджер RSM будет создавать все новые уровни таблиц регионов по мере увеличения объема виртуальной памяти, запрашиваемой приложениями. Для управления доступом к памяти на основе механизма DAT в z/OS используется специальная структура, получившая название управляющий элемент адресного пространства ASCE (Address Space Control Element), размещаемый в аппаратных регистрах.ASCE определяет, в частности, какой уровень таблиц региона является старшим для данного адресного пространства.

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

Управление основной памятью в z/OS базируется на концепции виртуальной памяти, основные принципы которой были изложены при рассмотрении эволюции системы в п. 5.1.1. Важно подчеркнуть, что в z/OS фактически сохранена архитектура, реализованная в MVS/ESA и развитая в дальнейшем в OS/390. Конечно, расширение разрядности адреса (и, следовательно, объема адресного пространства) не могло не привести к целому ряду нововведений, о которых далее и пойдет речь. Но начнем, однако, с общих понятий и терминов, принятых в MVS, OS/390 и z/OS и необходимых для понимания механизмов управления памятью [4], [5].

В соответствии с концепцией MVS, каждая прикладная программа, а также некоторые системные функции получают в свое распоряжение отдельное виртуальное адресное пространство (virtual address space), размер которого для OS/390 составлял 231 байт, а для z/OS увеличился до 264

байт. Виртуальная память (virtual storage) является воображаемым объектом и фактически представлена в системе как совокупность специальных структур (таблиц), описывающих размещение данных и кода программы в выделенном для нее адресном пространстве. В реальности же выполнение приложений может осуществляться только тогда, когда данные и код загружены в основную память. На рис. 5.8 представлен обобщенный механизм реализации технологии виртуальной памяти.

Рис. 5.8. Элементы системы управления памятью

Некоторое приложение (MYPROG) "размещается" операционной системой в выделенном для него виртуальном адресном пространстве, занимая некоторое количество блоков памяти фиксированной длины, называемых страницами (page). Размер каждой страницы равен 4 KB. Приложение использует виртуальные страничные адреса, и ему доступна любая область собственного адресного пространства.

Чтобы начать выполнение приложения, система загружает его виртуальные страницы в основную память (Central storage), отмечая их местоположение в специальной таблице страниц (page table). Основная память также представлена в виде набора блоков размером 4 KB, называемых фреймами

(frame). При загрузке значения виртуальных адресов сохраняются в неизменном виде. Понятно, что при обращении к памяти требуются реальные физические адреса. Для преобразования виртуальных адресов в физические используется специальный аппаратный механизм динамического преобразования адресов DAT (Dynamic Address Translation), который учитывает реальное размещение виртуальных страниц в основной памяти в момент выполнения адресных команд. Механизм DAT подробно описан в п. 2.1.3. Напомним, что для повышения эффективности управления в системе поддерживается иерархическая модель сегментации виртуальной памяти, в соответствии с которой страницы объединяются в сегменты размером 1 MB (256 страниц на сегмент), а те в свою очередь - в более крупные разделы виртуальной памяти, называемые регионами.

При нехватке основной памяти некоторые страницы могут быть временно перемещены в специальные страничные наборы данных (page data set) во внешнюю вспомогательную память (Auxiliary storage) на магнитных дисках. Блок памяти в страничных наборах получил название слот (slot) и также имеет размер 4 KB. Вытесненные во вспомогательную память страницы находятся там до тех пор, пока не возникнет необходимость в их использовании при выполнении приложения. В этом случае генерируется программное прерывание по отсутствию страницы (page fault) и, при наличии свободных фреймов, запускается процедура "подкачки" страницы из вспомогательной памяти. При занятии страницей свободного фрейма в таблицу страниц вносится его указатель и затем формируется физический адрес.

Конечно, возможна ситуация, когда в основной памяти для загрузки отсутствующей страницы не осталось ни одного свободного фрейма. В этом случае запускается процедура изъятия страниц (page stealing), в результате которой одна или несколько виртуальных страниц "откачиваются" из основной памяти во вспомогательную, чтобы освободить место. Выбор изымаемых страниц основан на классическом методе LRU, использующем формируемые аппаратно биты ключа защиты памяти: бит обращения R и бит изменения С (см.

п. 2.1.3).

Перемещение страниц приложения из основной памяти во вспомогательную и обратно называют страничным обменом (paging), который может происходить многократно в течение всего времени выполнения. При этом следует обратить внимание, что для работы программ вовсе не требуется одновременное присутствие в основной памяти всех ее страниц, равно как и размещение этих страниц в соседних фреймах. Некоторые страницы, содержащие важную системную информацию, могут не участвовать в страничном обмене. Они имеют статус неперемещаемых (fixed) и постоянно находятся в основной памяти. Остальные же страницы считаются перемещаемыми (pagable).

Наряду со страничным обменом в z/OS поддерживается еще одна процедура, управляющая перемещением страниц, - свопинг (swapping). В некоторые критические моменты работы системы (например, при нехватке ресурсов или когда приложение долгое время не проявляет активности) операционная система по инициативе менеджера управления рабочей нагрузкой WLM может принять решение о выгрузке (swap out) всех страниц адресного пространства приложения из основной памяти во вспомогательную. Для этой цели могут создаваться специальные наборы данных свопинга (swap data set). Вытесненным таким образом приложениям не предоставляется процессорное время до тех пор, пока не будет выполнена операция swap in, возвращающая страницы приложения в основную память.

Необходимо отметить, что в операционных системах MVS/ESA и OS/390 для повышения эффективности страничного обмена применялась так называемая расширенная память (Expanded storage), которая, являясь фактическим продолжением основной памяти, использовалась для хранения вытесненных оттуда страниц. Это позволило существенно уменьшить время страничного обмена по сравнению с использованием для той же цели дисковой памяти. Благодаря применяемой для расширенной памяти блочной (а не побайтной) адресации (размер блока - 4 KB), объем расширенной памяти мог достигать 8 GB, в то время как основная память была ограничена размером 2 GB.

В z/OS необходимость в поддержке расширенной памяти отпала, поскольку появилась возможность просто увеличить объем основной памяти (в z900 до 64 GB)!

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

Для управления памятью в базовой управляющей программе z/OS представлены три менеджера памяти (VSM, RSM, ASM), каждый из которых отвечает за свой участок работы (рис. 5.8).

Менеджер виртуальной памяти VSM (Virtual Storage Manager) осуществляет постраничное размещение данных и кода приложений в виртуальном адресном пространстве по запросу, определяет структуру адресных пространств, предоставляет необходимую информацию об использовании виртуальной памяти менеджеру управления нагрузкой WLM. Для этих целей VSM, как и другие менеджеры памяти, предоставляет программисту набор специальных макросредств. Для каждого виртуального адресного пространства VSM строит управляющий блок, получивший название блок управления адресным пространством ASCB (Address Space Control Block). Этот блок содержит информацию и указатели, используемые при управлении адресным пространством. Для идентификации каждое создаваемое адресное пространство получает уникальный номер (идентификатор) ASID (Address Space IDentificator).

Менеджер физической памяти RSM (Real Storage Manager) производит размещение виртуальных страниц в основной памяти, создает и корректирует таблицы страниц, сегментов и регионов, управляет страничным обменом и свопингом. В OS/390 RSM также брал на себя функции управления расширенной памятью.

Менеджер вспомогательной памяти ASM (Auxiliary Storage Manager) предназначен для создания и управления наборами данных страничного обмена и свопинга на DASD, а также для перемещения виртуальных страниц между основной и вспомогательной памятью по указанию RSM.

Следующим важным вопросом является структура виртуального адресного пространства. Ранее отмечалось, что адресное пространство MVS включает общую область (common area), в которой размещаются доступные всем приложениям системные программы и данные, и защищенную приватную область (private area), используемую для размещения кода и данных приложения, а также ассоциированных с приложением системных структур. Начиная с MVS/XA, когда состоялся переход на 31-разрядную архитектуру, включая OS/390, структура виртуальной памяти приложения выглядит так, как представлено на рис. 5.9 [6]. Эта структура полностью соответствует структуре младших 2 GB виртуальной памяти z/OS, поэтому рассмотрим ее подробнее.

Для поддержки 24-разрядных приложений структура виртуального адресного пространства в младших 16 MB соответствует требованиям архитектуры MVS/370. Свыше границы 16 MB размещаются расширенная общая область

(Extended Common), как продолжение общей области MVS/370, и расширенная приватная область (Extended Private), которая может использоваться 31-разрядными приложениями. Следует отметить, что содержимое общей области, включая расширенную ее часть, для всех адресных пространств совпадает. Фактически это достигается путем создания в системе единого набора виртуальных страниц с определенными виртуальными адресами, разделяемого всеми адресными пространствами. Содержимое же приватной области для каждого адресного пространства уникально.

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

Область системных очередей SQA/ESQA служит для размещения общесистемных таблиц, блоков управления и очередей, состав и содержание которых определяется конфигурацией системы и общим количеством создаваемых в процессе работы адресных пространств. Настройка размера области SQA (ESQA) осуществляется с помощью параметра SQA в разделе IEASYS реестра SYS1.PARMLIB или с консоли оператора. При нехватке памяти для SQA система пытается "занять" необходимое пространство в области CSA. Страницы SQA (ESQA) также являются неперемещаемыми и всегда остаются в основной памяти.

Область загрузки модулей LPA/ELPA предназначена для размещения дополнительных реентерабельных загрузочных модулей ядра, включая SVC-программы и методы доступа, а также некоторые пользовательские приложения. Все указанные программы могут одновременно вызываться множеством задач, работающих в различных адресных пространствах. Модули, загружаемые в LPA/ELPA, должны быть предварительно записаны в библиотечный набор данных SYS1.LPALIB или другие наборы данных, определяемые в разделе LPALST реестра SYS1.PARMLIB. Таким образом, размер области LPA/ELPA зависит от количества размещаемых модулей. Учитывая особую роль модулей LPA, система требует их авторизации на основе технологии APF (Authorized Program Facility). Авторизованные модули получают право обращаться к защищенным областям системной и приватной памяти.

Область LPA/ELPA в свою очередь делится на три подобласти:

Pageable LPA (PLPA/EPLPA) - содержит перемещаемые модули;Fixed LPA (FLPA/EFLPA) - содержит неперемещаемые модули;Modified LPA (MLPA/EMLPA) - может использоваться на этапе начальной загрузки системы для временного хранения модифицируемых или обновляемых модулей PLPA.

Область общих сервисов CSA/ECSA служит для размещения общих данных, используемых несколькими активными адресными пространствами, и в том числе для организации обмена (межпространственной связи) между адресными пространствами.

Размер области CSA/ECSA устанавливается с помощью параметра CSA в разделе IEASYS реестра SYS1.PARMLIB или с консоли оператора. По умолчанию страницы CSA являются перемещаемыми.

Область префиксации PSA служит для хранения содержимого регистра PSW (старого и нового) при реализации механизма обработки прерываний, а также содержит указатели на важные системные управляющие блоки и таблицы. Данная область поддерживается аппаратно, всегда привязана к началу виртуального адресного пространства и имеет размер 4 KB в системах с архитектурой S/370, 370/XA, ESA/390 и 8 KB в системах с z/Architecture.

Для знакомства со структурой приватной области сначала рассмотрим, как она выглядит в OS/390, то есть в режиме 31-разрядной адресации (рис. 5.9). Мы уже отмечали, что часть виртуальной памяти в пределах первых 2 GB сохранила свою структуру в z/OS. В приватной области выделяются следующие элементы:

регион пользователя - User Region и Extended User Region;область локальных системных очередей - LSQA (Local System Queue Area) и ELSQA (Extended Local System Queue Area);область планировщика работ - SWA (Scheduler Work Area) и ESWA (Extended Scheduler Work Area);подпулы (Subpools) 229, 230 и 249;системный регион - System Region.

Рис. 5.9. Структура 31-разрядного виртуального адресного пространства

Регион пользователя предназначен для размещения пользовательских приложений и данных. После загрузки программ в регион пользователя система исключает из использования оставшиеся незанятыми страницы до поступления запроса на выделение дополнительных страниц в данном регионе. У пользователя есть возможность управлять размером региона с помощью одноименного параметра REGION операторов языка управления заданиями JOB и EXEC (см. п. 5.1.5).

Область локальных системных очередей LSQA/ELSQA содержит таблицы и очереди, ассоциируемые с текущим адресным пространством и выполняемыми в нем приложениями. В частности, здесь хранятся таблицы страниц, сегментов и регионов, формируемые менеджером физической памяти RSM.

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

Область планировщика работ SWA/ESWA служит для размещения блоков управления задачами (TCB) и других блоков управления, создаваемых для обслуживания приложений адресного пространства. Назначение блоков управления будет рассмотрено позднее.

Подпулы (Subpools) 229, 230 и 249 предоставляют локальную память, доступ к которой реализуется на основе запрашиваемых ключей защиты. Эта область служит для размещения управляющих блоков, которые могут использовать только авторизованные программы, имеющие соответствующее значение ключа. Эти управляющие блоки создаются системными компонентами для нужд пользовательских приложений.

LSQA, SWA и подпулы фактически разделяют одну область виртуальной памяти, которая примыкает к границе области CSA, а ELSQA, ESWA - к границе 2 GB. Эти области могут увеличиваться за счет незанятых страниц региона пользователя. Следует отметить, что подпулы могут выделяться и в других областях виртуальной памяти. Они служат для группирования логически связанных между собой блоков виртуальной памяти, например по значению ключа защиты, по возможности откачки или свопинга и т.п.

Системный регион System Region резервирует 16 KB виртуальной памяти для хранения служебной информации при выполнении некоторых системных функций.

Рассмотрим далее, какова структура 64-разрядного виртуального адресного пространства, впервые реализованного в z/OS, начиная с версии V1R2. В 64-разрядных пространствах исполняемый программный код по-прежнему может размещаться только в границах младших 2 GB, однако данные, к которым эти программы обращаются, могут быть загружены в виртуальную память свыше 2 GB. В настоящий момент при запуске приложения первоначально создается адресное пространство размером 2 GB, однако по запросу программы оно может быть увеличено (для этого предусмотрена специальная макрокоманда IARV64).

Рис. 5.10. Структура 64-разрядного виртуального адресного пространства

На рис. 5.10 представлена структура 64- разрядного виртуального адресного пространства, которая включает следующие области:

от 0 до 2 GB - сохраняет ранее рассмотренную структуру (см. рис. 5.9) и служит для размещения программного кода и данных для всех типов приложений;от 2 GB до 4 GB - не используемая по архитектурным соображениям область, получившая название Bar1);от 4 GB до 2 TB - нижний регион пользователя (low user region). Используется первым для предоставления памяти свыше границы 2 GB под данные;от 2 TB до 512 TB - разделяемая область (shared area) для совместного использования различными адресными пространствами. В настоящее время не поддерживается;от 512 TB до 16 EB - верхний регион пользователя (high user region). Используется при нехватке памяти в нижнем регионе.

При освоении новых объемов памяти полезно напомнить используемые единицы измерения: 1 терабайт (TB) равен 240 байт или 1024 GB, 1 петабайт (PB) равен 250 байт или 1024 TB, 1 экзабайт (EB) равен 260

байт или 1024 PB.

Для управления объемом выделяемой виртуальной памяти свыше 2 GB в рамках языка управления заданиями для операторов JOB и EXEC реализован новый параметр MEMLIMIT.

Как отмечалось ранее, при переходе к 64-разрядной виртуальной памяти z/OS механизм динамического преобразования адресов DAT модернизируется путем расширения иерархической модели сегментации за счет образования наряду с сегментами более крупных разделов виртуальной памяти. Эти разделы получили название первый (RF), второй (RS) и третий (RT) регионы (region first, region second, region third). Самый маленький по размеру третий регион объединяет 2048 мегабайтных сегментов и, таким образом, имеет объем 2 GB. Второй регион объединяет 2048 третьих регионов и имеет объем 4 TB. И наконец, регионы первого типа объединяют 2048 вторых регионов и занимают объем 8 PB каждый. Всего в 64-разрядном виртуальном адресном пространстве может быть создано 2048 первых регионов.

Для управления виртуальной памятью в каждом из дополнительных регионов z/OS формирует три типа таблиц: RTT, RST и RFT.

Таблицы третьего региона (RTT) содержат 2048 указателей на размещение "своих" таблиц сегментов (SGT), таблицы второго региона (RST) - указатели на таблицы третьего региона, таблица первого региона (одна на 64-разрядное виртуальное адресное пространство) - указатели на таблицы второго региона. Очевидно, что пятиступенчатый механизм преобразования адресов требует значительных накладных расходов (памяти и времени). В связи с этим разработчики предусмотрели гибкую схему создания и использования таблиц регионов, реализуемую менеджером физической памяти RSM. Если приложение не требует больше 2 GB памяти, то таблицы регионов не используются вообще, и применяется "старая" 31-разрядная процедура DAT, в которой используются только таблица сегментов и таблицы страниц. Когда приложение запрашивает виртуальную память свыше 2 GB ("за барьером") но не более 4 TB, создается таблица третьего региона (RTT) и соответствующее количество таблиц сегментов. Теперь первой в процедуре DAT будет обрабатываться RTT. Менеджер RSM будет создавать все новые уровни таблиц регионов по мере увеличения объема виртуальной памяти, запрашиваемой приложениями. Для управления доступом к памяти на основе механизма DAT в z/OS используется специальная структура, получившая название управляющий элемент адресного пространства ASCE (Address Space Control Element), размещаемый в аппаратных регистрах. ASCE определяет, в частности, какой уровень таблиц региона является старшим для данного адресного пространства.

Управление рабочей нагрузкой

Одна из важнейших функций базовой управляющей программы z/OS связана с решением задачи эффективного динамического перераспределения системных ресурсов (процессорного времени, основной памяти, каналов и устройств) между всеми видами выполняемых в системе работ с учетом их важности. В состав выполняемых работ включаются пакетные задания, запускаемые процедуры STC и программы поддержки интерактивных пользовательских сеансов TSO, приложения и команды, запускаемые в рамках сеансов TSO/ISPF, команды и утилиты UNIX shell, транзакции CICS, DB2 и др. Иногда такую задачу называют "балансировкой рабочей нагрузки", поскольку в условиях постоянно меняющегося объема выполняемых в системе работ, с одной стороны, требуется поддерживать приемлемый или заданный уровень пропускной способности (или времени реакции), а с другой - обеспечить максимальную загрузку имеющихся ресурсов, не допуская при этом ситуаций, когда какого-либо ресурса недостает. Решение этой задачи возложено на менеджера управления рабочей нагрузкой WLM (WorkLoad Manager), который впервые был представлен в MVS SP V5. Возможности WLM распространяются на множество работ, выполняемых в том числе и в кластере Parallel Sysplex.

WLM реализует эффективную модель управления нагрузкой, получившую название "целевой режим" (goal mode) и основанную на выборе и описании ожидаемых целей функционирования для каждой из выполняемых работ [8]. Отметим, что одновременно вплоть до z/OS V1R2 поддерживался и так называемый "режим совместимости" (compatibility mode) - ныне не применяемая модель управления, ориентированная на низкоуровневые средства настройки и контроля использования ресурсов с помощью менеджера системных ресурсов SRM (System Resource Manager).

Рассмотрим основные принципы управления рабочей нагрузкой в целевом режиме WLM. Все выполняемые в системе работы делятся на непересекающиеся группы, называемые классами обслуживания (service class). Принадлежность конкретной работы к тому или иному классу определяется по ее атрибутам, таким как тип работы (пакетное задание, транзакция и т.п.), идентификатор пользователя, учетная информация, используемая подсистема (среда) выполнения и др.
Атрибуты каждого класса обслуживания назначаются системным администратором при настройке системы или устанавливаются по умолчанию. Таким образом, в каждом классе объединяются работы с идентичными характеристиками с точки зрения используемых ресурсов и требуемой производительности.

С каждым классом обслуживания ассоциируется определенная цель выполнения (goal) и показатель важности (importance). С помощью WLM могут быть определены три типа целей выполнения, условно обозначаемых как время отклика, избирательность и скорость выполнения.

Цель типа "время отклика" (response time) означает установку желаемой длительности выполнения работы, которая измеряется от момента запуска (ввода) запроса до получения результата. Эта цель обычно выбирается для коротких транзакций, поступающих от интерактивных пользователей, и может быть задана двумя способами. Первый способ заключается в установке среднего времени отклика: например, 0,5 с для всех работ данного класса обслуживания. Второй способ позволяет дополнительно указать долю работ, для которых необходимо обеспечить требуемое время реакции: например, 80% работ данного класса обслуживания должны быть выполнены не более чем за 0,5 с.

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

Цель "скорость выполнения" (velocity) назначается для работ, для которых первые две цели неприемлемы. К этой категории относятся, например, длительные или "бесконечные" по времени выполнения работы, которые тем не менее нельзя отнести к низкоприоритетным. Скорость выполнения задается целым числом в диапазоне 1-99.

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

Показатель важности класса обслуживания характеризует, насколько важно для работ данного класса достичь установленной цели. Данный показатель, принимающий целочисленные значения в диапазоне от 1 до 5, применяют в тех случаях, когда в системе возникает дефицит ресурсов и требуется "пожертвовать" какими-то работами (то есть заставить их ждать). При разрешении коллизий работы класса обслуживания с показателем важности 1 будут иметь преимущество перед работами всех остальных классов. Для классов, имеющих цель "избирательность", показатель важности не назначается.

Выполнение работ каждого класса обслуживания представляется в виде последовательности периодов (period), для каждого из которых могут быть заданы различные цели и показатели важности. Продолжительность периода определяется по условному количеству выделенных для периода ресурсов, измеряемому в так называемых единицах обслуживания (service units). Эта величина зависит от количества использованных процессорных квантов для выполняемых задач (TCB и SRB), числа запросов на доступ к памяти и ввод-вывод, а также типов используемых устройств и оборудования.

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

управление созданием новых адресных пространств;управление страничным обменом (предотвращение нехватки памяти, откачка страниц);организацию свопинга (временное высвобождение ресурсов от низкоприоритетных работ);блокировку приема пакетных, STC и TSU заданий при повышенной нагрузке (нехватка свободных страниц в страничных наборах или в центральной памяти, пробуксовка страниц и т.п.)управление диспетчерскими приоритетами задач;управление пакетными инициаторами, обеспечивающими выполнение пакетных заданий;управление приоритетами при вводе-выводе;управление распределением наборов данных по устройствам.

Еще одно важное понятие, используемое WLM, - стратегия обслуживания

(service policy), которая позволяет динамически изменять параметры (цели, периоды, показатели важности) для установленных классов обслуживания в течение рабочего дня или в зависимости от дня недели и иных критериев.

Настройка параметров WLM осуществляется системным программистом на основе специальной диалоговой программы, доступной в TSO/ISPF.

Ранее отмечалось, что в z/OS появился новый компонент для динамического управления ресурсами в режиме LPAR с учетом рабочей нагрузки - интеллектуальный менеджер ресурсов IRD (Intelligent Resource Director) [9]. IRD расширяет концепцию целевого режима управления рабочей нагрузкой, реализуемую WLM, путем предоставления ресурсов логических разделов LPAR, размещенных как на одном физическом сервере, так и в рамках сисплекса (так называемый кластер LPAR). Новые возможности IRD затрагивают решение следующих основных задач применительно к целевому режиму управления:

динамическое изменение доли процессорного времени (processor weight), выделяемого логическому разделу (LPAR CPU management);динамическое переопределение канальных путей между LPAR для повышения эффективности ввода-вывода с учетом целевых критериев выполняемых работ (dynamic channel path management, DCM);организация доступных всем LPAR дополнительных очередей на ввод-вывод с учетом целевых критериев выполняемых работ (channel subsystem priority queuing, CSSPQ).

При управлении ресурсами системы существенную роль играют еще два компонента z/OS: SMF и RMF.

Компонент SMF (System Management Facility) входит в состав базовой управляющей программы и предназначен для сбора и регистрации информации, касающейся функционирования z/OS и приложений. SMF работает в собственном адресном пространстве. Собранная информация накапливается в виде так называемых SMF-записей в специальных VSAM - наборах данных с именами SYS1.MANx (х - целое число). Различают два типа записей: с системной и пользовательской информацией. SMF-записи с системной информацией включают, например, сведения о конфигурации системы, активности страничного обмена, рабочей нагрузке и интенсивности использования различных ресурсов.

SMF-записи с пользовательской информацией содержат данные об использовании процессоров и устройств (в первую очередь DASD) для каждого шага задания и задания в целом, а также для пользовательских сеансов TSO. Собранная SMF информация используется различными компонентами z/OS, включая WLM, а также доступна пользователю непосредственно или с помощью рассматриваемого ниже компонента RMF. Настройка SMF осуществляется с помощью раздела SMFPRM реестра SYS1.PARMLIB.

Менеджер сбора данных о ресурсах RMF (Resource Measurement Facility) принадлежит к числу опциональных компонентов z/OS и содержит средства для сбора данных и формирования отчетов об использовании ресурсов и производительности системы. Отчеты, формируемые RMF, могут использоваться для анализа текущего состояния системы, выявления узких мест, а также выбора наиболее эффективной стратегии управления ресурсами и нагрузкой и планирования развития аппаратного обеспечения системы.

В состав RMF входят три программных монитора.

Монитор III - предназначен для сбора и анализа информации на коротком отрезке времени (сбор первичных данных с периодом 1 с, консолидация собранных данных с сохранением результатов - каждые 100 с). Позволяет получить сведения о значениях времени отклика и скорости выполнения работ, информацию о задержках, сказавшихся на производительности.Монитор II - предназначен для сбора и анализа информации об использовании конкретного ресурса (например, процессоров, дискового тома, основной памяти) либо об активности и потребляемых ресурсах применительно к указанному адресному пространству или заданию в текущий момент времени. Может осуществляться непрерывный контроль состояния адресного пространства или задания.Монитор I - предназначен для сбора и анализа информации о рабочей нагрузке и использовании ресурсов на длительном (указанном) отрезке времени (по умолчанию период сбора - 1 с, период консолидации - 30 мин). Значения временных периодов могут быть заданы пользователем. В остальном - то же, что и монитор III.

Для хранения собранной информации все три типа мониторов могут задействовать наборы данных SMF, а монитор III, кроме того, использует собственный набор данных VSAM. Использование RMF осуществляется через диалоговый интерфейс, доступный в TSO/ISPF, однако существует возможность запуска мониторов RMF в пакетном режиме с выводом отчетов в указанный набор данных. При этом можно получать сообщения о возникающих проблемах.

Для хранения собранной информации все три типа мониторов могут задействовать наборы данных SMF, а монитор III, кроме того, использует собственный набор данных VSAM. Использование RMF осуществляется через диалоговый интерфейс, доступный в TSO/ISPF, однако существует возможность запуска мониторов RMF в пакетном режиме с выводом отчетов в указанный набор данных. При этом можно получать сообщения о возникающих проблемах.

1)

Термин Bar можно перевести как <пробел>, <планка>, <барьер> - кому что нравится. Появились также термины <above the bar> и <below the bar> для обозначения областей виртуальной памяти, лежащих соответственно выше Bar-области (для доступа требуется 64-разрядный адрес) и ниже (достаточно 31-разрядного адреса).

Управление вводом-выводом

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

Для описания конфигурации подключенного оборудования и устройств ввода-вывода, а также их динамической реконфигурации используются упоминавшиеся ранее диалоговые компоненты HCD или HCM. Результатом их применения является построение набора данных IODF (Input/Output Definition File), в котором определены параметры устройств ввода-вывода, используемые канальной подсистемой и z/OS. Канальная подсистема получает необходимую для работы информацию с помощью программы для описания оборудования IOCP (Input/Output Configuration Program), которая на основе IODF формирует конфигурационный набор данных параметров оборудования, подключенного к канальной подсистеме IOCDS (Input/Output Configuration Data Set). z/OS использует содержимое IODF на этапе начальной загрузки и инициализации (см. выше).

Управление потоками данных при вводе-выводе построено на основе гибкой многоуровневой модели [7]. На рис. 5.13 показана типичная схема обработки запросов ввода-вывода на примере приложения, использующего данные, хранящиеся на устройстве DASD.

Рис. 5.13. Средства управления потоками данных при вводе-выводе

Приложение MYPRG, представленное в адресном пространстве AS, запускается с помощью пакетного задания, которое содержит описание используемого набора данных с именем MYDATA (оператор DD). Операции ввода-вывода представлены в тексте приложения в виде макровызовов OPEN, GET, PUT, CLOSE. На языках высокого уровня данные макровызовы генерируются компилятором при обращении к соответствующим функциям ввода-вывода. Макровызов OPEN выполняется перед началом процесса ввода-вывода для построения специальных управляющих блоков - блока управления данными DCB (Data Control Block) и блока размещения данных DEB (Data Extent Block).
DCB содержит информацию о параметрах набора данных (имя, тип, устройство и т.п.), представленную в специальном одноименном макровызове DCB. Эти параметры могут быть дополнены и откорректированы в операторе языка управления заданиями DD, связанном с соответствующим DCB. DEB содержит информацию о размещении набора данных, включая адрес устройства и характеристики выделенного набору данных пространства внешней памяти.

Указанные управляющие блоки используются при выполнении операций ввода-вывода, которые осуществляются с помощью макровызовов чтения (ввода) GET и записи (вывода) PUT. Исполнение макросов GET/PUT начинается с передачи управления программе метода доступа, указатель на которую хранится в DCB. Метод доступа (access method) представляет собой своеобразный интерфейс между приложением и его данными, благодаря которому приложение работает на логическом уровне представления данных, вне зависимости от их физической организации. Программа метода доступа размещается в области LPA адресного пространства и берет на себя выполнение множества важных функций, таких как:

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

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

QSAM, BSAM - для обработки последовательных наборов данных и разделов библиотек;BPAM - для обработки библиотечных наборов данных (PDS и PDSE);VSAM - для обработки наборов данных VSAM;OAM - для обработки не разделенных на логические записи потоков данных (объектов), хранящихся в СУБД DB2 и на оптических носителях;VTAM - для организации сетевого ввода-вывода.

Каждый из представленных методов доступа реализует собственный алгоритм записи/чтения данных и располагает специфическим набором макрокоманд и утилит для организации ввода-вывода.

Наряду с выполнением представленных выше функций программа метода доступа создает управляющие блоки IOB и ECB. Управляющий блок ввода-вывода IOB (Input/Output Block) содержит указатели на все связанные с данной операцией ввода-вывода управляющие блоки и, самое важное, - на канальную программу. Канальная программа (channel program) создается программой метода доступа и состоит из последовательности канальных команд CCW, описывающих всю процедуру ввода-вывода, включая адреса области памяти, куда (откуда) пересылаются данные, а также объем передаваемых данных (см. п. 2.2).

Далее через вызов соответствующего SVC прерывания управление передается драйверу, который реализует интерфейс между методом доступа и супервизором ввода-вывода IOS. Блок управления событиями ECB (Event Control Block) служит для синхронизации работы метода доступа и драйвера. Когда в следующий раз метод доступа получит управление от диспетчера, он с помощью макровызова WAIT будет ждать сигнала от драйвера о завершении операции ввода-вывода.

Для большинства методов доступа, не использующих наборы данных VSAM, применяется так называемый драйвер EXCP (EXecute Channel Program), вызываемый одноименной макрокомандой. Драйвер резервирует в основной памяти страницы, которые будут использоваться для перемещения данных и размещения канальной программы и объявляет их фиксированными (неперемещаемыми) на время выполнения операций, корректируя соответствующим образом адреса канальной программы.

Затем управление передается супервизору ввода-вывода IOS (Input Output Supervisor), который обеспечивает взаимодействие z/OS c канальной подсистемой, выполняя следующие функции:

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

Канальная подсистема выполняет канальную программу, обеспечивая физический перенос данных между основной памятью и устройством с помощью аппаратного контроллера (CU) и канальных путей.Завершая операцию, канальная подсистема формирует прерывание ввода-вывода, предварительно записав код завершения операции в специальный управляющий блок IRB (Interrupt Response Block). Обработчик прерывания через SRB-запрос запускает программу оповещения супервизора ввода-вывода IOS, которая передает управление драйверу. Драйвер сигнализирует методу доступа о завершении операции ввода-вывода, который, в свою очередь, получив управление от диспетчера, возвращает управление пользовательскому приложению. После этого приложение, наконец, может продолжить свою работу. При наличии ошибок могут срабатывать программы восстановления, представленные в составе супервизора.

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

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

Напомним, что задача (task) представляет собой минимальную единицу работы, которой система предоставляет процессорные кванты. Задачи порождаются по инициативе приложений (с помощью макровызова ATTACH) для распараллеливания выполнения отдельных фрагментов кода программы. Любая программа, как минимум, представляет собой одну задачу, но может быть построена в виде совокупности параллельно выполняемых задач.

Для каждой задачи z/OS строит специальный управляющий блок - блок управления задачей TCB (Task Control Block), который содержит основные атрибуты задачи и размещается в адресном пространстве соответствующего приложения (в области планировщика работ SWA/ESWA пользовательского региона). В общем случае с каждым адресным пространством ассоциируется несколько TCB, включая некоторые системные задачи, обслуживающие выполнение пользовательских приложений. Все блоки TCB связаны между собой в иерархическую цепочку с помощью специальных указателей.

Наряду с задачами в z/OS существует еще один тип работ - так называемые "запросы на выполнение сервисных программ". Эти запросы инициируются системным кодом, исполняемым в некотором адресном пространстве, для выполнения действий, затрагивающих другое адресное пространство. Запросы выполняются в невытесняющем режиме и имеют ряд ограничений, связанных с невозможностью применения системных вызовов (SVC-прерываний) и использования памяти вне области SQA. Для каждого такого запроса система строит управляющий блок, получивший название SRB (System Request Block).

Таким образом, в любой момент времени в системе присутствует некоторое количество работ в виде задач и запросов, которые готовы к выполнению и нуждаются в предоставлении процессорного времени. Проблема распределения процессорного времени решается с помощью специальной системной программы, тесно связанной с процедурой обработки прерываний, которая называется диспетчер (dispatcher) или планировщик работ [7].

Диспетчер формирует очереди работ WUQ (Work Unit Queue) из числа вновь созданных, а также готовых к выполнению, но ранее прерванных задач и запросов (рис. 5.12).
Очереди имеют двухуровневую организацию. На первом уровне формируется цепочка ASCB - управляющих блоков адресных пространств, страницы которых представлены в физической памяти (swap in) и у которых имеется хотя бы одна задача или запрос, готовые к выполнению (т.е. не ожидающие завершения какого-либо события). ASCB упорядочены в соответствии с диспетчерскими приоритетами, установленными для различных адресных пространств с помощью менеджера управления рабочей нагрузкой WLM. Каждое адресное пространство располагает собственной очередью готовых к выполнению задач и запросов в виде цепочки управляющих блоков TCB и SRB, на которую имеется указатель в ASCB (очередь второго уровня). SRB всегда имеют преимущество перед TCB. Любое событие, изменяющее статус адресного пространства и его работ, приводит к изменению очереди.

Рис. 5.12. Диспетчеризация работ

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

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

загрузка адреса таблицы сегментов в управляющий регистр CR;восстановление ранее сохраненных регистров процессора;восстановление старого PSW и передача управления следующей работе.

Библиотечные наборы данных

Библиотечные наборы данных (Partitioned Data Set, PDS), или библиотеки, рассматриваются как совокупность разделов (members), каждый из которых имеет внутреннюю организацию, соответствующую последовательному набору данных. z/OS обеспечивает доступ к разделам библиотечного набора данных по их уникальным именам. Имя раздела формируется по тем же правилам, что и простое имя набора данных, и указывается в круглых скобках после имени библиотечного набора данных, например: MY.DSET.PROG(PROG01) - раздел PROG01 набора данных MY.DSET.PROG. Для обработки библиотечных наборов данных в z/OS поддерживается специальный метод доступа BPAM.

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

оглавление (directory), в котором содержится информация об именах разделов и их размещении в памяти (распределяется блоками по 256 байт);область данных, в которой содержатся сами разделы библиотеки.

Рис. 5.15. Структура библиотечного набора данных

Каждый элемент оглавления может содержать до 62 байт пользовательской или системной информации о соответствующем разделе набора данных. Эта возможность используется, в частности, в диалоговом компоненте ISPF/PDF.

Разделы могут обрабатываться в произвольном порядке, то есть разрешается считывать, удалять, переименовывать, копировать любые разделы. Добавление новых разделов возможно при наличии достаточного свободного пространства в конце области данных и в области оглавления. Память, выделенная под библиотечный набор данных, считается исчерпанной, если отсутствует возможность добавить новый раздел, в том числе и из-за нехватки места в области оглавления. Для библиотечных наборов данных поддерживается специальная операция "сжатия" или "чистки", которая заключается в устранении незанятых блоков в области данных библиотеки и увеличения непрерывного свободного пространства в конце области данных путем перераспределения разделов. Все разделы характеризуются единым набором значений параметров логических записей (RECFM, LRECL, BLKSIZE).

Библиотечные наборы данных обычно используются для хранения относительно небольших по объему "блоков" информации: исходных текстов программ, процедур и заданий, объектных модулей, текстовых документов, таблиц и т.п. Для хранения некоторых типов данных z/OS требует использовать только библиотечные наборы (PDS или PDSE), как, например, для хранения загрузочных модулей и каталогизированных процедур. Кроме того, многие системные наборы данных, такие как системный реестр SYS1.PARMLIB, имеют библиотечную организацию.

Характеристика наборов данных

Операционная система z/OS поддерживает работу с наборами данных, различающимися по типу логической организации: последовательными, индексно-последовательными, прямого доступа, библиотечными (PDS и PDSE), наборами данных, использующими метод доступа на основе виртуальной памяти (VSAM), а также наборами данных файловой системы UNIX (HFS, zFS) [11]. Для поддержки наборов данных различных типов в составе DFSMSdfp представлены компоненты, получившие название методы доступа и описанные в п. 5.1.3. Каждый метод доступа ориентирован на работу с наборами данных определенного типа и обеспечивает поддержку необходимых операций для организации ввода-вывода.

Операционная система z/OS обеспечивает обработку наборов данных на уровне логических записей и блоков. Это означает, что набор данных представляется в виде совокупности логических записей, а приложения получают доступ к логическим записям и обрабатывают их как единое целое. В то же время обмен данными между периферийными устройствами и основной памятью (ввод-вывод) осуществляется блоками (или физическими записями). В блоке объединяется некоторое количество логических записей. Таким образом, для каждого набора данных необходимо установить согласованные размеры логических записей и блоков.

В z/OS поддерживаются три формата логических записей: записи фиксированной длины, записи переменной длины, записи неопределенной длины. Записи фиксированной длины имеют постоянный размер и в языке управления заданиями идентифицируются символами F или FB в зависимости от выбранного способа блокирования записей:

F - в каждом блоке содержится только одна логическая запись;FB - каждом блоке может содержаться более одной логической записи.

Записи переменной длины могут иметь различный размер внутри одного набора данных, поэтому помимо данных они включают в себя дополнительное поле (дескриптор), где указывается длина текущей записи. Используемый для обозначения записей переменной длины идентификатор V означает, что в каждом блоке содержится только одна логическая запись, включая дескриптор записи.
Идентификатор VB применяется в тех случаях, если в каждом блоке может содержаться более одной логической записи, при этом для каждого блока дополнительно формируется дескриптор, содержащий длину блока.

Записи неопределенной длины (идентификатор U) характеризуются только размером блока и не содержат никакой информации о делении на логические записи.

Каждый набор данных характеризуется уникальным именем. Имена бывают простые и составные. Простое имя может содержать не более 8 символов (латинские буквы A-Z, цифры 0-9, спецсимволы #,@,$,-), причем первым символом имени не может быть цифра. Например, РАRTS01, B1934-1, $$$$A.

Составное имя набора данных складывается из нескольких простых, разделенных символом "." ("точка"). Например, D.USER1.JCL, А.VERY.LONG.DATASET.NАМЕ, $PARTS.DАTА2.

Максимальная длина составного имени - 44 символа, включая разделительные точки.

Простые имена в составном имени принято называть квалификаторами.

Далее будут рассмотрены основные типы организации наборов данных, за исключением индексно-последовательных и наборов данных прямого доступа (не рекомендованы IBM к использованию как устаревшие) и HFS (будут рассмотрены в п. 5.1.6).

Наборы данных VSAM

В основе наборов данных VSAM (Virtual Storage Access Method) лежит универсальный формат доступа к данным, объединяющий возможности последовательных, индексно-последовательных и наборов данных прямого доступа с применением более эффективной технологии. Управление наборами данных VSAM основано на использовании виртуального адресного пространства для размещения буферов ввода-вывода и управляющих таблиц, а также на применении метода индексирования записей.

Набор данных VSAM (рис. 5.16) состоит из логических записей (R) фиксированной или переменной длины, объединяемых в блоки равного размера. Такие блоки принято называть управляющими интервалами CI

(control interval). Помимо записей управляющий интервал включает системную информацию. Часть пространства CI может оказаться неиспользуемой. Управляющий интервал является единицей обмена данными между виртуальной памятью и диском. Управляющие интервалы, в свою очередь, могут объединяться в управляющие области CA (control area), каждая размером, кратным одному цилиндру. Таким образом, VSAM набор данных может быть представлен совокупностью управляющих областей равного размера.

Рис. 5.16. Обобщенная структура наборов данных VSAM

Набор данных VSAM может быть дополнен индексной составляющей, обеспечивающей доступ к данным по одному или нескольким альтернативным ключам. Совокупность данных и связанных с ними индексных компонентов получила название кластер VSAM. Фактически имя набора данных VSAM - это имя кластера, тогда как сами данные и индексы хранятся в различных, но связанных между собой наборах данных. При этом имя компонента данных дополняется справа квалификатором DATA, а имя индексного набора данных - квалификатором INDEX.

В z/OS поддерживается четыре типа VSAM наборов данных:

ESDS (Entry Sequenced Data Set) - неупорядоченный последовательный набор данных. Для каждой записи формируется относительный номер байта, что обеспечивает последовательный доступ к записям по смещению.KSDS (Key Sequenced Data Set) - последовательный набор данных с ключами.
Состоит из индексного компонента и компонента данных. Обеспечивает прямой доступ к записям по ключу.RRDS (Relative Record Data Set) - набор данных с записями с относительными номерами. Обеспечивает прямой доступ к записям фиксированной длины по номеру.LDS (Linear Data Set) - линейный набор данных, состоит из управляющих интервалов размером 4 КB без деления на логические записи. Управляющие интервалы содержат только данные и не включают системную информацию.

Отметим, что для общности наборы данных типа ESDS, RRDS и LDS также считают кластерами VSAM, в которых индексный компонент не представлен.

Наборы данных VSAM широко используются как для пользовательских, так и для системных нужд. Например, главный каталог z/OS является набором данных типа VSAM, организованным в порядке возрастания ключей (формат KSDS). Линейные наборы данных (LDS) используются в технологии DIV (Data-in-virtual) для отображения наборов данных в виртуальную память. Для создания и обслуживания наборов данных VSAM используется многофункциональная утилита IDCAMS.

Организация каталогов

Каталог - это набор данных, содержащий информацию о местонахождении других наборов данных в системе, независимо от того, на каком носителе (томе) они размещены. В z/OS существуют каталоги двух типов:

главный (master catalog);пользовательские (user catalogs).

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

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

На рис. 5.18 показана схема доступа к каталогизированным наборам данных, основанная на использовании имени набора данных (параметр DSNAME в языке управления заданиями). Здесь возможны два варианта: либо ссылка на набор данных присутствует непосредственно в главном каталоге (как для D.U01.CONT), либо предусмотрено применение пользовательского каталога для наборов данных с определенным значением старшего квалификатора имени (HLQ). В последнем случае главный каталог будет включать специальный элемент - ALIAS, совпадающий со значением HLQ (в нашем случае - CALC) и указывающий на размещение пользовательского каталога (UCAT). Пользовательский каталог в свою очередь содержит ссылки на все наборы данных, имя которых начинается с квалификатора CALC.

Рис. 5.18. Использование каталогов

z/OS поддерживает несколько способов организации каталогов, однако основной из них связан с каталогом формата ICF (Integrated Catalog Facility). ICF каталог состоит из двух компонентов: базовой структуры каталога BCS (basic catalog structure) и наборов данных VVDS.

BCS содержит информацию о томе, владельце, атрибутах безопасности наборов данных и представляет собой набор данных VSAM формата KSDS, при этом имя набора данных играет роль ключа. Для управления доступом к VSAM и SMS управляемым наборам данных часть необходимой информации представлена в наборах данных VVDS, создаваемых на каждом томе, где есть указанные наборы данных. VVDS также является набором данных VSAM (формат ESDS) и содержит информацию о параметрах размещения наборов данных VSAM на томе и характеристики SMS-управляемых наборов данных.

PDSE наборы данных

В z/OS поддерживается расширенный формат библиотечных наборов данных PDSE (Partitioned Data Set Extended), который, сохраняя основные внешние черты и свойства стандартного библиотечного набора данных, реализует более эффективный механизм использования памяти и доступа к данным.

В основе данного механизма лежит представление области внешней памяти, выделенной набору данных, в виде совокупности блоков размером 4 KB. Блоки распределяются между разделами и оглавлением разрывным способом, что дает возможность динамически изменять размеры отдельных разделов и добавлять при необходимости новые блоки к области оглавления. Такой способ исключает необходимость в выполнении операции сжатия, без которой трудно представить использование стандартных библиотечных наборов данных, а также исключает ситуации, связанные с нехваткой памяти в области оглавления.

Для повышения скорости доступа к данным оглавление PDSE имеет индексную организацию. Применяется кэширование оглавления и разделов в виртуальной памяти (пространствах данных и гиперпространствах).

Во многих случаях наборы данных PDSE можно использовать как более эффективную и удобную альтернативу стандартным библиотечным наборам данных. Однако для размещения исполнимых программ, представленных в формате program object (программный объект), используются исключительно наборы данных PDSE (см. п. 5.1.8).

Наборы данных PDSE вплоть до версии OS/390 2.8 могли использоваться только в рамках SMS-технологии, однако в z/OS поддержка PDSE перенесена на уровень MVS.

Последовательные наборы данных

Последовательные наборы данных (Physical Sequential, PS) рассматриваются как совокупность логических записей, которые обрабатываются в том порядке, в каком они были помещены в набор данных (т.е. последовательно). Корректировка последовательного набора данных возможна либо путем полной перезаписи всей информации, либо путем добавления новых логических записей в конец набора данных. Последовательные наборы данных используются чаще всего для хранения относительно больших объемов информации (отчетов о выполненных заданиях, журналов сеанса и т.д.) на любых типах устройств внешней памяти. Причем на ленточных накопителях могут использоваться исключительно последовательные наборы данных. Для обработки последовательных наборов данных в z/OS поддерживается два метода доступа: "базисный" BSAM и "с очередями" QSAM.

В зависимости от используемого типа логических записей и блокирования, поддерживается несколько форматов последовательных наборов данных (рис. 5.14). На рисунке использованы принятые в языке управления заданиями z/OS идентификаторы: RECFM - формат записи, LRECL - длина записи, BLKSIZE - длина блока.

Рис. 5.14. Структура последовательного набора данных

При использовании записей фиксированной длины (форматы F и FB) LRECL определяет размер каждой записи набора данных. Размер блока для формата FB выбирается кратным длине записи.

При использовании записей переменной длины (форматы V и VB) каждая запись включает четырехбайтовый дескриптор RDW, содержащий длину записи. Параметр LRECL определяет максимальную по длине запись с учетом поля дескриптора. Блоки записей переменной длины (формат VB) дополнительно включают четырехбайтовое поле дескриптора BDW, предназначенного для хранения длины блока. Параметр BLKSIZE в этом случае определяет максимальную длину блока.

При использовании записей неопределенной длины (формат U) система не поддерживает деления набора данных на логические записи и производит его обработку блоками фиксированного размера (BLKSIZE).

Распределение внешней памяти для наборов данных non-SMS

Ключевая задача управления данными - выделение пространства внешней памяти для вновь создаваемых наборов данных. В z/OS этот процесс получил название "распределение наборов данных" (data set allocation). Рассмотрим, как решается задача распределения при использовании классической MVS-технологии управления данными.

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

Определение устройства и тома для размещения набора данных.Определение характеристик набора данных и параметров размещения внутри тома.

На первом шаге пользователь указывает устройство внешней памяти и, возможно, определяет том.

Устройство может быть задано одним из трех способов:

номером устройства;типовым именем;групповым именем;

Номер устройства (device number) - это трех- или четырехразрядный физический адрес устройства в шестнадцатеричном представлении. Типовое имя устройства (generic device type) соответствует установленному производителем оборудования номеру модели, однозначно указывающему на тип устройства. Например, номера 3380 и 3390 соответствуют накопителям на жестких магнитных дисках, 3480 и 3490 - накопителям на магнитной ленте, 3270, 3278, 3290 - дисплейным терминалам и т.п. И наконец, групповое имя (esoteric group name) определяет устройство через логическое имя устройства или группы устройств, задаваемое системным программистом на этапе конфигурирования оборудования с помощью компонента HCD. Например, часто используют групповые имена вроде SYSDA, SYSALLDA, TAPE и т.п. Групповые имена устройств хранятся в специальной системной таблице допустимых устройств EDT (eligible device table). Отметим, что в качестве устройства размещения временных наборов данных может быть указан "виртуальный диск", обычно задаваемый групповым именем VIO. Виртуальный диск представляет собой динамически формируемую область виртуальной памяти, выделяемую для временного хранения наборов данных. Использование данного метода, получившего название Virtual Input Output (VIO), возможно лишь при соответствующей настройке EDT.

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

На втором шаге происходит выделение требуемого пространства памяти на выбранном устройстве в соответствии с заданными пользователем параметрами. Пользователь определяет тип и формат записей набора данных, необходимое количество единиц памяти (цилиндров, дорожек, байт), способ размещения (непрерывно в одном экстенте, в нескольких экстентах). Выделением необходимого пространства на диске управляет системный дисковый менеджер DADSM (Direct Access Device Space Manager), использующий значения параметров пользователя и информацию VTOC выбранного тома.

Таким образом, каждый раз, когда создается новый набор данных, пользователь через средства языка управления заданиями (см. п. 5.1.5), либо в режиме диалога (см. п. 5.1.7) должен определить более десятка различных параметров. Среди них есть и такие, которые, с одной стороны, требуют глубокого понимания физической структуры хранения данных, а с другой - достаточно трудно прогнозируемы. Яркий пример - объем выделяемого под набор данных пространства внешней памяти, который для многих типов данных чрезвычайно сложно рассчитать. В этом состоит существенный недостаток MVS-технологии, и это одна из причин перехода к технологии SMS.

SMS-технология управления данными

Технология SMS представляет собой совокупность системных средств и возможностей, автоматизирующих процессы управления ресурсами внешней памяти. SMS использует представленные в рамках компонента DFSMS программные продукты для создания, распределения, перемещения, резервного копирования, восстановления и уничтожения наборов данных таким образом, чтобы обеспечить высокое быстродействие при доступе к данным, эффективное использование внешней памяти, необходимый уровень безопасности и сохранность данных [12].

Одним из важных преимуществ технологии SMS является существенное снижение нагрузки на пользователя при решении задачи распределения новых наборов данных, поскольку выбор значительной части параметров распределения происходит автоматически. Кроме того, в рамках SMS реализован диалоговый интерфейс администратора ISMF (Interactive Storage Management Facility), с помощью которого можно осуществлять настройку функций SMS и формировать собственную политику управления данными и устройствами.

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

классы данных;классы памяти;классы управления;группы памяти.

Класс данных (Data Class) представляет собой именованный список значений параметров, используемых при создании наборов данных, таких как тип набора данных, формат логических записей (RECFM), длина записи (LRECL), размер блока (BLKSIZE), параметры выделяемого пространства памяти (SPACE), срок хранения, VSAM-атрибуты и др.

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

Класс управления (Management Class) определяет требования к обслуживанию наборов данных или целых томов средствами DFSMS, включая контроль длительности хранения, управление версиями, возможность временного перемещения на менее производительные устройства, периодичность резервного копирования, архивация, восстановление.
Эти параметры используются для автоматического обслуживания наборов данных и томов.

Группа памяти (Storage Group) задает множество (группу) томов, предназначенных для хранения данных определенной категории. Например, может быть назначена группа томов для хранения страничных наборов данных, группа пользовательских томов, группа томов для размещения баз данных DB2 и т.п.

Системный программист (администратор) с помощью диалога ISMF может создавать множества различных классов (групп) указанных типов, различающихся по имени, при этом каждому классу будут соответствовать определенные наборы значений соответствующих параметров. Таким образом, при создании набора данных достаточно указать только имя подходящего класса данных, и система обеспечит его распределение в соответствии с параметрами данного класса. В языке управления заданиями поддерживаются специальные параметры оператора описания данных DD, с помощью которых можно задавать требуемые классы (DATACLAS, STORCLAS, MGMTCLAS и др.)

В то же время SMS позволяет задействовать подготовленные администратором программы автоматического назначения классов ACS

(Automatic Class Selection). Эти программы могут установить принадлежность набора данных к тому или иному классу на основе некоторых внешних атрибутов наборов данных. К таким атрибутам относятся, например, имя набора данных или значения отдельных квалификаторов имени, атрибуты пакетного задания (имя задания или программы), имя пользователя, атрибуты RACF и т.п.

Средства управления данными в z/OS (DFSMS)

Управление данными в z/OS заключается в организации идентификации, хранения, каталогизации, поиска данных различного назначения (в том числе и программ), которые применяются для системных и пользовательских нужд. Основной единицей управления является набор данных (data set), определяемый как именованая совокупность связанных элементов данных, размещаемых во внешней памяти или иных устройствах.

Функции управления данными в z/OS возложены на подсистему управления данными DFSMS (Data Facility Storage Management System), которая включает набор компонентов, представленных в виде пяти модулей [10].

DFSMSdfp (data facility product) - базовый элемент z/OS, реализующий основные функции управления данными и устройствами хранения данных, включая распределение внешней памяти, организацию доступа к данным, поддержку операций над наборами данных, ведение каталогов наборов данных.DFSMSdss (data set service) - средства администрирования данных и устройств внешней памяти на магнитных дисках (резервное копирование, восстановление, дефрагментация);DFSMShsm (hierarchical storage manager) - средства оптимизации хранения наборов данных на различных носителях в зависимости от интенсивности использования и обеспечения сохранности данных;DFSMSrmm (removable media manager) - средства управления сменными носителями (ленточные и оптические устройства);DFSMStvs (transactional VSAM service) - поддержка параллельной обработки наборов данных VSAM для пакетных заданий и транзакций CICS.

Последние четыре модуля являются опциональными.

В z/OS реализованы и параллельно существуют две различные технологии управления данными, условно называемые MVS и SMS. Технология MVS (иногда говорят non-SMS) базируется на применении классических возможностей и методов управления данными, основы которых были заложены еще в OS/360. Главной особенностью данной технологии является непосредственный контроль пользователя над параметрами распределения наборов данных во внешней памяти при их создании. Технология SMS (от System Managed Storage) представляет собой программную надстройку, обеспечивающую комплексное автоматизированное управление наборами данных, включая их создание, размещение и администрирование на основе специально определяемых классов данных. Каждому такому классу приписывается фиксированный набор атрибутов, включая устройство размещения (том), объем выделяемой памяти, характеристики набора данных (тип, структура), параметры обслуживания и защиты и т.п. Использование технологии SMS требует особой системной настройки и специальным образом сконфигурированных томов внешней памяти.

В данном разделе вначале будут представлены базовые понятия и средства, реализованные в технологии MVS, а затем описаны особенности технологии SMS.

Структура тома DASD

Накопители на жестких магнитных дисках, по традиции обозначаемые в z/OS как DASD (Direct Access Storage Device), принадлежат к числу основных устройств внешней памяти, используемых для размещения и хранения как системных, так и пользовательских наборов данных всех типов. При размещении наборов данных на диске пространство внешней памяти выделяется непрерывными свободными блоками, которые называют экстентами

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

Организация размещения наборов данных на томе DASD представлена на рис. 5.17.

Каждый диск содержит специальную область, размещаемую на нулевой дорожке нулевого цилиндра. Эта область называется метка тома (volume label). Именно отсюда система начинает обработку размещенной на диске информации. Метка тома содержит серийный номер тома (фактически это и есть имя тома) и некоторые другие его атрибуты, а также указатель на системный набор данных VTOC.

Набор данных VTOC (Volume Table Of Contents) называют оглавлением тома. Он имеет последовательную организацию и служит для описания содержимого тома при помощи записей DSCB (Data Set Control Block) семи типов. Вот некоторые наиболее важные из них:

дескриптор набора данных (первые три экстента) (F1);дескриптор набора данных (дополнительные экстенты) (F3);дескриптор VTOC и признак SMS-управляемого тома (F4);дескриптор свободного пространства (если не используется индексный VTOC) (F5);

Дескриптор типа F1 содержит информацию о параметрах логической организации набора данных (формат и длина записи, размер блока и т.п.).

Рис. 5.17. Структура тома DASD

Для сокращения времени поиска и размещения наборов данных на томе может быть дополнительно создан специальный последовательный набор данных, называемый индекс VTOC (VTOC Index). Он содержит упорядоченные указатели на элементы VTOC, относящиеся к наборам данных (тип F1), а также битовую матрицу свободного пространства диска.

Оглавление тома создается при инициализации (форматировании) тома, для чего служит системная утилита ICKDSF. С ее помощью можно также выполнять операции по проверке и восстановлению тома DASD, создавать индекс VTOC. Если том планируется задействовать для размещения SMS управляемых наборов данных (так говорят, если применяется SMS-технология управления данными), то он инициализируется особым образом.

Еще один системный набор данных, который используется для организации доступа к данным дискового тома, получил название VVDS или VSAM Volume Data Set. Он создается на каждом томе, включающем наборы данных типа VSAM или SMS-управляемые наборы данных любого типа, и содержит дополнительные атрибуты их размещения. VVDS используется как часть системного каталога, о чем речь пойдет ниже.