Packages SQL statiques

Le service DRDA prend en charge l’exécution d’instructions SQL dynamiques et statiques. Le serveur DRDA traite les instructions SQL dynamiques, par exemple les commandes DRDA EXCSQLIMM (Execute Immediate SQL Statement) et EXCSQLSTT (Execute SQL Statement), en convertissant un ensemble de base de syntaxe ANSI SQL 92 Entry-Level DB2 en syntaxe T-SQL Microsoft SQL Server. Le service DRDA traite les instructions SQL statiques en deux étapes : (1) la liaison et (2) l'exécution.

Lors de la liaison, le service DRDA traite BGNBND (Begin Binding a Package to an RDB) et BNDSQLSTT (Bind SQL Statement to an RDB Package) dans une procédure stockée T-SQL de SQL Server. Si vous le souhaitez, le service DRDA peut traiter des liaisons dans des fichiers XML SQL statiques Microsoft pour DB2 ou traiter des liaisons en appelant un écouteur de liaison remplaçable personnalisé (par exemple, un classeur de package personnalisé ou tiers qui peut prendre en charge un ensemble plus large de conversions de syntaxe SQL). Pour plus d’informations sur le format XML du package pris en charge par le client Microsoft DRDA et le service DRDA, consultez la rubrique intitulée Static SQL for DB2.

Au moment de l’exécution, le service DRDA traite les commandes PRPSQLSTT (Prepare SQL Statement), EXCSQLSTT (Execute SQL Statement) et OPNQRY (Open Query) dans des instructions T-SQL CALL. Pour prendre en charge les opérations de curseur du serveur, le service DRDA traite OPNQRY en une commande de curseur ouvert, CNTQRY (Continuer la requête) dans une commande fetch et CLSQRY (Fermer la requête) dans une commande de curseur de fermeture. Le service DRDA traitera les commandes de validation, de restauration et de synchronisation des commandes de journal dans le cadre de sa prise en charge de DRDA DUW (Unité de Travail Distribuée).

Convention de nommage des paquets

DRDA définit un package SQL statique complet à l’aide d’un PKGNAM (nom du package RDB) qui se compose de ces plusieurs parties.

• RDBNAM (nom de la base de données relationnelle)

• RDBCOLID (identificateur de collection RDB)

• PKGID (identificateur de package RDB)

RDBNAME.RDBCOLID.PKGID.PKGCNSTKN.PKGSN  

L’exemple précédent montre le nom de paquet complètement qualifié avec un jeton de cohérence.

• PKGCNSTKN (jeton de cohérence du package RDB)

• VRSNAM (nom de version)

Conversion de paquets en procédures stockées

Le service DRDA convertit des packages SQL statiques pour DB2 et des instructions SQL incorporées en procédures stockées SQL Server, en traitant les flux de protocole DRDA BGNBND (Begin Bind) et BNDSQLSTT (Bind SQL Statement) et les valeurs de données mises en forme. Si vous le souhaitez, le service DRDA peut traiter des liaisons en tant que fichiers XML, pour une conversion ultérieure en procédures stockées ou à des fins de résolution des problèmes. En outre, le service DRDA peut appeler un composant d’écouteur de liaison personnalisé pour traiter les flux BGNBND et BNDSQLSTT. Pour plus d’informations sur le traitement des flux de liaison de package, consultez le carnet d’opérations. Consultez le Guide du programmeur et la référence du programmeur pour plus d’informations sur les écouteurs de liaison personnalisés.

Dans l’illustration précédente, le SQL intégré de DB2 pour z/OS est transformé en paquets DB2 lors de la phase de précompilation de DB2, puis en flux DRDA BGNBND et BNDSQLSTT lors de la phase de copie de liaison DB2, et enfin en procédures stockées SQL Server par le service DRDA lors du traitement des paquets de liaison et flux d’instructions DRDA.

Déclarations de paquet SQL statiques

Le produit IBM DB2 pour z/OS et la documentation incluent un ensemble d’exemples de programmes de test de vérification d’installation, y compris un COBOL pour z/OS

EXEC SQL CONNECT TO :TEMPLOC END-EXEC  
EXEC SQL INSERT INTO VHDEPT   
VALUES (:DEPT-NUMB, :DEPT-NAME, :DEPT-MGR,   
:DEPT-ADMR, :DEPT-LOC)  
END-EXEC.  
  

L’exemple précédent montre l’exemple de programme COBOL IBM DB2 pour z/OS avec des instructions SQL CONNECT et INSERT incorporées.

CONNECT TO :H  
INSERT INTO VHDEPT VALUES (:H, :H, :H, :H, :H )  
  

