Contrôle de débordement d'information

HR Access utilise des tableaux Cobols dont le nombre d'occurrence est fixé par le dictionnaire HR Access. Il peut donc arriver que ces tableau génèrent des erreurs de débordement.

Pour anticiper l'apparition de ces blocages, un collègue m'a transmis un SQL de Contrôle de débordement (ici avec les informations rattachées au processus de paie FDAZY hors 6* et 8*, l'alarme étant fixée dans le premier cas à 90% du maximum) :

  select a.nudoss, a.matcle, a.soccle, b.cdinfo, b.nboccr as NombreDico, c.cdpros,
  c.cdinfo, c.nboccr as NombreFDAZY , d.cdinfo, d.nombre as NombreTD12
  from hr.zy00 a, hr.di40 b, hr.ap30 c,  hr.zytd12 d
  where a.nudoss = d.nudoss and b.cdinfo= c.cdinfo and b.cdinfo = d.cdinfo
  and ((c.nboccr > 0 and d.nombre >= (c.nboccr*90/100))
  or   (c.nboccr = 0 and d.nombre >=  b.nboccr*90/100))
  and (b.tehist = '1' or b.tyinfo='R') and b.cdstdo = 'ZY' and c.cdstdo = 'ZY'
  and c.cdpros = 'FDAZY'
  and b.cdinfo not like '6%' and b.cdinfo not like '8%' order by b.cdinfo, d.nombre;

et

  select distinct b.cdinfo from hr.zy00 a, hr.di40 b, hr.ap30 c,  hr.zytd12 d
  where a.nudoss = d.nudoss and b.cdinfo= c.cdinfo and b.cdinfo = d.cdinfo
  and ((c.nboccr > 0 and d.nombre >= c.nboccr)
    or (c.nboccr = 0 and d.nombre >= b.nboccr))
  and (b.tehist = '1' or b.tyinfo='R')
  and b.cdstdo = 'ZY' and c.cdstdo = 'ZY' and c.cdpros = 'FDAZY'
  and b.cdinfo not like '6%' and b.cdinfo not like '8%' ;

Résoudre un verrouillage sur DB2

1 - Bilan

  db2pd -wlocks -db $DB2DBDFT

Cette commande liste les "applications DB2" (champ AppHandl) à la source d'un verrouillage et celles en attente de la levée du verrou. Si la commande n'affiche qu'une ligne avec l'heure - il n'y a pas de verrou - l'éventuel blocage n'est pas dû à DB2.

Personnaliser l'invite HRaSpace v7

Dans le fichier paramètre suivant de HRaSpace :
$SIGACS/../hraspace/webapps/hra-space/WEB-INF/classes/hra-space-str_f.xml (ici f pour français), deux paramètres sont intéressant à personnaliser :

• ID109 : message de la page d'accueil (par défaut "Bienvenue sur HRa Space")
• ID121 : message de bienvenue (affichage de l'identité de l'utilisateur connecté - variable $1 - en haut de page)

Je recommande pour ces deux champs d'ajouter (sauf en Production) le code ou le libellé de l'environnement (je vous conseille de prendre aussi en compte la version anglaise du fichier pour le cas des poste clients internationaux).

Message d'erreur "98 RS BNA 9N CG TD11 00000000000818"

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

Message d'erreur "L Z BHR 8V BN : VIRTUAL_SESSION_TIMEOUT"

Avec HRaSuite 7.1, passées 30 minutes d'inactivité, HRaSpace nettoie la session et renvoie à l'utilisateur un message VIRTUAL_SESSION_TIMEOUT qui le contraint à se reconnecter.

La durée de la session (time out) est paramétrable. Il s'agit d'insérer manuellement la ligne suivante dans la table PP15:
INSERT INTO PP15 VALUES ('code-plateforme physique','OP_TIMEOUT','mmm');

Alimenter :

• CDPLPH avec le code de la plate forme physique réelle
• VALPAR avec le nombre de minutes sur 3 caractères (mmm)
• IDPARM est alimentée par le paramètre OP_TIMEOUT (time out OpenHR)

Avec HRv9 apparaît CX_TIMEOUT. C'est la durée de connexion maximale (en minutes) - même si celle ci est restée active. Par défaut elle est de 18 heures. Sa valeur maximale possible est de 9999 minutes.

Libération de l'espace disque consommé par un log fantôme

Sous Unix, il peut arriver que les volumes fournis par les commandes "du" et "df" soient discordantes. Et l'on peut voir un disque se remplir sans réussir à trouver le fichier coupable !

Une cause probable est la conservation par le système d'exploitation d'un fichier "supprimé" ... mais encore ouvert en écriture :

• Si un processus a ouvert un écriture un fichier (ex : une exploration en boucle infinie),
• Et que vous détruisez ledit fichier (ex : le log de cette exploration),
• Alors l'espace n'est pas libéré tant que les processus Unix associés au batch ne sont pas tués.

Exemple :
L'espace disque est quasi plein (93% - 9Go consommés sur 9.8)
  df -g .
  Système de fichiers    Blocs GB      Libre %Util    Iutil %Iutil Monté sur
  /dev/lv_hradv2a            9,81       0,78   93%    52744    19% /appli/hradv2

Suppression d'un log volumineux
  rm ${LOG}/JD800NBW.DIGIX

L'espace n'est pas libéré
  df -g .
  Système de fichiers    Blocs GB      Libre %Util    Iutil %Iutil Monté sur
  /dev/lv_hradv2a            9,81       0,78   93%    52744    19% /appli/hradv2

L'espace consommé par les fichiers présents (3.2 Go) ne correspond pas a l'espace occupé dans le système de fichier (9 Go)
  du -ks /appli/hradv2
  3252884 /appli/hradv2

L'exploration à la source du log est en fait active.
Elle consomme énormément de puissance (C=120) et tourne depuis 4h25 (15h21 - 10h56).
Elle est probablement en boucle infinie.
  ps -fu ${LOGNAME}
     UID     PID    PPID   C    STIME    TTY  TIME CMD
  hradv2 1228816 1703940   0 15:21:18 pts/31  0:00 -ksh
  hradv2 1265740 2015454   0 10:56:23      -  0:00 sh /appli/hradv2/bin/OPER PPHRADV2JD800JD800NBX03PA45977233811DIGIX
  hradv2 1515600 1765484 120 10:56:26      - 268:31 /appli/hradv2/bin/RTSDGN /appli/hradv2/prod/gnt/LASS1AEX.so
  hradv2 1552476 1515600 0 15:34:42      -  0:00 oraclehradv2 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
  hradv2 1765484 1265740 0 10:59:02      -  0:00 sh /appli/hradv2/txt/tmp/JD800NBX.3096756 N

Suppression du processus (kill du Cobol AEX)
  kill -9 1515600

L'espace est maintenant libéré (6.76 Go libres)
  df -g .
  Système de fichiers    Blocs GB      Libre %Util    Iutil %Iutil Monté sur
  /dev/lv_hradv2a            9,81       6,76   32%    48252     3% /appli/hradv2

Récupérer l'heure systeme dans un traitement Cobol

Pour récupérer et afficher l’horodatage système dans un Cobol (heures, minutes, secondes, centièmes), déclarez une variable de 8 caractères et utilisez la commande "ACCEPT ... FROM TIME" :

Working :

       01         DIGIX-TIME.                  
         05         DIGIX-TIMEH PIC 9(2).     
         05         DIGIX-TIMEM PIC 9(2).     
         05         DIGIX-TIMES PIC 9(2).      
         05         DIGIX-TIMEC PIC 9(2).

Procedure :

  ACCEPT DIGIX-TIME FROM TIME.
  DISPLAY DIGIX-TIME.

Script de login Oracle login.sql

Quand SQL*Plus démarre, il recherche le script de login global "glogin.sql" dans le répertoire $ORACLE_HOME/sqlplus/admin et l'exécute s'il est présent. Dans un second temps, SQL*Plus va recherche le script de login "login.sql" dans le répertoire local, sinon dans le répertoire $ORACLE_PATH ou $SQLPATH que vous avez spécifié. Il l'exécute s'il est présent.

NB: à compter de Oracle 10g, SQL*Plus va exécuter le glogin.sql et login.sql après chaque 'connect' réussi. Cela est pratique quand on affiche le "user Oracle" dans l'invite.

Tester l'accessibilité de HR Access Web

Depuis HRv5.0.3, la servlet HRAdmin permet - via le paramètre AUTOCHECK - d'obtenir un bilan rapide de l'accessibilité de l'application :

http[s]://[serveur]:[port]/[hraccess]/HRAdmin?ACTION=AUTOCHECK

Le résultat retourné sera, si aucune erreur n'est détectée :
<HRRESULT Error="0">
 <![CDATA[ Autocheck OK  ]]>
</HRRESULT>

Un utilitaire comme "wget" permettra de "scripter" un contrôle de disponibilité de HR Web.

Pour HRv7 cette commande est spécifique au Rich Client (WebApp hr-rich-client). La  console d'administration permet en revanche de visualiser les statuts des modules. L'URL utilisable est (FUNCTION correspondant au nom de la fonction dans l'objet topologie système) :
http[s]://[serveur]:[port]/[hraccess]/hr-admin-console/controler?action=status&function=[FUNCTION]&node=[FUNCTION]Node

Exemple :

  hradev@srvhra:/hraccess/txt/tmp> wget -nv \--http-user="hr" \--http-passwd="mot2passe" --output-document="/tmp/$CDPLPH.OPENHRS.status"  "http://1.2.3.4:12345/hr-admin-console/controler?action=status&function=OPENHRS&node=OPENHRSNode"
 
  hradev@srvhra:/hraccess/txt/tmp> cat "/tmp/$CDPLPH.OPENHRS.status"
  OK

PS : Toute la chaine de connexion n'est pas contrôlée par la servlet HRAdmin, notamment les mécanismes de connexion de l'utilisateur et la résolution de sa confidentialité. Il faut entendre ce contrôle comme nécessaire mais non suffisant.

Tables working CO40 et CO41

Ces zones working des programmes de gestion de dossiers servent a stocker en mémoire la clef des demandes de mises à jour (table working CO40) et leur contenu (table working CO41). Ceci est valable pour les demandes de mise à jour (batch/TP), mais aussi pour les AMJ / AMK faits par les traitements rattachés aux processus de gestion.

Débordement de tables CO40 / CO41

En batch si la taille des zones CO40 / CO41 est insuffisante, les programmes basculent leurs données en base dans la table M8 (nom complet <RDPROS>M81). Ceci leur permet de continuer, mais avec des performances dégradées.
Depuis HRv3e, le TP fonctionne comme le batch avec une table de débordement CO40 en Base de Données. Les programmes peuvent toutefois bloquer sur des débordements en cas d'utilisation d'opérateurs ALE - opérateur incompatible avec la table en base.

Cryptage standard HR du mot de passe UC10-CDPASS avec HRv3, v5, v7

Par défaut le mot de passe de l'annuaire HR Access (table UC10 champ CDPASS) est en clair... Le minimum est d'en crypter le contenu.

Pour activer le cryptage standard HR Access, rattachez un traitement de type BCF avec dans le contexte TBPPSW la ligne et regénérez votre processus de confidentialité (AS0DC en standard).
M   "1"          UT-TECRYP         10 IT UT-TECRYP="0"

HR note que le mot de passe est codé en alimentant le champ UC10-CDPRDE (ca sent la vampirisation de rubrique) :

• 0 : non crypté
• 1 : cryptage standard
• 2 : cryptage spécifique

Ce cryptage standard fonctionne par translation de caractère (ce qui est loin d'être parfait). La règle peut se retrouver dans le squelette de BCX :
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-+;/ !(,)><=$_
-/AZ!1BFJV7(QSCL9X0Y,6+E4=2UR>); P5<8D_GK3MHIONW$T

Pour décoder un mot de passe, on pourra donc utiliser sous Unix une commande comme la suivante :
echo "!,X!7-" | tr "T\-/AZ!1BFJV7(QSCL9X0Y,6+E4=2UR>); P5<8D_GK3MHIONW\$" "_ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789\-+;/ !(,)><=\$"

Pour activer un cryptage personnalisé on utilisera :
M   "2"          UT-TECRYP

Le reste est à coder (écrivez des fonctions de codage et de décodage). Vous pourrez aussi faire un appel par un CALL à un module externe ... à condition de linker ce dernier au BNR et au RTSDGN (en modifiant le Makefile de adm/src).

Notez que quelle que soit votre politique, sur le réseau et dans les logs on pourra trouver le mot de passe crypté ... suivant la méthode standard.

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.

NOY et message "BBAD0012-DEPASSEMENT DE CAPACITE"

Le message suivant est fréquemment émis par la chaîne NOY d'exportation de données : BLS-BBAD0012-DEPASSEMENT DE CAPACITE (TABLE WORKING) : ****… 

En fait ce n’est qu’un warning, et les données sont bien exportées  (une correction a été faite depuis au moins la v3 de HR Access)... Il est donc inutile de tenir le nombre d’occurrence du dictionnaire à jour pour ce batch.

J'ai réalisé en HRv3.2 l'export d’une population avec un programme BCG compilé avec un nombre d’occurrence à 10 puis à 100. L’export avec le nombre d’occurrence positionné à 10 génère un warning (cf ci-dessous). Mais la taille du fichier d'export est identique à celui réalisé avec le nombre d’occurrence positionné à 100. Dans les deux cas le fichier contient bien toutes les occurrences de ZYSR.

On pourrait ouvrir un évènement HotLine pour message d’erreur abusif !
 
*****************************************************************
*                    Exportation des données                    *
*****************************************************************
 
JOB : JNOY                            DATE : 2009/09/01 15:59:29
 
*-------------------------- STEP120B -----------------------*
*                    REMOVE du fichier PSBBCG00                 *
*-----------------------------------------------------------*
 
*-------------------------- STEP120N ---------------------------*
*                    Exportation des données                    *
*---------------------------------------------------------------*
YIZZYBCG-BBAD0001-======================================================================================================
YIZZYBCG-BBAD0002-IDENTIFICATION DU PROGRAMME : BCG/4.200/2009-09-01-15.58.27/F/
YIZZYBCG-BBAD0003-DEBUT DE TRAITEMENT   - HORODATAGE DE DEBUT : 2009-09-01-15.59.29
YIZZYBCG-BBAD0004-LISTE DES PARAMETRES LUS
YIZZYBCG-BBAD0006-....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
YIZZYBCG-00000000-PA83F
YIZZYBCG-00000000-PA85 P  0002
YIZZYBCG-00000000-PA861SR
YIZZYBCG-BBAD0005-LISTE DES PARAMETRES INTERPRETES ET UTILISES
YIZZYBCG-BBAD0006-....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
YIZZYBCG-00000000-PA83F
YIZZYBCG-00000000-PA85 P  0002
YIZZYBCG-00000000-PA861SR
YIZZYBLS-BBAD0002-IDENTIFICATION DU PROGRAMME : BLS/4.200/2009-09-01-15.58.33/F/
YIZZYBLS-BBAD0012-DEPASSEMENT DE CAPACITE (TABLE WORKING) : ZYSR/000000000000012/000000000000012
YIZZYBCG-BBAD0008-STATISTIQUES SUR LES FICHIERS (ENREGISTREMENTS LUS/ECRITS)
YIZZYBCG-BBAD0009-PA (PA) : 000000000000003
YIZZYBCG-BBAD0009-M8 (M8) : 000000000000381
YIZZYBCG-BBAD0010-*** BCG : FIN NORMALE  - HORODATAGE DE FIN   : 2009-09-01-15.59.30  **** CODE RETOUR 00 ******
 
ls : 0653-341 Le fichier /hrdev/txt/lis/NOY*.31712 n'existe pas.
JOB : JNOY                            DATE : 2009/09/01 15:59:30
 
*---------------------------------------------------------------*
*                          Fin du job                           *
*---------------------------------------------------------------*

Analyse des transactions TP avec HRv5

Les fichiers chrono.log* disponibles avec HRv5 permettent de quantifier l'activité TP sur la base de "Transactions BHR" (une transaction BHR correspondant à un appel des programme Cobol transactionnels). Notez qu'une "Transaction utilisateur" va générer plusieurs "Transactions BHR". Toutefois cela n'altère en rien la qualité des mesures effectuées par ce biais.

La commande "awk" suivante vous permettra d'obtenir, pour le fichier chrono.log en cours, le nombre de transactions par tranche de 10 minutes, total, une analyse par processus HR, code action fonctionnelle, type de message, et le différentiel des connexions et déconnexions (ce qui correspond au nombre maxi d'utilisateurs connectés pour peu que vous démarriez votre analyse à un moment ou personne n'est connecté).

Type des messages reçus par BHR et BNM avec HRv7

Les traces permettent de voir le contenu des messages reçus par le serveur et traités par les programmes BHR / BNM. Deux caractères permettent au client de typer ses messages.

Exemple de message (récupéré dans le fichier stop_watch.log HRv7) :2011-03-25 10:19:40,946[ResponseListener-1] OPHRS1900 |10:19:40.613|       8|     325|     333|com.hraccess.dispatcher.utils.Header@63796379[transactionCode=Z00     ,programName=AS800BNM,virtualSessionId=q9sNW...,applicationId=*000GFT01BXKL,conversationId=0000,instanceId=8+C2,threadId=00,roleTemplate=ALLHRLO ,roleInstanciationValue=FR ,messageCode=2X]

•  processus "AS800"
•  message 2X "Demande d'information avec self + blobs"
•  Modèle de rôle "ALLHRLO"
•  virtualSessionId "q9sNW..."  - A mettre en relation avec :

hr-rich-client.log:2011-03-25 08:00:22,818 [1.3.1.4][  ] INFO  hraccess - HRWEB1068 User [User ID=AROGER][Virtual session ID=q9sNW...] connected

•  applicationId "*000GFT01BXKL", instance "8+C2"  - A mettre en relation avec :

hr-rich-client.log:2011-03-25 01:09:46,473 [  ][  ] INFO  connection - OPHRC1110 Opened a stand-alone session with application ID <*000GFT01BXKL> and instance ID <8+C2>


Ci dessous la liste des différents types :