Signaux à destination des processus Unix

Principaux Signaux (nom numéro signification) :

SIGHUP     1  (hang up): émis aux processus associés à un terminal lorsque celui-ci se déconnecte.
SIGINT     2  (interrupt): signal d'interruption émis aux processus associés à un terminal lorsque le caractère d'interruption (<CTRL-C>) est tapé.
SIGQUIT    3  (quit): signal d'interruption émis aux processus associés à un terminal lorsque le caractère pour quitter une application (<CTRL-\>) est tapé.
SIGILL     4  (illegal) : émis en cas d'instruction illégale.
SIGTRAP    5  (trap) : émis après chaque instruction en cas de traçage de processus.
SIGIOT     6  (input/output trap) : émis en cas d'erreur matérielle.
SIGKILL    9  (kill) : tue un processus, quel que soit son état.
SIGSEGV    11 (segmentation violation) : émis en cas de violation de la segmentation mémoire.
SIGSYS     12 (system) : émis en cas d'erreur de paramètre dans un appel système.
SIGPIPE    13 (pipe) : émis en cas d'écriture sur un tube sans lecteur.
SIGALRM    14 (alarm) : signal associé à une horloge.
SIGTERM    15 (termination) : terminaison normale d'un processus.

Dimensionner les tableaux Cobol suivant le nombre d'occurrences du dictionnaire HR

Dans un contexte de working d'un traitement, il est possible depuis HRDesign 420 (HRv3e) de saisir une ligne de commentaires ayant la forme suivante :
*<NBOCCR>sdci

Ceci aura pour effet :

• soit de remplacer le %1 présent dans la ligne de working suivante par le nombre d'occurrences maximal de l'information (DI40.NBOCCR) tel que saisi dans le dictionnaire,
• soit de remplacer la valeur de l'occurs déclaré sur un appel de description d'une information par le nombre d'occurrences maximal de l'information (DI40.NBOCCR) tel que saisi dans le dictionnaire.

Exemple d'utilisation dans un traitement :
*         01    UZZ.
*    *          <NBOCCR>ZYAG
*    E          ZYAGUZZ   020000IT  0 
*    *    02     **** UZZAG ****   
*         01    INDICE-MAX                  PICTURE 9(4)
*    *          <NBOCCR>ZYAG
*                                  VALUE +%1.                           

Mais attention : en cas de une modification dans le dictionnaire de la valeur du nombre d'occurrences maximum, suite à la génération logique, faire une génération physique forcée des programmes des processus impactés, car HR Access ne sait pas gérer la cascade d'impact sur les traitements...

Erreur "ksh: 08+03: bad number" lors de l'interprétation de calculs sous Unix

Sous certains Unix, l'opérateur korn shell qui permet l'interprétation d'un calcul ne fonctionne pas si un des arguments vaut 08 ou 09 (l'interpréteur prend ces valeurs comme étant de l'octal).

> echo $((07+03))
10
> echo $((08+03))
ksh: 08+03: bad number
> echo $((09+03))
ksh: 09+03: bad number

Sauf à lui préciser qu'il s'agit d'un nombre en base 10

