Frequently Asked Question - Pro/Engineer on Compaq Tru64 Unix workstations (formerly Digital Unix workstations)

Home

Frequently Asked Questions

Pro/Engineer on Compaq Tru64 Unix workstations

(formerly Digital Unix workstations)

Topics:

Operating System / Patches

* What operating system version is required for Pro/ENGINEER?

The operating system version required for Pro/ENGINEER is specified in the Hardware Configuration Notes for Pro/ENGINEER section.

Release 20 requires Unix 4.0A and Open3D 4.3 or later. Releases 2000i and 2000i2 require Unix 4.0D and Open3D 4.8 or later. Further, Compaq only certifies that Unix 4.0D and later are Y2K compliant. There are and will not be any patch kits to bring earlier versions into Y2K compliance.

* What operating system patches are required for Pro/ENGINEER?

The operating system patches required for Pro/ENGINEER are specified in the Hardware Configuration Notes for Pro/ENGINEER section.

* How are operating system patches obtained from Compaq Computer Corporation?

The latest "public" patch kits are available from the World Wide Web at http://www.service.digital.com.
Those customers with active Compaq Support contracts can contact Compaq Services to report problems
and obtain patches for specific issues they may be experiencing.

* What are the operating system commands to determine system information?

Compaq Tru64 Unix

Operating
System
Command           Usage
----------------- -------------------------------------------------------
Disk Space        df -k (output is in kb), check under "Avail" column.
                  Use df -k . for current directory disk space
Graphics hardware sizer -gt, refer to DEC Graphics Adapter Model table below
Limit (current)   limit
Limit (hard)      limit -h
Machine type      uname -m
OS patches        uname -a
OS version        awk '{print $0; exit}' /etc/motd
                  OR sizer -v
                  OR uname -a. A 386 after 4.0 indicates 4.0; a 464 after 4.0 indicates
                  4.0A; a 564 after 4.0 indicates 4.0B; a 878 after 4.0 indicates 
                  4.0D
RAM               /usr/sbin/uerf -R -r 300 | grep physical as root
Swap space        swapon -s,  under "Total swap allocation:" check 
                  "Allocated space:" and  "Available space:"
Window manager    with a user logged into the system, enter ps -ae | grep 
                  wm, mwm indicates the motif window manager; dtwm 
                  indicates the CDE window manager
Open3D installed? xdpyinfo | grep GLX on the local machine should display 
                  DEC-GLX and GLX
Open3D Version    setld -i | grep O3DDWSBASE | grep installed

You can also see a lot of this information using the "dxsysinfo" GUI tool that tells about
the configured hardware.


DEC Graphics Adapter Model table

Graphics Adapter Model          Graphics code (from sizer -gt)
------------------------------- -------------------------------------------
ZLX-M1 (PV-LO)                  PMAGC-AA
ZLX-M2 (PV-MID)                 PMAGC-BA
ZLX-E1 (SFB+8)                  PMAGD-AA
ZLX-E2 (SFB+24 W/O ZBUFFER)     PMAGD-BA
ZLX-E3                          PMAGD-CA
ZLXP-E1                         PBXGA-AA
ZLXP-E3 (TGA-24 W ZBUFFER)      PBXGA-CA
ZLX-L2 (PVLite-MID)             PMAGC-EA
ZLXp-L1                         ZLXp-L1
ZLXp-L2                         ZLXp-L2
HX8                             PMAGB-BA
PowerStorm3D30 or 4D20          ZLXp2
PowerStorm4D40T                 p00e21091
PowerStorm4D50T                 p00e41091
PowerStorm4D60T                 p00e31091

* How can the cpu_id of a system be determined?

The preferred method of determining the cpu_id of a system is through use of the ptcsetup function on the PTC software CD.

For UNIX operating systems use the following command as root if the CD is not available:

uerf | grep _hardware

For Windows NT operating systems use the following command if the CD is not available:

net config workstation; the number within the parentheses is the cpu_id.

Graphics Configuration

* What are the requirements for use of OpenGL graphics in Pro/ENGINEER?

