Debugging RPG Programs on IBM i: A Beginner’s Guide to Squashing Bugs

Step 1: Set Up Your Program for Debugging

Before you can debug, your RPG program needs to be ready to spill its secrets. Here’s how to prep:

Compile with Debug Info: When you compile your RPG source (using CRTRPGPGM or CRTBNDRPG), add the DBGVIEW(*SOURCE) or DBGVIEW(*LIST) option. This tells the system to include debugging data. For Free Format RPG, I love *SOURCE because it matches what I see in my editor (like VS Code with the IBM i extension).

CRTBNDRPG PGM(MYLIB/MYPGM) SRCFILE(MYLIB/QRPGLESRC) DBGVIEW(*SOURCE)

Check Your Authority: Make sure you’ve got *CHANGE or *ALL authority to the program object. No one likes a "Permission Denied" buzzkill.

Step 2: Launch the Debugger

IBM i gives you a slick interactive debugger called the STRDBG (Start Debug) command. Here’s how to kick it off:

Start the Debug Session:

STRDBG PGM(MYLIB/MYPGM)

Hit Enter, and you’re in! This loads your program into debug mode. You’ll see a screen listing the program(s) you’re debugging.

Set Breakpoints: Breakpoints are your “pause buttons.” Tell the debugger where to stop so you can snoop around. For example:

  • F6 or type BREAK 100 to pause at line 100 of your source.
  • You can set multiple breakpoints—go wild!

    • Call Your Program: Run your program as usual (e.g., CALL MYLIB/MYPGM). When it hits a breakpoint, the debugger takes over, showing you the source code at that exact spot.

    Step 3: Step Through and Investigate

    Now you’re in the driver’s seat! Use these handy keys to navigate:

  • F10 (Step): Execute one line at a time. Perfect for watching variables change.
  • F11 (Step Into): If your program calls another module or procedure, this dives in. (Free Format fans, this is gold for subprocedures!)
  • F5 (Go): Resume running until the next breakpoint or the end.
  • F12 (Resume): Exit debug mode and let the program finish.

    • While paused, check variable values with:

  • EVAL MYFIELD: Displays the value of MYFIELD. If it’s a subfile field, you might see garbage if the record’s not loaded yet.
  • EVAL MYFIELD = 'NEWVALUE': Change a value on the fly to test fixes.

    • Step 4: Watch for Common RPG Gotchas

    Debugging subfiles or file I/O? Here are some classics to catch:

  • Subfile Errors: Is SFLRCDNBR set wrong? Check your relative record number (RRN) logic.
  • File Reads Gone Wild: If your READ or CHAIN isn’t fetching data, peek at the file status (%STATUS) or check your key fields.
  • Display File Drama: Mismatched field lengths between your RPG and DSPF can cause weird output—compare them!

    • Step 5: Wrap It Up

    Once you’ve nabbed the culprit, exit the debugger with ENDDBG:

    ENDDBG

    Fix your code, recompile, and test again. Rinse and repeat until it’s smooth as a freshly printed green-bar report.

    Pro Tips for IBM i Debugging

  • Use STRISDB for Legacy: If you’re stuck on an older system without STRDBG support, STRISDB (Start Interactive Source Debugger) works for traditional RPG, though it’s clunkier.
  • Green Screen Fatigue?: Pair your debugging with Visual Studio Code’s IBM i extension—it integrates with STRDBG and shows source in a modern UI.
  • Log It: Add DSPLY statements to output key values during testing. It’s old-school but effective.

    • Debugging RPG on IBM i isn’t just about fixing errors—it’s about understanding your program’s soul. With STRDBG in your toolkit, you can tackle subfile snafus, file flops, or logic loops like a pro. So next time your program throws a tantrum, don’t panic—debug it, fix it, and keep the IBM i humming.

    Got a tricky bug you’re wrestling with? Drop a comment below, and let’s squash it together!

    Done?
     Mark lesson complete
    Previous Lesson
    Next Lesson
    {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
    >