IBM PCIeCC frequently asked questions

This page provides answers to frequently asked questions by customers of IBM's PCIe hardware security module (HSM), the IBM PCIe Cryptographic Coprocessor Version 1 (PCIeCC)

What operating system can I use?

The 4765 is supported on an IBM-approved x86 server running a supported operating system. See the PCIeCC Overviewpage for the list.

Which x86 servers are supported?

The 4765 is available on IBM-approved x86 servers as an IBM Z® machine type-model 4765-001 (4765).

What if I need to install a 4765 into a server that is not IBM approved?

IBM does not recommend installing a 4765 in a server that is not on the IBM-approved x86 servers list. Please contact Crypto at for additional information.

How can I learn about the PCIeCC and it specifications?

See the PCIeCC overview page.

How can I obtain performance data?

Obtain 4765 performance measurements here.

What warranty does IBM provide for the 4765?

Find warranty information for the 4765 here (PDF, 3,1 MB) (from Library page).

How can I place an order?

The 4765 is no longer sold by IBM.

Where do I get replacements for the two on-board batteries?

Order a 4765 battery replacement kit, which is required to safely replace the on-board batteries (note that this is the same kit as for a 4767).

Can I use a smart card to log on to CCA and manage master keys?

You can order optional smart card readers and smart cards (PDF, 2,9 MB) (from Library page) so that you can use smart cards to manage CCA DES and PKA master keys and log on to CCA using smart card CCA profiles).

What is involved in maintaining the two on-board batteries?

The on-board batteries are a critical component. See the "Maintaining coprocessor batteries" section in this manual (PDF, 1,4 MB ) (from Library page).

How do I properly replace the batteries?

See the "Replacing coprocessor batteries" section of this manual (PDF, 725 KB) to learn how to safely remove and replace the on-board batteries of a 4765 ( from Library page). The manual also describes how to properly recycle or dispose of the old batteries.

How do I obtain the firmware for my PCIeCC / 4765?

Find out how to obtain firmware (device drivers and operating system) here.

How do I install the 4765 in my server?

See the “Installing the coprocessor” section of this manual (PDF, 725 KB) (from Library page), after installing the host software first.

How can I find news of special interest about IBM's crypto products?

Important news for our current customers is posted here.

How can I obtain firmware updates?

You can find out how to obtain firmware updates here.

My enterprise has special cryptographic requirements. Can I customize the firmware of the HSM to make it perform as needed?

Learn more about the Cryptographic Coprocessor Toolkit (PDF, 1,1 MB) available for purchase from IBM to develop custom programming that extends the application program which performs within the HSM to create entirely new applications, thus extending the functionality of IBM's CCA application program.

Where can I get the expertise I need to customize CCA?

See this page on how to obtain education on the Cryptographic Coprocessor Toolkit.

When I have a problem with my hardware or software, how do I get help?

This page explains how to report a problem.

I could use some help writing code to call my first CCA verb. Do you provide any sample code?

Find sample code written in C that provides usage examples of the CCA API here.

Are there any CCA class offerings?

Find out about education offerings here.

How can I find out if there are any software updates to CCA?

Learn about software updates to the CCA software here.

How can I obtain a CCA software update?

Learn how to download CCA software updates here.

Do you provide a way to keep customers informed about Cryptocards news?

Keep abreast of the latest news about Cryptocards here.

How can I ask the Crypto team a question?

Ask the Crypto team a question, or make a comment.

What does a CCA return code of 12 and reason code of 338 mean?

CCA returns a return/reason code of 12/338 (X'C'/X'152') whenever a CCA application program attempts to use CCA but the coprocessor code has not been loaded. While other conditions can give rise to 12/338, this is typically the cause of the problem.

CCA returns a return/reason code of 12/338 (X'C'/X'152') whenever a CCA application program attempts to use CCA but the coprocessor code has not been loaded. While other conditions can give rise to 12/338, this is typically the cause of the problem.

