17 septembre 2009

Message d'erreur "BBAD0019-MODULE EXECUTABLE DIFFERENT DE DERNIERE COMPILATION"

Les programmes Cobol HR Access stockent leur horodatage de compilation à deux endroits :
* dans la base de données, table PG15 champ TICOMP
* dans le source du programme lui même, variable TICOMP.
Jusqu'en HRv5, les batch dont les programmes ont des horodatages discordants sont mis en erreur :

FDAZDB9J-BBAD0019-MODULE EXECUTABLE (2009-06-24-08.52.12) DIFFERENT DE DERNIERE COMPILATION (2009-05-07-17.24.24)  B9J

Comme en générale le source est perdu, il n'est pas facile à postériori de connaitre le TICOMP d'un programme compilé ...

La commande Unix suivante permet de le récupérer dans la majeure partie des cas.
Exemple pour le programme FDCALDBI.so :

strings $SIGACS/prod/gnt/FDCALDBI.so | cut -c1-19 | grep '^....-..-..-..\...\...'|head -1

Reste à mettre la PG15 en accord avec l'exécutable par un update ...

Une solution plus classique est de forcer la regénération des programmes (par exemple RBG choix G + RBA, sinon RBZ) - ou de relivrer le processus si l'environnement est de type "exploitation".

Cas d'une NBW soumise avec un mauvais code plate forme

Dans l'assistant de gestion, l'écran de soumission de la chaine NBW (génération des explorations) permet de saisir un (mauvais) code plate forme. La génération va alors recréer les programmes techniques avec des conséquences "catastrophiques" pour l'environnement : les batch ne fonctionnent plus, le OpenHR ne redémarre plus. La solution la plus rapide pour rétablir la situation est de :
  • Repérer dans la table PG15 les lignes avec le "mauvais" code plate forme,
  • Supprimer par delete les doublons ayant le "bon" code plate forme (ou modifier ce code plate forme pour lui donner une valeur temporaire - ex: OLD_PGMS),
  • Modifier par update les occurrence avec le "mauvais" code plate forme pour y mettre le "bon".
  • Tester un batch, tester le TP.

Aucun commentaire:

Enregistrer un commentaire