DB2 pour VM met en oeuvre le support du demandeur d'application DRDA en tant que partie intégrante de l'adaptateur de ressources résidant sur la machine virtuelle de l'utilisateur final avec l'application. Vous pouvez utiliser le support du demandeur d'application même si la machine virtuelle du gestionnaire de bases de données locales n'est pas active. Vous pouvez activer le support du demandeur d'application DRDA en exécutant SQLINIT EXEC avec l'option protocol (auto) ou protocol (drda) (reportez-vous à la section Options de précompilation ou d'exécution d'une application).
Lorsque DB2 pour VM est utilisé comme demandeur d'application, il peut se connecter à un serveur d'applications DB2 pour VM ou à tout autre serveur prenant en charge l'architecture DRDA. Si vous souhaitez que le demandeur d'application DB2 pour VM fournisse un accès à la base de données répartie, vous devez prendre en compte les informations suivantes :
La plupart des opérations de traitement exécutées dans un environnement de bases de données réparties nécessitent l'échange de messages avec d'autres sites du réseau. Pour effectuer ce processus correctement, procédez par étapes dans l'ordre suivant :
Le demandeur d'application DB2 pour VM et le serveur d'applications DB2 pour VM sont indépendants l'un de l'autre. Le demandeur d'application DB2 pour VM achemine les demandes de connexion directement vers des serveurs d'applications locaux ou éloignés. Cependant, il ne se définit pas lui-même comme la cible des demandes de connexion entrantes. Seul le serveur d'applications DB2 pour VM peut accepter (ou rejeter) les demandes de connexion entrantes. Par conséquent, le demandeur d'application DB2 pour VM n'identifie pas les valeurs RDB_NAME et TPN pour lui-même, contrairement à DB2 Universal Database for OS/390.
Définissez le demandeur d'application DB2 pour VM sur le réseau SNA, en procédant comme suit :
Des noms de passerelle doivent être définis par le demandeur d'application (des noms de LU par exemple) pour l'acheminement des demandes sortantes dans le réseau. La Figure 30, en présente un exemple. Ces instructions figurent sur la machine virtuelle VTAM. Lorsque VTAM est démarré, les passerelles sont identifiées sur le réseau mais ne sont pas activées tant que la machine virtuelle AVS n'est pas démarrée. Chaque machine virtuelle AVS peut définir plusieurs passerelles sur un système hôte VM.
Figure 30. Exemple de définition de passerelle AVS
VBUILD TYPE=APPL ************************************************************* * * * Gateway Definition for Toronto DB2 for VM System * * * ************************************************************* TORGATE APPL APPC=YES, X AUTHEXIT=YES, X AUTOSES=1, X DMINWNL=10, X DMINWNR=10, X DSESLIM=20, X EAS=9999, X MAXPVT=100K, X MODETAB=RDBMODES, X PARSESS=YES, X SECACPT=ALREADYV, X SYNCLVL=SYNCPT, X VPACING=2 |
La liste suivante décrit les mots clés d'instruction APPL VTAM qui sont applicables aux rubriques du présent manuel. (L'instruction APPL VTAM prend en charge de nombreux autres mots clés non indiqués ici).
DB2 pour VM ne limite pas votre choix au mot clé VERIFY, mais la version VTAM que vous exécutez peut influencer ce choix. Dans un réseau non sécurisé, DB2 pour VM recommande l'utilisation du paramètre VERIFY=REQUIRED. Si vous choisissez VERIFY=OPTIONAL, VTAM effectue la vérification de la LU partenaire uniquement pour les partenaires qui en fournissent le support. VERIFY=REQUIRED permet à VTAM de rejeter les partenaires qui ne peuvent pas effectuer de vérification de LU partenaire.
L'activation de la passerelle s'effectue à partir de la machine virtuelle AVS fonctionnant sur le même hôte (ou d'autres hôtes du même groupe TSAF) comme demandeur d'application DB2 pour VM. Indiquez une commande ACTIVATE GATEWAY GLOBAL dans le profil de la machine AVS ou lancez cette commande en mode interactif à partir de la console d'une machine AVS pour activer automatiquement la passerelle à chaque démarrage du système AVS.
Assurez-vous que la valeur MAXCONN indiquée dans le répertoire CP de la machine sur laquelle se trouve la passerelle AVS est suffisamment élevée pour la prise en charge du nombre total de sessions requises.
Lancez la commande AGW DEACTIVE GATEWAY à partir de la machine virtuelle AVS pour désactiver la passerelle. La définition de la passerelle est conservée. La passerelle peut être réactivée à tout moment à l'aide de la commande AGW ACTIVATE GATEWAY GLOBAL.
Reportez-vous au manuel VM/ESA Connectivity Planning, Administration and Operation pour les formats des commandes AVS.
Le NETID de l'hôte (ou des autres hôtes du même groupe TSAF) où réside le demandeur d'application est fourni par VTAM dès que la demande parvient au réseau. Le NETID est stocké dans le NETID SNA du fichier CMS et réside sur le disque de production DB2 pour VM auquel a accès le demandeur d'application. Le demandeur d'application utilise le NETID pour générer le LUWID qui se transmet au cours de chaque conversation.
Pour définir les systèmes éloignés, enregistrez les noms de LU qui activent VTAM pour localiser la destination de réseau désirée. Lors du démarrage d'AVS, ce dernier identifie globalement les noms de passerelle (noms de LU) disponibles pour l'acheminement des demandes SQL dans le réseau VTAM. Le nom de passerelle doit être unique dans un ensemble de noms de LU reconnus par le système VTAM local, afin que les demandes entrantes et sortantes soient acheminées vers le nom de LU approprié. Ceci constitue le meilleur moyen de s'assurer que le nom de la passerelle est vraiment unique sur le réseau. En outre, le processus de définition de ressource VTAM en est simplifié.
Lorsqu'une application DB2 pour VM demande des données à un système éloigné, DB2 pour VM recherche dans le répertoire de communications CMS les informations suivantes relatives à ce système :
Le répertoire de communications CMS est un fichier CMS de type NAMES, qui est créé et géré par un administrateur système DB2 pour VM. Vous pouvez, comme l'administrateur, créer ce fichier sous XEDIT et ajouter les entrées que vous souhaitez pour identifier chaque partenaire DRDA potentiel. Chaque entrée du répertoire est composée d'un ensemble de marques et des valeurs qui leurs sont associées. La Figure 31 présente un exemple d'entrée. Lorsqu'une recherche est effectuée, la clé de recherche est comparée à la valeur de la marque :dbname pour chaque entrée du fichier, jusqu'à ce qu'une correspondance soit trouvée ou jusqu'à la fin du fichier. Dans l'exemple de la Figure 31, le responsable des ventes à Toronto veut créer un rapport de ventes mensuel pour la succursale de Montréal en accédant à distance à la base de données MONTREAL_SALES.
Figure 31. Exemple d'entrée dans un répertoire de communications CMS
+--------------------------------------------------------------------------------+ | SCOMDIR NAMES A1 V 132 Trunc=132 Size=10 Line=1 Col=1 Alt=8 | |====> | |00001 :nick.MTLSALES | |00002 :tpn.SALES | |00003 :luname.TORGATE MTLGATE | |00004 :modename.BATCH | |00005 :security.PGM | |00006 :userid.SALESMGR | |00007 :password.GREATMTH | |00008 :dbname.MONTREAL_SALES | |00009 | +--------------------------------------------------------------------------------+ |
La marque :tpn identifie le nom du programme transactionnel qui active le serveur d'applications. La première partie de la marque :luname identifie la passerelle AVS (LU locale) utilisée pour l'accès au réseau SNA. La seconde représente le nom de LU éloignée. La marque :modename identifie le mode VTAM qui définit les caractéristiques des sessions allouées entre les LU locales et éloignées. La taille de RU, la régulation et la classe de service (COS) sont des exemples de ces caractéristiques. La marque :security indique le niveau de sécurité à utiliser pour la conversation lors de la connexion du demandeur d'application au serveur d'applications.
Le répertoire de communications CMS se trouve sur un disque système public accessible à tous les demandeurs d'application d'un système VM donné. Tout programme ou produit nécessitant l'accès éloigné via VTAM peut utiliser le répertoire de communications CMS.
Vous pouvez accéder aux deux niveaux du répertoire de communications CMS : système et utilisateur. Par exemple, vous pouvez créer un répertoire sur un disque système public, accessible à tous les demandeurs d'application d'un système VM donné. Vous pouvez également créer votre propre répertoire utilisateur pour remplacer les entrées existantes ou ajouter de nouvelles entrées qui n'apparaissent pas dans le répertoire système. La recherche est effectuée d'abord dans le répertoire utilisateur. En cas d'échec, elle se poursuit dans le répertoire système qui est une extension du répertoire utilisateur ; les recherches y sont effectuées uniquement lorsque les valeurs n'ont pas été trouvées dans le répertoire utilisateur.
Chacun de ces répertoires est identifié auprès de l'application et activé par la commande CMS SET COMDIR. Par exemple, vous pouvez utiliser la séquence de commandes suivante pour identifier les répertoires système et utilisateur (sur les disques S et A, respectivement), mais choisir d'activer uniquement le répertoire système pour les recherches :
SET COMDIR FILE SYSTEM SCOMDIR NAMES S SET COMDIR FILE USER UCOMDIR NAMES A SET COMDIR OFF USER
Le répertoire de communications CMS est décrit en détails dans le manuel VM/ESA Connectivity Planning, Administration and Operation. La commande CMS SET COMDIR est décrite dans le manuel VM/ESA CMS Command Reference.
Dans l'environnement VM, la gestion des communications est effectuée par un ensemble de composants. Ces composants auquel il est fait appel pour les communications de systèmes autres que DRDA sont APPC/VM, le répertoire de communications CMS, TSAF, AVS et VTAM.
APPC/VM est l'API de niveau assembleur de la LU 6.2 que le demandeur d'application DB2 pour VM utilise pour demander des services de communication. Le répertoire de communications CMS fournit les informations d'acheminement et de sécurité du système partenaire réparti. AVS active la passerelle et convertit les flux APPC/VM sortants en flux APPC/VTAM, et les flux APPC/VTAM entrants en flux APPC/VM.
APPC/VM, TSAF et AVS utilisent le répertoire de communications CMS, VTAM et *IDENT pour acheminer les demandes en direction du partenaire DRDA approprié.
Pour permettre à VTAM de communiquer avec les applications partenaires identifiées dans le répertoire de communications CMS, vous devez fournir les informations suivantes :
Lorsqu'un demandeur d'application utilise AVS pour communiquer avec un serveur d'applications éloigné, une connexion est lancée automatiquement. Si cette connexion supplémentaire entraîne le dépassement du nombre maximal de sessions admises, AVS place cette connexion en attente jusqu'à ce qu'une session devienne disponible. Lorsqu'une session devient disponible, AVS attribue la session à la connexion en attente et l'application utilisateur reprend le contrôle des opérations. Pour éviter cette situation, augmentez le nombre maximal de sessions pour permettre l'établissement de connexions supplémentaires en cas d'accroissement des demandes. Assurez-vous également que la valeur MAXCONN indiquée dans le répertoire CP de la machine AVS est suffisamment élevée pour la prise en charge d'un grand nombre de sessions pour les connexions APPC/VM.
Les entrées que vous définissez dans la table de modes VTAM indiquent la taille de RU et la régulation. Si ces valeurs ne sont pas mentionnées correctement, des effets indésirables peuvent se produire pour toutes les applications VTAM.
Une fois que vous avez choisi la taille de RU, le nombre maximal de sessions et la régulation, évaluez l'impact que ces valeurs peuvent avoir sur votre réseau SNA. Lors de l'installation d'une nouvelle base de données, vous devez tenir compte des éléments suivants :
Si vous indiquez le paramètre NCP MAXBFRU, sélectionnez une valeur correspondant à la valeur de RU plus 29 octets. Dans la cas de NCP, le paramètre MAXBFRU définit le nombre de tampons d'E-S VTAM pouvant prendre en charge l'unité d'information acheminable (PIU). Si vous choisissez une taille de tampon IOBUF de 441, MAXBFRU=10 traite correctement une RU de 4 ko car 10*441 est supérieur à 4096+29.
Le demandeur d'application DB2 pour VM peut ne pas disposer du support DRDA. Suivez la procédure suivante pour préparer le demandeur d'application DB2 pour VM aux communications DRDA :
Reportez-vous au manuel DB2 for VM System Administration pour plus de détails.
Lorsqu'un système éloigné exécute des opérations de traitement sur des bases de données réparties au nom d'une application SQL, il doit être capable de répondre aux critères de sécurité du demandeur d'application, du serveur d'applications et du réseau reliant ces derniers entre eux. Ces critères entrent dans une ou plusieurs des catégories suivantes :
Dans SQL et LU 6.2, les utilisateurs sont identifiés par un ID utilisateur comportant de 1 à 8 caractères. Cette valeur doit être unique pour un système d'exploitation particulier mais ne l'est pas forcément sur tout le réseau SNA. Par exemple, prenons le cas de deux utilisateurs s'appelant tous les deux JONES ; l'un se trouve sur le système TORONTO et l'autre sur le système MONTREAL. S'il s'agit d'une seule et même personne, il n'existe aucun risque de conflit. Cependant, si l'utilisateur JONES de TORONTO n'est pas le même que JONES de MONTREAL, le réseau SNA (et, par conséquent, les systèmes de bases de données réparties de ce réseau) ne pourront pas faire la distinction entre ces deux utilisateurs. Par conséquent, JONES de TORONTO pourra utiliser les droits de JONES de MONTREAL et inversement, à moins que vous n'en décidiez autrement.
DB2 pour VM fournit un support de conversion pour les noms d'utilisateurs finals afin d'éviter les conflits de dénomination. Cependant, le système n'effectue pas la conversion des ID utilisateur. Si la conversion doit être effectuée par le système, vous devez vous assurer que la conversion entrante est assurée correctement au niveau du serveur d'applications.
La conversion sortante s'effectue à l'aide du répertoire de communications CMS. Le répertoire de communications CMS doit comporter une entrée :security.PGM. Si tel est le cas, les valeurs correspondantes des marques :userid et :password sont acheminées sur le site éloigné (serveur d'applications) dans la demande de connexion.
Lorsque vous créez l'entrée indiquée à la Figure 32, l'utilisateur dont l'ID est JONES sur le système local (TORONTO) est mappé avec l'ID JONEST lorsqu'il se connecte au serveur d'applications MONTREAL_SALES_DB sur le système MONTREAL. L'ambiguïté au niveau des ID utilisateur est alors levée.
Figure 32. Conversion de nom sortante
+--------------------------------------------------------------------------------+ | UCOMDIR NAMES A1 V 132 Trunc=132 Size=10 Line=1 Col=1 Alt=8 | |====> | |00001 :nick.MTLSALES | |00002 :tpn.SALES | |00003 :luname.TORLU MTLGATE | |00004 :modename.BATCH | |00005 :security.PGM | |00006 :userid.JONEST | |00007 :password.JONESPW | |00008 :dbname.MONTREAL_SALES_DB | |00009 | +--------------------------------------------------------------------------------+ |
Une fois que le demandeur d'application a sélectionné le nom d'utilisateur final qui le représente sur le site éloigné, il doit fournir les données de sécurité réseau LU 6.2 requises. Il existe trois grandes fonctions de sécurité réseau pour les unités logiques LU 6.2 :
Dans la mesure où le serveur d'applications est chargé de la gestion des ressources de bases de données, il détermine les fonctions de sécurité réseau que le demandeur d'application doit fournir. Vous devez enregistrer les besoins de sécurité du serveur d'applications dans le répertoire de communications du demandeur d'application en définissant la valeur appropriée pour la marque :security.
Les options de sécurité au niveau des conversations prises en charge par DRDA sont les suivantes :
DB2 pour VM ne prend pas en charge le cryptage du mot de passe. Le mot de passe peut être spécifié dans la marque :password, ou peut être stocké dans l'entrée du répertoire CP de l'utilisateur final à l'aide d'une instruction APPCPASS. L'utilisation de l'instruction APPCPASS est recommandée si vous voulez accroître le niveau de sécurité pour votre mot de passe. Si le mot de passe n'est pas spécifié dans l'entrée du répertoire de communications CMS, une instruction APPCPASS est recherchée dans l'entrée du répertoire système (VM) de l'utilisateur.
VM fournit l'instruction APPCPASS pour optimiser la sécurité de l'ID utilisateur et du mot de passe utilisés par le demandeur d'application pour se connecter à un serveur d'applications. L'instruction APPCPASS offre une grande souplesse d'utilisation ; vous pouvez l'utiliser de différentes façons pour le stockage des données de sécurité :
La Figure 33 illustre un exemple où l'ID utilisateur est stocké dans le répertoire de communications de l'utilisateur et le mot de passe dans l'entrée du répertoire VM de l'utilisateur. Dans l'entrée du répertoire de communications, l'ID utilisateur MTLSOU est indiqué, mais aucun mot de passe n'est mentionné. Le mot de passe est stocké dans l'entrée du répertoire VM de l'utilisateur.
Figure 33. Exemple d'entrée de répertoire de communications sans indication de mot de passe
+--------------------------------------------------------------------------------+ | UCOMDIR NAMES A1 V 132 Trunc=132 Size=8 Line=1 Col=1 Alt=8 | |====> | |00001 :nick.MTLSALES | |00002 :tpn.SALES | |00003 :luname.TORGATE MTLGATE | |00004 :modename.BATCH | |00005 :security.PGM | |00006 :userid.MTLSOU | |00007 :password. | |00008 :dbname.MONTREAL_SALES_DB | |00009 | +--------------------------------------------------------------------------------+ |
Lorsque APPC/VM établit la connexion entre le demandeur d'application et le serveur d'applications en utilisant la conversation SECURITY=PGM, il lit les valeurs des marques :userid et :password et les transmet au serveur d'applications. Si l'une ou l'autre de ces marques est en blanc, le système recherche les informations manquantes dans l'entrée du répertoire VM de l'utilisateur. Dans ce cas, l'instruction APPCPASS doit figurer dans l'entrée de répertoire VM comme indiqué ci-après.
APPCPASS TORGATE MTLGATE MTLSOU Q6VBN8XP
Cette instruction indique à APPC/VM que l'utilisateur (demandeur d'application) demandant la connexion via la passerelle AVS locale TORGATE, la LU partenaire MTLGATE et l'ID utilisateur MTLSOU doit envoyer le mot de passe Q6VBN8XP au serveur d'applications. Ces deux éléments permettent d'identifier l'utilisateur au niveau du serveur d'applications.
Le placement de l'instruction APPCPASS dans le répertoire VM n'incombe pas à l'utilisateur final. Ce dernier doit demander au programmeur des systèmes VM d'effectuer cette tâche.
Pour de plus amples informations sur la sécurité au niveau des conversations et sur l'instruction APPCPASS, reportez-vous au manuel VM/ESA Connectivity Planning, Administration, and Operation.
Dans le cadre de la sécurité globale de la base de données répartie, le demandeur d'application peut jouer un rôle important en contrôlant les utilisateurs finals qui sont autorisés à effectuer des demandes de bases de données réparties. Dans DB2 pour VM, le demandeur d'application peut contribuer à la sécurité de la base de données répartie de trois façons différentes :
Le sous-système de sécurité externe sur les systèmes VM est assuré par RACF ou des produits équivalents qui fournissent une interface compatible avec RACF. Le demandeur d'application DB2 pour VM n'est pas directement en relation avec le système de sécurité externe. Ce dernier n'est pas utilisé pour fournir des mots de passe pour la sécurité au niveau des conversations. Si vous choisissez d'utiliser la sécurité au niveau des sessions, le sous-système de sécurité externe est appelé par VTAM pour valider l'identité du nom de LU éloignée lors de la vérification de la LU partenaire.
Les valeurs par défaut appropriées de CHARNAME et du CCSID doivent être définies pour le demandeur d'application. En indiquant des valeurs correctes, vous assurez l'intégrité de la représentation des données alphanumériques et réduisez le temps système associé à la conversion de CCSID.
Par exemple, si votre demandeur d'application DB2 pour VM est généré avec la page de codes 37 et le jeu de caractères 697 (CP/CS 37/697) pour l'anglais (Etats-Unis), le demandeur d'application doit affecter par défaut à CHARNAME la valeur ENGLISH. En effet, CP/CS 37/697 correspond au CCSID 37, qui lui-même correspond à la valeur ENGLISH pour CHARNAME.
La valeur par défaut de CHARNAME pour un système migré ou récemment installé est INTERNATIONAL et le CCSID est 500. Ces valeurs ne sont probablement pas correctes pour votre installation. Pour afficher les valeurs des CCSID par défaut en cours, utilisez la commande suivante :
SQLINIT QUERY
La valeur de CCSID appropriée pour le demandeur d'application peut être l'une des valeurs non prises en charge par les tables de conversion au niveau du serveur d'applications. Dans ce cas, vous pouvez établir la connexion en procédant de la manière suivante :
Un demandeur d'application utilise un contrôleur défini avec CP/CS 37/697. Le serveur d'applications ne prend pas en charge la conversion à partir du CCSID 37, mais du CCSID 285 (il s'agit de la valeur UK-ENGLISH pour CHARNAME pour SQL/DS).
Si vous indiquez pour le demandeur d'application la valeur UK-ENGLISH pour CHARNAME (et un CCSID de 285), l'intégrité des données ne sera pas conservée. Par exemple, lorsque le symbole de la livre sterling (œ) est demandé par le serveur d'applications, le demandeur d'application affiche le symbole du dollar ($). D'autres caractères peuvent également être différents.
Pour modifier la valeur de CCSID d'un demandeur d'application DB2 pour VM, vous devez indiquer le paramètre CHARNAME du fichier SQLINIT EXEC. Reportez-vous au manuel DB2 for VM System Administration pour de plus amples informations.
La valeur de CCSID appropriée pour le demandeur d'application doit être prise en charge par les tables de conversion au niveau du demandeur d'application. Dans ce cas, vous pouvez établir la connexion en procédant de la manière suivante :
La liste de contrôle ci-après récapitule les étapes nécessaires à l'activation d'un demandeur d'application DRDA pour les communications DRDA, en supposant que votre système VM soit installé, que ACF/VTAM soit utilisé comme méthode d'accès en télétraitement et que les définitions VTAM requises pour communiquer avec les systèmes éloignés telles que les définitions NCP soient complètes.