Re: Accounting code and journaling -- MIDRANGE-L

Many thanks Chuck!

We have come to the conclusion that we will make the programs where the task-id is entered both add a row to a table and do a "chgacgcde".

This way the information is stored in the accounting journal (tested that an extra entry is created there whenever a job changes its accounting code) as well as in a table.

Based on the job-id and timestamp of the database journal it will then be possible to retrieve the task-id that was current for that job at that time.

The thing that we have to prove to the auditors is that *if* they give us a request to investigate a particular "who did what to which piece of information and why" scenario the information is available. We will not have to create a full reporting system for all changes, at least not right now.

Med vänlig hälsning / Best regards

Åke H Olsson

Box 433   SE 551 16 Jönköping   Sweden   visit: Brunnsgatan 11
phone: +46 (0)36 342976   mobile: +46 (0)705 482976 fax: +46 (0)36 34 29 29
ake.olsson@xxxxxx    www.pdb.se

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

------------------------------