DB2 pour MVS/ESA 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 pour MVS/ESA mais ne peut pas s'exécuter en l'absence du support de gestion de base de données locale de DB2 pour MVS/ESA.
Lorsque DB2 pour MVS/ESA 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 pour MVS/ESA 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 ces opérations s'exécutent correctement, vous devez effectuer les opérations suivantes :
Chaque programme sur le réseau se voit attribuer un NETID et un nom de LU. Votre demandeur d'application DB2 pour MVS/ESA doit donc avoir une valeur NETID.LUNAME lors de sa connexion au réseau. Etant donné que le demandeur d'application DB2 pour MVS/ESA est intégré dans le système de gestion de la base de données DB2 pour MVS/ESA locale, il doit avoir un RDB_NAME. Dans les publications DB2 pour MVS/ESA, il est fait référence au nom RDB_NAME en tant que nom d'emplacement.
Définissez le demandeur d'application DB2 pour MVS/ESA pour le réseau SNA en procédant comme suit :
DB2 pour MVS/ESA 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 pour MVS/ESA de deux manières :
Figure 3. DB2 pour MVS/ESA - Panneau d'installation DSNTIPR
+--------------------------------------------------------------------------------+ | | | 1 DDF STARTUP OPTION ===> AUTO NO (DDF not startable), | | AUTO (automatic start up), or | | COMMAND (start by command) | | 2 DB2 LOCATION NAME ===> SYDNEY The name other DB2s use to | | refer to this DB2 | | 3 DB2 NETWORK LUNAME ===> LUDBD1 The name VTAM uses to refer to this DB2| | 4 DB2 NETWORK PASSWORD ===> PSWDBD1 Password for connecting to other DB2s | | 5 RLST ACCESS ERROR ===> NOLIMIT Action on non-local RLST access error | | NOLIMIT - Run without limit | | NORUN - Do not run at all | | 1-5000000 - Limit in CPU service units | | PRESS: ENTER to continue END to exit HELP for more information | +--------------------------------------------------------------------------------+ |
La Figure 4 montre comment mettre à jour le fichier d'amorçage avec le nom d'emplacement SYDNEY, le nom de LU LUDBD1 et le mot de passe PSWDBD1.
Figure 4. Exemple de définition du fichier d'amorçage de DDF
//SYSADMB JOB ,'DB2 2.3 JOB',CLASS=A //* //* CHANGE LOG INVENTORY: //* UPDATE BSDS WITH //* - DB2 LOCATION NAME FOR SYDNEY //* - VTAM LUNAME (LUDBD1) //* - DB2/VTAM PASSWORD //* //DSNBSDS EXEC PGM=DSNJU003 //STEPLIB DD DISP=SHR,DSN=DSN230.DSNLOAD //SYSUT1 DD DISP=OLD,DSN=DSNC230.BSDS01 //SYSUT2 DD DISP=OLD,DSN=DSNC230.BSDS02 //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSIN DD * DDF LOCATION=SYDNEY,LUNAME=LUDBD1,PASSWORD=PSWDBD1 //* |
Lorsque DDF est lancé (soit automatiquement au démarrage de DB2 pour MVS/ESA, soit au moyen de la commande START DDF de DB2 pour MVS/ESA), il se connecte à VTAM, transmettant le nom de LU et le mot de passe à VTAM. VTAM reconnaît le système DB2 pour MVS/ESA 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 DB2 pour MVS/ESA. Le mot de passe VTAM permet de vérifier que DB2 pour MVS/ESA 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 pour MVS/ESA.
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 pour MVS/ESA, il vous faut enregistrer ces valeurs avec VTAM. VTAM utilise l'instruction APPL pour définir les noms de LU locales. La Figure 5 illustre la définition du nom de LU LUDBD1 pour VTAM.
Figure 5. Exemple de définition APPL pour DB2 pour MVS/ESA
DB2APPLS VBUILD TYPE=APPL * *--------------------------------------------------------------------* * * * APPL DEFINITION FOR THE SYDNEY DB2 SYSTEM * * * *--------------------------------------------------------------------* * LUDBD1 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 - 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 5 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 chacun des partenaires DB2 pour MVS/ESA est issu de la base de données de communications DB2 pour MVS/ESA (colonne USERSECURITY de la table SYSIBM.SYSLUNAMES). SECACPT=ALREADYV vous offre la plus grande souplesse pour la sélection des valeurs de USERSECURITY.
DB2 pour MVS/ESA 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.SYSLUMODES 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.SYSLUMODES, 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 DB2 pour MVS/ESA, le partenaire étant le vainqueur de conflit dans chacune des sessions. Dans la mesure où OS/2 crée les conversations LU 6.2 avec DB2 pour MVS/ESA 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.
Lorsqu'une application DB2 pour MVS/ESA demande des données issues d'un système éloigné, DB2 pour MVS/ESA recherche dans les tables de bases de données de communications des informations relatives au système éloigné. Ces recherches portent également sur :
La base de données de communications est un groupe de tables SQL géré par l'administrateur du système DB2 pour MVS/ESA. En tant qu'administrateur du système DB2 pour MVS/ESA, vous devez utiliser le SQL pour insérer des lignes dans la base de données de communications afin de décrire chaque partenaire DRDA potentiel. La base de données de communications se compose de cinq tables :
Cette table permet à DB2 pour MVS/ESA de déterminer le nom de LU et la valeur de TPN pour chaque RDB_NAME sélectionné par une application DB2 pour MVS/ESA. 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. Les colonnes sont les suivantes :
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 chaque système partenaire. 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 pour MVS/ESA. 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 pour MVS/ESA 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 imposer l'utilisation de valeurs différentes pour l'ID utilisateur SNA et l'ID autorisation DB2 pour MVS/ESA. 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 :
VTAM est le gestionnaire de communications des systèmes MVS. VTAM accepte les verbes LU 6.2 à partir de DB2 pour MVS/ESA 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 pour MVS/ESA, vous devez fournir à VTAM les informations suivantes :
Lorsque DB2 pour MVS/ESA 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 pour MVS/ESA. 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.
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 MVS, 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 MVS particulier mais ne doit pas forcément l'être sur tout le réseau SNA. 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 pour MVS/ESA 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 pour MVS/ESA émet une demande de base de données répartie, DB2 pour MVS/ESA 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 pour MVS/ESA 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 pour MVS/ESA, vous devez définir 'O' ou 'B' pour la colonne USERNAMES de la table SYSIBM.SYSLUNAMES. 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 pour MVS/ESA 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. 2 Le processus de conversion de nom recherche dans la table SYSIBM.SYSUSERNAMES, dans la séquence suivante, une ligne qui corresponde à l'un des modèles (TYPE.AUTHID.LUNAME) suivants :
S'il n'existe aucune ligne correspondante, DB2 pour MVS/ESA 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 pour MVS/ESA) 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 6.
Figure 6. SQL pour conversion de nom sortante
INSERT INTO SYSIBM.SYSLUNAMES (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', 'O'); INSERT INTO SYSIBM.SYSLOCATIONS (LOCATION, LOCTYPE, LINKNAME, LINKATTR) VALUES ('DALLAS', ' ', 'LUDALLAS', ''); INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD) VALUES ('O', 'JONES', 'LUDALLAS', 'NYJONES', 'JONESPWD'); INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD) VALUES ('O', 'DSNPLAN', 'LUDALLAS', ' ', 'PLANPWD'); |
Les tables de bases de données qui en résultent sont illustrées à la Figure 7 :
Figure 7. Conversion de nom sortante
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 :
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.SYSLUNAMES en définissant la colonne USERNAMES de cette table 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 pour MVS/ESA 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.SYSLUNAMES, DB2 pour MVS/ESA obtient le mot de passe de l'utilisateur final de deux sources différentes :
La Figure 8 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 n'importe quelle tentative d'accès à un système éloigné de la part de SMITH ou de JONES.
Figure 8. Envoi de mots de passe sur des sites éloignés
INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD) VALUES ('O', 'JONES', ' ', ' ', 'JONESPWD'); INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD) VALUES ('O', 'SMITH', ' ', ' ', 'SMITHPWD'); |
DB2 pour MVS/ESA recherche dans la table SYSIBM.SYSUSERNAMES 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.SYSUSERNAMES qui déclenchent l'envoi des noms sans conversion. La Figure 9 permet l'envoi de demandes à LUDALLAS et à LUNYC sans conversion du nom d'utilisateur final (ID utilisateur).
Figure 9. Envoi de mots de passe codés sur des sites éloignés
INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD) VALUES ('O', ' ', 'LUNYC', ' ', ' '); INSERT INTO SYSIBM.SYSUSERNAMES (TYPE, AUTHID, LUNAME, 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 demandeur d'application DB2 pour MVS/ESA 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 pour MVS/ESA éloigné.
Le sous-système de sécurité externe sur les systèmes MVS est fourni par RACF ou des produits équivalents qui offrent une interface compatible avec RACF. Le demandeur d'application DB2 pour MVS/ESA 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 pour MVS/ESA est livré avec un ID de jeu de caractères codés d'installation par défaut est 500. Cette valeur par défaut n'est probablement pas correcte pour votre installation.
Lors de l'installation de DB2 pour MVS/ESA, vous devez définir le CCSID d'installation en fonction du CCSID des caractères générés et transmis à DB2 pour MVS/ESA 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 pour MVS/ESA dispose de la fonction de conversion de chaque CCSID du serveur d'applications en CCSID d'installation du sous-système DB2 pour MVS/ESA. DB2 pour MVS/ESA 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 Administration Guide.