Technical Update for Tru64 UNIX Version 4.0F
August 2001

© 2001 Compaq Computer Corporation

This online supplement contains information about restrictions and problems that have been discovered since Tru64 UNIX Version 4.0F began shipping to customers. The notes herein apply to the operating system and the bundled layered products that accompany it.

New Features Notes

May 26, 2000: Compaq Capacity on Demand (CCod)

CCoD systems contain two types of CPUs, those that will be purchased initially with the system, and those that can be made available as processing requirements grow. The additional CPUs, reserved for expansion, are kept in the offline state and can be brought on line immediately without having to reboot the system.

The CCoD software is bundled as a layered product; therefore, you must install it after Tru64 UNIX has been installed.

Once you have purchased CCoD, use the setld command to install the following software subset: CODBASE400 Capacity on Demand

Instructions for installing, configuring, and using CCoD are included in the kit.

See the CCoD README file and the codconfig(8) reference page for more information on CCoD.

You can find additional information and the CCoD kit at:

Installation Notes

August 30, 2000:  Restrictions on setld Utility 

The setld utility does not handle directory names that contain white space.

Processor--Specific Notes

August 19, 1999:  Updated Restrictions on VMEbus Master Block Transfers for Alpha VME and AXPvme Systems 

To prevent potential DMA data loss on Alpha VME or AXPvme systems when using the VIP/VIC adapter's DMA engine to perform master block transfers (MBLTs/BLTs) to a VMEbus slave, new restrictions apply.

Failure to adhere to these restrictions may result in data loss during DMA transfers. Existing MBLT code should be reviewed for adherance to these restrictions. A future release of the operating system will check that DMA addresses adhere to these restrictions.

This note applies to Alpha VME and AXPvme systems, including the EBV10, EBV12, EBV14, and EBV16 single-board computers. This note supersedes the section "Restrictions on VMEbus Master Block Transfers" in the Tru64 UNIX vme_manual_update(7) reference page.

The following restrictions apply to using MBLTs on the Alpha VME and AXPvme platforms. These restrictions are listed by DMA transfer data-width below.

Note that you can use the valloc function to allocate memory aligned to a page boundary, as described in the valloc(3) reference page.

For the best DMA performance, the VMEbus address and the memory address should be aligned to a 256 byte boundary for D16 and D32 DMA transfers, or to a 2048 byte boundary for D64 DMA transfers.

April 19, 2000: SMARTengine/Alpha 21264 PCI/ISA Single-Board Computer

This section provides notes that apply to the SMARTengine/Alpha 21264 PCI/ISA single-board computer (SBC), the newest member of a family of PCI/ISA-based modular computing components.

The SMARTengine/Alpha 21264 PCI/ISA SBCs are PICMG-compliant processor cards based on the Compaq Alpha 21264 CPU.

Verifying CPU Version

The sizer utility can be used to identify SMARTengine/Alpha 21264 SBCs. The sizer -c command displays the following output for SMARTengine/Alpha 21264 SBCs:

sysname> sizer -c
cpu      "DMCCEV6"

Firmware Requirements

Before installing the operating system, make sure that your system has the correct firmware version. The minimum firmware version required for SMARTengine/Alpha 21264 SBCs is Version 5.6-6903 or higher. If you have an earlier firmware version, update your firmware before installing the operating system software. For information on how to update your firmware, see the firmware documentation.

To determine the version of firmware on your system, enter the following console firmware command at the prompt:

>>> show version

Installing Tru64 UNIX

For information about installing the operating system on a SMARTengine/Alpha 21264 SBC, see the Tru64 UNIX Installation Guide. Where the Installation Guide provides platform-specific instructions for booting, follow the same instructions as for PCI/ISA (DMCC) EBMnn SBCs, such as the EBM2n and EBM4n.

Mandatory Tru64 UNIX Version 4.0F Patches

All SMARTengine/Alpha 21264 SBCs running Tru64 UNIX Version 4.0F are required to install Tru64 UNIX Version 4.0F Patch Kit-0003 or higher. The latest Version 4.0F Patch Kit can be obtained at the following web location:

