Sous DB2 l'erreur SQL 818 signifie qu'il existe un
déphasage entre l'exécutable et sa bibliothèque de définition des accès
SQL stockée en base. Ce déphasage a plusieurs causes possibles :
Des exécutables ont été copiés à partir d'un autre environnement, mais le bind n'a pas été fait (ou inversement) :
Suite à une livraison imparfaite, exécutable et bind sont déphasés.
Vérifiez que l'horodatage des fichiers ".so" et ".bnd" sont en phase, et cohérents avec ceux de l'environnement source.
Il suffit alors de faire la mise à jour de la bibliothèque de définition des accès SQL ("
bind") par prise en compte du fichier *.bnd :
bind RRRRRPPP.bnd collection $HRSCHEMA datetime iso qualifier $HRSCHEMA
Avec RRRRRPPP radical et code du programme.
La dernière génération s'est terminée en fin anormale :
Il est possible de se trouver dans le cas de figure ou le "bind" a été fait mais la compilation est sortie en erreur. Ce déphasage se résout en corrigeant la source du problème de compilation et en relançant la génération de l'exécutable.
Les chaines de génération physique réalisent dans l'ordre :
- L'écriture du source Cobol
- La pré-compilation DB2 du source contenant du SQL (création du *.bnd)
- Mise à jour de la bibliothèque de définition des accès SQL ("bind" par prise en compte du fichier *.bnd)
- La compilation du Cobol (fichiers *.so)
- Le stockage des générés dans $SIGACS/prod (gnt et bnd)
Lorsqu'une étape sort en erreur, le stockage des *.so et *.bnd correspondants n'est pas réalisé.
Observer la correspondance de l'horodatage des fichiers *.bnd et *.so n'est donc pas pertinent.
Mieux vaut comparer l'horodatage du bind (LAST_BIND_TIME de SYSCAT.PACKAGES) avec celui de l'exécutable (TICOMP de PG15).
Une version obsolète de l'exécutable est encore active :
Avec les versions Web de HR Access, les BHR montés en mémoire sont partagés entre les différents utilisateurs de l'application. Un BHR peut ainsi rester plusieurs heures en ligne si l'activité TP est incessante.
Si une génération a lieu entre temps, la nouvelle version des exécutables n'est alors pas prise en compte. Néanmoins, le bind de la nouvelle version des programmes ayant été fait, les BHR actifs utilisent des exécutables BNA, BNK ... déphasés.
Pour limiter cette rémanence des programmes, il convient :
- De réduire le temps de latence des BHR au minimum (working time out dans dispatcher.ini ou dispatcher.properties),
- On s'arrangera pour que les BHR soient spécialisés par processus HR (reuse_cobol_runtimes à false dans dispatcher.ini ou dispatcher.properties),
- En dernier recours on éliminera les processus unix BHR obsolètes (kill).
Exemple : un processus BHR a démarré à 11h21 mais certains programmes ont été regénérés à 11h52.
hrppr@hra:/hraccess5/hrppr/txt/log> ps -ef | grep BHR
hrppr 6604 22369 1 11:21 ? 00:00:14 /hraccess5/hrppr/bin/RTSDGN TYBXBHR WZ005BNM0000000000000001 192.168.64.11 58282 logdir=/hraccess5/hrppr/openhr/logs,trace=true,debug=true,chrono=false,client=*
hrppr@hra:/hraccess5/hrppr/prod/gnt> ltt
-rwxrwxr-x 1 hrppr v5ppr 402219 jun 28 11:52 WZ005BNA.so
-rwxrwxr-x 1 hrppr v5ppr 402219 jun 28 11:53 WZ005BJA.so
-rwxrwxr-x 1 hrppr v5ppr 402219 jun 28 11:53 WZ005BNK.so
-rwxrwxr-x 1 hrppr v5ppr 402219 jun 28 11:54 WZ005BNL.so