> echo $((10#08+03))
11

La suppression du zéro non significatif fait disparaitre le problème.

> echo $((8+03))
11

La commande "bc" - elle - fonctionne dans tous les cas.

> echo "08+03" | bc
11

Demandez au support Unix un patch système (information trouvée sur une documentation de BMC Patrol).

Mécanisme de catalogage HRv5 intégré aux livraisons

Catalogage et Restauration

Avec HRv5 apparaît un versionning des objets de conception HR Design. Ce versioning permet de gérer différentes versions d’un même objet.

Les fonctions proposées sont de :

• sauvegarder les objets ; la sauvegarde est appelée « catalogage »,
• lister les différentes versions de l’objet,
• comparer les différentes versions de l’objet,
• Restaurer ou purger la version précédente d’un objet.

Une demande de catalogage peut se faire sur un objet, ou sur une collection. Le stockage des sauvegardes est réalisé dans une table dédiée : VS20. Pour un objet simple, HR utilisera un code collection technique ** ******.

La description d'un catalogage est stockée dans les tables KL50 et KL51. Lorsque l’objet a été catalogué, la table KL50 est mise à jour (une ligne par objet). Puis une ligne de KL51 est écrite (une ligne par catalogage – hors collections techniques)

Dans le cadre d’un catalogage, le programme BU4 compare ligne à ligne le contenu en vigueur de la table de stockage VS20 (chaque ligne étant horodatée par une date de début et une date de fin) et le contenu de la table de l'objet (ex : TRxx pour un traitement).

• En cas de différence sur une ligne de même clé, on procède par clôture de l’ancienne ligne et insertion d’une nouvelle ligne dans la table VS20. 
• En cas d’existence d’une ligne dans la table objet absente de la table de stockage, on crée la ligne dans la table de stockage.
• En cas d’absence d’une ligne dans la table objet présente dans la table de stockage, la ligne de la table de stockage est cloturée.

NB :
- On peut cataloguer une collection en tant qu'objet simple.
- On ne peut restaurer une collection cataloguée que totalement.
- Pour restaurer un objet unique, il faut que celui ci ait été catalogué hors d’une collection.
- En cas de restauration d’une ancienne version d’un objet, pensez à revalider les objets restaurés et ceux qu’ils impactent !

Les chaînes batch de catalogage et restauration sont :

• NRG : Catalogage de l’objet : (BTS + BOB) + BOP + BU4, sous pgms BX4 d’expansion de la liste et BYA ... BY9, B0A ... B09 de catalogages spécialisés,
• NRS : Restauration de l’objet : (BTS + BOB) + BOP + BU3 + BU5 + BU2.
• RB2 (subb2) : Purge des catalogages : BU6

Ces chaines sont aussi accessibles via l'interface HR Studio.

Les utilisateurs pourront supprimer, via HRD Studio, les catalogages qui ne les intéressent plus (version intermédiaire, version ne devant plus faire l’objet d’une restauration …). La suppression d’un catalogage correspond à une suppression TP des KL50, KL51. Puis, en batch, la chaîne RB2 supprimera les lignes de VS20 n’ayant plus de correspondance dans la table KL50. La date de fin des lignes précédant celles supprimées est mise à la date de fin de la ligne supprimée si les lignes étaient directement consécutives.

Export import

Partant d’une collection, HRD Studio permet la visualisation de la liste des objets à transférer vers une plate-forme donnée et de piloter l'export et l'import des objets via l’interface :

• Demande de la constitution de la liste des objets à exporter,
• Mise à jour (optionnelle) de cette liste,
• Exportation de la liste.

Les exports / imports soumis via TP entraînent le lancement de jobs batch asynchrones (un nouveau programme BTS créant une demande dans Opération et soumettant le batch via OPER).

Dans le cas d'un export batch soumis via le système (la méthode historique avec les scripts sub**), l’utilisateur doit constituer un fichier paramètre listant les objets à transférer.

• Ces paramètres peuvent contenir des collections et/ou des objets 'libres‘,
• Une collection peut être exportée en tant qu'objet 'libre' ou ‘complexe’.

Quatre chaînes batchs d'export / import d'objets sont disponibles :

• RB0 (subb0) : Export d'un objet déjà catalogué : BU3 + BU5
• RB3 (subb3) : Export et catalogage préalable : BU4 + BU3 + BU5
• RB4 (subb4) : Import et catalogage : BU2 + BU4
• RB7 (subb7) : prise en compre de l’export : BU7.

L’exportation implique un catalogage préalable: on n’exporte pas les objets en ligne mais la version présente en table VS20.

Ci dessous un schéma illustrant les mécanismes associés à ces chaînes :

Les fichiers paramètre sont $SIGACS/param/PARAMB0 (RB0) et PARAMB3 (RB3).

Les cartes paramètres sont :

• PA61 : Caractéristiques de l’export (RB0, RB3)
• PA63 : Objets exportés (RB0, RB3)
• PA6A : Libellé du catalogage (RB3) 
• PB6B : Forcer le projet d’accueil (RB4)

Les fichiers en sortie sont PSBBC100, PSBBC101 (à placer en entrée de RB4), PSBBC102 (à placer en entrée de RB7).

Points divers :

• Les listes de transfert sont stockées dans la table de travail (PG40). 
• Les listes des objets transférés (PP40) et leur origine (PP41) sont aussi en base.
• En mode différentiel, le programme BU3 générant la liste des objets à exporter compare les horodatages des objets catalogués en KL50 avec les transferts déjà réalisés (en PP40, PP41) avant d'alimenter la PG40.

Mettre en place une file d'attente sous Unix avec "at"

En l'absence d'ordonnanceur, pour limiter le nombre de processus batch actifs, il est possible de soumettre ces travaux dans les files d’attentes Unix. Il y a 6 files d’attente; deux sont réservées pour le système, certaines à des shells particuliers (ex : f pour le csh). Préférer les queues a (aussi utilisée par la commande at - qu'il vaut donc mieux laisser le plus libre possible), b (aussi utilisée par la commande batch), et e :

• "c" - cron events, réservée au système Unix
• "d" - sync events, réservée au système Unix
• "b" - batch jobs

Les autres sont dédiées à un langage shell :

• "a" - sh jobs - at jobs 
• "e" - ksh jobs 
• "f" - csh jobs

Par défaut c'est la file "a" qui est utilisée. Une tâche peut toutefois être envoyée sur une autre queue ("e" dans cet exemple) à une heure particulière (21:20 dans notre exemple) :

echo "sh monshell.sh > $LOG/monlog.log" | at -qe 2120

La commande "at -l" permet de lister les travaux placés en attente, "at -r" de les supprimer :
at -l
hr.1044415211.e mar  4 fév 21:20:11 CST 2003

Le format du nom du travail est : <UserUnix>.<IdTravail>.<NomQueue>. Sur AIX ils sont stockés dans le répertoire /var/adm/cron/atjobs :
ls /var/spool/cron/atjobs/hr.*.?
/var/spool/cron/atjobs/hr.1044415211.e

Et la commande soumise peut être consultée en fin du fichier :
tail -1 /var/spool/cron/atjobs/hr.1044415211.e
sh monshell.sh > $LOG/monlog.log

Quand le nombre maximum de batch en cours d'exécution est atteint pour une file d'attente, les suivants restent dans le tampon du "at" (visibles par un "at -l") d'ici à ce qu'un des batch se termine et libère une place.

L'heure de soumission n'est donc pas forcément identique à l'heure de début d'exécution. Il pourra être nécessaire d'informer les utilisateurs de cette caractéristique. 

Mise en place

1) Faites paramétrer les files d'attente via le fichier /var/adm/cron/queuedefs (AIX).

Attention :

• Ceci est de la prérogative de l'administrateur Unix de la machine,
• Ce paramétrage est fait pour la machine, c'est a dire pour toutes les applications hébergées.

Par exemple pour 3 files d’attente nommées « e », « b » et « a » de respectivement 4, 4 et 9 batchs pour les paies à la demande, les paies de correction et explorations, les autre batch, avec comme priorités 20, 25, 30 (20 étant plus prioritaire que 25) :

e.04j20n60w
b.04j25n60w
a.09j30n60w

Signifie :

• queue e : 4 batch (jobs) de priorité (nice) normale (20),
• queue b : 4 batch de priorité réduite (25),
• queue a : 9 batch de priorité basse (30),
• bilan (wait) toutes les 60 secondes

2) Sous HR Access, modifiez le script ${SIGACS}/bin/job.

Exemple ci joint :
- les paies à la demande NJL sont lancées sur la queue e
- les paies de correction et explorations sur la queue b
- tous les autre batch sur la queue a

...
# Lancement d'un script de $SIGACS/bin
if [ ! "$T" ]
then
  JSCRI=`echo "$PARAM"|cut –c14-21| tr –d ‘ ‘`
  case ${JSCRI} in
  [A-Z,0-9]*NJL)
  echo "sh $SIGACS/bin/$PHASE '$PARAM' 1>$LOG/$JOBLOG 2>&1 " | at -qe now 2>> $TMP/a.batch
    ;;
  [A-Z,0-9]*NJC|[A-Z,0-9]*NBX)
  echo "sh $SIGACS/bin/$PHASE '$PARAM' 1>$LOG/$JOBLOG 2>&1 " | at -qb now 2>> $TMP/a.batch
    ;;
  *)
  echo "sh $SIGACS/bin/$PHASE '$PARAM' 1>$LOG/$JOBLOG 2>&1 " | at -qa now 2>> $TMP/a.batch
    ;;
  esac
