DB2 - Connectivité - Informations complémentaires

Mise en oeuvre de DB2 pour VM

Comme illustré à la Figure 29, une application VM doit s'exécuter via un demandeur d'application DB2 pour VM (adaptateur de ressources) pour accéder à toute base de données du serveur d'applications DB2 pour VM ou DRDA. Une base de données du serveur d'applications DB2 pour VM peut recevoir des requêtes SQL provenant de n'importe quel demandeur d'application DB2 pour VM ou DRDA.

Figure 29. Demandeur d'application et serveur d'applications pour DB2 pour VM

                                                                          
                                                                         
 

REQTEXT

Options de précompilation ou d'exécution d'une application

DB2 pour VM prend en charge trois options de traitement de la commande sqlinit qui permettent à l'utilisateur et à l'administrateur de base de données d'activer le support de bases de données réparties. L'utilisateur peut indiquer l'une des options SQLINIT suivantes avant la précompilation ou l'exécution de l'application :

PROTOCOL(SQLDS)
Nécessite l'utilisation du protocole SQLDS privé. Il s'agit de l'option par défaut. Elle peut être utilisée entre un demandeur d'application DB2 pour VM application et un serveur, dans un environnement local ou éloigné. Le serveur d'applications DB2 pour VM suppose que le demandeur utilise les mêmes CCSID (ID de jeu de caractères codés) que le serveur. Les valeurs par défaut des CCSID 5 définies par le demandeur via SQLINIT ne sont pas prises en charge et aucun identificateur d'unité logique de travail (LUWID) LU 6.2 n'est associé à la conversation. Si vous utilisez uniquement les systèmes DB2 pour VM, et le même CCSID par défaut partout, il s'agit de l'option la plus efficace.

PROTOCOL(AUTO)
Demande au demandeur d'application DB2 pour VM d'identifier si le serveur d'applications appartient à un système équivalent ou à un système de type différent. Il choisit alors automatiquement un protocole SQLDS privé pour un système du même type ou un protocole DRDA pour un système de type différent. Il peut être utilisé entre des systèmes de même type (locaux ou éloignés) et des systèmes de type différent. Si le serveur d'applications n'a pas été défini avec le paramètre PROTOCOL=SQLDS, le demandeur d'application et le serveur peuvent avoir des valeurs par défaut de CCSID différentes. Les requêtes et les réponses sont converties en conséquence. L'option AUTO est recommandée dans les cas suivants :

PROTOCOL(DRDA)
Oblige le demandeur d'application DB2 pour VM à utiliser uniquement le protocole DRDA pour communiquer avec le serveur d'applications. Vous pouvez utiliser cette option entre des systèmes de même type (locaux ou éloignés) et des systèmes de type différent. Si le serveur d'applications est un système du même type, le protocole DRDA est utilisé entre les deux systèmes DB2 pour VM. Le demandeur d'application et le serveur d'applications peuvent avoir des CCSID par défaut différents. Les requêtes et les réponses sont converties en conséquence. Vous pouvez utiliser cette option pour la communication entre deux systèmes DB2 pour VM afin de tester des applications spécifiques où l'utilisation du protocole DRDA peut fournir un meilleur rendement en raison de l'utilisation d'une taille de tampon plus grande pour l'envoi et la réception de données.

Le Tableau 3 compare les caractéristiques fonctionnelles des options de traitement SQLINIT du demandeur d'application DB2 for VM.

Tableau 3. Comparaison des options de traitement SQLINIT du demandeur d'application DB2 pour VM
[SQLDS] [ AUTO ] [DRDA]
Les deux partenaires doivent être des systèmes DB2 pour VM. Connexion à tout système DRDA Connexion à tout système DRDA
Possibilité de communiquer avec un partenaire en local via TSAF ou AVS/VTAM Possibilité de communiquer avec un système DB2 pour VM en local ou avec un système DB2 pour VM éloigné via TSAF ou AVS. Dans le cas d'un système d'un autre type, la communication doit s'effectuer via AVS. Possibilité de communiquer avec un système DB2 pour VM en local ou avec un système DB2 pour VM éloigné via TSAF ou AVS. Dans le cas d'un système d'un autre type, la communication doit s'effectuer via AVS.
Prise en charge de SQL statique, dynamique et dynamique étendu Prise en charge de SQL statique, dynamique et dynamique étendu Prise en charge de SQL statique, dynamique et dynamique étendu 6
Les CCSID définis par SQLINIT pour le demandeur d'application sont ignorés par le serveur d'applications DB2 pour VM. Les CCSID définis par SQLINIT pour le demandeur d'application sont reconnus par le serveur d'applications DB2 pour VM et sont convertis correctement. Les CCSID définis par SQLINIT pour le demandeur d'application sont reconnus par le serveur d'applications DB2 pour VM et sont convertis correctement.
Taille de bloc fixe de 8 ko ; l'appel OPEN ne renvoie aucune ligne ; le demandeur d'application doit émettre explicitement une demande de fermeture de curseur. DB2 pour VM à DB2 pour VM : méthode SQLDS ; autres types de connexion : méthode DRDA Taille de bloc variable de 1 ko à 32 ko ; groupage plus compact des données ; l'appel OPEN renvoie un bloc de lignes ; le serveur d'applications peut fermer implicitement le curseur, évitant au demandeur d'application d'envoyer un appel CLOSE.
Possibilité d'utilisation du curseur INSERT et des PUT pour insérer un bloc de lignes à la fois en utilisant la taille de bloc de 8 ko DB2 pour VM à DB2 pour VM : méthode SQLDS ; autres types de connexion : méthode DRDA Les PUT sont transformés en insertions de lignes normales et sont envoyés à raison d'une ligne à la fois.
Toutes les commandes uniques de DB2 pour VM sont prises en charge. DB2 pour VM à DB2 pour VM : méthode SQLDS ; autres types de connexion : méthode DRDA Les commandes opérateur DB2 pour VM, certaines instructions DB2 pour VM et certaines commandes ISQL et DBSU ne sont pas prises en charge (Voir le manuel DB2 for VSE and VM SQL Reference).
LUWID n'est pas pris en charge. LUWID est pris en charge. LUWID est pris en charge.