Why do I have to wait for the coprocessor to be ready to use after it is powered on or reset, or when the device driver is being loaded?

Why do I have to wait for the coprocessor to be ready to use after it is powered on or reset, or when the device driver is being loaded?

Any time that the coprocessor is reset, it goes through an extensive set of power-on self-test (POST) functions. POST carefully tests all parts of the coprocessor. This includes special tests required for a device that is certified under FIPS 140 at Level 4. The coprocessor is a complex device that contains cryptographic hardware which must be carefully tested. These tests can take up to several minutes to run. The coprocessor is not available for use by any application programs until the POST completes.

On most servers, waiting for a reset will not be a problem when the server is booting. This is because the coprocessor POST runs at the same time. The coprocessor is usually available before the server is finished booting.

The coprocessor is also reset when the host device driver is explicitly loaded, or by running the CLU (Cryptographic Load Utility) program. Whatever the reason for the reset, the coprocessor will begin running POST and will not be usable for several minutes until the POST completes.

A CCA application program can be written to poll the coprocessor in order to determine when it is ready by periodically sending a CCA command like a Crypto_Facility_Query (CSUACFQ) status request and waiting until it returns with a successful return code.

Can I use Java to build applications to use with the CCA API

Yes. There is a JNI (Java Native Interface) available for using Java to build CCA applications. See the "Building Java applications to use with the CCA JNI" chapter in this manual (PDF,1,4 MB) (from Library page).

How can I install CCA from a console with a response file?

See "Installing CCA from a console."

What is the current FIPS status of the 4765?

The IBM 4765 continues to be FIPS 140-2 Level 4 compliant. The 4765 has been moved to the historical section of the NIST website, and has certificate #1505.  "Link resides outside"

The reason for the move is a change to the FIPS 186-4 standard that affects RSA key security.  That standard is called RSA-3K.

From Infogard: "All certs which did not migrate to RSA-3K and one of the NIST sp800-90 DRNGs were moved into a 'historical certifications' list and are collected separately.  So they are still available, on the separate list, but not current."

The reason IBM did not migrate to RSA-3K is because it is a lower level of security than what the 4765 has. IBM has no plans to migrate to this standard.

To elaborate, to meet the updated FIPS 186-4 standard, all crypto providers would have to reduce the size of our RSA keys from 4096 bits to 3072 bits. This would reduce security, so IBM decided not to make the change to meet the updated standard.

The Segment 1 hash in my IBM 4765 differs from the one listed in the FIPS certificate. Is this Segment 1 still FIPS-compliant?

The IBM 4765-001 Security Policy document is available here: "Link resides outside (PDF, 5.4 MB)" All changes in Segment 1 since the FIPS-certified release are not security related. They merely incorporate added bootstrap OS services and new cryptographic algorithms. See 4765-001 Segment 1 hash digests for a list of hash digests, which reflect the original Segment 1 version identified in the security policy document as well as subsequent, updated versions. All of these versions comply with this security policy document.

Do any IBM cryptographic adapters use the Dual_EC_DRBG method?

No. IBM CCA cryptographic coprocessors have ever used the Dual_EC_DBRG method, and thus customers using these coprocessors are not exposed to any weakness that might be in that algorithm. Coprocessors running CCA Release 4.4 or later use the SHA-256 based method from NIST SP 800-90, and older releases of CCA use a SHA-1 based method from ANSI X9.31.

IBM implements algorithms that are recommended by standards bodies and industry experts as the best practices, and updates those algorithms over time as recommendations change. For example, changes have occurred over time from DES to Triple-DES to AES and increases in RSA key size from 1024 to 4096 bits. Our current version of CCA implements the algorithms that are recognized as best practices today. To the best of our knowledge, and as supported by multiple crypto experts, there are no known weaknesses in the algorithms themselves. If industry recommendations change based on new analysis, IBM will consider moving to the newly recommended algorithms as we have always done in the past.

