Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 16 sur 16
  1. #1
    Invité de passage
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    octobre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 11
    Points : 4
    Points
    4

    Par défaut REXX - Récupérer le User qui a soumis un Job

    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.

  2. #2
    Membre confirmé
    Femme Profil pro
    Architecte technique
    Inscrit en
    janvier 2008
    Messages
    150
    Détails du profil
    Informations personnelles :
    Sexe : Femme

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2008
    Messages : 150
    Points : 226
    Points
    226

    Par défaut

    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

  3. #3
    Invité de passage
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    octobre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 11
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par xfanx Voir le message
    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

  4. #4
    Membre habitué
    Homme Profil pro Julien Guiffroy
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Guiffroy
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 106
    Points
    106

    Par défaut

    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

  5. #5
    Membre habitué
    Homme Profil pro Julien Guiffroy
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Guiffroy
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 106
    Points
    106

    Par défaut

    Citation Envoyé par xfanx Voir le message
    4 - et enfin, interdire les commande SJ sous TSO sur ces Jobs
    oups, pas vu !

  6. #6
    Invité de passage
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    octobre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 11
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par Skylyn Voir le message
    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

  7. #7
    Membre habitué
    Homme Profil pro Julien Guiffroy
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Guiffroy
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 106
    Points
    106

    Par défaut

    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

  8. #8
    Invité de passage
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    octobre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 11
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par Skylyn Voir le message
    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.

  9. #9
    Membre habitué
    Homme Profil pro Julien Guiffroy
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Guiffroy
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 106
    Points
    106

    Par défaut

    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 !

  10. #10
    Invité de passage
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    octobre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 11
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par Skylyn Voir le message
    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.

  11. #11
    Membre habitué
    Homme Profil pro Julien Guiffroy
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Guiffroy
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 106
    Points
    106

    Par défaut

    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

  12. #12
    Rédacteur/Modérateur
    Avatar de M.Dlb
    Inscrit en
    avril 2002
    Messages
    2 326
    Détails du profil
    Informations personnelles :
    Âge : 29

    Informations forums :
    Inscription : avril 2002
    Messages : 2 326
    Points : 3 397
    Points
    3 397

    Par défaut

    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
    M.Dlb - Modérateur z/OS - Rédacteur et Modérateur Pascal

  13. #13
    Invité de passage
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    octobre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 11
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par wormful_sickfoot Voir le message
    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

  14. #14
    Membre habitué
    Homme Profil pro Julien Guiffroy
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Guiffroy
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 106
    Points
    106

    Par défaut

    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?

  15. #15
    Rédacteur/Modérateur
    Avatar de M.Dlb
    Inscrit en
    avril 2002
    Messages
    2 326
    Détails du profil
    Informations personnelles :
    Âge : 29

    Informations forums :
    Inscription : avril 2002
    Messages : 2 326
    Points : 3 397
    Points
    3 397

    Par défaut

    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
    M.Dlb - Modérateur z/OS - Rédacteur et Modérateur Pascal

  16. #16
    Invité de passage
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    octobre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 11
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par wormful_sickfoot Voir le message
    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

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •