Detect controls for program changes

[Jim Damato <jdamato@xxxxxxxxxxxxxxxxx>]

Is anyone else running detect control reports for audit compliance or SOX?
We're running a daily report to detect changed program objects (among other
things), so that the previous day's changes may be validated against our
change control documentation.  (Five years ago I couldn't imagine that I'd
ever have to do this)  The report is driven off of objects' change date and
time from DSPOBJD to outfile.

We're getting "ghost" changes periodically -- unaccounted program changes.
When we started cross-referencing the report against the object audit
journal the journal confirmed the ghosts.  There is no object audit journal
activity to account for the object change.

It turns out that the ghost changes occur in RPGLE programs with embedded
SQL.  Apparently these programs have  built-in workspace for SQL processing.
At run-time the program might have to resize the workspace if the data set
requires such a change.  As a result the program object's change date is
updated, but no activity is logged to the object audit journal.  I got all
this information when I opened a PMR.  The explanation for the lack of a
journal entry was "the system is changing the program for the systems own
use".  The PMR was closed with everyone's favorite cop-out -- "working as
designed".

I'm stuck.  Every time we go through an audit one of the big accounting
firms asks for a list of programs with their create and change dates.  The
auditors cross reference the last change dates against our change control
paperwork.  I can't see a way to really audit change control on the AS/400
because there's no way to differentiate between an undocumented program
change and an internally generated system change.

Is anyone approaching such audits differently?

-Jim

James P. Damato
Manager - Systems Administration
Dollar General Corporation
<mailto:jdamato@xxxxxxxxxxxxxxxxx>