else
...

Mettre en place une file d'attente sous Unix avec qconfig

Sous système AIX, le fichier /etc/qconfig décrit les queues et matériels disponibles par la commande enq, laquelle place les requêtes en attente, et par qdaemon, qui exécute les actions et nettoie la queue. En temps normal ce système est utilisé pour les impressions, mais il est possible de l'utiliser pour l'exécution de traitements.

Exemple :
Une queue de traitements batch se déclare de cette façon :
bsh:
  discipline = fcfs
  device = bshdev
bshdev:
  backend = /usr/bin/ksh

Pour exécuter un script nommé MonShell.sh en utilisant cette queue batch, tapez :
qprt -Pbsh MonShell.sh

Le système exécute les traitements un par un, dans l'ordre dans lequel ils ont été soumis. Le processus qdaemon redirigera les sorties standard (input, standard output, et erreur) vers /dev/null (la poubelle).

Pour permettre l'exécution de deux traitements en parallèle, déclarez :
bsh:
  discipline = fcfs
  device = bsh1,bsh2
bsh1:
  backend = /usr/bin/ksh
bsh2:
  backend = /usr/bin/ksh

Il est même possible de demander un traitement sur un serveur distant ! Ci dessous par exemple, on crée localement une queue nommée "remh" qui passera la commande à la queue "bsh" préalablement déclarée sur un serveur "pluto" (à référencer dans le etc/hosts ou le DNS de l'entreprise) :

remh: 
  device = rd0 
  host = pluto 
  rq = bsh 
rd0: 
  backend = /usr/lib/lpd/rembak

A noter :

• La commande "enq" convertit automatiquement le fichier qconfig en binaire (/etc/qconfig.bin).
• Le fichier qconfig ne doit pas être édité tant que des travaux sont présents dans les queues (édition manuelle ou via commande mkque, rmque, chque, mkquedev, rmquedev, chquedev),
• La commande "enq -G" suspend la queue une fois tous les traitements terminés,
• La commande "startsrc -s qdaemon" redémarre le démon.

Mise en place

Je n'ai pas eu l'occasion de tester cet outil, mais il me semble intéressant ...
Ci dessous ce que j'en ferais :

1) Faites paramétrer les files d'attente via le fichier /etc/qconfig (AIX).

