RE: Detect controls for program changes

IBM support suggested that I submit a DCR, and maybe I will.  My experience
with DCR's has been "if we won't admit it's a bug we probably won't think
its necessary to change the design either".  Admitting you have a problem is
the first step toward recovery -- If they'd develop a PTF we could fix our
detect report quickly.  Even if IBM accepts the DCR, credibility in
management and our audit dept. will be completely shot before we get
resolution.

IBM did say:

"The update to the access plan can possibly be prevented by              
ensuring the object is always locked or ensuring users have only *USE to
the program while at the same time ensuring no users with *ALLOBJ spcaut
or any sufficiently adopting programs call the program."

I liked the idea about locking the object.  I'll get right to work figuring
out a way to maintain locks on all production programs.

The problems with ensuring users only have *USE access are:

-I'd have to completely overhaul security
-That security method is not supported by the product environment
-If IBM is saying that the system is making the change to the program howcum
the user needs authority?
-If I use one of their work-arounds to block the system from making the
change, aren't I damning my applications to less-than-optimal SQL?

The sad thing is that our methodology for auditing changes works for VMS,
Unix, and Windows.  The AS/400 is the one system where we can't meet SOX
compliance for change control.  And Rochester apparently is comfortable with
that.  For our company this becomes one more justification for folks to say
that the AS/400 is the old legacy system that can't keep pace with the
other, better platforms, and that it doesn't support open methods.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of 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.