Tip of the Week – WRKACTJOB

Hurry and find out what is killing the system!

We all have heard that from time to time. Some user is running an SQL that looks at over 300 million records and it pretty much kills the system. On top of that the System i will let it run because it can handle it and not crash. That is the upside, the down side to this problem in large System i shops is that all the Admins run back to their desks and what do they do?

WRKACTJOB

So not only do you have a Query taking up 105% of the CPU, now you have 5 other Admins all hitting it with one on the commands with the most overhead. Work with Active Jobs is in fact a very nice and telling screen but you as the Admin can wreck the system just as fast if enough of you type that command at the same time. If you know all your ODBC jobs run in a separate subsystem (we will cover that later) then just use WRKSSBS SBS(name of subsystem) instead. You can also just use WRKSYSACT and see who is beating the stuffing out of the CPU and if my memory serves it a command only one person can use at a time.

So be careful in times of crisis with the WRKACTJOB command. It can just make matter worse. Every shop I have ever been in has this problem. The CPU is trashing and all the Admin do a little more damage so it just takes more time to recover.

I got an email from Chris Whisonant saying that this is true on older systems but with never version of the OS and Hardware it has gone away. To that I say, thanks Chris. It used to be a rule of thumb but I guess IBM got wise to the problem and kind of fixed it. I would still only test the hardiness of the system after hours.

Fun things to do with WRKACTJOB