Attention :

• Ceci est de la prérogative de l'administrateur Unix de la machine, 
• Ce paramétrage est fait pour la machine, c'est a dire pour toutes les applications hébergées.

Par exemple pour 3 files d’attente nommées « bshnjl », « bshnbx » et « bshall » de respectivement 4, 4 et 9 batchs pour les paies à la demande, les paies de correction et explorations, les autre batch :

bshnjl:
  discipline = fcfs
  device = bshnjl1,bshnjl2,bshnjl3,bshnjl4
bshnjl1:
  backend = /usr/bin/ksh
...
bshnjl4:
  backend = /usr/bin/ksh

bshnbx:
  discipline = fcfs
  device = bshnbx1,bshnbx2,bshnbx3,bshnbx4
bshnbx1:
  backend = /usr/bin/ksh
...
bshnbx4:
  backend = /usr/bin/ksh

bshall:
  discipline = fcfs
  device = bshall1,bshall2,bshall3,bshall4,bshall5,bshall6,bshall7,bshall8,bshall9
bshall1:
  backend = /usr/bin/ksh
...
bshall9:
  backend = /usr/bin/ksh 

2) Sous HR Access, modifiez le script ${SIGACS}/bin/job.

Exemple ci joint :
- les paies à la demande NJL sont lancées sur la queue bshnjl
- les paies de correction et explorations sur la queue bshnbx
- tous les autre batch sur la queue bshall

...
# Lancement d'un script de $SIGACS/bin
if [ ! "$T" ]
then
  JSCRI=`echo "$PARAM"|cut –c14-21| tr –d ‘ ‘`
  echo "sh $SIGACS/bin/$PHASE '$PARAM' 1>$LOG/$JOBLOG 2>&1; rm \${0}" > $TMP/OPER.$$.pendingjob
  case ${JSCRI} in
  [A-Z,0-9]*NJL)
  qprt -Pbshnjl "$TMP/OPER.$$.pendingjob" 2>> $TMP/a.batch
    ;;
  [A-Z,0-9]*NJC|[A-Z,0-9]*NBX)
  qprt -Pbshnbx "$TMP/OPER.$$.pendingjob" 2>> $TMP/a.batch
    ;;
  *)
  qprt -Pbshall "$TMP/OPER.$$.pendingjob" 2>> $TMP/a.batch
    ;;
  esac
else
...

Activation / désactivation des clefs étrangères sous Oracle

Les tables techniques et les tables fonctionnelles utilisent des clefs étrangères et de "delete en cascade". Leur présence est nécessaire au bon fonctionnement du produit. Lors de certaines opérations (export - import Oracle de données) il peut être utile de les désactiver temporairement.

Faire le bilan des contraintes inactivées :
select constraint_name,validated from user_constraints where constraint_type='R' and validated <> 'VALIDATED'

Créer des ordres SQL pour désactiver les clefs étrangères :

select 'alter table '||table_name||' modify constraint '|| constraint_name||' disable novalidate;'     
from user_constraints where constraint_type='R';

Créer des ordres SQL pour réactiver les clefs étrangères :
select 'alter table '||table_name||' modify constraint '|| constraint_name||' enable validate;'     
from user_constraints where constraint_type='R';

Attention car certaines tables (ex: PP12) peuvent posséder une contrainte non nommée (Oracle va donc lui attribuer un nom système et la numéroter différemment sur chaque environnement).

Boucle de mise a jour SQL avec COMMITs intermédiaires

