Monitoring, problem determination, and troubleshooting
This domain tests a disciplined approach to monitoring and diagnosis. You must know where to look first, how to narrow scope, and which server or client logs answer which question.
Core rules
Start with scope: one node, one schedule, one storage pool, or server-wide. QUERY ACTLOG shows recent server activity. QUERY SESSION shows active client sessions; QUERY PROCESS shows server processes such as migration or reclamation. QUERY EVENT shows schedule outcomes. QUERY STATUS, QUERY DB, QUERY LOG, and QUERY STGPOOL check server and storage health. On the client, inspect dsmerror.log, dsmsched.log, and the client options. Server messages with ANR prefixes belong in the activity log; client messages often use ANS prefixes.
Worked example
A nightly backup fails for one node. Check QUERY EVENT for that node and schedule, then QUERY ACTLOG around the start time. If the server shows no session, check the client scheduler service and dsmsched.log; if authentication fails, check the node password and NODENAME; if storage is full, check QUERY STGPOOL and scratch volumes. The reasoning is to separate scheduling, authentication, network, and storage causes before changing anything.
Traps
Do not begin by restarting the server. Do not read only the client log when the server activity log has the decisive message. Do not confuse a failed schedule with a failed backup session. Activity log retention may be too short for old incidents, and a summary status can hide the first error.