Please! Journal 101 beginner newbie help
hkbo...@hotmail.com
my Boss asked me how to track changes to a file by users (in a RPG or a
DFU or a ODBC).
I know that journals will do this and more so that is what I told him.
I also said I think you can track system changes eg WRKSYSVAL.
I now have to report on this in explaining field changes in a record
and how this can be viewed by managers. They wish to open data entry
company wide as before it was a small department but while they trust
the small department they are worried by mistakes by more users. They
want to track when a change was made, what it was and by whom.
My question is:
-does anyone know of a succinct white or red book on explaining
journals for user databases.
-does anyone know of a succinct white or red book on explaining
journals for system databases.
I have already found "Journal management" rzaki.pdf and searched the
group but thought perhaps the Group knew of better.
I need to know of 'journal receivers', 'what is a receiver', 'what is a
journal', 'can a database have our my for management tracking journal
while a different journal for a third company product is running',
'what is comit control', etc
Happy just to get pointers to IBM PDF's.
ps: no need to hurry. I have told them I know nothing about this.
pps: I have written ILE triggers that record changes to files to other
files but is this better than journals or worse or the same thing?
Again just a book from IBM would be good.
whome
<hkbo...@hotmail.com> wrote in message
news:1164881824....@80g2000cwy.googlegroups.com...
you don't give enough info really. is this for permanent or one - off
requests?
How long are journal receivers retained on your system? (to journal file
changes, you need a journal, and attached journal receivers. a journal is
like a 'header' object which defines the journal attributes. Journal
receivers are attached to the journal and the receivers contain the actual
journalled data).
Do you want to track all files in the system , or certain critical files? Do
you want to track high volume transaction tables, or low volume master data
(eg, customer data, product tariffs, etc). All these make a difference on
the ideal solution.
We personally use triggers attached to critical tables to dump changes to
critical master tables out to history tables. Journalling is only useful
to retrieve changes in recent history (depending on your archiving
policies).
one very useful command, is expjrne (export journal entries).
To start journalling from scratch you need to...
crtjrn xxx/xxx
crtjrnrcv (and attach it to the journal you just created).
then,
strjrnpf , and capture both before and after images .
But, theres lots of best practice guidelines and pitfalls to avoid depending
on needs.
hkbo...@hotmail.com
firstly: yes, this is to be a permanent solution but I presume it to be
purged at, say, EOY. As per standard company management of all data.
>How long are journal receivers retained on your system?
Thus the reason I ask for a book, I do not yet understand JR's. Is this
not like an OUTQ that points to different printers. A JR points to
different Journals? The reason I ask Is that we have an installed
'solution' that somehow already 'records' our changes via journals
(perhaps 'remote'?) to our auditors/accountants and I am not allowed to
break (or even investigate) this setup. I have to add to the checking
of the file for internal use (totally allowed) but without breaking the
current use. Thus, can records from the 'user change' get recorded in
my 'area' with no regard to 'their' area.
>Do you want to track all files in the system , or certain critical files?
I only need to check one file as all others report to this file. This
is a header file and all sub-programs must update this file.
I thank you for your further suggestions but say that I really don't
understand the subject yet so thus the request for 'PDF`s'
Hi and thanks.
Saml
files to one end of the hose, and changes flow down the hose into the
bucket. When the journal receiver (bucket) is full you have to change it.
So now you have a full bucket (receiver) and one that is starting to fill.
You can do what you like with the full receivers--back them up to tape,
process the data, delete them.
Changing a journal receiver can be automated so that when a journal reaches
a specified size it is automatically changed. Or it can be changed
manaually, perhaps once a day.
Data in a journal receiver is "unstructured". There is a fixed prefix with
defined fields, then one chunk of unstructured data at the end which
represents the data record. There are ways of making this data readable but
none (that I know of) supplied with the operating system.
Some people read throught journal receiver data and convert them into audit
files. This is equivalent to what you've been doing with triggers, but it
can be made much more generalized with journaling.
There is a performance impact to journaling. If you set it up wrong, impact
can be significant, but probably not if you do it right. You can have one or
more journals, but each must have a receiver. For best performance, the
receiver should be on its own spindle.
"Commit" refer to commitment control, where all changed made are written to
the database, or none are. Read transaction, update file 1, update file 2,
commit, then both files are guaranteed to be updated. Journaling is
required, so if you aren't journaling now, you aren't using commit.
There is probably more, but time does not permit tonight...
Sam
<hkbo...@hotmail.com> wrote in message
news:1164881824....@80g2000cwy.googlegroups.com...
Steve Richter
hkbo...@hotmail.com wrote:
> Hi Group,
>
> my Boss asked me how to track changes to a file by users (in a RPG or a
> DFU or a ODBC).
>
> I know that journals will do this and more so that is what I told him.
that is exactly right. I dont think you need a book on the subject.
Once you know the command to run you can learn by trial and error. You
can start by using CPYF to copy the file you will be tracking into your
own library. Then have at it with the journaling commands: CRTJRNRCV,
CRTJRN, STRJRNPF, DSPJRN, DSPJRNA. GO CMDJRN to see all the journaling
commands. Once you are journaling your test file, use DFU ( the
UPDDTA command ) or STRSQL to change data in the file. Then DSPJRN to
display the journal entries.
> I also said I think you can track system changes eg WRKSYSVAL.
that would be the audit journal. There is a ton of usage information
that can be audited. GO CMDAUD to see those commands.
-Steve
manas
Do you want to look at off the shelf product or do you want to develop
something in house. WE use Live Audit from Data Mirror corp for DB
audit and inhouse reports on the System Audit journals for
system/object changes auditing. We are starting to use reports from
NetIQ product for our system changes.
Thanks
Manas
Tom Liotta
> my Boss asked me how to track changes to a file by users (in a RPG or a
> DFU or a ODBC).
hkboy897:
Journals are usually the best way to go for a few reasons, assuming you
want serious tracking and recovery. There's nothing wrong with triggers
if you want casual tracking.
Journals are enforced by OS/400 and DB2, while trigger programs are
user-written. As such, the operating system cannot do much to guarantee
them. There's no good way to ensure that records written to a tracking
file were actually written by the trigger program for example. (Unless
you journal the file that the trigger writes to, but then why not
journal the original file?)
Nor do you know if records written to that file have been changed or
deleted. Nor is there any automatic recovery/rollback such as RMVJRNCHG
and APYJRNCHG.
Saml used "hose and buckets" to describe journals and receivers, and
that's not a bad image. As each bucket fills, you can have OS/400
automatically switch to a new empty bucket, based on size criteria that
you set at creation time. Without such automation, you have to do extra
programming to manage the size(s?) of your tracking file(s?).
A journal can track about as many different files as you want. If you do
it yourself, you might need a different tracking file for each physical
file you cover or else design some way to handle different record types
-- not only when you write the initial tracking records, but also
whenever you need to retrieve them for reporting or whatever reason.
There are a number of generic routines you can search out for handling
journal entries over multiple files, but you'll be mostly on your own if
you choose to do it yourself.
I know this doesn't answer your question about on-line manuals.
Unfortunately, I'm not aware of any. I've used journals for many years,
so I've never needed to find anything beyond the standard IBM manuals.
Journals just aren't that hard to set up and use. You can set up tests
in minutes. It's probably far faster simply to try it a few times than
to read even simple articles.
If particular details cause confusion, this NG is as good a place as any
to get particular answers. Though some details might need clarification...
For example, I saw a post that described using the CRTJRN command and
following it with CRTJRNRCV. Actually, it's the other way around -- you
must create a receiver before creating a journal. The CRTJRN command
_requires_ supplying the name of a receiver for it to manage. Minor
detail, but easy to confuse the two.
Another post mentioned the system audit journal, QAUDJRN. An interesting
point about journals is that just about any historical detail you want
can be stored in them. QAUDJRN can automatically track changes to system
values and many kinds of actions. But you can store any detail by simply
running the SNDJRNE command, either against QAUDJRN or any journal you
create.
And once a detail is in a journal entry, it's hard to remove or change
that detail without leaving tracks about who did it, when it happened,
what job did it, what program, etc.
Tom Liotta
hkbo...@hotmail.com
Firstly, no a commercial system is not needed. We already have one
under the control of the audit company.
Our need is only for allowing more people to use the program that
allows orders to be entered. These people extend to sales people etc
and corruption etc is not an issue (only of data!). Thus, we track
changes to see messes made to data entry and to improve them and not
for true audit reasons.
I have said to my Boss that while journaling may be cleverer I will use
the current trigger arrangement as it is a known solution. The file
will be a mirror of the masterfile and carry new extra fields such as
add/change/delete, date, user etc. Also, I can instruct the programmers
to write a subfile browse interface over this file (a copy of a known
subfile inquiry) to include who, when etc changed the file. The journal
interface seems to be more of a security thing and we must write an
interpret interface.
I very much thank you all for your answers, I did not expect such
detailed help. This group is excellent in looking for answers.
If anyone else posts then I will read. I also think (if I remember!) to
post a comparison from triggers to journals, when I test the journal.
If I have not understood your answers then the fault is mine.
Thank you