Ci joint un modèle de boucle PL/SQL pour faire des mises à jour SQL avec des COMMITs intermédiaires (ici toutes les 100 mises à jour). Ceci est utile quand les volumes sont trop importants et provoquent des erreurs sur les tablespaces temporaires ou d'undo.

begin
loop
    update/insert/delete ... where ... and rownum < 100;
    exit when sql%rowcount < 99;
    commit;
end loop;
end;
/

Par exemple pour supprimer les travaux Opération de ZO de plus de 90 jours avec COMMIT tous les 10 DELETE :

begin
loop
    delete from ZO00 where TISOUM > '0001-01-01' and TISOUM < SYSDATE - 90 and rownum < 10;
    exit when sql%rowcount < 9;
    commit;
end loop;
end;
/

PS : ce faisant, vous avez libéré de l'espace dans chacune des tables ZO**, mais pas dans les tablespaces HRZO et HRZOI (faire un DELETE ne modifie pas l'espace alloué aux tables, mais libère de l'espace "à l'intérieur" des tables). Si vous souhaitez récupérer l'espace libéré dans chacune des tables pour le rendre disponible à toutes, vous devrez utiliser la commande :
ALTER {TABLE/INDEX} object_name DEALLOCATE UNUSED;

Le programme AEX possède une assignation APA pour un PA-FICHIER de 80 caracteres.

Ce fichier peut être consulté / alimenté par traitement spécifique : faire le OPEN, les READ/WRITE et le CLOSE dans vos traitements.

Le shell NBX ne possède pas d'assignation pour ce fichier optionnel.

• Celle ci peut être "ajoutée" manuellement par l'ajout avant le programme de la commande 

export APA=$SIGACS/txt/tmp/MONFIC
(mais cet ajout sera perdu en cas de regénération de la chaîne) 

• ou éventuellement dans le script OPER.

ProCobol Oracle - Utilisation d'une séquence dans un traitement HR Access

Cet exemple de traitement HR Access utilise une séquence Oracle pour attribuer un NUDOSS unique.

Les séquences sont plus fiables que tout mécanisme applicatif pour ce qui est d'éviter les affectations de NUDOSS en double (saisie TP importante, Mises à jours batch de reprise en parallèle).

Exemple de séquence

Création sous SQL :
SQL> create sequence HR.MYSEQUENCE start with 1 increment by 1 maxvalue 9 minvalue 1 cache 2 cycle order;
SQL> select mysequence.nextval from dual;
         1

Explicitation des options :

• cycle : pour revenir automatiquement à MINVALUE si MAXVALUE est atteint,
• cache : nombre d'identifiants conservés en mémoire par Oracle (minimum 2),
• order : obtenir que les identifiants soient fournis obligatoirement dans l'ordre,

Les pseudocolonnes CURRVAL et NEXTVAL pemettent d'obtenir l'identifiant en cours ou le suivant :

SQL> select mysequence.currval from dual;
         1
SQL> select mysequence.nextval from dual;
         2
...
SQL> select mysequence.nextval from dual;
         8
SQL> select mysequence.nextval from dual;
         9
SQL> select mysequence.nextval from dual;
         1

Destruction :
SQL> drop sequence HR.MYSEQUENCE;

Création de la séquence NUDOSS pour ZO

SQL> create sequence HR.NEW_NUDOSS_FOR_ZO start with 1 increment by 1 maxvalue 999999999 minvalue 1 cache 2 cycle order;

Création du traitement BNK contexte TBP051

Ce contexte de BNK est dédié à l'attribution de NUDOSS.

 Contexte de Variables TBW003 du traitement XY-ZONUDO

 ---------------------------------------- Variables AA --------------
010    *    HOST-VARIABLES
020    *    --------------
030    *    <DEBSEC>SO
040      01 H-MYNBDOSS             PICTURE 9(02).
050      01 H-MYNUDOSS             PICTURE 9(09).
060    *    <FINSEC>SO
070      01 U-MYNUDOSS-FOUND       PICTURE 9(01).

Contexte de Procédures TBP033 du traitement XY-ZONUDO

 ---------------------------------------------------- Fonction BB -------------
010    N   AFFECTATION NUDOSS ZO            10 BL
020    *
030    *   UTILISATION DE LA SEQUENCE
040    *   HR.NEW_NUDOSS_FOR_ZO
045    *   ET LECTURE DE ZO00
050    M   ZERO U-MYNUDOSS-FOUND
 ---------------------------------------------------- Fonction BF -------------
