2. Simplifier la création des bases de donénes SQL

objets existants, et ce que
l’on utilise DDS ou SQL pour créer les
objets DB2.
L’inclusion systématique de l’opération
suppression pose un problème : la
première exécution du script déclenche
une erreur pour la simple raison que
l’objet DB2 n’existe pas encore. Les
scripts qui utilisent la commande CL
CRTPF (Create Physical File) utilisent la
commande CL MONMSG (Monitor
Message) pour traiter cette condition,
en ignorant l’erreur et en laissant le
script poursuivre son exécution. Avant
la V5R3, le script base de données SQL
qui utilisait la commande RUNSQLSTM
(Run SQL Statement) pour exécuter un
script n’avait pas cette possibilité. Si une
instruction SQL DROP ne pouvait pas
trouver l’objet DB2, la commande
RUNSQLSTM se terminait immédiatement en produisant
une erreur. Cet état de fait imposait souvent deux versions
du script de création : l’une avec les seules opérations de
création et l’autre avec les opérations de création et de
suppression.
DB2 a résolu ce problème en V5R3 en changeant le niveau
de gravité de l’erreur associé aux instructions DROP qui
génèrent une erreur Object Not Found. Les instructions SQL
DROP qui échouent avec ce type d’erreur en V5R3 génèrent
désormais un niveau de gravité de message d’erreur de 20.Dans les releases antérieures, ce niveau était de 30 pour les
erreurs DROP.
Pour bénéficier de ce changement du niveau de gravité
des erreurs DROP, on peut assortir la commande RUNSQLSTM
du paramètre ERRLVL. Le paramètre niveau d’erreur
adopte par défaut un niveau de gravité de 10. Cette valeur signifie
que RUNSQLSTM cesse d’exécuter les instructions
SQL dès réception de messages d’erreur d’un niveau de gravité
supérieur à  10. C’est ce que montre la figure 4.
La commande

RUNSQLSTM SRCFILE(mysrc) SRCMBR(s1)

échoue et arrête l’exécution immédiatement après l’instruction
DROP, parce que le message d’erreur DOP (SQL0204)
présente un niveau de gravité supérieur à  10. En V5R3, on
peut spécifier un niveau de gravité de 20 sur la commande

RUNSQLSTM SRCFILE(mysrc)

SRCMBR(s1) ERRLVL(20)
ce qui permet à  la commande d’ignorer le message d’erreur
DROP et de continuer à  exécuter le script SQL, comme le
montre la figure 5. Par opposition à 
l’exemple précédent, le message d’erreur
DROP est signalé, mais le traitement
du script SQL continue parce que
le niveau de gravité de 20 n’est pas supérieur
à  20. On voit aussi dans la figure
5 que la commande RUNSQLSTM
échoue parce que l’instruction CREATE
VIEW échoue avec un message de gravité
de niveau 30. Cet échec démontre
les actions pré-V5R3 de l’instruction
DROP, dans lesquelles une condition
Object Not Found (Objet non trouvé)
générait un message d’erreur d’un niveau
de gravité 30.
A l’évidence, exécuter et gérer des
scripts SQL avec RUNSQLSTM est beaucoup
plus facile en V5R3, avec l’ajustement
du niveau de gravité pour les erreurs
d’instruction DROP « normales ».