Pro/Engineer requires that the Open3D layered product be installed on the workstation and a license key
be active in order to get hardware graphics acceleration through OpenGL. If everything is set up
correctly, no changes to "config.pro" are necessary to active OpenGL acceleration. That is the default if
Pro/Engineer detects the OpenGL extension is present in the X Windows server.

* What other special graphics requirements are there?

Beginning with Pro/E Version 20, Pro/E works best on systems with graphics cards that support overlay
planes. Most Compaq graphics accelerators supported on Tru64 Unix have at least 4 overlay planes (the
minimum Pro/E needs). However, in order for Pro/E to be able to use them, some special configuration
needs to be done. This configuration is documented in the Installation and Administration Guide in the
chapter on System Administration in the COMPAQ section of that chapter (note - this is where the
documentation is for V20 adjust as necessary for 2000i and 2000i2).

If you don't configure the window manager as documented, you will notice excessive "repaint" operations
of the graphics windows of Pro/E.

How can the operation of OpenGL graphics be verified?

OpenGL graphics operation can be verified by executing the OpenGL demo files located in /usr/examples/GL.

* What enhanced graphics capabilities are enabled with OpenGL graphics in Pro/ENGINEER?

Enhanced graphics capabilities enabled with hardware graphics vary with the config.pro "graphics" option value, hardware platform and graphics hardware and are specified in the Performance Graphics Hardware section.

* What causes the Pro/ENGINEER system colors to be displayed improperly?

Pro/ENGINEER system colors may be displayed improperly or windows may flash as the cursor is moved due to an exhausted color map. Closing other graphical applications may resolve this issue. Platforms with 24 (or more) bit hardware graphics adapters allow a wider variety of user defined colors than that provided by 8 bit or x_windows graphics adapters.

* What motif window manager (mwm) constraints are recommended with Pro/ENGINEER?

The motif window manager (mwm) constraints recommended with Pro/ENGINEER include:

Mwm*ProEngineer*clientDecoration:        +title +menu +border
Mwm*ProEngineer*focusAutoRaise:         false
Mwm*ProEngineer*keyboardFocusPolicy:pointer
Mwm*ProEngineer*resizeBorderWidth:    4
For the CDE Window manager, the analogous resources would be:

Dtwm*ProEngineer*clientDecoration:        +title +menu +border
Dtwm*ProEngineer*focusAutoRaise:          false
Dtwm*ProEngineer*keyboardFocusPolicy: pointer
Dtwm*ProEngineer*resizeBorderWidth:     4

These constraints can be automatically appended to the /usr/lib/X11/app-defaults /Mwm file for new full installations when installed as root. The constraints are located in the file /usr/lib/X11/app-defaults/ProE after installation. To add the constraints on a per user basis, append /usr/lib/X11/app-defaults/ProE to the .Xdefaults file in the user's home directory. Similar constraints may be added for other window managers.

* How can overlapped windows be avoided in Pro/ENGINEER?

Overlapped windows can be avoided in Pro/ENGINEER by using config.pro options. The config.pro option "windows_scale" "value" ("0.5"-"1.0", default is "1.0") scales Pro/ENGINEER windows with a given coefficient, a typical value is ".85". The config.pro option "menu_horizontal_hint" "value" ("right" "left", default is "left") will display the second column of menus to the specified side of the main menu. A value of "right" is recommended when using the option "windows_scale". The config.pro option "thermo_position_hint" "value" ("window_overlap" "no_window_overlap"; default is "window_overlap") will position the thermometer scales. A value of "no_window_overlap" is recommended when using the option "windows_scale".

* Should backing store be enabled? How can the backing store state be checked?

Backing store is disabled by default and should not be enabled.

Use the following command to check the backing store state; it should be set to NO (disabled):

xdpyinfo | grep options

System / Configuration Considerations

* What type of swap space is preferred?

Tru64 Unix only supports swap space on raw disk partitions. Swap "files" are not supported.

* What is the advantage of accessing Pro/ENGINEER and user files via local file systems over NFS mounted file systems?

