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.
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.
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.
GCS supervise l'exécution des applications VTAM telles que AVS dans un environnement VM. Les machines virtuelles s'exécutant sous la supervision de GCS n'utilisent pas CMS.
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.
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
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.
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
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 :