010    N   BOUCLE DE REHERCHE NUDOSS LIBRE  20 DW U-MYNUDOSS-FOUND = ZERO
020    *
030    *   SELECT NEXTVAL -----------------
040    *   <DEBSUB>RDTCOM
050    EXQ SELECT
060        %1.NEW_NUDOSS_FOR_ZO.NEXTVAL
070        INTO           :H-MYNUDOSS
080        FROM DUAL
090    *   <FINSUB>
092    COB DISPLAY "<DIGIX> Lecture Nextval "
094        "(" SQLCODE ") = " H-MYNUDOSS
100    ERR 0000015SQLCODE                   99 IT SQLCODE NOT= ZERO
110    GT  10
120    *   CTRL NUDOSS LIBRE -------------- 99 BL
130    *   <DEBSUB>RDTCOM
140    EXQ SELECT
150        COUNT(*) INTO  :H-MYNBDOSS
160        FROM %1.ZO00
170        WHERE NUDOSS = :H-MYNUDOSS
180    *   <FINSUB>
190    COB DISPLAY "<DIGIX> Lecture NbDoss "
200        "(" SQLCODE ") = " H-MYNBDOSS
210    *   ERREUR TECHNIQUE --------------- 99 IT SQLCODE NOT= ZERO
220    ERR 0000025SQLCODE                      AN SQLCODE NOT= W-WP00-NOTFND
230    GT  10
231    *   NUDOSS N'EST PAS LIBRE --------- 99 IT H-MYNBDOSS NOT= ZERO
232    COB DISPLAY "<DIGIX> Retour"
233    GB  20
243    *   NUDOSS LIBRE ------------------- 99 EL
253    COB DISPLAY "<DIGIX> Fin"
263    M   1              U-MYNUDOSS-FOUND
273    M   H-MYNUDOSS     UT-NUDOCR


Rattachement du traitement a FP800 et regénération.

Tests

Test de création de dossier.

traces STTS_FP800BNM :
<DIGIX> Lecture Nextval (+0000000000) = 000000001
<DIGIX> Lecture NbDoss (+0000000000) = 00
<DIGIX> Fin

Select en base :
SQL> select * from zotd11 where timjdo > '2002-05-22-00.00.00';

    NUDOSS T TIVERR              TIMJDO              VAC CDS
---------- - ------------------- ------------------- --- ---
         1 0 0001-01-01-00.00.00 2002-05-22-11.39.44 NJP DG3


Reinitialisation de la séquence (par DROP et CREATE) et nouveau test.

traces STTS_FP800BNM :
<DIGIX> Lecture Nextval (+0000000000) = 000000001
<DIGIX> Lecture NbDoss (+0000000000) = 01
<DIGIX> Retour
<DIGIX> Lecture Nextval (+0000000000) = 000000002
<DIGIX> Lecture NbDoss (+0000000000) = 00
<DIGIX> Fin

Select en base :
SQL> select * from zotd11 where timjdo > '2002-05-22-00.00.00';

    NUDOSS T TIVERR              TIMJDO              VAC CDS
---------- - ------------------- ------------------- --- ---
         1 0 0001-01-01-00.00.00 2002-05-22-11.39.44 NJP DG3
         2 0 0001-01-01-00.00.00 2002-05-22-11.48.13 NJP DG4

Le traitement a bien vu que le NUDOSS 1 était déjà attribué et a affecté 2 au nouveau dossier.

Executer un PL/SQL dans un traitement Cobol HR

Ci joint un test d'exécution d'un PL/SQL Oracle se connectant a une base distante dans un traitement HR Access (d'un point de vue architectural, un traitement de ce genre est à proscrire car on génère un "lien fort" entre les deux applications : si l'application distante est indisponible, le traitement local est bloqué).

Prérequis pour la connexion à la base distante : le listener Oracle doit être démarré et paramétré pour les bases source et cible.

Création d'un database link vers la base éloignée

Sur la base locale, la base éloignée ayant le code "DIST",

create database link BASE_DIST connect to  HR identified by ** using 'DIST';

Test de select sur la table PP10 éloignée à partir de la base locale :
select * from PP10@BASE_DIST where CDPCOM='1';

Création du package sur la base distante

Exemple : insertion de la date système dans une table spécifique

drop table MY_TABLE
/
create table MY_TABLE (MYDATE DATE)
/
drop package MY_PACKAGE
/
create package MY_PACKAGE as
procedure UPDT_DATE;
end MY_PACKAGE;
/
create package body MY_PACKAGE as
procedure UPDT_DATE is
BEGIN
      insert into MY_TABLE values (SYSDATE);
END UPDT_DATE;
end MY_PACKAGE;
/

Test d’exécution du package a partir de la base éloignée :

SQL> begin my_package.updt_date@BASE_DIST;
  2  end;
  3  /
PL/SQL procedure successfully completed.