CCA has access-control point (ACP) command names that sometimes differ between operating systems. How can I determine the ACP command names by operating system?

See this Microsoft® Excel® spreadsheet (XLS, 122 KB) to determine ACP command names by operating system.

What are the Segment 1 hash digests for the IBM 4765-001?

The following list of IBM 4765-001 Segment 1 hash digests reflects subsequent, updated versions of the Segment 1 mentioned in the IBM 4765 security policy document. Your image should match one of these hash digests.

How do I enhance throughput with CCA and IBM PCIeCC?

The following describes how to enhance throughput of the IBM PCIe Cryptographic Coprocessor when using the IBM Common Cryptographic Architecture application programming interface. There are characteristics of your CCA host application program that can affect performance and throughput of the coprocessor. To better understand how to enhance throughput, consider these areas before designing your CCA applications:

  • Multi-threading and multi-processing
  • Caching of AES, DES, and PKA keys

Multi-threading and multi-processing

IBM cryptographic coprocessors are hardware security modules (HSMs). An IBM PCIe HSM can process multiple CCA requests simultaneously. This is because the HSM has several independent hardware elements that enable it to multi-process. These elements include the RSA engine, DES engine, CPU, random number generator, and PCIe communications interface. All of these elements work independently, and each can process a part of a different CCA verb at the same time. By being able to work on several CCA API calls at the same time, the HSM can keep some or all of its hardware elements busy. Keeping all of the hardware elements busy maximizes overall system throughput.

In order for an application to take advantage of the multi-processing capability of the coprocessor, the host system must send multiple CCA requests at the same time. These requests need to be sent without waiting for each one to finish before sending the next one. One option is to have several independent host application programs all using the coprocessor at the same time. The best way to accomplish this is to design CCA host application programs that are multi-threaded. Every thread would independently send CCA requests to the HSM, such as when a Web server application starts a new thread for each request that it receives over the network. This results in enhanced utilization and maximum system throughput.

Incoming requests are automatically managed, and it is not possible to overload the HSM.

Caching AES, DES, PKA, and retained RSA keys

The HSM can optionally keep ready-to-use keys in a memory cache. Using cached keys enhances throughput, but can have an adverse affect. Here is an explanation about how caching keys enhances throughput, followed by how using cache can cause problems.

When a wrapped key that is not in retained key storage is used, it incurs the overhead of being validated and unwrapped. The hardware security module (HSM) can optionally store a finite number of unwrapped symmetric or asymmetric keys in a memory cache, safely stored and ready to use within the encapsulated secure module. When caching keys is activated, any retained RSA key that is used is also stored in cache. Even though retained keys are never wrapped, uncached retained keys incur the overhead of being retrieved from internal flash EPROM memory. As a result of using key caching, applications that reuse a common set of keys can run much faster than those that use different keys for each transaction. Typical CCA applications use a common set of AES, DES, and PKA keys. This makes caching very effective at improving throughput. It should be noted that PKA public keys and uncached keys that are in the clear are not cached because they have very low overhead.

To improve performance, the CCA implementation provides caching of key records obtained from key storage within the CCA host code. However, the host cache is unique for each host process. Caching can be a problem if different host processes access the same key record. An update to a key record caused in one process does not affect the contents of the key cache held for other processes. To avoid this problem, caching of key records within the key storage system can be suppressed so that all processes will access the most current key records. To suppress caching of key records, use the export system command to set the environment variable CSUCACHE to 'N' or 'n' or to any string that begins with either of those letters.

What is the meaning of the "8xxxxxxx" return codes from CLU?

The following describes return codes that can be returned by the IBM PCIe Cryptographic Coprocessor device driver. Programs such as CLU (Coprocessor Load Utility) and the host parts of the IBM Common Cryptographic Architecture (CCA) Support Program can receive unusual status in the form of a 4-byte return code from the device driver. A coprocessor reset can also cause a device driver code to be returned.

