My question, what ability does the 32b release of Progress have to see RAM above the 4G mark?
Progress executables, like any other Windows executables, don't allocate RAM or choose physical memory addresses. They allocate virtual memory and the OS memory manager determines whether the pages are memory-resident. 32 bits = 2^32 bytes = 4 GB of virtual memory address space for a 32-bit process; 2 GB for the OS and 2 GB for the user-mode code and data. Given the code, shared libraries, thread stack, heap, etc. that already reside in the user portion of the database broker's virtual memory address space, the practical limit of the size of shared memory is somewhere around 1.5 GB, but it will vary depending on your system. If you want to allocate larger shared memory structures, like buffer pool (-B) and lock table (-L), you need to run the 64-bit Enterprise RDBMS product rather than 32-bit.
Trying to functionally survive on a system with 340+ users with a buffer cache of 750M, limited lock table, etc is certainly not a good situation. But still, I find it hard to believe that Progress has not addressed this issue in the year 2014 on a version that is still available and to some degree, widely used.
I agree that that is not a good situation, and you can change it for the better. OpenEdge is indeed widely used, but as Tom has indicated most customers no longer face these constraints as they have moved their back end to 64-bit executables.
I ask this because the app layer is installed on the same box as the DB and I am beginning to wonder exactly what you are alluding to, i.e., that it is their app that is 32b. If I could confirm this and confirm that the DB is 64b I can recommend that we separate the app layer from the DB
Unfortunately one legitimate limitation of OpenEdge (though only on Windows) is that you cannot have both a 32-bit installation and a 64-bit installation of products in the same release, e.g. a 64-bit database and a 32-bit runtime. But you certainly can move your application tier to a different box. So you want the 32-bit executables for the client side (Client Networking or AppServer for example; your vendor will tell you) and 64-bit executables on the server side (Enterprise RDBMS and, likely, 4GL Development System, aka the compiler). With proper tuning of the clients, the database brokers, and the network path(s) for TCP connections instead of shared memory connections, you can make the clients perform well and eliminate most of the performance hit of connecting client/server. Though I suspect you may have larger bottlenecks at the moment.
A remote (TCP) client neither knows nor cares whether the database it connects to is running with 32-bit or 64-bit executables, so splitting the tiers isn't something that should cause you application compatibility issues unless you have clients that for some reason "must" run on the database server. But do talk to your vendor about concerns and your plans for addressing them.
This appears to be a limitation of Prgress, i.e,. max buffer is tied to block size.
I am restricted to a limit of a 2G buffer cache due to 1046 block size.
I'm not sure what number you are quoting but 1046 is not a Progress database block size. And as Tom said, this has nothing to do with your -B constraint. Shared memory (most of which is -B, usually) is constrained in that its segments must fit (be able to be mapped into) the free contiguous blocks of virtual memory in the address space of all processes that connect to it. Your limiting factor is the use of 32-bit executables to create and connect to shared memory.
On any modern OS the file system block size is at least 4 KB. It is 4 KB by default in NTFS. So if your database block size is less than that you will pay a severe performance penalty for having a small block size. The only way to change it is with a dump and load to create a new database. If you do this, I recommend 8 KB blocks.
In a "proenv" command prompt (find it in the OpenEdge group in the Start menu), navigate to the database directory and type:
proutil dbname -C describe
That will show you your database block size. If it isn't at least 4 KB then that is likely your biggest performance issue.