× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



James,

You can get rid of the open/close journal entries by specifying
OMTJRNE(*OPNCLO) on your STRJRNPF command.

Regarding the 100-character field containing the changed data, I'm guessing
you are looking at an output file created by the DSPJRN command. Check out
the ENTDTALEN option on the DSPJRN command. The default is *OUTFILFMT which
gives you the 100-character field. You probably want to use *CALC.

*CALC
The system calculates the length of the entry specific data field to
accommodate the longest entry specific data among all journal
entries in the specified receiver range. The entry specific data
field is a fixed-length character field. The minimum length of the
field is 130 characters. If the length calculated by the system
causes the record format length to exceed the maximum record length,
a message is sent and the entry-specific data field is truncated.


This only affects the output from the DSPJRN command. The actual journal
keeps the entire contents of the record.

Hope this helps!

Richard Casey


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James Rich
Sent: Friday, May 22, 2009 1:09 PM
To: Midrange Systems Technical Discussion
Subject: Re: Audit trail of file changes

On Fri, 22 May 2009, rob@xxxxxxxxx wrote:

Journals do need careful management. If you are truly only ever going to
journal this one file and no others, or, if you do start journalling other
files then you will have NO concerns about commitment control, etc, then
you may wish to journal just this one file to it's own journal. This will
allow you to customize the retention of that journal. However if you want
to start using commitment control and this file may be part of a
commitment boundary then you may will probably have to have all the files
in said boundary in the same journal.

I honestly don't see us using commitment control. I think that would
involve substantial rewriting of the applications. All we need is a way
to show before and after contents of this single file in a way that is
provably correct.

Guess what our biggest library on our system is?

This does concern me. At first I thought they only wanted to keep the
trail for a period of about a month. Now I found out they want to keep it
indefinitely. I noticed that the journal holds a lot more than just
updates, adds, and deletes; it also tracks every open, close, and backup.
I don't really need that second class of information. Is there a way to
either purge unwanted data or only log updates?

Another thing that has me a little confused is that the record length of
the file I'm journaling is 1088 but the field in the journal that I
believe holds the changed data is only 100. How can it possibly hold the
before and after images when the field is so much smaller that the record?

James Rich

if you want to understand why that is, there are many good books on
the design of operating systems. please pass them along to redmond
when you're done reading them :)
- Paul Davis on ardour-dev

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.