Mélanger l’autorité adoptée et USEADPAUT(*NO) dans un système de menus

PAYMENU est spécifié comme Initial Program (INLPGM) de BOB dans son profil utilisateur. Donc, quand BOB se connecte, il est immédiatement confronté à l’écran PAYMENU.

Le menu PAYMENU a trois options qui manipulent des données de paie ; une autre option permet à BOB d’aller à iSeries Query, et une autre amène BOB sur un écran WRKSPLF. L’écran WRKSPLF contient toujours une ligne de commande pour l’entrée de commande directe. L’option 90 permet à BOB de se déconnecter. Aucune ligne de commande n’est présente sur le menu PAYMENU lui-même.

Le programme PAYMENU adopte l’autorité de PAYOWNER. Chaque fois que BOB se connecte au système, le menu PAYMENU est présenté et BOB a adopté l’autorité de PAYOWNER.

Les options 1, 2 et 3 présentent les programmes de maintenance de la paie. Comme BOB a déjà adopté l’autorité dans son programme initial, les programmes qui doivent accéder aux données de paie n’ont pas besoin d’adopter l’autorité, mais ils ont besoin d’utiliser l’autorité adoptée fournie par PAYMENU. Ainsi, comme le montre la figure 4, les programmes pour les options 1, 2 et 3 sont créées avec USRPRF(*USER) et USEADPAUT(*YES). Cela signifie que les programmes n’adoptent pas d’autorité supplémentaire, mais ils utilisent l’autorité adoptée de PAYOWNER qui leur a été passée à partir du programme PAYMENU.

Le système ne vous permet pas de spécifier l’attribut USEADPAUT quand vous créez un programme. Si vous êtes autorisés à créer un programme qui utilise l’autorité adoptée, tous les programmes que vous créez sont créés avec USEADPAUT(*YES). Si vous n’êtes pas autorisés à créer un programme qui utilise l’autorité adoptée, il est créé avec USEADPAUT(*NO), et quelqu’un avec l’autorité suffisante doit changer le programme pour utiliser l’autorité adoptée à partir de PAYMENU :

CHGPGM PGM(PAYOBJ/PAYPGM1) USEADPAUT(*YES)

Stopper l’adoption

L’option 4 nous posera en principe un gros problème. Généralement, nous utiliserions simplement la commande WRKQRY à partir de cette option de menu. Mais comme le programme initial pour BOB a adopté l’autorité PAYOWNER, nous ne voulons pas fournir aux utilisateurs une interface vers Query quand ils ont encore l’autorité *ALL sur les fichiers de paie de production. L’outil IBM iSeries Query permet à un utilisateur de créer des fichiers de sortie, et si un utilisateur a l’autorité *ALL sur un fichier existant, celui-ci peut être écrasé par le résultat d’une requête. Oui, c’est bien ça, iSeries Query peut écraser vos fichiers de base de données de production si les utilisateurs ont trop d’autorité sur les fichiers. Et c’est exactement pourquoi nous devons stopper l’adoption de PAYOWNER avant de passer à la commande WRKQRY.

Se protéger contre iSeries Query

Au lieu d’utiliser la commande WRKQRY à partir de l’option de menu 4, nous créons un simple programme CL nommé PAYQRYPGM. Voici son code :

PGM
MONMSG CPF0000 /*Ignore any Errors */
QSYS/WRKQRY
ENPGM

Quand nous créons ce programme, pour indiquer que le programme doit adopter l’autorité, nous spécifions USRPRF(*OWNER). Ensuite nous changeons le propriétaire du programme en PAYQRY, qui a des droits en lecture seule sur les fichiers de paie. Ensuite nous changeons le programme pour qu’il n’utilise pas l’autorité adoptée de PAYOWNER qui lui a été passée à partir de PAYMENU. Voici les commandes :

CRTCLPGM PGM(PAYOBJ/PAYMAINT)
USRPRF(*OWNER)
SRCFILE(MYLIB/QCLSRC) SRCMBR(PAYQRYPGM)

CHGOBJOWN OBJ(PAYOBJ/PAYQRYPGM)
OBJTYPE(*PGM) NEWOWN(PAYQRY)

CHGPGM PGM(PAYOBJ/PAYQRYPGM) USEADPAUT(*NO)

Désormais, quand BOB sélectionne l’option 4, il perd temporairement l’autorité adoptée de PAYOWNER et adopte la nouvelle autorité de PAYQRY, qui a des droits en lecture seule sur les fichiers de paie. Maintenant, vos fichiers de production ne courent plus le risque d’être recouverts par le résultat de la requête de BOB. Quand BOB quitte la fonction Query, il est ramené au menu PAYMENU ; son autorité adoptée pour PAYOWNER est réinstaurée et son autorité adoptée pour PAYQRY est supprimée.