Эбберс М. Введение в современные мейнфреймы: основы z/OS

Подождите немного. Документ загружается.

442 Глава16

166 Следование процессу управления изменениями

Руководство вычислительного центра обычно отвечает за соглашения об уровне

сервиса (SLA) часто посредством команды специалистов или менеджеров по сервису.

Изменение механизмов и практик управления в вычислительном центре выполняет-

ся для обеспечения соответствия SLA.

Реализация любого изменения должна происходить под управлением операторс-

кого персонала. При внедрении в рабочую среду изменений, вызвавших проблемы

или нестабильность, операторский персонал отвечает за наблюдение, отчетность,

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

Хотя чаще всего системные программисты разрабатывают и реализуют собствен-

ные изменения, иногда изменения производятся по запросу через систему управления

изменениями. Все инструкции для операторского персонала или других групп зано-

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

Реализация изменений в бизнес-приложениях обычно выполняется аналитиком

производственного контроля. Изменения в приложениях обычно размещаются в тес

товых библиотеках, и официальный запрос (с контрольной записью) вызывает пере-

нос программ из тестовых библиотек в рабочую среду.

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

всем заинтересованным сторонам. Когда все стороны посчитают описание измене-

ния полным, тогда рассматривается вариант его реализации, вследствие чего оно ли-

бо планируется, либо откладывается, либо отклоняется.

При планировании изменений следует учитывать следующие факторы:

• преимущества, которые даст изменение;

• что произойдет, если изменение не будет выполнено;

• ресурсы, требуемые для реализации изменения;

• относительная важность запроса на изменение в сравнении с другими;

• взаимные зависимости между запросами на изменения.

Любое изменение предполагает риск. Одно из преимущество мэйнфрейма состо-

ит в том, что он обеспечивает очень высокую доступность. Поэтому все изменения

должны подвергаться тщательному контролю и управлению. Значительная часть

времени любого системного программиста занята планированием и оценкой рисков

реализации изменения. Одним из наиболее важных аспектов изменения является на-

личие способа его отмены и перехода к предыдущему состоянию.

1661 Оценка рисков

Как правило, руководство вычислительного центра проводит еженедельное собрание

для обсуждения, утверждения или отклонения изменений. Эти изменения могут от-

носиться к приложениям, системе, сети, оборудованию или электропитанию.

Важной частью любого изменения является оценка рисков (risk assessment), при ко-

торой изменение рассматривается и оценивается с точки зрения риска для системы.

Внесение изменений с невысокими рисками может разрешаться в течение дня, тогда

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

 Обзорсистемногопрограммирования 443

Также в вычислительных центрах часто используются периоды невысокого и вы-

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

ществляет авторизацию операций по кредитным картам, тогда периоды перед круп-

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

занятостью, и внесение изменений в эти периоды может быть запрещено. Кроме то-

го, на предприятиях розничной торговли периодами чрезвычайной занятости могут

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

ИТ-организации достигают своих целей посредством применения организован-

ных процессов и политик управления изменениями. К таким целям относятся:

• высокая доступность сервиса;

• повышенная безопасность;

• готовность аудита;

• снижение расходов.

1662 Система управления регистрацией изменений

Система управления регистрацией изменений (change control record system), как

правило, используется для обеспечения запрашивания, отслеживания и утверждения

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

(problem management system). Например, если в понедельник утром в рабочей систе-

ме возникла серьезная проблема, первым делом нужно рассмотреть изменения, ко-

торые были внесены в выходные дни, чтобы определить, вызвали ли они какие-либо

проблемы.

Регистрация также показывает, что система находится под контролем, что часто

бывает необходимо доказать аудиторам, особенно в секторе финансовых услуг с

сильным регулированием. Закон Сарбейнса-Оксли 2002 года в США, регулирующий

корпоративное управление, оговаривает необходимость эффективной системы внут-

