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 :
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 :
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. |
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 :
Dans la plupart des cas, il suffit d'indiquer le nom de la base de données éloignée et le nom d'emplacement éloigné 4 de la base de données. Lorsque seul le nom de l'emplacement éloigné est spécifié, les valeurs par défaut sont utilisées pour les autres paramètres. Le système sélectionne une description d'unité en fonction du nom d'emplacement éloigné.
Si plusieurs descriptions d'unités contiennent le même nom d'emplacement éloigné et qu'une description spécifique est requise, les valeurs indiquées pour le nom d'emplacement local et l'ID éloigné réseau dans l'entrée du répertoire des bases de données relationnelles doivent concorder avec celles figurant dans la description d'unité. La sélection de descriptions d'unités pouvant s'avérer complexe lorsque plusieurs d'entre elles utilisent le même nom d'emplacement éloigné, essayez d'utiliser des noms distincts dans chacune d'elles afin de limiter les risques de confusion. Par défaut, le nom du programme de transaction de la base de données éloignée est celui associé par défaut à DRDA, c'est à dire X'07F6C4C2'.
Les paramètres de communication indiqués dans le répertoire des bases de données relationnelles sont utilisés pour établir une conversation avec le système éloigné.
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.
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 :
Les attributs de réseau à définir sont les suivants :
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 :
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.
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 :
Pour créer d'autres descriptions de classe de service, utilisez la commande CRTCOSD.
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 :
Pour créer d'autres descriptions de mode, utilisez la commande CRTMODD.
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é.
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.
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.
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 :
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.
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 :
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.
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 :
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).
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.
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)
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.
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 :
La fonction de support de gestion de travaux OS/400 affecte au CCSID d'un travail la valeur du CCSID figurant dans le profil utilisateur. Si cette valeur est *SYSVAL, la fonction de support de gestion extrait le CCSID à partir de la valeur système QCCSID (fixée initialement à 65535). Si 65535 est affecté au CCSID de travaux portant sur la connexion à partir de DB2 Universal Database, les tentatives de connexion n'aboutissent pas. Modifier la valeur système QCCSID aurait une incidence sur l'ensemble du système. Il est donc recommandé de modifier le CCSID du profil utilisateur pour le travail qui est à l'origine du travail de serveur, en affectant à cet CCSID la valeur appropriée (par exemple, 37 pour l'anglais américain). En règle générale, il est judicieux d'utiliser le CCSID de l'AS/400 auquel vous vous connectez.
Le CCSID d'un travail peut être modifié à l'aide de la commande CHGJOB (Modifier un travail). Si la modification doit également porter sur les travaux suivants, utilisez la commande CHGUSRPRF (Modifier un profil utilisateur) pour modifier la valeur du CCSID dans le profil utilisateur. Pour connaître le CCSID en cours pour un travail, utilisez dans un programme CL la commande RTVJOBA (Extraire attributs du travail). En mode interactif, exécutez pour ce faire la commande WRKJOB (Gérer un travail), puis sélectionnez l'option 2 (Attributs de définition).
Par défaut, le CCSID d'un fichier physique de base de données est le même que celui attribué par défaut au travail lors de sa création (et qui peut être différent du CCSID en cours). Ceci ne s'applique pas si un CCSID a été explicitement indiqué dans la commande CRTPF (Créer un fichier physique) ou CRTSRCPF (Créer un fichier source). Avant DB2 pour l'AS/400 V3R1, le CCSID du travail représentait la valeur par défaut, soit 65535, inadapté pour l'architecture DRDA. Le CCSID de travail par défaut n'est plus 65535 et est donc approprié pour les fichiers physiques auxquels l'accès s'effectue via DRDA.
Vous pouvez utiliser la commande DSPFD (Afficher description fichier) pour visualiser le CCSID d'un fichier ou la commande DSPFFD (Afficher description des zones) pour connaître le CCSID des zones d'un fichier.
Utilisez la commande CHGPF (Modifier un fichier physique) pour modifier le CCSID d'un fichier physique. Les fichiers physiques ne sont pas nécessairement modifiables si une ou plusieurs des conditions suivantes sont remplies :