T4 Installation and Configuration Guide for OpenVMS

Your zipped up T4 kit includes the following files (xxx is either "X86", "AXP", or "I64", depending on platform):

You will need the SYSNAM privilege to establish the logical names required to successfully install T4 and make it ready to run.

Once you have moved this PCSI kit to your OpenVMS system, you may need to reset the file attributes. These can sometimes be altered in transit depending on how the transfer was accomplished. If necessary, the appropriate reset can be accomplished with the following command:

$ SET FILE/ATTRIBUTE=(RFM:FIX,LRL:512,MRS:512,ORG:SEQ,RAT:NONE)
VSI-VMS-T4-V0404-E-1.PCSI$COMPRESSED

If you are already running a version of T4, be sure you deassign your current T4$SYS system-wide logical name before installing the new kit.

$ DEASSIGN T4$SYS /SYS

You can now install the latest T4 V4.4-F kit using:

$ PRODUCT INSTALL T4

This installs the kit to the [.T4$SYS] subdirectory beneath SYS$SYSDEVICE:[VMS$COMMON] (that is, SYS$SYSDEVICE:[VMS$COMMON.T4$SYS])

To install to a different directory, use the /DESTINATION option as follows:

$ PRODUCT INSTALL T4/DESTINATION=disk$somewhere:[dir.tree]

This installs the kit to the [.T4$SYS] subdirectory beneath the destination directory (that is, disk$somewhere:[dir.tree.T4$SYS]).

The T4 kit must be installed separately on each node where you expect to run it.

Once you have installed the T4 V4.4-F kit, you will find many more files of additional reference material.

This is a critical step to ensure full utilization of T4 on your systems. By defining key T4-related logical names are defined as permanent, interrupted T4 sessions can resume automatically after a system reboot, preventing data loss. The logical names of interest, T4$SYS and T4$DATA, are discussed below.

To define the T4$SYS logical name and make it permanent, add the definition to the system startup SYLOGICALS.COM command procedure and run the following command:

$ DEFINE /SYSTEM /EXEC T4$SYS SYS$SYSDEVICE:[VMS$COMMON.T4$SYS]

When running T4 collections, you must have a convenient and suitably sized disk location available to store the performance data generated by T4. Configure this data disk before installing and reference it using the T4$DATA logical name. It is equally important to make this logical name permanent by adding the definition to the system startup code SYLOGICALS.COM command procedure which allows T4 sessions to resume following system reboots.

$ DEFINE /SYSTEM /EXEC T4$DATA Your_Data_Disk:[000000.T4$DATA]

You can establish a separate T4$DATA area for each OpenVMS system or you can set up a single T4$DATA disk that is available to all nodes on your OpenVMS cluster.

For each OpenVMS node that is going to be monitored with T4, a local batch queue is required to run T4 jobs on that node. This may be an existing queue (assuming it has available job slots), or a dedicated T4 batch queue can be created for that node, as shown below.

First, start the queue manager if not already started:

$ START/QUEUE/MANAGER/NEW

Create and start up a new batch queue:

$ INITIALIZE/QUEUE/START/BATCH T4$BATCH /JOB_LIMIT=10
$ SHOW QUEUE/BATCH/FULL
Batch queue T4$BATCH, idle, on NODEX::
/BASE_PRIORITY=4 /JOB_LIMIT=10 /OWNER=[SYSTEM]/PROTECTION=(S:M,O:D,G:R,W:S)

You will need one batch queue and one T4 collection session for each OpenVMS node you are going to monitor. As noted above, all the collected and processed data from these sessions will be saved to the T4$DATA directory.

The User Account (for example, T4_USER) that you plan to use to run T4 will require the following QUOTAS:

$ MC AUTHORIZE
UAF> MODIFY T4_USER /PRCLM=20/TQELM=100/PGFLQUOTA=500000
UAF> EXIT

The user responsible for launching T4 history creation sessions must have the ALTPRI privilege. This allows the OpenVMS Monitor Utility to run at the recommended process priority of 15.

For critical and performance-sensitive systems, VSI recommends launching T4 in long-term history mode by responding Yes when prompted with the following question:

Re-Submit data collection job daily [N] : Y

This approach builds a detailed, day-by-day performance history over time.

The actual size you will need for your T4 history area depends on several key factors:

To estimate the required disk space, VSI recommends starting with at least 500,000 blocks. Run a trial session (see quick instructions below) of 1 to 2 hours and determine how much disk space is needed for that run.

Then, adjust the size of the T4$DATA storage area as necessary to meet your needs.

T4 includes some rudimentary capabilities for assisting you in the management of your T4$DATA performance history area. Since the data that T4 helps you collect may prove invaluable to you in the future, VSI recommends that you think through and apply your standard local site policies for backing up, archiving, and preserving this potentially priceless historical system information.

Once T4 is installed, the T4 user account is configured with the required privileges and process limits, a T4 batch queue is established on each monitored node, and the T4$DATA storage area is created, you are ready to launch your first T4 V4.4-F collection session.

To help estimate the required disk space you will require to run T4 in its recommended long-term history mode, run the following command and respond to the prompts according to the guidelines shown below:

$ @T4$SYS:T4$CONFIG.COM

Once the run is complete, check the sizes of the files created in the T4$DATA directory. This will give you an idea of the approximate storage costs per hour for this OpenVMS node. The sections below describe the types of files created during a T4 session and the suggested retention periods of each type of data.

After determining an appropriate size for the T4$DATA area by following the steps above, you are ready to launch T4 in long-term history mode. Long-term history mode for T4 is explicitly designed to maximize the benefits that T4 can provide. At the same time it helps to minimize how much time you will have to spend and keep that down to an absolute bare minimum.

Here are some recommendations for parameter values to use in response to the questions triggered by running the following command:

$ @T4$SYS:T4$CONFIG.COM

T4 collection sessions will continue collecting and storing performance data until the batch jobs are deleted.

T4 produces a composite CSV file daily for each node being monitored. The names of these files are of the form:

T4_nodename_Collection_Date_start_time_end_time_COMP.CSV

For example, a one hour run on node PRFE40 might look like:

T4_PRFE40_28JUN2005_1400_1500_COMP.CSV

These *COMP.CSV files are typically the first files reviewed.

The output of a T4 collection session includes:

Note that after the CSV and DAT files are ZIPped, T4 will delete them, leaving only the ZIP files.

The key CSV files are:

The remaining CSV files are considered intermediate files and can be deleted after a few days.

VSI recommends that you retain all ZIP files that contain CSV's for at least eighteen months. VSI recommends retaining the ZIP files which contain DAT's for at least 45 days.

Even beyond eighteen months, if older CSV files need to be removed, VSI recommends archiving them to a permanent storage location that remains accessible when needed. At some point, you may need to review data from two or three years ago to compare current performance with historical behavior. This is only possible if these performance timeline files are retained and properly preserved.