Skip to main content

What happens if Journal Sequence Number reaches its Maximum Value?

Journals on IBM i makes life easier when something goes wrong. 

But, What if application starts failing because of Journal Receiver? This can happen in different scenarios. Here is the one scenario I have seen recently. 

"Journal sequence number is at the maximum value"

As the error suggests, Journal Receiver reached it's maximum sequence number and it cannot log any more entries into Journal. 

Maximum allowed sequence number on a Journal receiver is 9,999,999,999. 

We will see a bit about when this may occur and How to resolve it.

What happens when Sequence Number reaches it's maximum value?

Job would throw error 'Entry not journaled to journal &1. Reason code &3' (CPF7003) while adding an entry into Journal Receiver. Reason code would be '4' (4 -- Journal sequence number is at the maximum value.) in this case. 

There can be two scenarios when this issue occurs.

  1. Journal Receiver starts with sequence number '1' and reaches 9,999,999,999. This could occur very rarely and only if an application is fairly large and/or Journal Receiver isn't changed for a lone time.
  2. Journal Receiver starts with next sequence number from the previously attached Receiver and reaches maximum. This could occur frequently as CHGJRN would create the new Receiver with one greater than the sequence number of the last journal entry in the currently attached journal receiver.


What to do if Sequence Number reaches it's maximum value? 

CHGJRN command to be issued to generate new Receiver with an option to Reset the Sequence Number to '1'

CHGJRN JRN(LIBRARY/JOURNAL) JRNRCV(*GEN) SEQOPT(*RESET)

This would detach the current receiver and attach the new receiver to start from Sequence Number '1'. 

There could be error in executing this command if there are pending changes to be committed on the current receiver. These changes should be committed or Rollback for CHGJRN to execute. 

Here is how you could find the pending Commitment definitions.

DSPJRNRCVA JRNRCV(JOURNAL_RECEIVER)

F10=Work with journal attributes

(OR)
 
WRKJRNA JRN(JOURNAL)

F19=Display journaled objects

Option 6. Commitment Definitions 

This would display pending commitment definitions. COMMIT or ROLLBACK needs to be run for the pending changes on these Jobs.

Once these are resolved, CHGJRN should run fine.

Comments

  1. @Pradeep; nice job on documenting this behavior. Two notes though.

    Journal attribute RCVSIZOPT(*MAXOPT3) supports a JE Sequence of 18,446,744,073,709,551,600

    IPLs "can" reset the JE Sequence; which it does once it reaches a threshold, though I don't know what that number is. If you use RCVJRNE, then this becomes problematic because the reset isn't guaranteed, and that under certain circumstances (like multiple IPL's due to an O/S upgrade), which makes singular use of the JE Sequence number to drive processes unreliable -- recommend using Journal Receiver and Timestamp as a restart point.

    Thanks again for your content.

    ReplyDelete
    Replies
    1. Thanks a lot for the info TimH. I will make a note of these.

      Delete

Post a Comment

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 Arguments. Key Fiel

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 specified Ke

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 form. Below i