Le support du serveur d'applications dans DB2 pour VM permet à ce dernier de jouer le rôle de serveur pour les demandeurs d'application DRDA. Le demandeur d'application connecté à un serveur d'applications DB2 pour VM peut être :
Quel que soit le demandeur d'application connecté à un serveur d'applications DB2 pour VM, ce dernier permet au demandeur d'application d'accéder aux objets de base de données (tels que les tables) stockés en local sur le serveur d'applications DB2 pour VM. Le demandeur d'application doit créer un module contenant les instructions SQL de l'application sur le serveur d'applications avant l'établissement de la connexion.
Pour que le serveur d'applications DB2 pour VM puisse traiter les demandes de bases de données réparties, vous devez effectuer les opérations ci-après :
Pour que le serveur d'applications puisse recevoir des demandes de bases de données réparties, vous devez le définir sur le sous-système de communications local et affecter une valeur unique à RDB_NAME.
Procédez par étapes dans l'ordre suivant pour définir le serveur d'applications :
Le NETID est défini pour VTAM en tant que paramètre de lancement et toutes les demandes réparties à partir du demandeur d'application sont acheminées correctement. Le serveur d'applications DB2 pour VM ne définit pas le NETID.
Le serveur d'applications DB2 pour VM ne détermine pas non plus la passerelle à utiliser pour l'acheminement des demandes réparties entrantes provenant du demandeur d'application. Ce processus est toujours contrôlé par le demandeur d'application. Dans le cas d'un demandeur d'application DB2 pour VM, le répertoire de communications CMS indique le nom de la passerelle à l'aide des marques :luname et :tpn.
Pour que le serveur d'applications DB2 pour VM prenne en charge l'activité d'unité d'oeuvre répartie, le demandeur d'application doit sélectionner une passerelle AVS définie sur VTAM à l'aide du paramètre SYNCLVL=SYNCPT. Vérifiez que la passerelle AVS a été définie pour prendre en charge les unités d'oeuvre réparties.
Une fois que vous avez choisi la taille de RU, le nombre maximal de sessions et la régulation, évaluez l'impact que ces valeurs peuvent avoir sur le pool IOBUF VTAM.
L'ID ressource (RESID) correspond au nom de programme transactionnel sous VM. Dans l'environnement VM, il est généralement défini sous forme alphanumérique en 8 octets au plus. En principe, l'ID ressource défini doit être identique au nom du serveur, dans le but de faciliter la gestion du système. La Figure 34 présente un exemple de fichier RESID NAMES.
Figure 34. Exemple de fichier RESID NAMES
+--------------------------------------------------------------------------------+ | RESID NAMES A1 V 132 Trunc=132 Size=4 Line=1 Col=1 Alt=3 | |====> | |00001 :nick.MTLTPN | |00002 :dbname.MONTREAL_SALES_DB | |00003 :resid.SALES | |00004 | +--------------------------------------------------------------------------------+ |
Reportez-vous à la Figure 33, pour consulter l'entrée du répertoire de communications définissant ce nom dbname et l'ID ressource (en tant que TPN). Si le nom du serveur d'applications ne peut pas être identique à l'ID ressource (RESID), le serveur d'applications DB2 pour VM utilise le fichier RESID NAMES pour établir le mappage. Le mappage est nécessaire dans les cas suivants :
Lors de l'installation, la valeur par défaut doit utiliser le nom du serveur indiqué dans le fichier SQLDBINS EXEC comme ID ressource. Pour créer une entrée de mappage dans le fichier RESID NAMES, indiquez le paramètre RESID dans SQLDBINS.
Lorsque vous démarrez la base de données en utilisant SQLSTART DB(nom_serveur), DB2 pour VM consulte l'ID ressource correspondant et informe VM qu'il s'agit de la ressource à contrôler. S'il ne trouve pas l'entrée dans le fichier RESID NAMES, DB2 pour VM suppose que l'ID ressource est identique au nom du serveur et le signale à VM. Pour de plus amples informations, reportez-vous au manuel DB2 for VM System Administration.
Le serveur d'applications DB2 pour VM peut ne pas disposer du support DRDA. Procédez comme suit pour préparer le serveur d'applications DB2 pour VM aux communications DRDA :
Reportez-vous au manuel VM/ESA System Administration pour plus de détails.
Lorsqu'un demandeur d'application achemine une demande portant sur une base de données répartie vers le serveur d'applications DB2 pour VM, les critères de sécurité suivants peuvent être pris en compte :
Dans SQL et LU 6.2, les utilisateurs finals sont identifiés par un ID utilisateur comportant 1 à 8 octets. Cet ID utilisateur doit être unique pour un système d'exploitation particulier mais ne doit pas forcément l'être sur tout le réseau SNA. Pour éviter les conflits de dénomination, DB2 pour VM peut facultativement utiliser la fonction de conversion d'ID utilisateur fournie par AVS, mais uniquement dans les conditions suivantes :
Si une connexion est acheminée sur un serveur via AVS et que l'option SECURITY=SAME est utilisée, l'ID utilisateur AVS doit être converti. La commande AGW ADD USERID lancée à partir de la machine AVS doit fournir un niveau de sécurité suffisant pour permettre la connexion d'utilisateurs d'une LU éloignée ou d'une passerelle AVS spécifique. Un mappage doit être disponible pour toutes les LU et les ID utilisateur entrants se connectant avec l'option SECURITY=SAME L'utilisation de cette commande est très souple ; vous pouvez accepter tous les ID utilisateur d'une LU particulière ou de toutes les LU éloignées. Vous pouvez aussi accepter un ensemble d'ID utilisateur spécifiques d'une LU spécifique.
Si vous utilisez la commande AGW ADD USERID pour autoriser les ID utilisateur entrants (déjà vérifiés) sur la machine AVS locale, aucune validation n'est effectuée par l'hôte. Cela signifie que l'ID autorisé n'existe pas forcément sur l'hôte mais que la connexion est acceptée.
Il existe deux méthodes pour modifier l'autorisation accordée à l'ID utilisateur AVS :
Par exemple, l'utilisation d'ID utilisateur identiques sur des sites différents permet d'illustrer la façon dont la fonction de conversion AVS permet de résoudre les conflits de dénomination. Prenez le cas d'un utilisateur dont l'ID est JONES et résidant sur le système Toronto, et d'un autre ayant un ID identique mais localisé sur le système Montréal. Si l'utilisateur JONES de Montréal veut accéder aux données se trouvant sur le système Toronto, les actions suivantes au niveau de ce dernier empêchent tout conflit de dénomination et permettent d'éviter que JONES de Montréal ne dispose des droits accordés à JONES sur le système Toronto.
Ces opérations peuvent également être effectuées sur le système Montréal de sorte que JONES de Toronto n'utilise pas les droits accordés à JONES de Montréal, lors de l'accès au système Montréal.
Pour plus de détails sur les commandes AVS qui prennent en charge la conversion d'ID utilisateur, reportez-vous au manuel VM/ESA Connectivity Planning, Administration and Operation.
LU 6.2 offre trois fonctions principales de sécurité réseau :
Reportez-vous à la section Sécurité réseau, pour savoir comment spécifier la sécurité au niveau des sessions pour DB2 pour VM. La sécurité au niveau des sessions avec le serveur d'applications DB2 pour VM fonctionne sur le même principe qu'avec le demandeur d'application DB2 pour VM.
Le demandeur d'application envoie un ID utilisateur qui a déjà été vérifié (SECURITY=SAME) ou un ID utilisateur et un mot de passe (SECURITY=PGM). Si un utilisateur et un mot de passe sont envoyés, ils sont validés sur l'hôte du serveur d'applications par CP, RACF ou un programme équivalent avec le répertoire VM. Si la validation n'aboutit pas, la demande de connexion est rejetée, sinon elle est acceptée. Si la demande contient uniquement un ID utilisateur, DB2 pour VM l'accepte sans valider cet ID.
Remarque : | DB2 pour VM n'offre pas de fonction de cryptage car VM/ESA ne prend pas en charge le cryptage. |
Le serveur d'applications DB2 pour VM vérifie si l'ID utilisateur fourni par VM dispose des droits CONNECT pour accéder à la base de données, puis rejette la connexion si l'ID utilisateur ne dispose pas de ces droits.
En tant que propriétaire des ressources de base de données, le serveur d'applications DB2 pour VM contrôle les fonctions de sécurité de base de données pour les objets SQL résidant sur le serveur d'applications DB2 pour VM. L'accès aux objets gérés par DB2 pour VM est contrôlé via un ensemble de privilèges qui sont accordés aux utilisateurs par l'administrateur système DB2 pour VM ou le propriétaire de l'objet particulier. Le serveur d'applications DB2 for VM contrôle deux classes d'objets :
Lorsqu'une application est précompilée sur DB2 pour VM, le module contient les instructions SQL contenues dans le programme d'application. Ces instructions sont classées comme suit :
Lorsqu'un utilisateur final dispose des droits d'exécution d'un module, il dispose automatiquement des droits lui permettant d'exécuter chaque instruction SQL statique contenue dans le module. Les utilisateurs finals n'ont donc pas besoin d'utiliser les privilèges d'accès aux tables DB2 pour VM si le module contient uniquement des instructions SQL statiques.
L'utilisation de ce sous-système par le serveur d'applications DB2 pour VM est facultative. Si le serveur d'applications doit identifier le nom de LU du demandeur d'application, VTAM appelle le sous-système de sécurité pour effectuer l'échange de vérification de LU partenaire. La décision d'effectuer une vérification de LU partenaire dépend de la valeur indiquée au paramètre VERIFY de l'instruction APPL VTAM pour la passerelle qui est utilisée par le serveur d'applications DB2 pour VM pour recevoir les demandes entrantes portant sur les bases de données réparties.
Le sous-système de sécurité peut également être appelé par CP pour valider l'ID utilisateur et le mot de passe envoyés par le demandeur d'application. Si RACF est utilisé comme sous-système de sécurité et que vous ne disposez pas d'un profil système RACF, la validation est effectuée par RACF. Si vous disposez d'un profil système RACF, par exemple RACFPROF, utilisez les instructions suivantes pour demander cette validation à RACF :
RALTER VMXEVENT RACFPROF DELMEM (APPCPWVL/NOCTL RALTER VMXEVENT RACFPROF ADDMEM (APPCPWVL/CTL SETEVENT REFRESH RACFPROF
Vous devez affecter à CHARNAME et au CCSID une valeur par défaut appropriée pour votre installation. L'utilisation de valeurs correctes vous permet d'assurer l'intégrité de la représentation des données alphanumériques et de réduire le temps système associé à la conversion de CCSID.
Par exemple, si votre serveur d'applications DB2 pour VM est accessible aux utilisateurs locaux dont les contrôleurs de terminal sont générés avec la page de codes 37 et le jeu de caractères 697 (CP/CS 37/697) pour l'anglais (Etats-Unis), le serveur d'applications doit affecter par défaut à CHARNAME la valeur ENGLISH. En effet, CP/CS 37/697 correspond au CCSID 37, qui lui-même correspond à la valeur ENGLISH pour CHARNAME.
Pour éviter des conversions de CCSID inutiles, faites en sorte que la valeur par défaut du serveur d'applications soit identique à la valeur par défaut des demandeurs d'application qui ont le plus souvent accès à votre serveur d'applications.
Vous trouverez ci-après un cas où ces deux objectifs peuvent être contradictoires.
Si la valeur par défaut de CHARNAME pour le serveur d'applications est ENGLISH, l'intégrité des données est assurée pour les demandeurs d'application locaux mais elle génère du temps système supplémentaire pour la conversion du CCSID de tous les demandeurs d'application éloignés.
Lorsque la valeur par défaut de CHARNAME est UK-ENGLISH, aucun temps système supplémentaire n'est généré pour la conversion du CCSID de tous les demandeurs d'application éloignés, mais l'intégrité des données n'est pas assurée pour les demandeurs d'application locaux. Par exemple, le symbole de la livre sterling est remplacé par celui du dollar.
Pour afficher le CCSID en cours du système, interrogez la table SYSTEM.SYSOPTIONS. Le CCSID par défaut du serveur d'applications prend généralement la valeur CCSIDMIXED. Si cette valeur est égale à zéro, le CCSID par défaut du système prend la valeur CCSIDSBCS. Les valeurs de CHARNAME, CCSIDSBCS, CCSIDMIXED et CCSIDGRAPHIC de cette table sont remplacées par les valeurs utilisées comme valeurs système par défaut chaque fois que la base de données est démarrée. Les valeurs se trouvant dans cette table ne sont pas toujours les valeurs par défaut du système. Il se peut qu'un utilisateur disposant des droits d'administrateur de bases de données les modifie, bien que ce ne soit pas conseillé. Pour modifier la valeur par défaut du CCSID d'un serveur d'applications, vous devez indiquer le paramètre CHARNAME dans le fichier SQLSTART EXEC lors du prochain démarrage du serveur d'applications. Reportez-vous au manuel VM/ESA System Administration pour de plus amples informations.
Si la base de données a été récemment installée pour le serveur d'applications, la valeur par défaut du paramètre CHARNAME est INTERNATIONAL et le CCSID par défaut est 500. Ces valeurs ne sont probablement pas correctes pour votre système. La valeur par défaut de CHARNAME pour un système migré est ENGLISH, et le CCSID par défaut est 37.
La liste de contrôle ci-après récapitule les étapes nécessaires à l'activation d'un serveur d'applications DRDA pour les communications DRDA, en supposant que votre système VM est installé, que ACF/VTAM est utilisé comme méthode d'accès en télétraitement et que les définitions VTAM requises pour communiquer avec les systèmes éloignés, telles que les définitions NCP, sont complètes.