IBMi (AS400) fans only ' Journaling database physical files (tables)

By -


Journaling database physical files is a powerful, built-in OS feature. It allows you to audit data file changes.
Tracks additions, updates, deletions of a physical file.



Let's see how it works.

Scenario: I have a phisical file (Tabel) called CLANA00F, I wont tracks additions, updates and deletions about CLANA00F.



Step 1: CRTJRNRCV create a journal receiver in your library
CRTJRNRCV JRNRCV(VDOTEST1/JRCV) THRESHOLD(1500000) TEXT('My Journal Receiver')
CRTJRNRCV on IBMi




Step 2: CRTJRN create a journal into the journal receiver
CRTJRN JRN(VDOTEST1/JRNL) JRNRCV(VDOTEST1/JRCV)
CRTJRN on IBMi


Here is the just created journal receiver and the journal. 
STRPDM on IBMi




Step 3: STRJRNPF start auditing
STRJRNPF FILE(VDOTEST1/CLANA00F) JRN(VDOTEST1/JRNL) IMAGES(*BOTH) OMTJRNE(*OPNCLO) // the option OMTJRNE(*OPNCLO) omit open and close entries.
// Open and close operations on the specified file members do not create open and close journal entries. It saves some storage space in the attached receivers.                                     
STRJRNPF on IBMi

                                                       


Since now on, any changes to the CLANA00F file will be recorded in the journal.



Now I show you with a practical example.



I add a new record to CLANA00F
Work with data in a file on IBMi


Let's see what the journal shows:
DSPJRN JRN(VDOTEST1/JRNL) FILE((VDOTEST1/CLANA00F))

Perform option 5 in each row

DSPJRN on IBMi

The 3rd row PT - Record added shows and the entry specific data

Display journal entry on IBMi



I update a record in CLANA00F (I change ITA with FRA)
Let's see what the journal shows:
DSPJRN JRN(VDOTEST1/JRNL) FILE((VDOTEST1/CLANA00F))
DSPJRN on IBMi



I delete a record in CLANA00F
Let's see what the journal shows:
DSPJRN JRN(VDOTEST1/JRNL) FILE((VDOTEST1/CLANA00F))
DSPJRN on IBMi



Now let's see the whole history of CLANA00F
Display journal entries on IBMi
Type . . . . . . . . :   JF - Start journaling for file
Type . . . . . . . . :   JM - Start journaling for member
Type . . . . . . . . :   PT - Record added
Type . . . . . . . . :   UB - Update, before-image
Type . . . . . . . . :   UP - Update, after-image
Type . . . . . . . . :   DL - Record deleted
With option 5 in each row, you can see the entry specific data.



That's it.

I appreciate all the comments made on this blog.

#IBMiSample

Each IBMi user knows they run the most efficient system. All others just have too much money.

Comments

  1. AnonymousJanuary 13, 2023 at 11:51 AM

    unfortunately ibm does not provide anything serious to investigate the changed data

    ReplyDelete

Post a Comment

Popular posts from this blog

(IBM i fans only) Efficient WRKSPLF with WSF - How to Search string into spooled files, Sort, and Generate PDFs on IBMi

By -
Image
Searching Spooled Files Made Easy: A Unique Solution Managing spooled files efficiently is crucial for users dealing with numerous rows of print data. IBM's WRKSPLF command provides a standard way to interact with spooled files, but it lacks certain features that can significantly enhance user experience. In this article, we'll delve into a powerful functionality that IBM doesn't offer — the ability to search among spooled file lists. Our goal is to highlight the advantages of this capability and introduce a practical solution. The Limitations of Standard WRKSPLF While the WRKSPLF command is a handy tool for working with spooled files, it falls short in certain aspects. One prominent limitation is the inability to search efficiently through the list of spooled file rows. Users often find it challenging to quickly locate specific files based on criteria like creation date, status, or content. Introducing a Unique Solution: WSF (WorkSpooledFiles) To address the limitations of...
Read more

(IBM i fans only) Detecting and Handling Non-Printable Characters in DB2 SQL Using LOCATE() and REPLACE() Functions

By -
Image
When working with DB2 SQL on the IBMi platform, one of the challenges we might encounter is dealing with non-printable characters in our data. These are characters that don't have a direct representation on a standard keyboard and can cause display programs to crash if not handled properly. For this example, we'll be working with the CLANA00F file, which contains customer data. You can find details on how to create this file on my blog post here . Non-printable characters can sneak into our records for various reasons, and to prevent issues, we can run an SQL query that uses the LOCATE() function. This function returns the position of the first occurrence of a substring within a string, allowing us to detect these problematic characters. Suppose we have a customer name with a non-printable character, specifically the EBCDIC '0D' character, which corresponds to the "Carriage Return" (CR) control character in ASCII. To find this character in our records, we can ...
Read more

(IBM i fans only) How to Sniff User Access

By -
Image
If you need to monitor user access on your IBM i system, you can use SQL to query the history log. Note: At the end of this post, you'll find a request directly addressed to you, the readers. Here’s a simple example of how you can do this: SELECT MESSAGE_ID,        MESSAGE_TIMESTAMP,        FROM_USER,        MESSAGE_TEXT     FROM TABLE (             QSYS2.HISTORY_LOG_INFO()         )     WHERE message_id IN ('CPF1164', 'CPF1124')           AND FROM_USER IN ('QSECOFR', 'QSYS', 'QSYSOPR')     ORDER BY MESSAGE_TIMESTAMP In this query: - QSYS2.HISTORY_LOG_INFO(): This function retrieves information from the history log. -  message_id IN ('CPF1164', 'CPF1124') : Filters the results to include only specific message IDs, which indicate sign-on and sign-off events. - FROM_USER in ('QSECOFR', 'QSYS', 'QSYSOPR'): Filters the resu...
Read more