DB2 - Connectivité - Informations complémentaires

Configuration du demandeur d'application dans un environnement VM

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 :

Définition des données réseau

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 :

  1. Définition du système local.
  2. Définition des systèmes éloignés.
  3. Définition des sous-systèmes de communication
  4. Définition de la taille de RU et de la régulation
  5. Préparation du demandeur d'application DB2 pour VM

Définition du système local

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 :

  1. Définissez les noms de passerelle AVS en utilisant les instructions de définition APPL VTAM.

    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).

    TORGATE
    VTAM utilise l'étiquette d'instruction APPL comme nom (LU) de passerelle. Dans la Figure 30, la passerelle TORGATE est définie. Le NETID n'est pas indiqué dans l'instruction APPL VTAM. Il est automatiquement affecté à toutes les applications VTAM du système VTAM.

    AUTOSES=1
    La passerelle TORGATE spécifie qu'une session de vainqueur de conflit SNA démarre automatiquement lorsque vous lancez une commande APPC de modification du nombre de sessions (CNOS). Vous devez indiquer une valeur différente de zéro au paramètre AUTOSES pour AVS si vous voulez être averti de chaque échec de la commande CNOS. II n'est pas nécessaire de démarrer automatiquement toutes les sessions APPC entre les deux partenaires de bases de données réparties concernés. Si la valeur de AUTOSES est inférieure au nombre maximal de vainqueurs de conflit (DMINWNL), VTAM diffère le démarrage des sessions restantes jusqu'à ce qu'elles soient demandées par l'application de base de données répartie.

    DMINWNL=10
    La passerelle TORGATE indique que ce système DB2 pour VM est le vainqueur de conflit sur 10 sessions au minimum. Le traitement CNOS utilise le paramètre DMINWNL comme valeur par défaut, mais cette valeur peut être remplacée à tout moment pour tout partenaire donné, si vous émettez une commande AGW CNOS à partir de la machine virtuelle AVS.

    DMINWNR=10
    La passerelle TORGATE indique que ce système partenaire est le vainqueur de conflit sur 10 sessions au minimum. Le traitement CNOS utilise le paramètre DMINWNR comme valeur par défaut, mais cette valeur peut être remplacée à tout moment pour tout partenaire donné, si vous émettez une commande AGW CNOS à partir de la machine virtuelle AVS.

    DSESLIM=20
    Le nombre total de sessions (qui ont abouti ou non) admises entre la passerelle TORGATE et tous les systèmes répartis partenaires pour un nom de groupe de mode donné est égal à 20. Le traitement CNOS utilise le paramètre DSESLIM comme valeur par défaut, mais cette valeur peut être remplacée à tout moment pour tout partenaire donné, si vous émettez une commande AGW CNOS à partir de la machine virtuelle AVS. Si le partenaire ne peut pas prendre en charge le nombre de sessions indiquées par les paramètres DSESLIM, DMINWNL ou DMINWNR, le processus CNOS négocie, pour ces paramètres, de nouvelles valeurs qui peuvent être acceptées par le partenaire.

    EAS=9999
    Estimation du nombre total de sessions requises par cette LU VTAM.

    MODETAB=RDBMODES
    Le nom de la table de modes VTAM est RDBMODES. Cette table contient tous les noms de mode qui peuvent être utilisés par cette passerelle pour la communication avec d'autres partenaires de bases de données réparties.

    SECACPT=ALREADYV
    Il s'agit du paramètre de sécurité identifiant le niveau de sécurité de conversation le plus élevé pouvant être pris en charge par cette passerelle lorsqu'il est présenté avec une demande de base de données répartie à partir d'un partenaire éloigné. Il est recommandé d'utiliser l'option SECACPT=ALREADYV. Cette option prend en charge les niveaux de sécurité suivants :
    • SECURITY=NONE, demande ne contenant aucune donnée de sécurité. DB2 pour VM rejette les demandes DRDA utilisant ce niveau de sécurité.
    • SECURITY=PGM, demande contenant l'ID utilisateur et le mot de passe du demandeur. DB2 pour VM accepte les demandes DRDA utilisant ce niveau de sécurité.
    • SECURITY=SAME indique une demande qui a déjà été vérifiée et qui contient uniquement l'ID utilisateur du demandeur.

    SYNCLVL=SYNCPT
    Le paramètre SYNCLVL spécifie le niveau du support de synchronisation pour AVS. La valeur SYNCPT indique que les niveaux de synchronisation NONE, CONFIRM et SYNCPT sont pris en charge. Si cette passerelle AVS doit être utilisée pour les activités des unités d'oeuvre réparties DRDA-2 sur un serveur DB2 pour VM, spécifiez la valeur SYNCPT. S'il ne doit PAS y avoir d'activités des unités d'oeuvre réparties, spécifiez la valeur CONFIRM (indique que NONE et CONFIRM sont pris en charge, mais pas SYNCPT).

    VERIFY=NONE
    Identifie le niveau de la sécurité de session SNA (vérification de la LU partenaire) requis par ce système DB2 pour VM. La valeur NONE indique que la vérification de la LU partenaire n'est pas requise.

    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.

    VPACING=2
    Ce paramètre permet de définir la régulation utilisée entre la LU partenaire et cette passerelle. La régulation de session est très importante pour les systèmes de bases de données réparties.
  2. Activez la passerelle.

    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.

  3. Utilisez la commande AGW CNOS pour négocier le nombre de sessions entre la passerelle et chacune de ses LU partenaires.

    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.

  4. Vérifiez que le NETID VTAM est défini dans le gestionnaire de bases de données DB2 pour VM lors de l'installation.

    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.