Access times are reduced for Pro/ENGINEER and user files accessed via local file systems compared to NFS mounted file systems.

* What is the advantage of writing trail files to local file systems over NFS mounted directories?

To improve performance trail files should not be written to NFS mounted directories. The config.pro option "trail_dir" with a local file system locationvalue should be used to save the trail file locally.

* What do the messages: "Out of virtual memory" or "Memory error" indicate?

The messages "Out of virtual memory" and "Memory error" indicate that either available virtual memory
has been exhausted, or the Pro/Engineer process has run into a kernel imposed limit on preprocess memory usage.

Before entering Pro/Engineer, the user should type execute the commands "unlimit stacksize; unlimit
datasize" (in the C Shell; use the "ulimit" command in either the Bourne or Korn shells). This will allow
the users Pro/Engineer process to use up to 32MB of memory for stack space and up to 1 GB for data
space. To use more memory than these kernel imposed hard limits, the Tru64 Unix kernel must be
reconfigured.

Process size (using the "ps" command) and Swap space usage (using the "swapon -s" command) should be
monitored as Pro/ENGINEER is executed if this message is displayed. Either increasing the kernel
imposed process limits and/or increasing the amount of virtual memory available (swap space ) should cure these
messages.

* What accessory input devices are supported?

Spacetec IMC Corporation's Spaceball Models 2003 and 3003, Logitech Incorporated's Magellan 3D Controller and dial boxes available from specific hardware vendors are supported accessory input devices as specified in the Supported Accessories section. After installation and configuration of the PTC supported accessory per the hardware vendor's instructions, no additional configuration is required for use of the accessory from within Pro/ENGINEER.

*How do I configure my 64 bit Tru64 Unix system to allow addressing of very large memory (VLM) for
large assemblies?

Configuring and Tuning Process Memory on Compaq Tru64 Unix

       1.Default Limits and Kernel imposed "hard" limits
       2.Increasing kernel imposed limits
       3.Swap space and it's relation to virtual memory

Default Limits and Kernel imposed "hard" limits

The Compaq Tru64 Unix kernel imposes certain defaults that effect how much virtual memory any given
process can use during it's lifetime.
The defaults are:

     default per process stack size = 2 MB
     maximum per process stack size = 32 MB
     default per process data size = 128MB
     maximum per process data size = 1 GB
     default (and maximum) per process address space = 1 GB
     maximum virtual address space per user process = 1 GB

These limits can be increased two ways.

The first limit to increase is the "default" limits of 128 MB for datasize and 2 MB for stacksize.
Users can increase these limits up to the kernel imposed "hard limits" via the C-Shell "unlimit"
command or via the "ulimit" command in the Bourne or Korn shells. For instance, to increase the
limits for stack segment size and data segment size up to the kernel "hard limits", the following
commands could be entered in the C-Shell:

% unlimit stacksize
% unlimit datasize

From that point forward, the shell in which those commands were issued and any child processes
invoked by that shell process may use up to 32 MB of stack space and 1 GB of data space.

Increasing Kernel imposed limits

For some applications that work on large data sets (databases, technical and scientific
applications, etc), it may be desirable to increase the kernel imposed limits to process larger
amounts of data and/or solve bigger problems. This is done by modifying the default values for
various kernel subsystems.

The Tru64 Unix kernel reads most of it's configurable parameters from the kernel configuration
database, /etc/sysconfigtab, when the system is booted. Most modifications to kernel parameters
are made in this database using the "sysconfigdb" utility. Values to change are mostly in the
"proc" kernel susbsystem with the exception of one parameter that is in the "vm" kernel
subsystem. The tunable parameters in the "proc" subsystem that effect a processes memory usage
are:

    per-proc-stack-size
    max-per-proc-stack-size
    per-proc-data-size
    max-per-proc-data-size
    per-proc-address-space
    max-per-proc-address-space

The tunable "vm" subsystem parameter is
vm-maxvas

A general recommendation is to only increase the "max" hard limit values and leave the default
"user" values as is. That way users and processes that need to increase their limits can do so with
an "unlimit" command. Other processes will continue with the default limits and will not be able
to "hog" virtual memory from the processes that need it. In some cases, it may be desirable to
modify the defaults and the hard limits to the same value.

