DB2 - Connectivité - Informations complémentaires

Configuration du serveur d'applications dans un environnement VSE

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 :

Définition des données réseau

Les deux opérations suivantes sont nécessaires à l'établissement d'une connexion réseau avec le serveur d'applications VSE :

  1. Etablissement de sessions CICS de type LU 6.2 avec les systèmes éloignés
  2. Définition du serveur d'applications

Etablissement de sessions CICS de type LU 6.2

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.

Installation de CICS et définition des ressources pour les communications de type LU 6.2 
  1. Installation des modules requis pour ISC.

    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 :

  2. Installez le module Restart Resynchronization Support de CICS

    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.
    
  3. Définissez CICS sur VTAM pour VSE.

    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
    

    AUTH=(ACQ,SPO,VPACE)
    ACQ permet à CICS de disposer de sessions LU 6.2.

    SPO permet à CICS d'émettre une commande MODIFY vtamname USERVAR.

    VPACE permet de réguler le flux de données intersystèmes.

    ESA=30
    Indique le nombre d'unités adressables du réseau pour lesquelles CICS peut établir des sessions. Ce nombre doit inclure le nombre total de sessions parallèles pour ce système CICS.

    PARSESS=YES
    Indique le support de session parallèle LUTYPE6.

    SONSCIP=YES
    Indique le support de notification d'interruption de session (SON). Dans certains cas, ce support permet de récupérer une session défectueuse sans intervention de l'opérateur.

    APPC=NO
    Nécessaire pour permettre à CICS d'utiliser les macro-instructions VTAM. CICS n'émet pas de macro-instructions APPCCMD.
    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.
  4. Définissez des liaisons avec les systèmes éloignés à l'aide du protocole LU 6.2.
    1. Définissez toutes les LU éloignées sur CICS.

      Définissez toutes les LU éloignées en utilisant la commande CEDA DEFINE CONNECTION pour la définition des ressources en ligne (RDO) :

      • Spécifiez le nom de LU éloignée au paramètre NETNAME.
      • Spécifiez PROTOCOL=APPC pour vérifier que les protocoles LU 6.2 sont utilisés.
      • Spécifiez AUTOCONNECT=YES et INSERVICE=YES de sorte que la connexion, une fois installée, soit mise en service automatiquement et que les sessions soient acquises automatiquement.
      • Spécifiez le niveau de sécurité des conversations en utilisant le paramètre ATTACHSEC. ATTACHSEC=IDENTIFY est le niveau minimal de sécurité requis par DRDA.
      • Spécifiez le niveau de sécurité des sessions en utilisant le paramètre BINDPASSWORD. Par défaut, aucune sécurité n'est définie au niveau des sessions.

      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é.

    2. Définissez les groupes de sessions LU 6.2 avec le système éloigné.

      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 le nom de la connexion (définie ci-dessus) dans le paramètre CONNECTION.
      • Spécifiez l'entrée de la table de modes d'ouverture de session VTAM au paramètre MODENAME.
      • Utilisez le paramètre MAXIMUM pour spécifier :
        • Le nombre maximal de sessions
        • Le nombre maximal de sessions à prendre en charge en tant que vainqueurs de conflit

        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.

    3. Définissez les ID utilisateur et les mots de passe pour l'accès à CICS.

      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.

    4. Définissez les modules de chargement (phases) pour CICS à l'aide de la commande CEDA DEFINE PROGRAM :
      1. ARICAXED - Transaction AXE
      2. ARICDIRD - Répertoire DBNAME et routine de recherche
      3. ARICDAXD - Gestionnaire des transactions DAXP et DAXT
      4. ARICDEBD - Gestionnaire d'activation du support CICS TRUE
      5. ARICDRAD - CICS TRUE
      6. ARICDR2 - Bloc de contrôle DR2DFLT
      Pour chacun de ces éléments, l'option LANGUAGE=ASSEMBLER doit être spécifiée.
    5. Pour chaque TPN spécifié par le demandeur d'application, définissez une transaction AXE à l'aide de la commande CEDA DEFINE TRANSACTION :
      • Utilisez le paramètre TRANSACTION pour spécifier le TPN ;
      • Spécifiez PROGRAM=ARICAXED pour indiquer la phase ;
      • Utilisez le paramètre XTRANID pour spécifier un deuxième nom de transaction hexadécimal.
      Définissez également les transactions DAXP et DAXT, en spécifiant PROGRAM=ARICDAXD.

Exemples de définitions 

Reportez-vous au manuel DRDA Connectivity Guide pour consulter les exemples de définitions.

Définition du serveur d'applications

  1. Mettez à jour le répertoire DBNAME de DB2 pour VSE.

    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 :

  2. Utilisez la procédure ARISBDID pour créer et assembler le répertoire DBNAME (membre ARISDIRD.A).

Pour plus de détails, reportez-vous au manuel DB2 for VSE System Administration.

