DB2 - Connectivité - Informations complémentaires

Configuration du demandeur d'application

DB2 Universal Database for OS/390 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 Universal Database for OS/390 mais ne peut pas s'exécuter en l'absence du support de gestion de base de données locale de DB2 Universal Database for OS/390.

Lorsque DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 cela s'effectue correctement, vous devez procéder aux opérations suivantes :

  1. Définition du système local.
  2. Définition des systèmes éloignés.
  3. Définition des communications (pour les connexions SNA ou TCP/IP).
  4. Définition de la taille de RU et de la régulation (pour les connexions SNA uniquement).

Reportez-vous aux sections Définition du système local (SNA) ou Définition du système local (TCP/IP).

Définition du système local (SNA)

Chaque programme sur le réseau SNA se voit attribuer un NETID et un nom de LU. Votre demandeur d'application DB2 Universal Database for OS/390 doit donc avoir une valeur NETID.LUNAME (attribuée via VTAM) lors de sa connexion au réseau. Parce que le demandeur d'application DB2 Universal Database for OS/390 est intégré dans le système de gestion de la base de données DB2 Universal Database for OS/390 locale, il doit également avoir un nom RDB_NAME. Dans les publications DB2 Universal Database for OS/390, il est fait référence au nom RDB_NAME en tant que nom d'emplacement.

Définissez le demandeur d'application DB2 Universal Database for OS/390 pour le réseau SNA en procédant comme suit :

  1. Sélectionnez un nom de LU pour votre système DB2 Universal Database for OS/390. Le NETID de votre système DB2 Universal Database for OS/390 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 Universal Database for OS/390 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.
  4. Vérifiez que les fonctions de sécurité étendue sont activées (YES). Reportez-vous à la section Fonctions supplémentaires de sécurité.

Configuration du fichier d'amorçage de DDF 

DB2 Universal Database for OS/390 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 Universal Database for OS/390 de deux manières :

Lorsque DDF est lancé (soit automatiquement au démarrage de DB2 Universal Database for OS/390, soit au moyen de la commande START DDF de DB2 Universal Database for OS/390), il se connecte à VTAM, transmettant le nom de LU et le mot de passe à VTAM. VTAM reconnaît le système DB2 Universal Database for OS/390 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. Le mot de passe VTAM permet de vérifier que DB2 Universal Database for OS/390 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 Universal Database for OS/390.

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 Universal Database for OS/390, il vous faut enregistrer ces valeurs avec VTAM. VTAM utilise l'instruction APPL pour définir les noms de LU locales. La Figure 17, illustre la définition de nom de LU NYM2DB2 pour VTAM.

Figure 17. Exemple de définition APPL VTAM pour DB2 Universal Database for OS/390

 DB2APPLS VBUILD TYPE=APPL
 *
 *--------------------------------------------------------------------*
 *                                                                    *
 *           APPL DEFINITION FOR THE NEW_YORK3 DB2 SYSTEM             *
 *                                                                    *
 *--------------------------------------------------------------------*
 *
NYM2DB2  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 for OS/390 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 17 sont décrits comme suit :

NYM2DB2
VTAM utilise l'étiquette d'instruction APPL comme nom de LU. Dans ce cas, le nom de LU est NYM2DB2. 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 Universal Database for OS/390 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 Universal Database for OS/390 est le vainqueur de conflit. Le paramètre DMINWNL est la valeur par défaut pour le traitement de CNOS, mais elle peut être remplacée pour tout partenaire donné, en ajoutant une ligne à la table SYSIBM.LUMODES dans la base de données de communications DB2 Universal Database for OS/390.

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 elle peut être remplacée pour tout partenaire donné, en ajoutant une ligne à la table SYSIBM.LUMODES dans la base de données de communications DB2 Universal Database for OS/390.

DSESLIM=20
Nombre total de sessions (qui ont abouti ou non) que vous pouvez établir entre DB2 Universal Database for OS/390 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 elle peut être remplacée pour tout partenaire donné en ajoutant une ligne à la table SYSIBM.LUMODES dans la base de données de communications DB2 Universal Database for OS/390.

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 Universal Database for OS/390.

