Document revision date: 19 July 1999

It is not necessary to remove your existing queue startup and volume mount DCL procedures immediately. The OpenVMS Management Station server will recognize that you started a queue or mounted a volume with your command procedures and will assume that you want it that way.

As you become familiar with the server's management ability, you can remove or comment out the DCL commands and procedures that perform these tasks and allow OpenVMS Management Station to control your printer and storage environment.

In addition, the OpenVMS Management Station server periodically (every 24 hours) generates a DCL command procedure that includes the commands to mount all of the volumes managed by OpenVMS Management Station. If you are familiar with DCL, you can look at this command procedure to see what actions OpenVMS Management Station performs for you. And, in the event of an unforeseen system problem or a corrupt server database (SYS$SYSTEM:TNT$ACS.DAT), you could use this command procedure to mount the volumes.

The name of the generated file is TNT$EMERGENCY_MOUNT.COM. TNT$EMERGENCY_MOUNT.COM is created in SYS$SYSTEM or in the directory pointed to by the TNT$ACS logical, if that logical name exists.

The OpenVMS Management Station server limits TNT$EMERGENCY_MOUNT.COM to seven versions.

D.1.7 Keep Your Printer Environment Up to Date

The OpenVMS Management Station server installation creates a file named SYS$STARTUP:TNT$UTILITY.COM. This command procedure scans the OpenVMS system and updates the database of known printers, queues, and related devices.

D.1.7.1 When is the Database Updated?

The database is updated:

• As part of the OpenVMS Management Station installation.
• When you specifically invoke TNT$UTILITY.COM.
• At periodic intervals as a server background thread. Two logical names control how often this server thread runs:

  Logical Name	Description
  TNT$PRINTER_RECON_INTERVAL	How often the thread should run, in minutes, from when the server was last started on this node. If you do not define this logical, the default value is 1440 minutes (24 hours).
  TNT$PRINTER_RECON_INTERVAL_MIN	The minimum number of minutes that must elapse before the thread should run again, starting from when the database was last updated. If you do not define this logical, the default value is 60 minutes (1 hour).

You can think of these logicals as meaning "run the thread this often (TNT$PRINTER_RECON_INTERVAL), but make sure this much time has elapsed since the database was last updated (TNT$PRINTER_RECON_INTERVAL_MIN)."

Because you can run TNT$UTILITY.COM yourself, and because the OpenVMS Management Station server also updates the database, the TNT$PRINTER_RECON_INTERVAL_MIN logical prevents the database from being updated more frequently than is actually needed.

If you want to change the defaults for one of these logicals, define the logical on all nodes on which the OpenVMS Management Station server is running.

D.1.7.2 Do You Need to Run TNT$UTILITY.COM Manually?

If you use OpenVMS Management Station to make all of the changes to your printer configuration, the configuration files are immediately modified to reflect the changes and you probably do not need to specifically run TNT$UTILITY.COM.

However, if you or someone else uses DCL to make a change --- for example, if you use the DELETE /QUEUE command to delete a queue --- the configuration files will not be synchronized. In this case, the OpenVMS Management Station client will advise you to run TNT$UTILITY.COM to resynchronize the database.

Run the following procedure on one node in the cluster to make the database match your system:

$ @SYS$STARTUP:TNT$UTILITY.COM UPDATE PRINTERS

For example, if you or someone else used DCL to delete a queue, you need to delete that queue from the database. TNT$UTILITY.COM assumes that your system is set up and running the way that you want it to, so you should fix any problems before you run TNT$UTILITY.COM.

D.1.7.3 Are There Any Requirements for Running TNT$UTILITY.COM?

You need the SYSNAM privilege to run TNT$UTILITY.COM.

TNT$UTILITY.COM connects to the OpenVMS Management Station server on the current OpenVMS system to determine device and queue information. Therefore, the OpenVMS Management Station server must be running on the node where you run TNT$UTILITY.COM.

The OpenVMS Management Station server then connects to the other OpenVMS Management Station servers in the OpenVMS Cluster to determine device and queue information. It is generally a good idea to keep the OpenVMS Management Station server running on the other nodes in an OpenVMS Cluster to keep the database up to the minute.

However, if the OpenVMS Management Server is not able to connect to the OpenVMS Management Station server on a given node, it uses the known information about that OpenVMS 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.

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

D.1.9 Enabling Disk Quotas

Before installing OpenVMS Management Station, you might have disabled disk quotas on the SYSTEM disk. If so, you should 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

D.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 to wait (in seconds) after purging stale device reports before purging again. This value affects how frequently the cluster-wide 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 cluster-wide 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 behave 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 minimum to maximum range.

D.1.11 Running Third-Party TCP/IP Stacks