реннего контроля. Эффективное управление изменениями и проблемами в сфере

информационных услуг необходимо для соответствия этому закону. Кроме того,

восьмая директива Закона о компаниях в Европейском Союзе, вокруг которой на мо-

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

и Закон Сарбейнса-Оксли.

По этим причинам прежде чем реализовать какое-либо изменение, как минимум,

должен быть определен набор контролируемых документов, называемых формами

запроса изменений (change request forms). Они должны оговаривать следующее:

• Кто – отдел, группа или человек, требующий изменение, ответственный за

внесение изменения, ответственный за тестирование и ответственный за от-

мену изменения при необходимости, а также ответственные за утверждение

изменений.

• Что – затрагиваемые системы или службы (например электронная почта, фай-

ловая служба, домен и т. д.). Требуется включить максимальное количество

подробностей. В идеале, следует включить полные инструкции, чтобы при не-

обходимости внесение изменений мог выполнить кто-нибудь другой.

• Когда – дата/время начала и приблизительная продолжительность изменения.

444 Глава16

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

• Где – область изменений, т. е. подразделения, здания, отделы или группы, за-

трагиваемые изменением или требующие помощи при изменении.

• Как – план реализации изменений и план отмены изменений при необходимости.

• Приоритет – высокий, средний, низкий, обычный, аварийный, датированный

(например, перевод часов).

• Риск – высокий, средний, низкий.

• Воздействие – что произойдет, если реализовать изменение; что произойдет,

если не реализовать изменение; какие другие системы могут быть затронуты;

что произойдет в случае возникновения неожиданной ситуации.

1663 Производственный контроль

Производственным контролем обычно занимается специализированный персонал, уп-

равляющий планированием пакетных заданий, используя такие инструменты как Tivoli

Workload Scheduler для построения и управления сложным планированием пакетных

задач. Это может включать ежедневное и еженедельное создание резервных копий, вы-

полняемое в определенных точках сложной последовательности пакетов приложений.

При этом также могут отключаться и затем повторно включаться базы данных и опера-

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

контроля часто требуется учитывать национальные праздники и другие особые собы-

тия, например, (в случае предприятий розничной торговли) зимнюю распродажу.

Аналитики производственного контроля отвечают также за перенос последней

версии программы в рабочую среду. Это обычно включает перенос исходного кода

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

чего загрузочного модуля и помещение модуля в рабочую загрузочную библиотеку.

JCL копируется и обновляется в соответствии с производственными стандартами

и помещается в соответствующие библиотеки процедур, и пакеты приложений до

бавляются в планировщик заданий.

Кроме того, если требуется выполнить добавление новой библиотеки в linklist или

ее авторизацию, может привлекаться системный программист.

167 Конфигурирование консолей

Управление z/OS включает управление оборудованием, в частности – процессорами и

периферийными устройствами (включая консоли, на которых работают операторы),

а также программным обеспечением, в частности – операционной системой z/OS, под

системой ввода заданий, подсистемами, управляющими автоматизированными опера-

циями (например NetView

), и всеми приложениями, выполняющимися в z/OS.

Управление системой z/OS включает следующее:

• обработку сообщений и команд, составляющую основу взаимодействия опера-

тора с z/OS и основу автоматизации z/OS;

• консольные операции, определяющие способ взаимодействия операторов с z/

OS для мониторинга или управления аппаратным и программным обеспече-

нием.

 Обзорсистемногопрограммирования 445

При планировании операций в z/OS требуется учитывать, как операторы исполь-

зуют консоли для выполнения своей работы, и как управлять сообщениями и коман-

дами. Системному программисту нужно убедиться в том, что операторы получают на

своих консолях требуемые сообщения для выполнения своих задач, и выбрать соот-

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

ки сообщений.

С точки зрения управления z/OS при планировании важно учитывать, каким об-

разом инсталляция осуществляет консольное восстановление, а также должен ли

