RE: Journaling and contention

Well, I think we've figured it out.  Thanks to all who have helped.

It appears that by solving the contention/locking problem we created a
sizing problem.  Initially the journal receiver size was set to 50,000 K.
We were burning through receivers at a rate of better than two per minute.
We bumped the size up to 1,919,999 K (about 1.9 GB) -- the maximum for a
journal without specifying *MAXOPT1 for receiver size option.  We stopped
getting the contention related CPA7090 messages because the larger receivers
were created and deleted less frequently.

Journal receivers have a fixed size limit based on all of the receiver size
options.  For this application it was somewhere around 2 GB.  When that size
limit is reached the CPA7090 message is sent and the program making the
journaled change halts.  By bumping the receiver size to 1,919,999 K we got
too close to the receiver size limit of 2 GB.  As the receiver reached a
size of 1.9 GB the threshold would trigger the system creation of the next
receiver.  Sometimes, however, the batch jobs would fill up the current
receiver to 2 GB before the system could create the new receiver and change
the journal to use it.

We're now going through receivers at a rate of one every 5 minutes. The
system probably has less than 10 seconds to create a new receiver and change
the journal before the batch jobs take the current receiver from the 1.9 GB
threshold to the 2 GB limit.  If we back off the threshold to something like
1.5 GB we buy ourselves more time for the new receiver to be created before
the current receiver fills up.  We'll be trying it out this weekend.

The fact that we have intermittent problems with the timing of new receiver
creation does suggest that this journal should be in its own ASP, but we're
going to try playing with the sizes first.  Hopefully reducing the threshold
will not introduce the locking issue again.

Thank you again.

-Jim

-----Original Message-----
From: Jim Damato [mailto:jdamato@dollargeneral.com]
Sent: Friday, June 29, 2001 5:55 PM
To: 'MIDRANGE-L@midrange.com'
Subject: RE: Journaling and contention


Much thanks to Buck and Alexei for helpful replies.

We've dug into this one deeper and discovered that on two occasions we've
received the "CPA7090  Entry not journaled to journal IPBLK in MRCARC. (C R)
" message WITHOUT the preceding "CPI70E5  Journal or journal receiver not
available" message.

It seems like this means that the jobs are filling up the journal receiver
so fast that system cannot create a new receiver quickly enough.  The new
receiver is created after one or two jobs bomb because the current/old
receiver has run out of space.

Now my course of action seems to be:  1)  Try Buck's suggestion of giving
the history table its own journal.  2)  Put the journals and receivers in
their own pool -- contention between the journals and the data could be
preventing the receivers from being created quickly enough.  3)  Reduce the
number of concurrent batch streams writing to the history file.

I continue to dig into this.  I wonder if I've misinterpreted the situation.
It seems weird that my journaled batch jobs could get ahead of the system
managed journal receivers.  Any opinions?

-Jim

James Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@dollargeneral.com>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---