RE: Detect controls for program changes

["DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>]

Rob, are you talking about the SQL package that is contained within the *PGM
object?  Each time the program runs, SQL may potentially change the package
to "tune" the query to the environment.  Since this is completely controlled
by DB2, I doubt that it makes much difference which user the program runs
under.  

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
Sent: Friday, January 28, 2005 11:39 AM
To: Midrange Systems Technical Discussion
Subject: Re: Detect controls for program changes


I wonder, if the user running the program does not have access to change 
the program, does it still modify the program anyway with the new access 
path information?  Of so, how?  Perhaps you could submit that as a 
security breach?  Could that same method be used to patch other areas of 
the program object?

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





rob@xxxxxxxxx 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
01/28/2005 12:31 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Detect controls for program changes






I hear you.  Our change management software always reports "This object 
has been changed outside of Turnover..." everytime we promote a SQLRPGLE 
program.  Granted we don't do SOX (Chapter S corporation).  Perhaps, with 
the advent of the SOX hassle you should submit a DCR to come up with a way 

to determine if the change was strictly SQL access path related or what.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Jim Damato <jdamato@xxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
01/28/2005 11:41 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"'MIDRANGE-L@xxxxxxxxxxxx'" <MIDRANGE-L@xxxxxxxxxxxx>
cc

Subject
Detect controls for program changes






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>

-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.