PRTCT=PSWDBD1
Identifie le mot de passe VTAM à utiliser lors d'une tentative de connexion de DB2 Universal Database for OS/390 à 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 Universal Database for OS/390.

SECACPT=ALREADYV
Identifie la valeur de sécurité de conversation SNA la plus élevée qui soit acceptée par ce système DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 Universal Database for OS/390 :

Il est préférable de toujours spécifier SECACPT=ALREADYV, car le niveau de sécurité des conversations SNA de chaque partenaire DB2 Universal Database for OS/390 est issu de la base de données de communications DB2 Universal Database for OS/390 (colonne USERSECURITY de la table SYSIBM.LUNAMES). 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 Universal Database for OS/390. La valeur NONE indique que la vérification de la LU partenaire n'est pas requise.

DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 Universal Database for OS/390 utilise automatiquement la validation en deux phases si cette dernière peut être prise en charge par le partenaire.

ATNLOSS=ALL
Indique que DB2 Universal Database for OS/390 doit être informé chaque fois que se termine une session VTAM. C'est la garantie que DB2 Universal Database for OS/390 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.LUMODES 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.LUMODES, 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 avec DB2 Universal Database for OS/390, le partenaire étant le vainqueur de conflit dans chacune des sessions. Parce qu'OS/2 crée les conversations LU 6.2 avec DB2 Universal Database for OS/390 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 du système local (TCP/IP)

Pour plus de commodité, la présente section contient des informations extraites du manuel DB2 Connect Enterprise Edition pour OS/2 et Windows - Mise en route. Pour des informations plus détaillées, reportez-vous aux manuels DB2 Universal Database for OS/390 Installation Reference et DRDA Support for TCP/IP with DB2 Universal Database for OS/390 and DB2 Universal Database.

