32-bit client fails to connect self-service to one or more databases error 1720

32-bit client fails to connect self-service to one or more databases error 1720
OpenEdge client On Windows fails with error 1720 connecting self-service to one or more databases having large -B shared memory

Reducing the -B in the database server startup parameters enables the client to connect as a self-service client

OpenEdge client executable reached the Virtual Address Space limit on the Windows 32-bit platform.  

A misconception is that the 32-bit Windows platform allocates 4 GB of virtual memory per process running in the user space, this is not the case.  Microsoft Windows Virtual Memory Manager splits the 4 GB of addressable memory space into two segments:

1. 2GB that can be used for the User Process and
2. 2GB for the Operating System itself, which includes drivers, kernel and various other structures that need to be shared between different processes running on the same machine.

This 2GB of Virtual Address Space (also known as VAS) is mapped by the Windows Operating System to the Physical Memory and the Paging File when needed, for each running process. When an user process is initiated, it will use its allocated VAS for its execution segment, data, loaded dlls, memory mapped files (which is the way how the shared memory is accessed), stack, heap etc.  All of this must fit within the process' VAS which is limited on Windows 32-bit to 2GB.

Moreover there are loaded dlls, allocated stack, heap, open files, and various other memory structures allocated from within its executable, or from within functions residing in its dlls, which leaves even less space remaining for attaching the database shared memory segments.  When there is no enough space in process' VAS and the client tries to connect as self-service to the database server or servers in the case of multiple databases, failure to attach the shared memory segment will result in error 1720 with the error code 0.

One way to observe the current usage of a process' memory virtual address space is to use the Microsoft Windows Performance Monitor, with the object 'process' and add counter 'Virtual bytes peak'. This will provide an approximate value of the size being used in the process' VAS.

1. Consider reducing the -B on one or more database servers startup parameters.  A good starting point is to reduce the prior value by 10%. Since OpenEdge 10.1B the -shmsegsize database startup parameter can be adjusted down so enough contiguous Memory is available for the Virtual Memory Manager to provide to the server. Refer to Article P133127, What is the default -shmsegsize value used when allocating shared memory segments?   

The database must be restarted for these new settings 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 shared memory and the segments used to satisfy the requirement is sufficient to avoid the 1720 error. This also increases 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 Windows OpenEdge 64-bit license instead of 32-bit which is available since OpenEdge 10.2B.  

• 32-bit clients will need to connect to the 64-bit Database Client Server
• 64-bit clients will be able to attach to more shared memory