DB2 Version 9.7 for Linux, UNIX, and Windows

Alternative installation methods

Thin client topology overview (Windows)

This section describes an alternative method for installing an IBM® data server client that leverages the Windows® support for thin client topology. Thin client topologies are only supported in 32-bit environments. You can use this method to install IBM Data Server Client or DB2® Connect™ Personal Edition on Windows operating systems. This method does not apply to IBM Data Server Runtime Client or IBM Data Server Driver Package.

A thin client topologies or thin client topology environment consists of one thin client code server and one or more thin clients. The IBM data server client code is installed on the code server, rather than on each client workstation. On each thin client workstation, only a minimal amount of code and configuration is required. When a thin client initiates a database connection, IBM data server client code is dynamically loaded from the code server as required. The thin client then connects to the database in the usual fashion.

The following figures illustrate the thin client topology. In the first case, Data Server Client is installed on the code server that serves the Data Server Client code to the thin client workstations. These client workstations then connect to one or more DB2® servers.

In the second figure, DB2 Connect Personal Edition is used instead of Data Server Client. DB2 Connect Personal Edition provides the additional capability of enabling clients to connect directly to a DB2 product on midrange and mainframe platforms.

Figure 3. A typical thin client topology using IBM Data Server Client

Figure 4. A typical thin client topology using DB2 Connect Personal Edition

Use the thin client method of installing a client when client workstations need only occasional access to a database or when it would be difficult to set up the IBM data server client on each client workstation. If you implement this type of environment, disk space requirements for each workstation are reduced and you can install, update, or upgrade the code on only one machine: that is, the code server.

DB2 programs must be loaded from a code server across a LAN connection. The extent of performance loss at program initialization time depends on variables such as the load on and speed of both the network and the code server.

Thin client setup overview (Windows)

Setting up a thin client environment involves setup on both the code server and each thin client workstation.

To set up a thin client environment:

1. Install an IBM Data Server Client or DB2 Connect Personal Edition on the code server.
2. Make the code directory on the code server available to all thin workstations.
3. Create a thin client response file.
4. Map a network drive from each thin client workstation to the code server.
5. Setup each thin client by running the thnsetup command.

This installation does not include product documentation.

Installing IBM Data Server Client or DB2 Connect Personal Edition on the code server (Windows)

To install Data Server Client or DB2 Connect Personal Edition on the code server:

1. Locate the appropriate DVD, and start the installation wizard.
2. Select Custom installation from the installation wizard.
3. From the Select the Features to Install window, select Server Support, and then select Thin Client Code Server.
4. Complete the remaining installation wizard steps.

Your next step is to make the code directory on the code server available to all thin workstations.

Making the code directory available to all thin client workstations (Windows)

To make the code directory available to all thin client workstations (in read mode) using Windows XP as an example:

1. On the code server, start Windows Explorer.
2. Select the directory on the code server that will be used to serve thin client workstations. For this example, select the d:\sqllib directory to set up the share.
3. Select File --> Properties from the menu bar.
4. Click the Sharing tab.
5. Click the Shared This Folder radio button.
6. In the Share Name field, enter a share name that is eight characters or fewer. For example, enter NTCODESV.
7. Provide read access to the code directory to all thin client users:
   1. Click Permissions. The Share Permissions window opens.
   2. In the Group or User sName list, highlight the Everyone group.
      Note:
      You can give access to the Everyone group, to a group that you have specifically defined for thin client users, or to individual thin client users.
   3. Select Read.
   4. Click OK until all windows are closed.

Your next step is to create a thin client response file.

Creating a thin client response file (Windows)

Locate the sample response file db2thin.rsp in the c:\sqllib\thnsetup directory, where c:\sqllib represents the location where you installed your thin client code server. In a response file, the asterisk (*) acts like a comment. Any line that is prefixed by an asterisk will be ignored during the installation. To enable a keyword, remove the asterisk. If you do not specify a keyword, or if it is commented out, a default value will be used.

For example, the default entry for the ODBC_SUPPORT keyword (used for installing support for ODBC) in the response file is as follows:

   *COMP		=ODBC_SUPPORT

To install ODBC, remove the asterisk from the line as shown in this example:

   COMP		=ODBC_SUPPORT

For some keywords, you must set values. To enable these keywords, remove the asterisks. However, ensure that you also replace the contents to the right of the equal sign with the value that you want for the keywords.