Les étapes nécessaires à la définition des communications TCP/IP avec DB2 Universal Database for OS/390 sont les suivantes :

  1. Les communications TCP/IP doivent être activées sur DB2 Universal Database for OS/390 et le système partenaire.
  2. Deux numéros de port TCP/IP appropriés doivent être affectés par votre administrateur réseau. Par défaut, DB2 Universal Database for OS/390 utilise le numéro de port 446 pour les connexions de base de données et le numéro de port 5001 pour les demandes de resynchronisation (validation en deux phases).
  3. Le serveur d'applications éloignées ou le demandeur d'application doit utiliser les mêmes numéros de port (ou noms de service) que DB2 Universal Database for OS/390.
  4. Vérifiez que l'option de sécurité TCP/IP "already verified" (déjà vérifié) a la valeur YES. Reportez-vous à la section Fonctions supplémentaires de sécurité.
  5. Le fichier d'amorçage de DB2 Universal Database for OS/390 doit comprendre des paramètres supplémentaires. La Figure 18 présente les paramètres supplémentaires requis pour activer les communications TCP/IP.

    Figure 18. Exemple de définition de fichier d'amorçage de DDF (pour TCP/IP)

    //SYSADMB JOB ,'DB2 5.1 JOB',CLASS=A
    //*
    //*        CHANGE LOG INVENTORY:
    //*        UPDATE BSDS WITH
    //*             - DB2 LOCATION NAME FOR NEW_YORK3
    //*             - VTAM LUNAME (NYM2DB2)
    //*             - DB2/VTAM PASSWORD
    //*
    //*             - GENERIC LU NAME
    //*             - TCP/IP PORT FOR DATABASE CONNECTIONS
    //*             - TCP/IP PORT FOR RESYNCH OPERATIONS
    //*
    //DSNBSDS EXEC PGM=DSNJU003
    //STEPLIB  DD  DISP=SHR,DSN=DSN510.DSNLOAD
    //SYSUT1   DD  DISP=OLD,DSN=DSNC510.BSDS01
    //SYSUT2   DD  DISP=OLD,DSN=DSNC510.BSDS02
    //SYSPRINT DD  SYSOUT=*
    //SYSUDUMP DD  SYSOUT=*
    //SYSIN    DD  *
     DDF    LOCATION=NEW_YORK3,LUNAME=NTYM2DB2,PASSWORD=PSWDBD1,
            GENERICLU=name,PORT=446,RESPORT=5001
    /*
    //*
    

Définition des systèmes éloignés

Lorsqu'une application DB2 Universal Database for OS/390 demande des données issues d'un système éloigné, elle effectue une recherche dans les tables de bases de données de communications pour trouver des informations relatives au système éloigné. La base de données de communications (CDB) est un groupe de tables SQL géré par l'administrateur du système DB2 Universal Database for OS/390. En tant qu'administrateur du système DB2 Universal Database for OS/390, vous pouvez utiliser SQL pour insérer des lignes dans la base de données de communications pour décrire chaque partenaire DRDA potentiel. Vous trouverez une description complète de la base de données de communications et de son utilisation dans les manuels DB2 Universal Database for OS/390 SQL Reference et DB2 Universal Database for OS/390 Installation Guide.

Les informations suivantes sont recherchées dans la base de données de communications :

Peuplement de la base de données de communications 

Aucune mise à jour de la base de données de communications n'est requise si vous n'utilisez que les connexions de bases de données TCP/IP entrantes ; ainsi, si vous souhaitez n'utiliser DB2 Universal Database for OS/390 qu'en tant que serveur TCP/IP, il n'est pas nécessaire de peupler la base de données de communications et les valeurs par défaut peuvent être utilisées. Toutefois, si vous utilisez les connexions SNA entrantes, vous devez laisser au moins une ligne à blanc dans SYSIBM.LUNAMES. Par exemple, pour permettre aux demandes de connexion de bases de données SNA d'être acceptées par n'importe quelle LU DB2 Connect en entrée, utilisez une commande SQL comme celle-ci :

    INSERT INTO SYSIBM.LUNAMES (LUNAME) VALUES ('        ')                        

Lorsque vous utilisez DB2 Universal Database for OS/390 comme demandeur, la base de données de communications doit toujours être mise à jour. Vous devez insérer des lignes dans la table SYSIBM.LOCATIONS ainsi que dans la table SYSIBM.LUNAMES (pour les connexions SNA) ou SYSIBM.IPNAMES (pour les connexions TCP/IP).

En outre, si vous souhaitez contrôler les besoins de sécurité entrante ou la conversion d'id utilisateur entrant pour les connexions SNA, il se peut que d'autre mises à jour soient requises dans la base de données de communications soient requises. Des exemples supplémentaires sont fournis comme indiqué ci-après. La section Définition de la sécurité, indique comment définir la sécurité utilisateur lors de la configuration d'un demandeur d'application et la section Définition de la sécurité, décrit la configuration d'un serveur d'applications.

Le manuel DB2 Universal Database for OS/390 Administration Guide décrit en décrit en détail les conditions requises pour la mise à jour des tables de bases de données de communications. Après avoir rempli la base de données de communications, vous pouvez écrire des requêtes permettant d'accéder aux données présentes sur des systèmes éloignés. Le manuel DB2 Universal Database for OS/390 Installation Reference fournit également des informations sur la mise à jour des bases de données de communications.

Gestion des demandes par la base de données de communications 

Lors de l'envoi d'une demande, DB2 Universal Database for OS/390 utilise la colonne LINKNAME de la table du catalogue SYSIBM.LOCATIONS pour déterminer le protocole de réseau à utiliser pour la connexion de base de données sortante. Pour recevoir des demandes VTAM, vous devez sélectionner un nom LUNAME dans le panneau d'installation DSNTIPR de DB2 Universal Database for OS/390. Pour recevoir des demandes TCP/IP, vous devez sélectionner un port DRDA et un port de resynchronisation dans le panneau d'installation DSNTIP5 de DB2 Universal Database for OS/390. TCP/IP utilise le numéro de port du serveur pour transmettre des demandes du réseau au sous-système DB2 approprié.

Si la valeur de la colonne LINKNAME se trouve dans la table SYSIBM.IPNAMES, TCP/IP est utilisé pour les connexions DRDA. Si la valeur se trouve dans la table SYSIBM.LUNAMES, SNA est utilisé. Si le même nom se trouve à la fois dans SYSIBM.LUNAMES et dans SYSIBM.IPNAMES, TCP/IP est utilisé pour la connexion à l'emplacement.
Remarque :Un demandeur ne peut pas se connecter à un emplacement donné en utilisant à la fois les protocoles SNA et TCP/IP. Par exemple, si la table SYSIBM.LOCATIONS indique LU1 comme LINKNAME et si LU1 est défini à la fois dans la table SYSIBM.IPNAMES et dans la table SYSIBM.LUNAMES, TCP/IP est le seul protocole utilisé pour la connexion à LU1 à partir de ce demandeur.

Tables de bases de données de communications 

La base de données de communications est constituée des tables suivantes :

  1. SYSIBM.LOCATIONS

    Cette table permet à DB2 Universal Database for OS/390 de déterminer les informations d'adresse SNA ou TCP/IP requises pour l'accès à chaque nom RDB_NAME sélectionné par une application DB2 Universal Database for OS/390 pour les demandes sortantes. Les colonnes sont les suivantes :

    LOCATION
    RDB_NAME du système éloigné. DB2 Universal Database for OS/390 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.

    LINKNAME
    Nom de LU ou attributs TCP/IP du système éloigné.

    PORT
    Nom de port TCP/IP ou informations relatives au nom de service (le nom de port par défaut pour DRDA est 446).

    TPN
    Nom du programme transactionnel APPC du système éloigné. Si le système éloigné est un système DB2 Universal Database for OS/390 ou utilise la valeur de TPN DRDA par défaut (X'07F6C4C2'), une chaîne de caractères vide peut être utilisée pour spécifier le TPN car DB2 Universal Database for OS/390 choisit automatiquement la valeur appropriée.

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

    Cette table définit les attributs de réseau des systèmes éloignés utilisant les connexions SNA. 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 Universal Database for OS/390 pour le support de serveur secondaire de DB2 Universal Database for OS/390 (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 Universal Database for OS/390.

    SECURITY_IN
    Options d'acceptation de sécurité réseau requises quant au système éloigné lorsque ce système DB2 Universal Database for OS/390 fait office de serveur pour le système éloigné (conditions requises de sécurité entrante). Les valeurs peuvent être les suivantes :
    • V pour "verify" (vérifié). Une demande de connexion entrante doit comprendre l'un des éléments suivants : un ID utilisateur et un mot de passe, un ID utilisateur et un PassTicket RACF ou un ticket de sécurité DCE.
    • A pour "already verified" (déjà vérifié). Une demande ne requiert pas de mot de passe, bien qu'un contrôle de mot de passe soit effectué si elle est envoyée. Avec cette option, une demande de connexion entrante est acceptée si elle comprend l'un des éléments suivants : un ID utilisateur, un ID utilisateur et un mot de passe, un ID utilisateur et un PassTicket RACF ou un ticket de sécurité DCE.

      Si la colonne USERNAMES contient 'I' ou 'B', RACF n'est pas appelé pour valider les demandes de connexion entrantes ne contenant qu'un ID utilisateur.

    SECURITY_OUT
    Options d'acceptation de sécurité réseau requises du système éloigné lorsque ce système DB2 Universal Database for OS/390 agit en tant que demandeur (conditions requises de sécurité sortante). Les valeurs peuvent être les suivantes :
    • A pour "already verified" (déjà vérifié). Les demandes de connexion sortantes contiennent un ID autorisation, mais pas de mot de passe. L'ID autorisation utilisé pour une demande de connexion sortante est l'ID autorisation de l'utilisateur DB2 ou un ID converti, selon la valeur de la colonne USERNAMES.
    • R pour "RACF PassTicket" (PassTicket RACF). Les demandes de connexion sortantes contiennent un ID utilisateur et un PassTicket RACF. Le nom de LU du serveur est utilisé comme nom d'application du PassTicket RACF.

      L'ID autorisation utilisé pour une demande de connexion sortante est l'ID autorisation de l'utilisateur DB2 ou un ID converti, selon la valeur de la colonne USERNAMES.

    • P pour "password" (mot de passe). Les demandes de connexion sortantes contiennent un ID autorisation et un mot de passe. Le mot de passe est obtenu à partir de la table SYSIBM.USERNAMES ou de RACF, selon la valeur indiquée dans la colonne ENCRYPTPWDS.

      La colonne USERNAMES doit spécifier 'B' ou 'O'.

    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 Universal Database for OS/390.

    MODESELECT
    Détermine si la table SYSIBM.MODESELECT est utilisée ou non pour la sélection d'une entrée de mode de connexion VTAM (nom de mode) basée sur la demande émise par l'utilisateur final ou l'application qui émet la demande. Si cette colonne contient un 'Y', la table SYSIBM.MODESELECT 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 Universal Database for OS/390 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 (entrants seulement, sortants seulement ou les deux).

    GENERIC
    Indique si DB2 Universal Database for OS/390 doit utiliser son nom de LU réel ou générique.
  3. SYSIBM.LUMODES

    Cette table permet de définir le nombre maximal de sessions LU 6.2 (limites CNOS) pour les systèmes partenaires utilisant les connexions APPC (SNA). 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 DB2 Universal Database for OS/390 local 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 définit le nombre maximal de sessions VTAM par défaut pour DB2 Universal Database for OS/390.

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

  4. SYSIBM.MODESELECT

    Cette table vous permet de spécifier différents noms de mode pour des utilisateurs finals individuels et des applications DB2 Universal Database for OS/390. Elle est utilisée uniquement pour les connexions SNA. 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 Universal Database for OS/390. 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.USERNAMES

    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 Universal Database for OS/390 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 faire en sorte que différentes valeurs soient utilisées pour les connexions d'ID utilisateur et l'ID autorisation DB2 Universal Database for OS/390. 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).

    I signifie connexions entrantes, O signifie connexions sortantes.

    Utilisez "O" pour les connexions TCP/IP (la conversion d'ID et l'identification de site émetteur sortantes ne sont pas effectuées pour les demandes TCP/IP).

    AUTHID
    Pour la conversion de nom sortante, il s'agit de l'ID autorisation DB2 Universal Database for OS/390 à 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.

    LINKNAME
    Identifie les emplacements de réseaux VTAM ou TCP/IP associés à cette ligne. Une valeur à blanc dans cette colonne indique que cette règle de conversion de nom s'applique à n'importe quel partenaire TCP/IP ou SNA.

    Si une valeur LINKNAME est spécifiée, l'une des instructions suivantes ou les deux doivent être vraies :

    • Une ligne existe dans SYSIBM.LUNAMES, dont le nom de LUNAME correspond à la valeur spécifiée dans la colonne LINKNAME de la table SYSIBM.USERNAMES. Cette ligne indique le site VTAM associé à cette règle de conversion de nom.
    • Une ligne existe dans SYSIBM.IPNAMES dont le nom LINKNAME correspond à la valeur indiquée dans la colonne SYSIBM.USERNAMES LINKNAME. Cette ligne indique l'hôte TCP/IP associé à cette règle de conversion de nom.

      La conversion de nom et l'identification du site émetteur entrantes ne sont pas effectuées pour les clients TCP/IP.

    NEWAUTHID
    Nouveau nom d'utilisateur final (ID utilisateur SNA ou ID autorisation DB2 Universal Database for OS/390). 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.LUNAMES). Si les mots de passe sont codés, ignorez cette colonne.
  6. SYSIBM.IPNAMES

    Cette table est utilisée pour les noeuds TCP/IP.

    LINKNAME
    La valeur spécifiée dans cette colonne doit correspondre à la valeur spécifiée dans la colonne LINKNAME de SYSIBM.LOCATIONS.

    SECURITY_OUT
    Cette colonne définit l'option de sécurité DRDA utilisée lorsque des applications SQL DB2 locales se connectent à un serveur éloigné associé à cet hôte TCP/IP :
    • A pour "already verified" (déjà vérifié). Les demandes de connexion sortantes contiennent un ID autorisation, mais pas de mot de passe. L'ID autorisation utilisé pour une demande de connexion sortante est l'ID autorisation de l'utilisateur DB2 ou un ID converti, selon la valeur de la colonne USERNAMES.
    • R pour "RACF PassTicket" (PassTicket RACF). Les demandes de connexion sortantes contiennent un ID utilisateur et un PassTicket RACF. La valeur spécifiée dans la colonne LINKNAME est utilisée comme nom d'application PassTicket RACF pour le serveur éloigné.

      L'ID autorisation utilisé pour une demande de connexion sortante est l'ID autorisation de l'utilisateur DB2 ou un ID converti, selon la valeur de la colonne USERNAMES.

    • P pour "password" (mot de passe). Les demandes de connexion sortantes contiennent un ID autorisation et un mot de passe. Le mot de passe provient de la table SYSIBM.USERNAMES.

      La colonne USERNAMES doit spécifier "O."

    USERNAMES
    Cette colonne contrôle la conversion d'ID autorisation sortante. Cette opération est effectuée lorsqu'un ID autorisation est envoyé par DB2 à un serveur éloigné.
    • O signifie qu'un ID sortant fait l'objet d'une conversion. Des lignes de la table SYSIBM.USERNAMES sont utilisées pour effectuer la conversion d'ID.

      Aucune conversion ou identification du site émetteur n'est effectuée pour les ID entrants.

    • Une valeur à blanc signifie qu'aucune conversion n'est effectuée.

    IPADDR
    Cette colonne contient l'adresse IP ou le nom de domaine d'un hôte TCP/IP éloigné. La colonne IPADDR doit être spécifiée comme suit :
    • Si la colonne IPADDR contient une chaîne de caractères justifiée à gauche et contenant quatre valeurs numériques délimitées par des points décimaux, DB2 considère que la valeur est une adresse IP en notation décimale avec points. Par exemple, la chaîne '123.456.78.91' sera interprétée comme une adresse IP en notation décimale avec points.
    • Toutes les autres valeurs sont interprétées en tant que nom de domaine TCP/IP, pouvant être résolu par l'appel "gethostbyname". Les noms de domaine TCP/IP ne tiennent pas compte des majuscules et des minuscules.

Paramétrage des communications (SNA)

VTAM est le gestionnaire de communications des systèmes OS/390. VTAM accepte les verbes LU 6.2 de DB2 Universal Database for OS/390 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 Universal Database for OS/390, 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 des communications (TCP/IP)

Reportez-vous à la section Définition du système local (TCP/IP).

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 OS/390, 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 OS/390 donné, mais ne doit pas forcément l'être sur tout le réseau. 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 Universal Database for OS/390 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 Universal Database for OS/390 émet une demande de base de données répartie, DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 Universal Database for OS/390, vous devez définir "O" ou "B" pour la colonne USERNAMES de la table SYSIBM.LUNAMES ou SYSIBM.IPNAMES. 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 Universal Database for OS/390 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. 3 Le processus de conversion de nom recherche dans la table SYSIBM.USERNAMES, dans la séquence suivante, une ligne qui corresponde à l'un des modèles (TYPE.AUTHID.LINKNAME) suivants :

  1. O.AUTHID.LINKNAME-- 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.LINKNAME-- Règle de conversion pour n'importe quel utilisateur vers un système partenaire particulier.

S'il n'existe aucune ligne correspondante, DB2 Universal Database for OS/390 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 Universal Database for OS/390) 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 19.

Figure 19. SQL pour conversion de nom sortante (SNA)

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

Les tables de bases de données de communications qui en résultent sont illustrées à la Figure 20.

Figure 20. Conversion de nom sortante

                                                                                  
                                                                                 
 

REQTEXT

La Figure 21 présente un exemple plus simple indiquant comment se connecter à un serveur d'applications DRDA DB2 Universal Database à l'aide d'une connexion SNA.

Figure 21. SQL pour conversion de nom sortante (exemple simple pour SNA)

    INSERT INTO SYSIBM.LUNAMES (LUNAME,
                              SECURITY_OUT,                              
                              ENCRYPTPSWDS,                              
                              USERNAMES)                                 
                         VALUES ('NYX1GW01','P','N','O');
  INSERT INTO SYSIBM.LOCATIONS (LOCATION,LINKNAME,TPN)
                             VALUES('TASG6',                             
                                    'NYX1GW01','NYSERVER');
  INSERT INTO SYSIBM.USERNAMES (TYPE,AUTHID,LINKNAME,NEWAUTHID,PASSWORD) 
         VALUES ('O','      ','NYX1GW01','SVTDBM6','SG6JOHN');

La Figure 22 présente un exemple simple indiquant comment se connecter à un serveur d'applications DRDA DB2 Universal Database à l'aide d'une connexion TCP/IP.

Figure 22. SQL pour conversion de nom sortante (exemple simple pour TCP/IP)

-- DB2 for Solaris1 - UNIX                                                      
   DELETE FROM SYSIBM.IPNAMES WHERE LINKNAME = 'SOLARIS1' ;                     
   INSERT INTO SYSIBM.IPNAMES ( LINKNAME                                        
                              , SECURITY_OUT                                    
                              , USERNAMES                                       
                                , IBMREQD                                         
                              , IPADDR)                                         
                       VALUES ( 'SOLARIS1'                                      
                              , 'P'                                             
                              , 'O'                                             
                                , 'N'                                             
                              , '9.21.45.4')                                    
                              ;                                                 
   INSERT INTO SYSIBM.LOCATIONS ( LOCATION                                      
                                , LINKNAME                                      
                                , IBMREQD                                       
                                , PORT                                          
                                , TPN)                                          
                         VALUES ( 'TCPDB1'                                      
                                , 'SOLARIS1'                                    
                                , 'N'                                           
                                , '30088'                                       
                                , '')                                           
                                ;                                               
   INSERT INTO SYSIBM.USERNAMES ( TYPE                                          
                                , AUTHID                                        
                                , LINKNAME                                      
                                , NEWAUTHID                                     
                                , PASSWORD                                      
                                , IBMREQD)                                      
                         VALUES ( 'O'                                           
                                , ''                                            
                                , 'SOLARIS1'                                    
                                , 'svtdbm5'                                     
                                , 'svt5dbm'                                     
                                , 'N')                                          
                                ;                                               

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

Pour les connexions SNA, la LU 6.2 offre trois grandes fonctions de sécurité réseau :

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.LUNAMES ou SYSIBM.IPNAMES en définissant la colonne USERNAMES 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.LUNAMES ne contient ni 'O' ni 'B'.

Dans la mesure où DB2 Universal Database for OS/390 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.LUNAMES contient 'O' ou 'B'.

En fonction des options définies dans la table SYSIBM.LUNAMES, DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 serveur d'applications DB2 Universal Database for OS/390 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 Universal Database for OS/390. DB2 Universal Database for OS/390 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 Universal Database for OS/390. DB2 Universal Database for OS/390 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 Universal Database for OS/390.

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 Universal Database for OS/390 éloigné.

Exécution d'applications éloignées
Pour exécuter une application éloignée, l'utilisateur final DB2 Universal Database for OS/390 doit disposer des droits d'exécution du plan DB2 Universal Database for OS/390 associé à cette application. Le propriétaire du plan DB2 Universal Database for OS/390 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 Universal Database for OS/390. 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 OS/390 est généralement fourni par RACF ou par un autre produit offrant une interface compatible avec RACF. Le demandeur d'application DB2 Universal Database for OS/390 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 Universal Database for OS/390 est livré avec un ID de jeu de caractères codés d'installation dont la valeur par défaut est 500. Cette valeur par défaut n'est probablement pas correcte pour votre installation.

Lors de l'installation de DB2 Universal Database for OS/390, vous devez définir le CCSID d'installation en fonction du CCSID des caractères générés et transmis à DB2 Universal Database for OS/390 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 Universal Database for OS/390 dispose de la fonction de conversion de chaque CCSID du serveur d'applications en CCSID d'installation du sous-système DB2 Universal Database for OS/390. DB2 Universal Database for OS/390 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 Universal Database for OS/390 Administration Guide.


Notes de bas de page :

3
Si la demande est envoyée à un serveur DB2 Universal Database for OS/390, 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 ]