Output from .MO appears tabular for with one of the following headings:

 hob       va     flgs own  hmte  sown,cnt lt st xf
 0004  %fff13238  8000 ffe1 0000  0000 00  00 00 00 vmah
 0006  %fff0a891  8000 ffa6 0000  0000 00  00 00 00 mte       doscalls.dll

 hob     pob     har hobnxt flgs own  hmte  sown,cnt lt st xf
 0003 %fec80040  0003 fec8  0000 ffec 0000  0000 00  01 00 00
 0004 %fec80050  %fff13238  8000 ffe1 0000  0000 00  00 00 00

 hob   har hobnxt flgs own  hmte  sown,cnt lt st xf
 0001  0001 fec8  0000 fff1 0000  0000 00  00 00 00 vmob
 0002  0002 fec8  0000 ffe3 0000  0000 00  00 00 00 vmar

Each of the heading fields has the following meaning:

hob

The handle of the object record being formatted. This is the unique identifier by which the object record is known.
hobnext
The handle of next shared instance data object that maps to the same linear address range (shares the same arena record but maps to a different physical address).
har
The handle of the arena record that describes the linear address range allocated to this object.
pob
The linear address of the object record.
va
The virtual address of the pseudo-object named in the object description.
flgs
Object record flags.

The following flags are defined:

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³Name           ³Bit    ³Description                             ³
³               ³Mask   ³                                        ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_PSEUDO      ³0x8000 ³Pseudo-object                           ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_API         ³0x4000 ³API located object                      ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_LOCKWAIT    ³0x2000 ³Waiting for a lock conflict to resolve  ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_LALIAS      ³0x1000 ³Object has aliases                      ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_SHARED      ³0x0800 ³Object's contents are shared            ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_UVIRT       ³0x0400 ³UVirt object                            ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_ZEROINIT    ³0x0200 ³Object is zero-initialised              ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_RESIDENT    ³0x0100 ³Initial allocation was resident         ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_LOWMEM      ³0x0040 ³Object is in low memory                 ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_GUARD       ³0x0080 ³Guard page attribute                    ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_EXEC        ³0x0020 ³Executable attribute                    ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_READ        ³0x0010 ³Readable attribute                      ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_USER        ³0x0008 ³User attribute                          ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_WRITE       ³0x0004 ³Writeable attribute                     ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_HUGE        ³0x0002 ³Object is huge                          ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_SHRINKABLE  ³0x0001 ³Object is Shrinkable (only if also      ³
³               ³       ³OB_SHARED)                              ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³OB_DHSETMEM    ³0x0001 ³DevHlp_VMSetMems are allowed the object ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Notes:

See Pseudo-Objects when OB_PSEUDO is set.

OB_API is set as a result of allocation made by some APIs (for example, DosExecPgm). It forces page alignment and signals a likelihood of long-term locking.

OB_HUGE is set when the object is created by DosAllocHuge API.

When OB_LOCKWAIT is set then the thread has detected a lock request conflict and wishes to wait for the conflict to resolve. The conflict occurs because a contiguous storage lock has been requested but cannot be satisfied because one or more of the pages are already short-term locked. If the current request is for a short-term lock then the thread will wait up to 10 seconds for the conflict to clear. If the time-out expires then the current short-term lock request ends in error and the following message appears on the debugger screen:

VMLOCK: Short term lock for > 10 secs: hob=hob

If the current request is for a long-term lock then the thread will wait indefinitely. In both cases the block Id the thread waits on is the address of the VMOB flag word (VMOB+0x4). See .PB command for information on thread slots waiting on Block Ids.

own
This is the hob of the owner of this object. The owning hob may be in one of three categories:
• System Owner
  Used to indicate system owned objects. The owner description usually indicates the type of object that is being displayed. For example, the LDT for process 9 running pulse.exe is owned by system object 0xffb9 and has a description
  ldt 0009 c:pulse.exe.
  2. Module Owner (hmte)
  This is used for shared (code and data) objects that are part of a load module file. The .hmte of the associated load module is used as the Owner Id for the object. The object description names the owning module from the MTE/SMTE structures. See .LM command for related information.
  3. Process owner (hptda)
  Process owned objects are those allocated in the private arena of a running process and are either dynamic allocations or non-shared module segments, for example stack segments. The hptda of the process is used as the owner. The owner description names the process id and executable module of the owning process.
  hmte
  This names the hmte or System Object Id of the executable code that allocated the memory object or in the case of data segments of modules, whith which they are associated.
  sown
  Semaphore owner id. This is the thread slot number that owns the memory management semaphore associated with this object. Memory management uses the address of the VMOB as the block Id to sleep on when the semaphore is held. This semaphore is used to serialise access to a VMOB structure. See .PB command for information on thread slots waiting on Block Ids.
  cnt
  Count of owners of the VMOB semaphore and wait flag.

  The low order bit of cnt is used as a wait indicator. The high order 7 bits are a count of the number of times the owning thread has requested the VMOB semaphore without releasing it. See sown filed above for related information.

  xf
  Extra flags.

  The following flags are defined:

  ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
  ³name            ³bit  ³description                             ³
  ³                ³mask ³                                        ³
  ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  ³VMOB_SLOCK_WAIT ³0x01 ³Waiting on short term locks to clear    ³
  ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  ³VMOB_LLOCK_WAIT ³0x02 ³Waiting on long term locks to clear     ³
  ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  ³VMOB_DISC_SEG   ³0x04 ³Object is part of a discardable seg     ³
  ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  ³VMOB_HIGHMEM    ³0x08 ³Object was allocated via dh_vmalloc     ³
  ³                ³     ³using the VMDHA_USEHIGHMEM flag         ³
  ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
  

  Notes:

  The lock wait flags indicate that a thread is waiting for locked pages in the memory object to be unlocked, but not to resolve a conflicting lock request: that is indicated with the OB_LOCKWAIT flag.

  If a thread blocks waiting for long-term locks to clear then the address of the long-term lock count (VMOB + 0xd) is used as the Block-Id the thread blocks on. The thread blocks indefinitely.

  If a thread blocks waiting for short-term locks to clear then the address of the short-term lock count (VMOB + 0xe) is used as the Block-Id the thread blocks on. The thread will block for up to 10 seconds. If after that time the short-term lock has not been cleared then an error is returned and under the debug kernel the following message is sent to the debug console:

  VMLOCK: Short term lock for > 10 secs: hob=hob
  

  See .PB command for information on thread slots waiting on Block Ids.

  lt
  Count of active long-term lock holders. A non-zero value indicates one or more pages of the memory object have been long-term locked, that is prevented from being paged out from physical storage. Long-term locks are expected to be held for a relatively long period of time, in the order of seconds. See .MP command for information on displaying physical storage status. See also VM Lock Trace Kernel Debugger facility.
  st
  Count of active short-term lock holders. A non-zero value indicates one or more pages of the memory object have been short-term locked, that is prevented from being paged out from physical storage. Short-term locks are expected to be held for a relatively short period of time, in the order of mili-seconds. See .MP command for information on displaying physical storage status. See also VM Lock Trace Kernel Debugger facility.
  description
  The object description appears to the right of the tabular display. It is combines the interpretation of own and hmte fields. The following forms are possible:

  Process owned objects

  
  These appear as:
  priv pid process
  where:
  pid
  is the owning process id
  process
  is the executable running the owning process
  MTE Owned objects
  These appear as:
  shared module
  where:
  module
  is the name of the module that contains the object (hob) displayed.
  PTDA Pseudo-objects
  These appear as:
  ptda pid process
  where:
  pid
  is the process id in which the object is located.
  process
  is the executable running the owning process
  MTE Pseudo-objects
  These appear as:
  mte module
  where:
  module
  is the module name that corresponds to the MTE pointed to by the va
  LDT occupying storage
  This appears as:
  ldt pid process
  where:
  pid
  is the id of the process that owns the LDT related to the object
  process
  is the executable running the owning process
  Free objects
  These appear as:
  free
  System Owned Objects
  These appear as:
  owner user
  where:
  owner
  is the system object name corresponding to the own field.
  user
  is the system object name corresponding to the hmte field.

  Note: From fix pack 29 of Warp 3.0 and GA Warp 4.0 the hmte of all objects with a system owner id is also formatted in the user part of the description.

  ---

  [Back] [Next]