Tru64™ UNIX® FAQ

Contents

1.0 General software release information

1. What software is available for Tru64™ UNIX® for the Java™ Platform?

2.0 Downloading and installing the SDK & documentation

1. Are any operating system patches required to run the SDK?
2. How do I tell which Tru64 UNIX version I have?
3. I've downloaded the SDK. Are there installation notes available to me?
4. Would you explain the version naming convention used for your SDK kits?
5. Where can I find the documentation for the SDK?

3.0 Using the SDK & error messages

1. Why must my JNI native code be compiled and linked with the -pthread option?
2. How do I go about unpacking the example files from the SDK?
3. Is there any tuning required to run the Volano benchmark?
4. What window managers does the SDK support?
5. How do I get the best performance using your Fast VM when my application runs slower and uses more memory, than the SDK Java command?
6. How do I submit a problem report form that involves a Core Dump?
7. What should I do if my Java application terminates abnormally with a "could not allocate code space" message?
8. Java applications that were previously running well are now failing with a
   Seg Fault. A patch kit was installed. Is this causing a problem for the SDK?
9. We are experiencing connection timeouts and hangs with the use of the MulticastSocket class. Why is this happening?

4.0 Third party applications, Java tools & other utilities

1. Will Sun's JavaBeans™ Development Kit run on the Tru64 UNIX implementation of the SDK and if so, how do I install it?
2. Will Sun's Java Web Server run on the Tru64 UNIX implementation of the SDK, and if so, how do I install it?
3. Does HP provide the Java Foundation Classes (JFC)?
4. Do you have a Java Servlet Development Kit for Tru64 UNIX?
5. Where can I find information on HP's Visual Threads capabilities?
6. How do I run my Java Servlets and Java Server Pages on Tru64 UNIX?
7. Where can I find JDBC drivers if my application requires database access?
8. Why is SysMan Station complaining that the SysMan Station Authentication daemon is not running on Tru64 UNIX V5.1B?

1.0 General software release information

Q1.1: What software is available for Tru64™ UNIX® for the Java™ Platform?

A: HP offers the SDK and other software for Tru64 UNIX for the Java™ Platform. For a full listing of software products for Tru64 UNIX, see our software download page.

2.0 Downloading and installing the SDK & documentation

Q2.1: Are any operating system patches required to run the SDK?

A: No. The SDK is available for Tru64 UNIX V5.1B and higher, and patches are not required to run SDK. However, you may still want to install the latest operating system patch kit to get recent bug fixes for these versions of our UNIX. For more information, refer to the release product page.

Q2.2: How do I tell which Tru64 UNIX version I have?

A: The command 'sizer -v' reports the version of your Tru64 UNIX installation.

Q2.3: I've downloaded the SDK. Are there any installation notes available to me?

A: Yes. There are some important installation notes available on-line, including 'how to' information for determining your 'java environment version'. For more information, refer to the 'installation notes' page for the particular SDK for Tru64 UNIX you are running. Also, detailed information can be found in the Release Notes. To view the Release Notes, see our software documentation page.

Q2.4: Would you explain the version-naming convention used for your SDK kits? An example is that when typing the command, java -version, SDK v 1.4.2-7 displays as follows:

java version "1.4.2-7"