оператор перезагружать систему для изменения опций обработки.

Так как сообщения также являются основой для автоматизированных операций,

системный программист должен понимать принципы обработки сообщений для

планирования автоматизации в z/OS.

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

становится необходимость согласования операционной деятельности этих систем.

Даже в единичных системах z/OS инсталляции нужно контролировать связь между

функциональными областями.

Как в односистемных, так и в многосистемных средах команды, вводимые опера-

торами с консолей, могут представлять угрозу безопасности и требуют тщательного

согласования. Как планировщику, системному программисту нужно быть уверенным

в квалификации операторов z/OS.

Консольная конфигурация (console configuration) содержит различные консоли,

используемые операторами для связи с z/OS. Инсталляция сначала определяет уст-

ройства ввода-вывода, которые она может использовать как консоли через Hardware

Configuration Definition (HCD) – интерактивный интерфейс хоста, позволяющий

системному программисту определять аппаратную конфигурацию для канальной

подсистемы и операционной системы.

Hardware Configuration Manager (HCM) представляет собой графический пользо-

вательский интерфейс для HCD. HCM взаимодействует с HCD в клиент-серверном

режиме (т. е. HCM работает на рабочей станции, и HCD выполняется на хосте). Базо-

вые системы требуют наличия внутренней модели подключений к устройствам, од

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

поддержка (и дополнение) этой модели в визуальном формате. HCM обеспечивает

синхронизацию конфигурационных данных в файле на рабочей станции с IODF на

хосте. Несмотря на то, что можно использовать HCD непосредственно для задач кон-

фигурирования оборудования, многие клиенты предпочитают использовать исклю-

чительно HCM из-за графического интерфейса.

Помимо HCD, после определения устройств операционной системе z/OS сообща-

ется, какие устройства следует использовать как консоли, путем указания соответс-

твующих номеров устройств в разделе CONSOLxx библиотеки PARMLIB.

Как правило, операторы в системе z/OS получают сообщения и вводят команды

в консолях MCS и SMCS. Они могут использовать другие консоли (например, консоли

NetView) для взаимодействия с z/OS, однако в данной книге мы рассматриваем кон-

соли MCS, SMCS и EMCS, так как они чаще всего используются в вычислительных

центрах, работающих с z/OS.

446 Глава16

Консоли MCS (Multiple Console Support, MCS) представляют собой устройства с ло-

кальным подключением к системе z/OS, обеспечивающие базовые средства связи

между операторами и z/OS. Консоли MCS подключены к управляющим устройствам,

не поддерживающим сетевую архитектуру систем или протоколы SNA.

Консоли SMCS (SNA Multiple Console Support) представляют собой устройства, кото-

рые не должны быть локально подключены к системе z/OS, обеспечивающие базовые

средства связи между операторами и z/OS. Консоли SMCS используют z/OS Communi-

cations Server для обеспечения связи между операторами и z/OS вместо прямого вво-

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

Консоли EMCS (Extended Multiple Console Support) представляют собой устройства

(отличные от консолей MCS и SMCS), в которых операторы или программы могут

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

конфигурации позволяет системным программистам расширять количество консо-

лей за максимально допустимый предел для консолей MCS, равный 99 для каждой

системы z/OS в сисплексе.

Системная

консоль

(подключена

к контроллеру

процессора)

Консоль

MCS

Консоль MCS вывода

состояния MCS

Консоль MCS потока

сообщений MCS

Консоль

SMCS

Сеанс

TSO/E с SDSF

Сеанс

TSO/E с RMF

Консоль

EMCS

Консоль

NetView

MVS

VTAM

(SMCS)

TSO/E

Рис 165 Примерконсольнойконфигурациидлясистемыz/OS

Системный программист определяет эти консоли в конфигурации в соответствии

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

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

 Обзорсистемногопрограммирования 447

пать в качестве монитора для вывода сообщений оператору, работающему в некото-