SQL> select sysdate from dual;
2002-05-17-14.34.18
SQL> select * from my_table@BASE_DIST;
2002-05-17-14.34.04 

Exemple de traitement HR Access

En cas de création de dossier, on exécute la procédure stockée UPDT_DATE sur la base distante et on récupère la plus grande date dans la table distante MY_TABLE.

Working :
 Contexte de Variables TBW002 du traitement TT-TPSORA
 ---------------------------------------- Variables BB --------------
010    *    HOST-VARIABLES
020    *    --------------
030    *    <DEBSEC>SO
040      01  H-MYDATE PIC X(19).
050    *    <FINSEC>SO

Procedure :
 Contexte de Procédures TBP012 du traitement TT-TPSORA
 ---------------------------------------------------- Fonction BB -------------
010    N   EXECUTION D'UNE PROCEDURE STOCKE 10 BL
020    *   SUR UNE BASE DE DONNEES DISTANTE
030    *
040    *   PREREQUIS :
050    *   - DATABASE LINK BASE_DIST
060    *   - PACKAGE   MY_PACKAGE SUR DIST
070    *   - PROCEDURE UPDT_DATE  SUR DIST
075    COB DISPLAY "<DIGIX> ENTER TTTPSORA"
080    EXQ EXECUTE
085        BEGIN
090        MY_PACKAGE.UPDT_DATE@BASE_DIST;
100        END;
110    ERR 0000015SQLCODE                   99 IT SQLCODE NOT = ZERO
115    COB DISPLAY "<DIGIX> SQLCDE1 " SQLCODE
120    GT  10
130    EXQ SELECT                           99 BL
140        MYDATE INTO :H-MYDATE
150        FROM   MY_TABLE@BASE_DIST
160    ERR 0000025SQLCODE                   99 IT SQLCODE NOT = ZERO
162    COB DISPLAY "<DIGIX> SQLCDE2 " SQLCODE
164    GT  10
170    COB DISPLAY "<DIGIX> " H-MYDATE      99 EL

Incident a la compilation :
Les options de précompilation doivent intégrer une spécificité PL/SQL

Error at line 15886, column 24 in file FP800BNA.pco
000010     EXEC SQL    EXECUTE                                          TBP012
.......................1
PCB-S-00008, Must use option SQLCHECK=SEMANTICS(FULL) when there is embedded PL/SQL

Si l'option sqlcheck=semantics est ajoutée (fichier config, item PROFLAGS), la compilation du source affiche des warning volumineux avec un code retour bloquant :

/oracle/8.1.5/bin/procob    select_error=yes MODE=ANSI sqlcheck=SEMANTICS iname=FP800BNA.pco oname=FP800BNA.cbl

Pro*COBOL: Release 8.1.5.0.0 - Production on Fri May 17 16:26:39 2002
(c) Copyright 1999 Oracle Corporation.  All rights reserved.

System default option values taken from: /oracle/8.1.5/precomp/admin/pcbcfg.cfg

Error at line 6766, column 13 in file FP800BNA.pco
000001      EXEC SQL DECLARE CZOTD12 CURSOR FOR                         MACSYS
............1
PCB-S-00576, PLS-201: identifier 'ZOTD12' must be declared
Error at line 6766, column 13 in file FP800BNA.pco
000001      EXEC SQL DECLARE CZOTD12 CURSOR FOR                         MACSYS
............1
etc...

