Re: Journalling All Files

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Before rolling your own today, consider 3rd party software that
provides everything you need.

Here's one I'm aware of:
http://www.powertech.com/powertech/PowerTech_Web_SecurityAudit.asp

I'm sure there are others.

Charles

On Sat, Sep 12, 2009 at 6:53 PM, PaulMmn <PaulMmn@xxxxxxxxxxxxx> wrote:
> Jim--
>
> I think you received 2 copies of my message because I sent one copy
> directly to you, the other came through the Midrange mailing list.
>
> We wrote a program that can extract the data from any file.
>
> You need to create a custom retrieval file for each data file's
> records you plan to save.  This file has all the 'journal' fields
> that you get retrieving a journal transaction, plus all the fields
> from the original file's DDS (or retrieved SQL).
>
> You then retrieve the journal entries for a single database file to a
> work file.  This is a WIDE record-- it has the journal fields (date,
> time, job, user that created the transaction), copies of the database
> fields (the DDS), plus a lot of extraneous journal information that
> we're not interested in.
>
> Then you copy this work file to your custom file, FMTOPT(*NOCHK).
> This will truncate at the end of the DDS fields, and will result in a
> lot more compact data.  This file can be analyzed with any database
> tools.
>
> We've encapsulated the 'journal entry retrieve' and the CPYF into a
> program-- we just pass parms for a whole mess of files.
>
> The problem with this technique is that you need to run this same
> process for every database file.  And retrieving journal entries this
> way means that for every file you need to scan the same journal
> receivers.  Over.  And over.  And over and over again.
>
> Carsten Flensburg (sp) showed a more efficient technique using the
> RCVJRNE command. This command piggybacks on the IBM journal logic.
> You tell the system, "While you're capturing transactions, if you see
> any for this list (a, b, c, e) of files, give me a copy as well."
> This means that for a large number (see command limitations), you
> have one job waiting for transactions to happen, and another program
> that will process them once found.
>
> See
> http://www2.systeminetwork.com/artarchive/index.cfm?fuseaction=viewarticle&CO_ContentID=17415
> We mutiliated his procedure for our needs, but it's a lot more
> efficient than retrieving journal entries!
>
> --Paul E Musselman
> PaulMmn@xxxxxxxxxxxxxxxxxxxx
> --
> 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.