Каждый менеджер баз данных DB2 for VM может управлять одной или несколькими базами данных (одной в каждый момент времени); для обращения к нему используется имя базы данных, которой он управляет в настоящий момент. Имя реляционной базы данных уникально в наборе соединенных друг с другом сетей SNA.
Ниже описаны различные компоненты DRDA и VM, участвующие в работе с распределенными базами данных. Эти компоненты позволяют менеджеру баз данных DB2 for VM обращаться к локальным реляционным базам данных и связываться с удаленными системами DRDA в сети SNA.
Чтобы пользователь на стороне реквестера мог посылать требования, он должен иметь полномочия для соединения через шлюз AVS. Чтобы принимающий шлюз AVS на стороне сервера прикладных программ мог передавать эти требования пользователя, он должен иметь полномочия на соединение с компьютером сервера DB2 for VM. Для задания полномочий используются соответствующие управляющие операторы каталога IUCV на компьютере пользователя, на компьютере базы данных, а также на посылающем и принимающем компьютерах AVS. Подробности этой операции описаны в руководстве VM/ESA Connectivity Planning, Administration, and Operation.
DB2 for VM использует тег :dbname каталога связи, чтобы по RDB_NAME получить соответствующие данные маршрутизации.
Этот специальный файл и его использование описаны в руководстве по VM/ESA Connectivity Planning, Administration, and Operation.
GCS управляет выполнением прикладных программ VTAM, таких как AVS в среде VM. Виртуальные машины, работающие под управлением GCS, не используют CMS.
DB2 for VM использует TSAF для передачи требований к распределенной базе данных на другие компьютеры DB2 for VM в собрании TSAF. У локальной системы VM может не быть виртуальной машины AVS;, в таком случае DB2 for VM для передачи требований DRDA на такую систему использует TSAF. AVS позволяет пересылать требования другим собраниям TSAF и системам других типов (не DB2 for VM).
Собрание TSAF выглядит в сети SNA как одно или несколько логических устройств. Ресурсы, определенные в собрании TSAF как глобальные, доступны для удаленных программ APPC, расположенных в этом собрании.
Обычно собрание TSAF работает в автономном режиме, независимо от VTAM и сети SNA. Однако оно может работать совместно с AVS и VTAM, чтобы сделать свои глобальные ресурсы доступными для удаленных программ APPC, расположенных в сети SNA. Для этого машина AVS и машина VTAM должны работать на одном или нескольких членах TSAF. TSAF описывается в руководстве по VM/ESA Connectivity Planning, Administration, and Operation.
В следующем примере показано, какую роль играет каждый компонент в установлении связи между реквестером прикладных программ VM и удаленным сервером DRDA. На Рис. 27 показано, как реквестер прикладных программ соединяется с AVS и использует VTAM для доступа к сети SNA. Обращения к удаленным ресурсам не передаются через локальный сервер прикладных программ DB2 for VM.
Рис. 27. Требование доступа к удаленному ресурсу
Предположим, что реквестер прикладных программ DB2 for VM, работающий в собрании TSAF, обращается к удаленным данным, управляемым сервером прикладных программ DRDA. По определению это означает, что машина TSAF работает на локальном хосте VM, на котором расположен реквестер прикладных программ. Кроме того, компонент AVS и машина VTAM работают в некоторой системе VM в этом собрании TSAF. AVS и VTAM могут также находиться в той же системе, что и реквестер прикладных программ или сервер прикладных программ.
После запуска машины VTAM она определяет локальный шлюз AVS для сети SNA и запускает один или несколько сеансов, используемых в дальнейшем для установления диалогов.
После запуска машины AVS она согласует параметры ограничений для сеансов между шлюзом и возможными LU партнеров.
Сервер прикладных программ может быть активен или неактивен. Оператор должен запустить его, чтобы этот сервер мог обрабатывать требования от реквестеров прикладных программ в таких же системах или в системах других типов.
Реквестер прикладных программ выполняет оператор APPC/VM CONNECT, чтобы установить диалог LU 6.2 с сервером прикладных программ. Функция CONNECT использует каталог связей CMS, чтобы по имени реляционной базы данных найти соответствующие имя LU и TPN, представляющие собой адрес сервера прикладных программ в сети SNA. Каталог связей также определяет уровень защиты диалога и элементы защиты (ID пользователя и пароль), передаваемые на удаленный узел для авторизации. Если используется SECURITY=PGM, реквестер прикладных программ должен передавать серверу прикладных программ ID пользователя и пароль. Можно задать ID пользователя и пароль в каталоге связей CMS или в записи APPCPASS, определенной в каталоге CP реквестера прикладных программ пользователя. Если используется SECURITY=SAME, на сервер прикладных программ передается только ID регистрации VM для реквестера прикладных программ и дополнительный пароль не требуется.
Например, если используется SECURITY=SAME, хост проверяет, работает ли машина AVS в локальной системе. Если это не так, хост устанавливает соединение между реквестером прикладных программ и локальной машиной TSAF. Локальная машина TSAF опрашивает другие машины TSAF в этом собрании TSAF, чтобы найти машину AVS, и затем устанавливает соединение с ней.
Компонент AVS в этом собрании TSAF преобразует требование соединения APPC/VM в вызов его функционального эквивалента APPC/VTAM. Затем AVS использует существующий сеанс или создает новый сеанс между своим шлюзом (LU) и удаленным LU. После этого AVS устанавливает диалог с удаленным LU и передает ему имя LU, TPN, информацию о защите и ID пользователя. Если удаленное LU - это также система VM, эти сеанс и диалог поддерживаются компонентом AVS, работающим в той системе.
В следующем примере показано, какую роль играет каждый компонент в установлении связи между удаленным реквестером прикладных программ и локальным сервером DRDA DB2 for VM. На Рис. 28 показано, как VTAM передает входящие требования на конкретный шлюз AVS и затем на сервер прикладных программ.
Рис. 28. Получение доступа к удаленному ресурсу
Предположим, что сервер прикладных программ DB2 for VM работает в собрании TSAF. По определению это означает, что машина TSAF работает на локальном хосте VM, на котором расположен сервер прикладных программ. Кроме того, компонент AVS и машина VTAM работают в некоторой системе VM в этом собрании TSAF. AVS и VTAM могут также находиться в той же системе, что и реквестер прикладных программ или сервер прикладных программ.
После запуска машины VTAM она определяет локальный шлюз AVS для сети SNA и запускает один или несколько сеансов, используемых в дальнейшем для установления диалогов.
После запуска машины AVS она согласует параметры ограничений для сеансов между шлюзом и возможными LU партнеров.
Сервер прикладных программ может быть активен или неактивен. Оператор должен запустить его, чтобы этот сервер мог обрабатывать требования от реквестеров прикладных программ в таких же системах или в системах других типов. После запуска сервера прикладных программ он использует службу *IDENT, чтобы зарегистрировать на хост-системе VM ID ресурса, поддерживаемый этим сервером. При каждой регистрации создается запись во внутренней таблице ресурсов, поддерживаемой системой VM.
После того, как локальный компонент AVS установит сеанс с LU партнера, он принимает требование на диалог и передает TPN, ID пользователя и пароль на хост VM для проверки. VM ищет это TPN в своей внутренней таблице ресурсов. Эта таблица содержит записи для всех ID ресурсов, зарегистрированных при помощи системной функции *IDENT. Если TPN найдено, VM проверяет данные ID пользователя и пароль по своему каталогу или используя RACF или аналогичный продукт защиты. Если эта проверка успешна, AVS устанавливает соединение с сервером прикладных программ и передает ему ID пользователя для авторизации в базе данных.
Если TPN не найдено в этой таблице, AVS предполагает, что TPN может находиться в другой системе VM в этом собрании TSAF, устанавливает соединение с локальной машиной TSAF и передает ей ID пользователя, пароль и TPN. Машина TSAF опрашивает другие машины TSAF в этом собрании TSAF. Если одна из этих машин подтверждает существование этого TPN в ее таблице ресурсов, локальная машина TSAF соединяется с этой удаленной машиной TSAF и передает ей ID пользователя и пароль для проверки по ее каталогу VM. Если эта проверка успешна, удаленная машина TSAF соединяется с сервером прикладных программ и передает ему ID пользователя для авторизации в базе данных.
Если реквестер прикладных программ хочет использовать преимущества поддержки распределенных единиц работы DRDA, он устанавливает защищенный диалог (такой, как SYNCLEVEL=SYNCPT) с сервером прикладных программ DB2 for VM. Прежде, чем CMS предоставляет соединение DB2 for VM, она создает на машине DB2 for VM единицу работы CMS для защищенного диалога. Затем DB2 for VM использует эту единицу работы CMS при выполнении всех операций для реквестера. Когда DB2 for VM начинает выполнять операции для реквестера, она регистрирует эту единицу работы CMS на менеджере точек синхронизации CRR. Затем, если DB2 получает в этом защищенном диалоге требования "выполнить принятие" или "выполнить откат", она обращается к менеджеру точек синхронизации CRR с требованием выполнить принятие или откат этой единицы работы. После этого менеджер точек синхронизации CRR выполняет принятие или откат, при необходимости обращаясь к серверу восстановления CRR для регистрации точки синхронизации.
В зависимости от сложности маршрута соединения диалог APPC между реквестером и сервером прикладных программ может включать дополнительные системы. Однако все промежуточные соединения управляются системой VM и прозрачны для реквестера прикладных программ или прикладной программы пользователя. Интерфейс APPC/VM позволяет серверам прикладных программ DB2 for VM связываться с программами APPC, расположенными в: