[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here

HP OpenVMS System Management Utilities Reference Manual


Previous Contents Index

H.4.2.16 STATES Class Record

The STATES class record contains data describing the number of processes in each of the scheduler states. The STATES class record has a record type of 1 and a size of 72 bytes.

Figure H-23 illustrates the format of the STATES class record.

Figure H-23 STATES Class Record Format


The following table describes the fields in the data block for the STATES class record:

Field Symbolic Offset Contents
Collided
Page Wait
MNR_STA$L_COLPG Number of processes in collided page wait (longword,L)
Misc
Resource Wait
MNR_STA$L_MWAIT Number of processes in miscellaneous resource wait (longword,L)
Common Event
Flag Wait
MNR_STA$L_CEF Number of processes in common event flag wait (longword,L)
Page Fault
Wait
MNR_STA$L_PFW Number of processes in page fault wait (longword,L)
Local Event Flag,
Inswapped
MNR_STA$L_LEF Number of processes in local event flag wait, inswapped (longword,L)
Local Event Flag,
Outswapped
MNR_STA$L_LEFO Number of processes in local event flag wait, outswapped (longword,L)
Hibernate,
Inswapped
MNR_STA$L_HIB Number of processes in hibernate wait, inswapped (longword,L)
Hibernate,
Outswapped
MNR_STA$L_HIBO Number of processes in hibernate wait, outswapped (longword,L)
Suspended,
Inswapped
MNR_STA$L_SUSP Number of processes in suspended wait, inswapped (longword,L)
Suspended,
Outswapped
MNR_STA$L_SUSPO Number of processes in suspended wait, outswapped (longword,L)
Free Page
Wait
MNR_STA$L_FPG Number of processes in free wait (longword,L)
Compute State,
Inswapped
MNR_STA$L_COM Number of processes in compute state, inswapped (longword,L)
Compute State,
Outswapped
MNR_STA$L_COMO Number of processes in compute state, outswapped (longword,L)
Current MNR_STA$L_CUR Number of current processes (longword,L)

H.4.2.17 SYSTEM Class Record

The SYSTEM class record contains data describing the overall operation of the three major system components (CPU, memory, I/O). The SYSTEM class record has a record type of 17 and a size of 52 bytes. Note that when the SYSTEM class is recorded, the PROCESSES, STATES, and MODES classes are also recorded, even if not explicitly requested.

Figure H-24 illustrates the format of the SYSTEM class record.

Figure H-24 SYSTEM Class Record Format


The following table describes the fields in the data block for the SYSTEM class record:

Field Symbolic Offset Contents
CPU Busy MNR_SYS$L_BUSY Count of clock ticks (10-millisecond units) spent in all CPU modes since system was booted (longword,C)
Other States MNR_SYS$L_OTHSTAT Number of processes in states other than LEF, LEFO, HIB, HIBO, COM, COMO, PFW, and MWAIT (longword,L)
Process Count MNR_SYS$L_PROCS Number of processes in system (longword,L)
Page Faults MNR_SYS$L_FAULTS Count of page faults for all working sets (longword,C)
Read I/Os MNR_SYS$L_PREADIO Count of read I/Os resulting from disk page faults (longword,C)
Free Page Count MNR_SYS$L_FREECNT Number of pages currently on free-page list (longword,L)
Modified Page Count MNR_SYS$L_MFYCNT Number of pages currently on modified-page list (longword,L)
Direct I/Os MNR_SYS$L_DIRIO Count of direct I/O operations (longword,C)
Buffered I/Os MNR_SYS$L_BUFIO Count of buffered I/O operations (longword,C)

H.4.2.18 TIMER Class Record

The TIMER class record contains data that is useful to the OpenVMS executive when monitoring timer queue entries (TQEs). The TIMER class record has a record type of 26 and a size of 32 bytes.

Figure H-25 illustrates the format of the TIMER class record.

Figure H-25 TIMER Class Record Format


The following table describes the contents of each of the TIMER class record fields:

Field Symbolic Offset Contents
Total TQEs MNR_TMR$L_TQE_TOTAL Count of all TQEs processed per second.
SYSUB TQEs MNR_TMR$L_TQE_SYSUB Count of SYSUB TQEs processed per second.
Timer TQEs MNR_TMR$L_TQE_TIMER Count of timer requests made by users per second.
Wakeup TQEs MNR_TMR$L_TQE_WAKEUP Count of wakeup timer requests made by users per second.

H.4.2.19 TRANSACTION Class Record

The TRANSACTION class record contains data describing the operations of the DECdtm transaction manager. The TRANSACTION class has a record type of 22 and a size of 72 bytes. Figure H-26 illustrates the format of the TRANSACTION class record.

Figure H-26 TRANSACTION Class Record Format


The following table describes the contents of each of the TRANSACTION class record fields:

Field Symbolic Offset Contents
Starts MNR_TRA$L_STARTS Count of transactions started. The number of times that calls on the local node to $START_TRANS have completed successfully (longword, C).
Prepares MNR_TRA$L_PREPARES Count of transactions that have been prepared (longword, C).
One Phase Commits MNR_TRA$L_ONE_PHASE Count of one-phase commit events initiated (longword, C).
Commits MNR_TRA$L_COMMITS Count of transactions committed. This is the combined total of one-phase and two-phase commits (longword, C).
Aborts MNR_TRA$L_ABORTS Count of transactions aborted. Combined total of planned and unplanned aborts (longword, C).
Ends MNR_TRA$L_ENDS Count of transactions ended. The number of times that calls on the local node to $END_TRANS have completed successfully (longword, C).
Branches MNR_TRA$L_BRANCHS Count of transaction branches started on the local node (longword, C).
Adds MNR_TRA$L_ADDS Count of transaction branches added on the local node (longword, C).
0-1 Transactions MNR_TRA$L_BUCKETS1 Count of transactions with a duration of less than 1 second (longword, C).
1-2 Transactions MNR_TRA$L_BUCKETS2 Count of transactions with a duration of 1 to 2 (1.99) seconds (longword, C).
2-3 Transactions MNR_TRA$L_BUCKETS3 Count of transactions with a duration of 2 to 3 seconds (longword, C).
3-4 Transactions MNR_TRA$L_BUCKETS4 Count of transactions with a duration of 3 to 4 seconds (longword, C).
4-5 Transactions MNR_TRA$L_BUCKETS5 Count of transactions with a duration of 4 to 5 seconds (longword, C).
5+ Transactions MNR_TRA$L_BUCKETS6 Count of transactions with a duration greater than 5 seconds (longword, C).


Appendix I
HP OpenVMS Integrity servers Serial Multiplexer (MUX) Support for Integrity Servers

RS232 serial lines and multiplexers are used for a variety of tasks, from traditional terminal connections to low-speed system-to-system communication and even for communication with remote instruments. OpenVMS has traditionally supported adding serial lines at the same time as option-card-based multiplexers. This solution requires dedicating I/O slots; it also limits the choices of option cards available.

With the widespread adoption of the Universal Serial Bus (USB) on industry-standard platforms, a variety of USB-based serial-line dongles and multiplexers are now available. (Dongles are single-function devices with a connector.) OpenVMS has moved away from option-card-based serial multiplexers and has adopted USB to add serial lines to HP Integrity servers.

USB-based serial devices have many configurations; these vary from single-line dongles to rack-mounted 16-line (or more) multiplexers. Rather than using one or two option-card solutions with 8 or 16 lines for all configurations, you can now configure USB to meet your exact requirements.

Testing shows that the USB-based serial multiplexers perform as well as (or better than) their option-card counterparts and cause very low overhead to the system. In fact, the overhead is lower than option-card-based multiplexers.

I.1 Conforming Devices

OpenVMS has developed USB interface drivers for the three most popular RS232 chipsets on the market:

  • Prolific PL2303
  • FTDI FT232AM and FTDI FT232BM
  • Inside Out Networks EDGEPORT (from DIGI)

Many sources exist for products based on these chips. OpenVMS has purchased a number of representative products on the open market to validate them. A list of devices that OpenVMS has tested, along with an overview of their capabilities and limitations, is in the section called "Tested Devices." (OpenVMS intends to continue to update this list regularly and to make it available on its Web page.)

Because consumer products are often short-lived, OpenVMS periodically samples the market for new devices. You can also contact the OpenVMS organization directly at the following Web site to request that a specific product be validated:


     http://h20219.www2.hp.com/services/cache/77481-0-0-225-121.html 

For the devices listed in "Tested Devices," the OpenVMS organization accepts bug reports from customers and produces driver ECO fixes as needed. Driver support for these devices ships with the base operating system and does not require a separate layered-product kit or license.

Tested Devices

The following devices have been tested on OpenVMS:

  • Inside Out Networks EDGEPORT/416 (DB9) and EDGEPORT/8 (DB25)
    • The EDGEPORT/416 DB9 (DIGI Part Number 301-1000-10) is a dual RS232 controller with 8 lines per controller (and a total of 16 lines). The device is packaged as two 8-line controllers behind a USB hub; it also provides 4 additional USB expansion ports. The device is powered from a DC adapter integrated on the back of the device.
    • The EDGEPORT/8 DB25 (DIGI Part Number 301-1016-08) is a single RS232 controller with a total of 8 lines. The device is bus powered and does not require an external power supply.

    These devices are rack mountable. Both devices have a unique serial number; they are always assigned the same name, regardless of the USB port into which they are plugged. Testing of these devices shows reliable operation in both software flow control and raw binary (no flow control) modes at up to 115,200 baud.
    The system parameter TTY_SILOTIME controls latency; it trades throughput and system overhead for latency. The default value for TTY_SILOTIME is 8. This value is multiplied by 100 and is used to represent the number of times a query is sent to the device for more data after a character transmit or receive.
    If no input (or no subsequent output) is seen after 800 responses to the query, the driver stops sending queries to the device and waits for an input interrupt. Reducing the TTY_SILOTIME value allows the device to buffer more data, with slightly higher latency.
    Increasing the value of TTY_SILOTIME makes the device more sensitive to latency but decreases buffering and overall throughput; it also adds more system and USB overhead. Setting TTY_SILOTIME to zero causes the driver to send input queries to the device continually. This setting causes the lowest latency, the highest system overhead, and the lowest throughput possible.

    Note

    The TTY_SILOTIME system parameter has no effect on Prolific or FTDI devices. The EDGEPORT controller design is different from devices that do not respond to a request until the device has data and a buffer timeout is reached. As a result, input data is buffered whenever possible.
    In contrast, the EDGEPORT, responds immediately to input requests regardless of the amount of data available, and sends asynchronous reports about the availability of new data. This allows either a highly buffered implementation or one that is similar to polling.
  • Cool Gear (VScom) FTDI 8-Port RS232 (DB9)
    This device (USBGEAR.COM Order Number 8XDB9-USB) is an 8-port DC adapter-powered device that contains 8 individual FDTI FT232BM chips and configures as 8 individual single-line controllers.
    The controllers have unique serial numbers and are always assigned the same OpenVMS name, regardless of the USB port into which a controller is plugged.
    Tests of this device show reliable operation in both software flow control and raw binary (no flow control) modes at up to 115,200 baud.
  • Prolific PL2303 4-Port RS232 Cable Dongle (DB9)
    This device (USBGEAR.COM Order Number USBG-4X232) is a 4-port wire dongle (4 wires connected to a single USB connector), with 4xDB9 connectors on the wires. The cables contain a USB hub and 4 PL2303 serial controllers. The device is bus powered and does not need a separate power supply.
    This device provides no serial number. The persistence of its name is based on where it is plugged (that is, its path topology); when the device is plugged at a different location, it appears to be a different instance of the device.
    Tests of this device show reliable operation in both software flow control and raw binary (no flow control) modes at up to 115,200 baud.
  • FTDI 232AM Single-Port RS232 Dongle (DB9)
    This device (USBGEAR.COM Order Number USBG-232MINI) is a single-port dongle (no wire) that plugs into a single USB port. The device is bus powered and needs no external power supply.
    The device provides a serial number and is configured with the same OpenVMS device name regardless of where it is plugged.
    Tests of the device show reliable operation in both software flow control and raw binary (no flow control) modes at up to 115,200 baud.
  • USBG-4-DOC-1 Multifunction Docking Station
    This multifunction device (USBGEAR.COM Order Number USBG-4-DOC includes the following:
    • 1 Prolific RS232 (DB9) serial port
    • A PS2-USB keyboard port converter
    • A PS2-USB mouse port converter
    • A bidirectional parallel port
    • A 4-port USB hub

    This device is useful when only a single line is needed and when a parallel port, PS2 keyboard or mouse connectivity, or additional USB ports are required.
    The device provides no serial number, and its name persistence is based on where it is plugged (path topology). When the device is plugged in at a different location, it appears to be a different instance of the device.
    Tests of this device show reliable operation in both software flow control and in raw binary (no flow control) modes at up to 115,200 baud.

I.2 Device Installation

The low-range and mid-range Integrity servers provide builtin USB controllers and at least two ports on the system. High-end cell-based systems often do not have builtin USB controllers and sometimes require an optional card (HP Part Number A6869A) to add USB ports.

If no keyboard and mouse are used on the system, you can connect the USB serial device directly to one of the USB ports on the system. The USB design allows expansion of available ports using a hierarchical series of hubs. A hub usually expands an available USB port into 4 USB ports; this means that two ports on most systems can be expanded up to as many as 128 ports by using additional hub devices. By default, OpenVMS recognizes USB devices and configures them automatically (with no additional user action).

UCM assigns USB device names as devices are discovered. When you use multiple similar devices, the order of discovery determines the name. The permanent (persistent name) database obtains the same OpenVMS device name each time the system is booted and the device is found.

Devices that have a unique serial number are always given the same name after they are added to the permanent database. Devices with no serial number are given the same name only when they are plugged into the USB bus hierarchy in the same place as when the name was made persistent. If the device is moved to a different USB port, UCM considers it a new device, and it is given its own unique name.

For more information about controlling USB device configuration, see the HP OpenVMS System Management Utilities Reference Manual.

The following actions are required to configure a serial multiplexer:

  • Boot the system and then connect the device. (You can connect the device prior to booting as well.)
  • By default, OpenVMS automatically detects and connects the device. You can verify this by entering the following command:


       $ SHOW DEVICE TX 
    

The lines are ready to use and are always given the same name or names when OpenVMS VMS boots or when the device is connected. (A device without a serial number, however, is considered to be a different device when it is connected to a different port.)


Previous Next Contents Index