Self-Study Runbook

This is your guided, self-paced workbook for building lasting IBM i fluency with the AI platform. Unlike the live demo runbook (which is optimized for short presentations), this version is designed for deliberate practice. Each exercise includes learning objectives, step-by-step prompts, expected outcomes, reflection questions, and checkpoints.

Work through one exercise per session. Run every prompt yourself. After each exercise, answer the reflection questions in your own words. This is how the platform turns you from a user into a confident operator.

How to Use This Workbook

  1. Read the exercise objective and glossary terms first.
  2. Run the prompts exactly as written (copy-paste).
  3. Compare your results to the “Expected Outcome” section.
  4. Answer the reflection questions before moving on.
  5. If anything is unclear, open the Glossary or Tools Reference and re-observe.

All exercises stay in the Observe → Recommend boundary unless explicitly marked “Act with approval.” You can safely run every exercise on a production partition.

Exercise 1: Your First System Health Snapshot

Learning objectives

  • Understand the difference between a broad health check and targeted queries using facade tools.
  • Learn to interpret ASP utilization and job status at a glance.
  • Practice turning raw tool output into a one-paragraph summary.

Glossary terms to review first
ASP, Job, Subsystem, QSYSOPR

Prompts (run in order)

  1. Run a system health check and summarize the biggest risks. (Invokes inspect_system view: "health")
  2. Check storage usage summary and tell me whether capacity looks healthy. Focus on ASP 1. (Invokes inspect_storage view: "summary")
  3. Check active jobs and show the top 5 CPU consumers with their subsystem names. (Invokes inspect_jobs view: "active")
  4. Check QSYSOPR and list any unanswered inquiry messages. (Invokes inspect_messages view: "qsysopr")

Expected outcome
You receive a concise paragraph that states current ASP %, number of active jobs, top CPU consumers, and whether operator attention is required. No tool should have mutated system state.

Reflection questions

  • Which ASP is closest to capacity? Why does that matter?
  • Were any jobs in MSGW or LCKW? What does that status mean?
  • How would you explain this snapshot to a non-technical manager in two sentences?

Checkpoint
You can now run a repeatable daily health check without assistance.

Exercise 2: Investigate a Specific Job

Learning objectives

  • Move from broad observation to targeted diagnosis.
  • Read and interpret a job log.
  • Practice forming a hypothesis before planning any action.

Glossary terms
Job, Job Log (see spool file / message queue entries), Message Queue

Prompts

  1. Check active jobs and find one that has been running or is currently in a waiting status like MSGW or LCKW. (Invokes inspect_jobs view: "active")
  2. Get the job log for that job using its qualified name and summarize the last 20 messages. Highlight any CPF or MCH errors. (Invokes inspect_messages view: "job_log")
  3. If the job is waiting on a lock, inspect active locks to identify the object and library. (Invokes inspect_objects view: "object_locks")

Expected outcome
You can name the exact job (number/user/name), its current status, the last error or wait condition, and any database or system object involved.

Reflection questions

  • What was the root cause visible in the job log?
  • Would ending this job have been safe or risky? Why?
  • Which tool would you use next if you needed to change the job attributes or end it?

Checkpoint
You can independently diagnose a slow or stuck job using only Observe tools.

Exercise 3: Plan a Safe User Change

Learning objectives

  • Experience the full Recommend phase before any mutation.
  • Understand least-privilege principles in practice.
  • See how the platform generates an approval request and preview credentials.

Glossary terms
User Profile, Authority, Group Profile, Object Authority

Prompts (Recommend only — do not execute yet)

  1. List user profiles that currently have *ALLOBJ or *SECADM special authorities. (Invokes inspect_users view: "special_authorities")
  2. Plan creation of a new user DEMOAPP with text "Demo application service account" and no special authorities. (Invokes manage_user_profile operation: "create", mode: "preview")
  3. Plan resetting DEMOAPP's password and forcing a change at next sign-on. (Invokes manage_user_profile operation: "reset_password", mode: "preview")
  4. Review the generated plans. Note the exact CHGUSRPRF and CRTUSRPRF commands the AI proposes.

Expected outcome
Two clean Change Plans with redacted credentials, explicit authority boundaries, and a pending previewId and previewToken that a security officer could approve.

Reflection questions

  • Why does the plan refuse to grant *ALLOBJ even if you ask?
  • What would happen if you approved the reset without verifying the user exists?
  • How does the approval workflow protect both the system and the operator?

Checkpoint
You understand why every user change must go through a plan step and can explain the approval gate to a colleague.

Exercise 4: Storage Deep Dive & Find the Culprit

Learning objectives

  • Use storage consumer ranking to locate large libraries or IFS directories.
  • Connect storage pressure to real objects and owners.
  • Practice turning data into an action plan.

Glossary terms
ASP, Library, IFS, Save File

Prompts

  1. Find storage consumers and rank the top 10 libraries by size. (Invokes inspect_storage view: "consumers")
  2. For the largest library, list its biggest objects and note their types and owners. (Invokes inspect_objects view: "library_objects")
  3. If an IFS directory appears large, list its directory contents and summarize file sizes. (Invokes inspect_ifs view: "directory")
  4. Plan a save of the library QGPL/QPRINT to a save file using a CL command preview. (Invokes plan_run_ibmi_command for a SAVOBJ command)

Expected outcome
You can name the top storage consumer, the object types driving the size, and have a ready-to-approve save plan if cleanup or archival is needed.

Reflection questions

  • Was the largest consumer a production library, a test library, or old save files?
  • How would you decide whether to delete, archive, or compress the data?
  • Which tool would you use to confirm no active jobs are still writing to that library?

Checkpoint
You can independently investigate and plan remediation for storage pressure.

Exercise 5: Full Approval Lifecycle (Observe → Recommend → Act with Approval)

Learning objectives

  • Experience the complete governed change workflow.
  • Understand the difference between planning and executing.
  • See how audit logging captures every step.

Glossary terms
Approval (see security section), Run IBM i command, Security Officer

Prompts (stop before final Act if you do not have approval permissions)

  1. Check whether the FTP server is currently running. (Invokes inspect_network view: "servers")
  2. Plan ending the FTP server and explain the risk to production file transfers. (Invokes manage_tcp_server operation: "end", mode: "preview")
  3. Create the approval request (the preview call will automatically generate a previewId and previewToken).
  4. (If you have an approver role) Approve the request in the Hub UI to generate an approvalTicket.
  5. Execute the approved plan by calling the execution tool. (Invokes manage_tcp_server operation: "end", mode: "execute" with the ticket)
  6. Verify the server is stopped, then plan and execute the restart via manage_tcp_server in "preview" then "execute" modes.

Expected outcome
A complete audit trail: Observe results → Change Plan → Approval request + comment → Execution log → Post-action verification. The FTP server is stopped and restarted under full governance.

Reflection questions

  • What would have happened if you tried to end the server without a plan?
  • How does the approval comment help during an audit?
  • Why is it safer to plan the restart in the same session rather than “just remember to start it later”?

Checkpoint
You have completed a real, approved, audited change using the full Observe → Recommend → Act lifecycle.

Next Level

After completing these five exercises you are ready for:

  • The full Admin Playbooks for daily operations.
  • Running custom SQL recipe diagnostics via run_sql_recipe.
  • Exploring PowerHA, journaling, or network tools using the same Observe-first pattern.
  • Contributing new procedure articles to the in-tool help system.

Return to the Learning IBM i with AI landing page for the recommended progression, or open the Glossary any time a term is unclear.

You now have both the vocabulary and the repeatable workflows to manage IBM i confidently with AI assistance.

Last updated: 2026-05-21