DB2 - Connectivité - Informations complémentaires

Mise en oeuvre de DB2 pour OS/390

DRDA définit les types de fonctions de système de gestion de bases de données réparties. DB2 Universal Database for OS/390 prend en charge la fonction unité d'oeuvre éloignée. Avec l'unité d'oeuvre éloignée, un programme d'application s'exécutant sur un système peut accéder aux données d'un système de gestion de bases de données réparties à l'aide du SQL fournir par ce dernier.

DB2 Universal Database for OS/390 prend également en charge l'unité d'oeuvre répartie. Avec l'unité d'oeuvre répartie, un programme d'application s'exécutant sur un système peut accéder à des données au niveau de plusieurs SGBD éloignés en utilisant le SQL fourni par ces derniers. Pour en savoir plus sur les types de distribution définis par DRDA, reportez-vous au manuel DRDA Connectivity Guide.

Comme le montre la Figure 14, DB2 Universal Database for OS/390 prend en charge trois configurations de connexions de bases de données réparties, selon deux méthodes d'accès :

[1] L'accès défini par le système (on parle également de protocole privé de DB2 UDB pour OS/390) permet à un demandeur DB2 UDB pour OS/390 de se connecter à un ou plusieurs serveurs DB2 UDB pour OS/390. Cette connexion établie entre le demandeur DB2 UDB pour OS/390 et le serveur n'adhère pas aux protocoles définis dans DRDA et ne peut pas être utilisée pour connecter des produits non DB2 UDB pour OS/390 à DB2 pour OS/390. L'établissement de ce type de connexion se fait par la codification, dans l'application, de noms ou d'alias composés de trois parties.

[2] L'accès défini par l'application permet à un demandeur DB2 Universal Database for OS/390 ou non DB2 Universal Database for OS/390 (par exemple, DB2 Connect) de se connecter à un ou plusieurs serveurs d'applications DB2 Universal Database for OS/390 ou non DB2 Universal Database for OS/390 (par exemple, DB2 Universal Database et DB2 Universal Database pour AS/400) via des protocoles DRDA. Le nombre de serveurs d'applications pouvant être simultanément connectés au demandeur d'application dépend du niveau de DB2 UDB pour OS/390 du demandeur d'application. Si le demandeur d'application est DB2 pour MVS/ESA version 2.3, un seul serveur d'applications peut être connecté à la fois. L'établissement de ce type de connexion se fait par la codification d'instructions SQL CONNECT dans l'application. Si le demandeur d'application est DB2 pour MVS/ESA version 3.1 ou suivante, un ou plusieurs serveur(s) d'applications peuvent être connecté(s) simultanément.

[3] L'accès défini par l'application et l'accès défini par le système peuvent être utilisés conjointement pour établir des connexions. Vous ne pouvez pas vous connecter en utilisant DRDA et la mémoire contrôlée par le système dans la même unité d'exécution.

Le terme serveur secondaire décrit des systèmes utilisés en tant que serveurs du serveur d'applications.

Si, dans une configuration, tous les systèmes prennent en charge la validation en deux phases, l'unité d'oeuvre répartie (lecture et mise à jour sur plusieurs sites) est prise en charge. Si la validation en deux phases n'est pas prise en charge par tous les systèmes, les mises à jour à l'intérieur d'une unité d'oeuvre sont limitées soit à un seul site ne prenant pas en charge la validation en deux phases, soit au sous-ensemble de sites prenant en charge la validation en deux phases.

Figure 14. Connexions réparties de DB2 Universal Database for OS/390

                                                                                  
                                                                                 
 

REQTEXT

Le Tableau 2 compare les types de connexion de bases de données réparties DB2 Universal Database for OS/390.

