Honestly, when I started working with this data many years ago, I thought it was the best thing since sliced bread. It’s really a shame that so few people know about this well-kept secret, which I’ll share with you here as part of my series on IBM i and its best-kept secrets.

You don’t need to understand the finer details about wait buckets in order to leverage their value. This article will introduce you to a few simple ways you can use them to better understand the behaviour of the jobs on your system and—here’s the good part—what you can do to get them to perform better. Over time, you’ll get a better grasp of the details and nuances as you seek to answer to the questions that arise from running these simple commands.

What is a wait bucket?

Think of it like this: There are 32 distinct buckets that account for your response time. This includes time spent running the job on the processor, time spent in the queue waiting to access the processor, time spent on a write, read, fault, record lock, and so on. Suffice it to say there are 32 of these buckets and once added together they can fully explain the run time of a job. Cool, right?

I like to add these buckets together across the entire system and see what I refer to as the “system signature.” I can often recognize a partition by its signature graph alone.  Why does this matter? Well, it allows me to quickly estimate the impact of proceeding with a system upgrade, adding memory or changing the disk subsystem. If a customer invests in hardware to improve performance, I want to be sure be sure it will do just that. If I see that a system is bogged down in “seizes” (a type of lock), I can be pretty sure the problem will only get worse, not better!

I can’t teach you everything there is to know about wait buckets, but I can definitely get you started. And, by the way, if you have any questions, just reach out to me. I love this stuff!

How to view wait buckets

Step 1: Type in WRKSYSACT (this will show you what’s happening on the system at this time))

Step 2: Hit F11 a few times until you see 6=Wait detail

Step 3: Enter 6 next to the job for the wait detail

• “Reserved” at the top of the list refers to the time dispatched to processor, which is mostly CPU time.
• The numbers are relative to each other. Don’t worry if they don’t add up to 100%.
• It will only show the buckets for which time was actually spent, so don’t expect to see 32.
• For example, if you see write time, journal time, record locks and CPU queuing, you have an idea of where the problem lies. Now you’re ready to start asking questions.
• For details on the 32 buckets, you can refer to: https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzahx/rzahxbasicwaitaccounting.htm

There are several other ways to see or leverage this helpful information. Here are some of my favourites:

1. Query the QAPMJOBWT file in your performance data library (usually QPFRDATA or QMPGDATA). I use this to create system-wide signature graphs.
2. If you have performance tools, drill into the job details from the Go Perform menu. This allows you to refer back to specific points in time.
3. Performance Data Investigator (PDI) is a free tool that graphs your performance data, including wait buckets.

Let’s keep the conversation going!

Thanks to everyone who provided feedback on my first blog article about IBM i’s best-kept secrets. Your input is truly appreciated. As always, please let me know if you have a secret you think I should write about. And if you’re enjoying this series, please share it with fellow system admins, developers or IT department managers. This is your chance to make their day—and mine!

You can reach me at: tamarav@r2i.ca