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

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

В расширенной общей области выделяется дополнительная виртуальная память для перечисленных областей с расположением относительно границы 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 в свою очередь делится на три подобласти:

Область общих сервисов 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. В приватной области выделяются следующие элементы:

Регион пользователя предназначен для размещения пользовательских приложений и данных. После загрузки программ в регион пользователя система исключает из использования оставшиеся незанятыми страницы до поступления запроса на выделение дополнительных страниц в данном регионе. У пользователя есть возможность управлять размером региона с помощью одноименного параметра 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-разрядного виртуального адресного пространства, которая включает следующие области:

При освоении новых объемов памяти полезно напомнить используемые единицы измерения: 1 терабайт (TB) равен 2⁴⁰ байт или 1024 GB, 1 петабайт (PB) равен 2⁵⁰ байт или 1024 TB, 1 экзабайт (EB) равен 2⁶⁰ байт или 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

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

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

Базовый системный код (ядро 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В основе системы организации ввода-вывода в 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 на этапе начальной загрузки и инициализации (см. выше).

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

Приложение 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 поддерживается несколько методов доступа, предназначенных для обслуживания наборов данных и устройств определенного типа. Чаще всего используются следующие методы доступа:

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

Наряду с выполнением представленных выше функций программа метода доступа создает управляющие блоки 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 канальной подсистемой, выполняя следующие функции:

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

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

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

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

WLM реализует эффективную модель управления нагрузкой, получившую название " целевой режим " (goal mode) и основанную на выборе и описании ожидаемых целей функционирования для каждой из выполняемых работ . Отметим, что одновременно вплоть до 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 производит выбор путем их "взвешивания" на основе заданных целей и показателей важности. Менеджер управления рабочей нагрузкой принимает участие в реализации всех важнейших системных механизмов, включая:

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

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

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

При управлении ресурсами системы существенную роль играют еще два компонента 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 входят три программных монитора.

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