Hi Thomas,

interestingly, I was able, using plain VFP, to replicate Fabio's results: based on PerfMon Physical Memory available, filling up a VFP 9 instance with strings, after setting 3050,1 to 1800000000 (1.8GB) did indeed use that much memory, for the first and second instances, on a 2003 x64 server with 8GB of memory. The third instance got chopped a bit because other processes (a spare SQL Server for one) were running on that machine. Removing them one-by-one restored available physical memory.

That said, those weren't my results when running multiple instances of a large EXE (has a ton of metadata of various kinds stored in the EXE for a couple of good reasons). I'll have to revisit that, and see if I continue to get the same results. In that case, I set 3050,1 to a reasonable number for the application, and progcache to 0, since that testing was a terminal server and having dynamic program caching makes a lot of sense. But why I couldn't get above 2 GB total in instances is the mystery: but I'll try again, in case I misread the numbers.

Hank

>Hank,
>
>>but what's your paging in that circumstance: excessive paging is what led me to look at the issue.
>
>quite a few other possible solutions to that, depending in part on the exact nature of the problem.
>One issue might be sys(3050,x,1)#sys(3050,y,2) and chatty OLE linking implementation -
>which was a very special problem I found once and probably is not your current source of trouble.
>
>But generally if you are running into swap problems either add memory to the box and/or lower sys(3050) generally,
>as most of the time windows governs mem starved situations better than you. Heigthen it only if a WinDOS usage
>is more typical for the situation and you can focus on ONE process as rule of thumb - exeptions as always exist.
>If VM or TS usage is thrown into it as well or other WorkingSetSize issues, ask for a large budget or large data gathering timeframe.
>
>regards
>
>thomas