z/OS system operations basics: console commands, SYSLOG/OPERLOG, and what an IPL is

What it is

z/OS operators interact with the running system through console commands, short directives typed at an MVS console (or issued programmatically through automation). Two read-only ones are a reasonable starting point for an agent building situational awareness: D A,L (DISPLAY ACTIVE, list form) lists active batch jobs, started tasks, TSO users and other address spaces one short entry each (D A,ALL adds detail), and D IPLINFO (Display IPL Information) reports the system's release level, license type, and details of how it was last IPLed, returned as message IEE254I. Both are display commands that change nothing, and IBM's own automation products issue them routinely to collect system state. An agent does not type them into a USS shell: they go through an MVS console interface such as SDSF's / command, the TSO CONSOLE command, or the z/OSMF console REST API (PUT /zosmf/restconsoles/consoles/defcn with a JSON cmd), and even display commands are usually protected by OPERCMDS profiles (MVS.DISPLAY.*).

System messages — from applications, subsystems, and the operating system itself — accumulate in one or both of two logs. SYSLOG is a per-system (per-LPAR) message log, produced as JES-managed output. OPERLOG is the sysplex-wide equivalent: a log stream, managed by the system logger, that merges messages from every system in a sysplex that has activated it, which is generally the more useful of the two when troubleshooting across a multi-system environment rather than one image. SDSF's OPERLOG panel is a common way to browse it interactively; both logs draw from the same "hardcopy message set" of messages destined for permanent logging.

An IPL (Initial Program Load) is the mainframe equivalent of a full system boot, started from the Hardware Management Console rather than by a console command: a hardware-level load step, followed by loading and initializing the nucleus, initializing general system resources, and Master Scheduler Initialization before the system is ready to accept work. Because an IPL takes the whole LPAR down and back up, it is a planned, scheduled event — coordinated through a change window — never something triggered as a side effect of routine diagnostic work.

Why it matters

An agent tasked with "check what's happening on this system" has safe, standard commands to start with (D A,L, D IPLINFO, reading OPERLOG/SYSLOG) that give a real picture without touching anything, which is the right posture before any command that could affect availability.

How to apply

• Start any investigation with read-only display commands (D A,L, D IPLINFO, and the JES/SDSF equivalents for jobs) before considering anything that changes state.
• Prefer OPERLOG over a single system's SYSLOG when the environment is a sysplex, since OPERLOG already merges the sysplex-wide view.
• Treat an IPL as requiring the same change-window discipline as any other full-system restart; never run shutdown-type commands (for example ending JES2 or removing a system from the sysplex) as part of routine diagnostics.

Pitfalls

• Confusing "no jobs shown in my USS shell" with "the system is idle" — D A,L and JES/SDSF cover batch and started-task activity that a USS process listing does not.
• Reading SYSLOG alone in a sysplex and missing events that only appear in another system's log or in the merged OPERLOG view.