The Program Status Word (PSW) is one of the first things to look at in a dump because it captures the current execution state of the processor and the address of the next instruction to be executed.
In practical debugging, the PSW helps answer a few immediate questions: where execution was headed, whether the task was waiting, whether certain interrupts were enabled, and what addressing mode or control state clues might matter before you even inspect the failing instruction.
The PSW reflects general system state, including whether the machine is waiting or processing, whether I/O interrupts are enabled, and the address of the next instruction to execute.
Working rule: when you first open a dump, do not try to decode every PSW bit at once. Start with the instruction address, the wait state indicator, and any obvious interrupt-mask flags, then move outward to registers and nearby instructions.
The fastest practical step is to take the PSW next-instruction address and map it to a module, CSECT, load module listing, or disassembly. If the PSW keeps showing the same address or a small repeating series of addresses across multiple snapshots, the program is likely looping.
In an abend the address tells you where to start reading. In a suspected loop, repeated PSW snapshots can reveal the repeating path before you fully decode register contents.
Simple checklist: copy the PSW address → identify the module or routine → check nearby instructions → compare the condition code with recent arithmetic or compare logic → inspect registers and storage that feed that code path.
The PSW shows processor state around the current execution point, but you still need registers, surrounding instructions, storage contents, and calling context to understand why control arrived there. It is easy to confuse the address of the next instruction with the instruction that actually caused trouble — depending on the failure type, the address shown may be one instruction past the problem.
Mainframe data structures generally require their starting address to be on a specific boundary. Misalignment can cause program checks or unexpected behavior, so recognizing boundary codes quickly is useful during dump reading.
Enter any hex address into the Mainframe Calculator. The small code column between Hex and Notes displays H, F, or D automatically, or leaves it blank for an odd address. This lets you verify alignment for any value you are working with without doing the mental arithmetic yourself.
Example: if you compute a DSECT offset and land on address 00123456, the calculator shows F — a fullword boundary. If you land on 00123457, the column is blank, which immediately tells you the address is misaligned for any multi-byte structure.
Much of hands-on mainframe debugging involves computing where a field is relative to a known base address. The Mainframe Calculator is built specifically for this kind of work.
If you need to compare several alternative offsets, enter each one in a different OFFSET row and toggle them on or off with the plus/minus button. The SaveArea lets you park an intermediate result so you can continue working without losing it.
Coming soon: worked examples of real dump reading scenarios using the calculator, including offset chains, displacement arithmetic, and common control block layouts.
EBCDIC (Extended Binary Coded Decimal Interchange Code) is the character encoding used on IBM mainframes. Unlike ASCII, EBCDIC does not place digits and letters in a contiguous range, which matters when you are examining character data in a dump.
Notice the gap between I (C9) and J (D1) and between R (D9) and S (E2) — these are not contiguous ranges the way ASCII A–Z is. A quick range check in a dump storage display helps you confirm whether bytes contain printable characters or binary data.
Coming soon: a full EBCDIC printable-character table and tips for spotting common data patterns in hex dumps.