рой функциональной области, например, с библиотекой пулов магнитных лент, или

для вывода сообщений о принтерах, установленных в инсталляции.

На рис. 16.5 показана консольная конфигурация для системы z/OS, включающая

системную консоль, консоль SMCS, NetView и TSO/E.

Функции системной консоли входят в консоль управления аппаратными сред-

ствами (Hardware Management Console, HMC). Оператор может использовать систем-

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

восстановления, когда другие консоли недоступны.

Помимо консолей MCS и SMCS, система z/OS, представленная на рис. 16.5, содер-

жит консоль NetView, определенную в ней. NetView работает с системными сообще-

ниями и командными списками при автоматизации задач оператора z/OS. Многие

системные операции можно контролировать с консоли NetView.

Пользователи могут осуществлять мониторинг многих системных функций z/OS

с терминалов TSO/E. Используя средство SDSF (System Display and Search Facility)

и средство RMF™ (Resource Measurement Facility), пользователи TSO/E могут осущест

влять мониторинг z/OS и реагировать на проблемы балансировки нагрузки и произ-

водительности. Авторизованный пользователь TSO/E может также инициировать се-

анс расширенной консоли MCS (EMCS) для взаимодействия с z/OS.

На рис. 16.5 показаны следующие консоли MCS:

• Консоль MCS, с которой оператор может просматривать сообщения и вводить

команды z/OS. Эта консоль работает в полнофункциональном режиме, так как

она может получать сообщения и принимать команды. Оператор может конт-

ролировать операции системы z/OS с консоли MCS или SMCS.

• Консоль MCS вывода состояния.

Оператор может просматривать информацию о состоянии системы, используя

команды DEVSERV, DISPLAY, TRACK или CONFIG. Однако так как эта консоль

является консолью вывода состояния, оператор не может вводить команды

с консоли. Оператор в полнофункциональном режиме консоли может вводить

эти команды и направлять выходные данные для просмотра на консоль вывода

состояния.

• Консоль MCS потока сообщений.

Консоль потока сообщений может выводить системные сообщения. Оператор

может просматривать сообщения, направленные на эту консоль. Однако эта

консоль является консолью потока сообщений, поэтому оператор не может вво-

дить команды через нее. Коды перенаправления (routing codes) и уровень ин-

формации сообщений для консоли определяется таким образом, чтобы система

могла направлять требуемые сообщения для вывода на экран консоли. Таким об-

разом, оператор, отвечающий за функциональную область, например, за библи-

отеку пулов магнитных лент, может просматривать сообщения MOUNT.

Во многих инсталляциях вместо того, чтобы использовать большое количество

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

на одном многооконном дисплее. Как правило, консоль аппаратных средств исполь-

448 Глава16

зуется отдельно, но большинство других терминалов объединяется. Управление сис-

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

системы автоматизации.

IBM Open Systems Adapter-Express Integrated Console Controller (OSA-ICC) пред-

ставляет собой современный способ объединения консолей. OSA-ICC использует

TCP/IP-соединения через Ethernet LAN для подключения к персональным компьюте-

рам как к консолям через подключение TN3270 (telnet).

168 Инициализация системы

Начальная загрузка (initial program load, IPL) представляет собой акт загрузки ко-

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

Системы z/OS предназначены для непрерывной работы в течение многих месяцев

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

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

вень изменений в системе определяет график перезагрузки. Например:

• Тестовую систему можно перезагружать ежедневно или даже чаще.

• Банковскую систему высокой доступности можно перезагружать раз в год или

даже реже, чтобы обновить версии программного обеспечения.

• Часто причиной перезагрузок могут быть внешние факторы, например, необ-

ходимость тестирования и обслуживания систем питания в машинном зале.

• Иногда плохо работающее программное обеспечение нерационально исполь-

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

однако такое поведение обычно подлежит изучению и коррекции.