Tableau 2. Comparaison de connexions de bases de données réparties DB2 Universal Database for OS/390
[1] Accès défini par le système [2] Accès défini par l'application (l'ensemble des systèmes prenant en charge la validation en deux phases) [3] Accès défini par l'application et accès défini par le système
Tous les partenaires doivent être des systèmes DB2 Universal Database for OS/390. Permet d'interconnecter deux systèmes DRDA, quels qu'ils soient. Le demandeur d'application peut être n'importe quel système DRDA ; les serveurs doivent être des systèmes DB2 Universal Database for OS/390.
Permet une connexion directe à plusieurs partenaires. Permet une connexion directe à plusieurs partenaires. Le demandeur d'application se connecte directement aux serveurs d'applications ; les serveurs d'applications peuvent se connecter à plusieurs serveurs secondaires DB2 Universal Database for OS/390.
Chaque application SQL peut avoir plusieurs conversations avec chaque serveur. Chaque application SQL a une conversation avec chaque serveur. L'application SQL a une conversation avec chaque serveur ; le serveur d'applications DB2 Universal Database for OS/390 peut établir plusieurs conversations avec chaque serveur pour l'application.
Permet d'accéder aux ressources locales et éloignées dans une seule portée de validation. Permet d'accéder aux ressources locales et éloignées dans une seule portée de validation. Le demandeur d'application et le serveur d'applications peuvent accéder aux données locales et éloignées
Plus efficace au niveau de requêtes volumineuses et de requêtes simultanées. Plus efficace au niveau des instructions SQL exécutées très peu de fois dans une seule portée de validation. La connexion demandeur d'application-serveur d'applications se comporte comme [2] ; les connexions de serveurs secondaires se comportent comme [1].
Prise en charge du SQL statique ou dynamique mais le serveur définit dynamiquement l'accès au SQL statique lors de la première exécution dans une seule portée de validation. Permet de lancer des instructions SQL statiques ou dynamiques. Le demandeur d'application et le serveur d'applications peuvent lancer des instructions SQL statiques ou dynamiques ; les serveurs secondaires prennent en charge le SQL statique ou dynamique mais définissent dynamiquement l'accès au SQL statique lors de la première exécution dans une seule portée de validation.
Limité aux instructions SQL INSERT, DELETE et UPDATE ainsi qu'aux instructions qui prennent en charge SELECT. Peut utiliser toute instruction prise en charge par le système qui exécute l'instruction. Les serveurs d'applications prennent en charge toute forme de SQL ; les serveurs secondaires ne prennent en charge que le SQL DML (par exemple, CREATE ou ALTER)

Fonctions supplémentaires de sécurité

Codes de sécurité étendue

Avant la version 5.1 de DB2 Universal Database for OS/390, les demandes de connexion avec ID utilisateur et mot de passe pouvaient ne pas aboutir et générer SQL30082, code raison 0, mais sans explication de l'échec.

La version 5.1 de DB2 Universal Database for OS/390 apporte une amélioration : la prise en charge de codes de sécurité étendue. Celle-ci permet d'obtenir des diagnostics supplémentaires, tels que (MOT DE PASSE PERIME), en plus du code raison.

Pour pouvoir bénéficier de cette amélioration, vous devez affecter la valeur YES au paramètre d'installation ZPARM de DB2 Universal Database for OS/390 pour une sécurité étendue. Pour définir la valeur EXTSEC=YES, utilisez l'écran d'installation DSN6SYSP de DB2 Universal Database for OS/390 ou l'écran DDF 1 (DSNTIPR). La valeur défaut est EXTSEC=NO. Si un mot de passe a expiré, les applications PC, UNIX, Apple Macintosh et Web utilisant DB2 Connect recevront un message d'erreur SQL01404.

Sécurité TCP/IP déjà vérifiée

Pour fournir un support pour l'option de sécurité AUTHENTICATION=CLIENT de DB2 Universal Database, utilisez l'écran d'installation de DB2 Universal Database for OS/390 DSNTIP4 (ou l'écran DDF 2) et affectez la valeur YES au paramètre de sécurité TCP/IP déjà vérifiée.

Sécurité des applications PC ODBC et Java

Les applications ODBC et Java sur postes de travail utilisent des instructions SQL dynamiques, ce qui peut affecter la sécurité pour certaines installations. DB2 Universal Database for OS/390 inclut une nouvelle option de définition d'accès, DYNAMICRULES (BIND), qui permet l'exécution de ce langage sous le contrôle du propriétaire ou du programme de définition d'accès. Pour la procédure de définition de DYNAMICRULES via DB2 Connect, reportez-vous au manuel Command Reference.

DB2 Universal Database et DB2 Connect version 5 fournissent un nouveau paramètre de configuration CLI/ODBC, CURRENTPACKAGESET, figurant dans le fichier de configuration DB2CLI.INI. Vous devez associer à ce paramètre un nom de schéma disposant des privilèges appropriés. Une instruction SQL SET CURRENT PACKAGESET schema sera alors automatiquement émise après chaque connexion à l'application.

Utilisez le gestionnaire ODBC pour mettre à jour le fichier DB2CLI.INI. Pour plus de détails, reportez-vous au manuel Installation et configuration - Informations complémentaires.

Prise en charge de la modification de mot de passe

Si une instruction SQL CONNECT renvoie un message signalant que le mot de passe associé à l'ID utilisateur a expiré, avec DB2 Connect, Version 5.2 et plus, vous pouvez désormais modifier le mot de passe sans avoir à vous connecter à TSO. Via DRDA, DB2 Universal Database for OS/390 peut changer le mot de passe à votre place.

L'utilisateur doit fournir l'ancien mot de passe ainsi que le nouveau mot de passe et le mot de passe de vérification. Si DCS est l'option de sécurité indiquée sur le serveur DB2 Connect Enterprise Edition, une demande de modification du mot de passe est envoyée au serveur de bases de données DB2 Universal Database for OS/390. S'il s'agit de SERVER, le mot de passe du serveur DB2 Connect est modifié.

Avantage supplémentaire, il n'est plus obligatoire de définir le LU de manière distincte. Pour plus de détails, reportez-vous au manuel Mise en route consacré à DB2 Connect Enterprise Edition.


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