A: The number following the hyphen indicates an Update release - in this case number "7". It does NOT indicate that this is a beta release. Beta releases are indicated by including the word "beta" as part of the version name; for example, "1.4.7-beta". This version naming convention (hyphen#) is necessary because we have had to re-release kits to fix Sun's or other problems. This numbering scheme makes it much easier to determine exactly which kit you are using.

Also note that an 'Update' release contains the full SDK release based on Sun's Java 2 SDK along with the latest features and bug fixes.

Q2.5: Where can I find the documentation for the SDK?

A: If you installed the OSFJAVADOCxxx subset, there is a set of HTML pages beginning at /usr/share/doclib/java/index.html. These pages have been revised to reflect the kit that ships with Tru64 UNIX.

The source files for the class libraries, also part of the documentation subset, can be found at /usr/examples/java/src.zip for SDK 1.1.n or at /usr/opt/java11n/src.jar for SDK 1.2.2 and higher.

Documentation is also on-line and available from the software documentation page.

3.0 Using the SDK & error messages

Q3.1: Why must my JNI native code be compiled and linked with the -pthread option?

A: All C/C++ code that uses POSIX threads must be compiled and linked using the C/C++ -pthread option. Otherwise, the resulting program will not execute properly. The Virtual Machine uses POSIX threads. Hence, any JNI native code that uses the JVM uses POSIX threads by default, and so must be compiled and linked using the -pthread option. For more information about the -pthread option, please see the C/C++ man pages.

Q3.2: How do I go about unpacking the example files from the SDK?

A: The jar utility, which is part of the SDK and is the standard "zip" utility, will give you full access to the examples src.zip or src.jar.

Q3.3: Is there any tuning required to run the Volano benchmark?

A: The Volano benchmark simulates a chat server and tests the ability of a machine to be a chat server. This test often results in significant amounts of idle time on the processor under test. Therefore, to obtain the best results, the system under test should be tuned to be a Web server. Greater performance can be achieved by lowering the idle time and increasing overall network performance. Even with this tuning, we have seen noticeable processor idle time. The following describes the procedure we recommend to tune your system.

To see the best VolanoMark™ results on HP’s Tru64 UNIX, you should tune your system as a web server, per the instructions in the manual Tru64 UNIX System Configuration and Tuning, Section A.1. Additionally, you should set the inet parameter tcpnodelack to 1. You can do this temporarily on a running system with the command (requires root privileges):

# /sbin/sysconfig -r inet tcpnodelack=1

You can make this setting permanent by using the sysconfigdb utility.

After making these changes, you may notice an improvement in the Volano benchmark results.

Q3.4: What window managers does the SDK support?

A: The CDE desktop window manager (dtwm), and the Motif window manager (mwm), are fully supported. You may also use the DIGITAL eXcursion™ window manager when running your Java application on a Tru64 UNIX system and redirecting the display back to a PC.

Non-standard and unsupported window managers include fvwm and twm. Therefore, you may experience some unusual behavior using them.

Q3.5: How do I get the best performance using your Fast VM when my application runs slower and uses more memory, than the SDK Java command?

A: The Fast VM has been tuned for large memory systems, and you may need to tune the Fast VM using the -Xmx option to get the best performance. The default heap size for the Fast VM is much larger than the SDK Java command, and in addition, the Fast VM grows more rapidly to the default value. The Fast VM performs much better than the SDK Java command though the best -Xmx value depends on your application and characteristics of your system. For information on tuning the Fast VM for smaller memory systems, refer to the documentation.

Q3.6: How do I submit a problem report form that involves a Core Dump?

A: In order to provide useful information to the Java technology on Alpha team at HP, core dumps must be analyzed at the customer site using the Ladebug debugger. There are often dependencies on libraries (such as Oracle libraries, etc.) installed at the customer site that the support team can not easily replicate. Without these libraries, the Ladebug debugger is prevented from extracting any information.

You will need to enter the following Ladebug commands that provide information about the stack trace, the active function's variables, and detailed information about the threads. When you have completed these steps, place the output in a file and submit it along with your problem report form. For instructions on how to submit a problem report form, see our software support page.

1. Make sure that you have a Ladebug version of 4.0-63 or higher. You can download Ladebug from http://h18000.www1.hp.com/products/software/ladebug/.
   
   
2. Locate the java_g executable for the version you are using.
   
   For SDK v 1.1.7: /usr/bin/alpha/native_threads/java_g
   For SDK v 1.1.8: /usr/opt/java118/bin/alpha/native_threads/java_g
   For SDK v 1.2.2: /usr/opt/java122/bin/alpha/native_threads/java_g
   For SDK v 1.3.0: /usr/opt/java130/bin/alpha/native_threads/java_g
   For SDK v 1.3.1: /usr/opt/java131/bin/alpha/native_threads/java_g
   For SDK v 1.4.0: /usr/opt/java140/bin/java_g
   For SDK v 1.4.1: /usr/opt/java141/bin/java_g
   
   
3. Run Ladebug with java_g and the core file. % ladebug /usr/opt/java131/bin/alpha/native_threads/java_g <corefile>
   
   
4. Use the record command for convenience in saving the results to a file.

   (Ladebug) record io core_results.txt

5. Examine the stack trace.
   
   (Ladebug) where
   
   
6. Dump the active function's local variables and parameters.
   
   (Ladebug) dump
   
   
7. Execute the following threads commands to display detailed information about the threads:
   
   

   (ladebug) pthread "system"	# system info
   (ladebug) pthread "versions"	# DECthreads version
   (ladebug) pthread "vp"	# Brief listing of VPs
   (ladebug) pthread "thread -1a"	# Brief listing of threads
   (ladebug) pthread "mutex -faql"	# Full listing of all locked mutexes
   (ladebug) pthread "cond -faqw"	# Full listing of all CV's with waiters
   (ladebug) pthread "rwlocks -faqr	# Full listing of all read-locks
   (ladebug) pthread "rwlocks -faqw	# Full listing of all write-locks
   (ladebug) pthread "show -tuvk"	# Timeslice, Upcall, VP (on old versions), and kernel information
   (ladebug) pthread "vp -f"	# Full info on all VPs
   (ladebug) pthread "thread -fa"	# Full info on all threads
   (ladebug) pthread "stacks -fs"	# Display each threads' stacks beginning and end points.
   (ladebug) pthread "mutex -faq"	# Full info on all mutexes
   (ladebug) pthread "cond -faq"	# Full info on all CV's
   (ladebug) pthread "rwlocks -faq	# Full listing of all write-locks
   (ladebug) pthread "vm -cf"	# DECthreads internal memory manager
   (ladebug) pthread "keys"	# List of per-thread context keys
   (ladebug) pthread "mutex -h"	# History for mutexes, if available (typically not)
   (ladebug) pthread "cond -h"	# History for condition variables, if available

Q3.7: What should I do if my Java application terminates abnormally with a "could not allocate code space" message?

A:   The following message is displayed if code space is exhausted:

Could not allocate code space. Please try the -Xcode option: No such file or directory, file .../srcjava/alpha/../../srcjava/sys/alpha/md.c, line 359

This message means that you have run out of code space memory.

The code space is the memory that the FastVM uses to store machine code when it compiles a Java method. The default size for the code space is 32 megabytes. You can specify a larger code space (up to 256 megabytes) using the Java -Xcode option. For example, -Xcode100m increases the code space to 100 megabytes.

You can also use the Java -Xdynclassgc option. This causes the FastVM to garbage collect code space memory and so prevent it from running out.

The two options can be used together.

Q3.8: Java applications that were previously running well are now failing with a
Seg Fault. A patch kit was installed. Is this causing a problem for the SDK?

A: Patch kit 2 for V5.1B and Patch kit 5 for V5.1A introduce a new security feature called “no execute heap/data”, similar in concept to the executable stack protection for Tru64 UNIX. When enabled, the feature prevents the execution of instructions that reside in heap or other data areas of process memory, providing additional protection against buffer overflow exploits.

The security feature is disabled by default so simply installing either of these patches will not cause a problem for Java applications. The system administrator would need to take additional actions as described in the release notes for the patch kit in order to enable the security feature. The status of the security feature can be examined by executing the following commands:

example:
     % su - root
     # sysconfig -q proc

result:
     executable_data = 0 means it is disabled
     executable_data = 5 applies to applications running as root

The Java programming language needs the ability to execute instructions that reside in heap and therefore will run into trouble unless the SDK kits are specially marked to exempt them from this restriction. If the new security feature is set properly, it will only apply to applications running as root and this is not the norm for most Java applications. Regardless of the limited exposure, it is still necessary to ensure that all SDK kits on your system are properly marked. All SDK kits on our Web site have been marked and will run without incident with the patch kit installed. SDK versions that were previously available, such as V1.3.1-2, have not been marked and will need to be marked by the script described here.

A special script was provided with the new security feature that included instructions that it should be run after the patch kit was installed. If this step was not completed, you must take the time to do so. The script is called javaexecutedata, and it will search in known locations on the system to mark any SDK kits installed. Once the SDK kits have been marked, they will run normally with the new security feature.

example:
     % su - root
     # /usr/sbin/javaexecutedata

It is likely that there are applications that provide our Run Time Environment (RTE) versions that have not been marked. These will fail for applications that run as root. The javaexecutedata script is set up to handle these cases and can be easily run to rectify the problem. The script will accept a starting directory from which it will search down the tree marking any SDK kits it encounters. Once you determine the directory in which the application resides, feed that directory to the javaexecutedata script and it will mark the SDK kit included with the application.

example:
     % su - root
     # /usr/sbin/javaexecutedata /usr/some_app

The failure from an unmarked SDK kit will take place within a few seconds of the application startup. If you see a Seg Fault as the application starts, the problem is likely due to the patch kit installed. Seg Faults are rare but when one occurs, it will normally take place after the application is up and running. Another clue that the problem is related to the installation of the patch kit is that the failure will look similar to one of the following:

1. When using the Fast VM on v 1.2.x and higher:
   
   **Memory region has incorrect protections, exiting**,
   file /sys/alpha/gcinit.c, line 309
   
   OR
   
   Seg Fault message with an endless stack trace
   
   
2. When using the Classic VM with any version:
   
   SIGSEGV 11* segmentation violation
   
   si_signo [11]: SIGSEGV 11* segmentation violation
   si_errno [0]: Successful
   si_code [2]: SEGV_ACCERR [addr: 0x1403ADA00]
   
   sc_pc: 0x0, r26: 0x1
   
   stackpointer fff9db8
   
   Full thread dump Classic VM (1.3.1-2, native threads):
   
   “ Finalizer” (TID:0xcb0800, sys_thread_t:0x1402f69f8, state:CW, native ID:0x20001e2f3c0) prio=8
   
   at java.lang.Object.wait(Native Method)
   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:108)
   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:123)
   at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:162)
   “ Reference Handler” (TID:0xcb08b0, sys_thread_t:0x1402f15f8, state:CW, native ID:0x200019273c0) prio
   
   at java.lang.Object.wait(Native Method)
   at java.lang.Object.wait(Object.java:420)
   at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110)
   “ Signal dispatcher” (TID:0xcb09c0, sys_thread_t:0x1402ea5f8, state:CW, native ID:0x20000f173c0) prio=5
   
   “ main” (TID:0xcb0600, sys_thread_t:0x1400093f8, state:R, native ID:0x3ffc01b6000) prio=5
   
   Monitor Cache Dump:
   
   java.lang.ref.Reference$Lock@CB08C0/CE9480: <unowned>
   
   Waiting to be notified:
   
   “ Reference Handler” (0x1402f15f8)
   
   java.lang.ref.ReferenceQueue$Lock@CB0820/CE9620: <unowned>
   
   Waiting to be notified:
   “ Finalizer” (0x1402f69f8)
   
   Registered Monitor Dump:
   
   utf8 hash table: <unowned>
   JNI pinning lock: <unowned>
   JNI global reference lock: <unowned>
   BinClass lock: <unowned>
   Class linking lock: <unowned>
   System class loader lock: <unowned>
   Code rewrite lock: <unowned>
   Heap lock: <unowned>
   Monitor cache lock: owner “main” (0x1400093f8) 1 entry
   Thread queue lock: owner “main” (0x1400093f8) 1 entry
   Monitor registry: owner “main” (0x1400093f8) 1 entry
   
   Abort (core dumped)
   
   
