Comparing two records

[Huddy]

Re: Comparing two records

agreed tom.

I'm looking at the CMPJRNIMG, i'm guessing this is the way I'm heading but the information it's providing is quite vague in that it's not specific to field values.

[tomliotta]

Re: Comparing two records

how do i go about reading the journal for a specific file and report the neccesasary level of detail.

Date of change
time
field and field description
value.

It can be done the same ways on practically all systems in the AS/400 line going back a few versions of the OS, but better methods are possible on later versions. And the ways to do it can change for different programming languages.

What OS version should be targeted? What language do you need?

[ChrisL]

Re: Comparing two records

Huddy, if you look at the DSPJRN command, you can specify specific files - I'm sure there is something on this site somewhere that gives you a journal extract command which will allow you to dump all of the data to a file. If you can't find it let me know and I'll see if I can dig out the code we use here.

[Huddy]

Re: Comparing two records

It can be done the same ways on practically all systems in the AS/400 line going back a few versions of the OS, but better methods are possible on later versions. And the ways to do it can change for different programming languages.

What OS version should be targeted? What language do you need?

We are on OS 6.1 and would prefer to use RPG free

Huddy, if you look at the DSPJRN command, you can specify specific files - I'm sure there is something on this site somewhere that gives you a journal extract command which will allow you to dump all of the data to a file. If you can't find it let me know and I'll see if I can dig out the code we use here.

Ok thanks.. I'm just taking a look at that now.. see what it comes back with..

[gcraill]

Re: Comparing two records

What are the performance ramifications on this?

• How many files do you need to query?
• How many files do you have in total on that journal?
• How many transactions does your journal create daily?

From experience here we have a lot of files, a lot of users and a lot of updates daily. And that means we are averaging 330+ million journal entries per day. OK not truly massive but it is up there, we have over 20000 objects in those journalled libraries (fair few are LF or DTAQ/DTAARA) but it adds up to a lot of traffic.

Now if we want to troll the journals looking for changes to only 100 files, it means we are looking through journal entries (reading them all via DSPJRN) for ALL those objects and updates, and we log before and after images, whereby we may only want to report on the changes, so it adds up to a large amount of ignored traffic. (Here we only DSPJRN about 1% of files)

Users meanwhile want to keep working, so they keep creating new journal transactions, and the disks keep moving the heads back to the DSPJRN search, then back to the area of the disk to write the new entries, then back for more trolling ... etc

If we do this for EACH of those 100 files, then we repeat the stress load on those disk arms, which we have physically noted here as a response hit for end users.

sooooooo

1. You could move those 100 files to a seperate journal so that 90% of all total processing is unaffected by DSPJRN enquiries to the "extract" journal
2. You could have a batch server do a periodic DSPJRN on selected files to an OUTFILE (say every 15-30 mins) and then all your downstream stuff reads the outfile and you limit the DSPJRN to 1 pass only instead of 100
3. You could bang a trigger on the 100 files to dump to a log file the changes etc so there is no DSPJRN at all
4. Other (please specify)

performance wise what is the best way to accomplish this ?

Currently we do option 2, but I am talking to the application develoeprs about splitting them off to a new journal as well.