> Tech > Choisir le groupe d’activation

Choisir le groupe d’activation

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Chaque programme ILE et programme de service s’exécute dans un groupe d’activation. Quand on crée un programme de service, il faut songer au groupe d’activation dans lequel il pourra s’exécuter. Dans l’exemple cidessus, nous avons utilisé le *CALLER spécifié pour la commande CRTSRVP GM, c’est-à-dire le même que le groupe

par défaut de la commande. On dispose d’un triple choix en groupe d’activation :

  • *CALLER (défaut pour la commande CRTSRVPGM)
  • Un nom utilisé par plusieurs programmes de service
  • Un nom unique utilisé par un seul programme de service

Avec *CALLER, le programme de service s’exécutera dans le même groupe d’activation que celui auquel appartient l’appelant. Chaque groupe d’activation différent aura sa propre instance de stockage statique et sa propre instance de fichier ouvert pour les éventuels fichiers ouverts par le programme de service.

En utilisant *CALLER, on permet au système de réutiliser un groupe d’activation existant quand un programme se lie à votre programme de service, plutôt que de passer du temps à créer un nouveau groupe d’activation. On s’assure également ainsi que le groupe d’activation utilisé par le programme de service ne sera jamais récupéré (reclaimed) avant le groupe d’activation utilisé par les programmes qui utilisent le programme de service. Le système doit initialiser chaque module du programme de service, une fois pour chaque groupe d’activation.

(Avertissement : Si votre programme de service s’exécute dans *CALLER et si son programme appelant fait de même, et si vous appelez le programme à partir de la ligne de commande, votre programme de service s’exécutera dans le groupe d’activation par défaut. Ce n’est pas forcément gênant, à une réserve près : si le programme de service a des fichiers ouverts et si vous utilisez la commande RCLRSC (Reclaim Resources), le système fermera les fichiers mais le programme de service restera actif, croyant que les fichiers sont encore ouverts. Par la suite, le prochain appel d’une procédure dans le programme de service risque d’échouer avec MCH3402 quand il essaiera d’accéder à un fichier qu’il croit ouvert.)

L’utilisation d’un groupe d’activation nommé fait que le programme de service s’exécutera dans le même groupe d’activation, indépendamment du groupe d’activation dans lequel son appelant opère. Il n’y aura qu’une instance du stockage statique et les fichiers ne seront ouverts qu’une fois.

En utilisant un groupe d’activation nommé, vous demandez au système de créer un groupe d’activation séparé pour votre programme de service (à moins que le groupe d’activation n’ait déjà été créé, soit parce que le programme a été appelé précédemment, soit parce qu’un autre programme de service utilise le même groupe d’activation). Toutefois, le système ne doit initialiser les modules dans votre programme de service qu’une fois par job, en supposant que vous ne récupérez jamais le groupe d’activation.

(Avertissement : Si vous utilisez un groupe d’activation nommé et si le groupe d’activation est récupéré (reclaimed) pendant qu’un programme actif utilise encore le programme de service, le programme actif échouera la prochaine fois qu’il appellera une procédure dans le programme de service.)

Il est presque toujours judicieux d’utiliser *CALLER. Si vous optez pour un groupe d’activation nommé, mettez bien vos utilisateurs en garde contre les dangers de la récupération du groupe d’activation. Le choix des groupes d’activation implique d’autres considérations – particulièrement si vous utilisez des fichiers dans vos programmes de service. Mais cet aspect n’entre pas dans le cadre de cet article. Pour approfondir votre connaissance des groupes d’activation, lisez le manuel ILE Concepts (SC41-5606).

Téléchargez cette ressource

Comment lutter contre le Phishing ?

Comment lutter contre le Phishing ?

Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010