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

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

372 Глава12

SPUFI осуществляет ввод и вывод файлов, поэтому необходимо наличие двух

предварительно распределенных наборов данных.

• Первый набор данных, который может иметь имя ZPROF.SPUFI.CNTL, обычно

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

содержания или сохранения пользовательских запросов в виде разделов. При

использовании последовательного набора данных запись выполнялась бы по-

верх существующего SQL.

• Выходной файл, который может иметь имя ZPROF.SPUFI.OUTPUT, должен быть

последовательным; это означает, что выходные данные следующего запроса

записываются поверх существующего содержимого файла. Если нужно сохра-

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

средства редактирования в меню ISPF.

На рис. 12.6 представлено назначение наборов данных.

Рис 126 НазначениенаборовданныхSPUFI

Обратите внимание на опцию 5, которую можно временно изменить на YES, что-

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

боваться изменить, является максимальное количество извлекаемых строк.

Если установить для опции 5 значение NO и нажать клавишу Enter, SPUFI откроет

входной файл ZPROF.SPUFI.CNTL(DEPT), в котором можно выполнить ввод или ре-

дактирование SQL-оператора. После ввода команды

recov on

и нажатия Enter пре-

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

описанного ранее в этой книге. Экран представлен на рис. 12.7.

Если в профиле установлено CAPS ON, тогда введенный SQL-оператор при нажа-

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

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

Рис 127 Редактированиевходногофайла

Обратите внимание на то, что таблица имеет имя DSN8810.DEPT. Оно представля-

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

лиц, созданные пользователем DSN8810.

Рис 128 ВозвратвпервуюпанельSPUFI

374 Глава12

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

конца, в качестве которого в SQL используется точка с запятой (;), так как это задано в

параметрах по умолчанию (это можно изменить; см. опцию 5 на предыдущем экране).

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

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

Рис 129 ПерваячастьрезультатовзапросавSPUFI

Рис 1210 Второйэкранрезультатов

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

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

F3. Появится экран, представленный на рис. 12.8.

Обратите внимание на звездочку (*) в опции 6, вызванную тем, что редактирова-

ние SQL только что было завершено. Если на данном этапе нажать Enter, произойдет

выполнение SQL-оператора, после чего автоматически откроется выходной файл,

так как в пункте BROWSE OUTPUT установлено значение YES. Первая часть выходных

данных представлена на рис. 12.9.

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

следует нажать F8, после чего появится экран, представленный на рис. 12.10.

Обратите внимание на то, что таблица результатов содержит только один столбец.

Дело в том, что только этот столбец (DEPTNO) был указан в операторе SELECT. Значе-

ния в столбце DEPTNO были извлечены из всех (14) строк таблицы. Было выдано

также несколько сообщений. Одно из них содержит количество извлеченных строк.

Другое указывает, что SQLCODE (код завершения SQL, указывающий успешное или

неуспешное завершение) равен 100, что означает конец файла и отсутствие каких-

либо еще результатов.

Дополнительные сведения. Дополнительные сведения о языке SQL см. в руко-

водстве DB2 UDB for z/OS: SQL Reference. Эту и другие публикации IBM можно найти

на веб-сайте z/OS Internet Library:

http://www.ibm.com/servers/eserver/zseries/zos/bkserv/

129 Программирование приложений для DB2

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

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

4-го поколения (4GL), разработанный в середине 1970-х для использования в DB2. SQL

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

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

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

Для этого SQL встраивается в исходный код языка программирования, такого как

Java, Smalltalk, REXX, C, C++, COBOL, Fortran, PL/I и высокоуровневый ассемблер. Су-

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

статические и динамические.

• Статические.

Статическими SQL-операторами называются полные SQL-операторы, записан

ные внутри исходного кода. В процессе подготовки программы, DB2 опреде-

ляет пути доступа для операторов, и они записываются в DB2. SQL-операторы

не изменяются от одного запуска программы к другому; при этом используют-

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

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

чание. Все SQL-операторы должны иметь путь доступа).

• Динамические.

Динамическими SQL-операторами называются SQL-операторы, частично или

полностью неизвестные на момент написания программы. Только после запус-

376 Глава12

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

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

так как операторы могут изменяться от одного запуска программы к другому.

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

ставляет собой приложение, принимающее динамические SQL-операторы. Это

те операторы, которые вводятся во входном файле. При каждом запуске SPUFI,

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

