Before using this information and the product it supports, read the information in Notices.
This edition of the user guide applies to the security components included with the IBM SDK for Java.
Note: Before using this information and the product it supports, read the general information under Notices.
This edition of the user guide applies to:
and to all subsequent releases and modifications until otherwise indicated in new editions.
© Copyright Sun Microsystems, Inc. 1997, 2007, 901 San Antonio Rd., Palo Alto, CA 94303 USA. All rights reserved.
The security components described in this user guide are shipped with the SDK and are not extensions. They provide a wide range of security services through standard Java APIs (except iKeyman). The security components contain the IBM® implementation of various security algorithms and mechanisms. IBM does not provide support for any of the IBM Java security components when used with a non-IBM JVM or with non-IBM security providers when used with the IBM JVM.
The IBM SDK also provides a FIPS 140-2 certified cryptographic module, IBMJCEFIPS, implemented as a JCE provider. Applications can comply with the FIPS 140-2 requirements by using the IBMJCEFIPS module.
The CertPath component provides PKIX-compliant certification path building and validation.
The JGSS component provides a generic API that can be plugged in by different security mechanisms. IBM JGSS uses Kerberos V5 as the default mechanism for authentication and secure communication.
The JAAS component provides a means for principal-based authentication and authorization.
The JCE framework has two providers: IBMJCE is the pre-registered default provider; IBMJCEFIPS is optional.
JSSE is the Java implementation of the SSL and TLS protocols. The JSSE pre-registered default provider is IBMJSSE2.
IBM Java Simple Authentication and Security Layer, or SASL, is an Internet standard (RFC 2222) that specifies a protocol for authentication and optional establishment of a security layer between client and server applications.
The Java security configuration file does not refer to the Sun provider. The IBM JCE provider has replaced the Sun provider. The JCE supplies all the signature handling message digest algorithms that were previously supplied by the Sun provider. It also supplies the IBM secure random number generator, IBMSecureRandom, which is a real Random Number Generator. SHA1PRNG is a Pseudo Random Number Generator and is supplied for code compatibility. SHA1PRNG is not guaranteed to produce the same output as the SUN SHA1PRNG.
In the IBM SDK v1.4.1, the following options were added to the java.security.debug property to help you debug Java Cryptography Architecture (JCA)-related problems:
An example of a valid option string is "provider, algorithm:stack".
In this guide, there is a 'What's new' section for each component. This information is provided to help you with migration.
Overview of the IBM security providers.
The IBM SDK v6 has been tested with the following default security providers:
You can also add other IBM security providers, such as the IBMJCEFIPS provider (com.ibm.crypto.fips.provider.IBMJCEFIPS), using one of these methods:
java.security.Security.addProvider()
The iKeyman utility is a tool for key databases containing digital certificates and keys.
With iKeyman, you can:
To load a Java cryptographic token on SLES10 using iKeyman, you must rename the cryptography library from /usr/lib/opencryptoki/libopencryptoki.so.0.0.0:0 to /usr/lib/opencryptoki/libopencryptoki.so. If /usr/lib/opencryptoki/libopencryptoki.so is already linked, you must delete it before the renaming.
PKCS#11 access provided by IBMPKCS11Impl Provider rather than IBMPKCS11 Provider and a native library.
Support for symmetric key management (only supported by JCEKS and PKCS#11 key databases).
Use of the Java CMS Provider for CMS key databases rather than a native library.
For more information, including information about the iKeyman GUI, see the iKeyman User Guide at: http://www.ibm.com/developerworks/java/jdk/security/index.html.
The Sun Microsystems Java platform provides a means to enforce access controls based on where code came from and who signed it. These access controls are needed because of the distributed nature of the Java platform where, for example, a remote applet can be downloaded over a public network and then run locally.
However, before SDK v1.4.0, the Java platform did not provide a way to enforce similar access controls based on who runs the code. To provide this type of access control, the Java security architecture requires the following:
The Java Authentication and Authorization Service (JAAS) framework provides these enhancements.
For a general overview of JAAS, see the Sun Web site: http://java.sun.com/products/jaas.
IBM implementations are contained in the com.ibm.* package instead of the com.sun.* package.
For detailed information, including API documentation and samples, see the developerWorks® Web site at http://www.ibm.com/developerworks/java/jdk/security/index.html. This site contains the LoginModule Developer's Guide and sample code in "HelloWorld.tar".
A history of the changes to the Java Authentication and Authorization Service (JAAS) since it was added to the SDK.
Added a new JAAS login module which enables users to perform authentication using credentials stored in an LDAP directory service. The new module provides LDAP support for existing JAAS-enabled applications.
New to the IBM 32-bit SDK for Linux on Intel architecture
The original release of JAAS for Linux and the Java Platform included the following login module and principal classes:
These original platform-dependent principal classes will be replaced by a set of platform-independent principal classes in future releases of JAAS for Linux. To ease migration, this version of JAAS contains the original set as well as the new set of principal classes. Also included is a new login module called com.ibm.security.auth.module.LinuxLoginModule2000, which has the same function as LinuxLoginModule but references the new set of principals. Additional principal classes have been included to facilitate the writing of new login modules.
You are encouraged to use the new set of principals when developing applications that use JAAS. Previously developed applications will be compatible with this version as well as future versions of JAAS released for the SDK v1.4.0.
If migrating applications to the new set of principals is desired, then most changes encountered will be in JAAS policy and configuration files rather than in the applications. Refer to the following table for guidance.
Original class | Replaced by |
---|---|
LinuxPrincipal | UsernamePrincipal |
LinuxNumericGroupPrincipal | GroupIDPrincipal PrimaryGroupIDPrincipal |
LinuxNumericUserPrincipal | UserIDPrincipal |
n/a | DomainPrincipal |
n/a | DomainIDPrincipal |
n/a | ServerPrincipal |
n/a | WkstationPrincipal |
LinuxLoginModule | LinuxLoginModule2000 |
Principal classes are found in the com.ibm.security.auth package while the login module is found in the com.ibm.security.auth.module package. Check the JAAS API documentation (Javadoc information) for more information on the new principal classes.
For example, this JAAS policy grant block:
grant Principal com.ibm.security.auth.LinuxPrincipal "bob", Principal com.ibm.security.auth.LinuxNumericUserPrincipal "727", Principal com.ibm.security.auth.LinuxNumericGroupPrincipal "12" { permission java.util.PropertyPermission "java.home", "read"; };
is replaced by:
grant Principal com.ibm.security.auth.UsernamePrincipal "bob", Principal com.ibm.security.auth.UserIDPrincipal "727", Principal com.ibm.security.auth.GroupIDPrincipal "12" { permission java.util.PropertyPermission "java.home", "read"; };
The Java Certification Path API provides interfaces and abstract classes for creating, building, and validating certification paths (also known as "certificate chains").
The IBM CertPath classes differ from the Sun version in the following ways:
For detailed information, including API documentation and samples, see the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
A history of the changes to CertPath since it was added to the SDK.
public TrustAnchor(X500Principal caPrincipal, PublicKey pubKey, byte[] nameConstraints); public final X500Principal getCA();
public X500Principal getIssuer(); public void setIssuer(X500Principal issuer); public X500Principal getSubject(); public void setSubject(X500Principal subject);
public void setIssuers(Collection issuers); public void addIssuer(X500Principal issuer); public Collection getIssuers();
The Java Cryptography Extension (JCE) provides a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers. The software also supports secure streams and sealed objects. JCE supplements the Java platform, which already includes interfaces and implementations of message digests and digital signatures.
You can obtain unrestricted jurisdiction policy files from http://www.ibm.com/developerworks/java/jdk/security/index.html. The policy files are replaced with restricted policy files when you upgrade your SDK. Before upgrading your SDK, make a backup of your policy files. After upgrading your SDK, install your backup policy files if you need an unrestricted policy.
The v1.4.2 unrestricted (and restricted) jurisdiction policy files are suitable for use with v5.0 and later. The v1.4.1 files are not suitable.
The com.sun.* packages are reimplemented by IBM and renamed com.ibm.* packages.
The IBM version of JCE differs from the Sun version in the following ways:
Blowfish
DES
El Gamal
Mars
ARCFOUR
PBE with MD2 and DES
PBE with MD2 and Triple DES
PBE with MD2 and RC2
PBE with MD5 and DES
PBE with MD5 and Triple DES
PBE with MD5 and RC2
PBE with SHA1 and DES
PBE with SHA1 and TripleDES
PBE with SHA1 and RC2
PBE with SHA1 and 40-bit RC2
PBE with SHA1 and 128-bit RC2
PBE with SHA1 and 40-bit RC4
PBE with SHA1 and 128-bit RC4
PBE with SHA1 and 2-key Triple DES
PBE with SHA1 and 3-key Triple DES
RC2
RC4
RSA encryption/decryption
RSA encryption/decryption with OAEP Padding
Seal
Triple DES
SHA2 with RSA
SHA3 with RSA
SHA5 with RSA
MD5 with RSA
MD2 with RSA signature
SHA1 with DSA signature
SHA2
SHA3
SHA5
MD5
MD2
Hmac/MD5
Hmac/SHA2
Hmac/SHA3
Hmac/SHA5
IBM SHA1PRNG
JKS
PKCS12KS
For detailed information, including API documentation and samples, see the developerWorks Web site at http://www.ibm.com/developerworks/java/jdk/security/index.html.
A history of the changes to the Java Cryptography Extension (JCE) since it was added to the SDK.
Known limitations of the IBM JCE provider.
The IBM SecureRandom generator in the IBM JCE provider meets several government security specifications. However, in order to meet these specifications, the authentication process can take longer than the authentication process for other providers. This problem has been seen on WebSphere® Application Server 7.0 when connecting to an Oracle database server.
If authentication does not need to be bound by the strict JCE security specification, use the IBM SecureRandom provider instead. This provider is available from Java 6 SR9 onwards. For more information, see IBM SecureRandom Provider.
Java Generic Security Service (JGSS) API provides secure exchange of messages between communicating applications.
JGSS is an API framework that uses Kerberos V5 as the underlying default security mechanism. The API is a standardized abstract interface under which you can plug different security mechanisms that are based on private-key, public-key, and other security technologies.
JGSS shields secure applications from the complexities and peculiarities of the different underlying security mechanisms. JGSS provides identity and message origin authentication, message integrity, and message confidentiality. JGSS also features an optional Java Authentication and Authorization Service (JAAS) Kerberos login interface, and authorization checks. JAAS augments the access control features of Java, which is based on CodeSource with access controls based on authenticated principal identities.
The IBM version of JGSS differs from the Sun version in the following ways:
For detailed information about JGSS, including API documentation and samples, see the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
A history of the changes to the Java Generic Security Service (JGSS) since it was added to the SDK.
Added CipherTextStealing mode.
To use this feature, configure Krb5LoginModule to use the ticket cache and set the newly introduced renewTGT option to true. Here is an example of a JAAS login configuration file that requests TGT renewal:
server { com.ibm.security.auth.module.Krb5LoginModule required principal=principal@your_realm useDefaultCcache=TRUE renewTGT=true; };Note that if renewTGT is set to true, useDefaultCcache must also be set to true; otherwise, it results in a configuration error.
The Java Secure Socket Extension (JSSE) is a Java package that enables secure internet communications. The package implements a Java version of SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols. It includes functions for data encryption, server authentication, message integrity, and optional client authentication.
By abstracting the complex underlying security algorithms and "handshaking" mechanisms, JSSE minimizes the risk of creating subtle but dangerous security vulnerabilities. Also, it simplifies application development by serving as a building block that you can integrate directly into your applications. Using JSSE, you can provide for the secure passage of data between a client and a server running any application protocol (such as HTTP, Telnet, NNTP, and FTP) over TCP/IP.
The FIPS provider included with the SDK is undergoing certification with the US Government. The certification progress is available on the CSRC Web site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140InProcess.pdf.
For detailed information, including API documentation and samples, see http://www.ibm.com/developerworks/java/jdk/security/index.html.
The IBMJSSE2 Provider, which was introduced in the v1.4.2 SDK, has replaced the IBMJSSE Provider. Although they are nearly equivalent, there are differences between the two providers.
The now-discontinued IBMJSSE Provider and the IBMJSSE2 Provider differ in the following ways:
Although they are nearly equivalent, there are differences between the IBMJSSE2 Provider and the Sun JSSE Provider.
The IBMJSSE2 Provider differs from the Sun JSSE in the following ways:
A history of the changes to the IBMJSSE2 Provider since it was added to the SDK.
Change for Version 6, Service Refresh 9
The IBMJSSE2 Provider is new for Version 1.4.2.
IBM JSSE2 allows SSL V3 or TLS V1 session renegotiation with peers that have implemented RFC 5746.
The IETF has published RFC 5746 Transport Layer Security (TLS) - Renegotiation Indication Extension. RFC 5746 defines a mechanism to implement TLS/SSL handshake renegotiation securely. Use of RFC 5746 replaces the industry wide interim solution of disabling all renegotiation implemented after the weakness was discovered.
After applying this APAR, IBM JSSE2 allows SSL V3 or TLS V1 session renegotiation with peers that have implemented RFC 5746. Session renegotiation with peers that do not support RFC 5746 reverts to the interim disablement solution. By default, unsecured renegotiation is not allowed. Use the system property com.ibm.jsse2.renegotiate to control how unsecured negotiations are handled by IBM JSSE2.
Read RFC 5746 for additional details if interested in the underlying TLS protocol changes to correct the weakness.
The following system properties are available to control how restrictive IBM JSSE2 is in the enforcement of RFC 5746:
The IBMPKCS11Impl Provider uses the Java Cryptography Extension (JCE) and Java Cryptography Architecture (JCA) frameworks to add the ability to use hardware cryptography through the Public Key Cryptographic Standards #11 (PKCS #11) standard.
This provider takes advantage of hardware cryptography in the existing JCE architecture. It gives Java programmers the significant security and performance advantages of hardware cryptography with minimal changes to existing Java applications. Because the complexities of hardware cryptography are handled in the normal JCE, advanced security and performance using hardware cryptographic devices is available readily.
PKCS#11 is a standard that provides a common application interface to cryptographic services on various platforms through several hardware cryptographic devices. See the IBMPKCS11Impl provider user guide for a list of supported devices.
For detailed information, including API documentation, see the developerWorks Web site at http://www.ibm.com/developerworks/java/jdk/security/index.html.
A history of the changes to the IBMPKCS11Impl Provider since it was added to the SDK.
Updated IBMPKCS11Impl to allow more algorithms and to allow the Sun 5.0 methods of initialization of the provider. The new algorithms are:
Added the ability to pass in a configuration file to the provider. This configuration file can contain a significant amount of information about the device; for example, what it should or should not do. After the provider is created, the application can log in to the card in different ways. Some devices allow you to perform some cryptographic functions without logging into the device. The v1.4.2 ways to initialize the device still work. However, you can no longer have more than one of these providers at a time. Instead, with this release, you can initialize more than one IBMPKCS11Impl provider using the 5.0 configuration file and login methods.
Deprecated the classes DESPKCS11KeyParameterSpec and DESedePKCS11KeyParameterSpec. Use the GeneralPKCS11KeyParameterSpec class for all symmetric key types (for instance, DES, DESede, AES, RC4, Blowfish).
The IBMPKCS11Impl Provider was new for v1.4.2.
The IBM Java JCE (Java Cryptographic Extension) FIPS Provider (IBMJCEFIPS) for multi-platforms is a scalable, multi-purpose cryptographic module that supports FIPS-approved cryptographic operations through Java APIs.
The IBMJCEFIPS includes the following Federal Information Processing Standards (FIPS) 140-2 [Level 1] compliant components:
To meet the requirements specified in the FIPS publication 140-2, the encryption algorithms used by the IBMJCEFIPS Provider are isolated into the IBMJCEFIPS Provider cryptographic module. You can access the module using the product code from the Java JCE framework APIs. Because the IBMJCEFIPS Provider uses the cryptographic module in an approved manner, the product complies with the FIPS 140-2 requirements.
Type | Algorithm | Specification |
---|---|---|
Symmetric Cipher | AES (ECB, CBC, OFB, CFB, and PCBC) | FIPS 197 |
Symmetric Cipher | Triple DES (ECB, CBC, OFB, CFB, and PCBC) | FIPS 46-3 |
Message Digest |
SHA1 SHA-256 SHA-384 SHA-512 HMAC-SHA1 |
FIPS 180-2 FIPS 198a |
Random Number Generator | FIPS 186-2 appendix 3.1 | FIPS 186-2 |
Digital Signature | DSA (512 - 1024) | FIPS 186-2 |
Digital Signature | RSA (512 - 2048) | FIPS 186-2 |
In addition, the IBMJCEFIPS supports the following unapproved algorithms:
Type | Algorithm | Specification |
---|---|---|
Asymmetric Cipher | RSA | PKCS#1 |
Key Agreement | Diffie-Hellman | PKCS #3 (Allowed in Approved mode) |
Digital Signature | DSAforSSL | Allowed for use inside the TLS protocol |
Digital Signature | RSAforSSL | Allowed for use inside the TLS protocol |
Message Digest | MD5 | FIPS 180-2 |
Random Number Generation | Universal Software Based Random Number Generator | Available upon request from IBM. Patented by IBM, EC Pat. No. EP1081591A2, U.S. pat. Pend. |
For more detailed information about the FIPS certified provider IBMJCEFIPS, see the IBM Java JCE FIPS 140-2 Cryptographic Module Security Policy. For usage information and details of the API, see the IBM Java JCE FIPS (IBMJCEFIPS) Cryptographic Module API document. These documents are available at http://www.ibm.com/developerworks/java/jdk/security/index.html.
Sun does not provide IBMJCEFIPS.
For detailed information, including API documentation and Security Policy, see the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
Simple Authentication and Security Layer, or SASL, is an Internet standard (RFC 2222) that specifies a protocol for authentication and optional establishment of a security layer between client and server applications. SASL defines how authentication data is to be exchanged but does not itself specify the contents of that data. It is a framework into which specific authentication mechanisms that specify the contents and semantics of the authentication data can fit.
The Java SASL API defines classes and interfaces for applications that use SASL mechanisms. It is defined to be mechanism-neutral: the application that uses the API does not need to be hardwired into using any particular SASL mechanism. The API supports both client and server applications. It allows applications to select the mechanism to use based on preferred security features, such as whether they are susceptible to passive dictionary attacks or whether they accept anonymous authentication. The Java SASL API also allows developers to use their own, custom SASL mechanisms. SASL mechanisms are installed by using the Java Cryptography Architecture (JCA).
The IBMSASL provider supports the following client and server mechanisms.
Only the package names, for example com.ibm.security.sasl, and the provider name are different from the Sun Implementation: com.ibm.security.sasl.IBMSASL.
Detailed information, including API documentation and samples, is on the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
Uses of the Key Certificate Management utilities.
The Key Certificate Management utilities make up a set of packages used to:
The Key Certificate Management utilities can:
The Subject Key Identifier is specified in RFC 3820, Section 4.2.1.2, http://www.faqs.org/rfcs/rfc3820.html.
The Key Certificate Management How-to Guide and Javadoc information are on the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
Java XML Encryption provides a standard set of APIs for XML digital encryption services and digital signature services.
You can use XML Encryption to perform fine-grained, element-based encryption of fragments in an XML Document. You can encrypt arbitrary binary data and include it in an XML document. The result of encrypting data is an XML Encryption element that contains or references the cipher data.
The IBM provider implementation of Java XML Encryption supports these algorithms:
You can use XML Digital Signature to perform detached, enveloped, and enveloping signatures and to sign arbitrary binary data and include this signed data in an XML document. The result of encrypting data is an XML Signature element that contains or references the signature data.
The IBM provider implementation of Java XML Digital Signature supports these algorithms:
The user guide and Javadoc information are on the developerWorks Web site: http://www.ibm.com/developerworks/java/jdk/security/index.html
IBM SecureRandom provides cryptographically strong random number generation as an alternative to the IBM JCE SecureRandom provider.
The IBM SecureRandom
provider is available from Java 6
SR9 onwards. The provider contains implementations of MD5, SHA1, IBMSecureRandom,
and SHA1PRNG. The algorithms MD5 and SHA1 are present only to supplement
the SecureRandom implementations. The provider does not expose these
algorithms as Message Digests that the provider supports.
The algorithms provided include:
MD5 with RSA
IBM SHA1PRNG
The IBM SecureRandom algorithm in the IBM SecureRandom provider does not meet all of the government security specifications that are required for IBM JCE SecureRandom. As a consequence, the performance is improved. However, you must use the IBM SecureRandom provider only for operations that do not need to meet the strict JCE specification. For example, the IBM SecureRandom provider can be used to replace IBM JCE SecureRandom when WebSphere Application Server 7.0 accesses an Oracle database server.
The IBM SecureRandom provider is intended only as a replacement for the SecureRandom algorithms of the IBMJCE provider. You must not use the IBM SecureRandom provider to replace the SecureRandom algorithms in any other provider, including IBMJCEFIPS.
The IBMSecureRandom.jar file containing the provider can be found in the jre/lib/ext directory. The IBM SecureRandom provider is not in the provider list by default. If you want to use this provider, follow these steps:
.... security.provider.2=com.ibm.securerandom.provider.IBMSecureRandom security.provider.3=com.ibm.crypto.provider.IBMJCE ....
The following extract shows you how to access the provider in your code:
SecureRandom random=null; SecureRandom random1=null; try { random = SecureRandom.getInstance ("IBMSecureRandom","IBMSecureRandom"); random1 = SecureRandom.getInstance("SHA1PRNG","IBMSecureRandom"); } catch (NoSuchAlgorithmException nsae ) { System.out.println("No such alg : "+nsae); System.exit(-1); } catch (NoSuchProviderException nspe ) { System.out.println("No such provider : " + nspe); System.exit(-1); }
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to:
For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:
The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:
Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.
The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.
Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample programs.
Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows:
© (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. © Copyright IBM Corp. _enter the year or years_.
If you are viewing this information softcopy, the photographs and color illustrations may not appear.
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at http://www.ibm.com/legal/copytrade.shtml.
Intel is a trademark of Intel Corporation in the United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Other company, product and service names may be trademarks or service marks of others.