| 
Le contrôle de validation est différent sur plusieurs points en V3R10. Tout d'abord, les contrôles de validation peuvent maintenant être multiples au sein d'un même job. Cette nouveauté est apportée par la notion de groupe d'activation. 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 ait de répercussion sur les autres applications (autres groupes d'activation). |
|
La principale nouveauté concernant le contrôle de validation est la validation à deux phases (Two Phases Commit) Depuis la V2R30, il était possible de demander un contrôle de validation lors de manipulation de fichiers éloignés (DDM, DRDA, ...) Ces fichiers devaient être journalisés sur le site distant, bien sur. Cela ce fait avec SQL et DRDA en passant un ordre CONNECT à une base éloignée alors que la session SQL a activé le contrôle de validation [STRSQL COMMIT(*CHG) par exemple] . Mais vous ne deviez travailler qu'avec une seule base éloignée au sein d'une même transaction. CONNECT baseb (manipulation de la base) COMMIT <-! vous devez d'abord valider vos actions sur baseb. CONNECT basea ---! |
|
Avec la validation à deux phases de la V3R10, vous pouvez manipuler plusieurs bases lors d'une transaction : CONNECT baseb (manipulation de la base) CONNECT basea (manipulation de la base) COMMIT = validation des manipulations sur les deux Bases de données. Cette technique est appellée validation à deux phases puisqu'elle s'effectue en deux temps (en deux vagues : "WAVE"). 1/ "PREPARE WAVE" l'initiateur de la transaction (le système qui valide) prévient tous les autres sites d'une demande de validation. Les autres ressources doivent répondre (on parle de "VOTE") Soit 2A/ tous les votes sont "prêt !" (ready). ==> demande à toutes les ressources de valider : "COMMITTED WAVE" Soit 2B/ tous les votes ne sont PAS "prêt !". (il suffit d'un seul) ==> ROLLBACK général. |
|
Une transaction est appelée LUW (logical Unit of Work) En utilisant des ressouces éloignées comme en V2R30 on parle de RUW (Remote Unit of Work) Dans la validation à deux phases le terme est DUW (Distributed Unit of Work) Il y a un nouveau JOB système (visible via WRKACTJOB) QLUR chargé de tout ce travail avec les sites distants. (nous connaissions déja QLUS qui gérait les appels entrants) Les types de ressources utilisant ce principes sont ! Les fichiers PF,LF locaux. Les fichiers DDM avec PTCCNV(*YES) DDL data définition language/SQL (CREATE TABLE, etc ...) DRDA SQL en manipulation de données LU6.2 dialogue APPC , pgms utilisants des fichiers ICFF (IL Y A DE NOUVEAUX VERBES APPC) API vous pouvez placer des ressources sous contrôle de validation, c'est alors un programme d'exit écrit par vous qui intervient. |
|
Et enfin, chaque site se voit attribuer un rôle lors de la validation "Transaction programme network" simple. ........................ !----: Système B : Agent .................. ! :......................: : Système A :------- :................: ! ........................ Initiateur !----: Système C : Agent :......................: "Transaction programme network" à plusieurs niveaux. ............... !----: Système B : Agent .................. ................ ! :.............: : Système A :--: Système E :--- :................: :..............: ! ............... Initiateur Agent !----: Système C : Agent Initiateur en :.............: cascade. |
|
Pour améliorer les performances, l'initiateur peut attribuer à un agent le rôle de "dernier agent" . le dernier agent ne participe pas à la vague de préparation (PREPARE WAVE), il valide le premier lors de la phase "COMMITTED WAVE" et si sa validation ne se termine pas normalement l'initiateur demandera un ROLLBACK général. il y a sur chaque site une couche système qui intervient : Transaction Manager Sytème I (initiateur) Système A (agent) TmI TmA pgmI !-> Transaction manager I ! pgmA | ! ! | | ! ! | | ! ! | | ! <----------liaison-----------> ! | | ! ! | | ! ! | | ! Transaction manager A -> ! | |
|
l'enchainement logique d'une phase de validation est le suivant : Sytème I (initiateur) Système A (agent) TmI TmA pgmI ! ! pgmA | ! !<-lecture----------| | !<-receive and wait----------------! | |--Commit--->! ! | | !-------prepare------------------->! | | ! !--RCVTKCMT(indic)->| | ! ! | | ! !<--Commit----------| | !<------request commit-------------! | | ! ! | | !-------commit-------------------->! | | ! ! | | !<------reset----------------------! | |<-return----! !--return---------->| | ! ! | <-----------> ! <------------------------------> ! ^ ^ dialogue entre pgm et couche système dialogue entre couches système |
|
l'enchaînement logique d'une phase de validation est le suivant : Sytème I (initiateur) Système A (agent) TmI TmA pgmI ! ! pgmA 1 | ! !<-lecture----------| | !<-receive and wait----------------! | 2 |--Commit--->! ! | 3 | !-------prepare------------------->! | 4 | ! !--RCVTKCMT(indic)->| | ! ! | 5 | ! !<--Commit----------| ########################################################################## # 1: l'agent est en attente (lecture) # # 2: le pgm initiateur demande une validation # # 3: le TMI lance une "prepare wave" (pgmI n'a plus la main) # # 4: cette demande est reçue par TMA qui envoie l'indication à pgmA # # (nouveau mot-clé ICF RCVTKCMT = réception d'une demande de commit) # # 5: si le pgm agent reste d'accord, il valide (ordre commit) # # (TMA prend cet ordre pour un "vote ready" (accord), mais ne # # valide pas physiquement) # ########################################################################## |
|
l'enchainement logique d'une phase de validation est le suivant : Sytème I (initiateur) Système A (agent) TmI TmA pgmI ! ! pgmA ######################################################################### # 6: TMA transmet le vote positif à TMI # # 7: quand tous les agents ont voté, TMI lance la vague de validation # # (TMA reçoit cet ordre, valide réellement et libère les verrouillages # # 8: Réponse de TMA, retour en phase d'attente. # # 9: si tout s'est bien passé, les pgms (I et A) reprennent le contrôle # ######################################################################### 6 | !<------request commit-------------! | | ! ! | 7 | !-------commit-------------------->! | | ! ! | 8 | !<------reset----------------------! | 9 |<-return----! !--return---------->| | ! ! | |
|
l'enchaînement logique d'une phase de validation est le suivant : Sytème I (initiateur) Système A (agent) TmI TmA pgmI ! ! pgmA ######################################################################### # en cas de problème lors de la "committed wave", le système va entrer # # en phase de resynchronisation (tentative de reconnection avec le # # site distant) [7A] jusqu'à la reprise normale de la transaction. # # les programmes (particulièrement pgmI), ne reprendront le contrôle # # qu'une fois la validation complètement terminée. # ######################################################################### 6 | !<------request commit-------------! | | ! ! | 7 | !-------commit-----------------> | | ! | 7A | !-------resynchronisation---------> | 7A | !-------resynchronisation---------> | 7A | !-------resynchronisation--------->! | | ! ! | 8 | !<---reset-------------------------! | 9 |<-return----! :-return----------->| |
|
Vous pouvez demander(si vous n'avez pas besoin de synchroniser vos fichiers) à ce que la resynchronisation se fasse en asynchrone (en tâche de fond). TMI passera la main à un pgm système QDBSRVxx, afin qu'il effectue cette resynchronisation, puis rendra le contrôle à pgmI, en le prévenant qu'il est en attente de resynchronisation. Ce paramètre se précise par l'appel à l'API QTNCHGCO (change commit option) en mettant la valeur *NO au paramètre Wait For Outcome [dft = *YES] Si jamais la resynchronisation ne pouvait avoir lieu, l'état de la transaction serait déclaré "Heuristic Mixed" et une intervention opérateur est enclenchée. Un autre paramètre modifiable via cette API est le Vote READ-ONLY . Un "transaction manager" n'ayant pas de modification à valider, participe quand même à la "comitted wave" (Commit ou Rollback) en ce sens qu'il doit repositionner les curseurs (ou fichiers) là ou ils étaient en début de transaction en cas de rollback. |
|
Si l'agent ne fait que répondre aux demandes de l'initiateur (cas typique du client/serveur, où le serveur ne fera que de l'accès direct aux fichiers, suivant les demandes du client), alors vous n'avez pas besoin de se repositionnement fichier RAPPEL : S'il n' a pas d'action base de données à VALIDER ! Vous pouvez alors renseigner le paramètre vote READ-ONLY à *YES, ce qui fait que : - l'agent sera appellé normalement lors de la phase de préparation - si l'agent à des modifications à valider il participera à la comitted wave - mais s'il n'a rien à valider, il repondera (votera) READ-ONLY. - l'initiateur prendra cette réponse pour un vote positif, tout en notant qu'il est inutile de rappeler cette ressource lors de la phase de validation proprement dire. Comme vous le voyez, il y a un certain nombre de subtilités possibles. |
|
Pour gérer tous les contrôles de validation actifs, la nouvelle commande : WRKCMTDFN est utile. Elle permet de gérer tous les contrôles de validation déclenchés par un JOB, ou bien tous les contrôles actifs sur votre machine. Gérer définitions validation (WRKCMTDFN) Indiquez vos choix, puis appuyez sur ENTREE. Travail . . . . . . . . . . . . JOB *all Utilisateur . . . . . . . . . Numéro . . . . . . . . . . . . Etat . . . . . . . . . . . . . . STATUS *ALL ID unité d'oeuvre logique . . . LUWID *ALL Sortie . . . . . . . . . . . . . OUTPUT * Fin F3=Exit F4=Invite F5=Réafficher F10=Autres paramètres F12=Annuler F13=Mode d'emploi invite F24=Autres touches |
|
Gestion des définitions de validation Système: S4409790 Indiquez vos options, puis appuyez sur ENTREE. 5=Afficher état 12=Gérer travail 14=Validation forcée 16=Invalidation forcée ... Définition Resync en Opt validation Travail Util Numéro cours *DFTACTGRP QZDAINIT QUSER 009936 NON ^ ! !-- Le nom de la définition de validation est soit *DFTACTGRP soit le nom du groupe d'activation soit un nom "système" (cas de QDBCMTDFN) Avec F11 vous pouvez connaître les coordonnées de la LUW. Fin F3=Exit F5=Réafficher F6=Etat des ressources F9=Ligne de commande F12=Annuler |
|
Gestion des définitions de validation Système: S4409790 Indiquez vos options, puis appuyez sur ENTREE. 5=Afficher état 12=Gérer travail 14=Validation forcée 16=Invalidation forcée ... Définition Opt validation ID unité d'oeuvre logique Etat 5 *DFTACTGRP APPN.S4409790.X'302CB1AE26D0'.00001 REINITIALISATION les options disponibles sont : 5 = voir l'état de la définition de validation 12 = gérer le travail qui l'a déclenchée 14 = Commit 16 = Rollback 18 = gérer l'état de la configuration (RUW : Remote Unit of Work) 19 = annuler la resynchronisation. (point de synchronisation ==> ressources éloignées) Fin F3=Exit F5=Réafficher F9=Ligne de commande F11=Texte F12=Annuler F16=Trier par ID d'unité d'oeuvre F24=Autres touches |
|
Etat d'une définition de validation S4409790 25/08/95 15:58:30 Travail: QZDAINIT Utilisateur: QUSER Numéro: 009936 Définition de validation . . . . : *DFTACTGRP Groupe d'activation . . . . . . . : 2 ID unité d'oeuvre logique . . . . : APPN.S4409790.X'302CB1AE26D0'.00001 Travail actif . . . . . . . . . . : OUI Travail du serveur . . . . . . . : Lieu de la ressource . . . . . . : AUCUNE <-- Niveau de verrouillage par défaut : *CS notions liées au 2 Rôle (initiateur,agent) . . .. . : <-- phases commit. Etat . . . . . . . . . . . . . . : REINITIALISATION Date/horodatage . . . . . . . . Resynchronisation en cours . . . : NON <-- Nombre de validations . . . . . . : 0 Nombre d'invalidations . . . . . : 1 A suivre... Appuyez sur ENTREE pour continuer. F3=Exit F5=Réafficher F6=Etat des ressources F9=Ligne de commande F12=Annuler |
|
Etat d'une définition de validation S4409790 25/08/95 15:57:59 Travail: QZDAINIT Utilisateur: QUSER Numéro: 009936 Définition de validation . . . . : *DFTACTGRP Groupe d'activation . . . . . . . : 2 Opération heuristique . . . . . . : Journal par défaut . . . . . . . : <-- Bibliothèque . . . . . . . . . : } informations Objet de notification . . . . . . : *NONE <-- données par Bibliothèque . . . . . . . . . : STRCMTCTL. Type d'objet . . . . . . . . . : Membre . . . . . . . . . . . . : A suivre... Appuyez sur ENTREE pour continuer. F3=Exit F5=Réafficher F6=Etat des ressources F9=Ligne de commande F12=Annuler |
|
Etat d'une définition de validation S4409790 25/08/95 15:57:59 Travail: QZDAINIT Utilisateur: QUSER Numéro: 009936 Définition de validation . . . . : *DFTACTGRP Groupe d'activation . . . . . . . : 2 Options de validation: Attente des résultats . . . . . : ATTENTE Action si incidents . . . . . . : INVALIDATION Lecture seule admise . . . . . : NON Action si arrêt . . . . . . . . : ATTENTE Fin Appuyez sur ENTREE pour continuer. F3=Exit F5=Réafficher F6=Etat des ressources F9=Ligne de commande F12=Annuler |
|
Etat d'une définition de validation S4409790 25/08/95 15:58:30 Travail: QZDAINIT Utilisateur: QUSER Numéro: 009936 Définition de validation . . . . : *DFTACTGRP Groupe d'activation . . . . . . . : 2 .............................................................................. : Etat des ressources : : : : Indiquez votre option, puis appuyez sur ENTREE. : : 1=Choisir : : Opt Ressource : : Niveau enregistrement ############################## : : Niveau objet # F6 permet de gérer # : : Conversation # les ressources # : : Fichier éloigné # utilisées par cette # : : RDB éloignée # définition de # : : API # validation. # : : (V4R2) journaux éloignés ############################## : : (V5R1) Connexion TCP/IP Fin : : F5=Réafficher F12=Annuler : :............................................................................: |
|
Les différents états possibles pour une définition de validation sont: RST (reset) attente de Commit ou Rollback PIP (prepare in progress) l'initiateur a lancé la prepare wave, tous les agents n'ont pas encore voté. PRP (prepared) "a voté" , cette ressource à voté mais n'a pas encore reçu l'ordre de valider par l'initiateur CIP (commit in progress) l'intiateur a démarré la committed wave CMT (committed) tous les agents ont validé == autres états possibles ================================================= LAP (last agent pending) entre PIP et CIP, l'intiateur attend une réponse du dernier agent. VRO (Vote READ-ONLY) cet agent à répondu READ-ONLY, il n'a rien à valider. RBR (Rollbakc Required) soit - un agent à demandé une invalidation - une transaction a eu une fin anormale - l'API QTNRBRQD a été utilisée |
|
== états dus à une intervention opérateur ========================== (forced rollback) Rollback forcé (option 16) (forced commit) Commit forcé (option 14) HRM (heuristic Mixed) des ressources ont validé, d'autres ont invalidé, bref problème !!!! Une resynchronisation n'a pas abouti. le mot heuristic (heuristique en français) signifie "recherche qui aide à la compréhension", il s'agit ici, sans doute, de la recherche de l'opérateur sur les causes probables qui peut aider à la compréhension des origines du problème (quant aux remèdes ???) ---------------------------------------------------------------------------- les services DDM et DRDA étaient disponibles sur IP depuis la V4R20, ils sont devenus compatibles avec cette notion de validation à deux phases depuis la V5R10 de l'OS/400 |