Définition des systèmes éloignés

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.

Définition du sous-système de communication

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 :

  1. Définissez le nom de LU de chaque demandeur d'application et serveur d'applications pour VTAM. L'emplacement et la syntaxe de ces définitions dépend du type de connexion physique et logique du système éloigné au système VTAM.
  2. Créez une entrée dans la table de modes VTAM pour chaque nom de mode indiqué dans le répertoire de communications CMS. Ces entrées décrivent la taille de RU, la taille de la fenêtre de régulation et la classe de service pour un nom de mode donné.
  3. Si vous envisagez d'utiliser la vérification de LU partenaire (sécurité de la session), indiquez les profils VTAM et RACF (ou équivalents) pour l' algorithme de vérification.

Remarques sur le nombre maximal de sessions AVS 

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.

Définition de la taille de RU et de la régulation

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 :

Préparation du demandeur d'application DB2 pour VM

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 :

  1. L'exec ARISDBMA vous permet d'installer le support DRDA :

    Reportez-vous au manuel DB2 for VM System Administration pour plus de détails.

  2. Après avoir exécuté ARISDBMA, reconstruisez la bibliothèque ARISQLLD LOADLIB de DB2 pour VM. Reportez-vous au chapitre Using a DRDA Environment du manuel DB2 for VM System Administration pour plus de détails.

Définition de la sécurité

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 :

Sélection des noms d'utilisateurs finals

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                                                                           |
+--------------------------------------------------------------------------------+

Sécurité réseau

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 :

SECURITY=SAME
Egalement connue sous le nom de sécurité déjà vérifiée, cette option suppose que seul l'ID de l'utilisateur (ID connexion) final est transmis au système éloigné. Le mot de passe n'est pas transmis. Ce niveau de sécurité des conversations est utilisé lorsque :security.SAME est spécifié dans le répertoire de communications du demandeur d'application pour ce serveur. Lorsque cette option est utilisée, la conversion de nom d'utilisateur final sortante n'est pas effectuée. L'ID utilisateur envoyé au site DRDA éloigné correspond à l'ID connexion de l'utilisateur de CMS. La marque :userid du répertoire de communications CMS est ignorée pour :security.SAME.

SECURITY=PGM
Cette option déclenche l'envoi de l'ID utilisateur final et du mot de passe au système éloigné (serveur d'applications) pour validation. Cette option de sécurité est utilisée lorsque :security.PGM est spécifié dans l'entrée du répertoire de communications CMS du demandeur d'application. Lorsque cette option est utilisée, la conversion de nom d'utilisateur final sortante est effectuée.

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.

Instruction APPCPASS 

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.

Sécurité du gestionnaire de bases de données

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 :

Conversion de nom d'utilisateur sortante
Vous pouvez utiliser la fonction de conversion de nom d'utilisateur sortante pour contrôler l'accès à un serveur d'applications particulier, en fonction de l'identité de l'utilisateur final effectuant la demande. DB2 pour VM tente de convertir le nom de l'utilisateur final avant l'envoi de la demande au site éloigné. Toutefois, le meilleur moyen est de faire en sorte que le serveur d'applications effectue l'identification du site émetteur et la conversion entrante, car les utilisateurs de demandeur d'application VM peuvent remplacer la conversion sortante par leur répertoire de communications utilisateur CMS.

Précompilation d'une application
Les utilisateurs finals précompilent les applications éloignées vers un serveur d'applications particulier en utilisant la commande SQLPREP EXEC de DB2 pour VM ou la commande RELOAD PACKAGE de l'utilitaire de service de base de données (DBSU). DB2 pour VM ne se limite pas à ces fonctions. Lorsqu'un utilisateur final effectue la précompilation d'une application, il devient propriétaire du module issu de cette précompilation.

Exécution d'une application
Pour exécuter une application éloignée, l'utilisateur final DB2 pour VM doit disposer de droits sur le site éloigné (serveur d'applications) pour effectuer des opérations sur le module éloigné associé à l'application donnée. Le créateur (propriétaire) du module est automatiquement autorisé à l'exécuter. Les autres utilisateurs finals peuvent également se voir accorder les droits d'exécution du module à l'aide de l'instruction GRANT execute de DB2 pour VM. Le propriétaire de l'application de base de données répartie peut alors contrôler l'utilisation de l'application à raison d'un utilisateur à la fois.

Sous-système de sécurité

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.

Représentation des données

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 :

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 :

Liste de contrôle d'activation du demandeur d'application DRDA DB2 pour VM

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.

  1. Définissez la passerelle AVS locale pour VTAM
  2. Installez le support DRDA dans le demandeur d'application DB2 pour VM en utilisant la commande ARISDBMA.
  3. Configurez un répertoire de communications CMS et ajoutez toutes les instructions APPCPASS nécessaires au répertoire VM de la machine VM de l'application. Utilisez la commande SET COMDIR CMS pour activer le répertoire de communications.
  4. Démarrez VTAM et AVS pour que les applications VM puissent communiquer à distance via le réseau SNA.
  5. Lancez la commande SQLINIT et indiquez aux paramètres DBNAME, PROTOCOL et CHARNAME respectivement la base de données par défaut ainsi que le protocole et les valeurs de CCSID à utiliser.
  6. Préparez les applications sur le serveur éloigné.


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