> Tech > Protection d’un override

Protection d’un override

Tech - Par iTPro - Publié le 24 juin 2010
email

  Parfois on souhaitera protéger un override contre l'effet d'autres overrides pour le même fichier. Autrement dit, on veut être certain qu'un override émis dans un programme est bien celui qui s'appliquera quand on ouvrira le fichier « overriden ». On peut protéger un override contre toute modification par des overrides

provenant de niveaux d’appel inférieurs, du niveau du groupe d’activation et du niveau de job en spécifiant Secure(*Yes) sur la commande d’override.

   La figure 3 présente des extraits de deux programmes, ProgramA et ProgramB, fonctionnant dans le groupe d’activation par défaut et avec des overrides au niveau d’appel seulement. ProgramA émet simplement un override pour définir la valeur d’attribut de la file d’attente de sortie pour le fichier d’imprimante Report1 puis appelle ProgramB. Celui-ci, à  son tour, appelle deux programmes HLL, HLLPrtPgm1 et HLLPrtPgm2, tous deux chargés d’imprimer le fichier Report1. Avant d’appeler chacun de ces programmes, ProgramB émet un override vers le fichier Report1 pour changer la valeur d’attribut de la file d’attente de sortie.

   Quand on appelle ProgramA, le système émet d’abord un override au niveau d’appel qui donne la valeur Prt01 à  l’attribut de la file d’attente de sortie de Report1. Ensuite, ProgramA appelle ProgramB, créant ainsi un nouveau niveau d’appel. ProgramB commence à  émettre un override au niveau d’appel, donnant la valeur Prt02 à  l’attribut de la file d’attente de sortie de Report1. Notons que la commande OvrPrtF spécifie le paramètre Secure avec une valeur de Yes. ProgramB appelle ensuite le programme HLL, HLLPrtPgm1 pour ouvrir et imprimer Report1. Comme cette commande OvrPrtF au niveau d’appel spécifie Secure(*Yes), le système n’applique pas d’overrides au niveau d’appel provenant des niveaux d’appel inférieurs – plus précisément, l’override dans ProgramA qui donne la valeur Prt01 à  l’attribut de la file d’attente de sortie. HLLPrtPgm1 place par conséquent le rapport dans la file d’attente de sortie Prt02.

   ProgramB continue avec encore un autre override au niveau d’appel, donnant la valeur Prt03 à  l’attribut de file d’attente de sortie de Report1. Comme cet override se produit au même niveau d’appel que le premier override dans ProgramB, le système remplace l’override au niveau d’appel. Toutefois, ce nouvel override ne spécifie pas Secure(*Yes). Par conséquent, le système utilise l’override au niveau d’appel provenant du niveau d’appel 1. Cet override change la valeur de l’attribut de file d’attente de sortie de Prt03 en Prt01. ProgramB appelle finalement HLLPrtPgm2 pour ouvrir et spouler Report1 vers la file d’attente de sortie Prt01. Ces deux overrides dans ProgramB démontrent clairement la différence de comportement entre un override sécurisé et non sécurisé.

Téléchargez gratuitement cette ressource

Comment sécuriser la Digital Workplace ?

Comment sécuriser la Digital Workplace ?

Avec le recours généralisé au télétravail, les entreprises ont ouvert davantage leur SI. En dépit des précautions prises, elles ont mécaniquement élargi leur surface d’exposition aux risques. Découvrez 5 axes à ne pas négliger dans ce Top 5 Sécurité du Télétravail.

Tech - Par iTPro - Publié le 24 juin 2010