REXX - Récupérer le User qui a soumis un Job [Résolu]

[rg903]

Bonjour, j'ai parcouru l'ensemble des discussions sans trouver (ou voir) une ébauche de réponse à mon problème. Le voici :
Afin de tracer l'accès et la soumission d'un job, je dois récupérer le USER qui a soumis celui-ci. Facile me direz-vous avec le &SYSUID, sauf que celui-ci est "overridé" dans la carte JOB par un USER ayant l'autorisation d' accéder aux fichiers et bases du JCL.
La démarche de soumisson de ce JCL est la suivante :
l'utilisateur modifie un membre PDS (une SYSIN) qui contient une requête DB2, puis soumet un JCL qui appelle cette SYSIN. L'utilisateur lui-même n'est pas autorisé à accéder à la table DB2 contenue dans la requête, c'est pourquoi on utilise un USER dans la carte JOB du JCL.

Je compte inclure un REXX au début du JCL, qui permette de récupérer :
1/ la SYSIN soumise, qui l'a modifiée et à quel moment
2/ le USER ayant soumis le JCL et à quel moment.

J'espère que mon problème est assez bien exposé.

Merci pour les pistes que vous pourrez m'indiquer.

[xfanx]

bonjour,

nous avons eu le même genre de problématique sur mon site et l'avons réglé comme ça :

