DB2 - Connectivité - Informations complémentaires

Présentation de DB2 pour VM

Chaque système de gestion de bases de données DB2 pour VM peut gérer une ou plusieurs bases de données (une à la fois) et est identifié par le nom de la base de données en cours de traitement. Ce nom de base de données relationnelle est unique dans un ensemble de réseaux SNA interconnectés.

Les différents composants DRDA et VM concernés par le traitement d'une base de données répartie sont décrits ci-après. Ces composants permettent aux systèmes de gestion de bases de données DB2 pour VM d'accéder à des bases relationnelles locales et de communiquer avec des systèmes DRDA éloignés dans le réseau SNA.

AVS
Le support APPC/VTAM (AVS) est un composant de VM qui permet aux applications d'accéder au réseau SNA. Il fournit la fonction de LU telle qu'elle est définie par SNA. Une LU est appelée passerelle en environnement VM. AVS s'exécute dans un système de contrôle de groupe telle qu'une application VTAM. Il convertit les appels de macros APPC/VM en appels de macros APPC/VTAM et inversement. APPC/VM utilise AVS pour acheminer et convertir les flots de données. Grâce à AVS, les requêtes DB2 pour VM sont acheminées entre le système VM local et les emplacements SNA éloignés. AVS doit être utilisé chaque fois que des applications ou des bases de données DB2 pour VM communiquent avec des bases de données ou des applications d'un autre type.

Au niveau du demandeur d'application, l'utilisateur doit être autorisé à se connecter via la passerelle AVS avant tout envoi de requête. Dans le cas du serveur d'applications, la passerelle AVS en réception doit être également autorisée à se connecter à un serveur DB2 pour VM avant de pouvoir prendre en compte les requêtes des utilisateurs. L'autorisation est obtenue en fournissant les instructions de contrôle de répertoire IUCV appropriées à la machine utilisateur, à la machine de la base de données et aux machines AVS émettrices et réceptrices. Pour les détails sur la procédure à suivre, reportez-vous au manuel VM/ESA Connectivity Planning, Administration, and Operation.

APPC/VM
APPC/VM est une API de niveau assembleur qui fournit un sous-ensemble de la fonction LU 6.2 tel qu'il est défini par SNA. En termes pratiques, elle fournit les instructions LU 6.2 qui permettent aux applications DB2 pour VM de se connecter à des systèmes de gestion de bases de données locaux et éloignés et de s'exécuter dans ces systèmes. Les instructions LU 6.2 prises en charge par APPC/VM sont indiquées dans le manuel VM/ESA CP Programming Services.

Répertoire de communication
Le répertoire de communications est un fichier CMS NAMES qui joue un rôle spécifique dans l'établissement des conversations APPC entre un demandeur d'application VM local et un serveur d'applications. Le répertoire fournit les informations nécessaires à l'acheminement et à l'établissement d'une conversation APPC avec un serveur cible. Ces informations sont le nom de LU, le nom de programme transactionnel, la sécurité, le nom de mode, l'ID utilisateur, le mot de passe et le nom de la base de données.

DB2 pour VM utilise la marque COMDIR :dbname pour associer le nom RDB_NAME aux données de routage correspondantes.

Ce fichier spécial et sa fonction de communication sont décrits dans le manuel VM/ESA Connectivity Planning, Administration, and Operation.

CRR
CRR (récupération coordonnée des ressources) est une fonction de VM qui coordonne la validation ou la restitution des mises à jour de ressources protégées. Les programmes d'application répartis, associés à CRR, utilisent des conversations protégées pour assurer l'intégrité des ressources de transactions réparties.

CRR Recovery Server
Le serveur de récupération CRR est un composant de la fonction CRR fonctionnant sur sa propre machine virtuelle. Il est chargé de la fonction de journalisation des points de synchronisation et de la fonction de resynchronisation.

GCS
Le système de contrôle de groupe est un composant comprenant les éléments suivants :

Adaptateur de ressources
L'adaptateur de ressources est une partie du programme logique DB2 pour VM qui réside dans votre machine virtuelle et qui permet à votre application de demander l'accès à un serveur DB2 pour VM. La fonction demandeur d'application DRDA est intégrée à l'adaptateur de ressources.

TSAF
La fonction transparente d'accès est un composant de VM qui fournit un support de communication entre des systèmes VM interconnectés. Un groupe TSAF admet jusqu'à huit systèmes VM, qui peuvent être considérés comme analogues, pour la connexion à un réseau local VM (ou à un grand réseau). Chaque système VM participant doit disposer d'une machine virtuelle TSAF en cours de fonctionnement. Dans un groupe TSAF, tous les ID utilisateur et les ID ressource sont uniques.

DB2 pour VM utilise TSAF pour acheminer les requêtes portant sur des bases de données réparties vers d'autres machines DB2 pour VM au sein d'un groupe TSAF. Si le système VM local ne dispose pas de machine virtuelle AVS, DB2 pour VM utilise TSAF pour l'acheminement des requêtes DRDA vers un système VM ne disposant pas d'une machine virtuelle AVS. AVS permet de faire suivre les requêtes vers d'autres groupes TSAF et des systèmes autres que DB2 pour VM.

