node from the database. That is, in the absence of a valid connection to that OpenVMS node, the information in the database is assumed to be correct.

G.1.8 Keeping Your Storage Environment Up to Date

The TNT$UTILITY.COM utility accepts parameters (UPDATE STORAGE) to update the storage database. However, the storage database is updated dynamically every time you use the OpenVMS Management Station client to perform a storage management operation. Therefore, you do not need to run TNT$UTILITY.COM to update the storage database.

G.1.9 Enabling Disk Quotas

Before installing OpenVMS Management Station, you might have disabled disk quotas on the SYSTEM disk. If so, reenable the quotas and then rebuild to update quota information by entering the following commands:

$ RUN SYS$SYSTEM:DISKQUOTA DISKQUOTA> ENABLE DISKQUOTA> REBUILD DISKQUOTA> EXIT

G.1.10 Caching Storage Configuration Data

OpenVMS Management Station uses two logical names to determine how often to refresh cached (in-memory) storage configuration data.

TNT$PURGE_CYCLE_LATENCY—Determines how often (in seconds) to wait after purging stale device reports before purging again. This value affects how frequently the clusterwide data (maintained by a master server) is updated in memory.

min

=

180

 

 

default =

1800

(30 minutes)

max

=

18000

(5 hours)

TNT$LOCAL_SURVEY_LATENCY—Determines the delay (in seconds) from one node-specific device survey to the next. This value is independent of clusterwide surveys requested by the master server when performing a purge.

min

=

6

 

 

default

=

60 (1 minute)

max

=

600

(10 minutes)

For both logical names, smaller values result in the OpenVMS Management Station server consuming more CPU cycles in periodic purges or surveys.

If you do not accept the defaults, you might find that larger OpenVMS Cluster systems perform better with values on the high end of the allowed range.

If you do not define these logicals, the OpenVMS Management Station server uses the default values. If you do define these logical names, the values are used only if they are within the accepted range.

G.1.11 Running Third-Party TCP/IP Stacks

TCP/IP Services for OpenVMS Version 5.6 is the only supported TCP/IP stack. Additional stacks have not been tested. However, TCP/IP stacks that are 100 percent compliant with the QIO interface for TCP/IP Services for OpenVMS should also work. (Contact your TCP/IP vendor for additional information and support issues.)

For the best chance of success, check the following:

Make sure that the QIO service (for example, UCXQIO) is enabled.

For TCPware (from Process Software Corporation), also make sure that the TCPware UCX$IPC_SHR.EXE is an installed image.

Also for TCPware, make sure you are running a version of TCPware that correctly implements a DEC C-compatible socket interface.

262 Preparing to Use OpenVMS Management Station

Page 262
Image 262
HP OpenVMS 8.x manual Caching Storage Configuration Data, Running Third-Party TCP/IP Stacks