Многие изменения, которые в прошлом требовали перезагрузки, теперь можно

реализовывать динамически. Примеры таких изменений:

• добавление библиотеки в linklist для подсистемы, такой как CICS;

• добавление модулей в LPA.

z/OS перезагружается с использованием консоли управления аппаратными средс-

твами (Hardware Management Console, HMC). Для перезагрузки z/OS необходимо пре-

доставить следующую информацию:

• адрес устройства загрузочного тома;

• раздел LOADxx, содержащий указатели на системные параметры;

• набор данных IODF, содержащий конфигурационную информацию;

• адрес устройства тома IODF.

1681 Процесс инициализации

Процесс инициализации системы (рис. 16.6) готовит программу управления систе-

мой и ее среду к выполнению работы данной инсталляции. Этот процесс состоит из

следующих этапов:

• инициализация системы и памяти, включая создание адресных пространств

системных компонентов;

• инициализация главного планировщика и инициализация подсистемы.

 Обзорсистемногопрограммирования 449

LOADPARM

Начальная

загрузка

(IPL)

Начальный

загрузчик (bootstrap)

IPL ccuu

SYSRES

IPL-текст

IODF ccuu

LOADxx

IMSI

Alt

Nuc

1 - 4

5 - 6

Рис 166 Загрузкамашины

После инициализации системы, когда подсистема ввода заданий активна, инстал-

ляция может передавать задания для обработки с использованием команды START,

LOGON или MOUNT.

Процесс инициализации начинается, когда системный программист выбирает

функцию LOAD на консоли HMC. z/OS находит всю включенную и доступную основ-

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

Не все диски, подключенные к CPU, содержат загружаемый код. Диск, содержащий за-

гружаемый код, называется загрузочным (IPLable) диском, а если точнее, SYSRES-томом.

Загрузочные диски содержат начальный загрузчик (bootstrap module) на нулевой

дорожке нулевого цилиндра. При начальной загрузке этот начальный загрузчик за-

гружается в память по нулевому реальному адресу, и ему передается управление. Затем

начальный загрузчик считывает программу управления начальной загрузкой IEAIPL00

(также называемую IPL-текстом) и передает ей управление. Это, в свою очередь, за-

пускает более сложную задачу загрузки и запуска операционной системы.

После загрузки начального загрузчика и передачи управления IEAIPL00, IEAIPL00

готовит среду, подходящую для запуска программ и модулей, составляющих операци-

онную систему, следующим образом:

1. IEAIPL00 очищает основную память, записывая в нее нули, прежде чем определить

области памяти для главного планировщика.

2. IEAIPL00 находит набор данных SYS1.NUCLEUS на SYSRES-томе и загружает с него

набор программ, называемых модулями инициализации ресурсов начальной за-

грузки (IPL Resource Initialization Modules, IRIM).

3. Эти IRIM начинают создавать нормальную среду операционной системы из бло

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

450 Глава16

Некоторые из наиболее важных задач, выполняющихся модулями IRIM, перечис-

лены ниже:

• Чтение информации LOADPARM, вводимой с аппаратной консоли при выпол-

нении команды IPL.

• Поиск тома, заданного в LOADPARM, на котором находится набор данных IODF.

IRIM, сначала пытается найти LOADxx в SYS0.IPLPARM. Если это не удается, вы-

полняется поиск SYS1.IPLPARM и т. д. до SYS9.IPLPARM. Если к этому моменту

раздел LOADxx все еще не найден, поиск продолжается в SYS1.PARMLIB (если

система и там не найдет LOADxx, система переходит в состояние ожидания).

• Если раздел LOADxx найден, он открывается, и из него считывается информа-

ция, включающая суффикс ядра (если он не замещен в LOADPARM), имя глав-

ного каталога и суффикс используемого раздела IEASYSxx.

• Загрузка ядра операционной системы.

• Инициализация виртуальной памяти в адресном пространстве главного плани-

