The most common cause is the %Temp database becoming full. The MSM-Workstation development environment is allocated a 1Mb in-memory database when it starts. This is given the moniker %Temp and is volume group number 31. It contains a single UCI, "M__,M__". The ^UTILITY global is automatically translated into this database, allowing utilities to work even when the current database is read-only.
There is a way to give MSMWS.EXE a bigger %Temp database than was set when it was made. It involves a little registry editing, so take care. Here's what to do:
1. Start WS and use the command-window to check the current size of %Temp (VG #31):
>w $$TSPC^%msv(31,.size) 0 >w size 1024 >
That 1024 is the 1Mb standard size of M__,M__ (%Temp).
2. Shut down WS.
3. Use regedit to go to the following subtree:
HKEY_CURRENT_USER\Software\Micronetics\MSM-Workstation\Databases
This is where the monikers are stored. Don't worry if the subtree you find doesn't case-match the one I've quoted -- the Windows Registry is case-preserving but not case-sensitive.
Create a new string value item named %Temp and containing the following string:
M|2048|M__
4. Start WS, and use the command-window as above to confirm that VG#31 is now 2048 blocks big (as set in the second |-piece of that registry entry).
The MSM-Workstation development environment also uses ^BLDt as a scratch global, and employs explicit extended referencing to specify where to locate this. By default, when working in a network database your ^BLDt scratch data is stored in %Temp, avoiding network traffic. If the total size of concurrently-open objects is too great, this global might be unable to grow. Rather than configuring for a larger %Temp you can relocate the ^BLDt global. Search the online help using the keyword 'scratch' and look for a topic headed Managing the Scratch Global.