Without the patch kit, intermittently a SMARTengine/Alpha 21264 system may not respond to its serial ports, COMA and/or COMB. Although the system will continue to respond to network pings and will accept serial input, its serial output hangs.

Tru64 UNIX Version 4.0F Patch Kit-0003 or higher also fixes the following problems observed with the SMARTengine/Alpha 21264 SBC:

Restrictions and Known Problems

The following restrictions and known problems apply to SMARTengine/Alpha 21264 SBCs.

Option Card Restrictions

You can use the SMARTengine/Alpha 21264 PCI/ISA SBC on PCI/ISA backplanes in the ETMXB/ETMAB family and in corresponding kernels (platforms) in the ETMnn family. Supported PCI/ISA Backplanes and Kernels lists the currently supported PCI/ISA backplanes and kernels.

Supported PCI/ISA Backplanes and Kernels

Backplane Kernel Description
ETMXB-BA ETM05-xx 5-slot PICMG (2 PCI, 1 PCI/ISA, 1 ISA, 1 SBC)
ETMXB-DA ETM27-SA, 3X-ETM17-xx 7-slot PICMG (3 PCI, 1 PCI/ISA, 1 ISA, 2 SBC [1 SBC slot usable at a time])
ETMAB-CA ETM25-xx, 3X-ETM15-xx 10-slot PICMG (6 PCI, 1 PCI/ISA, 1 ISA, 2 SBC [1 SBC slot usable at a time])
ETMAB-EA ETM29-xx, 3X-ETM19-xx 10-slot PICMG (4 PCI/ISA, 4 ISA, 2 SBC [1 SBC slot usable at a time])
ETMAB-AB ETM31-CA 14-slot PICMG (7 PCI, 6 ISA, 1 SBC)
ETMAB-BB ETM33-CA 14-slot PICMG (10 PCI, 3 ISA, 1 SBC)
ETMAB-AC ETM42-CA 19-slot PICMG (10 PCI, 7 ISA, 2 SBC [1 SBC slot usable at a time])
ETMAB-BC ETM44-CA 19-slot PICMG (13 PCI, 4 ISA, 2 SBC [1 SBC slot usable at a time])

Table Note

All ETMAB backplanes use PCI-to-PCI bridge (PPB) technology to provide both primary (in front of the bridge) and secondary (behind the PPB) slots. All ETMAB backplanes are PCI Version 2.1 compliant.

The option cards shown in PCI/ISA Options Supported Behind the Bridge, in addition to working in front of the bridge, work behind the bridge. You can plug these cards into any available slot.

PCI/ISA Options Supported Behind the Bridge

Option Type Part Number Description
Graphics SN-PBXGB-AA TGA2 2MB PowerStorm 3D30
Graphics SN-PBXGK-BB Elsa GLoria Synergy
SCSI KZPBA-CB Qlogic PCI Ultra Wide differential SCSI controller
SCSI KZPCM-DA Dual-channel PCI to Ultra SCSI adapter with Ethernet controller
SCSI KZPSA-BB PCI differential SCSI adapter
SCSI SN-KZPBA-CA Qlogic PCI-SCSI Ultra Wide adapter (supports both narrow and wide drives)
SCSI KZPAA-AA PCI-SCSI host bus adapter
Network DE450-CA PCI NIC (TP, TW, AUI)
Network DE500-BA PCI NIC (TP)

Table Note

The SN-PBXGB-AA (TGA2 PowerStorm 3D30) video card will work behind a bridge in multiple configurations if the first card is within the primary bus. For restrictions on jumper settings and X server DMA for the PowerStorm 3D30 card, see PBXGB-AA (TGA2 PowerStorm 3D30) Video Card Restrictions.

PBXGB-AA (TGA2 PowerStorm 3D30) Video Card Restrictions

The following restrictions apply to the PBXGB-AA (TGA2 PowerStorm 3D30) video card (listed in PCI/ISA Options Supported Behind the Bridge):

Operator Control Panel and Watchdog Timer Supported Only in Hardware and Firmware

The operating system does not support the operator control panel or watchdog timer. These server management features are supported only in the hardware and the firmware.

IDE Device Mapping Potentially Impacts 21264 SBC Upgrades

