CPF9802

Comment s'en sortir

L'objet existe, mais le profil utilisateur du travail n'a pas les droits nécessaires pour l'utiliser. C'est un problème de sécurité, pas de programme.

Les causes les plus fréquentes

• Il manque un droit sur l'objet : lire un fichier demande *USE, le modifier *CHANGE.
• Il manque le droit sur la bibliothèque. Pour atteindre un objet, il faut au moins *EXECUTE sur la bibliothèque qui le contient. On l'oublie souvent.
• Le batch ne tourne pas sous le même profil que vos tests : SBMJOB USER(...), un travail planifié, un serveur (QUSER pour ODBC, QTMHHTTP pour le HTTP Server).
• Les droits passaient par un programme en droits adoptés (USRPRF(*OWNER)) qui n'est plus dans la pile d'appels, ou qui a été recompilé sans garder son propriétaire.

Diagnostiquer

/* Qui a quels droits sur l'objet ? */
DSPOBJAUT  OBJ(MALIB/MONFIC) OBJTYPE(*FILE)

/* Et sur la bibliothèque */
DSPOBJAUT  OBJ(QSYS/MALIB) OBJTYPE(*LIB)

/* Le profil : groupe, droits spéciaux */
DSPUSRPRF  USRPRF(PROFIL)

En SQL : SELECT * FROM QSYS2.OBJECT_PRIVILEGES WHERE SYSTEM_OBJECT_SCHEMA = 'MALIB' AND SYSTEM_OBJECT_NAME = 'MONFIC'.

Corriger

/* Accorder le droit utile, et seulement lui */
GRTOBJAUT  OBJ(MALIB/MONFIC) OBJTYPE(*FILE) USER(PROFIL) AUT(*USE)

/* Sans oublier la bibliothèque */
GRTOBJAUT  OBJ(QSYS/MALIB) OBJTYPE(*LIB) USER(PROFIL) AUT(*EXECUTE)

Pour plusieurs utilisateurs, accordez le droit à leur profil de groupe, ou passez par une liste d'autorisation (CRTAUTL, ADDAUTLE) : un seul endroit à maintenir.

Ne « réglez » pas le problème avec AUT(*ALL) pour *PUBLIC ou en donnant *ALLOBJ au profil : le message disparaît, et avec lui la sécurité de l'objet. Un auditeur le verra.