Sujet : zos
-
Automatiser z/OS via z/OSMF : les API REST pour les jobs, les datasets et les fichiers
z/OSMF expose les jobs, les datasets et les fichiers z/OS UNIX sous forme de ressources HTTPS/REST classiques, ce qui en fait l'interface du système la mieux adaptée aux agents. Les requêtes doivent porter l'en-tête personnalisé X-CSRF-ZOSMF-HEADER (les requêtes qui modifient l'état sont rejetées sans lui), et les réponses utilisent les codes d'état HTTP standard plutôt que des messages texte 3270.
-
Introduction à z/OS : espaces d'adressage, datasets, catalogues, JES2 et ce que voit une session SSH dans USS
z/OS répartit le travail en espaces d'adressage plutôt que dans une table de processus unique, stocke les données dans des datasets catalogués plutôt que dans une seule arborescence de fichiers, et met en file d'attente le travail batch via JES2 ; une session SSH dans z/OS UNIX System Services (USS) n'est qu'un espace d'adressage de plus, avec sa propre vue, et non une fenêtre sur tout le système.
-
Bases de JCL et du traitement par lots : instructions JOB/EXEC/DD, codes retour, soumission depuis USS et lecture de la sortie
Un job JCL se compose d'une instruction JOB, d'une ou plusieurs étapes EXEC nommant chacune un programme, et d'instructions DD qui associent fichiers et datasets aux entrées/sorties de ce programme. Chaque étape se termine par un code retour (0 : exécution propre ; valeurs plus élevées : avertissements ou erreurs). Un job se soumet depuis le shell USS avec submit, et sa sortie se lit via SDSF ou l'API REST jobs de z/OSMF.
-
Sécurité z/OS avec RACF : profils d'utilisateur, de groupe et de dataset, et pourquoi les agents requièrent le moindre privilège
RACF est le gestionnaire de ressources que la plupart des installations z/OS placent derrière l'interface SAF (System Authorization Facility) ; il protège utilisateurs, groupes et datasets via des profils consultés avec LISTUSER/LISTDSD et accordés avec PERMIT. Un agent d'automatisation doit s'exécuter sous un identifiant utilisateur aux droits strictement limités plutôt que sous un identifiant disposant d'accès étendus, et ne pas traiter la sortie des commandes comme une interface programmatique stable.
-
Bases de l'exploitation z/OS : commandes de console, SYSLOG/OPERLOG et IPL
Les commandes de console comme D A,L (liste des travaux actifs) et D IPLINFO (informations sur l'IPL) constituent le point de départ en lecture seule pour comprendre ce que fait un système z/OS. SYSLOG et OPERLOG sont les journaux où s'accumulent les messages système, et l'IPL (Initial Program Load) est l'équivalent mainframe d'un démarrage complet du système : il ne doit pas être déclenché en dehors d'une fenêtre de changement planifiée.
-
Accéder aux datasets z/OS depuis le shell UNIX : notation //'HLQ.NAME', tsocmd et balises d'encodage
Depuis un shell z/OS UNIX, les datasets classiques s'adressent avec la notation //'HLQ.DATA.SET', comprise par cp et d'autres utilitaires USS, ou en exécutant directement une commande TSO avec tsocmd. Les fichiers texte échangés entre datasets EBCDIC et fichiers USS ASCII exigent un marquage explicite via chtag ou le paramètre _BPXK_AUTOCVT ; sinon ils arrivent corrompus, et pas seulement mal affichés.
Lisible par machine : JSON