Tru64 UNIX identifies the IDE controllers on the SMARTengine/Alpha 21264 SBC as SCSI devices, which affects the naming of all other SCSI devices in the system. Even though the operating system does not support IDE drives on the 21264 SBC, the IDE controllers are configured during the system boot, causing the disk numbering to be shifted as if two SCSI controllers were added to the configuration.

This is not a significant issue for deploying new systems on the 21264 SBC or for SBC upgrades performed with a new Tru64 UNIX system installation, but can cause problems for SBC upgrades performed without a new system installation.

The altered naming of SCSI devices can create problems with /etc/fstab file entries and logical storage manager (LSM) features that rely on a previous installation's device naming.

After a 21264 SBC upgrade, if the existing system disk has been renumbered (for example, from rz0 to rz16), the existing system will not boot from the existing system disk. The root, usr, and swap partitions to which fstab points no longer exist. To resolve the problem, you must edit the fstab file, changing device name references (for example, from rz0 to rz16). As the swap partition is not accessible, the root partition can not be made writeable. Thus the fstab file must be modified before the existing system is upgraded, or the Tru64 UNIX distribution CD-ROM must be booted in single-user mode to edit the file.

If LSM features were used in connection with the existing system installation, further steps may be necessary. After a 21264 SBC upgrade, LSM volume data on any renumbered disk will no longer match the physical configuration. In particular, if a system disk containing LSM volumes is renumbered, changes similar to the following will be required before the upgraded system will boot into multiuser mode:

Writing PCI Bus Device Drivers

For information about writing PCI bus device drivers, refer to the Tru64 UNIX Device Driver Kit (DDK), which is orderable separately from the base operating system.

You can browse a subset of Tru64 UNIX device driver writing materials in the Library section of the Compaq Tru64 UNIX web site, currently located at:

You can find the latest DDK technical updates at the same location.

April 15, 2000: VMEbus Backplane (vb) Network Driver Performance Enhancement Patch

Tru64 UNIX Version 4.0F Patch Kit-0003 or higher includes a VMEbus backplane (vb) network driver patch that provides new parameters for tuning and enhancing vb data transfer performance. The latest Version 4.0F Patch Kit can be obtained at the following web location:

With Patch Kit-0003 or higher applied, four vb parameters, described below, can be modified using normal sysconfig mechanisms to increase throughput for direct memory access (DMA) and/or programmed I/O (PIO) data transfers.


Before you modify any vb parameters, you must read the guidelines and cautions for modifying vb per-node and per-network parameters in the vb(7) reference page.

May 19, 2000: AlphaStation 500/400, AlphaStation 500/500 and AlphaStation 600 Systems

The firmware for these systems contains a memory restriction that prohibits bootlinking the kernel. An attempt to bootlink a kernel may result in a system hang. In some cases, an attempt to boot a customized kernel may also cause a system hang.

May 1, 2001: KZPCC i2o Upgrade and Recovery Procedure

This technical update provides upgrade information and recovery procedures relating to the i2o (Intelligent I/O) driver update. The i2o interface is supported only on the KZPCC PCI backplane RAID controllers. You manage the i2o configuration using the StorageWorks Command Console (SWCC). Disks appear as ri or dsk devices to the operating system and as DZA devices at the console prompt when you use the >>> show dev command. You can determine whether your system uses this configuration by entering the following command:

# sysconfig -q i2o_bs
Module_Config_Name = i2o_bs
Subsystem_Description = I2O Block Storage driver
I2O_Option = attribute does not allow this operation
Driver_Version = 2.00
Num_Attached = 1
major_number = 76
major_number_old = 75
Max_Job_Pool_Size = 64
i2o_bs_debug = 0

On an up-to-date system, the Driver_Version must be 2.00, and not 1.00.

A framework error is displayed if your system does not use the i2o configuration. If you do not use any such devices, you do not need the information in this technical update. See ri(7) for more information on i2o.

The following sections describe the operating system revisions and upgrade paths to which this technical update applies.

Supported Versions

The following revisions of Tru64 UNIX support configurations that can include the KZPCC controller and i2o disks:

Valid i2o Migration Paths

Valid migration paths for i2o configurations by using update installation are as follows:

