JOURNAL

   F O N C T I O N    J O U R N A L   S U R    A S / 4 0 0
--------------------------------------------------------------
- Permet à tout moment de conserver la trace de toutes
                            les modifications faites sur la Base de Données.


A tout moment il faut pouvoir : - Redémarrer après un incident.
                                - Revenir à une situation antérieure.
                                - Analyser qui a fait quoi.
                                - Minimiser les risques de désynchronisation
                                       des fichiers.
               SYNCHRONISATION FICHIER AU NIVEAU D'UNE TRANSACTION
               ---------------------------------------------------


Prog.1  Lecture     Lecture     Lecture    :M.A.J     M.A.J     Ecriture
           F1          F2          F3      :  F2        F3         F4 :
                                           :                          :
Temps ------------>                      ! :       !         !        :  !
                                         ! :       !         !        :  !
                                         ! :       !         !        :  !
                                        T1 :      T2        T3        : T4
                                           :                          :
                                           :<----Problème si coupure->:

                   R E D E M A R R A G E     A     F R O I D


(1)  ---------------------------------------------------------------------->
         !                      !                      !
         !                      !                      !
         !                      !                      !
         !                      ! ------(3)-------------------------------->
         !                      !                      !
         !                      ! <--perte d'infos---> !
         !                      !                      !
     Point de               Point de                   !
     Contrôle               Contrôle                   !
                      (2) RESTAURATION                 !
                                                    Incident


                         (1) - Traitement normal


                         (2) - Retour au dernier point de contrôle.


                         (3) - Reprise par l'utilisateur.

                   R E D E M A R R A G E     A     C H A U D


(1)  ---------------------------------------------------------------------->
         !                      !                      !
         !                      !                      !
         !                      ! ------(3)----------> !
         !                      ! (reconstruction BD)  !
         !                      !                      !
         !                      !                      ! ------(4)--------->
         !                      !                      !
         !                      !                      !
         !                      !                      !
     Point de               Point de                   !
     Contrôle               Contrôle                   !
                      (2) RESTAURATION                 !
                                                    Incident
                         (1) - Traitement normal.


                     (2)+(3) - Synchronisation de la base de données.


                         (4) - L'utilisateur peut reprendre à la dernière
                               transaction.

                   L E S     I M A G E S     A V A N T


(1)  ---------------------------------------------------------------------->
         !                      !                      !
         !                      !                      !
         !                      ! <-------(2)--------- !
         !                      !                      !
         !                      !                      !
         !                      ! --------(3)------------------------------>
         !                      !                      !
         !                      !                      !
         !                      !                      !
     Point de               Point de                   !
     Contrôle               Contrôle                   !
                                                       !
                                                    Incident
                        (1) - Traitement normal.


                        (2) - Recouvrement arrière en utilisant
                              l'image des données avant leur modification.


                        (3) - Reprise par l'utilisateur/situation antérieure

                   L E S     I M A G E S     A P R E S


(1)  ---------------------------------------------------------------------->
         !                      !                      !
         !                      !                      !
         !                      ! ----(3)------------> !
         !                      !                      !
         !                      !                      !
         !                      !                      ! -----(4)---------->
         !                      !                      !
         !                      !                      !
         !                      !                      !
     Point de               Point de                   !
     Contrôle               Contrôle                   !
                      (2) RESTAURATION                 !
                                                    Incident
                         (1) - Traitement normal.


                     (2)+(3) - Recouvrement avant en utilisant
                                l'image des données après leur modification.
                         (4) - L'utilisateur peut reprendre à la dernière
                                transaction.

              F O N C T I O N N E M E N T    D U    J O U R N A L
              ---------------------------------------------------


** L'utilisation du journal permet au système de garder une trace :


 - des «images après» (option par défaut).


 - des «images avant» et «images après»


** Ces images sont conservées dans l'ordre des modifications apportées
       à la base de données, indépendamment de qui l'utilise.


---> L'ajout dans le journal se fait avant l'écriture de l'enregistrement
      concerné dans la base de données.


** La fonction journal repose sur l'utilisation de 2 types d'objets.


 - Le journal (type : *JRN)


 - Le récepteur de journal (type : *JRNRCV)

        D E S C R I P T I O N    G E N E R A L E    D U    J O U R N A L
        ----------------------------------------------------------------


- La journalisation est une fonction machine liée à un fichier.


- La fonction journal est mise en oeuvre par des commandes CL et le système
  assure le recouvrement des fichiers.


- Les fichiers journalisés sont synchronisés automatiquement avec le journal