специальные подготовительные SQL-операторы.

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

о процессах, происходящих при использовании DB2. Добавим, что все может выглядеть

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

1291 Подготовка программы в DB2: алгоритм

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

тирования связей, при подготовке SQL-кода должен включать дополнительные этапы,

так как компиляторы не распознают SQL. Эти этапы, наряду с компиляцией и редак-

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

ключением вызова DCLGEN, обычно выполняется в одном потоке заданий JCL. При

чтении объяснений см. рис. 12.11.

DCLGEN

DCLGEN представляет способ автоматического генерирования исходных определе-

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

теки DCLGEN, которую можно включить в вашу исходную программу. Если ее не

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

ных DB2 обычно создает их на основе правил компании. На этом этапе необходима

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

Прекомпиляция

Так как компиляторы не могут обрабатывать SQL-код, на этапе прекомпиляции SQL-

выражения заключаются в комментарии, подставляя оператор CALL обращения к DB2.

Он передает некоторые параметры, например, адреса переменных основного языка

(для извлечения данных), номера операторов и (что очень важно) измененную от-

метку времени, называемую маркером согласованности (consistency token; часто на-

зывается просто отметкой времени). На этом этапе не требуется запуск системы DB2;

все выполняется без доступа к DB2.

Прекомпилятор определяет SQL-код по специальным флагам начала и конца, ко-

торые должны быть включены для каждого SQL-оператора. Во всех языках програм-

мирования используется одинаковый флаг начала – EXEC SQL. Флаги конца различа-

ются. В COBOL используется END-EXEC. (точка), тогда как в C и других языках ис-

пользуется точка с запятой. Ниже приведен пример на языке COBOL:

EXEC SQL

SELECT EMPNO, LASTNAME

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

INTO :EMPNO, :LASTNAME

FROM EMP

END-EXEC.

В этом примере, EMPNO и LASTNAME извлекаются в переменные основного языка,

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

переменные, определенные на основном языке (COBOL, PL/1 и т. д.) – языке включа

ющем SQL-код. На этапе вызова DCLGEN также происходит определение этих пере-

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

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

с типом данных, совместимым с типом данных столбца.

Исходная

программа

Прекомпиляция

Включение

раздела

Компиляция

Редактирование

связей

Измененный

исходный

код

Объектный

модуль

Загрузочный

модуль

DBRM

Связывание

Пакет

Связывание

План

DCLGEN

Запуск

Рис 1211 Алгоритмподготовкипрограммы

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

• Измененный исходный код; представляет первоначальный исходный код,

в котором SQL-код заключен в комментарии и замещен операторами CALL.

378 Глава12

• Модуль запросов базы данных (database request module, DBRM), который обыч-

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

программы.

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

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

любой другой программы, не содержащей SQL.

Кстати, можно вставить в программу любой тип SQL-кода: DML, DDL и DCL, если

только не нарушаются правила авторизации.

Связывание

В DB2 связывание можно рассматривать как аналог процесса компиляции для DBRM.

Связывание выполняет три операции.

• Выполняет проверку синтаксиса на наличие ошибок.

• Выполняет проверку полномочий.

• Что важнее всего, определяет пути доступа для операторов. DB2 содержит

компонент, называемый оптимизатором (optimizer), который рассматривает

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

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

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

доступа с наименьшей стоимостью. Такой оптимизатор называется оптимиза-

тором на основе стоимости (в отличие от оптимизатора на основе правил).

SQL-код вместе с путем доступа (и маркером согласованности – отметкой време-

ни) хранится как пакет в оглавлении DB2. Другая информация, в частности инфор-

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

здается исполняемый SQL-код для одного приложения в пакете. Теперь DB2 имеет

всю информацию, необходимую для получения запрашиваемых данных для данной

программы.

Часто программы вызывают подпрограммы, которые также содержат SQL-вызовы.

Каждая из этих подпрограмм также имеет пакет. Необходимо сгруппировать всю ин-

формацию DB2 вместе. Для этого необходим еще один этап: еще одно связывание, но

на этот раз предназначенное для создания плана (plan).

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

может содержать не только информацию о программе, но и другую информацию.

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

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

Для полноты следует добавить, что изначально DBRM связывались непосредствен-

но в планы (они назывались встроенными DBRM). Однако при внесении небольшого

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

плана. Это также необходимо сделать и в случае добавления индекса.

Как вы знаете, в процессе связывания DB2 обновляет свои оглавление и каталог.

