par Gary Guthrie
« Essaie donc d'utiliser OvrScope(*Job) »
Combien de fois vous a-t-on donné ce conseil quand un override (substitution ou remplacement, ou écrasement) de fichier ne fonctionnait pas comme prévu ? Modifier l'application pour utiliser un override au niveau du job peut produire les résultats attendus, mais cela revient un peu à remplacer le moteur d'une voiture parce qu'il a détérioré une bougie.
Bien entendu, avec un moteur flambant neuf, la voiture fonctionnera à nouveau parfaitement. En revanche, un override au niveau du job ne produira pas forcément les résultats attendus, selon la conception de l'application. Et, même si l'application fonctionne aujourd'hui, un override malencontreux au niveau du job associé à des modifications risque de poser des problèmes d'application à l'avenir.
Si vous envisagez de sauter cet article parce que vous croyez tout savoir déjà sur les overrides de fichier, réfléchissez-y à deux fois ! Je connais beaucoup de programmeurs, dont certains sont excellents, qui croient sincèrement comprendre cette puissante fonction de l'OS/400 - après tout, voilà des années qu'ils pratiquent l'override dans leurs applications. Mais je ne connais personne qui domine vraiment le sujet. Par conséquent, poursuivez la lecture, étonnez-vous, et apprenez une fois pour toute comment le système traite les overrides de fichier. Puis, mettez cette connaissance en pratique pour tirer le maximum des overrides.
Avant d’examiner de près les overrides de fichier, il faut se familiariser avec les parties de l’anatomie d’un job associées à la fonction des overrides. La pile d’appels (call stack) et les groupes d’activation (activation groups) déterminent pour beaucoup l’effet des overrides sur les applications.
Les jobs sont en principe constitués d’une chaîne de programmes actifs, où un programme en appelle un autre. La pile d’appels est simplement une liste ordonnée de ces programmes actifs. Quand un job démarre, le système l’achemine vers le programme de départ pour l’exécuter et désigne ce programme comme la première entrée dans la pile d’appels. Si le programme en appelle ensuite un autre, le système attribue le programme nouvellement appelé à la deuxième entrée de la pile d’appels. Ce processus peut continuer, le deuxième programme en appelant un troisième, celui-ci en appelant un quatrième, et ainsi de suite, en ajoutant chaque fois le nouveau programme à la fin de la pile d’appels. Celle-ci reflète donc la profondeur des appels de programmes.
Soit la pile d’appels suivante :
ProgramA
ProgramB
ProgramC
ProgramD
Cette pile d’appels contient quatre programmes actifs. Ici, le système a appelé ProgramA comme son premier programme au démarrage du job. ProgramA a ensuite appelé ProgramB qui, à son tour, a appelé ProgramC. Pour finir, ProgramC a appelé ProgramD. Comme ces appels de programmes sont imbriqués, chaque programme se trouve dans une couche différente de la pile d’appels. Ces couches sont également appelées niveaux d’appel (call levels). Dans l’exemple, ProgramA est au niveau d’appel 1, indiquant ainsi qu’il est le premier programme appelé quand le job a démarré. ProgramB, ProgramC et ProgramD sont aux niveaux d’appel 2, 3 et 4 respectivement.
Quand les programmes se terminent, le système les enlève de la pile d’appels, réduisant du même coup le nombre de niveaux d’appel. Ainsi, quand ProgramD se termine, le système l’enlève de la pile d’appels et le job ne comporte plus que trois niveaux d’appel. A la fin de ProgramC, il ne reste plus que deux niveaux d’appel dans le job, ProgramA et ProgramB constituant alors la pile d’appels. Le processus se poursuit jusqu’à ce que ProgramA se termine et le job aussi.
A ce stade, nous voyons que quand un programme en appelle un autre, le système crée un nouveau niveau d’appel supérieur auquel le programme appelé s’exécute. Le programme appelé commence alors son exécution et, quand il se termine, le système l’enlève de la pile d’appels, redonnant le contrôle au programme appelant au niveau d’appel précédent.
C’est la version simple, mais la réalité est un peu plus compliquée. Tout d’abord, il se peut qu’un programme passe le contrôle à un autre programme sans que le programme nouvellement invoqué s’exécute à un niveau d’appel supérieur. Par exemple, avec la commande TfrCtl (Transfer Control) de CL, le système remplace (dans la pile d’appels) le programme émettant la commande par le programme auquel le contrôle va être transféré. Cela a deux conséquences : le programme invoqué s’exécute au même niveau d’appel que le programme invoquant et le programme invoquant est aussi complètement supprimé de la chaîne des programmes constituant la pile d’appels. Par conséquent, il n’est pas possible de redonner le contrôle au programme qui émet la commande TfrCtl. Au lieu de cela, quand le programme nouvellement invoqué se termine, le contrôle revient au programme au niveau d’appel immédiatement précédent.
J’ai dit plus haut que, quand les programmes se terminent, le système les enlève de la pile d’appels. En réalité, quand un programme se termine, le système enlève de la pile d’appels non seulement le programme finissant, mais également tout programme situé à un niveau d’appel supérieur à celui du programme finissant. A propos de cet exemple, certains se demandent peut-être « Comment ProgramB peut-il se terminer avant ProgramC ? » Il faut savoir que ProgramD peut envoyer un message d’échappement à la file d’attente des messages de programmes de ProgramB. La conséquence de cet événement est que le système redonne le contrôle au gestionnaire des erreurs (error handler) de ProgramB. Le fait que le contrôle a été redonné à ProgramB fait que le système enlève de la pile d’appels tous les programmes situés à un niveau d’appel supérieur à ProgramB – plus précisément – ProgramC et ProgramD. La conception de ProgramB détermine alors s’il est supprimé de la pile d’appels. S’il traite l’exception, ProgramB n’est pas enlevé de la pile d’appels et le traitement continue alors en ProgramB.
Notons également que, dans des circonstances normales, la pile d’appels commence avec plusieurs programmes système avant que n’apparaissent des programmes écrits par l’utilisateur. En fait, les programmes système apparaîtront probablement çà et là dans la pile d’appels. Ce point n’est important que pour démontrer que la pile d’appels n’est pas simplement une représentation des programmes écrits par l’utilisateur, comme on les appelle.
Pour bien comprendre les overrides de fichier, il faut, en plus d’une bonne compréhension des niveaux d’appel d’un job, être aussi familiarisé avec les groupes d’activation. Vous savez probablement qu’un job est une structure avec ses propres ressources allouées, comme des voies de données ouvertes (ODP, open data path) et du stockage pour les variables de programme. Ces ressources sont à la seule disposition des programmes exécutés dans ce job, à l’exclusion des autres jobs. Les groupes d’activation, dont l’introduction remonte à ILE (integrated language environment), sont une division des jobs en sous-structures plus petites.
Tout comme les jobs, les groupes d’activation sont constitués de ressources système privées, comme les ODP et le stockage pour les variables de programme. Les ressources allouées à un groupe d’activation sont réservées aux objets programme qui sont attribués à ce groupe d’activation particulier dans le job et qui s’y exécutent. On attribue les objets programme ILE à un groupe d’activation au moment de leur création. Ensuite, quand on exécute ces programmes, le système crée le ou les groupes d’activation auxquels les programmes sont attribués. Un job peut être constitué de multiples groupes d’activation, dont aucun ne peut accéder aux ressources uniques aux autres groupes d’activation dans le job. Ainsi, bien que de multiples groupes d’activation dans un job puissent ouvrir le même fichier, chaque groupe d’activation peut maintenir son propre ODP privé. Dans un tel cas, les programmes attribués au même groupe d’activation peuvent utiliser l’ODP, mais ceux qui sont attribués à un groupe d’activation différent n’ont pas accès au même ODP.
Une explication complète des groupes d’activation serait bien trop longue. Pour l’instant, il suffit de savoir que les groupes d’activation existent, qu’ils sont les sous-structures d’un job et qu’ils peuvent contenir leurs propres ensembles de ressources, hors de portée des autres groupes d’activation dans le job.