Un groupe TSAF est considéré comme une ou plusieurs unités logiques dans un réseau SNA. L'accès aux ressources définies comme globales dans le groupe TSAF peut être effectué via des programmes APPC éloignés résidant en un point quelconque du groupe.

En principe, un groupe TSAF s'exécute en mode autonome, indépendamment de VTAM et du réseau SNA. Cependant, il peut coopérer avec AVS et VTAM pour rendre ses ressources globales accessibles par les programmes APPC éloignés résidant en un point quelconque du réseau SNA. Pour cela, vous devez disposer d'une machine AVS et d'une machine VTAM s'exécutant sur un ou plusieurs membres TSAF. La fonction TSAF est décrite dans le manuel VM/ESA Connectivity Planning, Administration, and Operation.

VTAM
La méthode d'accès virtuelle en télétraitement (VTAM) fournit le support de communication de réseau pour la connectivité. DB2 pour VM utilise les fonctions VTAM via AVS pour acheminer les connexions et les requêtes vers les systèmes DRDA éloignés. La fonction VTAM est utilisée uniquement pour les demandes éloignées d'accès au réseau SNA.

*IDENT
AVS et TSAF utilisent le nom de programme transactionnel (TPN) pour acheminer les requêtes entre les systèmes VM qui sont connectés via TSAF et AVS. Il peut s'agir d'un nom de programme transactionnel enregistré sous SNA ou d'un nom alphanumérique correct. VM considère le nom de programme transactionnel comme un ID ressource. Pour accéder aux systèmes DRDA éloignés, le serveur DB2 pour VM utilise le service système VM IDENTIFY (*IDENT) pour se définir comme gestionnaire d'un ID ressource global (TPN). Une fois que le serveur est identifié comme ressource globale, TSAF et AVS peuvent acheminer les requêtes DRDA vers le serveur DB2 pour VM si le nom de programme transactionnel reçu correspond à l'ID ressource.

Communications du demandeur d'application - exemple

L'exemple suivant illustre le rôle joué par chaque composant dans l'établissement des communications entre un demandeur d'application VM et un serveur DRDA éloigné. La Figure 27, illustre comment un demandeur d'application se connecte à AVS et utilise VTAM pour accéder au réseau SNA. Les ressources éloignées ne sont pas acheminées vers le serveur d'applications DB2 pour VM local.

Figure 27. Demande d'accès à une ressource éloignée

                                                                          
                                                                         
 

REQTEXT

Supposez qu'un demandeur d'application DB2 pour VM s'exécutant dans un groupe TSAF doive accéder à des données éloignées gérées par un serveur d'applications DRDA. Par définition, cela implique qu'une machine TSAF fonctionne sur l'hôte VM local où se trouve le demandeur d'application. En outre un composant AVS et une machine VTAM s'exécutent sur un système VM dans ce groupe TSAF. AVS et VTAM peuvent également résider sur le même système que le demandeur et le serveur d'applications.

Une fois la machine VTAM démarrée, elle définit une passerelle AVS locale vers le réseau SNA et active une ou plusieurs sessions qui seront utilisées ultérieurement pour l'établissement des conversations.

Une fois la machine AVS démarrée, elle négocie le nombre maximal de sessions pouvant être ouvertes entre la passerelle AVS locale et les LU partenaires potentielles.

Le serveur d'applications peut être actif ou inactif. L'opérateur peut le démarrer avant de traiter les requêtes à partir d'un demandeur d'application du même type ou de type différent.

Le demandeur d'application émet une instruction APPC/VM CONNECT pour établir une conversation de type LU 6.2 avec le serveur d'applications. La fonction CONNECT utilise le répertoire de communications CMS pour remplacer le nom de la base de données relationnelle par les noms de LU et de programme transactionnel appropriés comprenant l'adresse du serveur d'applications dans le réseau SNA. Le répertoire de communications CMS détermine également le niveau de sécurité de la conversation et les anneaux de sécurité, tels que l'ID utilisateur et le mot de passe pour accéder au site éloigné dans le cadre de la gestion des autorisations. Si vous utilisez le paramètre SECURITY=PGM, le demandeur d'application doit transférer l'ID utilisateur et le mot de passe au serveur d'applications. Vous pouvez indiquer l'ID utilisateur et le mot de passe dans le répertoire de communications CMS ou dans l'enregistrement APPCPASS défini dans le répertoire CP de l'utilisateur du demandeur d'application. Si vous utilisez le paramètre SECURITY=SAME, seul l'ID connexion VM du demandeur d'application est envoyé au serveur d'applications et aucun autre mot de passe n'est requis.

Par exemple, si vous utilisez le paramètre SECURITY=SAME, l'hôte vérifie si une machine AVS s'exécute en local. Si ce n'est pas le cas, l'hôte établit une connexion entre le demandeur d'application et la machine TSAF locale. La machine TSAF locale interroge les autres machines du groupe TSAF pour la machine AVS, puis se connecte à cette dernière.

