Groupe d'activation
Groupe d'activation
Bonjour à tous,
C'est encore moi...
Je ne vais pas dire que c'est un problème mais plutôt un fonctionnement que j'ai du mal à comprendre.
J'ai deux programmes, le premier (PGM1) fait un CALL du second (PGM2).
Le premier fait une lecture sur un fichier pour vérifier que l'enregistrement existe et le second met à jour l'enregistrement.
Déjà je ne comprends pas comment ça ne plantait pas vu que des deux côtés le fichier est en MAJ...
Bref on modifie PGM2 pour rajouter une fonction (BNDDIR DFTACTGRP(*NO)... Cette fois boom ça plante car enregistrement déjà verrouillé par ce travail. Pourquoi le DFTACTGRP(*NO) fait planter la mise à jour or que ça fonctionnait avant?
On a remarqué que si on rajoutait DFTACTGRP(*NO) dans PGM1 ou ACTGRP(*CALLER) dans PGM2 ça solutionnait le problème. Je me demande pourquoi également....
Je pense que je n'ai pas tout compris sur les groupes d'activations.
Merci d'avance.
Florian
C'est encore moi...
Je ne vais pas dire que c'est un problème mais plutôt un fonctionnement que j'ai du mal à comprendre.
J'ai deux programmes, le premier (PGM1) fait un CALL du second (PGM2).
Le premier fait une lecture sur un fichier pour vérifier que l'enregistrement existe et le second met à jour l'enregistrement.
Déjà je ne comprends pas comment ça ne plantait pas vu que des deux côtés le fichier est en MAJ...
Bref on modifie PGM2 pour rajouter une fonction (BNDDIR DFTACTGRP(*NO)... Cette fois boom ça plante car enregistrement déjà verrouillé par ce travail. Pourquoi le DFTACTGRP(*NO) fait planter la mise à jour or que ça fonctionnait avant?
On a remarqué que si on rajoutait DFTACTGRP(*NO) dans PGM1 ou ACTGRP(*CALLER) dans PGM2 ça solutionnait le problème. Je me demande pourquoi également....
Je pense que je n'ai pas tout compris sur les groupes d'activations.
Merci d'avance.
Florian
-
- Site Admin
- Messages : 813
- Enregistré le : mer. 14 févr. 2007, 18:00:03
- Localisation : Nantes
- Contact :
je suis surpris
JE suis surpris
Chez moi ce pgm
appelle ce pgm
et je reçois
Chez moi ce pgm
Code : Tout sélectionner
**free
ctl-opt alwnull(*usrctl);
dcl-pr verrou02 extpgm;
*n bindec(9) const;
END-PR;
dcl-f producteur disk keyed usage(*update);
pr_code = 1;
chain pr_code producteur;
verrou02(1);
*inLR = *ON;
Code : Tout sélectionner
**free
ctl-opt alwnull(*usrctl);
dcl-pi *n;
p1 bindec(9);
END-PI;
dcl-f producteur disk keyed usage(*update);
chain p1 producteur;
dsply pr_nom;
*INLR = *ON;
Erreur. RNX1299 non intercepté par VERROU02 à la spécif 0000000030
Christian Massé (Volubis.fr)
-
- Site Admin
- Messages : 813
- Enregistré le : mer. 14 févr. 2007, 18:00:03
- Localisation : Nantes
- Contact :
SHARE(*YES)
Peut-être le fichier est-il en SHARE(*YES) ???
Si oui, l'ouverture est commune (partagée) aux pgms du même groupe d'activation.
Si oui, l'ouverture est commune (partagée) aux pgms du même groupe d'activation.
Modifié en dernier par cmasse le jeu. 02 juin 2016, 11:08:22, modifié 1 fois.
Christian Massé (Volubis.fr)
-
- Site Admin
- Messages : 813
- Enregistré le : mer. 14 févr. 2007, 18:00:03
- Localisation : Nantes
- Contact :
Groupe d'activation
LE groupe d'activation propose un cloisonnement pour :
- les substitutions (OVRxxx OVRSCOPE) qui ne sont valables que pour les pgm du même groupe
- les ouvertures partagées OPNQRYF par ex (OPNSCOPE) ou tout fichier ouvert en SHARE(*YES), le partage n'ayant lieu que pour les pgm du même groupe.(sans SHARE(*YES) chaque pgm a sa propre "vision" du fichier)
- le commit , la transaction étant limité au groupe d'activation actif (si un pgm d'un autre groupe fait un ROLLBACK, cela n'impacte pas les actions DB du pgm)
- enfin cela influence la gestion des erreurs, la même erreur étant transmise de pgm à pgm, à l'intérieur du groupe d'activation. Quand on sort du groupe vous recevez CEE9001.
- les substitutions (OVRxxx OVRSCOPE) qui ne sont valables que pour les pgm du même groupe
- les ouvertures partagées OPNQRYF par ex (OPNSCOPE) ou tout fichier ouvert en SHARE(*YES), le partage n'ayant lieu que pour les pgm du même groupe.(sans SHARE(*YES) chaque pgm a sa propre "vision" du fichier)
- le commit , la transaction étant limité au groupe d'activation actif (si un pgm d'un autre groupe fait un ROLLBACK, cela n'impacte pas les actions DB du pgm)
- enfin cela influence la gestion des erreurs, la même erreur étant transmise de pgm à pgm, à l'intérieur du groupe d'activation. Quand on sort du groupe vous recevez CEE9001.
Christian Massé (Volubis.fr)
-
- Site Admin
- Messages : 813
- Enregistré le : mer. 14 févr. 2007, 18:00:03
- Localisation : Nantes
- Contact :
OVRDBF
Ca veut surtout dire, que si vous faites un OVRDBF dans un CLP (forcement dans la groupe d’activation par défaut) qui appel un RPG dans un groupe d’activation (DFTACTGRP(*NO) sans autre paramètre place le pgm dans un groupe nommé QILE) ce dernier ne "verra" pas la substitution.
Christian Massé (Volubis.fr)