RE: Journal performance problems

>  Vern Hamberg:
>In the CL program that calls the batch program,
>specify the files that use commitment control and
>open them. Start a commit cycle in the CL program 
>before calling the batch program. In the application
>program(s), change the file description to specify
>that commitment control is in use. Once the program 
>returns to the CL program, end the commit cycle to 
>force any pending file I/O to complete.

I agree with the principles.  Depending on your batch size and volume,
however, this isn't necessarily a slam dunk.  If you have a lot of
throughput among individual batch update jobs you can run into journal lock
contention as you start and end commit cycles and as the system deems
journal receivers eligible for purge.  You can also chew up a lot of disk in
your journal receiver ASP.

If you have very long running high transaction batch updates you might
accumulate gobs of receivers before transactions are committed.  We've had
situations where a few gigs of receivers pile up for several active jobs.
All the receivers are pinned until the last job's pending transactions are
committed.  Then the journal itself seems to get hung up while the system
tries to delete five or six receivers.

Commitment control is a great idea for application integrity as well as
journal performance.  On batch jobs though you may have to put some thought
into the meaning of the commit cycle as it relates to the volume of
transactions in a batch job.  Committing an entire batch job as a single
database transaction may not always be the best idea.

-Jim

James P. Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@xxxxxxxxxxxxxxxxx>