Options de démarrage du serveur de bases de données

Cette section décrit différentes options permettant de démarrer le serveur de bases de données.

Paramètre PROTOCOL

L'administrateur de la base de données peut indiquer l'une des options suivantes avec le paramètre PROTOCOL lors du démarrage du serveur.

SQLDS
Option par défaut, recommandée si le serveur d'applications ne doit offrir un support que pour les demandeurs d'application DB2 pour VM ou pour la demande d'application DB2 pour VSE bénéficiant du partage d'invité VSE. Le serveur d'applications utilise uniquement le flux privé (SQLDS).

Le serveur d'applications est dépendant de l'option de traitement sélectionnée par le demandeur d'application. Si le paramètre PROTOCOL(SQLDS) est indiqué pour un demandeur DB2 pour VM, le traitement effectué sur le serveur DB2 pour VM se poursuit normalement avec les flux privés. Si le paramètre PROTOCOL(AUTO) est indiqué pour un demandeur DB2 pour VM, le serveur DB2 pour VM indique au demandeur d'utiliser un flux privé. Aucune information de CCSID n'est échangée entre le demandeur d'application et le serveur d'applications. Ce dernier suppose que les CCSID du demandeur d'application sont identiques aux siens. Si le paramètre PROTOCOL(DRDA) est indiqué pour un demandeur DB2 pour VM, la conversation prend fin. Si un demandeur d'application autre que DB2 pour VSE et VM tente d'accéder au serveur DB2 pour VM, la conversation prend fin.

AUTO
Option recommandée si le serveur d'applications doit fournir un support pour le protocole privé et le protocole DRDA. Lorsque les paramètres PROTOCOL(SQLDS) ou PROTOCOL(AUTO) sont indiqués pour les demandeurs d'application, ces derniers communiquent dans un flux privé. Dans le cas d'un demandeur d'application pour lequel l'option SQLDS est indiquée, aucune information de CCSID n'est échangée et le serveur d'applications suppose que les CCSID du demandeur d'application sont identiques aux siens. Lorsque l'option AUTO est indiquée pour un demandeur, les informations relatives au CCSID sont échangées et la conversion de CCSID pour les requêtes et les réponses est effectuée de manière appropriée. Le flux DRDA est requis par des demandeurs autres que DB2 pour VM, ou par n'importe quel demandeur DB2 pour VM spécifiant PROTOCOL(DRDA).

Paramètre SYNCPNT

Ce paramètre indique si un gestionnaire de points de synchronisation (SPM) va être utilisé pour coordonner l'activité de lecture et d'écriture multisite de l'unité d'oeuvre répartie DRDA-2.

Si Y est spécifié, le serveur utilise si possible un gestionnaire de points de synchronisation pour coordonner les activités de resynchronisation et de validation en deux phases. Si N est spécifié, le serveur d'applications n'utilise pas de SPM pour exécuter les validations en deux phases et il est limité aux unités d'oeuvre réparties à lecture multisite et à écriture monosite ; il peut constituer ce site unique. Si Y est spécifié, mais que le serveur d'applications ne trouve aucun gestionnaire de points de synchronisation disponible, le serveur fonctionne comme si N avait été indiqué.

La valeur par défaut est SYNCPNT=Y lorsque PROTOCOL=AUTO. Lorsque PROTOCOL=SQLDS, la valeur du paramètre SYNCPNT est N.


Notes de bas de page :

5
Dans DB2 pour VM, le demandeur d'application et le serveur d'applications spécifient les valeurs par défaut des CCSID en indiquant une option CHARNAME, pour SQLINIT et SQLSTART respectivement. Le nom CHARNAME est un nom symbolique qui est mis en correspondance en interne avec les CCSID appropriés.

6
Le langage SQL dynamique étendu est pris en charge avec les flux DRDA qui les convertit en instructions statiques ou dynamiques. Toutefois, il existe certaines restrictions.


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