1 - passer par une interface Rexx maison pour générer et soumettre le JCL via SK ISPF. (en d'autre terme interdire aux développeurs de pouvoir le modifier manuellement..)
2 - ajouter lors de la gen de ce JCL en SYSIN d'un 1er step, le USERID TSO du submitteur.
3 - comme vous le faite, ajouter un 1er step, REXX permettant de tracer le USERID et le code SQL exécuté.. et ce pour servir de piste d'audit des maj effectuées sur les tables BD2 non test.
4 - et enfin, interdire les commande SJ sous TSO sur ces Jobs

[rg903]

Envoyé par xfanx

bonjour,

nous avons eu le même genre de problématique sur mon site et l'avons réglé comme ça :

1 - passer par une interface Rexx maison pour générer et soumettre le JCL via SK ISPF. (en d'autre terme interdire aux développeurs de pouvoir le modifier manuellement..)
2 - ajouter lors de la gen de ce JCL en SYSIN d'un 1er step, le USERID TSO du submitteur.
3 - comme vous le faite, ajouter un 1er step, REXX permettant de tracer le USERID et le code SQL exécuté.. et ce pour servir de piste d'audit des maj effectuées sur les tables BD2 non test.
4 - et enfin, interdire les commande SJ sous TSO sur ces Jobs

Merci pour votre réponse rapide et complète. J'ai pensé effectivement à un JCL "Lanceur" mais je pensais pouvoir récupérer le USERID TSO du soumetteur malgré la présence d'un USER autorisé dans la carte job.

Merci encore

[Skylyn]

Si tu as accès à SDSF tu peux aussi coder "SJ" devant le job que tu voudrais consulter et tu verrais normalement la carte JOB avec le login USER=... ou le NOTIFY=... qui devrait indiquer la personne qui a lancé le JOB

[Skylyn]

Envoyé par xfanx

4 - et enfin, interdire les commande SJ sous TSO sur ces Jobs

oups, pas vu !

[rg903]

Envoyé par Skylyn

Si tu as accès à SDSF tu peux aussi coder "SJ" devant le job que tu voudrais consulter et tu verrais normalement la carte JOB avec le login USER=... ou le NOTIFY=... qui devrait indiquer la personne qui a lancé le JOB

Bonjour, oui c'est bien ce qu'il faut que je contourne car je veux récupérer le USER lançant le job et non pas celui qui est codé dans la carte job. Ou alors j'ai mal compris l'explication. Ce qui est tout à fait possible.

Moi aussi je m'embrouille

La commande SJ est effectivement protégée.
Merci à vous deux

[Skylyn]

Peut être une idée pour rechercher,

tu dis que le &SYSUID est "overridé", mais si tu codes le SYSUID avec le USER de la carte JOB et que tu écris dans un fichier à part le SYSUID "original"

je ne te dis pas que ça marches, j'ai jamais testé mais le "&" devant veut surement dire que c'est un espace mémoire temporaire alors peut être un paramètre comme le SYSAFF=... avec SYSUID=USER ou quelque chose comme ça pourrait passer...

je n'en suis pas sur mais à tester avec la syntaxe du style :

/*JOBPARM SYSUID=USER ou quelque chose comme ça

[rg903]

Envoyé par Skylyn

Peut être une idée pour rechercher,

tu dis que le &SYSUID est "overridé", mais si tu codes le SYSUID avec le USER de la carte JOB et que tu écris dans un fichier à part le SYSUID "original"

je ne te dis pas que ça marches, j'ai jamais testé mais le "&" devant veut surement dire que c'est un espace mémoire temporaire alors peut être un paramètre comme le SYSAFF=... avec SYSUID=USER ou quelque chose comme ça pourrait passer...

je n'en suis pas sur mais à tester avec la syntaxe du style :

/*JOBPARM SYSUID=USER ou quelque chose comme ça

Bonjour, merci pour tes recherches mais là c'est rapé.

En effet dans la doc JCL, il est bien précisé ce qui suit (in english please) :
"The system replaces &SYSUID with the user ID under whose authority the job will run, which is normally one of the following :
. The USER parameter from the JOB statement, if specified, or
. The user ID from which the job was submitted"

Donc soit le USER est précisé dans la carte JOB et c'est celui-ci qui est renvoyé par &SYSUID, soit il est récupéré du USER qui soumet le JOB.
Le "normalement" (normally dans le texte ) signifie que par une option RACF, on peut même éviter la propagation du user ID, auquel cas la variable &SYSUID prend une valeur nulle.

Ceci dit, la solution d'un JCL lanceur avec récupération du user ID initial a été retenue par les personnes qui m'ont posé le problème, dont acte.

Merci encore, et bon week-end.

[Skylyn]

Juste pour la culture personnelle ou pour toute autre personne intéressée :

As-tu résolu ton problème ?

Si oui, peux-tu nous fournir une "solution" ou un axe de recherche ?

Cela pourrait servir à qui aurait le problème ultérieurement !

[rg903]

Envoyé par Skylyn

Juste pour la culture personnelle ou pour toute autre personne intéressée :

As-tu résolu ton problème ?

Si oui, peux-tu nous fournir une "solution" ou un axe de recherche ?

Cela pourrait servir à qui aurait le problème ultérieurement !

Bonjour, je suis en plein développement d'une procédure et donc je ne suis pas venu souvent faire un tour sur le forum.
le cahier des charges a un peu changé depuis. Les utilisateurs passeront par un panel pour modifier une sysin, puis soumettre le job. Donc je récupère le USERID() lors de l'action sur le panel, la soumission du job étant la résultante de cette action. L'avantage est que je soumets derrière un autre job qui permet la constitution de la log, aussi bien de la Sysin modifiée que du User et des informations de type horodatage.

Merci pour votre participation.

[Skylyn]

Donc si j'ai bien compris :

Tu prends le &USERID que tu mets dans une SYSIN et ensuite pour la log indirectement le USERID est véhiculé par &SYSIN que tu utilises dans la procédure pour log ?

Quelque chose comme :

//EXEC PGM=xxxxxxx
SYSIN='&USERID'
...
//*LOG
//LOGLIST DD DSN=fichier.log,DISP=...,PARM=&SYSIN

enfin niveau syntaxe je suis pas sur mais d'après ta réponse, c'est ce que je comprends

[M.Dlb]

A priori, ca serait plutôt un panel ISPF qui permet la modification d'une SYSIN existante (le job d'origine), et lors de la validation du panel, le user qui appelle le panel est récupéré avec USERID() qui est une fonction REXX, et le job est soumis avec la SYSIN modifiée. Le mode de création de la log n'est pas précisé mais il serait logique que ca soit dans le même REXX, avec écriture dans la SYSLOG ou DataSet ?

Si j'ai bien tout compris bien sûr

[rg903]

Envoyé par wormful_sickfoot

A priori, ca serait plutôt un panel ISPF qui permet la modification d'une SYSIN existante (le job d'origine), et lors de la validation du panel, le user qui appelle le panel est récupéré avec USERID() qui est une fonction REXX, et le job est soumis avec la SYSIN modifiée. Le mode de création de la log n'est pas précisé mais il serait logique que ca soit dans le même REXX, avec écriture dans la SYSLOG ou DataSet ?

Si j'ai bien tout compris bien sûr

Bonjour, oui tu as bien compris, la saisie et la modification de la Sysin se fait au travers d'un panel ISPF, puis la soumission du job. Dans le REXX associé, je récupère, lors du choix de la soumission du job, le USER se trouvant sur le panel ainsi que l'horodatage,
/*
Récupération des informations USER et horodatage avant la soumission du job
*/
executeur = userid()
horodate = date(E)
horotime = time(N)

et je récupère les stats ISPF du membre contenant la SYSIN (USER + Horodatage).
/*
allocation pds contenant la requete a soumettre
*/
Address TSO
"Alloc FI("DDN1") DA('"DsnReq"') SHR"
/*
appel routine pour pds
*/
Address ISPEXEC
"LMINIT DATAID("DDN1") DATASET('"DsnReq"')"
"LMOPEN DATAID("DDN1") OPTION(INPUT)"
/*
Lecture des stats du membre de pds
*/
Address ISPEXEC
"LMMFIND dataid("DDN1") member("memreq") stats(YES)"
/*
Récupération des informations sur la requete
*/
id_modif = zluser
horo_mod_date = substr(zlmdate,7,2)!!'/'!!substr(zlmdate,4,2)!!'/'substr(zlmdate,1,2)
horo_mod_time = zlmtime
/*
Lecture de la requete
*/
datavar = 0
Address ISPEXEC
"LMGET dataid("DDN1") mode(multx) dataloc(srchline) datalen(datavar) maxlen(72)"

Je lance ensuite un autre job qui permet de constituer la log (table DB2) avec toutes les infos collectées.
Et roule ma poule, si je puis me permettre

[Skylyn]

Hum... ça a l'air bien rôdé ton truc !

Je ne connais pas bien REXX, enfin pas assez pour voir ce que tu voulais faire par ce dernier...

Si je puis me permettre une question : ton code REXX, tu le lances dans un JCL?

[M.Dlb]

Toujours en supposant... Le REXX lance le panel ISPF (avec ISPEXEC par exemple) puis récupère les infos saisies après la validation du panel ISPF, et fait les traitements nécessaires. Beaucoup d'applis sur site sont développées comme ça, un panel ISPF permet la saisie d'information et ensuite le REXX fait le boulot

[rg903]

Envoyé par wormful_sickfoot

Toujours en supposant... Le REXX lance le panel ISPF (avec ISPEXEC par exemple) puis récupère les infos saisies après la validation du panel ISPF, et fait les traitements nécessaires. Beaucoup d'applis sur site sont développées comme ça, un panel ISPF permet la saisie d'information et ensuite le REXX fait le boulot

Bonjour, bonnes suppositions

un REXX affiche un panel où deux choix sont possibles pour l'utilisateur :
1- Modifier un membre de PDS (qui sera la requête à soumettre, donc du SQL dans mon cas)
2- Soumettre le job qui effectue la requête.

Derrière ces choix sont liés deux REXX, un qui permet l'ouverture du membre de PDS en EDIT, l'autre un peu plus complexe qui permet :
1- de récupérer le USER connecté (qui est entré sur le panel si tu préfères)
2- de lancer le job effectuant la requête (via un squelette par FTINCL ... puis address tso submit)
3- de récupérer les informations (stats) de maj sur le membre de PDS contenant la requête (par LMFIND ...)
4- de constituer une requête d'insertion dans une table DB2 (qui servira de log) avec toutes les informations sur le(s) USER(s) et la requête.

Mais l'utilisateur n'aura accès qu'à la requête, et ne pourra que soumettre le job. Il récupère le résultat de la requête dans un fichier qu'il peut seulement consulter, ne peut pas voir ni les jobs soumis, ni les procédures REXX ou squelettes, grâce aux protections RACF mises en place.

Voilà toute l'histoire