Re: Log all PF changes?

If you're already journalling all (most) files, it seems improbable that
you can reasonably keep journal receivers around forever. I keep 90 days
where I'm at now; which takes about 4% of my disk space. Where I used to
be, we could only keep 7 days.

Unless you journal this one particular file to it's own journal. However,
when using commitment control, IBM strongly recommends (requires?) that all
files for a given commit cycle be journaled to the same journal. IIRC,
rollback doesn't work right when different journals are involved.

By harvesting the data, you can just keep the one files changes you need to
keep. You can also keep it in a an efficient manner.

For an audit log, off the top of my head..
SEQ#, TIMESTAMP, LIBRARY, TABLE, USER, PROGRAM, <xxx>, COLUMN_NAME,
ORIGINAL VALUE, NEW_VALUE

Lastly, if you're using the raw journal format for archival...consider how
you would deal with a new column being added to the table. Suddenly,
you're not dealing with the same format anymore.

The problem with rolling your own, IMHO, if you _HAVE_ to keep this
information, for legal reasons. Then it's on you to prove that your
solution meets the requirement. Whereas with a third party, it's on them
and they should already have that proven.



Charles




On Wed, Jan 6, 2016 at 4:40 PM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:

We currently run journaling, and receivers that are both detached and
saved are deleted daily.

Viewing what changed would be via an app that I would write.

I can see issues with HA, but I don't see HA ever happening here so I'm
not too concerned. I don't see off-hand how keeping receivers would
adversely affect commitment control however.

What are the advantages of harvesting the journal data and storing it in
DB2 or the IFS, space?



-----Original Message-----
From: Charles Wilt [mailto:charles.wilt@xxxxxxxxx]
Sent: Wednesday, January 06, 2016 3:23 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Log all PF changes?

Just a word of advice...

If you don't currently use journalling, and you want to start journally
for just this one file...

Then sure, it would make for a quick and easy solution.

However, some things to think about
- How do you intend to display the journal entries? DSPJRN in an of
itself is not very pretty. The table's data is just one big blob. It gets
even more complex when you have nullable fields and/or MINENTDTA() of other
than *NONE.
- If you ever need journalling for something else such as commitment
control or HA, then you're going to have problems keeping receivers around
forever.

IMHO, planning on keeping journal receivers around forever is not a good
idea.

Consider instead a program that harvests the journal entries and stores
them someplace.
You may be able to start with the CMPJRNIMG command as laid out here:
http://www.securemyi.com/nl/articles/databaseaudit.html

Personally, if I really _HAVE_ to (for legal reasons) have a record of
changes forever; then I'd be looking at a third party compliance tool.
http://www.helpsystems.com/powertech/products/datathread
http://www.cosynsoftware.com/index.asp?CID=product&PID=CAT

http://townsendsecurity.com/products/file-integrity-monitoring-advanced-tools

http://www.razlee.com/products/security/ap-journal/ap-journal_regulation_compliance_o.php

I'm sure there's more...

Charles




--
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.