ровщика для областей SQA (System Queue Area), ESQA (Extended SQA), LSQA (Local

SQA) и PSA (Prefixed Save Area). В конце последовательности начальной загрузки

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

• Инициализация управления реальной памятью, включая таблицу сегментов

для главного планировщика, записей таблицы сегментов для областей общей

памяти и таблицы фреймов страниц.

Затем последний из IRIM загружает первую часть программы инициализации ядра

(Nucleus Initialization Program, NIP), которая вызывает модули инициализации ресур-

сов (Resource Initialization Modules, RIM); один из ранних таких модулей запускает

коммуникации с NIP-консолью, определенной в IODF.

Система продолжает процесс инициализации, интерпретируя и действуя в соот-

ветствии с заданными системными параметрами. NIP выполняет следующие основ-

ные функции инициализации:

• Расширяет области SQA и ESQA до размерах, заданных системным параметром SQA.

• Создает перемещаемую область загрузки модулей (pageable link pack area, PLPA)

и расширенную PLPA для «холодного» запуска; сбрасывает таблицы таким об-

разом, чтобы они соответствовали существующей области PLPA и расширен-

ной PLPA для быстрого запуска или «теплого» запуска. Дополнительные сведе-

ния о быстром запуска и «теплом» запуске см. в руководстве z/OS MVS Initializa-

tion and Tuning Reference.

• Загружает модули в фиксированную область загрузки модулей (fixed link pack

area, FLPA) или в расширенную FLPA. Обратите внимание на то, что NIP выпол-

няет эту функцию, только если задан системный параметр FIX.

• Загружает модули в изменяемую область загрузки модулей (modified link pack

area, MLPA) и в расширенную MLPA. Обратите внимание на то, что NIP выпол-

няет эту функцию, только если задан системный параметр MLPA.

• Выделяет виртуальную память для общей системной области (CSA) и расши-

ренной CSA. Объем выделяемой памяти зависит от значений, заданных в сис-

темном параметре CSA при начальной загрузке.

 Обзорсистемногопрограммирования 451

• Защищает от

изменения страницы

NUCMAP, PLPA и расширенную PLPA, MLPA и

расширенную MLPA, FLPA и расширенную FLPA, а также фрагменты ядра.

ПримечаниеИнсталляцияможетотменитьзащитуотизмененияMLPAиFLPAпутемис-

пользованиязначения

NOPROTвсистемныхпараметрахMLPAиFIX

IEASYSnn, раздел PARMLIB, содержит параметры и указатели, контролирующие

направление начальной загрузки. См. Пример 16.6.

Пример 16.6. Фрагмент листинга раздела IEASYS00

File Edit Edit_Settings Menu Utilities Compilers Test Help

-------------------------------------------------------------------

EDIT SYS1.PARMLIB(IEASYS00) - 01.68 Columns 00001 00072

Command ===> Scroll ===> CSR

****** ***************************** Top of Data **********************

000001 ALLOC=00,

000002 APG=07,

000003 CLOCK=00,

000004 CLPA,

000005 CMB=(UNITR,COMM,GRAPH,CHRDR),

000006 CMD=(&CMDLIST1.),

000007 CON=00,

000008 COUPLE=00, WAS FK

000009 CSA=(2M,128M),

000010 DEVSUP=00,

000011 DIAG=00,

000012 DUMP=DASD,

000013 FIX=00,

000014 GRS=STAR,

000015 GRSCNF=ML,

000016 GRSRNL=02,

000017 IOS=00,

000018 LNKAUTH=LNKLST,

000019 LOGCLS=L,

000020 LOGLMT=999999,

000021 LOGREC=SYS1.&SYSNAME..LOGREC,

000022 LPA=(00,L),

000023 MAXUSER=1000,

000024 MSTRJCL=00,

000025 NSYSLX=250,

000026 OMVS=&OMVSPARM.,