Préparation et démarrage du serveur d'applications DB2 pour VSE

  1. La transaction AXE conserve un journal des erreurs qui est dans une file d'attente de stockage temporaire CICS appelé ARIAXELG. Le journal des erreurs contient des messages d'erreur utiles dans lesquels sont consignés les incidents de communication et les fins anormales de sessions DRDA. Définissez ce journal comme "récupérable" à l'aide de TST CICS.
  2. Exécutez la procédure ARIS342D pour installer le support serveur d'applications DRDA.
  3. Si nécessaire, exécutez la transaction DAXP pour spécifier le mot de passe et la langue par défaut qui seront utilisées lorsque le support TRUE de CICS sera activé pour un serveur donné. Reportez-vous au manuel DB2 for VSE Operation pour plus de détails.
  4. Démarrez DB2 pour VSE en utilisant les paramètres DBNAME, RMTUSERS et SYNCPNT :
  5. Tous les utilisateurs éloignés doivent disposer de droits accordés par DB2 pour VSE, avec des niveaux différents. Reportez-vous au manuel DB2 for VSE Database Administration pour plus de détails.
Identification des incidents:
  • Si le demandeur d'application réussit à trouver sa session CICS partenaire avec un nom de programme transactionnel correct (ce nom est défini dans le répertoire DBNAME), une transaction AXE est démarrée. Le nombre d'utilisations du programme ARICAXED est augmenté d'une unité (la vérification peut être effectuée à l'aide de la commande CEMT I PR(ARICAXED) ).
  • Pour vérifier qu'un ID utilisateur éloigné est établi dans la table d'ouverture de session CICS, effectuez une connexion locale à l'aide de la transaction CESN avec l'ID et le mot de passe de l'utilisateur éloigné. La connexion effectuée en local doit aboutir.
  • Lorsque le serveur DB2 pour VSE est actif et qu'une application effectue une activité d'unité d'oeuvre répartie DRDA-2 pour la première fois, le support TRUE sur un serveur s'active automatiquement. Consultez le message ARI0187I, qui indique que le support TRUE a été activé. Toutefois, si le message ARI0190E s'affiche, indiquant qu'une erreur s'est produite lors de l'activation de TRUE, consultez les éventuels messages d'erreur précédents sur la console.
  • Si votre programme d'application DRDA reçoit le code de détection X'08063426' ou X'FFFE0101', cela peut indiquer que CICS ne dispose pas de suffisamment de sessions. CICS peut manquer de sessions si toutes les sessions sont utilisées ou sont en attente de déconnexion, mais la déconnexion n'a pas abouti. CICS peut manquer de sessions s'il existe beaucoup de transactions entrantes simultanées de courte durée. Dans ce cas, augmentez le nombre de sessions spécifiées au paramètre CEDA DEFINE SESSIONS MAXIMUM pour prendre en compte les sessions dont la déconnexion est programmée, mais non encore effectuée.

Définition de la sécurité

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é :

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

+--------------------------------------------------------------------------------+
|  :nick.VSE1     :tpn.TOR3                                                      |
|                 :luname.TORGATE VSEGATE                                        |
|                 :modename.IBMRDB                                               |
|                 :security.PGM                                                  |
|                 :userid.SALESMGR                                               |
|                 :password.PROFIT                                               |
|                 :dbname.TORONTO3                                               |
|                                                                                |
|                                                                                |
|                                                                                |
|  Où :   TOR3    - ID transaction mappé dans la base de données TORONTO3.       |
|         TORGATE - Passerelle VM/APPC.                                          |
|         VSEGATE - ID application de la partition CICS/VSE utilisée             |
|                   comme passerelle de TORONTO3.                                |
|         SALESMGR/PROFIT - USERID/PASSWORD défini dans le DFHSNT de             |
|                           VSEGATE, et admis pour TORONTO3                      |
|         TORONTO3 - Nom spécifié au paramètre de démarrage DBNAME lorsque le    |
|                    serveur d'applications DB2 pour VSE a été démarré (ou que   |
|                    le nom de la base de données par défaut a été déterminé par |
|                    répertoire DBNAME si DBNAME a été ignoré lors du démarrage).|
+--------------------------------------------------------------------------------+

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

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 :

Représentation des données

Reportez-vous à la section Représentation des données.

Liste de contrôle d'activation du serveur d'applications DRDA DB2 pour VSE

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.

  1. Installez le support ISC et le module Restart Resynchronization Support de CICS.
  2. Définissez CICS sur VTAM pour VSE.
  3. Assemblez la table VTAM LOGMODE comportant l'entrée IBMRDB.
  4. Assemblez la table d'ouverture de session comportant tous les ID utilisateur éloignés et mots de passes définis.
  5. Démarrez CICS en indiquant les informations SIT appropriées :
  6. Définissez les systèmes éloignés pour CICS (RDO peut être utilisé) :
  7. Mettez à jour le répertoire DBNAME (ARISDIRD.A) :
  8. Exécutez la procédure ARISBDID pour assembler le répertoire DBNAME mis à jour.
  9. Préparez le serveur DB2 pour VSE :
  10. Si nécessaire, exécutez la transaction CICS DAXP.
  11. Démarrez DB2 pour VSE en utilisant le paramètre RMTUSERS approprié et, éventuellement, les paramètres DBNAME et SYNCPNT.
  12. Préparez les applications sur le serveur d'applications DRDA VSE.


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