There are times that the device driver of the coprocessor resets the device. Coprocessor resets can occur due to:

  • Device power-on
  • A device driver reset command
  • Coprocessor internal activity, such as completion of code updates
  • Coprocessor fault or tamper detection circuitry detects an event

Each time that a reset is not caused by a fault or tamper event, the device driver causes the coprocessor to run through its POST (power-on self-test), "Miniboot," internal code-loading, and status routines. During this process, the coprocessor attempts to coordinate with a host-system device driver. The coprocessor device driver monitors the status of its communication with the coprocessor and the coprocessor hardware status registers.

There are a very large number of possible 4-byte return codes. The most likely device driver return codes to be encountered are described in the following table. They are shown as hexadecimal digits, all of which are in the form of 8xxxxxxx.

Descriptions of most likely device driver return codes

Return code 
Reason Considerations
8040FFBF External intrusion Arises due to optional electrical connection (intrusion latch) to the coprocessor. This condition can be reset. See the CSUACFC verb, keyword RESET-IL. On IBM cryptographic coprocessors installed with CCA on x86 and IBM Power servers, no action is taken by CCA based on the state of the intrusion latch, and the state of the intrusion can be safely ignored.
8040FFDA Dead battery The on-board batteries have been allowed to run out of sufficient power, or have been removed. The coprocessor is zeroized and permanently disabled.
8040FFDB X-ray tamper This does not apply to the PCIe coprocessor.
8040FFEB Temperature tamper A high or low temperature threshold has been exceeded. The coprocessor is zeroized and permanently disabled.
8040FFF3 Voltage tamper A high or low voltage threshold has been exceeded. The coprocessor is zeroized and permanently disabled.
8040FFF9 Mesh tamper Physical damage to the tamper-evident shield that protects the coprocessor secrets has been detected. The coprocessor is zeroized and permanently disabled.
8040FFFB Reset bit is on Either (1) low voltage was detected, (2) the internal operating temperature of the coprocessor went out of limits, or (3) the host driver sent a reset command. Using proper procedures, try removing the coprocessor from the bus and reinserting it.
8040FFFE Battery warning Battery power is marginal. Failure to replace the on-board batteries as soon as possible could result in permanent damage to and non-recoverable failure of the coprocessor. See the IBM 4765 PCIe Cryptographic Coprocessor Installation Manual "Link resides outside (PDF, 725 KB)"(from Library page) for battery ordering and replacement procedures.
804xxxxx (e.g. 80400005) General communication problem Except for the prior X'8040xxxx' codes, there are additional conditions that arise in host-coprocessor communication. Determine that the host system in fact has a coprocessor. Using proper procedures, try removing the coprocessor from the bus and reinserting it. Run the CLU ST (status) command. If the problem persists, please contact the Crypto team.
8340xxxx Miniboot-0 codes This class of return code arises from the lowest-level of reset testing. If a return code in this class occurs, please contact the Crypto team.
8340038F Random number generation fault Continuous monitoring of the random number generator has detected a possible problem. There is a very small statistical probability of this event occurring without indicating an actual ongoing problem. The CLU ST (status) command should be run at least twice to determine if the condition can be cleared.
8440xxxx Miniboot-1 codes This class of return code arises from the replaceable POST and code-loading code. If a code in this class occurs, please contact the Crypto team.

How do I verify the integrity of the IBM 4767?

It is a good practice to validate that a coprocessor is legitimate and untampered before using it. IBM ships a copy of CLU (Coprocessor Load Utility) to use with the CCA Support Program. You can use this utility to validate your coprocessor.

For information on using CLU, refer to the "Coprocessor Load Utility reference" section of the IBM 4765 PCIe Cryptographic Coprocessor CCA Support Program Installation Manual "Link resides outside (PDF, 1.4 MB)". This manual and all other product documentation can be found on the Library page.

CLU status command

Use the ST command of CLU to start the validation process. This returns the coprocessor status.

