THMGR


THMGR

     Starts the threshold manager configuration program.

SYNTAX

     THMGR


PARAMETERS

     Internal commands:

ADDTHRESHOLD (AT) ResourceName ThresholdValue YES|NO ControlName
DELETETHRESHOLD (DT) ResourceName ThresholdValue
DISABLEMANAGER (DM)
DISABLENOTIFY (DN)
DISABLERESOURCE (DR) ResourceName
DISPLAY (DS)
ENABLEMANAGER (EM)
ENABLENOTIFY (EN)
ENABLERESOURCE (ER) ResourceName
EXIT (E)
HELP (H)
LISTREDO (LR)
MODIFYINTERVAL (MI) TimeInterval
MODIFYTHRESHOLD (MT) ResourceName OldThresholdvalue
[NewThresholdvalue]
[YES | NO]
[ControlName]
REDO
RESET (RT)
SHOW (SH) [ALL | DEFAULT | ResourceName ]



OPERATION

     The following is a brief description of the system resources currently
monitored by Threshold Manager.

ACCESS RIGHTS
This resource is also referred to as the Extent B-Tree AR Table.
 Disk files and virtual memory disk areas are allocated in contiguous
pieces called "extents". Each node in the Extent AR B-Tree can describe
 up to eight extents. If an object contains more than eight extents, it
 will use additional nodes as needed. Every non-resident object with
 variable access rights will obtain one or more nodes in this table when
it is mapped in (opened). NOTE: Objects with variable access rights are
 those for which not all pages have identical read and/or write access or
the same privilege level. NM program files and NM library files are
examples of objects with variable access rights. Page 0 has write access
in addition to the read/execute access that is given to the other pages
of the file. Extent information about objects with fixed access rights is
kept in the Extent B-TreeTable.

CM CODE SEGMENTS
Compatibility Mode (CM) Code Segments are part of a Segmented Library (SL).
 Entries in the Code Segment Table (CST) are allocated whenever an SL segment
is loaded for the first time. This occurs when: *A CM program is executed via
 the :RUN command with the ;LIB=option *SL segments are :ALLOCATEd *A procedure
 (in a Segmented Library) is loaded via the LOADPROC intrinsic CST entries are
 shared. Loading a SL segment after the first time will not result in the
 allocation of an additional CST entry. When the last user of a particular
code segment unloads that segment, the CST entry is released.

CM DATA SEGMENTS
Compatibility Mode (CM) Data Segments contain program data for processes
 during the time they execute in compatibility mode, and for system data
 structures that have not yet been converted to Native Mode (NM). Also,
 some CM data structures may have been retained because some application
and third party code depend on accessing them directly. Note that even
 some NM programs may need CM Data Segment entries.

CM PHYSICAL CODE SEGMENTS
Compatibility Mode (CM) Physical Code Segments are allocated by the
operating system and typically are contained in the system Segmented
Library (SL.PUB.SYS). There are 255 entries in the CST which are reserved
  for these segments.

CM PORTS COMPLETION
CM Ports Completion are used as a fast queuing and messaging system within
the operating system, primarily by datacomm subsystems. Processes (including
 system processes) create ports at which they can receive brief messages from
 other processes or other parts of the system. Typically, processes will
eventually wait on some port, to be awakened when a message arrives then
 act on that message.

CM PORTS
CM Ports are used as a very fast queuing and messaging system within the
 operating system. Processes (including system processes) create ports at
 which they can receive brief messages from other processes or other parts
of the system. Typically, processes will eventually wait on some port and
 then be awakened when a message arrives then act on that message.

FILE DESCRIPTORS
This resource is also referred to as the VSOD/GUFD table (Virtual Space
 Object Descriptor/Global Unique File Descriptor Table). Every object in
 the system requires an entry in either the VSOD or VSOD/GUFD table (with
 the exception of certain resident objects that reside in the Disabled
 Expandable VSOD table). All file objects obtain an entry in the VSOD/GUFD
 table when they are mapped in (or opened). When the file is mapped out
(closed), the entry is linked onto a list known as the LRU (Least Recently
 Used) list. If the same file is opened again, the LRU list is searched to
 see if an entry already exists for that file. If so, the entry is re-used
 which saves the overhead of mapping the file in again. If the entry is not
 on the LRU list, a new entry must be obtained. If there are no free entries
 in the table, an entry is obtained from the LRU list. The object previously
 associated with that LRU entry is now considered to be mapped out.

Entries are allocated within the Process Local File Descriptor (PLFD) table.
 Each PLFD entry is paired with a GDPD entry within the PLFD table. However,
 if a native mode file is opened with Multi Access (intra-job) or G-Multi Access
 (inter-job), then the GDPD entry is allocated from the System GDPD table.
 Subsequent opens of the same Multi Access file will share the same GDPD entry.
 If the file is a CM file (for example, Message, RIO, or Circular files), then the
GDPD entry is allocated in the PLFD, and the FMAVT table manages the Multi Access.

FILE EXTENTS
This resource is also referred to as the Extent B-Tree Table. Disk files and
 virtual memory disk areas are allocated in contiguous pieces called "extents".
Each node in the Extent B-Tree can describe up to four extents. If an object
 contains more than four extents, it will use additional notes as needed. Every
 non-resident object with fixed access rights will require one or more nodes
 in this table when it is mapped in (opened).
 NOTE: Objects with fixed access rights are those for which all pages have
 identical read and/or write access as well as the same privilege level.
Extent information about objects with variable access rights is kept in
the Extent AR B-Tree Table.

I/O NOTIFICATIONS
This resource is also referred to as the MM I/O Notify Table (Memory Manager
 Input/Output Notify Table). The MM I/O Notification Table contains one entry
 per page for each I/O request on that page (a page can be requested by
several processes at a time). Entries are added when a process needs to
 be notified of an I/O completion. Entries are deleted when the process has
 been notified or when it is determined that a process need not be notified
 for a particular page.

I/O REQUESTS
This resource is also referred to as the MM I/O Request Table (Memory Manager
  Input/Output Request Table). The I/O Request Table contains one entry for
 each I/O request on the system. The entry keeps track of the status of the
request. Entries are added at the time the I/O request is sent. This table
 contains one entry per Memory Information Block (MIB) chain (I/O request).
 Entries are deleted when the requesting processes have been notified.
This table is different from the I/O Notification Table which has one entry
per process that has requested an I/O (the same page can be requested several
 times by different processes).

LOCALITY LIST ENTRIES
When a process needs to have pages brought into memory in order to continue
 execution, these pages will be added to its locality list. Before a process
is launched, MPE/iX scans the locality list, brings the pages into memory,
 and then allows the process to run. This avoids the process faulting on pages
 it already faulted on recently. The entries in this table are added each time
 a process experiences a page fault on a virtual address, or when a process
prefetches anobject. The entries are deleted when the pages have been brought
 into memory.

MEMORY INFORMATION BLOCKS
The MIB Table is a Memory Management data structure that contains one entry
 for each Memory Information Block on the system. A MIB is a global data
 structure used by the Memory Manager, the Virtual Space Management, and
 the I/O subsystems to handle requests for I/O.
 MIBs are allocated by Virtual Space Management in response to Memory Manager
 requests to execute an I/O. Each of the three subsystems manages its own
 area of the MIB for which it is responsible. MIB entries are created at
 I/O request time and are released when the I/O has completed.

PROCESS INFORMATION BLOCKS
This table maintains some of the information about each active process
 on the system. Each process requires one PIB (Process Information Block)
entry. A process, in MPE terminology, is an instance of the running of
 any program. Thus if user A runs program X and user B runs that same
 program X, there are two additional processes running on the system.
 Each direct logo requires 2 processes; a Job Session Main (JSMAIN) and
 a Command Interpreter (CI). If in addition, the job or session runs a
 simple program which does no process handling, that would make a total
 of 3 processes (and thus 3 PIB entries) for that logon. Remote sessions
require an additional PIB entry for the Virtual Terminal Server (VTSERVER)
 process. Many applications and third party products use process handling
 to call additional processes - each additional process requires an additional
 PIB entry while that process is active. For planning purposes, you should
 assume that the system will use approximately 100 PIB entries which will
not be available for user processes.