L'exemple précédent montre un programme COBOL avec instructions SQL intégrées pour IBM DB2 sous z/OS. Les instructions SQL sont extraites et compilées par le pré-compilateur DB2, puis stockées dans un package SQL statique de DB2, avec une section pour chaque instruction.

<Section Number="18" Alias="">  
  <Statement Number="18">INSERT INTO VHDEPT VALUES ( :H , :H , :H , :H , :H ) </Statement>  
  <Parameters>  
    <Parameter Name="DEPT-NUMB" Type="Char" Length="3" Precision="0" Scale="0" CCSID="37" Nullable="False" />  
    <Parameter Name="DEPT-NAME" Type="Char" Length="36" Precision="0" Scale="0" CCSID="37" Nullable="False" />  
    <Parameter Name="DEPT-MGR" Type="Char" Length="6" Precision="0" Scale="0" CCSID="37" Nullable="False" />  
    <Parameter Name="DEPT-ADMR" Type="Char" Length="3" Precision="0" Scale="0" CCSID="37" Nullable="False" />  
    <Parameter Name="DEPT-LOC" Type="Char" Length="16" Precision="0" Scale="0" CCSID="37" Nullable="False" />  
  </Parameters>  
</Section>  

L'exemple précédent montre comment le programme COBOL échantillon IBM DB2 pour z/OS exécute des instructions SQL statiques de package DB2, converties par le service DRDA en une section de fichier XML SQL statique pour DB2. DB2 pour z/OS n’inclut pas l’instruction CONNECT dans le package distant défini par DRDA.

/****** BNDOPT: <Options><BNDCHKEXS>BNDEXSOPT</BNDCHKEXS><BNDCRTCTL>BNDNERALW</BNDCRTCTL><BNDEXPOPT>EXPNON</BNDEXPOPT><DFTRDBCOL>CXE001</DFTRDBCOL><DGRIOPRL>1</DGRIOPRL><PKGATHOPT>PKGATHKP</PKGATHOPT><PKGISOLVL>ISOLVLCS</PKGISOLVL><PKGOWNID>CXE001</PKGOWNID><PKGRPLOPT>PKGRPLALW</PKGRPLOPT><QRYBLKCTL>FIXROWPRC</QRYBLKCTL><RDBRLSOPT>RDBRLSCMM</RDBRLSOPT><STTDATFMT>USADATFMT</STTDATFMT><STTDECDEL>DECDELPRD</STTDECDEL><STTSTRDEL>STRDELAP</STTSTRDEL><STTTIMFMT>USATIMFMT</STTTIMFMT></Options> ******/  
  
CREATE PROCEDURE [DSN8910].[DSN8HC3_18BBB2BA1492DAC8_19] @DEPT_NUMB Char(3), @DEPT_NAME Char(36), @DEPT_MGR Char(6), @DEPT_ADMR Char(3), @DEPT_LOC Char(16)  
AS  
begin  
      INSERT INTO VHDEPT VALUES ( @DEPT_NUMB , @DEPT_NAME , @DEPT_MGR , @DEPT_ADMR , @DEPT_LOC )   
      return @@ROWCOUNT  
end  
GO  
  

L'exemple précédent montre un programme d'exemple COBOL avec SQL statique pour IBM DB2 pour z/OS, dont les instructions de package DB2 sont converties par le Service DRDA en une instruction SQL Server CREATE PROCEDURE.

Options de liaison de package de service DRDA

Le flux DRDA BGNBND (Begin Bind) inclut un ensemble d’options de liaison de package qui peuvent influencer le stockage et l’exécution du package d’exécution. Le service DRDA mappe un nombre limité d’options de liaison aux constructions SQL Server. Le service DRDA conserve les options de liaison dans le fichier XML du package SQL statique pour DB2, en tant que commentaires dans la procédure stockée, et éventuellement en tant que propriétés étendues sur la procédure stockée.

Lier le contrôle de création de package

Le service DRDA prend en charge le DRDA BGNBND BNDCRTCTL (Bind Package Creation Control), qui indique à MsDrdaService d’ignorer les erreurs de liaison. Le point de code BNDCRTCTL prend en charge une énumération de valeurs.

• BNDCHKONL(VÉRIFICATION DE LIAISON UNIQUEMENT)

• BNDNERALW (Lier aucune erreur autorisée)

• BNDERRALW (Erreurs de liaison autorisées)

