le forum IBM i

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

JE suis surpris

Chez moi ce pgm

Code : Tout sélectionner

**free
ctl-opt alwnull&#40;*usrctl&#41;;
dcl-pr verrou02 extpgm;
  *n bindec&#40;9&#41; const;
END-PR;
dcl-f producteur disk keyed usage&#40;*update&#41;;
pr_code = 1;
chain pr_code producteur;
verrou02&#40;1&#41;;
*inLR = *ON;

appelle ce pgm

Code : Tout sélectionner

**free
ctl-opt alwnull&#40;*usrctl&#41;;
dcl-pi *n;
  p1 bindec&#40;9&#41;;
END-PI;
dcl-f producteur disk keyed usage&#40;*update&#41;;
chain p1 producteur;
dsply pr_nom;
*INLR = *ON;

et je reçois

Erreur. RNX1299 non intercepté par VERROU02 à la spécif 0000000030

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.

Bonjour,

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

Il fait quoi exactement le DFTACTGRP(*NO)?

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.

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

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?

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.

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.

le forum IBM i

Groupe d'activation

Groupe d'activation

je suis surpris

SHARE(*YES)

Groupe d'activation

OVRDBF