3. When using the Fast VM with 1.1.x versions:

   ** Unexpected SEGV **Addr?00D460 PC?00D460
   pc: 0x3f00d460
   java.lang.OutOfMemoryError
   pc: 0x3ef959a8
   Unknown Address
   pc: 0x3ef9588c
   Unknown Address
   pc: 0x3ef48d0c
   Unknown Address
   pc: 0x3ef49c38
   Unknown Address
   pc: 0x120009898
   Unknown Address
   pc: 0x120007eac
   Unknown Address

Q3.9: We are experiencing connection timeouts and hangs with the use of the MulticastSocket class. Why is this happening?

A: Some of the Tru64 UNIX OS patch kits have been known to cause failures for the MulticastSocket class. The failure is mostly a connection timeout but could also cause a hang.

Listed below are the Tru64 UNIX patch kits that cause the problem. If you have installed one of these patch kits, a portion of the offending patch kit can be removed without having to remove the entire patch kit. Also, patch kits that contain a fix to this problem are available.

Use 'dupatch' to list out the details of patch kits contained on your system, and to remove the offending patch-id (refer to the list above). Then retest your application.

4.0 Third party applications, Java tools & other utilities

Q4.1: Will Sun's JavaBeans™ Development Kit run on the Tru64 UNIX implementation of the SDK and if so, how do I install it?

