Skip to main content

Check Journaled Objects from SQL - IBM i

Journaled Objects

Journals play very important role on IBM i and are helpful to identify who has updated the data and/or to retrieve the data before the update or delete from the tables and so on. 

Journaled objects can be seen by using WRKJRNA (Work with Journal Attributes) CL command or by using API QjoRetrieveJournalInformation (Retrieve Journal Information). 

One other easier way to check the list of journaled objects is by using SQL view JOURNALED_OBJECTS. This view is present in QSYS2 and system name JRN_OBJS.

We can use this view to retrieve the objects attached to a particular journal or identify the journal associated with the particular object and so on. 

E.g.: 

Retrieve the objects attached to a journal. 

Retrieve Objects attached to a journal - IBM i

In the above query, 
  • Line - 1: SELECT statement on JOURNALED_OBJECTS view. 
  • Line - 2: Where condition on column JOURNAL_LIBRARY to select the records with the journal library passed. 
  • Line - 3: condition on column JOURNAL_NAME to select the records with the journal name passed. 

Or, If we need to identify the journal attached to a specific object. 

Identify the journal attached to a object - IBM i

In the above query,
  • Line - 2: Where condition on column OBJECT_LIBRARY to select the records with objects present in the library passed. 
  • Line - 3: condition on column OBJECT_NAME to select the records with the object name passed. 
  • Line - 4: condition on column OBJECT_TYPE to select the records with the object type passed. 

These are just the two examples that I use most and we can query for the specific requirement from the different columns present in the view. 

Below are the full list of columns present in this view. 

  • JOURNAL_LIBRARY - The name of the library that contains the journal. 
  • JOURNAL_NAME - Then name of the journal.
  • IASP_NUMBER - The number of ASP (Auxiliary Storage Pool) in which journal is present (1 for the system ASP).
  • IASP_NAME - The name of IASP (Independent Auxiliary Storage Pool). Special value *SYSBAS for system ASP (ASP 1) and other basic ASPs (2 - 32).
  • OBJECT_TYPE - Type of the object journaled. 
    • *DIR - Directory
    • *DTAARA - Dataarea
    • *DTAQ - Data Queue
    • *FILE - Database File
    • *JRNRCV - Journal Receiver
    • *LIB - Library
    • *STMF -Stream File
    • *SYMLNK - Symbolic Link
  • OBJECT_LIBRARY - Name of the library in which the journaled object present. Contains null value for object types *DIR, *STMF or *SYMLNK.
  • OBJECT_NAME - Name of the object journaled. Contains null value for object types *DIR, *STMF or *SYMLNK.
  • FILE_TYPE - Type of the file that is journaled. Below are the valid file types and contains null value if the object journaled is not a file.
    • PHYSICAL - Physical File
    • LOGICAL - Logical File
  • PATH_NAME - IFS path name for the IFS object journaled.  Contains null value if object types are not *DIR, *STMF or *SYMLNK.
  • FILE_IDENTIFIER - Identifier associated with the IFS object. Contains null value if object types are not *DIR, *STMF or *SYMLNK.
  • JOURNAL_IMAGES - Specifies the kind of images to be written to journal for this object. Below are the valid values and contains null value for journal receiver (Object type - *JRNRCV).
    • *AFTER - Only after images are written to the journal.
    • *BOTH - Both before and after images are written to the journal.
  • OMIT_JOURNAL_ENTRY - Specifies the journal entries to be omitted from writing to journal for this object. Below are the valid values and contains null value for journal receiver (Object type - *JRNRCV).
    • *NONE - No entries are omitted. 
    • *OPNCLO - Open and close entries on the specified file members are omitted. 
    • *OPNCLOSYN - Open, close and force entries on the specified objects are omitted. 
  • INHERIT - Specifies whether new objects created within this journaled library (or directory) should inherit the journal state of the parent library (or directory). Below are the valid values and contains null value if object type is not *LIB or *DIR.
    • *YES - New objects will inherit the journal state of the parent. 
    • *NO - New objects will not inherit the journal state of the parent.
  • REMOTE_JOURNAL_FILTER - Specifies whether the journal entries written for the objects that inherit the parent library (or directory) are eligible for remote journal filtering by object. Below are the valid values and contains null value if object type is *JRNRCV.
    • *YES - Journal entries written are eligible for remote journal filtering. 
    • *NO - Journal entries written aren't eligible for remote journal filtering.

*This function is only available since IBM i 7.3 TR9 and IBM i 7.4 TR3. 

 
If you have any Suggestions or Feedback, Please leave a comment below or use Contact Form. 

Comments

Popular posts from this blog

All about READ in RPGLE & Why we use it with SETLL/SETGT?

READ READ is one of the most used Opcodes in RPGLE. As the name suggests main purpose of this Opcode is to read a record from Database file. What are the different READ Opcodes? To list, Below are the five Opcodes.  READ - Read a Record READC - Read Next Changed Record READE - Read Equal Key Record READP - Read Prior Record READPE - Read Prior Equal Record We will see more about each of these later in this article. Before that, We will see a bit about SETLL/SETGT .  SETLL (Set Lower Limit) SETLL accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Corresponding Record (or Next Record if exact match isn't found).  SETGT (Set Greater Than) SETGT accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Next Record (Greater Than the Key value). Syntax: SETLL SEARCH-ARGUMENTS/KEYFIELDS FILENAME SETGT  SEARCH-ARGUMENTS/KEYFIELDS FILENAME One of the below can be passed as Search...

What we need to know about CHAIN (RPGLE) & How is it different from READ?

CHAIN READ & CHAIN, These are one of the most used (& useful) Opcodes by any RPG developer. These Opcodes are used to read a record from file. So, What's the difference between CHAIN & READ?   CHAIN operation retrieves a record based on the Key specified. It's more like Retrieving Random record from a Database file based on the Key fields.  READ operation reads the record currently pointed to from a Database file. There are multiple Opcodes that start with READ and all are used to read a record but with slight difference. We will see more about different Opcodes and How they are different from each other (and CHAIN) in another article. Few differences to note.  CHAIN requires Key fields to read a record where as READ would read the record currently pointed to (SETLL or SETGT are used to point a Record).  If there are multiple records with the same Key data, CHAIN would return the same record every time. READE can be used to read all the records with the s...

Extract a portion of a Date/Time/Timestamp in RPGLE - IBM i

%SUBDT Extracting Year, Month, Day, Hour, Minutes, Seconds or Milli seconds of a given Date/Time/Timestamp is required most of the times.  This can be extracted easily by using %SUBDT. BIF name looks more similar to %SUBST which is used to extract a portion of string by passing from and two positions of the original string. Instead, We would need to pass a value (i.e., Date, Time or Timestamp ) and Unit (i.e., *YEARS, *MONTHS, *DAYS, *HOURS, *MINUTES, *SECONDS or *MSECONDS) to %SUBDT.  Valid unit should be passed for the type of the value passed. Below are the valid values for each type. Date - *DAYS, *MONTHS, *YEARS Time - *HOURS, *MINUTES, *SECONDS Timestamp - *DAYS, *MONTHS, *YEARS, *HOURS, *MINUTES, *SECONDS, *MSECONDS Syntax: %SUBDT(value : unit { : digits { : decpos} }) Value and Unit are the mandatory arguments.  Digits and Decimal positions are optional and can only be used with *SECONDS for Timestamp. We can either pass the full form for the unit or use the short...