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

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

382 Глава12

Иерархическая структура данных, представленная на рис. 12.13, описывает дан-

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

жению. Она не представляет физического хранения данных. Физическое хранение

не имеет отношения к приложению.

Основным строительным элементом иерархической структуры данных является

отношение типа «родитель-потомок» между сегментами данных, которое также изоб-

ражено на рис. 12.13.

12112 Использование служб z/OS в IMS

Система IMS разработана таким образом, чтобы наилучшим образом использовать

возможности операционной системы z/OS.

• Она выполняется в нескольких адресных пространствах

Подсистемы IMS (за исключением пакетных приложений и утилит IMS/DB)

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

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

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

пространствах дает следующие преимущества:

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

сорном CPC;

возможность параллельной диспетчеризации адресных пространств на

разных процессорах;

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

отказах приложений.

• Она выполняет по несколько задач в каждом адресном пространстве

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

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

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

обслуживания.

• Она использует межпространственные службы z/OS для связи между различ-

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

использует общую системную область z/OS (Common System Area, CSA) для

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

адресных пространств, составляющих подсистему IMS. Это сокращает нагруз-

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

• Она использует интерфейс подсистем z/OS для обнаружения отказа зависи-

мых адресных пространств и предотвращения отмены зависимых адресных

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

DB2 и WebSphere MQ.

• Она может использовать сисплекс z/OS (обсуждается далее в этой книге). Не-

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

сисплекс, осуществляя доступ к одним и тем же базам данных IMS. Это обеспе-

чивает следующие преимущества:

 Системыуправлениябазамиданныхвz/OS 383

o повышение доступности – системы z/OS и подсистемы IMS можно вклю-

чать и отключать, не прерывая обслуживания;

повышение производительности – несколько подсистем IMS могут обслу-

живать гораздо более интенсивную нагрузку.

12113 Эволюция IMS

Изначально, все оперативные приложения IMS/DB использовали IMS/TM в качестве

интерфейса к базе данных. Однако с ростом популярности DB2 многие клиенты на-

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

DB2, продолжая при этом использовать уже существующие приложения. Этим объяс-

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

12114 Пример оперативной обработки

Возвращаясь к примеру туристического агентства, приведенному в главе 11 «Системы

управления транзакциями в z/OS», можно привести следующие примеры IMS-тран-

закций, используемых в авиакомпании:

• некоторые пакетные задания требуют ежедневного обновления, например

платежи, осуществляемые туристическими агентствами и другими клиентами;

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

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

• проверка выполнения (и оплаты) бронирования может осуществляться в опе-

ративном приложении;

• проверка наличия свободных мест.

1212 Заключение

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

жественное дублирование, что может вызвать несогласованность данных. Поэтому

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

(для чтения и изменения) из различных мест. Поддержка согласованности, безопас-

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

работчикам не приходится об этом беспокоиться.

Реляционная база данных представляет основной способ организации данных в сов

ременном деловом мире. В СУБД DB2 производства IBM реализованы такие понятия ре-

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

базе данных (SQL), пустые значения и нормализованная структура. В реляционных базах

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

В DB2 имеет место иерархическая зависимость от основных объектов. В структу-

ре таблицы можно создавать индексы и представления. При удалении таблицы эти

объекты также удаляются. Таблицы находятся в физическом наборе данных, называе-

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

логический набор табличных пространств. К новым объектам схемы в DB2 относятся

UDT, UDF, LOB, триггеры и хранимые процедуры.

384 Глава12

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

Каталог и оглавление содержат метаданные обо всех объектах в РСУБД. Буферные

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

их быстрого извлечения; активные или архивные журналы и BSDS являются способа-

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

Единственным способом доступа к данным в базах данных DB2 является исполь-

зование SQL. SQL не является полным языком программирования, он работает на

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

состоит из трех категорий, реализующих различные функции: DML, DDL и DCL.

На мэйнфреймах для ввода SQL-операторов используется инструмент SPUFI.

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

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

(3GL) не распознают SQL. Прекомпилятор заключает SQL-операторы в комментарии,

копирует их в DBRM, снабжая маркерами согласованности, и заменяет их обращени-

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

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

ется путь доступа и исполняемый SQL-код сохраняется в пакете. После этого пакеты

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

ле передает свой маркер согласованности в DB2 для сопоставления с SQL-кодом

в соответствующем плане и выполнения SQL-кода.

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

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

тор EXPLAIN.

Оператор EXPLAIN определяет путь доступа запроса в целях повышения его про-

изводительности. Операторы EXPLAIN особенно полезны для составления запросов

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

Основные термины в этой главе

Полнофункциональнаябазаданных

DL/I Измененныйисходныйкод

SPUFI SQL SYSADM

EXPLAIN Представление DBMS

Многозадачность Многопоточность Администраторбазыданных

1213 Контрольные вопросы

Чтобы проверить понимание материала этой главы, ответьте на следующие вопросы:

1. Назовите некоторые обязанности администратора базы данных?

2. Какие объекты DB2 определяют физическую область хранения? Это таблицы?

3. Какие сложности могут возникнуть в следующем SQL-операторе?

SELECT *

FROM PAYROLL;

4. Какую категорию SQL вы бы использовали для определения объектов в DB2?

5. Каким образом прекомпилятор обнаруживает SQL-оператор в программе?

 Системыуправлениябазамиданныхвz/OS 385

