DB2 - Connectivité - Informations complémentaires

Configuration du demandeur d'application

DB2 pour MVS/ESA met en oeuvre le support de demandeur d'application DRDA en tant que partie intégrante de la fonction DDF (Distributed Data Facility) de DB2 pour MVS/ESA. La fonction DDF peut être arrêtée de façon indépendante à partir des fonctions de gestion de bases de données de DB2 pour MVS/ESA mais ne peut pas s'exécuter en l'absence du support de gestion de base de données locale de DB2 pour MVS/ESA.

Lorsque DB2 pour MVS/ESA agit en tant que demandeur d'application, il peut connecter des applications s'exécutant sur le système à des serveurs de bases de données éloignés DB2 Universal Database, DB2 pour MVS/ESA, DB2 Universal Database for OS/390, DB2 Universal Database pour AS/400 et DB2 pour VSE & VM, qui mettent en oeuvre la fonction de serveur d'applications DRDA.

Si vous souhaitez que le demandeur d'application DB2 pour MVS/ESA 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 que ces opérations s'exécutent correctement, vous devez effectuer les opérations suivantes :

  1. Définition du système local.
  2. Définition des systèmes éloignés.
  3. Définition des communications.
  4. Définition de la taille de RU et de la régulation.

Définition du système local

Chaque programme sur le réseau se voit attribuer un NETID et un nom de LU. Votre demandeur d'application DB2 pour MVS/ESA doit donc avoir une valeur NETID.LUNAME lors de sa connexion au réseau. Etant donné que le demandeur d'application DB2 pour MVS/ESA est intégré dans le système de gestion de la base de données DB2 pour MVS/ESA locale, il doit avoir un RDB_NAME. Dans les publications DB2 pour MVS/ESA, il est fait référence au nom RDB_NAME en tant que nom d'emplacement.