DIGITAL TCP/IP Services for OpenVMS Version 3.2 or higher is the only supported TCP/IP stack. Additional stacks have not been tested. However, TCP/IP stacks that are 100% compliant with the QIO interface for DIGITAL 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, also make sure that TCPware's UCX$IPC_SHR.EXE is an installed image.
• Also for TCPware, make sure you are running a version of TCPware that correctly implements a DECC-compatible socket interface, such as Version 5.3-3.

If you encounter a problem while using OpenVMS Management Station, please report it to Compaq. Depending on the nature of the problem and the type of support you have, you can take one of the following actions:

• If your software contract or warranty agreement entitles you to telephone support, call Compaq.
• If the problem is related to OpenVMS Management Station documentation, use the Internet address printed in front of this book to send us your comments.

If you use the POLYCENTER Software Installation utility to remove OpenVMS Management Station from the OpenVMS system, the following files are not removed:

• TNT$ACS.DAT
• TNT$JOURNAL.TNT$TRANSACTION_JOURNAL
• TNT$SERVER_ERROR.LOG
• TNT$UADB.DAT
• TNT$EMERGENCY_MOUNT.COM

Do not delete these files unless you have already removed OpenVMS Management Station.

D.2 Preparing Your PC

During the OpenVMS installation or upgrade procedure, you selected the OpenVMS Management Station client software files to be installed on your OpenVMS system disk (or you added them later using the DCL command PRODUCT INSTALL TNT). After you have prepared your OpenVMS system to run the server software, you must next prepare your PC to run the client software.

This section includes the following information:

• Required memory and disk space
• Required software
• Installing the client software
• Getting started using OpenVMS Management Station

Your PC requires 13 MB of free disk space to install the OpenVMS Management Station client software.

D.2.2 Distribution Files

There are two versions of the OpenVMS Management Station client kit: TNT030_I.EXE for Intel systems (Windows 95 and Windows NT), and TNT030_A.EXE for Alpha Windows NT systems. Both of these files are located in the SYS$COMMON:[TNT.CLIENT] directory.

The Intel kit will not install under FX!32 running on Alpha processors; use the Alpha native kit in this case.

D.2.3 Required Software

Microsoft Windows NT Versions 4.0 (Service Pack 3 or higher) or Windows 95 or higher (Intel only) must be installed on each PC on which you want to install the OpenVMS Management Station client.

The version of MMC included in this baselevel requires files provided by Microsoft Internet Explorer. Version 3.02 or later of Internet Explorer must be present on the system.

D.2.4 Time Required for Installation

The time required to install the OpenVMS Management Station client software is approximately 5 minutes.

D.2.5 Copy the Client File to the PC

The client files TNT030_I.EXE (Intel) and TNT030_A.EXE (Alpha) are located in the SYS$COMMON:[TNT.CLIENT] directory. Copy either client file to a temporary directory the PC using any of the following procedures:

• Create a file share to the OpenVMS system and copy the file.
• Use FTP on the PC to copy the file from the OpenVMS system.

The installation procedure allows you to select the installation directory, and suggests \Program Files\OpenVMS Mgmt Station\ as the default.

D.2.7 Installation Procedure

Run TNT030_I.EXE (Intel) or TNT030_A.EXE (Alpha) from a temporary directory. These are self-extracting executable files that automate the OpenVMS Management Station installation.

D.2.8 Recovering from Errors

If an error occurs during installation, you will receive an error message describing the problem. This information can help you determine the cause of the problem. An error can occur during the installation if one or more of the following conditions exist:

• The operating system version is incorrect.
• Disk space and memory necessary for successful installation are inadequate.

When you create an OpenVMS Cluster or OpenVMS Node object in an OpenVMS Management Domain, you select the transport you want to use for all connections to that system. You can choose DECnet Phase IV or TCP/IP.

OpenVMS Management Station uses this transport for all communications between the PC and this system, or between any other OpenVMS system that is running the OpenVMS Management Station server and this system.

You do need to make sure that your PC can connect to the primary-server systems, as described in the following sections. OpenVMS Management Station connects your PC to the primary-server system and then routes management operations to the target systems.

D.3.1 Defining TCP/IP Nodes

Your hosts file or name server must be able to resolve the IP name or address of all primary-server systems. If you can successfully ping the primary-server systems from your PC, then this condition is met.

D.4 Uninstalling Version 2.1 of the OpenVMS Management Station Client

Version 3.0 of the OpenVMS Management Station client is not dependent on Version 2.1 and does not share any files with this prior version. After installing the Version 3.0 client, you can uninstall the Version 2.1 client software.

D.5 Uninstalling OpenVMS Management Station

If you need to uninstall the OpenVMS Management Station client software, make sure you first exit OpenVMS Management Station. The uninstallation fails if OpenVMS Management Station is currently running.

If you run the OpenVMS Management Station Help, the following files might be created:

