Journal sequence #’s resetting after IPL (V5R4)
My company recently upgraded from V5R3 to V5R4. Prior to the upgrade, our journal sequence #'s did not reset after an IPL. A new journal receiver would be attached, and the sequence # would increment by 1. We have a number of processes that scrape the journals, based on the sequence # at the start of day, and and end of day marker (we scrape from the starting sequence # until the EOD marker is hit). This process has worked for over 5 years, without any issues.
We upgraded our OS over the weekend, and after the first IPL, our journal sequence # reset to 1 (unkown to us at the time). This caused a number of issues which took quite some time to correct. Our next IPL is scheduled to take place on Saturday night, and if possible, we want to avoid having our journal sequence #'s reset.
When on V5R3, this worked fine, and I don't think that the ability to continue sequence #'s would have been removed from V5R4 (and I didn't see anything regarding this in the IBM documentation).
Our Journals are currently set up with the following attributes:
Manage Receivers: *SYSTEM
Delete receivers: *NO
Journal Cache: *NO
Manage Delay: 10
Delete Delay: 10
Journal Type: *LOCAL
Journal State: *ACTIVE
Minimize entry data: *NONE
Receiver size Options: *MAXOPT1
Fixed Length Data: *JOB, *USR, *PGM
It should be noted that we change receivers daily, and the CHGJRN command that is used within the CL states *CONT for the sequence option. This works without any issues. Its only when the system is IPL'd that we see the sequence # reset.
Any suggestions on what can be done to prevent the sequence # from resetting at IPL would be greatly appreciated.
Software/Hardware used:
Software/Hardware used:
ASKED:
April 15, 2009 5:57 PM
UPDATED:
April 16, 2009 6:08 AM
Answer Wiki:
As per IBM guide,
If the journal receiver was attached while RCVSIZOPT(*MAXOPT1 or *MAXOPT2) was in effect for the journal, the system attempts to perform a CHGJRN command to reset the sequence number when the journal receiver's sequence number exceeds 9,900,000,000.
If the journal receiver was attached while RCVSIZOPT(*MAXOPT3) was in effect for the journal, the system attempts to perform a CHGJRN command to reset the sequence number when the journal receiver's sequence number exceeds 18,446,644,000,000,000,000.
For all other journal receivers, the system attempts this CHGJRN when the sequence number exceeds 2,147,000,000.
Additionally, during an initial program load (IPL) or the vary on of an independent ASP, the system performs a CHGJRN command to create and attach a new journal receiver and to reset the journal sequence number of journals that are not needed for commitment control recovery for that IPL or vary on, unless the RCVSIZOPT is *MAXOPT3. The sequence number will not be reset and a new journal receiver will not be attached if the RCVSIZOPT is *MAXOPT3 unless the sequence number exceeds the sequence number threshold which is 18,446,600,000,000,000,000.
Hence based on this I think you will have to specify the Receiver size Options: *MAXOPT3.
To see all answers submitted to the Answer Wiki: View Answer History.
RSS - Discussions Help
Discuss This Question:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
