There are three methods of determining which shared memory segments are associated with an OpenEdge database.
1. The first way is via the PROUTIL command and can only be used on UNIX systems. The dbipcs option will allow you to identify all shared memory segments associated with any OpenEdge databases running on this machine.
Command Syntax: (notice no dbname is specified)
$ proutil -C dbipcs
Sample output:
PROGRESS SHARED MEMORY STATUS
ID ShMemVer Seg# InUse Database
0 - - - (not PROGRESS)
1 - - - (not PROGRESS)
6 10213 0 Yes /db/prod/sports.db
7 10213 1 - /db/prod/sports.db
8 10213 2 - /db/prod/sports.db
10 10213 0 No /db/test/sports.db
13 64010213 - - (unsupported shared memory version)
Where:
ID - Indicates the shared-memory ID.
ShMemVer - Specifies the OpenEdge shared memory version.
Seg# - Indicates the shared-memory segment number. One database can own more than one shared-memory segment.
In the example above the 'sports' database owns 3 shmsegs.
InUse - Specifies whether the segment is in use.
YES or NO are displayed only if the segment # is 0.
All other segments show a dash(-)
Database - Represents full pathname to the database.
This column will even represent non-OpenEdge (not PROGRESS) and
different versions of OpenEdge databases (unsupported shared memory version) running on the server.
In the example above, if the proutil -C dbipcs were run with OE 10.1C 64-bit instead of the 32-bit executable,
then all the other ShMemVer=10213 lines would read (unsupported shared memory version)
and this line would read:
13 64010213 0 Yes /db/dev/sports.db
On Unix platforms additional information about the shmid's can be found with IPCS:
- $ ipcs -a ( provides the same information including semaphores, where "ipcs -m" is equivalent to dbipcs for comparison)
- $ ipcs -mt (time is useful against the known-time shared-memory issues are realised)
- $ ipcs -mp (shmid creator and specifically the last operator's pid)
On Windows, one way to identify shared memory segments is to use the handle.exe tool from System Internals available at the Microsoft's website can be used to identify which OpenEdge process has a handle to the shared memory. It does not require any install, only for the EULA to be accepted the first time it is run.
Example:
$ handle64.exe -a sharemem. -u -nobanner
_mprosrv.exe pid: 13424 [Domain\owner]
264: \Sessions\1\BaseNamedObjects\sharemem.[path to db].[dbname].0
2. The second way to see shared memory segment information is using PROMON. The promon utility will allow you to display shared memory segments and the shared memory segment ids in use for a specific database. This method can be used on Windows and Unix platforms.
Command Syntax:
# promon dbname
- In promon type R&D <return> to get to the R&D Menu
- Select 1 for Status Displays
- Select 14 for Shared Memory Segments
Sample output:
Status: Shared Memory Segments
Seg Id Size Used Free
1 6 268435456 268435444 12
2 7 268435456 268435220 236
3 8 120987648 116561868 4425780
In this example:
- There are 3 shared memory segments.
- Only the last segment will have any appreciable space free.
- The "ID" will correspond with the "ID" in the above dbipcs shared-memory ID.
3. The third method is to use the _segments VST table. This method can be used on Windows and Unix platforms.
FOR EACH _segments NO-LOCK:
DISPLAY _segments EXCEPT _segment-misc.
END.
