Journaling for Dummies

Share on Facebook0Share on Google+0Tweet about this on Twitter0Share on LinkedIn1Email this to someoneShare on Reddit0

Journaling is the primary mechanism used by logical software replication tools such as Rocket iCluster and other products. Products such as IBM SystemMirror for IBM i or PowerHA use a combination of disk level mirroring done by the SAN or operating system based mirroring at the page level using IASPs (Independent Auxiliary Storage Pools). So if you are currently using a software replication tool, you need to understand journaling and what is in your journals.

If you have been an IBM i customer since it was the good old AS/400 and came in a white box, you are probably intimately familiar with the basics of journaling. This blog post is NOT for you. Go practice your REXX coding or cobble together a neat new CL using an unknown API and come back next week! If you are new to the platform, or are more familiar with other databases like SQL or Oracle, take a few minutes and hang around.

So what is a journal? A journal is a logical operating system construct which along with the attached journal receivers, knows what is going on in your database before the database itself! There is a single audit journal called QAUDJRN in library QSYS which captures changes to everything that isn’t data areas, data queues, IFS or physical files. Changes to physical files are captured in “database journals” of which you can have as many as you want or need and can be stored in any library.

Think of a journal as the database equivalent of a point and shoot digital camera. What the journal does is take pictures of every single change that occurs to your physical files or in the case of the system audit journal, changes to all other objects. So every file rename, file move, user profile creation, record insert or record update – SNAP, a picture is taken by the journal. In other databases this is sometimes called a database log. The SD card in the camera is the journal receiver. I can have one receiver attached to a journal at any one time – similar to having 1 SD card in the camera. When the receiver is full, the operating system (or you manually) can detach the receiver and attach a new one (i.e. swap SD cards). Once the transaction is captured by the journal, the operating system automatically applies that change to the object or physical file.

Journals and journal receivers can be queried and examined, and since everything that happens is captured, it makes a great audit trail for determining who did what to what file/object and when. It also can be configured to capture both the before and the after image of the record. Have you ever experienced this….

Missing Data

If you have, you NEED journaling.

In our next post we will look at what is actually in the journal. Stay tuned!

The following two tabs change content below.

iCluster Tech Tuesday

iCluster TechTuesday is a set of posts covering technical tips and techniques to help get the most out of your Rocket iCluster installation.

,

4 Responses to Journaling for Dummies

  1. Kate Stanton April 26, 2015 at 7:15 pm #

    My system does not appear to have a QAUDJRN or QSYS file.

    This on UniVerse 10.3.7 under Windows 7.

    In our software we have an audit file to which we write before and after images of changes made during data entry to flagged files.

    We could be duplicating effort.

  2. Mike Warkentin April 26, 2015 at 8:28 pm #

    Hi Kate.

    This article is specifically related to Power Systems running IBM i (so the iSeries or AS/400 if you have been in IT for as long as I have). So you are not duplicating any efforts. Most databases have similar journaling features to IBM i that are sometimes called transaction logs or redo logs. They all do the same thing, capture transactions occurring to the database and allow you to replicate or sometimes remove those transactions.

    Thanks for the comments though, it’s always nice to know someone is out there reading!

  3. Joe Baumgarten May 1, 2015 at 9:30 am #

    Hi Mike,

    Great intro to journaling!

    In my past life as an IT Director of an AS/400 shop, we used journaling frequently to recover and fix mistakes that an errant program made to our key database files. Restore the last “good version” of the file, fix the program, reapply all the transactions, done!

    However, the most interesting use of journaling I ever had was at the bequest of the White House Secret Service. One of the data entry operators had found a magazine subscription for the Clintons in the White House and changed the name on the address label to “death to the president”. I used the journals to trace the database change down to the precise transaction, date, time and operator code. I paired that with the system log-in information for his user profile and BUSTED!

    CSI-IT. Love it!

  4. Mike Warkentin May 1, 2015 at 9:55 am #

    Hi Joe. Great story re the use of journaling to bust the bad data entry operator!

    I was on the other end of this back in my old MVS days. I was a systems programmer and was doing a new OS release where I had to recreate the system catalog. After recreating I mistakenly deleted the production system catalog instead of my test version. MVS also has transaction logs and I was soon busted too.

Leave a Reply