Les registres spéciaux

Vous pourriez ainsi collecter facilement des données de moniteur de base de données pour certains programmes ou modules spécifiques plutôt que pour toute l’application.

Les registres spéciaux client ne sont pas réservés à l’usage d’IBM : ce sont des interfaces programmatiques mises à disposition de votre application comme SQL. Certains programmeurs accélèrent les processus de réglage (débogage et performance) en faisant attribuer par leurs applications des valeurs aux registres spéciaux client.

Prenons le cas d’un système ralenti par une instruction SQL longue à exécuter, détectée par un outil de performances DB2 comme le moniteur de base de données ou Visual Explain. Ces outils identifient le texte de l’instruction SQL, sans que vous connaissiez l’application responsable de son exécution. Si les registres spéciaux client avaient été définis avant que votre application ne soumette des instructions SQL, les valeurs de registres client permettraient de déterminer si le SQL provient de votre application, d’un logiciel tierce partie, ou d’un produit IBM. Dès lors que les registres client fournissent ce renseignement sur l’environnement, il est bien plus facile de déterminer les problèmes.

Vous trouverez ci-dessous une liste des interfaces programmables dont l’IBM i 6.1 dispose pour attribuer des valeurs aux registres spéciaux client. Ces interfaces permettent d’attribuer une chaîne de caractères d’un maximum de 255 octets à une valeur de registre client. Si vous avez l’intention d’utiliser les filtres de registres client du moniteur de base de données, il faut que les valeurs de registres client soient plus courtes : en effet, les filtres de registres client ne sont pas des paramètres formels sur la commande STRDBMON. Comme les paramètres sont passés indirectement par l’intermédiaire du paramètre COMMENT, les filtres de registres client ne peuvent pas dépasser 50 octets. Voici la liste des interfaces programmables :

•    IBM i SQLESETI API

•    CLI SQLSetConnectAttr() function

•    JDBC setClientInfo connection method

•    OLE DB provider (IBMDASQL and IBMDA400) connection string keywords
o    Application Name
o    Client Accounting
o    Client Program ID
o    Client User ID
o    Client WorkStation Name

•    ADO.NET provider connection string keywords
o    ApplicationName
o    ClientAccounting
o    ClientProgramId
o    ClientUserId
o    ClientWorkstation

•    SYSIBM.WLM_SET_CLIENT_INFO stored procedure
o    First Parameter: Client User ID
o    Second Parameter: Client WorkStation Name
o    Third Parameter: Client Application Name
o    Fourth Parameter: Client Accounting
o    Fifth Parameter: Client Program ID

La procédure stockée WLM_SET_CLIENT_INFO ne changera la valeur d’un registre client que quand une valeur non-null sera passée comme paramètre. Si une valeur de paramètre d’entrée null est passée sur l’appel de procédure, le registre client associé à cette valeur de paramètre null restera inchangé. Prenons comme exemple l’appel de procédure stockée suivant.

    CALL sysproc.wlm_set_client_info( NULL, NULL, ‘MYAPP’, NULL, ‘MYPGM1’)

On voit que trois des cinq valeurs d’entrée sur l’appel de procédure stockée sont null. Il s’ensuit que les valeurs de registres CLIENT USERID, CLIENT WRKSTNNAME, et CLIENT ACCTG ne sont pas changées sur l’appel de procédure. Cet appel de procédure n’a que deux conséquences : le registre CLIENT APPLNAME est changé en ‘MYAPP’ et le registre CLIENT PROGRAMID est changé en ‘MYPGM1’.
Il existe plusieurs outils pour examiner la valeur courante des registres spéciaux client et déterminer s’ils ont ont été bien définis par votre application. En plus du moniteur de base de données et de Visual Explain, l’outil SQL Details for Job de System i Navigator peut aussi servir à examiner les valeurs des registres client associées à une requête SQL. Pour accéder à l’outil SQL Details, faites un clic droit sur l’icône Databases dans l’arborescence System i Navigator et sélectionnez cette tâche. La figure 4 donne un exemple de la sortie de SQL Details for Job.

Tout compte fait, il n’y aura plus de mauvaises nouvelles

On voit bien maintenant comment les registres spéciaux client et les filtres de moniteurs de base de données peuvent être associés pour instaurer le suivi pour STRSQL – et toute autre interface SQL sur votre système. Voila une excellente nouvelle pour les auditeurs qui doivent savoir exactement quels changements ont été apportés à la base de données et par qui. Bon suivi !