Groupe d'activation

RPG (3 et 4, free), CL, SQL, etc...
Répondre
florian67
Messages : 135
Enregistré le : lun. 23 déc. 2013, 17:03:12

Groupe d'activation

Message par florian67 »

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

cmasse
Site Admin
Messages : 813
Enregistré le : mer. 14 févr. 2007, 18:00:03
Localisation : Nantes
Contact :

je suis surpris

Message par cmasse »

JE suis surpris

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;    
appelle ce pgm

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;     
et je reçois
Erreur. RNX1299 non intercepté par VERROU02 à la spécif 0000000030
Christian Massé (Volubis.fr)

cmasse
Site Admin
Messages : 813
Enregistré le : mer. 14 févr. 2007, 18:00:03
Localisation : Nantes
Contact :

SHARE(*YES)

Message par cmasse »

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.
Modifié en dernier par cmasse le jeu. 02 juin 2016, 11:08:22, modifié 1 fois.
Christian Massé (Volubis.fr)

florian67
Messages : 135
Enregistré le : lun. 23 déc. 2013, 17:03:12

Message par florian67 »

Bonjour,

Pour le SHARE(*YES) je ne pense pas.

Il fait quoi exactement le DFTACTGRP(*NO)?

cmasse
Site Admin
Messages : 813
Enregistré le : mer. 14 févr. 2007, 18:00:03
Localisation : Nantes
Contact :

Groupe d'activation

Message par cmasse »

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.
Christian Massé (Volubis.fr)

florian67
Messages : 135
Enregistré le : lun. 23 déc. 2013, 17:03:12

Message par florian67 »

Je regarde un peu plus en détail ce problème car c'est encore un peu un mystère ... :)

florian67
Messages : 135
Enregistré le : lun. 23 déc. 2013, 17:03:12

Message par florian67 »

Pour revenir à cette phrase :
- les substitutions (OVRxxx OVRSCOPE) qui ne sont valables que pour les pgm du même groupe.

ça veut dire que si je fais un OVRDBF (qcmdexc) avec DFTACTGRP(*NO), ça peut poser des problèmes?

cmasse
Site Admin
Messages : 813
Enregistré le : mer. 14 févr. 2007, 18:00:03
Localisation : Nantes
Contact :

OVRDBF

Message par cmasse »

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)

florian67
Messages : 135
Enregistré le : lun. 23 déc. 2013, 17:03:12

Message par florian67 »

Je testé ça. Si je fais un OVRDBF (fichier multi-membre) dans le RPG je ne vois pas les données. Par contre si je rajoute OVRSCOPE(*ACTGRPDFN) SHARE(*YES) ça fonctionne très bien. Je commence à comprendre la mécanique des groupes d'activations.

Répondre