Re: Audit trail of file changes

James,

Remember, tapes qualify as "indefinitely". What requirement is there that
these must be "online" versus "near line" or "off line"? Assume tapes are
ok, after all, doesn't it fit the requirement of "keeping the trail"?
Don't ask a question you don't want to hear the answer of. If it doesn't
qualify in the future you can always restore them - therefore, it's not an
irreversible decision.

Gee, how would you do that? QAUDRCV0001 contained the data from 01/21/09
- 01/23/09 and was saved on volume TAP123. That volume is located at ...
Summary: You may wish to log this data when you save them off to tape.
See WRKJRNRCV for
Attach date . . . . . : 04/12/09 Attach time . . . . . : 17:58:06
Detach date . . . . . : 04/12/09 Detach time . . . . . : 17:58:08
Save date . . . . . . : 05/21/09 Save time . . . . . . : 23:37:45
We wrote a purge program (pre Mimix) that would delete any journal
receiver that was
- detached for over x days
- saved
Write one like that which then records that data to a file and you're in
like Flynn. Hint: Check the completion message on the save for the
volume id. And for Christ's sake use different volume id's on every tape
cartridge you have. Get over the old S/34 habit of IBMIRD for all volume
id's that some people do. Offsite storage facilities, like Iron Mountain,
live and die by these volume id's being on the barcode on the tape. That,
and IBM utilities like PRTERRLOG TYPE(*VOLSTAT) VOLTYPE(3590) will tell
you when the tape should be trashed because of too many write errors.

Notice this on STRJRNPF?
STRJRNPF OMTJRNE(*OPNCLO)
Journal entries to be omitted . > *OPNCLO
*OPNCLO
Open and close entries are omitted. Open and close operations
on the specified file members do not create open and close
journal entries. This prevents the use of TOJOBO and TOJOBC
entries on the Apply Journaled Changes (APYJRNCHG) and Remove
Journaled Changes (RMVJRNCHG) commands, but it saves some
storage space in the attached receivers.
I can't imagine that being a real space saver in most applications. Some
situations I can imagine it though, like if someone forgets to specify FOR
FETCH ONLY on a SELECT, and this happens a lot. But what the heck, IBM
did it so there must be a reason.

You cannot purge unwanted data from a journal. IBM goes to great lengths
to maintain the sanctity of a journal. In fact if there's a gap between
journal receivers that has to be noticeable also. Previous and next
journal receiver entries are stored in each receiver. This sanctity is
why a journal may be respected evidence while a log file that anyone with
*ALLOBJ authority can UPDDTA records out of it will just get snickered at.

There are options in CRTJRN that you may wish to study to reduce size
Minimize entry specific data, MINENTDTA. Read the help. Storing
everything makes it really easy to look at the receiver and see what was
changed. Much like DSPPFM shows you the whole record. This is the
default. Another entry is field body. So if you only changed one column
in a row it will only show the changed column, not all of them. This
reduces space. Now, if you only changed a character or two (like from
'John' to John 2') then you can reduce it down to the changed character. I
really wouldn't want to look at that receiver without a good tool. I am
sure that someone somewhere has tools that can query receivers. DBU has
some and we use it a little. By the way, we use Minimize entry data :
*NONE. But we have the disk available.

Rob Berendt