Définissez le demandeur d'application DB2 pour MVS/ESA pour le réseau SNA en procédant comme suit :

  1. Sélectionnez un nom de LU pour votre système DB2 pour MVS/ESA. Le NETID de votre système DB2 pour MVS/ESA s'obtient automatiquement à partir de VTAM au démarrage de DDF.
  2. Définissez le nom de LU et le nom d'emplacement dans le fichier d'amorçage (BSDS) DB2 pour MVS/ESA. (DB2 pour MVS/ESA limite le nom d'emplacement à 16 caractères).
  3. Créez une définition APPL VTAM pour enregistrer le nom de LU sélectionné avec VTAM.

Configuration du fichier d'amorçage de DDF 

DB2 pour MVS/ESA lit le fichier d'amorçage pendant le traitement du démarrage pour obtenir des paramètres d'installation du système. L'un des enregistrements stockés dans le fichier d'amorçage est appelé enregistrement DDF, parce qu'il contient les informations utilisées par la fonction DDF pour se connecter à VTAM. Ces informations sont les suivantes :

Vous pouvez fournir les informations du fichier d'amorçage de DDF à DB2 pour MVS/ESA de deux manières :

Lorsque DDF est lancé (soit automatiquement au démarrage de DB2 pour MVS/ESA, soit au moyen de la commande START DDF de DB2 pour MVS/ESA), il se connecte à VTAM, transmettant le nom de LU et le mot de passe à VTAM. VTAM reconnaît le système DB2 pour MVS/ESA en vérifiant le nom de LU et le mot de passe (si un mot de passe VTAM est requis) avec les valeurs définies dans l'instruction APPL VTAM DB2 pour MVS/ESA. Le mot de passe VTAM permet de vérifier que DB2 pour MVS/ESA est habilité à utiliser le nom de LU spécifié sur le système VTAM. Le mot de passe VTAM n'est pas transmis via le réseau et ne permet pas de connecter d'autres systèmes du réseau à DB2 pour MVS/ESA.

Si VTAM n'exige pas de mot de passe, ignorez le mot clé PASSWORD= dans l'inventaire du journal des modifications. L'absence de mot clé indique qu'aucun mot de passe VTAM n'est nécessaire.

Création d'une définition APPL VTAM 

Après avoir défini le nom de LU VTAM et le mot de passe pour DB2 pour MVS/ESA, il vous faut enregistrer ces valeurs avec VTAM. VTAM utilise l'instruction APPL pour définir les noms de LU locales. La Figure 5 illustre la définition du nom de LU LUDBD1 pour VTAM.

Figure 5. Exemple de définition APPL pour DB2 pour MVS/ESA

 DB2APPLS VBUILD TYPE=APPL
 *
 *--------------------------------------------------------------------*
 *                                                                    *
 *           APPL DEFINITION FOR THE SYDNEY DB2 SYSTEM                *
 *                                                                    *
 *--------------------------------------------------------------------*
 *
 LUDBD1   APPL  APPC=YES,                                    X
               AUTH=(ACQ),                                   X
                AUTOSES=1,                                   X
                DMINWNL=10,                                  X
                DMINWNR=10,                                  X
                DSESLIM=20,                                  X
                EAS=9999,                                    X
                MODETAB=RDBMODES,                            X
                PRTCT=PSWDBD1,                               X
                SECACPT=ALREADYV,                            X
                SRBEXIT=YES,                                 X
                VERIFY=NONE,                                 X
                VPACING=2,                                   X
                SYNCLVL=SYNCPT,                              X
                ATNLOSS=ALL                                  X

Plusieurs mots clés sont disponibles dans l'instruction APPL VTAM. Vous trouverez des explications détaillées concernant la signification des mots clés dans le manuel DB2 - Administration Guide. Les seuls mots clés abordés ici sont ceux qui se rapportent aux rubriques du présent manuel. Les mots clés intéressants de la Figure 5 sont décrits comme suit :

LUDBD1
VTAM utilise l'étiquette d'instruction APPL comme nom de LU. Dans ce cas, le nom de LU est LUDBD1. La syntaxe APPL ne prévoit pas de place pour une valeur NETID.LUNAME complète. La valeur de NETID n'est pas spécifiée dans l'instruction APPL VTAM car elle est automatiquement attribuée à toutes les applications VTAM pour le système VTAM.

AUTOSES=1
Nombre de sessions de vainqueur de conflit SNA qui démarrent automatiquement lors de l'émission d'une demande CNOS APPC (modification du nombre de sessions). Une valeur différente de zéro doit être fournie avec AUTOSES pour informer DB2 pour MVS/ESA chaque fois que le traitement de CNOS VTAM échoue.

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 SNA restantes jusqu'à ce qu'elles soient requises par une application de base de données répartie.

DMINWNL=10
Nombre de sessions dans lesquelles ce système DB2 pour MVS/ESA est le vainqueur de conflit. Le paramètre DMINWNL est la valeur par défaut pour le traitement de CNOS, mais celle-ci peut être remplacée pour tout partenaire donné, par l'ajout d'une ligne à la table SYSIBM.SYSLUMODES dans la base de données de communications DB2 pour MVS/ESA.

DMINWNR=10
Nombre de sessions dans lesquelles le système partenaire est le vainqueur de conflit. Le paramètre DMINWNR est la valeur par défaut pour le traitement de CNOS, mais celle-ci peut être remplacée pour tout partenaire donné, par l'ajout d'une ligne à la table SYSIBM.SYSLUMODES dans la base de données de communications DB2 pour MVS/ESA.

DSESLIM=20
Nombre total de sessions (qui ont abouti ou non) que vous pouvez établir entre DB2 pour MVS/ESA et un autre système réparti pour un nom de groupe de mode donné. Le paramètre DSESLIM est la valeur par défaut pour le traitement de CNOS, mais celle-ci peut être remplacée par tout partenaire donné, par l'ajout d'une ligne à la table SYSIBM.SYSLUMODES dans la base de données de communications DB2 pour MVS/ESA.

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
Identifie la table MODE VTAM contenant chaque nom de mode DB2 pour MVS/ESA.

PRTCT=PSWDBD1
Identifie le mot de passe VTAM à utiliser lors d'une tentative de connexion de DB2 pour MVS/ESA à VTAM. Si vous omettez le mot clé PRTCT, aucun mot de passe n'est requis et vous devez omettre le mot clé PASSWORD= dans l'inventaire du journal des modifications de DB2 pour MVS/ESA.

SECACPT=ALREADYV
Identifie la valeur de sécurité de conversation SNA la plus élevée qui soit acceptée par ce système DB2 pour MVS/ESA lors de la réception d'une demande de base de données répartie émanant d'un système éloigné. Le mot clé ALREADYV indique que ce système DB2 pour MVS/ESA peut accepter trois options de sécurité de session SNA issues d'autres systèmes DRDA demandant des données provenant de ce système DB2 pour MVS/ESA :

Il est préférable de toujours spécifier SECACPT=ALREADYV car le niveau de sécurité des conversations SNA de chacun des partenaires DB2 pour MVS/ESA est issu de la base de données de communications DB2 pour MVS/ESA (colonne USERSECURITY de la table SYSIBM.SYSLUNAMES). SECACPT=ALREADYV vous offre la plus grande souplesse pour la sélection des valeurs de USERSECURITY.

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

DB2 pour MVS/ESA ne restreint pas votre choix pour le mot clé VERIFY. Dans le cas d'un réseau non sécurisé, VERIFY=REQUIRED est recommandé. VERIFY=REQUIRED permet à VTAM de rejeter les partenaires qui ne peuvent pas effectuer de vérification de LU partenaire. Si vous choisissez VERIFY=OPTIONAL, VTAM effectue la vérification de la LU partenaire uniquement pour les partenaires qui en fournissent le support.

VPACING=2
Attribue la valeur 2 pour la régulation de VTAM.

SYNCLVL=SYNCPT
Indique que DB2 pour MVS/ESA peut prendre en charge la validation en deux phases. VTAM utilise ces informations pour informer le partenaire que la validation en deux phases est disponible. Si ce mot clé est présent, DB2 pour MVS/ESA utilise automatiquement la validation en deux phases si cette dernière peut être prise en charge par le partenaire.

ATNLOSS=ALL
Indique que DB2 pour MVS/ESA doit être informé chaque fois que se termine une session VTAM. C'est la garantie que DB2 pour MVS/ESA exécute une resynchronisation SNA lorsque cela est requis.

DSESLIM, DMINWNL et DMINWNR vous permettent de définir un nombre maximal de sessions VTAM par défaut pour l'ensemble des partenaires. Pour les partenaires requérant un nombre maximal de sessions particulier, la table SYSIBM.SYSLUMODES peut être utilisée pour remplacer le nombre maximal de sessions par défaut. Vous pouvez par exemple vouloir spécifier un nombre maximal de sessions par défaut VTAM adapté à vos systèmes OS/2. Pour d'autres partenaires, vous pouvez, dans la table SYSIBM.SYSLUMODES, créer des lignes pour définir le nombre maximal de sessions voulu. Considérez ces exemples de valeurs :

DSESLIM=4,DMINWNL=0,DMINWNR=4

Ces paramètres permettent à chacun des partenaires de créer jusqu'à quatre sessions DB2 pour MVS/ESA, le partenaire étant le vainqueur de conflit dans chacune des sessions. Dans la mesure où OS/2 crée les conversations LU 6.2 avec DB2 pour MVS/ESA en faisant d'OS/2 le vainqueur de conflit dans les sessions, vous profitez d'un petit avantage au niveau de la performance. Si OS/2 a une session de vainqueur de conflit disponible, aucune permission n'est requise pour le démarrage d'une nouvelle conversation LU 6.2.

Définition des systèmes éloignés

Lorsqu'une application DB2 pour MVS/ESA demande des données issues d'un système éloigné, DB2 pour MVS/ESA recherche dans les tables de bases de données de communications des informations relatives au système éloigné. Ces recherches portent également sur :

La base de données de communications est un groupe de tables SQL géré par l'administrateur du système DB2 pour MVS/ESA. En tant qu'administrateur du système DB2 pour MVS/ESA, vous devez utiliser le SQL pour insérer des lignes dans la base de données de communications afin de décrire chaque partenaire DRDA potentiel. La base de données de communications se compose de cinq tables :

  1. SYSIBM.SYSLOCATIONS

    Cette table permet à DB2 pour MVS/ESA de déterminer le nom de LU et la valeur de TPN pour chaque RDB_NAME sélectionné par une application DB2 pour MVS/ESA. Les colonnes sont les suivantes :

    LOCATION
    RDB_NAME du système éloigné. DB2 pour MVS/ESA limite la longueur de la valeur de RDB_NAME à 16 octets, ce qui représente 2 octets de moins par rapport à la limite de 18 octets définie dans DRDA.

    LOCTYPE
    Non utilisé actuellement ; doit rester en blanc.

    LINKNAME
    Nom de LU du système éloigné.

    LINKATTR
    TPN du système éloigné. Si le système éloigné est un système DB2 pour MVS/ESA ou s'il utilise la valeur TPN DRDA par défaut (X'07F6C4C2', 1 ) ; une chaîne vide peut être indiquée pour spécifier le TPN car DB2 pour MVS/ESA choisit automatiquement la valeur correcte.

    Si le système éloigné requiert une valeur de TPN différente de la valeur de TPN par défaut, vous devez mentionner cette valeur dans cette colonne.

  2. SYSIBM.SYSLUNAMES

    Cette table définit les attributs de réseau des systèmes éloignés. Les colonnes sont les suivantes :

    LUNAME
    Nom de LU du système éloigné.

    SYSMODENAME
    Nom de mode de connexion VTAM utilisé pour l'établissement de conversations entre deux systèmes DB2 pour MVS/ESA pour le support du serveur secondaire DB2 pour MVS/ESA (accès défini par le système). Une valeur à blanc dans cette colonne indique qu'il faut utiliser IBMDB2LM pour les conversations du système DB2 pour MVS/ESA.

    USERSECURITY
    Options d'acceptation de sécurité réseau requises quant au système éloigné lorsque ce système DB2 pour MVS/ESA fait office de serveur pour le système éloigné (conditions requises de sécurité entrante).

    ENCRYPTPSWDS
    Indique si les mots de passe échangés avec ce partenaire sont codés ou non. Les mots de passe codés sont uniquement pris en charge par les demandeurs et les serveurs DB2 pour MVS/ESA.

    MODESELECT
    Détermine si la table SYSIBM.SYSMODESELECT est utilisée ou non pour la sélection d'une entrée de mode de connexion VTAM (nom de mode) basée sur l'utilisateur final ou l'application qui émet la demande. Si cette colonne contient un 'Y', la table SYSIBM.SYSMODESELECT est utilisée pour obtenir le nom de mode pour chaque demande de base de données répartie sortante.

    Si MODESELECT contient une autre valeur que 'Y', le nom de mode IBMDB2LM est utilisé pour les demandes d'accès défini par le système et le nom de mode IBMRDB est utilisé pour les demandes DRDA.

    La colonne MODESELECT vous permet de donner la priorité aux demandes de base de données répartie en spécifiant une classe de service VTAM associée au nom de mode.

    USERNAMES
    Niveau d'identification du site émetteur et conversion de l'ID utilisateur requis. Cette colonne spécifie également les paramètres de sécurité utilisés par ce sous-système DB2 pour MVS/ESA lors de la demande de données émanant du partenaire éloigné (conditions requises de sécurité sortante). Cette colonne peut avoir pour valeur I, O, ou B.
  3. SYSIBM.SYSLUMODES

    Cette table permet de définir le nombre maximal de sessions LU 6.2 (limites CNOS) pour chaque système partenaire. Les colonnes sont les suivantes :

    LUNAME
    Nom de LU du système éloigné.

    MODENAME
    Nom du mode de connexion VTAM dont les limites sont spécifiées. Une valeur à blanc revient à indiquer IBMDB2LM.

    CONVLIMIT
    Nombre maximal de conversations actives entre le système local DB2 pour MVS/ESA et le système éloigné pour ce mode de connexion. Cette valeur permet de remplacer le paramètre DSESLIM dans l'instruction de définition APPL VTAM pour ce mode de connexion, qui fournit le nombre maximal de sessions VTAM par défaut pour DB2 pour MVS/ESA.

    La valeur sélectionnée dans CONVLIMIT est utilisée pendant le processus CNOS afin de définir CONVLIMIT/2 pour DMINWNR et DMINWNL.

    AUTO
    Détermine si la pré-allocation de sessions et le traitement de CNOS sont initialisés automatiquement au démarrage de DDF ou reportés jusqu'à la première référence au nom de LU via ce mode de connexion.
  4. SYSIBM.SYSMODESELECT

    Cette table vous permet de spécifier différents noms de mode pour des utilisateurs finals individuels et des applications DB2 pour MVS/ESA. Dans la mesure où une classe de service (COS) peut être associée à chaque nom de mode VTAM, vous pouvez utiliser cette table pour attribuer des priorités de transmission de réseau aux applications de base de données répartie, sur la base d'une combinaison de AUTHID, PLANNAME et LUNAME. Les colonnes sont les suivantes :

    AUTHID
    ID autorisation de l'utilisateur DB2 pour MVS/ESA. La valeur par défaut est à blanc, ce qui indique que le nom de mode de connexion spécifié s'applique à tous les ID autorisation.

    PLANNAME
    Nom de plan associé à l'application demandant l'accès à un système de bases de données éloignées. La valeur par défaut est à blanc, ce qui indique que le nom de mode de connexion spécifié s'applique à tous les noms de plan. Le nom de plan utilisé pour la commande BIND PACKAGE est DSNBIND.

    LUNAME
    Nom de LU associé au système de bases de données éloignées.

    MODENAME
    Nom de mode de connexion VTAM à utiliser lors de l'acheminement d'une demande de base de données répartie vers le système éloigné indiqué. Par défaut, cette valeur est à blanc, pour indiquer que l'on doit utiliser IBMDB2LM pour les conversations à accès défini par le système et IBMRDB pour les conversations DRDA.
  5. SYSIBM.SYSUSERNAMES

    Cette table permet de gérer les noms d'utilisateurs finals via des mots de passe, des conversions de noms et des identifications de site émetteur. DB2 pour MVS/ESA utilise le nom de l'utilisateur comme ID autorisation. La plupart des autres produits utilisent ce nom comme ID utilisateur.

    Avec cette table, vous pouvez utiliser la conversion de nom pour imposer l'utilisation de valeurs différentes pour l'ID utilisateur SNA et l'ID autorisation DB2 pour MVS/ESA. Le processus de conversion de nom est autorisé pour les demandes destinées à un système éloigné (demandes sortantes) et pour les demandes émanant d'un système éloigné (demandes entrantes). Si les mots de passe ne sont pas codés, cette table est la source du mot de passe de l'utilisateur final lorsque l'ID utilisateur et le mot de passe sont envoyés vers un site éloigné. Les colonnes sont les suivantes :

    TYPE
    Description de l'utilisation de la ligne (qu'il s'agisse ou non d'une ligne décrivant les conversions de noms pour les demandes sortantes ou entrantes d'identification de site émetteur).

    AUTHID
    Pour la conversion de nom sortante, il s'agit de l'ID autorisation DB2 pour MVS/ESA à convertir. Pour la conversion de nom entrante, il s'agit de l'ID utilisateur SNA à convertir. Dans les deux cas, une valeur AUTHID à blanc s'applique à tous les ID autorisation ou utilisateurs.

    LUNAME
    Nom de LU du système éloigné auquel s'applique cette ligne. Si la valeur est à blanc, la valeur NEWAUTHID s'applique à tous les systèmes.

    NEWAUTHID
    Nouveau nom d'utilisateur final (ID utilisateur SNA ou ID autorisation DB2 pour MVS/ESA). Une valeur à blanc indique qu'il n'est pas nécessaire de convertir l'ID.

    PASSWORD
    Mot de passe utilisé pour la conversation d'allocation si les mots de passe ne sont pas codés (ENCRYPTPSWDS = 'N' dans SYSIBM.SYSLUNAMES). Si les mots de passe sont codés, ignorez cette colonne.

Paramétrage des communications

VTAM est le gestionnaire de communications des systèmes MVS. VTAM accepte les verbes LU 6.2 à partir de DB2 pour MVS/ESA et les convertit en flots de données LU 6.2 que vous pouvez transmettre sur le réseau. Pour permettre à VTAM de communiquer avec les applications partenaires définies dans les bases de données de communications DB2 pour MVS/ESA, vous devez fournir à VTAM les informations suivantes :

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

Les entrées de table de modes VTAM que vous avez définies spécifient les tailles 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 les tailles de RU, le nombre maximal de sessions et la régulation, il est très important d'évaluer l'impact que ces valeurs peuvent avoir sur le réseau VTAM existant. Lors de l'installation d'une nouvelle base de données répartie, vous devez tenir compte des éléments suivants :

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 les systèmes MVS, les utilisateurs finals sont identifiés par un ID utilisateur comportant de 1 à 8 caractères. Cet ID utilisateur doit être unique pour un système MVS particulier mais ne doit pas forcément l'être 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 NEWYORK et l'autre sur le système DALLAS. S'il s'agit d'une seule et même personne, il n'existe aucun risque de conflit. Cependant, si l'utilisateur JONES de DALLAS n'est pas le même que l'utilisateur JONES de NEWYORK, 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. Si vous ne remédiez pas à cette situation, JONES de DALLAS pourra utiliser les droits de JONES de NEWYORK.

DB2 pour MVS/ESA fournit un support de conversion pour les noms d'utilisateurs finals afin d'éviter les conflits de dénomination. Lorsqu'une application au niveau du demandeur d'application DB2 pour MVS/ESA émet une demande de base de données répartie, DB2 pour MVS/ESA exécute la conversion du nom si la base de données de communications spécifie que la conversion de nom sortante est requise. Si la conversion de nom sortante est sélectionnée, DB2 pour MVS/ESA exige toujours qu'un mot de passe soit envoyé avec chaque demande de base de données répartie sortante.

Pour activer la conversion de nom sortante dans DB2 pour MVS/ESA, vous devez définir 'O' ou 'B' pour la colonne USERNAMES de la table SYSIBM.SYSLUNAMES. Si 'O' est défini pour USERNAMES, la conversion du nom d'utilisateur final s'effectue pour les demandes sortantes. Si 'B' est défini pour USERNAMES, la conversion du nom d'utilisateur final s'effectue pour les demandes sortantes et entrantes.

Etant donné que l'autorisation DB2 pour MVS/ESA dépend à la fois de l'ID utilisateur de l'utilisateur final et de l'ID utilisateur du propriétaire du module ou du plan DB2 Universal Database for OS/390, le processus de conversion du nom d'utilisateur final s'opère pour l'ID utilisateur de l'utilisateur final, l'ID utilisateur du propriétaire du plan et l'ID utilisateur du propriétaire du module. 2 Le processus de conversion de nom recherche dans la table SYSIBM.SYSUSERNAMES, dans la séquence suivante, une ligne qui corresponde à l'un des modèles (TYPE.AUTHID.LUNAME) suivants :

  1. O.AUTHID.LUNAME-- Règle de conversion pour un utilisateur final particulier vers un système partenaire particulier.
  2. O.AUTHID.espace-- Règle de conversion pour un utilisateur final particulier vers n'importe quel système partenaire.
  3. O.espace.LUNAME-- Règle de conversion pour n'importe quel utilisateur vers un système partenaire particulier.

S'il n'existe aucune ligne correspondante, DB2 pour MVS/ESA rejette la demande de base de données répartie. S'il existe une ligne correspondante, la valeur de la colonne NEWAUTHID est utilisée comme ID autorisation. (Une valeur NEWAUTHID à blanc indique que le nom original est utilisé sans conversion).

Reportez-vous à l'exemple déjà évoqué. Vous souhaitez attribuer à JONES de NEWYORK un nom différent (NYJONES) lorsque JONES envoie des demandes de bases de données réparties à DALLAS. Dans l'exemple, imaginez que l'application utilisée par JONES appartienne à DSNPLAN (propriétaire du plan DB2 pour MVS/ESA) et qu'il ne soit pas nécessaire de convertir cet ID utilisateur lors de son envoi à DALLAS. Les instructions SQL requises pour la fourniture des règles de conversion des noms dans les bases de données de communications sont illustrées à la Figure 6.

Figure 6. SQL pour conversion de nom sortante

INSERT INTO SYSIBM.SYSLUNAMES
     (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', 'O');
INSERT INTO SYSIBM.SYSLOCATIONS
     (LOCATION, LOCTYPE, LINKNAME, LINKATTR)
  VALUES ('DALLAS', ' ', 'LUDALLAS', '');
INSERT INTO SYSIBM.SYSUSERNAMES
     (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('O', 'JONES', 'LUDALLAS', 'NYJONES', 'JONESPWD');
INSERT INTO SYSIBM.SYSUSERNAMES
     (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('O', 'DSNPLAN', 'LUDALLAS', ' ', 'PLANPWD');

Les tables de bases de données qui en résultent sont illustrées à la Figure 7 :

Figure 7. Conversion de nom sortante

                                                                                  
                                                                                 
 

REQTEXT

Sécurité réseau

Une fois que le demandeur d'application a sélectionné les noms d'utilisateurs finals pour représenter l'application éloignée, il doit fournir les données de sécurité réseau LU 6.2 requises. Il existe trois principales 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 quelles sont les fonctions de sécurité réseau requises pour le demandeur d'application. Vous devez enregistrer les conditions de sécurité requises au niveau de la conversation de chaque serveur d'applications dans la table SYSIBM.SYSLUNAMES en définissant la colonne USERNAMES de cette table de manière à ce qu'elle reflète les conditions requises par le serveur d'applications.

Les options possibles pour les conversations SNA 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 utilisateur de l'utilisateur final est transmis au système éloigné (aucun mot de passe n'est transmis). Utilisez ce niveau de sécurité de conversation lorsque la colonne USERNAMES dans SYSIBM.SYSLUNAMES ne contient ni 'O' ni 'B'.

Dans la mesure où DB2 pour MVS/ESA lie la conversion de nom d'utilisateur final à la sécurité de la conversation sortante, vous n'êtes pas autorisé à utiliser SECURITY=SAME lorsque la conversion de nom d'utilisateur final sortante est activée.

SECURITY=PGM
Cette option déclenche l'envoi de l'ID utilisateur final et du mot de passe au système éloigné pour validation. Utilisez cette option de sécurité lorsque la colonne USERNAMES de la table SYSIBM.SYSLUNAMES contient 'O' ou 'B'.

En fonction des options définies dans la table SYSIBM.SYSLUNAMES, DB2 pour MVS/ESA obtient le mot de passe de l'utilisateur final de deux sources différentes :

SECURITY=NONE
Cette option n'est pas prise en charge par DRDA ; DB2 pour MVS/ESA ne prévoit donc rien pour cette option de sécurité.

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

La conversion de nom sortante constitue, pour le demandeur d'application, l'un des moyens de participer à la sécurité d'une base de données répartie, comme indiqué à la section Sélection des noms d'utilisateurs finals. Vous pouvez utiliser la fonction de conversion du nom sortante pour contrôler l'accès à chaque serveur d'applications, sur la base de l'identité de l'utilisateur final et de l'application effectuant la demande. Les autres moyens permettant au demandeur d'application DB2 pour MVS/ESA de contribuer à la sécurité des systèmes répartis sont les suivants :

Définition des accès aux applications éloignées
Les utilisateurs finals définissent les accès aux applications éloignées au niveau du serveur d'applications via la commande BIND PACKAGE de DB2 pour MVS/ESA. DB2 pour MVS/ESA ne limite pas l'utilisation de la commande BIND PACKAGE au niveau du demandeur. Toutefois, un utilisateur final ne peut pas utiliser de module éloigné si celui-ci ne fait pas partie d'un plan DB2 pour MVS/ESA. DB2 pour MVS/ESA limite l'utilisation de la commande BIND PLAN. Un utilisateur final ne peut pas ajouter le module éloigné à un plan, à moins de bénéficier du privilège BIND ou BINDADD avec l'instruction GRANT de DB2 pour MVS/ESA.

Lors de la définition de l'accès à un module, utilisez l'option ENABLE/DISABLE pour spécifier si le module doit être utilisé par TSO, CICS/ESA, IMS/ESA ou par un sous-système DB2 pour MVS/ESA éloigné.

Exécution d'applications éloignées
Pour exécuter une application éloignée, l'utilisateur final DB2 pour MVS/ESA doit disposer des droits d'exécution du plan DB2 pour MVS/ESA associé à cette application. Le propriétaire du plan DB2 pour MVS/ESA dispose automatiquement des droits d'exécution du plan. 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 MVS/ESA. 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 MVS est fourni par RACF ou des produits équivalents qui offrent une interface compatible avec RACF. Le demandeur d'application DB2 pour MVS/ESA n'a pas d'appels directs avec le sous-système de sécurité externe, exception faite du support de mot de passe codé dont vous trouverez la description dans la section Sécurité réseau. Toutefois, le sous-système de sécurité externe est utilisé indirectement au niveau du demandeur d'application, dans les situations suivantes :

Représentation des données

DB2 pour MVS/ESA est livré avec un ID de jeu de caractères codés d'installation par défaut est 500. Cette valeur par défaut n'est probablement pas correcte pour votre installation.

Lors de l'installation de DB2 pour MVS/ESA, vous devez définir le CCSID d'installation en fonction du CCSID des caractères générés et transmis à DB2 pour MVS/ESA par les unités d'entrée au niveau de votre site. Ce CCSID est généralement déterminé par la langue nationale utilisée. Si le CCSID d'installation n'est pas correct, la conversion des caractères produira des résultats erronés. Pour connaître la liste des CCSID pris en charge pour chaque pays ou langue nationale, reportez-vous au manuel DB2 Connect User's Guide.

Vous devez vous assurer que votre sous-système DB2 pour MVS/ESA dispose de la fonction de conversion de chaque CCSID du serveur d'applications en CCSID d'installation du sous-système DB2 pour MVS/ESA. DB2 pour MVS/ESA fournit les tables de conversion pour les combinaisons de CCSID source et cible les plus répandues, mais pas pour toutes les combinaisons possibles. Vous pouvez compléter l'ensemble de tables et de routines de conversion disponibles, si nécessaire. Pour en savoir plus sur la conversion de caractères DB2 pour MVS/ESA, reportez-vous au manuel DB2 Administration Guide.


Notes de bas de page :

1
C'est cette valeur TPN qui s'applique actuellement à DB2 pour VM.

2
Si la demande est envoyée à un serveur DB2 pour MVS/ESA, la conversion de nom s'opère également pour le propriétaire du module et pour celui du plan. Aucun mot de passe n'est jamais associé aux noms de propriétaires de module et de plan.


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