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).

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.

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.)