From the CLU status response, confirm that the ROM Status is in the desired INITIALIZED state:

ROM Status 
Page 1 Certified : YES 
Segment-1 State : INITIALIZED

If you are using the CCA Support Program, confirm that the state is RUNNABLE and the Owner ID is 2 for the ROM Status of Segments 2 and 3:

Segment-2 State : RUNNABLE 
Segment-2 Owner ID : 2 
Segment-3 State : RUNNABLE 
Segment-3 Owner ID : 2

An Owner ID of 2 indicates the CCA product. Any value other than 2 is not valid for CCA. (Note: Each Cryptographic Coprocessor Toolkit purchaser is assigned a unique Owner ID (other than 2), and is able to load a customized version of CCA.)

Continuing with the status response, observe the values returned for each of the Segment-n Hash values, where n = 1, 2, or 3, returned for the code segments. Each of these three hash values is associated with a particular release of code.

Using the table below, verify that the hash digest returned by the CLU status command matches the expected hash digest in the table. If any of the three segment hash digests do not match, the code loaded in the coprocessor is illegitimate and is to be considered tampered.


Expected hash digests by segment and CCA release
Segment CCA Release Expected hash digest
1 4.4.55 722D F07C 6C6B 4939 5FFC 5B6F 777C 5B88 
A35B F368 BB73 3F49 9164 6D49 8B9E 5107
  4.4.20 722D F07C 6C6B 4939 5FFC 5B6F 777C 5B88 
A35B F368 BB73 3F49 9164 6D49 8B9E 5107
  4.4.16 722D F07C 6C6B 4939 5FFC 5B6F 777C 5B88 
A35B F368 BB73 3F49 9164 6D49 8B9E 5107
  4.3.5 722D F07C 6C6B 4939 5FFC 5B6F 777C 5B88 
A35B F368 BB73 3F49 9164 6D49 8B9E 5107
  4.2.5 57DA 34B1 4327 9C43 4910 7A55 6C4B 1F69 
54BC 3209 13D7 5D59 050C D27D FE99 6B1A
  4.1.6 177C AF13 C601 2276 90AA 8E20 D3BB BA58 
79A6 7EBA 6C2A D68B 0A34 33E0 802C 4EA7
2 4.4.55 03FA 58F1 F2B7 B5A5 68FE 23E6 BB7D 789D 
2878 3F78 BE02 8AD1 6E90 8ACA 5968 F1BF
  4.4.20 F3D7 5D25 2823 83FC EC69 20C3 73DC 45DF 
6D7A 2F8D 0CA9 B9D3 C4EC 8E22 AC79 3CF5
  4.4.16 01BA B729 C7AC CDD8 CFEF B6B2 E292 FF8C 
FDDB 07F0 0CB2 57DD 658E 87CA 09C5 E63E
  4.3.5 5EA8 9396 A42C 74DB 3664 9C1F 3622 C418 
435E 88FF D574 C38A 5132 0322 DCFD BE2C
  4.2.5 551D 27BE 0784 6DFC 5221 3DDA 46C2 E061 
7AAB 02B5 E884 6A88 1CEA 890A 6584 C5EE
  4.1.6 F131 02E0 8BA6 C68D 9190 FBA5 DAB8 9A4A 
59E8 2751 5D04 2358 F4BB EE32 A17C 7245
3 4.4.55 E0FF 2DC0 13F2 FD9B 451D 1AAF 4AFE CBE7 
6DFD 9245 445C DE73 C6C5 DB8A FE33 17B7
  4.4.20 8E44 9398 32D1 6BC3 4772 249E 69C8 72F4 
71FB 2379 6C96 DD3E FDB3 9CDE 4826 D395
  4.4.16 2BCB 0FE8 C281 2ABE 56C9 E41D F3D5 2D6B 
58BF 4493 6B9D 6B91 1C28 DD16 A803 2868
  4.3.5 B0DB 1360 94C9 949C ECD5 B881 9A30 B6D6 