6. Каким образом загрузочный модуль повторно объединяется с SQL-операторами?

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

Какой процесс создает этот путь доступа?

8. Что такое хранимая процедура?

9. Назовите некоторые обязанности системного администратора?

10. Назовите некоторые обязанности администратора базы данных?

11. Назовите некоторые способы обеспечения безопасности в DB2?

12. Какова структура базы данных в IMS-DB? Опишите ее.

1214 Упражнение 1 – Использование SPUFI

в COBOL-программе

Для выполнения этого упражнения необходимо подключение к DB2.

12141 Этап 1: Создание файлов

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

нительных PDS:

• ZUSER##.DB2.INCLUDE – для хранения DCLGEN;

• ZUSER##.DB2.DBRM – для хранения DBRM.

В качестве базового набора данных можно использовать ZUSER##.LANG.CNTL.

Кроме того, требуется также файл ZUSER##.SPUFI.OUTPUT, представляющий собой

простой файл формата VB с длиной записи 4092 и длиной блока 4096.

12142 Этап 2: DCLGEN

DCLGEN представляет простой способ генерирования COBOL-операторов определе-

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

включить в исходную программу.

Во-первых, в меню DB2I (DB2 Interactive) нужно выбрать D, что соответствует

DB2I Defaults (см. рис. 12.14), и нажать Enter.

На панели DB2I Defaults Panel 1 задайте для опции 3 (Application Language) значе-

ние IBMCOB (рис. 12.15).

Нажмите Enter, и на панели DB2I Defaults Panel 2 задайте значение DEFAULT для

опции 3 (COBOL string delimiter) и значение G для опции 3 (DBCS symbol). Нажмите

Enter (см. рис. 12.16).

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

После нажатия Enter происходит возврат на главную панель DB2I (см. рис. 12.14);

теперь следует выбрать опцию 2 (DCLGEN).

Необходимо наличие уже выделенного целевого набора данных для содержания

определения DCLGEN (ZUSER##.DB2.INCLUDE); он должен быть создан для вас. Если

он отсутствует, перейдите в меню ISPF и создайте файл PDS.

386 Глава12

Рис 1214 МенюDB2

Рис 1215 ПанельDB2IDefaultsPanel1

Рис 1216 ПанельDB2IDefaultpanel2

 Системыуправлениябазамиданныхвz/OS 387

Рис 1217 DCLGEN

Как показано на рис. 12.17, необходимо задать таблицу, владельца таблицы, PDS-

файл и действие ADD. Результирующее сообщение должно иметь следующий вид:

EXECUTION COMPLETE, MEMBER DCLEMP ADDED

*** _

При изменении определения таблицы необходимо также изменить DCLGEN и ис-

пользовать REPLACE.

12143 Этап 3: Тестирование SQL-кода

Перейдите в SPUFI; используйте PDS-файл SPUFI.CNTL. В этом PDS-файле найдите

раздел SELECT. Он представляет SQL-оператор, используемый в программе. Выраже-

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

получить. Кроме того, он позволяет увидеть отделы, заданные в таблице.

Конечно же в более сложных запросах это является общепринятой практикой.

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

SQL-код.

12144 Этап 4: Создание программы

На данном этапе можно создать программу или использовать программу, содержащу-

юся в LANG.SOURCE(COBDB2). Этот пример программы определяет среднюю зарпла-

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

вершить выполнение программы, введите

999

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

• ваши переменные (включите раздел, созданный на этапе 1),

• Укажите SQL-разделители для языка COBOL.

Позиции для их добавления отмечены символами «???».

388 Глава12

12145 Этап 5: Завершение создания программы

Откройте задание LANG.CNTL(COBDB2) и внесите изменения, указанные в начале за-

дания.

Задание содержит следующие шаги:

Шаг PC: представляет этап прекомпиляции в DB2; на этом этапе происходит раз-

деление исходного кода на две части: DBRM и измененный исходный код.

Шаги COB, PLKED и LKED: представляют этапы компиляции и редактирования

связей измененного исходного кода.

Шаг BIND: представляет связывание пакета и плана.

Вопрос: Если бы потребовалось изменить программу, какое связывание можно

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

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

деле (потребуется только лишь изменить SQL).

Шаг Run: запускает программу в пакете для двух отделов: A00 и D21.

12146 Этап 6: Запуск программы из TSO

Вместо того чтобы запускать программу в пакете, попробуйте запустить ее из пригла-

шения TSO READY. Для этого необходимо распределить оба файла для сеанса (это

нужно сделать до запуска задания).

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

TSO alloc da(*) f(sysprint) reuse

tso alloc da(*) f(sysin) reuse

Затем вернитесь в экран DB2I.

Рис 1218 Готовоквыполнению

 Системыуправлениябазамиданныхвz/OS 389

Рис 1219 Выполнениепрограммы

Выберите опцию 6 RUN. Здесь следует ввести имя файла и имя плана (см. рис. 12.18).

 z/OSHTTPServer 391

z/OS HTTP Serer

ЦельКакспециалистувсферемэйнфреймов,вамнужнознать,какимобразом

выполнитьразвертываниевеб-приложениявz/OS,икакнастроитьz/OS

наобслуживаниевеб-задач

Послезавершенияработынадэтойглавойвысможете:

• назватьтрисерверныхрежима;

• описать,чтотакоестатическиеидинамическиевеб-страницы;

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

функции,функциибезопасностиифункциикеширования