- Les postes (opérations d'entrée/sortie) sont écrits dans un objet séparé


- Seuls les fichiers physiques sont journalisés (par défaut).


- Les modifications faites sur un fichier physique par le moyen d'un
   fichier logique sont prises en compte par le système.

                     P R I N C I P E    D U    J O U R N A L
                     ---------------------------------------


                                    S A N S
                                    -------


         Prog.1               Fichier Application (F1)          Prog.2


         WRITE  ------------> ___________________               READ
                              ___________________
                              ___________________

                     P R I N C I P E    D U    J O U R N A L
                     ---------------------------------------


                                    A V E C
                                    -------


         Prog.1               Fichier Application (F1)          Prog.2


         WRITE  ------------> ___________________               READ
            !                 ___________________
            !                 ___________________
            !
            !                _____________________
            !               <_____________________>
    .*JRN....               <      *JRNRCV (R1)   >
    :fichier:-------------->< _WRITE/F1/prog1/.._ >
    :  F1   :               < ___________________ >     - Image après
    :récept.:               < ___________________ >           OU
    :  R1   :               < ___________________ >     - Image après
    :.......:               < ___________________ >       et image avant
                            <_____________________>

                   L ' O B J E T    J O U R N A L    * J R N
                   -----------------------------------------


** C'est un objet par lequel est prise en compte toute modification apportée
      à un ou plusieurs fichiers physiques.


** Il permet de retrouver des informations sur :


 - Le ou les récepteurs (*JRNRCV) qui lui sont associés.


 - Le ou les fichiers physiques journalisés par son intermédiaire.




** Il est possible, à tout moment, de détacher un récepteur d'un journal
     et d'attacher le nouveau, sans interrompre le déroulement normal
      des opérations (fichiers ouverts, programmes actifs)


** Lorsqu'un nouveau récepteur est attaché à un journal, le précédent
 est automatiquement détaché. Ceci autorise une segmentation des sauvegardes


** Dès qu'un récepteur est attaché à un journal, il fait partie d'une
  chaîne de récepteurs connus et gérés par ce journal.

                   Fichier                           Fichier
             ___________________               ___________________
             ___________________               ___________________
             ___________________               ___________________
             ___________________               ___________________
             ___________________               ___________________
                      !                            /
                      !             _______       /
                       ------->   < Journal > <--/
                                   <_______>
                                    / 
  Récepteur                       /        Récepteur          Récepteur     -- R
_______________                 /        _________________  ____________________
_______________ <-------------/          _________________  ____________________
_______________                          _________________  ____________________
_______________                          _________________  ____________________
   Attaché                                 Détaché            Détaché          D
le 12/xx/xx                              le 12/xx/xx        le 11/XX/XX
                                                              Sauvegardé 
                                                            le 12/XX/XX

                        M I S E     E N     O E U V R E
                        -------------------------------


                       - Création d'un récepteur.         CRTJRNRCV 


                       - Création d'un journal.           CRTJRN 


                       - Démarrage de la journalisation.  STRJRNPF 



                     Créer un récepteur de journal (CRTJRNRCV)  

  Indiquez vos choix, puis appuyez sur Entrée. 


  Récepteur de journal . . . . . . JRNRCV          JRNRCV0001 
    Bibliothèque . . . . . . . . .                  *CURLIB    
  ID pool mémoire secondaire . . . ASP            1      
  Choix unité mémoire  . . . . . . UNIT           *ANY   
  Seuil d'alerte du récepteur  . . THRESHOLD      *NONE       
  Texte 'descriptif' . . . . . . . TEXT           *BLANK
                     

                 C R E A T I O N     D ' U N     J O U R N A L
                 ---------------------------------------------


** BUT : Créer un journal et ses attributs, et lui attacher un récepteur(s).


         Le(s) récepteur(s) doivent exister avant la création du journal.


                             Créer un journal (CRTJRN)       

   
  Indiquez vos choix, puis appuyez sur Entrée. 


  Journal  . . . . . . . . . . . . JRN             CMDJRN     
    Bibliothèque . . . . . . . . .                  *CURLIB    
  Récepteur de journal . . . . . . JRNRCV          JRNRCV0001 
    Bibliothèque . . . . . . . . .                  *LIBL      
                                                                <- 2 Maxi.
                                                    *LIBL      
  ID pool mémoire secondaire . . . ASP            1      
  File att msg seuil d'alerte  . . MSGQ           QSYSOPR    
    Bibliothèque . . . . . . . . .                  *LIBL      
  Texte 'descriptif' . . . . . . . TEXT           *BLANK
                     

 La version 3.10 propose une gestion automatique des récepteurs de journaux.


 Cette nouveauté semble intéressante si vous utilisez la fonction
  journal uniquement pour gérer le COMMIT/ROLLBACK avec DB2/400 et
  non dans un but de sauvegarde.


 1/ sur votre récepteur renseignez le paramètre THRESHOLD (seuil d'alerte)


                    Créer un récepteur de journal (CRTJRNRCV)


 Indiquez vos choix, puis appuyez sur ENTREE.


 Récepteur de journal . . . . . . JRNRCV                   
   Bibliothèque . . . . . . . . .                 *CURLIB   
 ID pool mémoire secondaire . . . ASP            *LIBASP 
 Seuil d'alerte du récepteur  . . THRESHOLD      *NONE      <--
 Texte 'descriptif' . . . . . . . TEXT           *BLANK                     




Ce paramètre indique quand le changement automatique de récepteur doit
 avoir lieu (taille maxi en Ko).

Puis, sur la commande :
                            Créer un journal (CRTJRN) ou (CHGJRN)


 Indiquez vos choix, puis appuyez sur ENTREE.


 Journal  . . . . . . . . . . . . JRN                      
   Bibliothèque . . . . . . . . .                 *CURLIB   
 Récepteur de journal . . . . . . JRNRCV                   
   Bibliothèque . . . . . . . . .                 *LIBL     
                                                           
                                                  *LIBL     
 ID pool mémoire secondaire . . . ASP            *LIBASP 
 File att msg seuil d'alerte  . . MSGQ           QSYSOPR   
   Bibliothèque . . . . . . . . .                 *LIBL     
 Gestion des récepteurs . . . . . MNGRCV         *SYSTEM    < CHGJRN auto.
 Suppression des récepteurs . . . DLTRCV         *YES       < DLTJRNRCV auto
 Options de taille de récepteur   RCVSIZOPT      *NONE 
 Texte 'descriptif' . . . . . . . TEXT           *BLANK                     


Le système enchaîne alors les commandes suivantes: CHGJRN JRNRCV(*GEN)
                                                   DLTJRNRCV du récepteur.

 Puis il faut démarrer la journalisation POUR CHAQUE FICHIER.



                       Démarrer journalisation PF (STRJRNPF)    



  Indiquez vos choix, puis appuyez sur Entrée. 


  Fichier physique à journaliser   FILE            LCDEF      
    Bibliothèque . . . . . . . . .                  *LIBL      
                          + si autres valeurs                
                                                    *LIBL      
  Journal  . . . . . . . . . . . . JRN             CMDJRN     
    Bibliothèque . . . . . . . . .                  *LIBL      
  Enregistrer images . . . . . . . IMAGES         *AFTER  (ATTENTION *BOTH) 
  Postes de journal à omettre  . . OMTJRNE        *NONE          !
                                                                 !
                                                                 !
                                                                 v
                                                          pour les images
                                                            avant/après

 La version 5.10 apporte de nombreuses nouveautés pour la fonction journal


  deux paramètres permettent de gagner de la place sur les récepteurs :


   sur les commandes CRTJRN / CHGJRN


 + RCVSIZOPT(*MINFIXLEN) les informations de JOB et de profil ne sont plus
                           stockées.


   il ne faut pas avoir besoin de ces notions à des fins d'analyse ou de
    reprise manuelles.




 + MINENTDTA(*FILE | *DTAARA)


   indique les objets pour lesquels on doit stocker des données réduites :


   *DTAARA, pour les data area on stocke uniquement les octets modifiés


   *FILE  , pour les fichiers, les données sont compressées
            (et donc illisibles par programme)

 la grande nouveauté est la journalisation des objets :


    + *DTAARA | *DTAQ


    + la structure IFS (répertoires , fichiers stream et liens)


 la journalisation des data area et data queue se fait par
...........................................................................
:                    Démarrer journalisation objet (STRJRNOBJ)            :
:                                                                         :
: Indiquez vos choix, puis appuyez sur ENTREE.                            :
:                                                                         :
: Objet  . . . . . . . . . . . . .                 Nom                    :
:   Bibliothèque . . . . . . . . .     *LIBL       Nom, *LIBL, *CURLIB    :
:              + si autres valeurs                                        :
:                                      *LIBL                              :
: Type d'objet . . . . . . . . . .                 *DTAARA, *DTAQ         :
: Journal  . . . . . . . . . . . .                 Nom                    :
:   Bibliothèque . . . . . . . . .     *LIBL       Nom, *LIBL, *CURLIB    :
: Images . . . . . . . . . . . . .   *AFTER        *AFTER, *BOTH          :
:.........................................................................:

 seules les Data area peuvent être incluses dans une commande
   APYJRNCHG / RMVJRNCHG (code E).La journalisation des DTAQ est
   proposée dans un but de trace de l'activité.(code Q, type QS)


 la commande WRKJRNA a été modifiée afin d'afficher les objets journalisés
  par F19:
..........................................................................
:                             Objets journalisés                         :
:                                                                        :
:  Indiquez votre choix, puis appuyez sur ENTREE.                        :
:                                                                        :
:    Afficher . . .   1   1=Fichiers                                     :
:                         2=Chemins d'accès                              :
:                         3=Zones de données                             :
:                         4=Files d'attente de données                   :
:                         5=Objets du système de fichiers intégré        :
:                                                                        :
:                                                                        :
:  F12=Annuler                                                           :
:........................................................................:


    

  la journalisation de la structure IFS se fait par la commande STRJRN :


   on peut journaliser un répertoire ou un fichier (/ et /Qopensys seulement)


   si l'on journalise un répertoire, la journalisation peut avoir lieu
    pour les sous répertoires (SUBTREE)


   et enfin les objets qui seront crées dans ce répertoire peuvent être
    journalisés automatiquement (INHERIT)


  pour journaliser toute l'activité du répertoire /test :


  STRJRN OBJ('/test') JRN(/qsys.lib/mabib.lib/monjrn.jrn) SUBTREE(*YES)
         PATTERN('*') INHERIT(*YES)


  pour journaliser tous les fichiers .TXT de /test :


  STRJRN OBJ('/test') JRN(/qsys.lib/mabib.lib/monjrn.jrn) SUBTREE(*NO)
         PATTERN('*.TXT') INHERIT(*YES)




    

 le système journalise,


    pour un répertoire : les créations/suppressions de fichiers
                                                    de répertoires
                                                    de liens symboliques


    pour un fichier :    création/suppression
                         modification des attributs/des droits
                         modification du contenu




 le système utilise lui-même un cycle de validation pour certaines
  opérations sensibles (création d'un répertoire par ex.)


 il n'utilise pas, ne subit pas nos STRCMTCTL, ni COMMIT/ROLLBACK donc.


 l'utilisation de RMVJRNCHG est impossible, seule APYJRNCHG l'est.


 les actions sont toutes ré-exécutées (création de répertoires, de fichiers,
   les modications de contenu de fichiers stream sont refaites.)


    

journalisation d'un répertoire


...........................................................................
:                                Poste de journal                         :
:                                                                         :
: Objet  . . . . . . . :   /jrntest                                       :
: Données incomplètes  :   Non             Donn poste réduites  :   Non   :
: Séquence . . . . . . :   169                                            :
: Code . . . . . . . . :   B  - Système de fichiers intégré               :
: Type . . . . . . . . :   JT - Démarrage journalisation pour objet       :
:                                                                         :
:              Données spécifiques du poste                               :
: Colonne      *...+....1....+....2....+....3....+....4....+....5         :
:  00001      '0               ØcÓ¢   ¶0                   ¢     '        :
:  00051      '                          ù Ê > È Á Ë È'                   :
:.........................................................................:


 les sous répertoires seront effectivement journalisés,


  les fichiers IFS créés ensuite, le seront aussi.


    

 effet d'une mise à jour de fichier IFS (par EDTF)


...........................................................................
:                                 Poste de journal                        :
:                                                                         :
:  Objet  . . . . . . . :   /jrntest/sousrep/test.txt                     :
:  Données incomplètes  :   Non             Donn poste réduites  :   Non  :
:  Séquence . . . . . . :   315                                           :
:  Code . . . . . . . . :   B  - Système de fichiers intégré              :
:  Type . . . . . . . . :   WA - Ecriture, image-après                    :
:                                                                         :
:               Données spécifiques du poste                              :
:  Colonne      *...+....1....+....2....+....3....+....4....+....5        :
:   00001      '        ØcÓР "ó                                no'       :
:   00051      'uvelle ligne modifiée  '                                  :
:.........................................................................:


 la commande APYJRNCHG sera lancée sur ce fichier (après une mise à blanc)


  et le fichier retrouvera bien son contenu.


    

Nouveautés liées à la fonction journal en 5.20.


- le système attendait 10 minutes maxi la fin des transactions en cours
    lors d'un changement ou lors de la suppression d'un récepteur.


    MNGRCVDLY et DLTRCVLDY permettent de paramétrer (jusqu'à 1 jour)
     ce temps d'attente maximum supporté.


- nouveau format de sortie du DSPJRN  OUTPUT(*OUTFILE) OUTFILFMT(*TYPE5)
   qui montre, entre autre, les bras disque utilisés.


    ainsi que :   - des informations sur le thread
                  - le type d'adresse
                  - l'adresse IP
                  - le port IP


 Ces dernières informations ne sont disponibles que si vous le demander
  par CHGJRN FIXLENDTA( )


      on peut maintenant indiquer ce qui doit être stocké dans la
      partie fixe des postes de récepteur.

   ce paramètre est incompatible avec RCVSIZOPT(*MINFIXLEN) [ V5R10 ]


   FIXLENDTA:


             *JOBUSRPGM les informations JOB, profil et PGM en cours
                         sont stockées (comme avant)


             *JOB       les coordonnées du JOB sont stockée
             *USR       le nom du profil utilisateur est stocké
             *PGM       le nom du programme est stocké
             *PGMLIB    la bibliothèque du pgm et son ASP sont stockés
             *SYSSEQ    le N° de séquence système est stocké
             *RMTADR    l'adresse IP "remote" est stockée
             *THD       le n° du thread est stocké
             *LUW       l'unité logique de travail est stockée (2 phases)
             *XID       l'ID du thread (en hexa) est stocké.




 Ce paramètre accepte des entrées multiples et ne peut être renseigné
   que lors d'un changement de récepteur.


    

Exemple d'informations retournées suite à une mise à jour :


  DSPDTA (DFU) sur le fichier de sortie


..........................................................................
:SYSTEM SEQUENCE:       09656058842867188894                             :
:RECEIVER:              QSQJRN1027       RECEIVER LIBRARY: BDVIN1        :
:RECEIVER ASP DEVICE:   *SYSBAS          RCV ASP:              1         :
:ARM NUMBER:                1            THREAD ID:               %      :
:THREAD ID HEX:         000000000000006C ADDRESS FAMILY:   4             :
:REMOTE PORT:            1725                                            :
:REMOTE ADDRESS:        10.3.1.18                                        :
:LOGICAL UNIT OF WORK:                                                   :
:XID:                                                                    :
:........................................................................:


l'adresse IP (information importante pour la sécurité) est ici, renseignée
  avec l'adresse du pc sur lequel tourne l'émulateur 5250.


Elle sera aussi renseignée pour l'AUDIT Sécurité (QAUDIT)


    

- Lors d'un rollback sur un grand nombre de lignes, la phase de retour
  arrière (mise à jour inversée, puis déverrouillage) peut être longue.


 la commande WRKCMTDFN vous montre maintenant, l'état d'avancement.


  Faites F6 (ressources) et demander l'état du journal, puis F11
............................................................................
:                                 Etat journal                             :
:                                                          Système:   AS400:
:Travail:   PCXP           Utilisateur:   AF400CM        Numéro:   061418  :
:                                                                          :
:Définition de validation . . . . . . . :   *DFTACTGRP                     :
:                                                                          :
:Indiquez vos options, puis appuyez sur ENTREE.                            :
:  5=Afficher postes cycle validation   6=Afficher tous les postes         :
:  7=Gérer les attributs de journal                                        :
:                                                                          :
:                             --------Invalidation---------                :
:Opt  Journal     Biblio      Date      Heure     % exécuté                :
:     QSQJRN      BDVIN1                           10                      :
:..........................................................................:

un deuxième F11 (Afficher état déverrouillage)


............................................................................
:                                 Etat journal                             :
:                                                          Système:   AS400:
:Travail:   PCXP           Utilisateur:   AF400CM        Numéro:   061418  :
:                                                                          :
:Définition de validation . . . . . . . :   *DFTACTGRP                     :
:                                                                          :
:Indiquez vos options, puis appuyez sur ENTREE.                            :
:  5=Afficher postes cycle validation   6=Afficher tous les postes         :
:  7=Gérer les attributs de journal                                        :
:                                                                          :
:                                                                          :
:                             -------Déverrouillage--------                :
:Opt  Journal     Biblio      Date      Heure     % exécuté                :
:     QSQJRN      BDVIN1                            0                      :
:..........................................................................:




 SMAPP, lui aussi vous montre plus d'informations.

Déja, la valeur de reprise (temps maxi de rétablissement souhaité)
 était fixée à l'origine à 150 Minutes, puis 120 en 4.40 et 90 en 5.10.


la V5R20 propose comme valeur par défaut 70 Minutes ! (cf EDTRCYAP)


l'écran affiché par DSPRCYAP, montre les index écartés et les raisons.


 F14, liste des index journalisés


 F13, liste des index non journalisés et pourquoi.


    > FRCACCPTH(*YES)       le PF possède le paramètre "écriture forcée"


    > journaux multiples    la transaction implique plusieurs journaux


    > JRNSTATE(*STANDBY)    le journal est mis à l'état *STANDBY
...........................................................................
: Il s'agit d'un journal ou la journalisation est "prête" mais non        :
:  effective (système de BACKUP), cette option et l'option JRNCACHE(*YES) :
:  implique l'installation de 5722SS1 option 42, dispo facturable.        :
:.........................................................................:

 Journalisation automatique 


 S'il existe un journal nommé QSQJRN dans votre bibliothèque, la création,
   PAR SQL uniquement (CREATE TABLE), d'un fichier physique inclus sa
   journalisation, automatiquement.


 Depuis la V5R30 , SQL cherche aussi une Data Area :


   Quand on créé une table, s'il existe une data area QDFTJRN contenant
     les coordonnées d'un journal, la table est automatiquement journalisée


   structure de la Data Area:    1-10 : nom  de la bibliothèque
                                11-20 : nom du journal
                                21-30 : *FILE -> journalisation automatique
                                        *NONE -> pas de journalisaiton


 Cette data area a été modifiée,en V5R40 ,comme suit :


       elle peux faire maintenant jusqu'à 1980c


       elle contient (à partir de 21) des couples de  20c, type/opération

   -type admet les valeurs :  *FILE      pour les fichiers (PF)
                              *DTAARA     "   les data area
                              *DTAQ       "   les dtaq
                              *ALL        "   les 3 types précédents


   -opération   "     "    :  *CREATE         journalisation lors de CRTPF
                              *MOVE                 "        lors de MOVOBJ
                              *RESTORE              "        lors de RSTOBJ
                              *ALLOPR         pour les 3 opérations
 par exemple :
         1         2         3         4         5         6         7
....*....0....*....0....*....0....*....0....*....0....*....0....*....0....*
BIBJRN   MONJOURNAL *FILE     *ALLOPR   *DTAARA   *CREATE


 journalisation des fichiers dans tous les cas,des DTAARA lors des créations


V6R10 :
------
  la journalisation peut se faire pour une bibliothèque entière par
    STRJRNLIB, cela remplace la Dataarea QDFTJRN et n'impose plus de droits
    sur le journal au créateur du fichier

 EN V7, La commande STRJRNLIB admet de nouveaux paramètres :


   Filtre de journalisation, incluant la journalisation "remote"
    automatique ou non (CHGJRNOBJ pour modifier), par INHRULES


    Règles d'héritage:    INHRULES 
    Type d'objet . . . . . . . . . *ALL        *FILE, *DTAARA , *DTAQ
    Opération  . . . . . . . . . . *ALLOPR     *CREATE, *MOVE, *RESTORE
    Action associée à la règle . . *INCLUDE    *INCLUDE , *OMIT
    Images . . . . . . . . . . . . *OBJDFT     *AFTER, *BOTH
    Omettre poste de journal . . . *OBJDFT     *NONE, *OPNCLO
    Filtre de journaux éloignés  . *OBJDFT     *NO , *YES
    Filtre de noms . . . . . . . . *ALL        *ALL ou un nom générique


 par exemple


   STRJRNLIB LIB(BDVIN1) JRN(BDVIN1/QSQJRN) INHRULES((*ALL)
   (*FILE *ALLOPR *OMIT *OBJDFT *OBJDFT *OBJDFT Q*))


   journalise tous les objets (le premier *ALL), sauf les fichiers dont le
    nom commence par Q (deuxième ligne)

 Pour revoir ensuite ces paramètres utilisez DSPLIBD
 F10=Affichage des règles d'héritage :


                         Affichage des règles d'héritage


  Bibliothèque . . . . . :   BDVIN1        Type . . . . . . . . . :   PROD




  Type        Filtre       Opérations   Action      Images      Postes
  objet       noms        journalisées  règle       journal     omis
  *ALL        *ALL         *ALLOPR      *INCLUDE    *OBJDFT     *OBJDFT
  *FILE       Q*           *ALLOPR      *OMIT       *OBJDFT     *OBJDFT


 F11=Afficher filtre journal éloigné, affiche :


 Bibliothèque . . . . . :   BDVIN1        Type . . . . . . . . . :   PROD


                                                               Filtre
 Type        Filtre       Opérations   Action      Images      journal
 objet       noms        journalisées  règle       journal     éloigné
 *ALL        *ALL         *ALLOPR      *INCLUDE    *OBJDFT     *OBJDFT
 *FILE       Q*           *ALLOPR      *OMIT       *OBJDFT     *OBJDFT

 Autre nouveautés V7

Le nouveau paramètre de la V7 DFRID permet de restaurer un physique APRES le(les) logiques ou Tables matérialisées (MQT).

Ceci est une fonction de base de la V7

Le level 26 des PTF Database permet d'appliquer ce mode fonctionnement (évitant une double restauration) aux journaux :

Il est possible désormais de restaurer des fichiers, des DataArea et des DTAQ, puis de restaurer le journal (objets dans BIBA, journal dans BIBJ)

les objets sont automatiquement journalisés dès que le journal est restauré.

Comme avec les logiques

• Soit vous utilisez le même DFRID sur les commandes de restauration (RSTLIB, RSTOBJ, RST)
• Soit vous utilisez la commande RSTDFROBJ

et en 7.2 Le paramètre STRJRN sur les commandes RSTOBJ / RSTLIB est nouveau

• *YES
  La journalisation est démarrée pour les nouveaux objets qui étaient journalisés lors de leur sauvegarde.
  
  
• *NO
  La journalisation n'est pas démarrée pour les objets qui sont restaurés.

 Journalisation et Intégrité référentielle 


 Si vous appliquez une règle d'intégrité référentielle entre deux fichiers
  (par exemple le client doit exister pour pouvoir saisir des commandes)
  vous devez indiquer la règle en cas de mise à jour (changement de clé)
  et en cas de suppression, sur le fichier parent (le fichier client) .


     ADDPFCST    FILE(commandes)
                 TYPE(*REFCST)
                 CST(FK_CLIENTS_COMMANDES)
                 KEY(numcli)       <- zone du fichier commande
                 PRNFILE(clients)  <- fichier parent
           -->   UPDRULE(*NOACTION)
           -->   DLTRULE(*CASCADE)


  UPDRULE :  *NOACTION  contrôle lors du COMMIT, c'est la valeur par défaut.


             *RESTRICT  contrôle immédiat (avant de faire)


  DLTRULE : les mêmes +  *CASCADE  , *SETNULL , *SETDFT

 Avec toute valeur autre que *RESTRICT , la journalisation est obligatoire.


   dans le cas contraire: - l'intégrité sera établie (ADDPFCST fonctionne).


                          - MAIS toutes vos demandes d'ouverture de fichier
                             seront refusées (erreur d' E/S).
 Exemple avec SQL :


  create table clients
   (nocli dec(6, 0) as identity PRIMARY KEY ,
    nomcli char(50) , depcli numeric(2, 0))


  Create table commandes
   (nocde dec(6, 0) as identity  PRIMARY KEY ,
    nocli dec(6 , 0) references clients ON DELETE CASCADE , (NOACTION/dft)
     qtecde dec(7 , 2) , pricde dec(7 , 2))


  create table livraisons
  (noliv DEC(6 , 0) as identity PRIMARY KEY,
   NOCDE dec(6 , 0) references commandes ON DELETE CASCADE ,
   qteliv dec(7 , 2)   ,  datliv date)  , ETC...

  Si la table livraisons n'est pas journalisée, un ordre DELETE sur clients
   provoque SQL7008, code raison 3: "Table CLIENTS non journalisée"
   (ce qui n'est pas forcement trés clair) avec CPF523C dans la JOBLOG.




   il est difficile de définir une contrainte d'intégrité référentielle
     entre deux fichiers journalisés par des journaux différents.
     (cas de deux collections SQL)




   la doc indique que c'est impossible si vous indiquez une règle à une
    autre valeur que *RESTRICT.


   en fait DB2 vous laisse faire, mais la suppression s'avère physiquement
    impossible avec une règle de suppresion *CASCADE par exemple.
     (erreur d'E/S, sous SQL SQL7008)


   on constate aussi que si vous travaillez en transaction (STRCMTCTL)
    il faut avoir validé l'insertion de l'enregistrement père avant
    de pouvoir insérer le fils, bref c'est bien compliqué !

La commande DSPJRN permet d'obtenir des infos sur le contenu d'un récepteur.


                           Afficher un journal (DSPJRN)         


  Indiquez vos choix, puis appuyez sur Entrée. 


  Journal  . . . . . . . . . . . . JRN             CMDJRN     
    Bibliothèque . . . . . . . . .                  TP         
  Fichier physique journalisé:     FILE           
    Fichier  . . . . . . . . . . .                *ALLFILE   
      Bibliothèque . . . . . . . .                             
    Membre . . . . . . . . . . . .                           
                          + si autres valeurs     
  Plage de récepteurs de journal:  RCVRNG         
    Début au récepteur de journal                 *CURRENT   
      Bibliothèque . . . . . . . .                             
    Fin au récepteur de journal  .                           
      Bibliothèque . . . . . . . .                             
  Numéro de séquence de début  . . FROMENT        *FIRST      
  Date et heure de début:          FROMTIME       
    Date de début  . . . . . . . .                         
    Heure de début . . . . . . . .                         
                                                                   A suivre... 

                           Afficher un journal (DSPJRN)         


  Indiquez vos choix, puis appuyez sur Entrée. 


  Numéro de séquence de fin  . . . TOENT          *LAST       
  Date et heure de fin:            TOTIME         
    Date de fin  . . . . . . . . .                         
    Heure de fin . . . . . . . . .                         
  Nombre de postes de journal  . . NBRENT         *ALL        
  Codes journal  . . . . . . . . . JRNCDE         *ALL 
                          + si autres valeurs          
  Types de postes de journal . . . ENTTYP         *ALL 
                          + si autres valeurs          
  Travail  . . . . . . . . . . . . JOB            *ALL       
    Utilisateur  . . . . . . . . .                             
    Numéro . . . . . . . . . . . .                         
  Programme  . . . . . . . . . . . PGM            *ALL       
  ID cycle de validation . . . . . CMTCYCID       *ALL        
  Longueur donnée du poste . . . . ENTDTALEN      100    
  Format de sortie . . . . . . . . OUTFMT         *CHAR 
  Sortie . . . . . . . . . . . . . OUTPUT         *        <-*PRINT/*OUTFILE

                               Postes du journal                
 Journal  . . . . . . :   CMDJRN          Bibliothèque . . . . :   TP         


 Indiquez vos options, puis appuyez sur ENTREE.          
   5=Afficher le poste complet                             


 ######################################################################### 
 Opt    Séquence  Code  Type  Objet       Biblio      Travail     Heure    
             304   C     SC                           DSP36       14:39:23 
             305   R     PT   LCDEF       TP          DSP36       14:39:23 
             306   C     CM                           DSP36       14:39:23 
             307   C     SC                           DSP36       14:39:46 
  5          309   R     UB   LCDEF       TP          DSP36       14:39:46 
             310   R     UP   LCDEF       TP          DSP36       14:39:46 
             311   C     CM                           DSP36       14:39:46 
             312   C     SC                           DSP36       14:40:12 
             314   R     UB   LCDEF       TP          DSP36       14:40:12 
             315   R     UP   LCDEF       TP          DSP36       14:40:12 
             316   C     CM                           DSP36       14:40:12 
             317   C     SC                           DSP36       14:40:21    + 


 F3=Exit   F12=Annuler                                    

                            Poste complet du journal            
 Journal  . . . . . . :   CMDJRN          Bibliothèque . . . . :   TP         


 Séquence . . . . . . :          309 
 Code . . . . . . . . :   R  - Opération sur enregistrement spécifique       
 Type . . . . . . . . :   UB - Mise à jour, image avant                      


 Objet  . . . . . . . :   LCDEF           Bibliothèque . . . . :   TP         
 Membre . . . . . . . :   LCDEF           Indicateur . . . . . :   1 
 Date . . . . . . . . :   xx/xx/xx        Heure  . . . . . . . :   14:39:46 
 Nombre/Rang  . . . . :           50      Programme  . . . . . :   CMDFOUR2   


 Travail  . . . . . . . . . . . . . :   121673/QSECOFR/DSP36         
 ID du cycle de validation  . . . . :          307 
 Données du poste . . . . . . . . . : 
             *...+..1......+....2....+....3....+....4....+....5 
            '    ^ Ģ&    ? r A3           - '                    




 Appuyez sur ENTREE pour continuer.                                           
 F3=Exit                  F11=Format hexadécimal                              
 F12=Annuler              F14=Poste précédent                                 

                            Poste complet du journal            
 Journal  . . . . . . :   CMDJRN          Bibliothèque . . . . :   TP         


 Séquence . . . . . . :          309 
 Code . . . . . . . . :   R  - Opération sur enregistrement spécifique       
 Type . . . . . . . . :   UB - Mise à jour, image avant                      


 Objet  . . . . . . . :   LCDEF           Bibliothèque . . . . :   TP         
 Membre . . . . . . . :   LCDEF           Indicateur . . . . . :   1 
 Date . . . . . . . . :   xx/xx/xx        Heure  . . . . . . . :   14:39:46 
 Nombre/Rang  . . . . :           50      Programme  . . . . . :   CMDFOUR2   


 Travail  . . . . . . . . . . . . . :   121673/QSECOFR/DSP36         
 ID du cycle de validation  . . . . :          307 
 Données du poste . . . . . . . . . : 
             * . . . + . . . . 1 . . . . + . . . . 2 . . . . +  
            '15163F015F0078500F010F006F01990FC1F340404040404040' 
            '40000003600F'                                       
                                                                              # 
 Appuyez sur ENTREE pour continuer.                                           
 F3=Exit                  F11=Format alphanumérique                           
 F12=Annuler              F14=Poste précédent                                 

 Pour voir les entrées spécifiques à une période


  -> utilisez les paramètres FROMTIME() / TOTIME()


     pensez à mettre les bons récepteurs ou *CURCHAIN dans RCVRNG()




 Pour voir les entrées spécifiques à un fichier


  -> renseignez le paramètre FILE sur la commande DSPJRN




  1/ si le fichier n'existe pas précisez bibliothèque, fichier ET membre


      le système "scan" le (les) récepteur(s) pour trouver vos entrées


  2/ si le fichier existe, le système lui attribut un ID unique


      cet identifiant est récupéré dans le fichier existant,
        seules les entrées correspondant à cette version du fichier
        sont affichées (même niveau de format, même date de création, ...)

     Pour voir les entrées correspondant à une autre "version"


     -récupérez l'identifiant avec un DSPJRN sans le paramètre FILE


 DSPJRN, 5 sur le poste concerné, F10


                         Détails d'un poste de journal 


 Journal  . . . . . . :   QSQJRN          Bibliothèque . . . . :   BDVIN2


 Séquence . . . . . . :   75178
 Code . . . . . . . . :   R  - Opération sur enregistrement spécifique
 Type . . . . . . . . :   UB - Mise à jour, image avant


 ID journal . . . . . :   X'18400024D2AD02B10063' <-


     -utilisez la valeur trouvée (héxa) dans le paramètre OBJID


 DSPJRN JRN(BDVIN2/QSQJRN) RCVRNG(*CURCHAIN) ENTTYP(UB)
        OBJJID(X'18400024D2AD02B10063')


    

      LISTE DES ZONES DU FICHIER PHYSIQUE CREE PAR DSPJRN *OUTFILE


 Nom          Nom         Nom      Nom
Fichier      Biblio.     Format    Zone     Lg.  Décim.  Texte descriptif
OUTJRN       QGPL        QJORDJE   JOENTL     5   0      Longueur du poste
  "             "           "      JOSEQN    10   0      N° de séquence
  "             "           "      JOCODE     1          Code journal
  "             "           "      JOENTT     2          Type du poste
  "             "           "      JODATE     6          Date du poste
  "             "           "      JOTIME     6   0      Heure du poste
  "             "           "      JOJOB     10          Nom du travail
  "             "           "      JOUSER    10          Utilisateur
  "             "           "      JONBR      6   0      N° du travail
  "             "           "      JOPGM     10          Nom du programme
  "             "           "      JOOBJ     10          Nom de l'objet
  "             "           "      JOLIB     10          Bibliothèque
  "             "           "      JOMBR     10          Nom du membre
  "             "           "      JOCTRR    10   0      Rang de l'enreg.mod
  "             "           "      JOFLAG     1          Flag:0 ou 1
  "             "           "      JOCCID    10   0      Id cycle commit
  "             "           "      JORES      8          non utilisé
  "             "           "      JOESD    100          Données du poste

 +------------------------------------------------------------------------+
 |                    Principaux codes journaux                           |
 +------------------------------------------------------------------------+
 |          |                                                             |
 |   A      |   Accounting (comptabilité système)                         |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |   B      |   Système de fichier intégré , IFS.                         |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |   C      |   Commitment Control                                        |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |   D      |   Opération sur un fichier base de données (Create Table...)|
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |   E      |   Opération sur une Data Area                               |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |   F      |   Opération sur un membre                                   |
 +----------+-------------------------------------------------------------+

 +------------------------------------------------------------------------+
 |          |                                                             |
 |   I      |   Opération interne                                         |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |   J      |   Action sur un journal ou un récepteur                     |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |   L      |   Gestion de licence                                        |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |   M      |   Gestion de réseau (TCP/IP & SNMP)                         |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |   O      |   Opération sur un objet (non implémenté aujourd'hui)       |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |   Q      |   Opération sur une Data Queue                              |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |   R      |   Opération sur un enregsitrement base de données           |
 +----------+-------------------------------------------------------------+

 +------------------------------------------------------------------------+
 |          | Pour le CODE R les principaux types sont :                  |
 |          | ------------------------------------------                  |
 |          | BR - Image avant d'un enregistrement suite à une opération  |
 |          |       d'annulation                                          |
 |          | DL - Enregistrement supprimé d'un membre de fichier physique|
 |          | DR - Enregistrement supprimé pour effectuer une opération de|
 |          |       remise à l'état initial                               |
 |          | IL - Incrémentation de limite d'enregistrement              |
 |          | PT - Enregistrement ajouté à un membre de fichier physique  |
 |          | PX - Enregistrement ajouté directement à un membre          |
 |          | UB - Image avant d'un enregistrement mis à jour dans un mbr |
 |          | UP - Image après d'un enregistrement mis à jour dans un mbr |
 |          | UR - Image après d'un enregistrement suite à une opération  |
 |          |       d'annulation                                          |
 +------------------------------------------------------------------------+
 |   S      |   Mail serveur Framework (MSF & SMTP)                       |
 +----------+-------------------------------------------------------------+
 |   T      |   Audit système                                             |
 +----------+-------------------------------------------------------------+
 |   U      |   Entrée Utilisateur (SNDJRNE)                              |
 +----------+-------------------------------------------------------------+

 REPRISE.  En cas de problème, (scratch disque)


 (récupérer journal et récepteur par RCLSTG, s'ils sont dans un ASP)


 Restaurer journal et récepteur EN PREMIER.
                                                                                
 De façon à ce que les fichier soient automatiquement re-journalisés
  à la restauration.                                                            
 (il est d'ailleur recommandé de créer une bibliothèque à part pour tout        
   ce qui touche à la fonction journal, ce qui vous autorisera RSTLIB)          
                                                                              # 
 Puis,vos DATA par       Restaurer bibliothèque (RSTLIB)       


 Indiquez vos choix, puis appuyez sur ENTREE. 


 Biblio des objets sauvegardés  . SAVLIB          fichiers   
 Unité  . . . . . . . . . . . . . DEV             ########## 
                         + si autres valeurs                


 F3=Exit   F4=Invite   F5=Réafficher   F10=Autres paramètres   F12=Annuler
 F13=Mode d'emploi invite              F24=Autres touches                       

  Et,               Appliquer modifs journalisées (APYJRNCHG)  


 Indiquez vos choix, puis appuyez sur ENTREE. 


 Journal  . . . . . . . . . . . . JRN             CMDJRN     
   Bibliothèque . . . . . . . . .                  *LIBL      
 Fichier physique journalisé:     FILE           
   Fichier physique journalisé  .                 *ALL       
     Bibliothèque . . . . . . . .                  *LIBL      
   Membre . . . . . . . . . . . .                *FIRST     
                         + si autres valeurs     
 Plage de récepteurs de journal:  RCVRNG         
   Début au récepteur de journal                 *LASTSAVE  
     Bibliothèque . . . . . . . .                             
   Fin au récepteur de journal  .                           
     Bibliothèque . . . . . . . .                             
 Numéro de séquence de début  . . FROMENT         *LASTSAVE   
 Numéro de séquence de fin  . . . TOENT           *LASTRST    
                                                  ######## 
                                                                    A suivre... 
 F3=Exit   F4=Invite   F5=Réafficher   F12=Annuler   F13=Mode d'emploi invite
 F24=Autres touches                                                             

                    Appliquer modifs journalisées (APYJRNCHG)  


 Indiquez vos choix, puis appuyez sur ENTREE. 


 Date et heure de fin:            TOTIME         
   Date de fin  . . . . . . . . .                         
   Heure de fin . . . . . . . . .                         
 Nom de travail qualifié  . . . . TOJOBO                    
   Utilisateur  . . . . . . . . .                             
   Numéro . . . . . . . . . . . .                         
 Nom de travail qualifié  . . . . TOJOBC                    
   Utilisateur  . . . . . . . . .                             
   Numéro . . . . . . . . . . . .                         
 Frontière de validation  . . . . CMTBDY         *YES 




     remarquez TOJOBO/TOJOBC : jusqu'à ouverture/fermeture par un JOB


               CMTBDY : tenir compte des frontières de validation
                                                                            Fin 
 F3=Exit   F4=Invite   F5=Réafficher   F12=Annuler   F13=Mode d'emploi invite
 F24=Autres touches                                                             

  SI vous souhaitez revenir en arrière, Vous utiliserez la commande


     RMVJRNCHG. 




  ATTENTION, . à la cohérence de l'ensemble.


             . vos fichiers doivent être journalisés, images avant et après


             . il est conseillé de définir le premier n° de séquence
                                           (le plus récent)
                                           et le dernier (le plus ancien)


                 préalablement avec la commande DSPJRN.


             . il n'est PAS POSSIBLE de faire une sélection des modifs


               à annuler, hormis le début et la fin de recouvrement arrière.  

                     Enlever modifs journalisées (RMVJRNCHG)   


 Indiquez vos choix, puis appuyez sur ENTREE. 


 Journal  . . . . . . . . . . . . JRN             CMDJRN     
   Bibliothèque . . . . . . . . .                  *LIBL      
 Nom du fichier journalisé:       FILE           
   Fichier physique journalisé  .                   ? ? ?    
     Bibliothèque . . . . . . . .                  *LIBL      
   Membre . . . . . . . . . . . .                *FIRST     
                         + si autres valeurs   +  <------ 
 Plage de récepteurs de journal:  RCVRNG         
   Début au récepteur de journal                 *CURRENT   
     Bibliothèque . . . . . . . .                             
   Fin au récepteur de journal  .                           
     Bibliothèque . . . . . . . .                             
 Numéro de séquence de début  . . FROMENT        *LAST           <------  
 Numéro de séquence de fin  . . . TOENT          *FIRST          <------ 
                                                  ########## 
                                                                    A suivre... 
 F3=Exit   F4=Invite   F5=Réafficher   F12=Annuler   F13=Mode d'emploi invite
 F24=Autres touches                                                             

                     Enlever modifs journalisées (RMVJRNCHG)   


 Indiquez vos choix, puis appuyez sur ENTREE. 


 Nom de travail qualifié  . . . . TOJOBO                    
   Utilisateur  . . . . . . . . .                             
   Numéro . . . . . . . . . . . .                         
 Frontière de validation  . . . . CMTBDY         *YES 










       (mêmes remarques)










                                                                            Fin 
 F3=Exit   F4=Invite   F5=Réafficher   F12=Annuler   F13=Mode d'emploi invite
 F24=Autres touches                                                             

 Autres commandes liées à la fonction journal :


  WRKJRN     pour voir les journaux de votre système


  WRKJRNA    pour voir les attributs d'un journal :


                F13 vous affiche les fichiers journalisés
                F14 vous affiche les index journalisés
                F15 vous affiche la chaine des récepteurs


  CMPJRNIMG, pour imprimer les enregistrements modifiés
             (les images avant/après sont imprimées l'une sous l'autre)


  RTVJRNE    pour lire le contenu d'un journal en CL


  RCVJRNE    pour recevoir en temps réel les postes du journal


  ENDJRNPF ,
  DLTJRN   ,
  DLTJRNRCV, pour défaire...

La fonction journal permet de gérer des cycles de validation
 dans vos programmes


Il s'agit d'atomiser un groupe d'actions sur la base de données


C'est à dire de faire en sorte que ce groupe d'actions soit réalisé
  EN TOTALITE ou pas du tout.


Les fichiers concernés doivent être journalisés (et tous par le même journal)


Vous allez démarrer le contrôle de validation par la commande CL


     STRCMTCTL


      puis appeler le pgm RPG ou COBOL


           celui-ci doit déclarer la liste des fichiers qui sont sous
            contrôle de validation (syntaxe dépendante du langage)


     vous terminez par ENDCMTCTL


    

    En RPG3 , une specif F de continuation par fichier


     FPRODUIT UF  E           K        DISK
     F                                              KCOMIT




    En RPG4 , une specif F avec le mot-clé COMMIT


     FPRODUIT   UF   E           K DISK    COMMIT


     le mot-clé COMMIT du RPG4 admet en argument une variable de type
      indicateur (N) qui rend le travail sous commitment control
      dépendant du fait que cet indicateur soit vrai (*ON ou '1')


    en COBOL 


    FILE-CONTROL.
         SELECT PRODUIT ASSIGN TO ...
    I-O-CONTROL.
         COMMITMENT CONTROL FOR PRODUIT. (liste de fichiers possible)


    

     Puis votre programme va réaliser un certain nombre d'actions sur
      la base de données (ajout, mises à jour, etc ...)


 Ces actions SONT répercutées dans les fichiers , MAIS :


   TOUS les enregistrements manipulés restent verrouillés


   Ces modifications sont en instance (non définitives)




 Elles peuvent être validées en fin de transaction


  C'est vous qui déterminez ce qu'est une transaction, suivant l'endroit
   où vous placez l'ordre de validation, la fréquence.


   COMIT en RPG, COMMIT en RPG4 et COBOL


 Le système admet 500.000.000 lignes à l'intérieur d'UNE transaction,
  mais toute transaction dépassant 2000 lignes va probablement avoir
  un impact assez lourd sur les performances.


    

 Elles peuvent être invalidées (idem recouvrement arrière [RMVJRNCHG],
              mais uniquement sur les actions réalisées par votre programme)


 MISES à jour défaites, ajouts retirés, enregistrements supprimés ré-écrits,.


  ROLBK en RPG (3 ET 4) , ROLLBACK en COBOL.




 Les mêmes ordres peuvent être demandés en CL


 Cdes COMMIT et ROLLBACK (en cas de plantage du pgm RPG, par ex)




LE SYSTEME ASSURE QU'EN CAS DE FIN ANORMALE (du job, du système, ...)


   IL EXECUTERA UN ROLLBACK IMPLICITE




   A l'IPL suivant s'il le faut.




    

 Options du STRCMTCTL 


            LCKLVL : *CHG  tous les enregistrements modifiés,ajoutés
                            sont verrouillés
                           (pas les enregistrements lus)


                     *CS   = idem *CHG plus verrouillage des enregistrements
                              lus (un au maxi = une lecture déverrouille le
                                   précédent)


                     *ALL  = idem *CHG plus verrouillage de TOUS les
                              enregistrements lus jusqu'à COMMIT/ROLLBACK.


            NFYOBJ   *NONE ou un nom


                     en RPG vous pouvez lors d'un COMMIT demander au système
                      de mémoriser des informations (Facteur 1 du COMMIT)


                     en cas de fin anormale, ces informations seront écrites
                      dans l'objet de notification afin que votre programme
                      puisse proposer une reprise.

   Vous devez alors indiquer - un nom d'objet


                             - un type (*MSGQ, *DTAARA, *FILE)


                             - ainsi qu'un nom de membre si *FILE




  Le plus simple est probablement la notion de fichier qui sera lu en
   entrée par le pgm, s'il contient des informations, c'est que la dernière
   transaction ne s'est pas terminée normalement.


   Il faut probablement mémoriser dans le fichier l'utilisateur (voire le
    terminal) et lire le fichier par clé en début de programme.


  Vous pouvez alors tenter de proposer une reprise avec les données
   utiles stockées dans le fichier.




  la suppression de l'enregistrement dans le fichier de notification est
    à votre charge ==> pensez-y !


    

 Contrôle de validation et intégrité référentielle 




 Dans la cadre d'une intégrité référentielle, si l'une de deux règles en
  cas de mise à jour ou de suppression n'est pas à *RESTRICT (vérification
  avant de faire), le contrôle de validation doit être actif.




    s'il ne l'est pas, le système démarre un contrôle de validation
     nommé "QDBCMTDFN" (passez WRKCMTDFN pour le voir)


 Contrôle de validation et groupes d'activation 


  Un certain nombre de paramètres systèmes concernant la gestion de fichier
   peuvent maintenant être liés à la notion de groupe d'activation.


  On parle de champ d'application ou de portée, pour indiquer si un
   paramètre est valide pour l'ensemble du job ou uniquement pour les pgms
   d'un groupe d'activation (celui dans lequel se trouve le pgm ayant passé
   la commande)


    

A/ la portée d'une substitution avec OVRDBF OVRSCOPE( )


B/ la portée d'une ouverture avec OPNSCOPE( ) [cdes OVRDBF,OPNDBF,OPNQRYF]


C/ et enfin, le contrôle de validation est lancé pour le groupe d'activation
  en cours, ou bien pour l'ensemble du job.


  STRCMTCTL CMTSCOPE        *ACTGRP : lancé pour le groupe d'activation


                            *JOB    : lancé pour le job.


  la valeur par défaut (*ACTGRP) permet d'avoir plusieurs transactions
   en cours, en même temps, portant sur des fichiers différents.


  Donc, de valider au sein d'une application, une transaction en cours
   (COMMIT), ou bien de l'invalider, sans que cela n'ait de répercussion
   sur les autres applications (autres groupes d'activation).


  Pour gérer tous les contrôles de validation actifs, la nouvelle
   commande : WRKCMTDFN est utile.


    

                     Gestion des définitions de validation 
                                                            Système:   AS400
 Indiquez vos options, puis appuyez sur ENTREE.
   5=Afficher état   12=Gérer travail   14=Validation forcée
   16=Invalidation forcée ...


      Définition                                  Unité     Resync en
 Opt  validation  Travail     Util        Numéro  exécut      cours
      *DFTACTGRP  DSPO4       QPGMR       091010  *NONE     NON
      QDBCMTDFN   DSP04       QPGMR       091010  *NONE     NON


 La colonne Définition de validation peut afficher les valeurs suivantes :


 *DFTACTGRP ou un nom de groupe d'activation (DSPJOB / opt 18 pour le voir)


 *JOB s'il s'agit un contrôle de validation lancé au niveau JOB


 un nom commencant par Q pour un contrôle de validation lancé par le système


 *TNSOBJ pour un contrôle de validation lié à une transaction (Api XA/Xopen)


 nb : vous pouvez aussi utiliser Iseries Navigator pour voir tout cela.

 Ajouter une ressource par API  


 Il faut définir une ressource sous contrôle de validation en lui associant
    un paramètre de 80 c. et un pgm d'exit.


 A chaque action du control de validation (commit ou rollback) le pgm d'exit
  sera appellé et recevra les 80 c. (entre autre)


  Ajouter une ressource :    QTNADDCR 


                            - BIN(4,0) zone de retour (à utiliser en fin
                                                          avec QNTRMVCR)
                            - CHAR(10) nom de la ressource


                            - CHAR(20) nom qualifié du pgm d'exit


                            - CHAR(80) informations à envoyer au pgm d'exit


                            - CHAR(1)  appel du pgm à l'IPL (O ou N)


                            - CHAR(??) code erreur

   Le pgm d'exit reçoit deux paramètres


   1/ les informations liées à la ressource (80 c.)


   2/ une structure composée comme suit:


      1 à  4 BIN(4)  lg des infos (toujours 32)


      5 à  5 CHAR(1) commit (C) ou rollback (R)


      6 à  6 CHAR(1) Appel lors de l'IPL (O ou N)


      7 à 10 CHAR(4) réservé


     11 à 11 CHAR(1) état du processus (job) lors de l'appel


                     '0' processus n'est PAS en phase de fin
                     '1' processus en phase de fin NORMALE
                     '2' processus en phase de fin ANORMALE


     12 à 31 CHAR(20) réservé

  Enlever une ressource :  QTNRMVCR 


                          - BIN(4,0) zone de retour reçue de QTNADDCR


                          - CHAR(??) code erreur


  Modifier options du contrôle de validation


                           QTNCHGCO  


                          - CHAR(??) infos à modifier


                            BIN(4)   lg des infos à modifier


                            infos à modifier sous forme de flags CHAR(1)
                            principalement liées au "two phases commit"


                          - CHAR(??) code erreur






    

  Informations sur le contrôle de validation
                           QTNRCMTI 


                          - CHAR(??) variable en retour (format CMTI0100)


                              1 à 4 BIN(4,0) octets renvoyés
                              5 à 8 BIN(4,0) octets valides
                              9 à 9 CHAR(1)  status I=inactif,L=actif(local)
                                                    R=actif(remote),
                                                    A=actif sans ressources
                             10  19 CHAR(10) verrouillage
                             20  20 portée du contrôle de validation
                                                    A = groupe d'activation
                                                    J = JOB
                             > plus les options modifiables par QTNCHGCO


                          - BIN(4,0) lg de la variable en retour


                          - CHAR(8)  format = CMTI0100


                          - CHAR(??) code erreur

 Programme trigger et contrôle de validation : 


            FONCTIONNEMENT HORS CONTROLE DE VALIDATION 


 Si le programme applicatif et le programme trigger ne s'exécutent pas
  sous contrôle de validation, toute erreur du programme trigger laissera
  les fichiers dans l'état au moment de l'erreur.




            FONCTIONNEMENT SOUS CONTROLE DE VALIDATION 


 Si le programme applicatif seul s'exécute sous contrôle de validation,
  l'opération COMMIT du programme applicatif s'applique uniquement à ses
  propres modifications.




 Si le programme trigger seul s'exécute sous contrôle de validation, les
  modifications effectuées par le programme trigger sont validées quand :


      - le groupe d'activation se termine (COMMIT implicite)
      - une opération de COMMIT est demandée par le programme

 Si le programme applicatif et le programme trigger s'exécutent sous le
  même contrôle de validation, un arrêt anormal du programme trigger
  entraînera le Rollback de toutes les opérations qui lui sont associées.


 Un Rollback est également effectué sur l'opération de modification
  d'origine. Ceci nécessite que le programme trigger envoie un message
  d'exception quand l'erreur est détectée.


 Les deux programmes sont alors fortement couplés  , c'est la solution pour
  un trigger chargé de détecter des erreurs pouvant annuler l'action B de D.




 Si le programme applicatif et le programme trigger s'exécutent sous des
  contrôles de validation différents, l'opération COMMIT du programme
  applicatif n'agit que sur son propre contrôle de validation.


 La validation des modifications du programme trigger doit être effectuée
  de façon distincte.


 les deux programmes sont faiblement couplés, c'est la solution pour un
  trigger chargé de répercuté des actions (dans un autre fichier)

 SQL et COMMIT/ROLLBACK 


  si vous réalisez vos Entrées/Sorties par SQL :


  1/ vous ne passez plus la commande STRCMTCTL, mais renseignez le paramètre

       COMMIT :
                > sur la commande STRSQL ou par F13 ensuite.
                > lors de la compilation (CRTSQLRPGI, par exemple)
                > dans le paramétrage du driver ODBC/JDBC.


       *NONE ou *NC : Vous travailler HORS contrôle de validation


       *CHG  ou *UR : les objets manipulés par les ordres SQL suivants :
                      ALTER, CALL, COMMENT ON, CREATE, DROP, GRANT, LABEL ON
                       RENAME, REVOKE ainsi que les lignes ajoutées (Insert)
                       détruites (DELETE) et modifiées (UPDATE) sont
                       verouillés jusqu'à la fin de transaction


                      Les modifications non validées des autres travaux
                       sont visibles , car pas de verrou en lecture.


    

       *CS          : idem *CHG, PLUS une ligne par table en lecture.


                      Pour un Select simple, la ligne est verrouillée PUIS
                      libérée (il ne s'agit que de tester sa disponibilité)


                      Pour un curseur


                        chaque ligne lue est verrouillée par FETCH jusqu'à
                         la lecture de la ligne suivante.


                        sauf à préciser :


                          KEEP LOCKS


                       la ligne est alors verrouilée jusqu'à la fin de la
                        transaction ou fermeture du curseur


                      Les modifications non validées des autres travaux
                       ne sont donc pas visibles , la ligne n'étant pas
                       accessible !


    

        la version 7 vient compléter ce choix en placant en fin d'ordre
         une phrase précisant la concurrence d'accès:


 ..........................................................................
 : - WAIT FOR OUTCOME                                                     :
 :     Attendre que les lignes verrouillées soient libérées (CS ou RS)    :
 : - SKIP LOCKED DATA                                                     :
 :     les lignes verrouillées sont ignorées (NC, UR, CS, ou RS)          :
 : - USE CURRENTLY COMMITTED                                              :
 :     Utiliser les (anciennes) valeurs déjà validées (SELECT sous CS)    :
 :........................................................................:


       *ALL  ou *RS : idem *CS, sauf verrouillage de TOUTES les lignes lues
                       pour un curseur


                      Pour un Select simple, la ligne est verrouillée PUIS
                      libérée, sauf à préciser USE AND KEEP EXCLUSIVE LOCKS
                      auquel cas elle est verrouillée jusqu'au COMMIT.


                      des lignes peuvent être inserées dans le fichier
                       pendant la transaction par d'autres JOB.

       *RR          : idem *ALL, sauf que les tables manipulées par INSERT,
                       UPDATE, DELETE et SELECT sont verrouillées en usage
                       Exclusif , empéchant l'insertion de lignes.


                      On ne voit pas les transactions en cours et la même
                       requête passée dans la même transaction produit le
                       même résultat  (Repeatable Read !)


 récapitulatif                                  ! NC ! UR ! CS ! RS ! RR !
                                                !----!----!----!----!----!
 Accès aux lignes en cours de modfication ?     ! O  ! O  ! N  ! N  ! N  !
 -------------------------------------------------------------------------
 Mise à jour des lignes en cours de transaction?! N  ! N  ! N  ! N  ! N  !
 -------------------------------------------------------------------------
 Le même ordre produit même résultat ?          ! N  ! N  ! N  ! N  ! O  !
 -------------------------------------------------------------------------
 une ligne mise à jour est modifiable ailleurs? ! O  ! 1  ! 1  ! 1  ! 1  !
 -------------------------------------------------------------------------
 une ligne lue est modifiable ailleurs ?        ! 2  ! 2  ! 2  ! N  ! N  !
 -------------------------------------------------------------------------

 1 : Non la ligne est verrouillé jusqu'au COMMIT, après Oui bien sûr.

 2 : si le curseur est FOR UPDATE Non, sinon Oui.

    

  2/ vous validez avec l'ordre SQL COMMIT (vous invalidez par ROLLBACK)




     ATTENTION, l'ordre SQL COMMIT possède un paramètre important


       HOLD :  -  Les ressources sont suspendues. Les curseurs actifs
                  ne sont pas désactivés , les instructions SQL
                  préparées sont conservées et toutes les ressources
                  acquises pendant la transaction sont suspendues.




       (sans)  -  Les ressources ne seront pas suspendues. Les curseurs
                  actifs sont désactivés, les instructions SQL préparées
                  sont supprimées et les ressurces suspendues libérées.




  Un curseur peut etre déclaré WITH HOLD ou WITHOUT HOLD


  s'il est déclaré WITH HOLD, il ne sera pas désactivé, meme en cas de
   COMMIT simple.


    

 Cas particulier du langage SQL/PSM (procédures cataloguées)


    les instructions d'une procédure cataloguées peuvent être regroupées
     comme un tout (on parle d'instruction complexe, "compound statement")




 corps général d'une procédure cataloguée écrite en SQL/PSM


  CREATE PROCEDURE bibliothèque/procédure ( parametres )
  language SQL
  BEGIN  ATOMIC | NOT ATOMIC


  DECLARE (partie déclaration)


     .../... (instructions) ;


  END




  les blocs d'instructions (BEGIN / END) peuvent être imbriqués


    

  PSM est en fait un L4G qui génére un source C dans QTEMP et créé un pgm.


   ce pgm est compilé dans le groupe d'activation *CALLER (toujours)


   si vous indiquez  NOT ATOMIC ou si vous n'indiquez rien, vous travaillez
   hors transaction, sauf transaction en cours, démarrée par STRSQL, par ex


 Exemple :
  ---
  ---  test d'une procédure simple
  ---   elle prend le niveau de commit de la session SQL
  ---  le DELETE du fichier client est impossible car certains fichiers
  ---    enfants (livraisons et factures) ne sont pas journalisés.
  ---  le DELETE du fichier facture n'est possible qu'avec COMMIT(*NONE)
  ---   le pgm ne se plante alors qu'à la deuxième instruction.
   create procedure af4test/prc1 ()
   language SQL
   begin
    delete from af4test/factures;
    delete from af4test/clients where nocli = 4;
   end

 ---
 ---  test d'une autre procédure simple
 ---   ici, les deux fichiers sont journalisés
 ---  le DELETE du fichier ma_cave est toujours possible
 ---  le DELETE du fichier pays est impossible, il y a des producteurs
 ---
 ---   sans ATOMIC, le fichier cave est vide, même en cas de prb


  create procedure af4test/prc2 ()
  language SQL
  begin
   delete from bdvin9/ma_cave;
   delete from bdvin9/pays where pays_code=11;
  end
 ...........................................................................
 : > call af4TEST/prc2                                                     :
 :   Suppression impossible à cause de la contrainte référentielle Q_BDVIN :
 : > select * from bdvin9/ma_cave ==> fichier vide                         :
 :.........................................................................:
 ---
 ---  avec ATOMIC, le fichier cave est plein suite à cette manipulation
 ---   ==> SQL a fait un ROLLBACK, d'ailleur le pgm est compilé COMMIT(*CHG)

 vous pouvez dans la partie déclaration, déclarer des HANDLER 


    on déclare 1/ l'erreur (code ou nom-condition déclaré lui aussi)
               2/ le traitement
               3/ la reprise après traitement.
                                                              (1)


     DECLARE   ------------------------  HANDLER FOR  code-erreur--------->
                 !              !
              (3)!--CONTINUE----!
                 !              !
                 !--EXIT--------!
                 !              !
                 !--UNDO--------!


    >-------instruction SQL ;
                  (2)


 dans tous les cas on exécute le traitement (2) avant de gérer
  la reprise (3)


    

 la reprise :


 CONTINUE =  on continue le code en séquence.
             (si l'erreur a lieu dans un IF, CASE, WHILE, on sort
               et on se débranche à l'instruction qui suit le IF ...)


 EXIT     =  on va au END


 UNDO     =  on annule tous les changements (ROLLBACK) puis EXIT,


              ce qui implique  BEGIN ATOMIC !




 et enfin, la V5R20 apporte un nouveau niveau de granularité


    - SAVEPOINT


     Cette notion permet de matérialiser des étapes dans une transaction
      offrant la possibilité de revenir à une étape précise et non au début
      de la transaction en cas de ROLLBACK.


    

  un point de reprise est posé par l'instruction SAVEPOINT


       UPDATE client ...                       ;


     SAVEPOINT MAJ ON ROLLBACK RETAIN CURSORS  ;


       DELETE FROM CLIENTS ...  ;
       DELETE FROM COMMANDES    ;


     SAVEPOINT DLT ON ROLLBACK RETAIN CURSORS   ;


       INSERT INTO ...          ;


     IF xxx ROLLBACK TO SAVEPOINT MAJ
      ELSE RELEASE SAVEPOINT ;


  ON ROLLBACK RETAIN CURSORS, permet de garder le(les) curseur(s) ouverts
  ON ROLLBACK RETAIN LOCKS , permet de garder les verrouillages/ligne


  RELEASE SAVEPOINT, libère (détruit) le point de reprise


    

Exemple (en RPG4) :


     Dligne          E DS                  extname(fichier)
      /free
        nom = 'test1'  ;
       exsr ecriture   ;
        nom = 'test2'  ;
       exsr ecriture   ;
       // point de sauvegarde
       exsr savepointS1;
        nom = 'test3'  ;
       exsr ecriture   ;


       // annulation de CETTE écriture par ROLLBACK TO SAVEPOINT
       exsr rollbackS1 ;
        nom = 'test4'  ;
       exsr ecriture   ;


       // validation, je dois avoir les lignes 1,2 ET 4 (exact).
       exsr commit     ;
       *inlr = *on     ;
      /end-free

     C     ecriture      begsr
     C/EXEC SQL
     C+ INSERT INTO FICHIER VALUES(default, :nom)
     C/END-EXEC
     c                   endsr


     C     savepointS1   begsr
     C/EXEC SQL
     C+  SAVEPOINT s1
     C/END-EXEC
     c                   endsr
     C     rollbackS1    begsr
     C/EXEC SQL
     C+ ROLLBACK  to SAVEPOINT s1
     C/END-EXEC
     c                   endsr
     C     commit        begsr
     C/EXEC SQL
     C+ COMMIT
     C/END-EXEC
     c                   endsr

 +------------------------------------------------------------------------+
 |            Principaux codes journaux liés au COMMIT                    |
 +------------------------------------------------------------------------+
 |          |                                                             |
 |  C  BC   |   démarrage du contrôle de validation                       |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |  C  SC   |   démarrage d'un cycle                                      |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |  C  CM   |   Commit                                                    |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |  C  RB   |   Rollback                                                  |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |  C  LW   |   Fin de transaction, écrit uniquement avec OMTJRNE(*NONE)  |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |  C  EC   |   arrêt du contrôle de validation                           |
 +----------+-------------------------------------------------------------+


    

 +------------------------------------------------------------------------+
 |          |                                                             |
 |  C  SB   |   Début d'un transaction imbriquée ou SAVEPOINT             |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |  C  SQ   |   libération d'un SAVEPOINT ou commit d'une transaction     |
 |          |    imbriquée (Procédures cataloguées)                       |
 +----------+-------------------------------------------------------------+
 |          |                                                             |
 |  C  SU   |   Rollback d'un SAVEPOINT ou d'une transaction imbriquée    |
 +----------+-------------------------------------------------------------+
 Ces trois dernières entrées ne sont écrites que de manière optionnelle. 




 pour les écrire pour un journal donné (MONJOURNAL dans MABIB) pour ce JOB :


    ADDENVVAR ENVVAR(QTN_JRNSAVPT_MABIB_MONJOURNAL) VALUE(*YES)


 pour les écrire pour TOUS les journaux, TOUS les JOBS :


    ADDENVVAR ENVVAR(QTN_JRNSAVPT_*ALL_*ALL) VALUE(*YES) LEVEL(*SYS)


    

 La disponibilité de la base de données a été revue en V5R30.


 1/ la sauvegarde de fichiers en cours d'activité (paramètre SAVACT)
      peut se faire meme en cas de transaction.


 2/ la réorganisaiton des fichiers :


      a/ peut etre interrompue


      b/ peut éventuellement se faire sans verrouillage fort


 Rappel sur le paramètre SAVACT.


   cela permet de faire une sauvegarde d'une base en activité.


     il reste cependant le problème des objets base de données en cours
      de transaction (sous commitment control)


     on peut sauvegarder des fichiers en cours de mise à jour simple, mais
      pas sous COMMIT/ROLLBACK


    

  Exemple :


  Soit un fichier avec un enregistrement verrouillé par un pgm sans COMMIT.
   DB2 va poser un verrouillage *SHRUPD sur le membre (les données)


   SAVLIB ==> la sauvegarde prévient d'un objet NON sauvegardé


   SAVLIB SAVACT(*LIB) ==> la sauvegarde est effectué normalement (complète)
   [ SAVLIB SAVACT(*SYNCLIB) si vous avez plusieurs bibliothèques ]


   ......................................................................
   : L'intégrité de la base en cas de restauration est à votre charge,  :
   :   vous venez peut-etre de sauvegarder une piece comptable          :
   :   incomplète (non équilibrée), par exemple.                        :
   :                                                                    :
   : La fonction journal peut vous y aider (APYJRNCHG / RMVJRNCHG).     :
   :....................................................................:


   le paramètre SAVACTWAIT(120) permet d'indiquer le temps d'attente pour
    la disponibilité des objets et la fin d'une transaction.




    

  Mais, imaginons un fichier en cours d'utilisation sous commitment control
   (DB2 pose alors un verrou *SHRRD sur l'objet)


   SAVLIB ==> la sauvegarde prévient d'un objet NON sauvegardé


   SAVLIB SAVACT(*LIB) ==> Erreur CPF377F, la sauvegarde n'a pas lieu


   ....................................................................
   :   La disponibilité des objets est testée AVANT la sauvegarde !   :
   :..................................................................:


   SAVLIB SAVACT(*LIB) SAVACTWAIT(120 *NOCMTBDY ) nouveau paramètre en 5.30
   ........................................................................
   : le paramètre SAVACTWAIT accèpte trois valeurs :                      :
   :  1/ attente pour la disponibilité des objets                         :
   :  2/ attente pour la disponibilité des enregistrements en transaction :
   :  3/ attente pour les autres transactions (création de table, ...)    :
   :......................................................................:


    la sauvegarde a lieu, complète, avec un message d'information CPI3731
      par fichier en transaction, dans la JOBLOG du travail.

Détail du message CPI3731


                     Complément d'informations sur message 


 ID message . . . . . . :   CPI3731
 Date d'envoi . . . . . :   29/11/04      Heure d'envoi  . . . . :   17:34:2


 Message . . . . :   Objet FICH1P1 (type *FILE) enregistré avec une transaction
   partielle.


 Cause . . . . . : L'objet FICH1P1 de type *FILE de la bibliothèque AF4SRCT
   été sauvegardé avec une ou plusieurs transactions partielles. Si cet objet
   est un fichier base de données, le nom du membre est FICH1P1.
 Que faire . . . :
     -- S'il s'agit d'une opération de restauration, vous ne pouvez utiliser
   cet objet avant d'appliquer ou de supprimer les modifications journalisées
   (commande APYJRNCHG ou RMVJRNCHG) pour atteindre les limites de validation
   Pour appliquer ou supprimer les modifications, vous aurez besoin du journal
   QSQJRN de la bibliothèque AF4SRCT et de la chaîne des destinataires du
   journal commençant par JRNRCV0001 dans la bibliothèque AF4SRCT de l'unité
   ASP *SYSBAS.

 ATTENTION, le message indique bien que le fichier a été sauvegardé
  lors d'une transaction incomplète , il n'est donc pas intègre.


 SI VOUS LE RESTAUREZ :


  vous aurez un message CPI3731 (toujours de type *INFO) dans la JOBLOG.


 et le fichier sera considéré comme inutilisable. 


  DSPFD montre cela, un OPEN sur le fichier engendre CPF428D


  et vous devez :


   i/   avoir ou restaurer le récepteur avec la transaction terminée, puis
         passer l'une des commandes suivantes : APYJRNCHG ou RMVJRNCHG


   ii/  restaurer une version avec transaction complète du fichier


   iii/ passer la commande CHGJRNOBJA ATR(*PTLTNS) PTLTNS(*ALLUSE)
         pour autoriser l'utilisation de cette version non intègre.
         (reprise "à la main" de l'intégrité du fichier)

 A noter qu'un ROLLBACK peut maintenant être annulé.


     1/ passez la commande WRKCMTDFN JOB(*ALL)
     2/ faites F11 pour regarder l'état de la transaction




Si vous avez les droits *ALLOBJ, vous pouvez passer l'option 20 qui annule
 le ROLLBACK, le fichier devient alors dans le même état qu'un fichier
 restauré suite à une sauvegarde pendant transaction.


Il est donc, lui aussi inutilisable, sauf à


     a/ terminer la transaction


     b/ passer la commande CHGJRNOBJA




Il est enfin possible d'empécher cette fonction, même à un utilisateur
 ayant des droits en créant une DATA AREA QGPL/QTNNOENDRB.




    

 Autre nouveauté concernant la disponibilté de la base de données, la
  réorganisation de fichier, plus souple qu'avant.


 Elle peut maintenant être interrompue (Appel/sys 2 ou ENDJOB)
  (Iseries navigator vous propose un dialogue spécifique et très pratique)


  RGZPFM ... ALWCANCEL(*YES)


  Avant, (ou sans ce paramètre)  quand vous lancez RGZPFM, le système :


   1/ invalide tous les index.


   2/ fabrique une copie du fichier qui deviendra l'original à la fin.


   3/ reconstruit ensuite les index (sauf celui utilisé en référence)


 Si on interrompt la réorganisation, on retouve le fichier physique dans
  son état d'origine, et le système se met à reconstruire tous les index !


 Ce qui rend l'interruption très délicate, les applications étant en
   attente de la disponibilité des index associés.

 si vous précisez ALWCANCEL(*YES)


   - le système ne travaille pas sur une copie du fichier
       ==> le fichier doit etre journalisé !


   - la réorganisation est un peu plus longue.


   - vous pouvez indiquer KEYFILE(*RPLDLTRCD) qui place les enregistrements
      de fin du fichier, à la place des enregistrements supprimés.


   - vous pouvez demander une maintenance des index en temps réel, afin
      d'assurer une disponibilité immédiate de la base, en cas d'arret.


        RBDACCPTH(*YES) les chemins d'accès sont maintenu de manière
                         asynchrone, en fin d'opération (comme avant)


        RBDACCPTH(*OPTIMIZE) le système choisi, soit une maintenance pendant
                             la réoganisaiton, soit une maintenance
                              asynchrone, en fin de traitement.


        RBDACCPTH(*NO)  les chemins d'accès sont maintenus PENDANT la
                         réoganisation [ALWCANCEL(*YES) obligatoire]

   Dans ce dernier cas, RBDACCPTH(*NO), vous pouvez autoriser l'accès
    au fichier pendant la réogranisation, avec le paramètre LOCK.




     LOCK(*EXCL)     le système pose un verrou exclusif rendant l'accès
                      au fichier impossible.


     LOCK(*EXCLRD)   le système pose un verrou exclusif avec lecture,
                      rendant la consultation possible, mais la mise à jour
                      impossible.


     LOCK(*SHRUPD)   le système pose un verrou en mode partagé, la mise à
                      jour du fichier par d'autres traitements est permise.


                     ATTENTION, la réorganisaiton du fichier suivant un
                      critère de clef précis [paramètre KEYFILE], n'est
                      plus garantie, des enregistrements pouvant etre
                      insérés (par exemple) pendant le traitement.


    Ce dernier paramètre, rend, lui aussi la réorganisaiton plus longue.


    

 Détails :


  Le système créé un fichier de travail dans QRECOVERY portant le nom SQL
    QDBRGZ_BIBLIOTHEQUE_FICHIER, et le détruit en fin de traitement.


  L'annulation d'une demande s'affiche comme cela dans l'historique


  .......................................................................
  : Dernière demande au niveau 2 interrompue.                           :
  : Traitement de l'instruction SQL arrêté. Code raison : 3. (SQL0952)  :
  :.....................................................................:


  Si le fichier de QRECOVERY existe déja, le système tente une reprise,
   si les paramètres de la commande sont les mêmes.


  Voici ce que peut afficher la LOG


   QDBRGZ_AF4W_HTTPLOG_HTTPLOG de type *FILE existe déjà dans QRECOVERY.
   Non continuation de l'opération de réorganisation annulée sur le fichier
     HTTPLOG_I2 de la bibliothèque HTTPLOG_I2, membre AF4W.




    

 Si vous demandez de l'Aide, il ya trois codes possibles :


  1 -- Les paramètres indiqués lors de la réorganisation en cours (RGZPFM
 FILE(AF4W/HTTPLOG) MBR(HTTPLOG) KEYFILE(AF4W/HTTPLOG_I2 HTTPLOG_I2)
 RCDFMT(*ONLY) RBDACCPTH(*YES) ALWCANCEL(*YES) LOCK(*EXCL)) ne correspondent
 pas exactement aux paramètres de la réorganisation annulée (RGZPFM
 FILE(AF4W/HTTPLOG) MBR(HTTPLOG) KEYFILE(AF4W/HTTPLOG_I2 HTTPLOG_I2)
 RCDFMT(*ONLY) RBDACCPTH(*YES) ALWCANCEL(*YES) LOCK(*SHRUPD)).


 le code raison 2 indique que le fichier contient trop de différences


         - restauration du fichier, depuis.
         - changement de nom (fichier ou membre)
         - déplacement (bibliothèque)
         - effacement du membre (CLRPFM)
         - ALTER TABLE


 le code 3 que le fichier dans QRECOVERY n'existe pas ou est endommagé.