Address space uses unexpected CPU

When Address space uses unexpected CPU, remember: high CPU means a program is doing too much work, not that the machine is slow. Paging spikes mean the region is bigger than real storage allows.

What it means

• An address space burning CPU is usually looping, scanning, or reprocessing — the machine is fine, the work grew.
• Heavy paging slows everything down because the system keeps stealing pages; it looks like a CPU problem but is a storage problem.
• WLM can deliberately slow work down by placing it in a low-priority service class during online hours.

Common causes

• A recent code change introduced a loop or removed an early exit — classic the day after a deployment.
• A DB2 query lost its index access path and now performs a tablespace scan.
• REGION size too small for the workload, forcing constant paging.
• WLM policy puts the batch job in a low service class while online work runs.
• Common storage (CSA/ECSA) shortage after a new product was installed.

How to diagnose

• SDSF DA panel sorted by CPU% — the top address space is the suspect; note its job name and ASID.
• Use RMF Monitor III (or SDSF DA with delay) to see whether the job is CPU-bound or just waiting.
• Check D ASM and the RMF paging report: high page-in rates confirm paging, not a CPU shortage.
• Run D WLM,SYSTEMS and confirm the job service class — a low class explains slow response times.
• Compare SMF type 30 CPU time per step before and after the change date to prove the regression.

How to fix it

• Raise REGION (for example REGION=0M on a test run) to rule out paging before touching code.
• Fix the loop or restore the index; verify with EXPLAIN that the access path is back.
• Ask the systems team to move the job to a higher WLM service class for its batch window.
• Back out the deployment if CPU jumped exactly at the deploy time.

Example: Quick CPU check commands

REGION=0M lets the step use what it needs; if the slowdown disappears, it was paging.

Interview tip

• Q: Batch CPU doubled the day after a deployment, similar to Address space uses unexpected CPU. Walk me through your diagnosis.
• A: I confirm the timing with SMF type 30 CPU data, then find the top CPU address space in SDSF DA. If it is our job, I compare the DB2 plan and EXPLAIN before and after — a lost index is the usual suspect. I also rule out paging with a REGION=0M test run before blaming the code.

Prevention checklist

• Capture a CPU baseline (SMF 30) before every deployment so regressions are provable.
• Add a WLM service-class check to the post-deployment verification runbook.
• Set paging-rate alerts for batch LPARs in the monitoring tool.