To modify the kernel limits, use the "sysconfigdb" utility. First check the limits for each
subsystem using the "sysconfigdb -l" command:
# /sbin/sysconfigdb -l proc

# /sbin/sysconfigdb -l vm

Note: you will need to be logged in as "root" to modify the kernel parameter database. You do
not need to have root privileges to check
the values in the running kernel though.

If there have been values previously set or changed in the sysconfigtab file, you will see output
similar to

vm:
    ubc-borrowpercent = 20
    vm-heappercent = 30
    vm-mapentries = 1000000

If any of the limits that need to be changed are listed in the output, you don't need to change
them if they are greater than what you were going to increase them to. If there are no existing
entries in the file, you may see a message like:
proc: no entries found in /etc/sysconfigtab
This is just a message telling you that no changes have been made to that kernel subsystem and
the kernel is running with it's default values.

As an example, let us increase the kernel imposed limits to KGB per process. Use your favorite text
editor to create a file that looks like the following:

proc:
max-per-proc-data-size=8589934592 (KGB in bytes)
max-per-proc-address-space=8589934592

vm:
vm-maxvas=8589934592

Save it in a filename of your choice. Here, we have not increased the default limits for stack size.
Most applications will work correctly with the default 32 MB kernel hard limit. If your
application gives you error messages saying "Can't Grow Stack", then you will need to increase
the stack limits as well. In practice, all 3 of the kernel parameters changed in the above example
are usually always set to the same value.

Once you've made the desired changes, update the /etc/sysconfigtab database with the following
command:
# /sbin/sysconfigdb -m -f <your file>

The "-m" argument tells sysconfigdb to merge the entries from your file with any existing entries
already in the configuration database.

The "proc" and "vm" kernel subsystems are static, meaning that any changes you make to them
will not take effect until the system is rebooted. Now reboot your system. Log in and open a
terminal window. If it is a C-Shell window, type "unlimit stacksize; unlimit datasize; unlimit
addressspace" followed by "limit" to see if the changes took effect. Use the "ulimit" command for
a Bourne Shell or Korn Shell. You should now see the 8 GB of data and address space listed as the
process limits.

The alternate method of reconfiguring the kernel is to use the Kernel Tuning gui tool (command
"dxkerneltuner"). The GUI tool will correctly edit the "sysconfigtab" file for you minimizing the
risk of corruption. In the GUI, dynamic kernel parameters can be changed "on the fly". For
static parameters, it will tell you that reboot is necessary. In retrospect, using the
"dxkerneltuner" gui tool should be the preferred method for reconfiguring the Tru64 Unix kernel
instead of the hand editing procedures explained above.

Swap Space Considerations

None of these changes will do any good unless the system has the virtual memory to back it up.
Virtual Memory consists of physical memory and paging space (swap space) on disk. If you know
you will be consistently working with very large data sets, you should install as much physical
memory as possible and/or you can afford to give the maximum performance possible.

The rule of thumb for Tru64 Unix is that you should configure 2 times the amount of swap space
as you have physical RAM. So, if you have 512 MB of RAM, configure KGB of swap when
installing Tru64 Unix. Tru64 Unix only supports device (partition) swapping, so a little up front
planning of disk allocation is necessary before installing the Operating System. Additional swap
can be added later by configuring swap on unused disk partitions or adding additional disks as
necessary.