A: Yes. Sun's JavaBeans Development Kit is 100% Java and will run on the Tru64 UNIX implementation of our SDK. BDK 1.1. requires Java 2 Standard Edition v 1.2 or later. If you are still running SDK v 1.1.x release, you can download BDK 1.0. To install BDK 1.1 on Tru64 UNIX, follow the instructions below.

• Download the BDK file by following the instructions on Sun's BDK Download Web page. Use the "Select a Platform" dropdown list to select "Any". Click to "Continue".
• Click on "Accept" to accept the License Agreement.
• Click on "FTP download "bdk1_0-Jul98.zip".
• As a result of performing the above steps, you will have a file named "bdk1_1-solsparc.bin.
• To continue on, follow the instructions under "What's in the BDK".

Q4.2: Will Sun's Java Web Server run on the Tru64 UNIX implementation of the SDK?

A: On February 7th 2001, Sun announced the End Of Life (EOL) of Java Web Server, and the last date for purchasing Java Web Server was May 11, 2001. You might want to consider using Sun's iPlanet's web server products. The iPlanet web server runs on the Tru64 UNIX implementation of our SDK.

Q4.3: Does HP provide the Java Foundation Classes (JFC)?

A: Yes. JFC functionality is an integral part of SDK v 1.2.1 and higher. Therefore, HP provides the JFC with the SDK available on this Web site. JFC is not provided with our other earlier SDK offerings because it was a separate component prior to Java 2.

