DB2 - Connectivité - Informations complémentaires

Configuration du demandeur d'application

La prise en charge des demandeurs d'application DRDA par le système AS/400 fait partie intégrante du système d'exploitation OS/400. Par conséquent, il suffit que ce dernier soit actif pour que cette prise en charge soit assurée. Cela s'applique également à la prise en charge du serveur d'applications dans DB2 Universal Database pour AS/400.

Lorsque DB2 Universal Database pour AS/400 joue le rôle de demandeur d'application, il peut se connecter à tout serveur d'applications prenant en charge le protocole DRDA. Si vous souhaitez que DB2 Universal Database pour AS/400 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

Le demandeur d'application doit être capable d'accepter un nom de base de données relationnelle et de le convertir en paramètres de réseau. Le système AS/400 utilise le répertoire des bases de données relationnelles pour enregistrer le nom des bases de données relationnelles ainsi que les paramètres réseau correspondants. Ce répertoire permet au demandeur d'application AS/400 de transmettre les données réseau nécessaires à l'établissement de communications dans un réseau de base de données répartie.

La plupart des opérations de traitement exécutées dans un environnement de bases de données réparties nécessitent l'échange de messages avec d'autres sites du réseau. Pour que ces opérations s'exécutent correctement en environnement SNA, vous devez :

Définition du système local pour DB2 Universal Database pour AS/400

Le répertoire des bases de données relationnelles de chaque demandeur d'application doit comporter une entrée correspondant à la base de données relationnelle locale ainsi qu'une entrée pour chaque base de données relationnelle éloignée auquel accède le demandeur d'application. Sur le réseau de base de données répartie, tout système AS/400 qui joue le rôle uniquement de serveur d'applications doit disposer, dans son répertoire de bases de données relationnelles, d'une entrée correspondant à la base de données relationnelle locale. Pour plus de détails sur le répertoire des bases de données relationnelles, reportez-vous au manuel AS/400 Distributed Database Programming.

Pour définir le système local, nommez la base de données locale en ajoutant, dans le répertoire des bases de données relationnelles, une entrée correspondant à un un nom d'emplacement éloigné avec la valeur *LOCAL. Cette opération s'effectue à l'aide de la commande ADDRDBDIRE. L'exemple suivant utilise la commande ADDRDBDIRE, où ROCHESTERDB désigne la base de données du demandeur d'application :

   ADDRDBDIRE RDB(ROCHESTERDB) RMTLOCNAME(*LOCAL)

Pour plus de détails sur le répertoire des bases de données relationnelles, reportez-vous au manuel AS/400 Distributed Database Programming.
Remarque :Dans les versions les plus récentes d'OS/400, le nom de la base de données relationnelle locale est créé automatiquement s'il n'existe pas au moment requis. Le nom utilisé est le nom de système figurant dans les attributs réseau.

Définition du système éloigné pour DB2 Universal Database pour AS/400

Le répertoire des bases de données relationnelles de chaque serveur d'applications du réseau de base de données répartie doit comporter une entrée locale ainsi qu'une entrée pour chaque base de données éloignée de chaque demandeur d'application. Pour créer ces entrées, procédez comme suit :

Pour les connexions TCP/IP (prises en charge dans DB2 Universal Database pour AS/400 version 4.2), seuls le nom de la base de données éloignée, et l'adresse et le port IP associé sont requis. Reportez-vous au manuel Connexion de DB2 Universal Database pour AS/400 au sein d'un réseau DRDA via TCP/IP.

Paramétrage des communications SNA

La présente section décrit comment configurer les communications sur l'AS/400 à l'aide de l'architecture APPN. Le système AS/400 permet également la configuration de communications APPC avancées, mais celles-ci n'offrent pas de support pour l'acheminement des données sur réseau. Une base de données répartie AS/400 peut toutefois fonctionner avec ces deux types de configuration. Pour plus de détails sur les configurations APPC, reportez-vous au manuel OS/400 Communications Configuration.

