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.
20 octobre 2009
8 octobre 2009
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.
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.
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.
1 octobre 2009
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) :
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.
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.
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".
* 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.
7 septembre 2009
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 *
*---------------------------------------------------------------*
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 *
*---------------------------------------------------------------*
31 juillet 2009
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é).
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é).
Inscription à :
Articles (Atom)