Lee Gunter wrote:
>
> Perhaps, someone can shed some light on this.  The question du jour
> concerns the current use of extra data segments in our primary
> online application and a couple of associated batch apps.  [snip]
> ...we want to try to reduce overhead by building the segments as
> large as they'll ever need to be and eliminating the ALTDSEG calls
> to shrink and resize the segments as needed.  What I can't
> discover is what, if any, impact this will have on transient
> space and memory manager CPU utilization.

We have a legacy CM (SPL) application that does a similar thing.
Obviously you will need potentially as much transient space as you
are going to allocate initially.  Our application uses the XDS segments
to pass information from one process to another.  An early
optimization was to modify the allocation routines to track the
amount of space dynamically, and historically track the high water
mark.  Based on this, we initially size the segments for "average"
transactions and the code that loads the segments can dynamically
expand them by 4K (or whatever is appropriate to your app) when
necessary.  Further, the segments are pooled and reused, which
avoids the allocation/deallocation overhead (which is inherent in
doing ALTDSEG as well).

The more recent incantations of this system are in C and malloc() data
locally, avoiding a lot of DMOVIN/DMOVOUT overhead; but now we're
getting cross-cultural here :-)

Jeff Kell <[log in to unmask]>