Starts the threshold manager configuration program.
ADDTHRESHOLD (AT) ResourceName ThresholdValue YES|NO ControlName
DELETETHRESHOLD (DT) ResourceName ThresholdValue
DISABLERESOURCE (DR) ResourceName
ENABLERESOURCE (ER) ResourceName
MODIFYINTERVAL (MI) TimeInterval
MODIFYTHRESHOLD (MT) ResourceName OldThresholdvalue
[YES | NO]
SHOW (SH) [ALL | DEFAULT | ResourceName ]
The following is a brief description of the system resources currently
monitored by Threshold Manager.
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 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.
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.
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.
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.
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
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
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.
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.
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.