SHARED GLOBAL SPACE
This resource is also known as SR6/SR7 short pointer space due to the
 architecturally defined method of accessing the data contained here.
 This space is used for some operating system objects (tables),
 Compatibility Mode (CM) data segments and short mapped files.

SYSTEM VOLUME SET PERMANENT SPACE
This refers to the disk space on the MPEXL_SYSTEM_VOLUME_SET volumes which
 can be allocated for permanent files and the operating system data structures.
 Theoretically, this space can be a maximum of 100% of the total disk space on
 the set. However, operating system transient data structures also use disk space
 from the same pool of disk space on the set, and therefore the maximum of 100%
 os not attainable. By the characteristics of the set defined during its
 initialization, 100% of the total disk space is available for both permanent
and transient spaces. Every time some transient space is allocated, the pool
 size of free disk space available for permanent space decreases, thus affecting
 the percentage usage of the permanent space too. This holds true for the other
way too.

SYSTEM VOLUME SET TRANSIENT SPACE
This refers to the disk space allocated on the MPEXL_SYSTEM_VOLUME_SET volumes
 to hold system data structures which are transient in nature. Transient data
 structures are created by the operating system in order to accomplish a task
on behalf of a user, and only exist for the duration of the task. There are
 certain transient data structures which are independent of the user_initiated
 tasks but exist for the whole duration that the system is running. However, in
 no case, a transient data structure left over from the previous boot is used
 in the current boot.
Unlike permanent disk space, transient disk space has no usefulness across
 consecutive boots, and the transient space which is not deallocated in the
 current boot (for example, the system is aborted abruptly) is always first
deallocated into the free disk space pool. Since both permanent and transient
disk spaces are allocated from the same pool of free disk space, even if only
 either of the two is being allocated at any time, the percent usage of the other
 is also affected. This is because the percent usage is calculated as the ratio
 of the total space allocated for either permanent or transient spaces to the
 sum of this space and the pool size of the free space.

TIMERS REQUEST LIST
This table is very similar to the resource Timers, shown below. The only
 difference in function is that Timers_Reg_Lis is used only by compatibility
 mode code. Please refer to Timers for a description of this table's function.

TIMERS
This resource is also known as the Timer Table. Timer entries are used
 throughout the system to manage asynchronous events. Jobs, sessions,
 file system, I/O, and networking subsystems all generate timer requests.
 Additionally, users can utilize intrinsics such as FREAD for timed
reads or PAUSE to indirectly request a timer entry.

VIRTUAL SPACE CACHE
This resource is also referred to as the VPN Cache Table (Virtual Page
 Number Cache Table). Disk files and virtual memory disk areas are allocated
 in contiguous pieces called "extents". Each VPN Cache entry corresponds to
 pages of an extent that are currently in memory (or ready to be mapped
 in/out of memory). Entries are added (locked in) when pages of an extent
are mapped in memory and they are deleted (unlocked) when pages of an extent
 are mapped out of memory. The number of entries per open file depends on the
 pattern of access to the file. The VPN Cache table size does not directly limit
 the number of open files, but does limit the total number of pages from all
 files that can be simultaneously present in memory.

VIRTUAL SPACE OBJECTS
This resource is also referred to as the VSOD Table (Virtual Space
 Object descriptor Table). Every object in the system (files, system tables,
 user stacks, etc.) requires an entry in either the VSOD or VSOD/GUFD table
 (with the exception of certain resident objects that reside in the
 Disabled Expandable VSOD table). All non-file transient objects (for
 example, system tables or user stacks) obtain an entry in the VSOD table
 when they are mapped in (or created). When the object is mapped out, the
 entry is released. There is no LRU (Least Recently Used) list for the VSOD
 as there is for the VSOD/GUFD.

VIRTUAL STORAGE
This resource is also referred to as the VS B-Tree Table. Every object
 in the system (files, system tables, user stacks, etc.) requires an entry
 in the VS B-Tree Table. Each node of this B-Tree can describe up to 32
 different objects. Each object described in this table will have a
 corresponding entry in the VSOD, VSOD/GUFD, or Disabled Expandable VSOD
 tables. When the object is mapped out (released), the entry is deleted.

EXAMPLE(S)

     THMGR

ADDITIONAL INFORMATION

Commands: