NRB Synth

Anthony m'a invité à tester un outil d'analyse des comptes rendus NRB qu'il propose : ... Ci joint l'URL pour y accéder.

Une fois enregistré vous accédez à une application Web - vous lui transmettez votre fichier NRB322IZ (compressé s'il est volumineux), et l'application vous affiche en retour une synthèse des cas d'erreur.

Je n'ai pas contrôlé le résultat, mais l'idée est sympathique, l'analyse rapide, et la mise en forme vaut le coup d’œil ... Cela change des 24 lignes et 132 colonnes de l'édition texte !



Noter que vos données transitent sur le Web ... Évitez donc d'envoyer des informations nominatives, confidentielles ou privées !

*GE01BMQ-BBAX0007-AUCUNE POPULATION LIBRE DANS LA TP13

Les chaînes batch HR Access vont créer suivant leurs besoins des listes de dossiers dans la table TP13 (identifiant des populations) et TP33 (numéros des dossiers).

1. Le traitement qui crée une population va choisir le premier identifiant libre.
2. Si aucune population n'est disponible, l'erreur BBAX0007 apparaîtra.
3. En fin de traitement, la population est libérée par exécution du programme BE9.

Est considéré comme libre une population non verrouillée (TP13.TEVERR = 0) ou dont la création date de plus de 24 heures (TP13.TIPOPL).

Les populations de plus de 1 heure peuvent être libérées par un (syntaxe Oracle) :
update TP13 set TEVERR = '0' where TIPOPL < SYSDATE - 1/24


A noter :

• Par défaut le produit est fournit avec 50 populations dans la table TP13. Pour un site important, il est tout à fait possible d'ajouter par insert des entrées dans cette table,
• sur les premières versions HRv5 les chaînes NRA ne libéraient pas leurs populations. Si tel est le cas, demandez un patch à l'éditeur.

Tables HRDesign apparues et disparues entre HRv5 et HRv9

Un certain nombre de tables historiquement présentes ont disparu avec HRv7 et HRv9 :
- Description des applications C/S : AP22 AP27 AP60 AP61 AP70 AP75 AP76 AP77 AP80 AP81 AP85 AP90 AP92
- Blobs (renommés BX) : BL10 BL20
- Tables de communication inter-programmes : CO22 CO60 CO70
- Description des écrans C/S : FE10 FE11 FE20 FE21 FE25 FE30 FE32 FE34 FE40 FE50 FE55 FE60 FE70 FE80 FE85 FE90
- Table de Mail : MD30
- Tables de communication inter-programmes : ME20
- Description des profils de confidentialité : PF11 PF20 PF22 PF25 PF30 PF34 PF40 PF60 PF70 PF80
- Description des feuilles de style C/S : ST10 ST11 ST20 ST31
- Populations TP : TP20
- Utilisateurs : authentification externe : UC30 UC40
- Verrouillage des dossiers consultés : VR10

D'autres sont apparues :
- Archives de rappel :AB10
- Description des Processus Guidés : BP05 BP06 BP07 BP10 BP11 BP13 BP15 BP20 BP30
- Blobs (anciennement BL) : BX10 BX20
- Event Depot (et séquence Oracle SEQUED10 - inutilisée ?) : ED10 ED20
- Tables de déploiement des objets HRaSpace : EM10 EM30
- Tables de la console d'évènements (à purger) : EV20 EV90
- Table de macros (inutilisée ?) : GE80 GE85
- Journalisation du Self Service (à purger) : LO10 LO20 LO30
- Données de session des utilisateurs (à purger) : MX10 MX20 MX30 MX40
- Données de session des applications OpenHR clientes (à purger) : MY10 MY20
- Données de travail des programmes batch (à purger) : PG50 PG60 PG70 PG80
- Paramètres de le Plate Forme Physique : PP15
- Références croisées / composants internes et objets : RC56
- Description des rôles de confidentialité : RM10 RM11 RM15 RM20 RM21 RM22 RM30 RM32 RM40 RM42 RM50 RM60
- Dates d'extraction ODS : TD08
- Rôles d'un utilisateur UC10 HR Design : UC15
- Mails internes HRaSpace (HRv9) : UD10 UD20 UD30 UD40
- Bloc Note interne HRaSpace(HRv9) : UP10 UP20 UP30 

Paramètres A3W pour habillage des chaînes lors de leur génération

Laurent m'appelle pour comprendre pourquoi la même chaîne générée en DEV ou en REC ne fait pas appel aux mêmes processus Opération ...

• En DEV, on voit un appel à :

$SIGACS/bin/RTSDGN $SIGACS/prod/gnt/FP800BOP.$SUFMOD

• Mais en REC, on trouve :

$SIGACS/bin/RTSDGN $SIGACS/prod/gnt/AS800BOP.$SUFMOD

Pensez alors à regarder le nom de fichier A3W indiqué dans le rattachement du processus à la plate forme physique (radicaux utilisateurs). 

Dans notre exemple, en Développement  on trouve ceci :

Mais en REC le radical 2 est vide, ce qui signifie que par défaut c'est le fichier INTPJA3W qui est utilisé.


Ces fichiers A3W sont stockés dans le répertoire $SIGACS/param.
Pour notre exemple on trouve :

• dans le squelette de la chaine, un appel au paramètre :

JJJJJNRA:002100*S0%NJBOP                         %2à2                            7AC070

• dans le fichier INTPJA3W, une référence au paramètres, avec longueur maximale (05 caractères) et valeur :

SUB05NJ=AS800                               PROCESSUS OPERATION COM  ***********

• et dans le fichier A3WPAPFR :

SUB05NJ=FP800


Pour corriger, modifiez le radical utilisateur, et faites une RBG "J) Toutes les chaînes" RBA (RBZ pour les chaînes de radical TYBX - en indiquant le fichier A3W à utiliser).

BMQ-BBAD0036-BMQ (9P/HS) ERREUR DANS MODULE BHS : CODE RETOUR 99 - (SQL)

Le programme BMQ prend en charge la création / modification / fusion / intersection de populations batch (tables TP13/TP33). Il appelle

• soit le programme BSO (pour remplacer les zones $$SDII par le nom physique des tables)
• soit le programme BNW (pour habiller les noms physiques des tables et appliquer la confidentialité liée à l'utilisateur)

Il analyse l'ordre SQL ... Et n'aime pas du tout qu'une rubrique d'un select imbriqué ne soit pas préfixé par un code associé à la table (en tous cas dès qu'une ambiguïté est possible).

Par exemple (extrait de log avec displays techniques activés), cet ordre ne passe pas :

DESIGN/CS BMQ-42BH INSTREAM <select NUDOSS from ZD00 where CDSTCO='DSJ' and NUDOSS in (select NUDOSS from ZDF1)>
*GE01BMQ-BBAD0036-BMQ (9P/HS) ERREUR DANS MODULE BHS : CODE RETOUR 99  - (SQL) /

Mais celui ci est accepté :

DESIGN/CS BMQ-42BH INSTREAM <select NUDOSS from ZD00 where CDSTCO='DSJ' and NUDOSS in (select F.NUDOSS from ZDF1 F)>
DESIGN/CS BMQ-42DD PREPARE S1 <select NUDOSS from HR.ZD00 BMQ where ( CDSTCO='DSJ' and NUDOSS in (select F.NUDOSS from HR.ZDF1 F))>
*GE01BMQ-BBAM0021-POPULATION 0015 CONTENANT 000000000000039 DOSSIERS A ETE CREEE

Soit dit en passant, l'ordre SQL en question aurait pu être écrit avec une jointure toute bête ...

Utilitaire db2top : suivre l'activité d'une base DB2

DB2 fournit sous Unix une interface permettant de suivre l'activité de la base : db2top
Ci joint un lien vers un manuel assez pratique, avec des cas d'usage.





Pour avoir le rendu en couleurs, faire un :
export TERM=xterm

Puis appeler l'exécutable :
db2top

La vue dynamic SQL accessible par "D" permet de consulter les ordres SQL dynamiques en cours.
A noter : 

• on n'y trouve pas les requêtes statiques (sans champs variabilisés - stockées dans des bibliothèques DB2 lors du BIND),
• Pour changer le tri , faire "z" ou "Z",
• Pour voir l'ordre complet, faire "L" puis indiquer l'identifiant "HashValue" de la requête,
• L'option -V permet de spécifier le schéma par défaut - ce qui peut être utile à db2expln et db2exfmt (option "e" et "x" pour l'analyse du plan d'accès de la requête).
• Pour rafraichir les données (purger le tampon) des "dynamic sql", faire "R".

Il y a d'autres vues, comme "T" pour les tables accédées ou "U" pour les verrous actifs.

Des options par défaut peuvent être spécifiées dans $HOME/.db2toprc.

Vous pouvez collecter les données en batch - ici pendant 5 minute avec un intervalle de 30 secondes :
db2top -C -d hradev -b m -m 5 -i 30 -f $TMP/db2top.file

[14:41:32] Starting DB2 snapshot data collector, collection every 30 second(s), max duration 5 minute(s), max file growth/hour 100.0M, hit <CTRL+C> to cancel...
[14:41:32] Overridding previous occurence of '/hradev/hraccess/txt/tmp/db2top.file'
[14:42:02] 1.4M written, time 30.112, 173.8M/hour
...
[14:46:33] 8.5M written, time 300.962, 103.0M/hour
[14:47:03] Max duration reached, 8.5M bytes, time was 331.062...
[14:47:03] Snapshot data collection stored in '/hradev/txt/tmp/db2top.file'
Exiting...

Puis extraire les données du fichier :

db2top -d hradev -b l -f $TMP/db2top.file
Time;Application_Handle(Stat);Cpu%_Total;IO%_Total;Mem%_Total;Application_Status;Application_Name;Delta_RowsRead/s;Delta_RowsWritten/s;Delta_IOReads/s;Delta_IOWrites/s;Delta_TQr+w/s;Sess_Memory;Assoc._Agents;Paral._Degree;Lockwait_(sec);Locks_Held;Sorts_(sec);Log_Used;Delta_RowsSelect/s;Fetch_Count(Stmt);Dynamic_SQL;Static_SQL;#of_XQueries;Os_User;DB_User;Client_NetName;Client_Platform;Status_ChTime;Time_InStatus;IoType_(Data/Index/Temp);Sorts_Overflows;Hash_Join_Overflows;Client_Pid;Node_Number;Last_Operation;TimeTo_Connect;Session_Cpu;Statement_Cpu;Max Cost_Estimate;Wkd_Id;Recent_Cpu[1]
14:43:33;18528;0.00%;2.08%;4.76%;UOW Waiting in the application;db2jcc_applicat;43;20;713;0;0;262144;1;1;0;0;0;0;25;0;3613;354;0;DIGIX;DIGIX;digix;ABCD;14:43:04;28.081875;ddddddddddddddddddd;0;0;0;0;Static Commit;1.340;0.240599;0.000008;0;1;0.000
14:44:33;18528;0.00%;30.77%;4.40%;UOW Waiting in the application;db2jcc_applicat;0;0;16;0;0;262144;1;1;0;0;0;0;0;0;3639;362;0;DIGIX;DIGIX;digix;ABCD;14:44:04;29.102762;ddddddddddddddddddd;0;0;0;0;Static Commit;1.340;0.245410;0.000012;0;1;0.000
...
  

Avec l'option -A on a un résumé orienté performance par application.

 Rank Application_Handle(Stat)        Percentage fromTime toTime                   sum(Cpu%_Total)
----- ------------------------------ ----------- -------- --------- ------------------------------
    1 18528                             50.0000% 14:44:33 14:46:03                          100000
    2 5288                              50.0000% 14:44:33 14:46:03                          100000
    3 20799                              0.0000% 14:44:33 14:46:03                               0

Merci à Michel pour le tuyau.

Mise a jour des références croisées des squelettes par TYBXRBS

Depuis HRv7, une chaîne technique TYBXRBS est mise a disposition pour permettre la mise a jour des références croisées d'un squelette (CALL entre programmes, relations programmes et contextes, liens avec des compteurs de paie). Ces références croisées sont stockées dans les tables RF**.

Cette opération est nécessaire après avoir livré un squelette par copie du fichier (suite à réception d'un patch Hot Line ou d'une personnalisation).