Let me see if I can clear things up a little.  If my description is a
little vague on the details you are looking for let me know.  I want to
keep way from putting the gory details of the internals out here.

As the APAR states there is a boundary condition in checkpointing that
can cause this problem.  The MOVEBATCHSIZE and TXNGROUPMAX options
limit the number of objects that can be moved within the single data base
transaction before committing that transaction.  When these numbers are
very large there is a better chance of hitting this boundary condition
that causes the problem.  By lowering these numbers it is unlikely that
this condition will occur.

The tradeoff, which I think is what you are trying to understand is
performance.  These options were added to allow some performance tuning
in the ADSM server.  These used to be hard coded values.  TXNGROUPMAX
was 16.  I do not remember offhand what the value was for MOVEBATCHSIZE.

As you stated there are sister options for each of these options.  One
value is for the number of objects, the other value is for the number of
bytes being moved by that transaction.  This other value does not have
as a significant of an impact on the recovery log usage.  The transaction
is committed when either the maximum number of objects allowed for that
transaction is reached or the number of bytes of data being moved by that
transaction is reached.

I am not sure if I cleared things up for you.  Let me know if you have any
questions on this are would like me to go into a little more detail in
a specific area.

David Bohm, ADSM technical support.