Il faut ajouter une seconde option userid=HR/** (fichier config, item PROFLAGS) pour permettre au précompilateur de vérifier l'existence des objets dans le dictionnaire Oracle.

En conséquence, on placera dans le fichier $SIGACS/adm/cfg/config :
PROFLAGS=select_error=yes MODE=ANSI sqlcheck=SEMANTICS userid=HR/**

Ces modifications faites, la compilation cobol se termine bien.

---
---    FP800BNA.pco  -->  FP800BNA.so
---
/oracle/8.1.5/bin/procob                                                 select_error=yes MODE=ANSI sqlcheck=SEMANTICS userid=HR/HR iname=FP800BNA.pco oname=FP800BNA.cbl

Pro*COBOL: Release 8.1.5.0.0 - Production on Fri May 17 16:59:12 2002

(c) Copyright 1999 Oracle Corporation.  All rights reserved.

System default option values taken from: /oracle/8.1.5/precomp/admin/pcbcfg.cfg

cob -C nolist -vz -C ASSIGN=EXTERNAL -C SEQUENTIAL=LINE -C IBMCOMP -C SIGN=EBCDIC -C WRITELOCK -C NOTRUNC -C NOBOUND -C PERFORM-TYPE=MF -C COPYLIST -C NORESEQ -U FP800BNA.cbl
* Micro Focus Server Express         V1.1 revision 000 Compiler
* Copyright (C) 1984-2000 MERANT International URN HXCAI/AA0/00000G
...
* Accepted - NORESEQ
* Compiling FP800BNA.cbl
* Total Messages:     0
* Data:       81196     Code:      160818
* Server Express V1.1.0 Code generator
* Copyright (C) 1984-2000 MERANT International Ltd. All rights reserved.
* Accepted - verbose
* Generating FP800BNA
* Data:       81728     Code:      264232     Literals:       13512.

A noter :

• L'ajout de l'option userid fait que le user/password de connexion Oracle et présent dans le fichier $SIGACS/adm/cfg/config, et dans tous les compte rendus de précompilation...
• L'ajout de l'option spellcheck=semantics impose que les tables soient créées (par RBH, RBF) avant la génération physique des programmes (par RBG, RBA).

L'executable fonctionne.
On trouve dans les traces après exécution :

<DIGIX> ENTER TTTPSORA
<DIGIX> 2002-05-17-16.23.00

SQL> select * from MY_TABLE@BASE_DIST;  
2002-05-17-16.23.00

ProCobol Oracle - Programmes volumineux - make : the return code from the last command is 11

Christophe m'indique que chez son client, un problème bloquait la pré-compilation Cobol de Oracle d'un gros programme BLK : le procob sortait en erreur suite à une opération en mémoire, et générait un généreux fichier 'core' (version Oracle  8.1.6 patchée).

make : the signal code from the last command is 11

La hot-line Oracle lui a conseillée de passer l'option ltype=none (option PROFLAGS dans le fichier $SIGACS/adm/cfg/config).

Cette option évite l'étape de génération du fichier ".lis" intermédiaire entre le .pco et le .cbl, et effectivement, une fois cette option modifiée, le programme se compile entièrement.

Taille limitée à 4 Go pour les fichiers Cobol Server Express

Une erreur dans DBJ (chaîne NJD) était apparue chez un grand compte car la taille du fichier généré dépassait les 4 Go.
Pour supprimer cette erreur, positionner dans le .profile la variable EXTFH (external file handler) si elle n'existe pas deja :

EXTFH=$SIGACS/adm/cfg/extfh.cfg
export EXTFH

Enregistrer, se déconnecter puis se reconnecter.
Dans le fichier $EXTFH écrire : 
[XFH-DEFAULT]
FILEMAXSIZE=8

Ou si l'on souhaite limiter ce paramètre au seul fichier des archives :

[XFH-DEFAULT]
[/hraprd/file/PAPFR/PSBDAP00.A]
FILEMAXSIZE=8

Ce paramètre FILEMAXSIZE de Cobol Server Express - qui a comme valeur par défaut 4 - permet d'indiquer sur combien d'octets gérer l'adressage des données (adresse codée sur 4 octets = limite à 4 Go). Avec un paramètre égal à 8 la limitation de taille est en théorie de 2 To. Sans rien regénérer, la chaîne est passée et à créé un fichier de 4,5Go.

En revanche, la commande de tri MFSort est structurellement limitée à 4 Go - Je n'ai pas trouvé de solution technique à ce jour. Il est nécessaire de trouver une solution fonctionnelle - par exemple :

• Découper le fichier a traiter,
• Trier puis fusionner les morceaux ,
• Lire et ecrire en séquence les morceaux ...

Principes de génération des applications HR Access

Les applications HR Access sont décrites à l'aide du poste de personnalisation HR Studio sur un environnement de type développement. 

Les étapes sont (en simplifiant) :

1. Création des objets du modèle de données,
2. Création des objets écrans (cas du transactionnel C/S),
3. Création des objets traitements de contrôle et mise à jour,
4. Assemblage sous forme d'entité "Processus", création des menus C/S,
5. Exécution d'un batch de génération des exécutables.

Les chaînes batch de génération des exécutables se basent sur la description des objets de conception pour écrire les shells et les programmes nécessaires :

• Elles traduisent certaines des entités en "macros" HR Design (stockées dans les tables GExx) - C'est la génération dite "Logique",
• Elles assemblent un source cobol ou un shell,
• Elles compilent le source cobol - C'est la génération dite "Physique".

La chaîne RON réalise l'ensemble des opérations pour une "Application" ou un "Processus".

La chaîne RBH se limite à la génération logique.

La chaîne RBF utilise les informations de la génération logique pour créer les DDL des tables.

La chaîne RBG liste les tâches (en table PG20) pour la chaîne RBA de génération physique.

La chaîne RBZ se limite à la génération physique d'un exécutable d'un processus.