• BNDNERALW (Aucune erreur d'association autorisée)

  Par défaut, le service DRDA utilise le paramètre BNDNERALW (aucune erreur de liaison autorisée). Le service DRDA retourne un message de réponse BGNBNDRM (BGNBND Reply Message) avec une erreur indiquant le problème, quand l’une des instances suivantes se produit.

• Problème de conversion DRDA-to-XML

• Problème de conversion XML vers DDL

• L’écouteur d'attachement personnalisé retourne DDL sur l’interface de rappel

• Le service DRDA ne peut pas exécuter l’instruction DDL

  Pour demander au service DRDA d’ignorer les erreurs et de continuer à traiter un paquet, le client AR DRDA doit spécifier l’option BNDCRTCTL BNDERRALW (Erreurs de liaison autorisées).

  Lorsque vous utilisez l’outil d’administration DB2 avec DB2 pour z/OS, l’administrateur DB2 peut spécifier l’option SQLERROR « C » (Continuer). Lorsque vous utilisez l'outil de copie de liaison DB2 avec DB2 pour z/OS, le programmeur DB2 peut accéder au panneau DB2 BIND PACKAGE, spécifier MODIFIER LES PARAMÈTRES PAR DÉFAUT ACTUELS=OUI, puis définir le TRAITEMENT DES ERREURS SQL=C.

Remplacer le paquet de liaison

Le service DRDA prend en charge l'option DRDA BGNBND PKGRPLOPT (option de remplacement de package), qui indique au service MsDrdaService de supprimer et de recréer la procédure stockée du package. Le point de code PKGRPLOPT prend en charge une valeur booléenne.

Actuellement, nous ajoutons, mais ne remplaçons pas les packages lors du traitement de l'instruction BGNBND (Begin Bind) BNDSQLSTT (Bind SQL Statement). Cette option indique à DB2 pour z/OS de supprimer et de créer une copie du package.

• PKGRPLALW (Remplacement du paquet autorisé)

• PKGRPLNA (Remplacement du paquet non autorisé)

  Par défaut, le service DRDA est défini par défaut sur PKGRPLALW (Remplacement du package autorisé). Le service DRDA exécute une instruction DROP PROCEDURE avant d’exécuter une instruction CREATE PROCEDURE.

Liste des options de liaison

Voici une liste des options de liaison de package définies dans le fichier XML de package SQL statique pour DB2. Le format de ces éléments, types et valeurs diffère de la version de Host Integration Server à une autre. Dans HIS 2010 (V8.5), la technologie a pris en charge un format de version 8.5 de ces options de liaison. Dans HIS 2013 (V9.0), la technologie prend en charge un format de version 9.0 de ces options de liaison, qui est plus détaillée et descriptive. La technologie HIS 2013 inclut un fichier de schéma XSD à utiliser avec le fichier XML de package SQL pour DB2 statique

Curseurs SQL statiques du service DRDA

Le service DRDA transforme le SQL statique des packages DB2 en procédures stockées pour SQL Server lors du traitement des commandes DRDA, y compris "begin bind" et "bind" des instructions SQL, ainsi que les déclarations SQL DECLARE CURSOR incorporées. Selon le type de curseur, le service DRDA définit la procédure stockée pour inclure des paramètres d’entrée supplémentaires (« INVOKE_TYPE ») pour définir l’action sur le curseur (par exemple, ouvrir, extraire, fermer). Le service DRDA inclut des commentaires dans la procédure stockée SQL Server pour indiquer les options de liaison (par exemple, le protocole de ligne fixe) et le type de curseur (par exemple, global, pour la mise à jour, en lecture seule).

Déclarer et ouvrir un curseur

Le service DRDA ouvre un curseur en appelant une procédure stockée SQL Server avec un type de paramètre d’appel « @_INVOKE_TYPE\_ = 0 », en réponse à un DRDA AR OPNQRY (Open Query) pour gérer les commandes DECLARE CURSOR et OPEN CURSOR d’un programme consommateur, en renvoyant une ligne unique à l'AR DRDA en réponse à la commande DRDA OPNQRY appelée QRYDTA (jeu de données de réponse aux requêtes).

Extraction par rapport à un curseur

Le service DRDA récupère des données via un curseur en appelant une procédure stockée SQL Server avec un argument de type de paramètre «@_INVOKE_TYPE\_ = 1» et un argument de paramètre @_FETCH_ROW_COUNT\_ = n», en réponse à un DRDA AR CNTQRY (Continuer la requête) pour prendre en charge les commandes FETCH d'un programme consommateur, en retournant une seule ligne ou n lignes à l'AR DRDA dans une réponse à la commande DRDA CNTQRY appelée QRYDTA (jeu de données de réponse aux requêtes).

Pour améliorer les performances, le service DRDA retourne plusieurs lignes par extraction si possible, sauf si le package ou le curseur est défini pour une extraction de lignes unique afin de prendre en charge la mise à jour simultanée. Consultez la description de la syntaxe de clause SQL et les options de liaison ci-dessous.

Fermer un curseur

Le service DRDA ferme un curseur en appelant une procédure stockée de SQL Server avec un argument de paramètre de type d'invocation « @_INVOKE_TYPE\_ = 2 », en réponse à une commande CLSQRY (Close Query) de DRDA AR pour prendre en charge la commande CLOSE CURSOR d’un programme consommateur, et retourne à l'AR DRDA une réponse à la commande DRDA CLSQRY appelée ENDQRYRM (End of Query Reply Message).

Si les instructions DECLARE CURSOR incluent une clause SQL WITH HOLD, le service DRDA définit la procédure stockée avec une option DECLARE CURSOR GLOBAL. Dans ce cas, SQL Server conserve le curseur sur les demandes de fermeture et de validation pendant la durée de la connexion de DRDA AR à DRDA Service à SQL Server.

Syntaxe de clause SQL

Le service DRDA inclut un commentaire RETURN_RESULTSET dans la procédure stockée lorsque l’instruction DECLARE CURSOR SQL inclut la clause SQL DECLARE CURSOR FOR SELECT.

Le service DRDA inclut un commentaire CURSOR_WITH_HOLD dans la procédure stockée lorsque l’instruction DECLARE CURSOR SQL inclut la clause SQL WITH HOLD. Le service DRDA définit la procédure stockée avec une option DECLARE CURSOR GLOBAL, et SQL Server conserve le curseur pendant les demandes de fermeture et de validation pour toute la durée de la connexion de DRDA AR au service DRDA jusqu'au serveur SQL.

Le service DRDA inclut un commentaire CURSOR_FOR_UPDATE dans la procédure stockée lorsque l’instruction DECLARE CURSOR SQL inclut la clause SQL FOR UPDATE. Le service DRDA définit la procédure stockée sans l’argument de paramètre @_FETCH_ROW_COUNT\_ = n ». Le service DRDA retourne une seule ligne par extraction uniquement.

Selon l’option de liaison, le service DRDA interprète la syntaxe de la clause SQL FOR READ ONLY et FOR FETCH ONLY comme indiquant un curseur non-modifiable, sur lequel le service DRDA peut extraire plusieurs lignes par CNTQRY. Le service DRDA définit la procédure stockée avec l’argument de paramètre @_FETCH_ROW_COUNT\_ = n ». Le service DRDA retourne une seule ligne ou plusieurs lignes par extraction en fonction de l’option de liaison.

DECLARE C2 CURSOR WITH HOLD FOR SELECT SALESKEY FROM CONTOSO.DSN8910.BULKTST1 FOR READ ONLY  
DECLARE C4 CURSOR WITH HOLD FOR SELECT SALESKEY FROM CONTOSO.DSN8910.BULKTST1 FOR FETCH ONLY DECLARE C8 CURSOR WITH HOLD FOR SELECT SALESKEY FROM CONTOSO.DSN8910.BULKTST1  

Exemples d’instructions SELECT définies à l’aide de LMTBLKPRC qui incluent le paramètre fetch row count.

Option de liaison de paquet

Le service DRDA interprète l’option DRDA BGNBND (Begin Bind) QRYBLKCTL (Query Block Protocol Control) comme remplacement de la syntaxe du type de curseur et de la clause SQL, en demandant au service DRDA de retourner une seule ligne par extraction ou plusieurs lignes par extraction sur des curseurs non modifiables.

Le QRYBLKCTL par défaut est LMTBLKPRC (Limited Block Query Protocol), qui indique au service DRDA de retourner plusieurs lignes par bloc de requête, autant que possible dans un bloc de 32K, moins les octets nécessaires pour le DRDA DSS (Data Stream Structures) pour définir les types de données de colonne.

Le programmeur DB2 peut, si nécessaire, lier un package avec l'option DB2 CURRENTDATA=YES, qui est traduite en option DRDA BGNBND (Begin Bind), QRYBLKCTL (Query Block Protocol Control), FIXROWPRC (Fixed Row Query Protocol), pour indiquer au service DRDA de renvoyer une seule ligne fixe par CNTQRY (Continue Query) en réponse à l'instruction SQL FETCH du programme.

Aucun curseur requis

Si l’option de liaison est l’option LMTBLKPRC par défaut, le serveur de données définit une procédure stockée avec une instruction SELECT, mais pas DECLARE CURSOR, lorsque l’instruction est en lecture seule. Consultez la description de la syntaxe de clause SQL et les options de liaison ci-dessous.

DECLARE C1 CURSOR FOR SELECT SALESKEY FROM CONTOSO.DSN8910.BULKTST1 FOR READ ONLY  
DECLARE C3 CURSOR FOR SELECT SALESKEY FROM CONTOSO.DSN8910.BULKTST1 FOR FETCH ONLY  
DECLARE C7 CURSOR FOR SELECT SALESKEY FROM CONTOSO.DSN8910.BULKTST1  
  

Exemples d’instructions SELECT qui ne nécessitent pas de curseurs SQL Server.