Обновление означает недопущение их обновления другими людьми (данные забло-

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

в DB2 является практически невозможным. Для того чтобы обойти это ограничение,

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

были реализованы пакеты. Теперь необходимо только лишь выполнить повторное

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

ствие на других пользователей почти отсутствует. В настоящее время все еще исполь-

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

образование в пакеты.

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

используются.

Запуск

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

память. Когда встречается SQL-оператор, обращение к DB2 (оператор CALL), заменив-

ший SQL-оператор, передает его параметры в DB2. Одним из параметров является мар-

кер согласованности. Этот же маркер (или отметка времени) присутствует и в пакете.

Затем выполняется просмотр пакетов в заданном плане DB2 в поисках наличия соот-

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

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

Последнее замечание: результатом SQL-выражения обычно является результирую-

щее множество (содержащее больше одной строки). Приложение может обрабаты-

вать только одну запись или строку за раз. В DB2 добавляется специальная конструк-

ция, называемая курсором (cursor), который, в сущности, аналогичен указателю

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

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

Дополнительные сведения. Дополнительные сведения см. в публикации DB2

UDB for z/OS: Application Programming and SQL Guide.

1210 Функции IMS Database Manager

Система управления базами данных (СУБД) предоставляет средства доступа транзак-

ций или процессов бизнес-приложений к хранимой информации. Роль СУБД состоит

в том, чтобы обеспечить следующие функции:

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

одной копии данных;

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

всех обновлений;

• уменьшение зависимостей методов доступа от аппаратных устройств и опера-

ционной системы;

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

копии данных.

1211 Структура подсистемы IMS Database

IMS Database Manager представляет собой центральный пункт управления и доступа

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

функций в составе продукта IMS. В этом разделе описываются различные типы адрес-

380 Глава12

ных пространств z/OS и связи между ними. Основой подсистемы IMS является управ-

ляющий регион (control region), запущенный в одном адресном пространстве z/OS.

Он содержит множество зависимых адресных пространств, запущенных в других ре-

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

в которых выполняются IMS-приложения.

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

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

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

Исторически сложилось так, что в некоторых документах, описывающих IMS,

термин «регион» используется для описания адресного пространства z/OS (напри-

мер, управляющий регион IMS). В этой книге термин «регион» используется в соот-

ветствии с общеупотребительным значением. Можно считать термин «регион» сино-

нимом термина «адресное пространство z/OS».

На рис. 12.12 представлена подсистема IMS DB/DC. Дополнительные сведения

см. в книге

An Introduction to IMS (ISBN 0-13-185671-5).

Системное адресное

пространство

Адресное пространство приложения

В сумме не более 99

Система IMS

Отдельное

адресное

пространство

DLI

Регион

DBRC

MPP

IFP

BMP

Приложение Приложение Приложение

Библиотеки IMS

Очереди сообщений IMS

Журналы

Fast Patch DBs

Полнофункциональные

базы данных

RECONs

Адресное

пространство

управляющего

региона

Адресное

пространство

зависимого

региона

Сеть

Рис 1212 СтруктураподсистемыIMSDB/DC

12111 Иерархическая модель базы данных IMS

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

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

отношений между различными типами сущностей.

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

В этой модели отдельные типы сущностей реализуются как сегменты в иерархи-

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

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

приложениями.

Обратите внимание на то, что в IMS использование термина «база данных» не-

сколько отличается от других СУБД. В IMS термин «база данных» используется для

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

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

в IMS база данных приблизительно эквивалентна таблице.

DL/I позволяет использовать большое разнообразие структур данных. Максималь-

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

В иерархической структуре данных может быть определено не больше 15 уровней

сегментов. Не существует ограничений по количеству экземпляров каждого типа сег-

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

Последовательность доступа к сегментам

Переход по иерархии осуществляется сверху вниз, слева направо, спереди назад (для

двойников).

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

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

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

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

порядок их хранения и обработки.

КОРЕНЬ

(1)

Сегмент A2

(8)

Сегмент A1

(2)

Сегмент D3

(9)

Сегмент D2

(4)

Сегмент E3

(7)

Сегмент D1

(3)

Сегмент E2

(6)

Сегмент E1

(5)

Сегмент B2

(14)

Сегмент B1

(10)

Сегмент G2

(12)

Сегмент H1

(13)

Сегмент G1

(11)

Рис 1213 Последовательность