Consultor Eletrônico

Change in the Calculation of Shared Memory Key in v8.0B+

There has been a change introduced in version 8.0B and higher in how
Progress calculates the shared memory key by which we attach to shared
memory. In the releases prior to 8.0B, the algorithm called ftok() to
create a key based on a file located on the filesystem. The key
generated was then used by all processes which required access to
shared memory and semaphores. Progress has found this mechanism using
ftok() for key generation to be somewhat unreliable, especially when
using larger systems with multiple disk drives and controllers.

Beginning in version 8.0B we now rely on the Operating System to
manage the key generation within the shared memory/semaphore creation
routine. The Operating System then passes us a "handle" to the shared
memory/semaphores which we in turn pass to all processes which need to
access the resource. We believe this algorithm to be much more
reliable since we are allowing the Operating Systems to manage
connecting to both shared memory and semaphores. The value passed to
us by the Operating System for the "handle" is assumed to be unique.
The new shared memory key calculation process should reduce the
occurence of such errors as:

Shared memory in use by another process. (1260)

A case where this error could potentially still occur is if you have
either all databases of a version prior to 8.0B or a mixture of
databases that includes both databases from 8.0B+ and ones from
earlier versions. If latter is the case for you, a potential work
around is to start the lower version databases before the version
8.0B+ databases. As always, the occurence of such an error should be
reported. However, the likelihood of it appearing should be greatly
reduced because we are now relying on the Operating System to provide
us with a unique value for the handle used for the shared memory key.

sda 9/16/97

Progress Software Technical Support Note # 17251