Following is an example of the entry for DB2.DIAGLEVEL:

   *DB2.DIAGLEVEL	= 0 - 4

To set this keyword to 4, make the following change:

   DB2.DIAGLEVEL	= 4

After you finish editing the response file, save it using a different name to maintain the original sample. For example, call the edited file test.rsp, and save it in the same directory in which you set up the shared permissions (for example, d:\sqllib).

You will use this response file in a subsequent step, setting up thin clients using the thnsetup command.

Mapping a network drive from each thin client to the code server (Windows)

You must be logged on to the workstation as a valid user with shared directory access to the code server. You have access to the code server if a locally defined user account was created on the code server.

To map a network drive from the thin client:

1. Launch Windows Explorer.
2. On the Tools menu, click Map Network Drive.
3. In the Drive list, select the drive to which you want to map the location of the code server.
4. In the Folder field, specify the location of the share as follows:

        \\computer_name\share_name 

   where:

   computer_name

   represents the computer name of the code server

   share_name

   represents the share name of the shared directory on the code server

5. Select the Reconnect at Logon check box to make the share persistent.

The next step is enabling each thin client.

Setting up thin clients using the thnsetup command (Windows)

Before you begin

Ensure that either Microsoft® Visual C++ 2005 or the appropriate runtime components of the Visual C++ libraries are installed before you issue the thnsetup command. The runtime library is available from the Microsoft runtime library download Web site. There are two choices: choose vcredist_x86.exe for 32-bit systems or vcredist_x64.exe for 64-bit systems.

About this task

Perform the following steps on each workstation that you want to set up as a thin client.

Procedure

To set up a thin client:

1. Run the thnsetup command. You can specify the following parameters:
   
   where:

   /P

   Specifies the path where the DB2 code is installed on the code server. This parameter is required. If you have not already mapped a persistent network drive to the code server. The value of this parameter should be the drive letter used to represent the network drive.

   /U

   Specifies the fully qualified response file name. This parameter is required. Normally, the file is located on the code server in the directory c:\sqllib\thnsetup, where c:\sqllib\ represents the drive where you installed your thin client code server.

   /L

   Specifies the fully qualified log file name, where setup information and any errors occurring during setup will be logged. This parameter is optional. If you do not specify the log file name, the default db2.log file name is used. This file will be created in the db2log directory, on the drive where your operating system is installed.

   /M

   Specifies the name of the code server. This parameter is required.

   /S

   Specifies the share name of the code server where you installed the DB2 product. This parameter is necessary only if you did not map a persistent network drive. This parameter is mandatory on Windows XP and Windows Server 2003 operating systems.

2. When the thnsetup command is completed, check the messages in the log file (db2.log in the y:\db2log directory, where y is the drive on which the DB2 code is installed).

   Check any error messages. The error messages in the log file depend on the errors that were encountered during the attempted installation. The log file states the reasons for failure.

Example

For example, you might want to create a thin client workstation under the following conditions:

• The shared directory with the share name on a code server is mapped locally to the x drive.
• The response file is called test.rsp.
• The response file is located in the same directory as the code server:

On the thin client workstation, enter the following command from a DOS prompt on the thin workstation:

   x:\thnsetup\thnsetup /P x: /U x:\thnsetup\test.rsp /M machineName  

DB2 instance merge modules (Windows)

DB2 Version 9.5 supports two types of merge modules: DB2 instance merge modules and non-DB2 instance merge modules. It is recommended that you use non-DB2 instance merge modules.

DB2 instance merge modules require additional overhead and maintenance, but can be used when:

• an application requires a DB2 instance environment, or,
• an application requires function that only exists in a DB2 instance merge module. (The DB2 instance merge modules are listed later in this section.)

Using DB2 instance Windows Installer merge modules, you can easily add IBM Data Server Runtime Client function to any product that uses the Windows Installer.

When you merge the modules, you will be prompted to supply the DB2 copy name. Multiple copies of DB2 products can be installed on the same machine; so each copy is known by its unique name. This name will be used when the installation is performed on each target machine. Choose a name that is unlikely to be already used for another DB2 copy. Suitable names include the name of your application, for example, myapp_db2copy_1. If the name is not unique, the installation will fail.

For more information on merge module technology, see the documentation included with your installation authoring product or at http://msdn.microsoft.com.

The following merge modules are available for your use:

DB2 Base Client Merge Module.msm