Scope of this Procedure

The operating system automatically assigns device names to every disk discovered during the boot. Normally, hardware configurations are stored and are recovered across operating system upgrades. Because the i2o driver is updated during upgrades and installations, the configuration must be preserved and restored using a software patch. The patch is identified as patch id .399 of Patch Kit 3. New installations of Version 5.1 to i2o disks are unaffected provided you install the patch during installation.

If you do not install the patch, the following problems will occur:

The patch application is fully automated. The recovery procedures in this technical update are provided in the unlikely event that a problem might occur during the upgrade. If such a problem leaves your system in an unusable state, you wil be able to recover it manually.

Overview of the Patch Procedure

The normal patch procedure should work as follows:

  1. Back up your system

  2. Upgrade your system.

  3. Install the patch kit

  4. Systems configured with a KZPCC will reboot on the first boot of the patched kernel.

    The patch kit will automatically find and update the i2o configuration. To verify that the patch has prevented any problems, observe the screen messages during the reboot. The following example shows a truncated boot display that includes the i2o messages

    i2c: Server Management Hardware Present
    vm_swap_init: Unexpected swapon for swap device /dev/disk/dsk0b
    vm_swap_init: swap is re-set to lazy (over commitment) mode
    Checking device naming:
    Mounting / (root)
    ufs_mount: mount device does not match fstab
    user_cfg_pt: reconfigured
    root_mounted_rw: reconfigured
    user_cfg_pt: reconfigured
    root_mounted_rw: reconfigured
    user_cfg_pt: reconfigured
    dsfmgr: NOTE: updating kernel basenames for system at /
    scp kevm tty00 tty01 lp0 dsk1 dsk2 dsk3 dsk4 floppy0 cdrom0
    Assigning a cluster device number to root
    dsfmgr: NOTE: creating device special files for system at /
    +dsk5a +dsk5a +dsk5b +dsk5b +dsk5c +dsk5c +dsk5d +dsk5d +dsk5e 
    +sk5e +dsk5f +dsk5f +dsk5g dsk5g +dsk5h +dsk5h
    Restoring i2o disk names to their original values:
      Changing new hwid:name 59:dsk5 to (25)dsk0 . . . done.
    syncing disks... CP - SAVE_TERM routine to be called
    CP - SAVE_TERM exited with hlt_req = 1, r0 = 00000000.00000000
    halted CPU 0
    halt code = 5
    HALT instruction executed
    PC = fffffc0000535e40
    CPU 0 booting
    (boot dza514.0.0.2004.1 -file vmunix -flags A)
    block 0 of dza514.0.0.2004.1 is a valid boot block

    The bolded text is the message that you will see when the restoration is successful. This Changing new hwid.... message is displayed for each disk in turn. No further intervention is necessary.

If the upgrade and patch procedure functions correctly, the migration (or preservation) of your disk device names is transparent and your upgraded system will function normally. If the procedure did not function correctly, your system will not boot to a corrct working state and you will be immediately aware of device name problems. See Recovery Procedures for recovery procedures.

Recovery Procedures

Use these recovery procedures only if your system does not reboot and operate correctly after an upgrade or an installation. Your system must comply with the i2o and operating system requirements defined in May 1, 2001: KZPCC i2o Upgrade and Recovery Procedure.

Reapply Patch .399

Patch .399 must be installed. If the patch is removed from a configuration where i2o devices are in use, the dsk device names of the i2o disks might be incorrect. This problem occurs because the system assigns new hardware identifiers and creates new device special files (such as dev/disk/dskN) for the i2o disks.

If the patch is removed, or if any problems occur during the upgrade, use the following procedure to recover:

  1. Shut the system down to single-user mode.

  2. Reapply patch .399 as defined in the patch kit documentation.

  3. Reboot the system.

If the system does not boot correctly to multi-user mode, see Manually Restore the Device Names.

Manually Restore the Device Names