5459 D3BF 7B33 901B 143B 1314 FBE4 6003
  4.2.5 6B8A 8F58 3181 9348 1E58 4338 BFA7 216D 
EB98 1CD6 26F8 7E21 2FFF 13E3 DAE3 201E
  4.1.6 ADBA 6401 6349 1D1D 8769 F3C4 EDDE B197 
036F DFA8 4B11 C1C4 FE1F AF40 358B B6D0

CLU SS command

The CLU system status (SS) command response includes a part number (P/N) value, such as 45D7930. Make a note of this 7-character alphanumeric value. It will be needed to complete the CLU validate command below.

CLU validate command

In the final manufacturing step, an IBM PCIe Cryptographic Coprocessor generates its own RSA public-private device-key key pair with the private key retained within the coprocessor. Manufacturing uses a class key to certify the device key, which is returned to the coprocessor.

Power from the on-board batteries or PCIe bus enables the coprocessor to actively monitor for tampering events. This monitoring occurs from the time of factory certification until the end of the coprocessor's useful life. Detection of tampering activity results in the zeroization of the coprocessor's secrets, along with the destruction of the private device key and its certificate.

For each different coprocessor part number, IBM ships a CLU file called a class-key certificate file. This type of file contains the class-key certificates for each class of coprocessor. For any given coprocessor class, CLU has hardcoded into it the necessary root key to validate the class-key certificates.

CLU has a VA (validate) command that uses as input a class-key certificate file. The file name is derived from the part number of the coprocessor. The part number (P/N) can be retrieved using the CLU system status (SS) command. Once you determine the part number for the coprocessor that you wish to valid, append "v.clu" to it to determine the name of the CLU data file to use for with the CLU VA command. For part number 45D7930, the class-key certificate data file name would be 45d7930v.clu.

When CLU is called with the VA command, it first validates the certificate contained in the class-key certificate file being provided as input. Using this certificate, CLU then validates the device key certificate that it retrieves from the coprocessor. Finally, using the validated device key, CLU validates status responses that the coprocessor signs with its device key.

You will need one or more of the following class-key certificate files for the IBM 4765, depending on which part numbers need to be validated:

Class-key files for use with the CLU VA command
Part Number Class-key certificate file
00V5420 00v5420v.clu
41U8608 41u8608v.clu
41U9986 41u9986v.clu
45D5117 45d5117v.clu
45D6045 45d6045v.clu
45D7930 45d7930v.clu
45D7947 45d7947v.clu

The IBM 4765 root key, which is hardcoded into CLU, is shown below. It is expressed in hexadecimal with the most significant bit first:

Public exponent:


C686E350 E09D6B08 64914CED C5A50B27
9D9C9ADA 6A84F01A 239D9ADB 7B0CCD07
1E784362 B4734E76 ED9583E5 98BF868A
B168464C C118099D EBA19A51 963FD3F1
8B39D9D1 E371D5E9 52361D20 D7F6EA9F
1C31A527 B7D94D0A 57DB1DF0 41B7C25B
B77ECDB4 16D9BEA0 D012C320 DD1E94D1
0E7C36C3 5B7D333A FC168A86 7FDBEA30
C82BF1FF 75C65391 3EAF7D63 C022E074
F8C34C5B 734D89FA 0C24583C 8440F167
6C5CB5E2 FA8D676B 37151A5D DC47AA1E
9B5FFB46 B68EC29C 9226F1B5 B19E3FD5
C134CF36 34C77FD8 AE01DA56 1ECE58B9
B415A143 4E176477 16C42EFB AA3A2E19
93639C01 CA841A91 2B580065 DC73C676
D2A8F1DA 98252833 A3AC4D30 7F874492
15745E0B 8CB23113 B980CE73 EE20308C
4B3C358E D971F26F EAE8CCDB 3157EDF2
6BAA30EF EEB60EB2 A6B6E46E 651159DA
B66DB985 98E53879 EE8D341B FDE939EA
4B25C5D8 50BE1130 90B30349 F120852A
005BED05 5A579EDD A2B09847 E29A3E81
F0ADEB30 8B40DAA7 B07A3B7F 998AB6F5
0D7F59D0 F3506B0D E146293B A958026F
304539E8 717737BA 34F3D43C 5582B0AC
F1D1391C C7BC676A 6AC0CFC6 E914E8E1
729CCA56 210C29E6 9AF1F2A2 A0BAB802
7ECCFD14 0CABC729 9210450C A5574F2C
B35A8841 22299C71 F2B1B490 3FE953C3
8BEAD71A 71F2B6A9 5ABAE4C9 839D95B9

