Article

Client process failing with error 1720 in 10.1B+ attempting to attach to database in shared memory on Windows.

« Go Back

Information

 
EnvironmentProduct : OpenEdge
Version: 10.1B, 10.2x, 11.x
OS: Windows
Other: 32-bit
Question/Problem Description
Client process getting error 1720 in 10.1B and later when attempting to attach to database shared memory on Windows.
Getting error 1176 when starting database server with large value for -B on Windows under 10.1B.
 
Clarifying Information
Error MessageUnable to attach shared memory Global\<shmname>, error 0. (1720)
The data space of the process is not enough for the shm segment (1176)
Defect/Enhancement Number
Cause
Changes to internal architecture of the OpenEdge 10.1B client code and 10.1B database internals have changed the memory requirements and some functional limits for many executables.

In 10.1B the client will most likely only be able to connect in shared memory to a database or multiple databases whose total allocated shared memory is around 1.4 Gig of RAM (or less).

Depending on the database startup parameters, the following are typical values for -B dependent on database blocksize:

DB Blocksize   Approximate limit for -B value which
               will allow shared memory connection
1k             1400000
2k              700000
4k              350000
8k              175000


These numbers are largely approximations. 
Other database startup parameters which affect shared memory sizing such as -B, -L, -Mxs, -shmsegsize, et al. will lower the above limits.
Changes to .dll versions within a system may lower the above suggested values. In prior versions shared pointers were only 64 bits wide on 64-bit versions of Progress / OpenEdge. In 10.1B or later versions shared pointers are 64 bits wide for both 32-bit and 64-bit versions of Progress / OpenEdge. This is one of the factors which has increased the size of client and server memory space in 10.1B and later necessary for the manipulation of 64-bit structures.

Though the database may be able to startup with values higher than those listed above, the client requires a much larger heap size in 10.1B compared to earlier versions and this added memory usage lowers the total memory that the client can attach to and still be within the addressable 32-bit memory limit for a client executable on Windows.
Resolution
1. Consider reducing the -B for the database startup.  A good starting point is to reduce the prior value by 10% and adjust the -shmsegsize down so enough contiguous Memory is available for the Virtual Memory Manager to provide to the server.

The database must be restarted for this new setting to take effect and the client connection in shared memory should be attempted immediately after the database is started to see if the reduction in -B is sufficient to avoid the 1720 error, also increasing the chances of their being enough contiguous Memory available for the Virtual Memory Manager to provide to the client.  For example several clients may be able to connect, before the nth fails due to the fact that the memory pages have fragmented such that contiguous memory are not longer available when the shared memory requirements are approaching the 32-bit executable limit.

2.  Connect Client-Server instead of shared-memory (-S -H)

3.  Use OpenEdge 64-bit license instead of 32-bit which is available since OpenEdge 10.2B
Workaround
Notes
Attachment 
Feedback
 
Was this article helpful?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful.



Characters Remaining: 255

 



Copyright © 1993-2014. Progress Software Corporation. All Rights Reserved. See the next generation of application development and data connectivity software, try now!