The "2x" rule is just a guideline. You can configure as much swap space as you like (ok, there is a
limit. It's in the 8 Terabyte range!). However, you should configure at least as much swap space
as you have RAM. If you configure less swap than you have RAM, the OS will never fully utilize
the physical RAM before beginning to page to the swap areas.

Tru64 Unix has two swap modes; the default is called "eager" mode and the alternate is called
"overcommit" or "lazy" swap mode. In eager swap mode, the operating system reserves swap
space for a process whenever it makes a request for memory. That way if it ever needs to be
swapped out, it has somewhere to store it's pages in the swap area(s). In "lazy" swap mode, swap
space is used by a process only when it needs to be paged to disk.

What are the advantages and disadvantages?
In "eager" swap mode, a process always has a place to go if it needs to be paged out. In "lazy"
mode, if a process needs to be paged out and there is no place in the swap area to go, the OS will
start killing off other idle processes to make room for the active process to go to the swap
partition(s). This can be dangerous and it is for this reason that it is generally not recommended
to run in "lazy" swap mode. This is especially true for multi-user servers where users' processes
could be killed off seemingly at random. However, for single user workstations, this can be more
of an acceptable risk. If you are getting a lot of "Swap space below 10% free" messages in the
console window and do not have any additional free disk space to add more swap, switching to
"lazy" mode can usually alleviate these messages. This is because in "eager" swap mode, the
virtual memory of the system is essentially equal to the amount of swap space configured (every
process reserves it's space). In "lazy" swap mode, virtual memory = physical RAM + swap space
(swap isn't used until it's needed). "Lazy" swap mode also seems to have a slight performance
advantage because the OS doesn't have to reserve swap space for a process whenever it asks for
more memory.

The default swap mode is the "eager" swap mode. To switch to "lazy" swap mode, as root rename
the file "/bin/swapdefault" to "/sbin/swapdefault.sav". Then reboot the system. To switch back,
rename the file back to it's original name and reboot again.

Operating System Decertifications

Releases 2000i and 2000i2 are only supported on Tru64 Unix (formerly Digital Unix) 4.0D and later. Furthermore,
only Unix 4.0D and later are certified Y2K compliant by Compaq.

* Digital UNIX V3.2, V3.2b, V3.2C

August 26, 1996

Dear PTC/Digital Customer:

The purpose of this letter is to provide advance notification of Digital UNIX v3.2, V3.2b, & v3.2c decertification. Our mutual objective is to improve performance, quality and customer support of the Pro/ENGINEER product family by moving to a more current PTC-supported OS version. Release 17.0 will be the final supported release on Digital UNIX v3.2, v3.2b & v3.2c. Therefore, please plan to complete your migration to Digital UNIX v3.2d (or to a higher PTC-supported operating system) prior to upgrading to Release 18.0. Release 18.0 is targeted to begin shipping to customers in December, 1996.

Please contact your local Digital representative or Authorized Digital Reseller for assistance in migrating your current operating system to Digital UNIX v3.2d or higher. Thank you.

Sincerely,

Glenn R. Sinclair
Hardware Partner Manager
Parametric Technology Corporation
617-398-5285

Vic Sakalys
Business Relationship Manager
Digital Equipment Corporation
508-467-7767

* Digital UNIX V3.2d

January 15, 1997

Dear PTC/Digital Customer:

The purpose of this letter is to provide advance notification of hardware requirements for running Release 19.0 of the Pro/ENGINEER Product family. Release 18.0 will be the final supported release of PTC software on Digital UNIX v3.2d operating system. Therefore, please plan to complete your migration to Digital UNIX v4.0 (or to a higher PTC-supported operating system) prior to upgrading to Release 19.0. Release 19.0 is targeted for shipment to customers in the third quarter of calendar 1997.

Digital UNIX v4.0 runs on all PTC-supported Digital workstations, so there should be no hardware issues resulting from this migration to Digital UNIX v4.0. For up-to-date hardware configuration requirements, please refer to the hardware partner section of PTC's web site:

http://www.ptc.com/partners/hardware/index.htm.

Our mutual objective is to improve performance, quality and customer support of the Pro/ENGINEER product family by moving to a more current PTC-supported OS version. Please contact your local Digital representative or Authorized Digital Reseller for assistance in migrating your current operating system to Digital UNIX v4.0 or higher. Thank you.

Sincerely,

Glenn R. Sinclair                                      Victor R. Sakalys
Hardware Partner Manager                  Strategic Relationship Manager
Parametric Technology Corporation Digital Equipment Corporation
617-398-5285                                        508-467-7767
sinclair@ptc.com                                   victor.sakalys@mro.mts.dec.com