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 :
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 :
Reportez-vous aux sections Définition du système local (SNA) ou Définition du système local (TCP/IP).
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 :
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 :
Figure 15. DB2 Universal Database for OS/390 - Panneau d'installation DSNTIPR
+--------------------------------------------------------------------------------+ | | | DISTRIBUTED DATA FACILITY =| |==> _ | | | | Enter data below: | | | | 1 DDF STARTUP OPTION ===> AUTO NO, AUTO, or COMMAND | | 2 DB2 LOCATION NAME ===> NEW_YORK3 The name other DB2s use to | | refer to this DB2 | | 3 DB2 NETWORK LUNAME ===> NYM2DB2 The name VTAM uses to refer to this DB2 | | 4 DB2 NETWORK PASSWORD ===> PSWDBD1 Password for DB2's VTAM application | | 5 RLST ACCESS ERROR ===> NOLIMIT NOLIMIT, NORUN, or 1-5000000 | | 6 RESYNC INTERVAL ===> 3 Minutes between resynchronization period| | 7 DDF THREADS ===> ACTIVE (ACTIVE or INACTIVE) Status of a | | database access thread that commits or | | rolls back and holds no database locks | | or cursors | | 8 DB2 GENERIC LUNAME ===> Generic VTAM LU name for this DB2 | | subsystem or data sharing group | | 9 IDLE THREAD TIMEOUT ===> 120 0 or seconds until dormant server ACTIVE| | thread will be terminated (0-9999) | | 10 EXTENDED SECURITY ===> YES Allow change password and descriptive | | security error codes. YES or NO. | | PRESS: ENTER to continue RETURN to exit HELP for more information | | | +--------------------------------------------------------------------------------+ |
La Figure 16 montre comment mettre à jour le fichier d'amorçage avec le nom d'emplacement NEW_YORK3, le nom de LU NYM2DB2 et le mot de passe PSWDBD1.
Figure 16. Exemple de définition du fichier d'amorçage de DDF (pour VTAM)
//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 //* //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=NYM2DB2,PASSWORD=PSWDBD1 //* |
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.
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 :
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.
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.
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.
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.
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.
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 :
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 /* //* |
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 :
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.
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. |
La base de données de communications est constituée des tables suivantes :
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 :
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.
Cette table définit les attributs de réseau des systèmes éloignés utilisant les connexions SNA. Les colonnes sont les suivantes :
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.
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.
La colonne USERNAMES doit spécifier 'B' ou 'O'.
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.
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 :
La valeur sélectionnée dans CONVLIMIT est utilisée pendant le processus CNOS afin de définir CONVLIMIT/2 pour DMINWNR et DMINWNL.
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 :
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 :
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).
Si une valeur LINKNAME est spécifiée, l'une des instructions suivantes ou les deux doivent être vraies :
La conversion de nom et l'identification du site émetteur entrantes ne sont pas effectuées pour les clients TCP/IP.
Cette table est utilisée pour les noeuds TCP/IP.
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.
La colonne USERNAMES doit spécifier "O."
Aucune conversion ou identification du site émetteur n'est effectuée pour les ID entrants.
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 :
Lorsque DB2 Universal Database for OS/390 communique avec VTAM, il est autorisé à ne transmettre qu'un seul nom de LU (pas NETID.LUNAME) à VTAM pour identifier la destination voulue. Ce nom de LU doit être unique parmi les noms de LU connus du système VTAM local, permettant ainsi à VTAM de déterminer les noms de NETID et de LU à partir du nom de LU transmis par DB2 Universal Database for OS/390. Le fait que les noms de LU soient uniques sur le réseau SNA d'une entreprise simplifie grandement le processus de définition des ressources VTAM. Toutefois, cela n'est pas toujours possible. Si les noms de LU de vos réseaux SNA ne sont pas uniques, vous devez utiliser la conversion de nom de LU VTAM afin de créer la combinaison NETID.LUNAME correcte pour un nom de LU qui n'est pas unique. Vous trouverez la description de cette procédure dans la section "Resource Name Translation" du manuel VTAM Network Implementation Guide.
L'emplacement et la syntaxe de ces définitions VTAM permettant de définir des noms de LU éloignée dépendent essentiellement du type de connexion physique et logique du système éloigné au système VTAM local.
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 :
Si vous indiquez le paramètre NCP MAXBFRU, sélectionnez une valeur pouvant gérer la taille de RU plus 29 octets. Dans la cas de NCP, le paramètre MAXBFRU définit le nombre de tampons d'E-S VTAM pouvant prendre en charge l'unité d'information acheminable (PIU). Si vous choisissez une taille de tampon IOBUF de 441, MAXBFRU=10 traite correctement une RU de 4 ko car 10*441 est supérieur à 4096+29.
Reportez-vous à la section Définition du système local (TCP/IP).
Lorsqu'un système éloigné exécute des opérations de traitement sur des bases de données réparties au nom d'une application SQL, il doit être capable de répondre aux critères de sécurité du demandeur d'application, du serveur d'applications et du réseau reliant ces derniers entre eux. Ces critères entrent dans une ou plusieurs des catégories suivantes :
Dans 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 :
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
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') ; |
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 :
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.
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 :
La Figure 23 définit les mots de passe pour SMITH et JONES. La colonne LUNAME de l'exemple contient des valeurs à blanc, par conséquent ces mots de passe sont utilisés pour toute tentative d'accès à un système éloigné de la part de SMITH ou de JONES.
Figure 23. Envoi de mots de passe sur des sites éloignés (SNA)
INSERT INTO SYSIBM.USERNAMES (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD) VALUES ('O', 'JONES', ' ', ' ', 'JONESPWD'); INSERT INTO SYSIBM.USERNAMES (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD) VALUES ('O', 'SMITH', ' ', ' ', 'SMITHPWD'); |
DB2 Universal Database for OS/390 recherche dans la table SYSIBM.USERNAMES l'ID utilisateur (valeur NEWAUTHID) à transmettre au système éloigné. Ce nom converti permet l'extraction du mot de passe RACF. Si vous ne souhaitez pas convertir les noms, vous devez créer des lignes dans la table SYSIBM.USERNAMES qui déclenchent l'envoi des noms sans conversion. La Figure 24 permet l'envoi de demandes à LUDALLAS et à LUNYC sans conversion du nom d'utilisateur final (ID utilisateur).
Figure 24. Envoi de mots de passe codés sur des sites éloignés (SNA)
INSERT INTO SYSIBM.USERNAMES (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD) VALUES ('O', ' ', 'LUNYC', ' ', ' '); INSERT INTO SYSIBM.USERNAMES (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD) VALUES ('O', ' ', 'LUDALLAS', ' ', ' '); |
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 :
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é.
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 :
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.