Ansicht
Dokumentation
12711 - CPA7090 - Entry not Journaled to journal QSQJRN hit maximum sequence # 2,147,483,136
Vendor Master (General Section) SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3upThis documentation is copyright by SAP AG.
CPA7090 - Entry not Journaled to journal QSQJRN hit maximum sequence # 2,147,483,136
Hi Doreen,sorry for your problems.
More or less all replies are correct somehow:
- 2,147,483,136 is a 32 bit problem
- you cannot create commit boundaries greater than 2,147,483,136 -
but you didn't want this anyway, because your system would crash at
20-40 million rows because of DASD problems with the journal receivers
The real reason of YOUR problem is the point, that you are not IPLing
for months ...
OK, yopu could change the receiver to the new format and will reach
the many 9999..., but this is only 4 times as large - so no real help.
Every IPL this sequence number is reset automatically. As 2 billion
is quite a large number NOBODY in the world gets hit form
this "problem" - except you.
In order to solve your issue, you should think on issueing a chgjrn
with RESET in a regular timeframe - once a week or at least once a
month.
As this screws up the commits, it is necessary, to do this when no
commit cycle is open - otherwise the command will just fail.
So, I would plan this for saturday night and would check, that it at
least runs perfect once a month.
I don't know by hard if you are doing a backup of your PRD
databaseregular or if you are only doing a backup of a copy. If you
do the first, the point of the backup would be the perfect timing, as
the save-while-active needs the same point, that no commit is open.
Sorry,
Volker
--- In DoNotReply@consolut.eu, "Anderson, Doreen"
<dandersoZb...> wrote:
> See below especially - "Last sequence number" value
>
> Display Journal Receiver
Attributes
>
> Receiver . . . . . . . : QSQJRN4484 Library . . . . . . . :
R3P01JRN
>
> Journal . . . . . . . : QSQJRN Library . . . . . . . :
R3P01DATA
> Threshold (K) . . . . : 200000 Size (K) . . . . . . . :
8412
> Attach date . . . . . : 01/26/04 Attach time . . . . . :
20:18:04
> Detach date . . . . . : 01/26/04 Detach time . . . . . :
23:13:34
> Save date . . . . . . : 01/27/04 Save time . . . . . . :
10:09:03
> Text . . . . . . . . . : Created by
upgrade
>
> Auxiliary storage pool . . . . . . . . . . . . . . :
2
> Status . . . . . . . . . . . . . . . . . . . . . . :
SAVED
> Number of entries . . . . . . . . . . . . . . . . . :
5186
> Minimized fixed length . . . . . . . . . . . . . . :
NO
> Receiver maximums option . . . . . . . . . . . . . :
0
> Maximum entry specific data length . . . . . . . . :
30064
> Maximum null value indicators . . . . . . . . . . . :
133
> First sequence number . . . . . . . . . . . . . . . :
2147477951
> Last sequence number . . . . . . . . . . . . . . . :
2147483136
>
>
> -----Original Message-----
> From: Vincenzo Boesch [mailto:vboeschZb...]
> Sent: Tuesday, January 27, 2004 3:29 PM
> To: DoNotReply@consolut.eu
> Subject: AW: CPA7090 - Entry not Journaled to
journal QSQJRN hit maximum sequence # 2,147,483,136
>
> But this is not the maximum of journal entries; it is the maximum
number of
> entries with open commits!
>
> Imagine a program is updating so many records and is never doing
any commit!
> I would say this is not a problem of the operating system; it is a
problem
> of the program who is never executing a commit!
>
> I have seen this problem before at a customer site and the solution
was to
> change the program in a way that it executes more often a commit.
>
> Regards, Vincenzo
>
>
> -----Ursprüngliche Nachricht-----
> Von: Anderson, Doreen [mailto:dandersoZb...]
> Gesendet: Dienstag, 27. Januar 2004 19:59
> An: DoNotReply@consolut.eu
> Betreff: CPA7090 - Entry not Journaled to journal
QSQJRN hit
> maximum sequence # 2,147,483,136
>
> How is everyone else handling the journal sequence # maximum?
>
> We hit this at 20:18 last night, found out about it at 11pm and a
fun
> time was had by all till 12midnight.
>
> Is a maximum journal sequence # of 2,147,483,136 IBM's idea of a
joke?
>
>
>
> Document Title
> Journal Sequence Number Filled Up with Pending Commits in Journal
> Receiver
>
> Document Description
> The maximum sequence number for a journal is 2,147,483,136 (see
note).
> If this number is reached, journaling is stopped for the journal.
The
> system sends a warning message to the message queue for the journal
when
> the sequence number exceeds 2,147,000,000. This warning message is
> CPI70E7.
>
>
>
> However, if this message is ignored or the user does not notice it,
> journaling may stop because the sequence number has filled up and
> recovery may not be possible. Recovery is to CHGJRN SEQOPT(*RESET).
The
> reset could fail because the sequence number is required to be
> consecutive for commitment control.
>
>
>
> [Non-text portions of this message have been removed]
>
>
> Have a look to our homepage at: http://www.consolut.net
> DoNotReply@consolut.eu
>
> consolut Links
>
> To visit your group on the web, go to:
> http://groups.consolut.net/group/SAP on System i/
>
> To unsubscribe from this group, send an email to:
> DoNotReply@consolut.eu
>
> Your use of consolut is subject to:
> http://www.consolut.net
>
>
>
> [Non-text portions of this message have been removed]
>
>
> Have a look to our homepage at: http://www.consolut.net
> DoNotReply@consolut.eu
>
>
> consolut Links
>
> To visit your group on the web, go to:
> http://groups.consolut.net/group/SAP on System i/
>
> To unsubscribe from this group, send an email to:
> DoNotReply@consolut.eu
>
> Your use of consolut is subject to:
> http://www.consolut.net
Durban Tours - Südafrika Safari
SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up RFUMSV00 - Advance Return for Tax on Sales/Purchases
This documentation is copyright by SAP AG.
Length: 8024 Date: 20240420 Time: 135853 sap01-206 ( 3 ms )
