Lee writes:

> 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.  We demo'd LPS's
> "XDSMAP"  a couple of years ago to intercept and convert the XDS calls to
> mapped file access, but a problem soon appeared with respect to a limit on
> tracking PINs (<=4000, I believe), and I don't know if that's ever been

I've checked the code...I see no limitation for # of PINs anywhere.
The only limits I see are:

   #define MAX_XDS_PER_PROCESS     256
   #define MAX_XDS_LENGTH        32764

And, we have a semi-experimental version that allows maximum XDS length
of 1/2 GB for process-private XDS and 2 MB for shared XDS.  This version,
however, requires a coding change because the offset and length parameters
are 32-bits instead of 16 bits.

> addressed by the vendor.  In the meantime, 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.

If all possible DSTs were allocated (16,384 of them), and every single one
was at the maximum size of 64 KB, that's one gigabyte of storage.

However, you aren't going to be allocating that many, I suspect :)

So...to calculate the impact, the worst case is the number you're allocating
times 65536 bytes.  Let's say that's 100 data segments.  That's 6,553,600
bytes of data, worst case ... and a pretty small amount in the overall
scheme of things.

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html