How do I install CCA from a console?

In the event that a graphical desktop environment is not available, it is possible to install CCA from a console with the use of a response file. This response file is a text file created by the installer. It contains a record of user responses during the execution of the installer. This record of responses can then be used to control subsequent installs on another server, but without requiring a graphical desktop environment.

Due to legal and technical restrictions, the installer must be invoked once in GUI mode to accept the license agreements and to generate the response file.

A response file can only be used to replay exactly the same type install used in creating it. For example, if a response file is created during an install on a server without an existing installation, then that response file cannot be used to add features to an existing installation. A different response file must be created for each installation scenario.


Before installing CCA from a console, note the following caveats:

  • Successfully installing from a console without a response file is not possible.
  • If the message "Graphical installers are not supported by the VM" appears during the installation of CCA, the installer will resort to console mode instead of GUI mode, but without a response file. Although no errors will be reported, the install will not be functional.
  • Do not attempt to install using the "-i console" option. A required response file will not be used.
  • Do not attempt to install from an ssh or telnet session without a response file.

The steps to install or uninstall CCA from a console depend on which operating system you are using. Users with a 32-bit SUSE Linux Enterprise Server (SLES) operating system must follow one set of instructions, while users with a 64-bit SLES operating system, or a 32-bit or 64-bit Red Hat Enterprise Linux (RHEL) operating system, must follow a different set of instructions.

Steps to install or uninstall CCA from a console using 32-bit SLES

Follow these steps to install CCA from a console using a 32-bit SLES operating system, where "#.#.#" is "version.release.mod":

  1. To generate the response file, the installer must first be run as root from a GUI. For example, run as root this command:

    ./setup4765_#.#.#.bin -r "/home/user/"

  2. Copy the file /home/user/ to:


    where #.#.# is version.release.mod. For example:

    cp -p /home/user/ /home/user/

  3. Edit /home/user/ by adding this line to the top of the file, before all other non-comment items:


  4. Transfer the response file to a server without a GUI, and run as root. For example:

    ./setup4765_#.#.#.bin -f "/home/user/"

The uninstall program installed as part of the 32-bit SLES CCA install can be invoked with the "-i console" option. Perform this step to uninstall CCA from a console using a 32-bit SLES operating system:

/opt/IBM/4765/modify_installation -i console

Steps to install or uninstall CCA from a console using 64-bit SLES, or 32-bit or 64-bit RHEL

Follow these steps to install CCA from a console using either a 64-bit SLES operating system, or a 32-bit or 64-bit RHEL operating system, where "#.#.#" is "version.release.mod":

  1. To generate the response file, the installer must first be run as root from a GUI. For example, run as root this command:

    ./setup4765_#.#.#.bin -r "/home/user/"

  2. Transfer the response file to a server without a GUI, and run as root. For example:

    ./setup4765_#.#.#.bin -i silent -f "/home/user/"

The uninstall program installed as part of the 64-bit SLES, 32-bit RHEL, and 64-bit RHEL CCA install must not be invoked using the "-i console" option. Perform this step to uninstall CCA from a console using a 64-bit SLES, or a 32-bit or 64-bit RHEL operating system:

/opt/IBM/4765/modify_installation -i silent