Re: SOX monitoring and journal interpreter

Most of what production access needs you list would be handled by the change management software. Subsequently that info would get reported to SOX.

You do mention handling manual data errors. SOX would prefer that these get handled by a fix application. These would end up going through your change management. Again, they have their documentation. Basically, the days of manually fixing data, in my opinion, is over. Someone in you your company will require the logging of the modification.

Lloyd

On Oct 20, 2017, at 9:02 AM, Darren Strong <darren@xxxxxxxxx> wrote:

In our environment, IT does need to make changes to data on the production
machine. Reasons include, mass data changes, messaging software support,
high availability software support, priming data changes for modification
or new programs, customers sending bad data via EDI that has to be
corrected because they refuse to send correction, malfunction in program
writing incorrect data either by program design or user error. Its
difficult for me to imagine a world where things are so perfect that IT
wouldn't have to make data level changes on the production system.



___________________________________
Darren Strong
Dekko





From: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
To: wdsci-l@xxxxxxxxxxxx
Date: 10/20/2017 08:43 AM
Subject: Re: [WDSCI-L] SOX monitoring and journal interpreter
Sent by: "WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx>



Hi Darren

This depends on what "activity" means - we don't allow developers to
change data on the production LPARs, so we don't have to record that
kind of thing.

In a very simplistic way, I think of SOX as related to ensuring process
- how things are done.

We use Turnover change management app - it generates logs for each
promotion/distribution to production - we convert these SPLFs to PDFs
and store for auditing later.

If there are changes to file formats, say, those are logged by
Turnover, and Turnover takes care of preserving the data.

So it seems to me that you don't need to go at some types of file
changes - you mention "actual file data" - I would think it rare that
developers can even DO that.

HTH
Vern

On 10/20/2017 7:25 AM, Darren Strong wrote:
Thanks to SOX we're asked to develop a system to monitor activity by
developers on the production system (An IBM i). First, has anyone else
done something like this, and in an overview, how did you do it?

For my attempt, I'm summarizing file journal entries based on some
criteria, like user, and generating a summary report/spreadsheet with a
concatenated key. Then from that, I want to allow an auditor to drill

into

that summary to get the detail of file changes. For now, I'm

copy/pasting

this "key" into another report program that is going to report change by
change, what happened in that file for that user, job, etc.

Anyway, I'm using the DISPLAY_JOURNAL SQL table function, and I have

this

huge and varying format ENTRY_DATA column. This is where the actual file
data is. I'd like to split this into the file's columns on the
spreadsheet, which I could do if it was all character data, but I'm

having

trouble figuring out how to split numerics of varying size and format

into

something in an RPG variable. If I use %subst to break a chunk of the
buffer out, what kind of field would I feed that into, because the
datatypes will vary so much?


___________________________________
Darren Strong
Dekko

--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/wdsci-l.


--
This is the Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/wdsci-l.