RE: QRECOVERY and *CBLK error

You're probably using the older, small receiver size on the journal
receivers.  How about specifying a very large journal receiver size.
First your Journal would need the 'Receiver size options' set to MAXOPT1
(V5R1), or MAXOPT2 (V5R2) or MAXOPT3 (V5R3), depending on which OS/400
version you're running.  These size options would allow a much bigger
*JRNRCV size and a very large sequence number.  Then you could change
the *JRNRCV to be user managed and hopefully you could schedule a time
(daily or maybe once a week) for the applications to be down long enough
to do a CHGJRN to attach the next *JRNRCV.  You could still set a
journal receiver threshold much smaller than the MAXOPT1 maximum size
that would send a message to the message queue you define.  Even if the
threshold is reached and the journal receiver can't be rolled, you would
still have journal records being written to the existing journal
receiver since it wouldn't be max'ed out.  

HTH,
Glenn

Glenn Birnbaum
Platform Technology Services, REI
"Get Outside Yourself":  http://www.rei.com


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Krish Thirumalai
Sent: Friday, May 13, 2005 12:16 PM
To: Midrange Systems Technical Discussion
Subject: QRECOVERY and *CBLK error


One of our clients is getting this message, on a regular basis on their
system operator message queus. This issue was originally passed to IBM
and their response was that the volume of journal records written prior
to sync allowing the OS to obtain a lock to detach active journal
receiver was causing the issue.

Has anyone experienced this issue before. I do realize that the *CBLK is
the commitment block, but since redesigning our application is not an
option what is our solution.

IBM's recommended solution is to create a new journal receiver (total of
2) and separate files across both based on volume of journal record
creation.  They did say that this may or may not help if the situation
is created by a single application.

Message ID . . . . . . :   CPA7090       Severity . . . . . . . :   99

Message type . . . . . :   Inquiry                                    
        Date sent  . . . . . . :   05/10/05      Time sent  . . . . .
. :14:00:31

Message . . . . :   Entry not journaled to journal JRN in PRODLIB. (C
R)

Cause . . . . . :   The entry was not journaled into receiver JRNRC20384
in 
  library PRODLIB for journal JRN in library PRODLIB because of   
  reason code 1. The object associated with this entry is CBLK621188 in 
  library QRECOVERY of type *CBLK member *N, or has file ID 
  X'00000000000000000000000000000000' and path *N. If *N or hex zero
appears,
  information is not available or does not apply.

  Reason code definitions:

   1 -- Space for entry cannot be allocated on journal receiver.

   2 -- Journal is damaged.

   3 -- Attached receiver is damaged.

   4 -- Journal sequence number is at the maximum value.

   5 -- An internal journal failure occurred.

   7 -- Attached receiver is off line.

     8 -- Journal is off line.

     9 -- A new journal receiver must be attached to the journal.

    10 -- Journal state is *INACTIVE.

    11 -- Journal is a remote journal.

    12 -- Entry exceeds the maximum journal entry size.

    13 -- Unable to allocate large or very large space.

    14 -- Journal state is *STANDBY.

Recovery  . . . :

    If receiver JRNRC20384 in library PRODLIB is no longer attached to
journal JRN, recovery  using CHGJRN to attach a new receiver may not be
required.
    If condition is corrected, enter R to try request again. If you do
not  want to try the request again, enter C for cancel.
    Recovery for each reason code is:

   1 -- If the owning user or group profile of the journal receiver has

 reached its storage limit, increase the maximum storage (MAXSTG
parameter on 
 CHGUSRPRF). If the journal receiver has reached its maximum size,
change the 
 journal (CHGJRN) to attach a new receiver.

Possible choices for replying to message . . . . . . . . . . . . . . . :

  C -- CANCEL OPERATION

  R -- RETRY OPERATION


-- 
Krish Thirumalai

-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.