Le support du serveur d'applications DB2 pour VSE permet à DB2 pour VSE de jouer le rôle de serveur pour les demandeurs d'application DRDA. Les demandeurs d'application susceptibles d'être connectés à un serveur d'applications DB2 pour VSE sont les suivants :
Les deux opérations suivantes sont nécessaires à l'établissement d'une connexion réseau avec le serveur d'applications VSE :
Le serveur d'applications DB2 pour VSE utilise des liaisons CICS de type LU 6.2 pour communiquer avec le demandeur d'application. La partition CICS utilisée doit donc disposer de liaisons LU 6.2 avec les systèmes éloignés sur lesquels s'exécutent les demandeurs d'application. Le manuel CICS/VSE Intercommunications Guide contient des informations détaillées sur la manière de définir et d'établir des liaisons CICS de type LU 6.2 avec des systèmes éloignés.
Vous devez inclure les modules suivants dans votre système à l'aide d'une table d'initialisation du système (SIT) ou des paramètres de substitution pour l'initialisation :
Si ce module CICS n'a pas été activé lors de l'installation du système CICS, vous devez mettre à jour les tables CICS suivantes pour activer la fonction de resynchronisation de redémarrage de CICS :
DFHJCT Journal Control Table A journal used for the CICS system log must be defined in the DFHJCT specifying JFILEID=SYSTEM in a DFHJCT TYPE=ENTRY macro. DFHPCT Program Control Table To generate the DFHPCT entry to use the CICS Restart Resynchronization capability, enter: DFHPCT TYPE=GROUP,FN=RMI DFHPPT Processing Program Table To generate the DFHPPT entry to use the CICS Restart Resynchronization capability, enter: DFHPPT TYPE=GROUP,FN=RMI DFHSIT System Initialization Table. The DFHSIT macro must include the JCT parameter. Specify JCT=YES or JCT=(jj<,....>) where jj is the SUFFIX parameter value specified in th DFHJCT TYPE=INITIAL macro defining the CICS system log journal data set.
Pour prendre en charge les connexions LU 6.2, CICS doit être défini sur VTAM pour VSE en tant que noeud principal d'applications. Le nom de noeud principal d'applications qui est codé dans l'instruction APPL VTAM est l'ID APPL de la partition CICS indiquée dans la table SIT par le paramètre APPLID. Il s'agit du nom de LU utilisé par VTAM (et par conséquent, par les partenaires de communication CICS) pour identifier le système CICS.
Reportez-vous à la Figure 36.
Figure 36. Exemple de définition APPL VTAM pour CICS
VBUILD TYPE=APPL ************************************************************************ * * * LU Definition for Toronto VSE SQL/DS System * * * ************************************************************************ VSEGATE APPL ACBNAME=VSEGATE, AUTH=(ACQ,SPO,VPACE), APPC=NO, SONSCIP=YES, ESA=30 MODTAB=RDBMODES, PARSESS=YES, VPACING=0 |
SPO permet à CICS d'émettre une commande MODIFY vtamname USERVAR.
VPACE permet de réguler le flux de données intersystèmes.
Remarque : | SYNCLVL=SYNCPT n'est pas requis car APPC=NO est spécifié. CICS gère toutes les activités au niveau du point de synchronisation pour les unités d'oeuvre réparties. |
Définissez toutes les LU éloignées en utilisant la commande CEDA DEFINE CONNECTION pour la définition des ressources en ligne (RDO) :
Pour plus de détails sur la sécurité au niveau des conversations et des sessions, reportez-vous à la section Définition de la sécurité.
Pour chaque connexion définie précédemment, définissez des groupes de sessions parallèles pour chaque liaison à la LU éloignée, en utilisant la commande CEDA DEFINE SESSIONS :
Spécifiez les valeurs utilisées par le logiciel de communications du demandeur d'application DRDA, par exemple, IBM Communications Server pour OS/2.
Sachez que le fait de définir des valeurs supérieures pour SENDSize et RECEIVESize peut améliorer la vitesse de transmission des données, mais rendra nécessaire une plus grande quantité de mémoire virtuelle sur le réseau. La taille prise en charge par toutes les couches du réseau SNA est égale à 4 ko. Lors de la configuration du serveur DRDA, vous devez donc attribuer à la taille des tampons d'émission et de réception la valeur de 4 ko. Lorsque des connexions peuvent être établies à partir d'utilisateurs éloignés, définissez ces paramètres pour déterminer la valeur optimale.
Définissez tous les utilisateurs de la table d'ouverture de session CICS (DFHSNT). Vous pouvez vérifier la validité d'un ID utilisateur en effectuant une connexion CESN à un terminal CICS. La connexion effectuée en local doit aboutir.
Reportez-vous au manuel DRDA Connectivity Guide pour consulter les exemples de définitions.
Ajoutez une entrée au répertoire DBNAME pour chaque transaction définie précédemment, en utilisant la commande CEDA DEFINE TRANSACTION. Lorsque des sessions LU 6.2 sont établies, un demandeur d'application éloigné peut démarrer une conversation avec un serveur d'applications DB2 pour VSE. Pour ce faire, il alloue une conversation de type LU 6.2 au serveur d'applications, en indiquant un nom de programme transactionnel (TPN). Ce nom doit être un ID transaction CICS de la transaction AXE chargée d'acheminer les demandes en provenance ou en direction du serveur DB2 pour VSE. Le nom de programme transactionnel doit se trouver dans le répertoire DBNAME de DB2 pour VSE mappé avec le serveur DB2 pour VSE pour être accessible à partir du demandeur d'application. L'administrateur de bases de données DB2 pour VSE se charge de mettre à jour le répertoire DBNAME et d'informer les utilisateurs éloignés du mappage du nom de programme transactionnel avec le serveur.
Le nom de programme transactionnel et le nom de serveur qui lui est associé (nom de la base de données tel qu'il est défini dans le répertoire DBNAME) doivent être identifiés au niveau du demandeur d'application :
Pour plus de détails, reportez-vous au manuel DB2 for VSE System Administration.
Identification des incidents: |
|
Le serveur d'applications DB2 pour VSE dépend de CICS pour la sécurité des communications intersystèmes. CICS offre différents systèmes de sécurité :
Mise en oeuvre CICS de la vérification LU-LU du niveau de session LU 6.2 SNA. La mise en oeuvre de la sécurité au moment de la définition d'accès est facultative dans l'architecture LU 6.2. En ce qui concerne le serveur d'applications, elle peut être activée en indiquant un BINDPASSWORD dans la commande CEDA DEFINE CONNECTION lors de la définition de la connexion avec le demandeur d'application. Sur le demandeur d'application, la LU partenaire qui sert le demandeur d'application doit également prendre en charge la sécurité au moment de la définition d'accès et utilise le même mot de passe pour la vérification de la LU partenaire.
Vous pouvez utiliser ce type de sécurité pour empêcher aux systèmes éloignés ne disposant pas des droits requis, d'établir des sessions avec CICS.
La sécurité de la liaison peut être utilisée pour restreindre les connexions d'un système éloigné (et de son demandeur d'application DRDA résident) à un ensemble de transactions AXE donné.
Par exemple, vous pouvez définir deux transactions AXE : AXE2 avec la clé de sécurité 2 et AXE3 avec la clé de sécurité 3. Une sécurité opérateur de 3 peut être attribuée aux demandeurs d'application d'un système éloigné (par exemple, à l'aide du paramètre OPERSECURITY dans la commande CEDA DEFINE SESSION), ce qui leur permet de se connecter uniquement à AXE3. Cette transaction risque de ne pas disposer d'accès privilégiés au serveur lorsque AXE2 dispose de ces privilèges. Reportez-vous au manuel DB2 for VSE System Administration pour consulter une description de l'accès privilégié au serveur d'applications par des demandeurs d'application éloignés.
Reportez-vous au manuel CICS Intercommunication Guide pour connaître la manière d'activer la sécurité de la liaison.
Mise en oeuvre CICS de la sécurité au niveau des conversations LU 6.2 SNA permettant la vérification de l'utilisateur final.
La sécurité utilisateur valide l'ID utilisateur avec la table d'ouverture de session CICS (DFHSNT) avant d'accepter une demande de démarrage d'une conversation. Par exemple, les demandeurs d'application DRDA non définis dans la table d'ouverture de session CICS ne sont pas admis à se connecter à une transaction AXE pour démarrer une conversation avec le serveur DB2 pour VSE. Le niveau de sécurité utilisateur d'un système éloigné peut être sélectionné dans la commande CEDA DEFINE CONNECTION au moyen du paramètre ATTACHSEC. Les trois niveaux de sécurité de connexion sont les suivants :
Dans la mesure où le serveur d'applications est responsable de la gestion des ressources de bases de données, il détermine les fonctions de sécurité réseau que le demandeur d'application doit fournir. Par exemple, avec un demandeur d'application DB2 pour VM, vous devez enregistrer les besoins en matière de sécurité au niveau des conversations du serveur d'applications dans le répertoire de communications du demandeur d'application en spécifiant la valeur appropriée dans la marque :security (voir la Figure 37).
Figure 37. Exemple d'entrée de répertoire de communications CMS
La conversion d'ID utilisateur n'est pas prise en charge par le serveur d'applications VSE. CICS utilise l'ID utilisateur transmis directement à partir du demandeur.
Après avoir été démarrée par le demandeur d'application, la transaction AXE extrait l'ID utilisateur de CICS et le transfère au serveur DB2 pour VSE. Pour définir le niveau de droit utilisateur requis sur les ressources de bases de données, vous devez mettre à jour l'ID utilisateur dans le catalogue DB2 pour VSE SYSTEM.SYSUSERAUTH.
Le serveur d'applications DB2 pour VSE vérifie si l'ID utilisateur fourni par CICS dispose des droits CONNECT pour accéder à la base de données, et refuse la connexion si ce n'est pas le cas.
En tant que propriétaire des ressources de base de données, le serveur d'applications DB2 pour VSE 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 VSE. L'accès aux objets gérés par DB2 pour VSE est contrôlé via un ensemble de privilèges qui sont accordés aux utilisateurs par l'administrateur système DB2 pour VSE ou le propriétaire de l'objet donné. Le serveur d'applications DB2 pour VSE contrôle deux classes d'objets :
Lorsqu'une application est précompilée sur DB2 pour VSE, le module comporte 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 VSE si le module contient uniquement des instructions SQL statiques.
Reportez-vous à la section Représentation des données.
La liste de contrôle ci-après récapitule les étapes nécessaires à l'activation d'un serveur d'applications DRDA, en supposant que votre système VSE 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.
Toutes les définitions relatives à ces instructions doivent figurer sous un groupe appelé IBMG, par exemple. Installez ce groupe à l'aide de CEDA INSTALL GROUP(IBMG).