Thanks for the resolution of my confusion.  :-)

Let me see if I can state this a different way.

The default minimums, as documented, are:
     MOVEBATCHSIZE - 32
    TXNGROUPMAX - 16

Both of these parameters control the number of files to be processed before a
commit to the data base is done, and thus effect the data stored in the
recovery log.  One handles storage pool operations, while the other handles
network operations.

The coverletter in question describes a problem that apparently was caused by
someone setting these values very high.  The recommendation of the letter is
to set these no higher than 100.  Those of us who have not specified other
than the defaults, or have selected values less than 100, should not have any
real exposure here.

There was also mention of the increased space utilization in the recovery log
if the the log mode used was normal (this makes sense).   Does this problem
only relate to logmode = normal operation, or does the original problem occur
when roll forward mode is used too?  (I would expect the space requirement in
rollforward operation to be a non-issue, since all of the information would
need to be kept in the log regardless of the limits set.)

Am I out on a limb here?

Jerry Lawson
jlawson AT itthartford DOT com


________________________Forward Header________________________
Author: INTERNET.OWNERAD
Subject: Warning for MVS servers
07-12-96 10:31 AM

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.