Bases de l'exploitation z/OS : commandes de console, SYSLOG/OPERLOG et IPL

Ce que c'est

Les opérateurs z/OS interagissent avec le système en fonctionnement au moyen de commandes de console : de courtes directives saisies sur une console MVS (ou émises par programme via un outil d'automatisation). Deux commandes en lecture seule constituent un bon point de départ pour un agent qui cherche à se représenter l'état du système. D A,L (DISPLAY ACTIVE, format liste) affiche les travaux batch actifs, les started tasks, les utilisateurs TSO et les autres espaces d'adressage, à raison d'une courte ligne par entrée (D A,ALL ajoute des détails). D IPLINFO (Display IPL Information) indique le niveau de release du système, le type de licence et les détails du dernier IPL, sous la forme du message IEE254I. Ce sont deux commandes d'affichage qui ne modifient rien, et les produits d'automatisation d'IBM les émettent couramment pour collecter l'état du système. Un agent ne les saisit pas dans un shell USS : elles passent par une interface de console MVS, telle que la commande / de SDSF, la commande TSO CONSOLE ou l'API REST de console de z/OSMF (PUT /zosmf/restconsoles/consoles/defcn avec un champ JSON cmd). Même les commandes d'affichage sont en général protégées par des profils OPERCMDS (MVS.DISPLAY.*).

Les messages système — émis par les applications, les sous-systèmes et le système d'exploitation lui-même — s'accumulent dans l'un des deux journaux, ou dans les deux. SYSLOG est un journal de messages propre à chaque système (chaque LPAR), produit sous forme de sortie gérée par JES. OPERLOG en est l'équivalent à l'échelle du sysplex : un log stream géré par le system logger, qui fusionne les messages de tous les systèmes du sysplex où il est activé. C'est généralement le plus utile des deux pour diagnostiquer un environnement multisystème plutôt qu'une seule image. Le panneau OPERLOG de SDSF est un moyen courant de le consulter de façon interactive ; les deux journaux puisent dans le même « hardcopy message set », c'est-à-dire l'ensemble des messages destinés à une journalisation permanente.

Un IPL (Initial Program Load) est l'équivalent mainframe d'un démarrage complet du système. Il est lancé depuis la Hardware Management Console et non par une commande de console. Il comprend une étape de chargement au niveau matériel, suivie du chargement et de l'initialisation du nucleus, de l'initialisation des ressources système générales et de la Master Scheduler Initialization, avant que le système puisse accepter du travail. Comme un IPL arrête puis relance toute la LPAR, c'est un événement planifié, coordonné dans une fenêtre de changement, et jamais un effet de bord d'un travail de diagnostic courant.

Pourquoi c'est important

Un agent chargé de « vérifier ce qui se passe sur ce système » dispose de commandes standard et sûres pour commencer (D A,L, D IPLINFO, lecture d'OPERLOG/SYSLOG). Elles donnent une image fidèle sans rien toucher, ce qui est la bonne posture avant toute commande susceptible d'affecter la disponibilité.

Comment l'appliquer

• Commencer toute investigation par des commandes d'affichage en lecture seule (D A,L, D IPLINFO, ainsi que les équivalents JES/SDSF pour les travaux) avant d'envisager quoi que ce soit qui modifie l'état du système.
• Préférer OPERLOG au SYSLOG d'un seul système lorsque l'environnement est un sysplex, car OPERLOG fournit déjà la vue fusionnée à l'échelle du sysplex.
• Appliquer à un IPL la même discipline de fenêtre de changement qu'à tout autre redémarrage complet du système ; ne jamais exécuter de commandes de type arrêt (par exemple arrêter JES2 ou retirer un système du sysplex) dans le cadre d'un diagnostic courant.

Pièges

• Confondre « aucun travail visible dans mon shell USS » avec « le système est inactif » : D A,L et JES/SDSF couvrent l'activité des travaux batch et des started tasks, que la liste des processus USS n'affiche pas.
• Lire uniquement le SYSLOG dans un sysplex et passer à côté d'événements qui n'apparaissent que dans le journal d'un autre système ou dans la vue fusionnée d'OPERLOG.