Le composant AVS du groupe TSAF convertit la demande de connexion APPC/VM en un appel de fonction APPC/VTAM équivalent. AVS utilise ensuite une session existante ou alloue une nouvelle session entre sa passerelle (LU) et la LU éloignée. AVS établit ensuite une conversation avec la LU éloignée, puis transmet le nom de LU, le nom de p utilisateur. Si la LU éloignée est également un système VM, la session et la conversation sont gérées par le composant AVS s'exécutant sur ce système.

Communications du serveur d'applications - exemple

L'exemple suivant illustre le rôle joué par chaque composant dans l'établissement des communications entre un demandeur d'application éloigné et un serveur DRDA DB2 pour VM local. La Figure 28 illustre comment VTAM achemine la connexion entrante vers la passerelle AVS spécifique, puis vers le serveur d'applications.

Figure 28. Accès à une ressource éloignée

                                                                          
                                                                         
 

REQTEXT

Supposons qu'un serveur d'applications DB2 pour VM fonctionne dans un groupe TSAF. Par définition, cela implique qu'une machine TSAF fonctionne sur l'hôte VM local où se trouve le serveur d'applications. En outre un composant AVS et une machine VTAM s'exécutent sur un système VM dans ce groupe TSAF. AVS et VTAM peuvent également résider sur le même système que le demandeur et le serveur d'applications.

Une fois la machine VTAM démarrée, elle définit une passerelle AVS locale vers le réseau SNA et active une ou plusieurs sessions qui seront utilisées ultérieurement pour l'établissement des conversations.

Une fois la machine AVS démarrée, elle négocie le nombre maximal de sessions pouvant être ouvertes entre la passerelle AVS locale et les LU partenaires potentielles.

Le serveur d'applications peut être actif ou inactif. L'opérateur peut le démarrer avant de traiter les requêtes à partir d'un demandeur d'application du même type ou de type différent. Une fois le serveur d'applications démarré, il utilise le service *IDENT pour enregistrer l'ID ressource qu'il gère avec le système VM hôte. Chaque enregistrement crée une entrée dans une table de ressource interne maintenue par le système VM.

Une fois que le composant AVS local a établi la session avec sa LU partenaire, il accepte la conversation et transmet le TPN, l'ID utilisateur et le mot de passe à l'hôte VM pour validation. VM recherche alors le nom de programme transactionnel dans sa propre table de ressources internes. Cette table contient une entrée pour chaque ID ressource enregistré via le service système *IDENT. Si la recherche TPN aboutit, VM valide l'ID utilisateur et le mot de passe dans son répertoire, RACF ou un produit de sécurité similaire. Si la validation aboutit, AVS établit une connexion au serveur d'applications et lui transmet l'ID utilisateur dans le cadre des autorisations d'accès à la base de données.

Si la recherche dans la table n'aboutit pas, AVS suppose que le nom de programme transactionnel réside sur un autre système VM du groupe TSAF et établit une connexion à la machine TSAF locale, lui transmet l'ID utilisateur, le mot de passe et le nom de programme transactionnel. La machine TSAF interroge les autres machines du groupe TSAF. Si l'une de ces machines décèle la présence du nom de programme transactionnel dans sa table de ressource, la machine TSAF locale se connecte à la machine TSAF éloignée et lui transmet l'ID utilisateur et le mot de passe à vérifier avec son répertoire VM. Si la validation aboutit, la machine TSAF éloignée se connecte au serveur d'applications et lui transmet l'ID utilisateur en guise d'autorisation d'accès à la base de données.

Si le demandeur d'application souhaite bénéficier du support d'unité d'oeuvre répartie DRDA, il établit une conversation protégée (SYNCLEVEL=SYNCPT) avec le serveur d'applications DB2 pour VM. Avant d'afficher la fenêtre de connexion de DB2 pour VM, CMS crée une unité d'oeuvre CMS pour la conversation protégée sur la machine DB2 pour VM. DB2 pour VM utilise alors cette unité d'oeuvre CMS à chaque fois qu'il exécute un travail pour le demandeur. Lorsque DB2 pour VM commence à exécuter ce travail, il enregistre cette unité d'oeuvre CMS auprès du gestionnaire de point de synchronisation. Ensuite, lorsque DB2 reçoit une indication de validation (COMMIT) ou d'annulation (ROLLBACK) sur la conversation protégée, il demande au gestionnaire du point de synchronisation CRR de valider ou d'annuler l'unité d'oeuvre. Le gestionnaire du point de synchronisation CRR exécute ensuite la validation ou l'annulation, en demandant au serveur de récupération CRR d'effectuer une journalisation du point de synchronisation si nécessaire.

En fonction de la complexité du routage de la connexion, la conversation APPC entre le demandeur d'application et le serveur d'applications peut nécessiter l'utilisation de systèmes supplémentaires. Toutefois, toutes les connexions intermédiaires sont gérées par VM et sont transparentes pour le demandeur d'application ou l'application de l'utilisateur. L'interface APPC/VM permet aux serveurs d'applications DB2 pour VM de communiquer avec les programmes APPC se trouvant dans :


[ Début de page | Page précédente | Page suivante | Table des matières | Index ]