Ansicht
Dokumentation
12723 - CPA7090 - Entry not Journaled to journal QSQJRN hit maximum sequence # 2,147,483,136
ROGBILLS - Synchronize billing plans BAL_S_LOG - Application Log: Log header dataThis documentation is copyright by SAP AG.
CPA7090 - Entry not Journaled to journal QSQJRN hit maximum sequence # 2,147,483,136
Hi Doreen,I would suggest, that you read the docu for this command and just try
it several times. In my eyes, it is fully sufficient, when it goes
through ones a months or even less.
You can check in the journal as well.
Perhaps the factor 4 solution helps you as well ...
I don't know what happen when the CHGJRN with reset is not possible.
If it has no effect on the system, you could schedule it for every
night and check once a month if the value is not too high ...
Seey ou
Volker
--- In DoNotReply@consolut.eu, "Anderson, Doreen"
<dandersoZb...> wrote:
> ARGH!
>
> I thought we would be ok if we reset this 2x per year with the time
change (when we IPL) but we did IPL in October 2003 and according to
the information you provided, the sequence # would have reset then.
>
> We only backup the replicated copy.
>
> We try so hard to make this box 24 x 7 - Saturday night is also
busy - no ability to get a window without an open commit cycle
>
>
> -----Original Message-----
> From: Volker Gueldenpfennig [mailto:volker.gueldenpfennigZs...]
> Sent: Wednesday, January 28, 2004 12:35 AM
> To: DoNotReply@consolut.eu
> Subject: Re: 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
>
>
> 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
CL_GUI_FRONTEND_SERVICES - Frontend Services BAL_S_LOG - Application Log: Log header data
This documentation is copyright by SAP AG.
Length: 11558 Date: 20240424 Time: 072833 sap01-206 ( 4 ms )