• VMSMGMT.FTS
• VMSMGMT.GID
• VMSPRINT.FTS
• VMSPRINT.GID
• VMSSCOPE.FTS
• VMSSCOPE.GID
• VMSSTORE.FTS
• VMSSTORE.GID
• VMSACNT.FTS
• VMSACNT.GID

The OpenVMS Management Station Uninstall program does not delete these files. To complete the uninstall:

1. Delete these files
2. Delete the OpenVMS Management Station directory

Note that the OpenVMS Management Station Uninstall program does not uninstall the Microsoft Management Console (MMC) support files.

D.6 Getting Started with OpenVMS Management Station

All information about getting started, setting up, and using OpenVMS Management Station is contained in online help and the OpenVMS Management Station Overview and Release Notes.

You can remove the OpenVMS Alpha operating system from your disk in the following ways:

• If the disk contains a small number of user files, copy those user files elsewhere and then reinitialize the disk.
• If the disk contains many user files, use the PRODUCT REMOVE command to remove an obsolete or extra copy of the OpenVMS Alpha operating system without removing any of the user files. Note that you must also delete or archive certain operating system files that the PRODUCT REMOVE command cannot delete.

Follow these steps to remove OpenVMS Alpha operating system files:

1. If your system disk has multiple system-specific roots, boot the system and execute SYS$MANAGER:CLUSTER_CONFIG.COM to remove all roots except the one from which you are booted.
2. Shut down and boot from the distribution CD-ROM or from a system disk other than the one from which OpenVMS Alpha is being removed. Then do one of the following:
   • If OpenVMS Alpha is not running from the distribution CD-ROM, log in to a privileged account.
   • If OpenVMS Alpha is running from the distribution CD-ROM, choose the option to execute DCL commands.
3. Enter the following DCL commands:

   $ DEFINE/NOLOG PCSI$SYSDEVICE target-disk $ DEFINE/NOLOG PCSI$SPECIFIC target-disk:[SYSx.] $ DEFINE/NOLOG PCSI$DESTINATION target-disk:[VMS$COMMON] $ PRODUCT REMOVE VMS /REMOTE

   
   where:

   • target-disk is the device name of the disk from which OpenVMS Alpha is being removed.
   • SYSx is the root number that you did not remove in step 1.
4. If the disk also contains layered products that were installed using the POLYCENTER Software Installation utility, Compaq recommends that you remove them as well. Remove any layered products before using the PRODUCT REMOVE VMS command.
   Use the following command to remove all the products at once. Select the layered products you want to remove from the menu.

   $ PRODUCT REMOVE * /REMOTE

   
   Use the following commands to remove individual products:

   $ PRODUCT SHOW PRODUCT/REMOTE $ PRODUCT REMOVE product-name /REMOTE

5. Because the PRODUCT REMOVE command does not delete certain files, review the target disk to determine if you want to delete, move, or archive the operating system files that still remain on the disk.
   Following are lists of the files that the PRODUCT REMOVE command does not delete:
   • In target-disk:[SYS*.SYSEXE], where * is 0 or the hexadecimal number of any additional OpenVMS Cluster roots on the target disk:
     • ALPHAVMSSYS.PAR
     • MODPARAMS.DAT
     • PAGEFILE.SYS
     • SWAPFILE.SYS
   • In target-disk:[VMS$COMMON.SYSEXE]:
     • LMF$LICENSE.LDB
     • PCSI$FILE_SYSTEM.PCSI$DATABASE
     • PCSI$PROCESSOR.PCSI$DATABASE
     • PCSI$ROOT.PCSI$DATABASE
     • RIGHTSLIST.DAT
     • SYSUAF.DAT
   
   As you examine the preceding lists of files, you may want to archive, rather than delete, the following files:
   • ALPHAVMSSYS.PAR
   • MODPARAMS.DAT
   • LMF$LICENSE.LDB
   • RIGHTSLIST.DAT
   • SYSUAF.DAT
   
   Also, if you previously removed layered products, there may be additional files created by the layered products that you may want to delete, move, or archive.
6. Review the target disk for the directory structures [VMS$COMMON...] and [SYSx...] that remain after you remove the OpenVMS Alpha operating system. You may want to delete these directories.
   Note that the directories [SYSx]SYSCOMMON.DIR (in all [SYSx]) are aliases for the file [000000]VMS$COMMON.DIR. DO NOT DELETE THESE SYSCOMMON.DIR files. Instead, use SET FILE /REMOVE as follows:

   $SET FILE /REMOVE [SYS*]SYSCOMMON.DIR

   
   After you have executed this command and deleted, moved or archived all the files in [VMS$COMMON...] you can delete [000000]VMS$COMMON.DIR. You can then proceed to delete, move or archive the files in each [SYSx] directory.

	privacy and legal statement
6522PRO_015.HTML