Error Messages (N)

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z #

Number of private slots in segment table exhausted (1083)

PROGRESS uses shared memory for database access. Each process that
uses shared memory must attach to it. If the PROGRESS client could
only attach to 1 database, then when the broker created the shared
memory segment, it would be created in such a way that all the
processes connecting to the shared memory segments would be connected
at the same address so all the pointer locations inside shared memory
would have the same address regardless of which process was looking at them.

Since version 6 when a PROGRESS client was made capable of connecting
to multiple databases a new scheme needed to be invented for looking
at data in shared memory. No longer was it the case that all processes
would connect to shared memory at the same address. For Example:

A Process could look at a place in shared memory and it's address
would be 10752 because it's attach address to the shared memory
segment was 10000.
A different process connects to the same shared memory, but attaches
at address 20000 instead of 10000. The same data for this process will
have address 20752.

To solve this problem, PROGRESS came up with Position Independent
Pointers (PIP). The rule being any pointer which is stored in shared
memory *MUST* be a PIP pointer. The implementation for PIP pointers
is to only store offsets from the beginning of the shared memory
segment. In addition, a table is created to keep track of attach addresses.
In this way, the above example would look like:

The value in question would have a PIP address of Segment 1, offset 752.
Process 1 would look at the Attach address of Segment 1 (10000) and add
752 to get it real pointer relative to that process (10752).
Process 2 would do the same, Segment 1 (20000) and 752 = 20752} for a real
pointer.

With this all said and done, now back to the error message:
SYSTEM ERROR: Number of private slots in segment table exhausted (1083)

The Database Manager code is not always sure if a data structure is to
reside in shared memory or not. To that end, PROGRESS reserves a few
(10) table entries for pointers that get converted to PIP pointers when
the pointers were not in shared memory, but rather private memory. These
reserved table entries are called "Private Slots". Each slot can address
up to 16MB (which is the largest shared memory segment size PROGRESS uses,
128 MB on IBM). When a pointer is getting converted to a PIP pointer,
PROGRESS looks for the shared memory segment that would contain the
pointer. If it can't find it, then the pointer *must* reside in private
memory. It will then look to see if this pointer is within any of the
already existing private slots made up of 16 MB each, if not then we'll
create a new virtual private segment by taking up a table entry (slot).
Once all these slots are consumed, then upon creation of the next virtual
private slot, you would get the above message.

So, how does this happen. Maybe the client process is taking up too
much memory performing it's operation. Maybe the processes heap is
split up into 2 segments, below and above shared memory swo that the
pointers more than 16MB away from each other (not likely).
Maybe the clients -hs setting is too high. Most likely it's a bug
in PROGRESS that needs investigating.