Re: Accounting code and journaling

Åke Olsson wrote:

We have a request from the auditors it goes as follows:

They want to be able to see in the database journal any changes
that were related to a "change request" i.e. all database updates
performed by people in IT operation and support. The basic idea
is that way they can follow up on grounds of "who did what to
this record and why?" The who is the userid that already is in
the journal entries. The "why" is the problem part.

Our starting point was that we should set the accounting code of
the job to the change request ID that we started working on and
hopefully that this accounting code would make its way into the
journals. A lot of other job information is in there so why not
this?

Apparently the accounting code does not get journaled
automatically.

Should it? Will the journaling behavior change if we also start
the accounting journal? (Not active at the moment).

I am not aware that, and am doubtful that, the job accounting code would suddenly start appearing in journal entries that either track object changes or auditing, just because QACGJRN had been activated for a QACGLVL. The job accounting exists primarily for tracking CPU for jobs, e.g. to charge a department or user for the amount of system resources they consume, so IMO the accounting code attribute [ACGCDE] should not be sent as part of every journal entry. Although that accounting code might be valuable for the noted scenario, surely there are hundreds of other attributes which would also be nice in that & other contexts; short of being configurable for what is included in journal entries, choices were obviously made about what limited amount of information would be included.

If the assumption can be made that the change-request-ID could be set as the job accounting code for whatever upcoming processing was associated with that job, then that same value could instead be sent to a [change request tracking] database file as a new\updated row or journal as its own journal entry [SNDJRNE]. That data can then be used to correlate the job name from any change activity logged in other journals, to the change-request-ID by the same job name, since that point in time. An end-time or duration might need to be inferred if the design for the change request activity environment would not be sure to send another entry when the processing of any one change-request-ID had been completed. If the system change tracking request identifiers were stored as rows in a database file, then commitment control could be used to update the row which then identifies [in the journal entry; or the row update could itself track] the user\job performing the change processing, and then the commit entry could log the completion.

Regards, Chuck