This module provides the function required for database connection, SQL, and DB2 command function. This module allows you to use the Named Pipes communication protocol to transfer data in a client-server environment, contains the system bind files which are used for such tasks as creating databases or accessing remote host databases, and, provides various tools used to administer local and remote databases. This module also allows you to create a response file which can be used to configure the DB2 copy within your installation. The configurable option specifies the location of a response file used to configure the DB2 copy. Types of configuration include creating instances, setting database manager configuration parameters or DB2 profile registry variables. You can also use the Command Line Processor (CLP) with this module.

For information about the sequence of various custom actions and the proposed sequences, view the merge module with a tool such as Orca.

DB2 JDBC and SQLJ Support.msm

This module contains JDBC and SQLJ support allowing Java™ samples to be built and run using the JDBC driver.

DB2 LDAP Exploitation Merge Module.msm

This module allows the DB2 copy to use an LDAP directory to store database directory and configuration information.

DB2 ODBC Support Merge Module.msm

This module provides support for applications that use Open Database Connectivity (ODBC) to access data.

DB2 OLE DB Support Merge Module.msm

This module provides a set of interfaces that allows applications to uniformly access data stored in different data sources.

IBM Data Server Provider for .NET Merge Module.msm

This module enables your application to use the IBM Data Server Provider for .NET. The IBM Data Server Provider for .NET is an extension of the ADO.NET interface that enables your .NET applications to quickly and securely access data from DB2 databases.

The following Microsoft re-distributable merge modules are included with the IBM Data Server Runtime Client merge modules. You must include these Microsoft merge modules when merging Data Server Runtime Client merge modules.

You can find the Microsoft merge modules on the IBM Data Server Runtime Client DVD under the merge module directory.

The following merge modules contain IBM data server client messages used by the DB2 copy. Depending on the languages of your product, include and install the components in the appropriate merge module.

IBM Data Server Runtime Client installation command-line options

You can install IBM Data Server Runtime Client using the db2setup.exe command on Linux® or UNIX® operating systems or the setup.exe command on Windows operating systems. The parameters of the two commands are different.

The following list describes selected popular standard Windows Installer command line options available when you run setup.exe to install IBM Data Server Runtime Client on Windows operating systems. For more information on the available Windows Installer options, see http://www.msdn.microsoft.com/.

/w

This option forces setup.exe to wait until the installation is complete before exiting.

/v

This option allows you to pass additional command-line options and public properties to Windows Installer. You must specify this option to perform a response file installation.

/l*v[log file name]

This option allows you to create a log of the installation. You can use the log to troubleshoot any problems that you encountered during the installation.

/qn

This option allows you to perform a silent installation with no User Interface (UI), except for a window that the Windows installer displays while it extracts files from the installation package before it starts the actual installation.

/qb!

This option displays a basic user interface which shows simple progress and error message handling and hides the Cancel button, except in a window that the Windows installer displays while it extracts files from the installation package before it starts the actual installation.

/L

This option allow you to change the setup language by specifying the language identifier. For example, to specify French as the setup language, specify the French language identifier, setup.exe /L 1036 command.

Table 18. Language Identifiers

Language	Identifier
Arabic (Saudi Arabia)	1025
Bulgarian	1026
Chinese (Simplified)	2052
Chinese (Traditional)	1028
Croatian	1050
Czech	1029
Danish	1030
Dutch (Standard)	1043
English	1033
Finnish	1035
French (Standard)	1036
German	1031
Greek	1032
Hebrew	1037
Hungarian	1038
Italian (Standard)	1040
Japanese	1041
Korean	1042
Norwegian (Bokmal)	1044
Polish	1045
Portuguese (Brazilian)	1046
Portuguese (Standard)	2070
Romanian	1048
Russian	1049
Slovak	1051
Slovenian	1060
Spanish (Traditional Sort)	1034
Swedish	1053
Turkish	1055

Here are the public properties that you can specify to control the installation of Data Server Runtime Client:

• These parameters must be the last parameters in the command line.
• RSP_FILE_PATH - This contains the full path to the response file that you use to install Data Server Runtime Client. This is valid only when you specify /qn.

To perform a response file installation, the following command line parameter should be used:

   setup /v"/qn RSP_FILE_PATH=[Full path to the response file]"

The example assumes that no copy of the client is already installed. If one or more copies exist, the command is different. To install a second copy using a response file, use the following command:

   setup /v" TRANSFORMS=:InstanceId1.mst MSINEWINSTANCE=1 
         /qn RSP_FILE_PATH=[Full path to the response file]"