System will not boot to multi-user mode This problem occurs because the system was unable to determine the correct device names. You must manually restore the device names as described in the following procedure:

  1. The system must be shut down and halted to the console prompt (>>>)

  2. Boot the system to single user mode as follows:

    >>> boot -fl s

  3. Mount the root file system for read and write access as follows:

    # mountroot

  4. Use the /sbin/hwmgr command to obtain device data as follows:

    # /sbin/hwmgr view devices
    HWID: Device Name      Mfg  Model            Location
     4: /dev/kevm
    58: /dev/disk/dsk5c          i2o_bs           iop-0-tid-514
    46: /dev/disk/floppy0c       3.5in floppy     fdi0-unit-0
    53: /dev/disk/cdrom0c  DEC   RRD46   (C)DEC   bus-0-targ-5-lun-0
    54: /dev/disk/dsk1c    DEC   RZ1BB-CA (C)DEC  bus-1-targ-0-lun-0

    Any i2o devices are shown as Model i2o_bs. In the preceding command output, you can see that the i2o device is assigned the device name /dev/disk/dsk5. The device name is dskN. You can ignore the trailing c character, which is the partition identifier.

  5. Examine the /etc/i2oNameData.log file to find the previous dskN device special names for the i2o devices. For example:

    # cat /cluster/members/membern/etc/i2oNameData.log

    The output provides you with the following information:

  6. Having determined that the former device name was dsk0 and the new device name is dsk5, you can now restore the former device name. First, use the /sbin/hwmgr command to delete the old database entries for each i2o device, by specifying its former HWID as follows:

    # hwmgr delete component -id 25

  7. Use the /sbin/dsfmgr command to remove the existing device special files (dev/disk/dskNa) for each i2o device, by specifying its former HWID as follows:

    # /sbin/dsfmgr -R hwid 25
     -dsk0a -dsk0b -dsk0c -dsk0d ... dsk0h

  8. Use the /sbin/dsfmgr command to move the existing device special files (dev/disk/dskNa) for each i2o device, by specifying its former and current device names as follows:

    # /sbin/dsfmgr -m dsk5 dsk0

  9. Reboot the system as follows:

    # shutdown -h now

  10. Reboot the system to single user mode using the generic kernel as follows:

    >>>  boot -fl s -fi genvmunix

  11. When the single-user prompt (#) is displayed, apply the patch immediately as described in Reapply Patch .399.

    Do not alter the KZPCC configuration until patch .399 of Patch Kit 3 is installed as specified in the Patch Kit documentation.

Contact your technical support representative if you are unable to correct your system configuration using these procedures.

Base Operating System Notes

October 11, 1999: The executable_stack System Attribute

The executable_stack system attribute was added to Tru64 UNIX Version 4.0F. This attribute allows or disallows execute privilege on the user program stack for programs that would otherwise have this privilege. A value of 1 allows this privilege; a value of 0 disallows it. The default value is 0.

Disallowing execute privilege on the user program stack enhances system security but does not affect normal programs.

You can modify this attribute at run time. Although certain applications may require the program stack to be executable, it is strongly recommended that you set executable_stack to 1 only on systems (such as those behind firewalls) that are not vulnerable to security violations.

June 10, 1999: Problem with the at Command During Daylight Saving TimeProblem with the at Command During Daylight Saving Time

The at command has a problem scheduling jobs at the start of Daylight Saving Time (DST) in time zones and countries where daylight saving time applies. The problem occurs for jobs set to execute during the transition hour on the day the clocks are set ahead.

Currently, if you schedule a command to run during the hour when the clocks are set ahead, the command runs an hour earlier. For example, if you schedule a job to run at 2:30 AM on the day the clocks are set ahead, the job is executed at 1:30 AM, which is one half hour before 3:00 AM.

Alternatively, you can schedule the job to run an hour later. Then it will run between 3:00 and 4:00 AM.

June 10, 1999: Patch Kit for Users of Elsa Gloria Synergy Video Graphics Adapter

Customers who have an AlphaServer 800, 1000A, 1200, 4000, 4100, DS10, DS20, or ES40 and wish to use the Elsa Gloria Synergy® video graphics adapter, part number SN-PBXGK-BB, are required to install the Tru64 UNIX Version 4.0F SSB kit and the Tru64 UNIX Version 4.0F Patch Kit-1 in order to ensure correct graphics performance.

The Tru64 UNIX Version 4.0F Patch Kit-1 can be found in the Tru64 UNIX Version 4.0F SSB kit on a separate CD-ROM with part number AG-RJA9A-BE, or can be found at the following web site:

June 10, 1999: Very Small AdvFS Domains Created in lockmode

Creation of AdvFS domains smaller than 20 MB while running in lockmode 4 might cause the system to panic when the first fileset is created within the small domain. Such domains can safely be created and used if the system is not running in lockmode 4. To see which lockmode the system is running in, enter the following command:

% sysconfig -q generic lockmode

August 31, 2000: Security Flaw in Netscape Communicator

Versions of Netscape Communicator less than version 4.75 contain a security vulnerability that could potentially allow unauthorized users read only access to your file system. This vulnerability, known as Brown Orifice, exploits the Navigator components ability to run programs written in the Java Programming Language. Compaq highly recommends upgrading any version of Netscape Communicator you are using on Tru64 UNIX less than version 4.75 to Netscape Communicator 4.75 or later to avoid this security vulnerability. To determine which version of Netscape Communicator you are running, click on the Help button in the toolbar at the top of the Navigator component window, then choose the About Communicator option from the drop down menu. You can download the latest version of Netscape Communicator for Tru64 UNIX from the Netscape Download World Wide Web site :

Alternatively, you can download from the following Compaq Tru64 UNIX World Wide Web site:

If you are unable to upgrade to Netscape Communicator 4.75 or later, you can avo id this security vulnerability by disabling the browsers ability to run Java by following these steps:

  1. Start Netscape Communicator:

    $ /usr/bin/X11/netscape

  2. Click on the Edit button in the toolbar a t the top of the Navigator component window.

  3. Click on the Preferences option on the drop down menu that appears when the Edit button is selected. This will display the Netscape: Preferences dialog.

  4. In the window pane on the left of the Netscape: Preferences dialog, click on the Advanced tab. This will display the advanced Communicator preferences in the dialog.

  5. If the box next to the Enable Java preference has a check mark in it, click on the box to remove the check mark. This will disable the Java Programming Language. Then click on the OK button in the Advanced preferences dialog.


    If there is not a check mark in the box, you do not need to take any action.

  6. Exit Netscape Communicator by clicking on the Exit option in the drop down menu that appears when you click on the File button on the toolbar at the top of the Navigator window.

Disabling Java ensures Netscape Communicator is not vulnerable to Brown Orifice. Disabling JavaScript is not required to avoid this vulnerability. Users of the Japanese or Chinese interfaces provided in the Worldwide Language Support software must update the Communicator version numbers in /usr/lib/X11/*/app-defaults/Nets cape if they choose to upgrade to Netscape Communicator 4.75 or later. If the version numbers in these files do not match the version of Netscape Communicator installed, it will not run in the Japanese or Chinese locales.

You can download the updated files from the Compaq Tru64 UNIX World Wide Web site:

December 6, 2000: diskconfig LSMnopriv Option Does Not Work

The LSMnopriv partition type in diskconfig does not work and generates an error when applied. To create such a partition, invoke the disklabel command directly with an fstype of LSMnopriv. This problem will be corrected in a future release.

Development Environment Notes

September 17, 1999: Threads Local Storage

Starting with Tru64 UNIXVersion 4.0D, Thread Local Storage (TLS) support has been added to the DEC C compiler.


Thread Local Storage is a name for data that has static extent (that is, not on the stack) for the lifetime of a thread in a multithreaded process, and whose allocation is specific to each thread. In standard multithreaded programs, static extent data is shared among all threads of a given process, whereas Thread Local Storage is allocated on a per-thread basis such that each thread has its own copy of the data that can be modified by that thread without affecting the value seen by the other threads in the process. For a complete discussion of threads, see the Guide to DECthreads and the Programmer's Guide.


The essential functionality of Thread Local Storage is and has been provided by explicit application program interfaces (APIs) such as POSIX (DECThreads) pthread_key_create(), pthread_setspecific(), pthread_getspecific(), and pthread_key_delete().

Although these APIs are portable to POSIX-conforming platforms, using them can be cumbersome and error-prone. Significant engineering work is typically required to take existing single-threaded code and make it thread-safe by replacing all of the appropriate static and external variable declarations and their uses by calls to these thread-local APIs. Furthermore, for Win32 platforms there is a somewhat different set of APIs: TlsAlloc(), TlsGetValue(), TlsSetValue(), and TlsFree(), which have the same kinds of usability problems as the POSIX APIs.

By contrast, the Thread Local Storage language feature is much simpler to use than any of the APIs, and it is especially convenient to use when converting single-threaded code to be multithreaded. This is because the change to make a static or external variable have a thread-specific value involves only adding a storage-class qualifier to its declaration. The compiler, linker, program loader, and debugger effectively implement the complexity of the API calls automatically for variables declared with this qualifier. Unlike coding to the APIs, you do not need to find and modify all uses of the variables, or to add explicit allocation and deallocation code. While the language feature is not generally portable under any formal programming standard, it is portable between Tru64 UNIX and Win32 platforms.

The __thread Attribute

The C and C++ compilers for Tru64 UNIX include the extended storage-class attribute, __thread.

You must use the __thread attribute with the __declspec keyword to declare a thread variable. For example, the following code declares an integer thread local variable and initializes it with a value:

__declspec( __thread ) int tls_i = 1;

Guidelines and Restrictions

You must observe the following guidelines and restrictions when declaring thread local objects and variables:

Window System Notes

Tooltalk Security

To prevent unauthorized access to your machine, a new security mechanism has been added to Tooltalk. This security mechanism, which was jointly developed by all companies shipping CDE, requires that a Tooltalk message contain a valid cookie in order for the ttsession message server to deliver the message to its recipients. A different cookie is generated by ttsession every time a user logs in using dtlogin.

The cookie resides in a new file called .TTauthority under your home directory. This permits you to send Tooltalk messages to the local ttsession message server. Any other user that wants to send a Tooltalk message to ttsession must place a copy of the cookie in their .TTauthority file. See the ttauth(1) reference page for instructions on how to share a cookie with other users.

For the special case of a root user sending messages to the local ttsession, Tooltalk looks for the cookie in the .TTauthority file of the user that owns the ttsession process. For messages being sent to a ttsession on a remote machine, Tooltalk looks for the cookie in root's .TTauthority file.

You can use the TTAUTHORITY environment variable to specify an alternate authority file.

Requiring all Tooltalk messages to contain a valid cookie might cause problems with some Tooltalk clients. Therefore, Compaq has added the ability to start ttsession with either relaxed security, full security, or no security.

Relaxed security is the default and requires a valid cookie only for the Tooltalk messages used to start an application on a remote machine. These messages contain a handler ptype, or have an operation name that maps to a ptype in the ptype database. Other message types are always delivered. Relaxed security is ideal for situations where notification messages are constantly being sent between Tooltalk clients.

To request full security, which requires that all messages contain a valid cookie, start the ttsession with the -F flag. You must use the -F flag in conjunction with the -a cookie flag (set by default).

To request no security, start the ttsession with the -a none flag. With no security, all messages are delivered without verification. This is not recommended, because it leaves your machine vulnerable to attack.

Documentation Notes

August 5, 1999: CD--ROM May Not Work with Netscape Communicator

When the Tru64 UNIX Documentation CD--ROM is used on a PC for which Internet Explorer is the default browser, the CD--ROM search capability works as documented in the instructions window. This window automatically pops up when you click on the Search button that is available from the main page of the documentation library.

The instructions tell you to open Windows Explorer, double click on the icon for the CD--ROM drive, and then double click on search.exe, which automatically loads the search query entry form into the Internet Explorer window. When the documentation CD--ROM is used on a PC for which Netscape Communicator is the default browser, these instructions might work, but sometimes do not. Problems observed when trying to use AltaVista CD-ROM Search with Netscape Communicator (Version 4.5 or higher) include the following:

If you encounter one or more of these problems, use the following procedure to work around them:

  1. After launching the AltaVista Search Dispatcher (search.exe), invoke Netscape manually if it is not already running.

  2. Use the File Open option in the Netscape window to find and open the InitPage.html file on the CD--ROM drive. Alternatively, you can type the URL to this file in the Netscape browser's Location: field.

  3. If your first search query takes more than 30 seconds to execute, click on the Stop icon and re-enter the query.

August 18, 2000: Consolidated Firmware CD Disk Partition Information

The Guide to Preparing Product Kits, Appendix A, Creating a Consolidated Firmware CD-ROM, Section A.1.1, Prepare for the Build Session, contains incorrect information for the disk partition size. Step 2 incorrectly states the following:

Use the disklabel utility to set up a 635 Mb partition on a spare disk, starting at block 0, with a size of 1300480 512-byte blocks and a file system type of unused.

The correct values are a 750 Mb partition with a size of 1536000 512-byte blocks.

Additionally, the following caution should be added to Section A.1.1, step 2:

Although you are creating a 750 Mb partition, remember that the CD-ROM is limited to 650 Mb and that you should only copy the specific versions of the firmware that you require.

Change the sample disklabel command in Section A.1.2, Build the Consolidated Firmware CD-ROM, step 5, and Section A.2.2, Building the Consolidated Firmware CD-ROM, step 6, to the following:

% disklabel -r -w -t cdfs -f \
      /spare/cons_oper_sys.cdfs \
      /mdec/xxboot.cdfs /cdimage/mdec/bootxx.cdfs

August 28, 2001:    Product Codes for Layered Product Kits

The Guide to Preparing Product Kits states that you must obtain a unique three-character product code for your layered product from Compaq. Some versions of the manual tell you to contact your Compaq representative and some versions state that you must send E-mail to the following address:

This address has been updated. To obtain a unique three-character product code, send E-mail to the following new address:

November 2, 2000: Incorrect Figure in Guide to Preparing Product Kits

Figure 2-3 is incorrect in the Guide to Preparing Product Kits for Version 4.0F and 4.0G. The left-hand branch below dcb_tools, going downwards, starts with src-src-opt-OAT100:

Guide to Preparing Product Kits: Incorrect Figure 2-3

The correct branch starts with src-usr-opt-OAT100:

Guide to Preparing Product Kits: Correct Figure 2-3

November 3, 2000: Release Notes Correction

Section 3.4.1 of the Release Notes states that Version 5.4 is the minimum firmware version required for Tru64 UNIX Version 4.0F on AlphaServer 8200, 8400, GS60, and GS140 systems. This information is outdated. A firmware update ships with each version of the Operating System. Compaq recommends that you update your firmware when you update your Operating System software.

December 6, 2000: Logical Storage Manager Guide Correction

Section 6.3.7 of the Logical Storage Manager Guide for Version 4.0D-4.0G states, in step 1, to enter voldisk rm after deporting a disk group to move it to another system. Do not do this command; this is an error. Simply deport the disk group and continue with step 2.

February 13, 2001 Additions to System Administration Documentation

Changes have been made to the binlogd and syslogd daemons, as follows:

April 17, 2001 Error in binlogd.8 Reference Page

The binlogd(8) reference page refers to the Event Manager (EVM). This feature is not available in Tru64 UNIX Version 4.0F and 4.0G.

April 17, 2001 Update to syslogd.8 Reference Page

The following options are added to the syslogd(8):


Specifies the size in Kbytes of the socket receive buffer. The default and maximum is 128 Kb. If you attempt to specify a larger size buffer it is automatically reduced to 128 Kb. Setting the buffer to a small value could result in messages being lost during periods of high logging activity.


Specifies the pathname of the UNIX domain socket to be used in making connections to the syslogd daemon. The default is /dev/log. You should not change this default in normal operation because the client functions syslog and openlog. See syslogd(8) openlog(3)reference pages.

August, 28, 2001: Reference Page Correction

xntpd(8) documents an -m option. This option is not supported in this release of the operating system.

Associated Product Notes

June 10, 1999: NetRAIN and Gigabit Ethernet Adapter

Redundant Array of Independent Network adapters (NetRAIN) is supported for the Gigabit Ethernet adapter (DEGPA-SA). See the Network Administration manual for additional NetRAIN guidelines.

Comments and Questions

We value your comments and questions on the information in this document. Please mail your comments to us at this address:

Legal Notice