La fonction AnyNet de l'AS/400 permet à des applications APPC de s'exécuter sur un réseau TCP/IP (Transmission Control Protocol/Internet Protocol). Les exemples fournis dans les sections qui suivent incluent DDM (gestion de fichiers éloignés), SNA Distribution Services (services de distribution SNA), Alerts (fonction d'alerte) et 5250 Display Station Pass-Through (fonction passe-système 5250). La configuration de certains paramètres supplémentaires suffit à exécuter ces applications sans modification sur un réseau TCP/IP. Pour indiquer la prise en charge de AnyNet, affectez la valeur *ANYNW au paramètre LINKTYPE de la commande CRTCTLAPPC.

Pour plus de détails sur APPC sur TCP/IP, reportez-vous aux manuels OS/400 Communications Configuration et OS/400 TCP/IP Configuration and Reference. Le support TCP/IP en natif pour les communications DRDA est fourni dans DB2 Universal Database pour AS/400 version 4.2. Pour plus de détails, reportez-vous au Chapitre Connexion de DB2 Universal Database pour AS/400 au sein d'un réseau DRDA via TCP/IP.

APPN comporte une fonction de mise en réseau qui permet à l'AS/400 de se connecter à un réseau de systèmes et de le contrôler sans avoir à utiliser le support de mise en réseau traditionnellement fourni par un grand système. Les étapes suivantes vous permettent de configurer un AS/400 pour le support APPN :

  1. Définition des attributs de réseau à l'aide de la commande CHGNETA (Modifier les attributs réseau)

    Les attributs de réseau à définir sont les suivants :

  2. Création de la description de la ligne de communication

    La description de la ligne de communication décrit la liaison physique ainsi que le protocole de liaison de données à utiliser entre l'AS/400 et le réseau. Pour la créer, utilisez les commandes suivantes :

  3. Création de descriptions de contrôleur

    Les descriptions de contrôleur décrivent les systèmes adjacents du réseau. Pour indiquer que le support APPN doit être utilisé, spécifiez APPN(*YES) lors de leur création. Les commandes nécessaires à la création des descriptions de contrôleur sont les suivantes :

    Si la valeur *YES est affectée au paramètre AUTOCRTCTL dans une description de ligne en anneau à jeton ou Ethernet, une description de contrôleur est créée automatiquement lorsque le système reçoit une demande de démarrage de session sur une ligne en anneau à jeton ou Ethernet.

  4. Création d'une description de classe de service

    Utilisez la description de classe de service pour sélectionner les voies de communication (encore appelées routes ou groupes de transmission) et déterminer la priorité de transmission. Cinq descriptions de classe de service sont fournies par le système :

    #CONNECT
    Classe de service par défaut.

    #BATCH
    Classe de service pour les travaux par lots.

    #BATCHSC
    Semblable à la classe de service BATCH, à la différence qu'une sécurité de liaison de données correspondant au moins à un réseau à commutation de paquets est nécessaire. Dans les réseaux de ce type, les données n'empruntent pas toujours la même voie.

    #INTER
    Classe de service configurée pour les communications interactives.

    #INTERSC
    Semblable à la classe de service INTER, à la différence qu'une sécurité de liaison de données correspondant au moins à un réseau à commutation de paquets est nécessaire.

    Pour créer d'autres descriptions de classe de service, utilisez la commande CRTCOSD.

  5. Création d'une description de mode

    La description de mode fournit les caractéristiques des sessions ainsi que le nombre de sessions susceptibles d'être utilisées pour négocier les valeurs autorisées entre l'emplacement local et l'emplacement éloigné. Elle pointe également vers la classe de service utilisée pour la conversation. Plusieurs modes prédéfinis sont livrés avec le système :

    BLANK
    Nom du mode par défaut spécifié dans les attributs réseau à la livraison du système.

    #BATCH
    Mode configuré pour les travaux traités par lots.

    #BATCHSC
    Semblable à BATCH, à la différence qu'une sécurité de liaison de données correspondant au moins à un réseau à commutation de paquets est nécessaire pour la classe de service associée.

    #INTER
    Mode configuré pour les communications interactives.

    #INTERSC
    Semblable à INTER, à la différence qu'une sécurité de liaison de données correspondant au moins à un réseau à commutation de paquets est nécessaire pour la classe de service associée.

    IBMRDB
    Mode configuré pour les communications DRDA.

    Pour créer d'autres descriptions de mode, utilisez la commande CRTMODD.

  6. Création de descriptions d'unité

    La description d'unité fournit les caractéristiques de la connexion physique entre le système local et le système éloigné. Vous n'avez pas à créer manuellement des descriptions d'unité si l'AS/400 s'exécute avec APPN et en tant qu'unité logique (LU) indépendante. Le système AS/400 crée automatiquement la description d'unité et l'associe à la description de contrôleur appropriée lors de l'établissement de la session. Si l'AS/400 est une LU dépendante, vous devez créer manuellement les descriptions d'unité à l'aide de la commande CRTDEVAPPC. Spécifiez la valeur APPN(*YES) dans la description d'unité pour indiquer qu'APPN est utilisé.

  7. Création de listes d'emplacements APPN

    Si vous devez ajouter d'autres emplacements locaux (appelés LU dans d'autres systèmes) ou définir des caractéristiques spéciales pour des emplacements APPN éloignés, vous devez créer des listes d'emplacements APPN. Le nom d'emplacement local correspond au nom de point de contrôle spécifié dans les attributs réseau. Si vous avez besoin d'emplacements supplémentaires pour l'AS/400, une liste d'emplacements locaux APPN doit être créée. Par exemple, si un emplacement éloigné n'appartient pas au même réseau que celui dont fait partie l'emplacement local, vous devez définir des caractéristiques particulières pour cet emplacement éloigné. Cela suppose la création d'une liste d'emplacements éloignés APPN. La commande CRTCFGL (Créer une liste de configuration) vous permet de définir des listes d'emplacements.

  8. Activation des communications.

    Vous pouvez activer les descriptions de communication à l'aide de la commande VRYCFG (Changer l'état de configuration) ou WRKCFGSTS (Gérer l'état de la configuration). Si les descriptions de ligne sont activées, les contrôleurs et les unités appropriés connectés à celles-ci sont aussi activés. La commande WRKCFGSTS permet également de visualiser l'état de chaque connexion.

  9. Taille de RU et régulation

    La taille de RU et la régulation sont déterminées en fonction des valeurs spécifiées dans la description de mode. Lors de la création de cette dernière, des valeurs par défaut sont proposées pour ces deux paramètres. Il s'agit d'estimations AS/400 convenant à la plupart des environnements comportant une base de données répartie. Si la valeur par défaut est acceptée pour la taille de RU, le système AS/400 détermine la valeur la plus appropriée à utiliser. Lorsque l'AS/400 communique avec un autre système prenant en charge la régulation adaptative, la valeur spécifiée pour la régulation ne constitue qu'une valeur de départ. La régulation est ajustée par chaque système, en fonction de sa capacité à gérer les données qu'il reçoit. Dans le cas de systèmes ne prenant pas en charge la régulation adaptative, la valeur de la régulation est négociée au démarrage de la session et reste la même pour toute la durée de cette dernière. Pour plus de détails, reportez-vous au manuel OS/400 Communications Configuration.

Remarques :

  1. La description de contrôleur correspond aux macros d'unité physique NCP/VTAM (Network Control Program and Virtual Telecommunications Access Method).

  2. La description d'unité correspond à la macro d'unité logique NCP/VTAM. Elle contient des informations comparables à celles qui sont consignées dans le profil de LU partenaire sous Communications Manager/2 1.1.

  3. La description de mode correspond aux tables de modes NCP/VTAM et au profil Mode service de transmission sous Communications Manager.

Pour plus de détails sur la configuration du support de mise en réseau et la gestion des listes d'emplacements, reportez-vous aux manuels OS/400 Communications Configuration et APPN Support. Pour consulter des exemples illustrant l'utilisation des commandes CL pour la définition des configurations système, reportez-vous au manuel AS/400 Distributed Database Programming.

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 en lieu et place 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

Sur les systèmes AS/400, un ID utilisateur de 1 à 10 caractères est affecté à chaque utilisateur final. Cet identificateur doit être distinct pour chacun d'eux au sein d'un même système, mais pas nécessairement au sein du réseau. Il s'agit de l'ID utilisateur transmis au système éloigné lors de l'établissement d'une connexion entre deux bases de données. Pour éviter les conflits entre les ID utilisateur définis sur les différents systèmes du réseau, il est fréquent qu'ils fassent l'objet d'une conversion sortante, avant d'être transmis sur le réseau. Toutefois, le système AS/400 n'offre aucune fonction de conversion sortante permettant la résolution des conflits potentiels sur le serveur. Ces conflits doivent être résolus au niveau du serveur d'applications, sauf si vous utilisez les clauses supplémentaires USER et USING avec l'instruction AS/400 SQL CONNECT. USER est un ID utilisateur reconnu sur le serveur d'applications et USING est le mot de passe correspondant.

Sécurité réseau

Une fois que le demandeur d'application a sélectionné les noms d'utilisateurs finals pour représenter l'application éloignée, il doit fournir les données de sécurité réseau LU 6.2 requises. Il existe trois principales fonctions de sécurité réseau pour les unités logiques LU 6.2 :

La sécurité assurée au niveau des sessions s'effectue par le biais d'une vérification de LU à LU. Une clé est associée à chaque LU et doit concorder avec la clé de la LU éloignée. Vous en spécifiez la valeur à l'aide du mot clé LOCPWD de la commande CRTDEVAPPC.

Dans la mesure où le serveur d'applications est chargé de la gestion des ressources de bases de données, il détermine les fonctions de sécurité réseau requises pour le demandeur d'application. Il revient à l'administrateur de la sécurité AS/400 de vérifier que les contraintes de sécurité imposées par chaque serveur d'applications ne dépassent pas les fonctions prises en charge par le demandeur d'application AS/400.

Les options de sécurité possibles pour les conversations SNA sont les suivantes :

SECURITY=SAME
Cette option est également connue sous le nom de "sécurité déjà vérifiée". Elle suppose que seul l'ID utilisateur d'une application soit transmis au système éloigné. Aucun mot de passe n'est transmis. Dans les versions antérieures à la version 2.2.0 de l'AS/400, ce niveau de sécurité était le seul qui soit pris en charge par un demandeur d'application AS/400.

SECURITY=PGM
Cette option entraîne la transmission à la fois de l'ID utilisateur et du mot de passe d'un utilisateur au système éloigné pour authentification. Dans les versions antérieures à la version 2.2.0 de l'AS/400, cette option de sécurité n'était pas prise en charge par un demandeur d'application AS/400.

SECURITY=NONE
Cette option n'est pas prise en charge lorsque l'AS/400 est un demandeur d'application.

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

L'AS/400 ne dispose pas d'un sous-système de sécurité externe. Toutes les procédures de sécurité sont gérées par la fonction de sécurité du système d'exploitation OS/400, comme le décrit la section suivante (Sécurité système).

Sécurité système

Le système d'exploitation OS/400 assure le contrôle des accès à tous les objets du système (programmes, modules, tables, vues, collections, etc.).

Le demandeur d'application contrôle les accès aux seuls objets résidant sur celui-ci. La sécurité des objets résidant sur le serveur d'applications est assurée par ce dernier, en fonction de l'ID utilisateur qui lui est transmis par le demandeur d'application. Cet ID utilisateur est associé à l'utilisateur du demandeur d'application AS/400 ou à l'ID utilisateur indiqué dans la clause USER de l'instruction SQL CONNECT (par exemple, CONNECT TO nom-bdd USER id-utilisateur USING mot-de-passe).

La sécurité des objets peut être modifiée à l'aide des commandes CL de gestion des droits sur les objets ou des instructions SQL GRANT et REVOKE. Vous disposez notamment des deux commandes CL suivantes : GRTOBJAUT (Octroyer droits sur un objet) et RVKOBJAUT (Révoquer droits sur un objet). Ces commandes peuvent être utilisées pour tout objet du système. Les instructions GRANT et REVOKE, en revanche, ne s'appliquent qu'aux objets SQL : tables, vues et modules. Par conséquent, si vous devez modifier les droits d'accès à d'autres objets (programmes ou collections, par exemple), utilisez les commandes GRTOBJAUT et RVKOBJAUT.

Affectation et révocation de droits 

Utilisez la commande suivante sur un système AS/400 pour octroyer à l'utilisateur UTIL1 les droits *USE sur le programme PGMA :

   GRTOBJAUT OBJ(PGMA) OBJTYPE(*PGM) USER(UTIL1) AUT(*USE)

La commande permettant de révoquer ces mêmes droits est la suivante :

   RVKOBJAUT OBJ(PGMA) OBJTYPE(*PGM) USER(UTIL1) AUT(*USE)

*PGM indique que l'objet est le type programme. *SQLPKG, *LIB et *FILE sont utilisés respectivement pour un module, une collection et une table.

Les commandes GRTOBJAUT et RVKOBJAUT peuvent également être utilisées pour empêcher les utilisateurs de créer des programmes et des modules. En cas de révocation du droit sur une quelconque commande CRTSQLxxx (où xxx = RPG, C, CBL, FTN ou PLI), l'utilisateur perd la possibilité de créer des programmes. Si la révocation porte sur la commande CRTSQLPKG, il devient impossible à l'utilisateur de créer des modules à partir du demandeur d'application ou sur le serveur d'applications.

Par exemple, entrez la commande suivante sur le système AS/400 pour octroyer à l'utilisateur UTIL1 le droit *USE sur la commande CRTSQLPKG :

   GRTOBJAUT OBJ(CRTSQLPKG) OBJTYPE(*CMD) USER(UTIL1) AUT(*USE)

Cette commande permet à l'utilisateur d'exécuter la commande crtsqlpkg sur le demandeur d'application. Sur le serveur d'applications, elle lui permet créer des modules.

La commande permettant de révoquer le même droit est la suivante :

   RVKOBJAUT OBJ(CRTSQLPKG) OBJTYPE(*CMD) USER(UTIL1) AUT(*USE)

Affectation des droits par défaut 

Lorsque des objets sont créés, les utilisateurs se voient octroyer des droits d'accès par défaut à ces derniers : le créateur d'une table, d'une vue ou d'un programme dispose de tous les droits sur ces objets, tandis que les autres utilisateurs se voient octroyer les mêmes droits que ceux dont ils disposent sur la bibliothèque ou la collection dans laquelle ces objets sont créés.

Pour plus de détails sur la sécurité système, reportez-vous au manuel AS/400 Security - Reference.

Représentation des données

Les produits prenant en charge l'architecture DRDA effectuent automatiquement les opérations de conversion requises sur le système récepteur. Il est toutefois nécessaire que le CCSID (ID de jeu de caractères codés) du demandeur d'application soit reconnu par le système récepteur.

Sur un demandeur d'application, prêtez attention au CCSID associé aux éléments suivants :


Notes de bas de page :

4
Sous OS/400, le "nom d'emplacement" correspond à "nom de LU" en VTAM, et le "nom d'emplacement éloigné", à "nom de LU éloignée ou de partenaire".


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