While at a conference this fall, I was asked about job accounting and prestart jobs. I thought this would be a good blog topic.
If you have set up job accounting, the system will write journal entries to the job accounting journal when the accounting code is changed or when a job ends.
As I think we all know, prestart jobs are started with the QUSER profile, but swap to the requesting user profile to handle the work request. When the work request is completed, the job will be swapped back to run under the QUSER profile. Depending upon how the prestart job is configured, in particular, the maximum number of uses, one job may handle requests from many different users.
In prestart jobs, after the user profile is swapped, a job accounting journal entry will be written to reflect the change in the accounting code associated with the user profile the job is doing work for. As such, you will discover that prestart server jobs may have multiple job accounting journal entries.
The trick is in the analysis of the job accounting journal entries to correctly track the resources to the requesting user profile. Because the journal entry is written after the swap of the user profile is done, that journal entry will reflect the resources used by the user profile prior to the swap. Because of the order of the swap and the generation of the job accounting entry, you cannot rely on the job user profile or current user profile information in the job accounting entry. You can only rely on the accounting code. That is, the resources in the journal entry will correctly reflect the resources used for the accounting code.
There is an experience report that was written on Job Accounting. In the “Analyzing the data” section of the document, you will find more detailed information, including some graphics to provide an example, on how job accounting works with prestart jobs.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.