In the 10/1 Administrator Tip there was an article on the proper way to end WRKACTJOB. I believe it is in error, as WRKACTJOB has been changed since this information was correct. There is not a job collecting the statistics constantly. In fact, the stats are those continuously collected by the system. The only work done by WRKACTJOB is done when the user refreshes (F5), resets (F10), or restarts (F13), when the various machine and resource data is retrieved and processed.
I just did a quick test with WRKACTJOB up in one session and WRKSYSSTS in another. I reset the WRKSYSSTS display (F10), and there was no noticeable change in CPU% while my WRKACTJOB session was idle. Then I shutdown the WRKACTJOB (admittedly, F3) and there was no difference. Then I started WRKACTJOB and ended with SYSREQ 2 -- again no difference.
Here is something from Ed Fishel of IBM that was included in MIDRANGE dot COM's Midrange-L mailing list. It seems that ending with SysReq 2 causes WRKACTJOB to do more work when starting up again:
Q. I've often heard that WRKACTJOB takes up a lot of CPU power. Why?
A. Over the years there have been changes to the way WRKACTJOB works. What was once true for DSPACTJOB on System/38 is no longer true for WRKACTJOB. Unfortunately people still pass on the old recommendations. In the following paragraphs I will attempt to provide an up to date description of WRKACTJOB.
When you exit WRKACTJOB by using Enter, F3, or F12 you have totally ended WRKACTJOB. The statistics reported by WRKACTJOB are not collected by WRKACTJOB. The collection of those statistics is always done for every job in the system by LIC. This collection occurs even when WRKACTJOB has never been used on the system.
WRKACTJOB does keep an internal space somewhere to save the current statistics so that it can report the changes the next time it is used within the same job. You can reset those statistics by using F13=Reset statistics or by using the RESET(*YES) parameter on the command. Using System Request followed by option 2 will cause WRKACTJOB to destroy the internal space it uses to save its statistics. It will then create another space the next time it is run. The space is also destroyed at the end of the job, so there is no advantage to using System Request followed by option 2 to end WRKACTJOB. The only WRKACTJOB resource you release when you sign off is the internal space object used to store the statistics. The size of this space varies based on the number of active jobs in the system. By signing off and then on again after each use of WRKACTJOB you are forcing it to recreate that space in the new job. This will waste more resources than it saves. Since WRKUSRJOB does not report any job statistics it does not need to use a space to save them.
In the past, the reason for the recommendation to not use WRKACTJOB (or DSPACTJOB on System/38) was because of the resources that it used while it was building the data to be displayed. In the past WRKACTJOB searched all work control blocks on the system looking for active jobs. When the system had lots of jobs with a status of JOBQ or OUTQ it could take WRKACTJOB a relatively long time to find just the active jobs. This was changed several releases ago. Now WRKACTJOB uses a much faster LIC interface to materialize the list of active jobs.
And in a later post on the same topic, Ed says:
The purpose of my post was to set the record straight on how WRKACTJOB works.
I have been told that on a system with tens of thousands of active jobs, even one user using WRKACTJOB is too many. Even when the WRKACTJOB list is subset it still looks at the control blocks for each active job just to see if the job should be in the list. I was also told that the GUI interfaces can have a smaller impact on the system when the list is subset to a small number of jobs in a subsystem, and if the default (or fewer) output columns are used.
My recommendation is to use WRKACTJOB sparingly. Use WRKSPLF, WRKSBMJOB, and WRKUSRJOB whenever they provide the information you are looking for.