You can also download Sun's JFC, and it will run fine on the SDK v 1.2.1 for Tru64 UNIX.

Q4.4: Do you have a Java Servlet Development Kit for Tru64 UNIX?

A: Servlets are available for Tru64 UNIX. To obtain the API and some sample servlets, you can download Sun's Java Servlet Development Kit (JSDK), and run it using our SDK for Tru64 UNIX.

Q4.5: Where can I find information on HP’s Visual Threads capabilities?

A: Visual Threads is a UNIX diagnostic tool that lets you analyze and refine your multithreaded application for potential logic and performance problems. Visual Threads is targeted toward developers who are implementing or maintaining multithreaded applications on Tru64 UNIX and who are using a POSIX threads API (POSIX, DCE, or CMA API) or that is written in Java. Visual Threads can be used with any application, written in any language. For more information, visit 'HP's Visual Threads' Web site.

Q4.6: How do I run my Java Servlets and Java Server Pages on Tru64 UNIX?

A: A reference implementation of the Java Servlet and Java Server Pages technologies, called 'Tomcat', is available from the Apache Software Foundation. See http://Jakarta.apache.org.

Tomcat is available for Tru64 UNIX and is included with Open Source Internet Solutions. For more information on how to run Tomcat, visit HP's Tru64 UNIX Internet page.

Q4.7: Where can I find JDBC drivers if my application requires database access?

A: Drivers are available from MERANT via HP's data access page. Additional drivers are available from Oracle, Informix, and Weblogic.

Q4.8: Why is SysMan Station complaining that the SysMan Station Authentication daemon is not running on Tru64 UNIX?

A: The SysMan Station Authentication daemon normally starts automatically when the system boots but when SDK v 1.3.1-4 or 1.3.1-5 is installed it will fail to start at boot time. This is only a problem at boot time and can be remedied by starting the daemon manually when logged in as root. Perform the following command as root to start the daemon:

/sbin/init.d/smauth restart

You may also wish to install SDK v 1.3.1-6 if you will be using SysMan Station frequently. This problem has been fixed in SDK v 1.3.1-6; the daemon is started correctly at boot time.