Fast Resolution for QZDASOINIT Job Issues
How are you currently set up to see which users or processes are impacting your IBM i environment? How quickly can your team identify potential runaway queries? What will it cost—in terms of time, lost productivity, and employment security—if a runaway database server job causes your system to grind to a halt due to insufficient resources?
For companies running IBM i, one recurring frustration IT teams must handle is runaway database jobs caused by external requests from business intelligence (BI) tools or users submitting and resubmitting queries. When these jobs are not caught in time, they pose a significant risk for total system availability loss. Even for the newest systems, runaway jobs can tax hardware resources to the point of failure.
QZDASOINIT Doesn’t Have to Be a Bad Word
With so many jobs sharing the same name, there could be hundreds of jobs contributing to escalating CPU, for example. The longer the process of identifying the offending job takes, the more CPU is consumed and the greater the risks and impact on resources.
Monitored groups in Robot Monitor show Total QZDASOINIT CPU and Total System CPU. System administrators benefit from proactive visibility into this group, its threshold, and the comparative context it provides. And if you’re not in front of the Robot Monitor display, the software will send you notification when these workloads misbehave.
One-click drilldown offers a detailed view of the jobs consuming the highest amounts of CPU to pinpoint the offending jobs instantly without running time-consuming manual searches in the QUSRWRK subsystem or running WRKACTJOB.
You can also click over to the SQL Statement tab to view the exact SQL statement causing system or application performance to plummet.
Get Started
How long did it take to locate that last runaway QZDASOINIT job on your IBM