DB2 10.1 DBA for Linux, UNIX, and Windows certification exam 611 prep, Part 8: Connectivity and networking

This tutorial aims to explain the process of configuring communications and the processes of cataloging databases, remote servers (nodes), and Database Connection Services (DCS) databases. You will also get introduced to DB2® Discovery and learn how to manage connections to System z® and System i® host databases. You will also learn about Lightweight Directory Access Protocol (LDAP). This tutorial prepares you for Part 8 of the DB2® 10.1 DBA for Linux®, UNIX®, and Windows® certification exam 611.

Share:

Darliene Hopes (dlhopes@us.ibm.com), DB2 Solution Migration Consultant, IBM China

Darliene HopesDarliene Hopes is a DB2 solution migration consultant at IBM. She has been working with DB2 for Linux, UNIX, and Windows since the start of her career. She is an IBM Certified DB2 database administrator who has been recently and consistently contributing to the DB2 community.



25 October 2012

Also available in Chinese

Before you start

About this series

Are you aiming to earn your IBM® DB2 10.1 DBA for Linux, UNIX, and Windows certification? If so, you've come to the right place. This series of "DB2 10.1 DBA certification exam 611" tutorials will provide you with the topics you need to become better prepared to pass the exam. This tutorial is great even if you aren't taking the exam and just want to familiarize yourself with the topics and learn about many of the new features and functionality available in DB2 10.1 for Linux, UNIX, and Windows.

About this tutorial

Six and one-half percent (6.5%) of the DB2 10.1 DBA for Linux, UNIX, and Windows (exam 611) is designed to test your ability to configure client/server connectivity as well as demonstrate knowledge of DB2 discovery and LDAP. The questions that make up this portion of the exam are designed to evaluate the following:

  • Your ability to catalog a local and remote DB2 database
  • Your ability to catalog a DB2 server
  • Your ability to understand DB2 Discovery
  • Your ability to understand the concept of LDAP

Objectives

The material in this tutorial covers the objectives in Section 8 of the DB2 10.1 DBA for Linux, UNIX, and Windows exam 611 (see Test 000-611: DB2 10.1 DBA for Linux, UNIX, and Windows). After completing this tutorial, you should be able to:

  • Catalog a DB2 database
  • Catalog a remote server
  • Identify the steps to access data stored on DB2 for z/OS® or DB2 for i5/OS™ database
  • Identify characteristics of DB2 locks (common locks shared across all platforms)
  • Understand how configuration parameters control the behavior of DB2 Discovery
  • Register a database/server with LDAP

Prerequisites

In order to understand some of the material presented here, you should be familiar with the following terms:

  • Authentication is the process by which a system verifies a user's identity. User authentication is completed by a security facility outside the DB2 database system, through an authentication security plug-in module.
  • Instance is a logical database manager environment where you catalog databases and set configuration parameters.
  • Configuration is the arrangement and options of settings for a system that affects system's performance and functionality.
  • Client refers to systems or applications that acquire the service of a server.
  • Server is a program providing database services to other computers and programs.
  • Remote refers to a database that resides on another server.

System requirements

You do not need a copy of DB2 to complete this tutorial. However, if you have access to a DB2 database server, you will be able to test some commands and concepts presented. You can download a complimentary copy of DB2 Express-C from IBM.


Configuring communications

Typically, in a client/server environment, databases stored on a server are accessed by remotely stored applications using a distributed connection. The distributed connection also allows administrators to remotely manage databases and servers. Some type of communications protocol recognized by the server must be used in order for this communication with a server to take place. In the same case, each server must use some communications protocol to detect inbound requests from clients. Usually, this is done by using the operating system on each machine to provide the communications protocol support needed. But in some cases, you can use the support provided by a separate add-on product. Either way, clients and servers must be configured to use a communication protocol that is recognized by DB2.

DB2 10 recognizes the following communications protocols:

  • NetBios
  • TCP/IP (this is used in most cases)
  • Named pipe

After installing DB2 on a client or server, it is automatically configured to take advantage of any communications protocols set up for that specific machine if the protocols found are recognized by DB2. Then the information about each of the supported communications protocol available is collected and stored in the configuration files for the DAS instance and the default instance as they are created. Changes in this information, including new protocol activation or the reconfiguring of an existing protocol, must be manually configured for each instance before such changes are reflected as it is not automatically updated.

Manually configuring communications

Using the Setup communications dialog within Data Studio is the simplest way to manually configure communications or make communications configuration changes. An alternate way to configure communications:

  1. Assign the value TCPIP to the DB2COMM registry variable. You must always update the DB2COMM registry variable value before the communications protocol desired can be used. Executing this command sets the registry value to TCPIP: db2set DB2COMM=TCPIP.
  2. Assign the name of the TCP/IP port that the database server will use to receive communications from remote clients to the svcename parameter of DB2 Database Manager configuration file. Executing an UPDATE DATABASE MANAGER CONFIGURATION command will set the parameter. Here is an example of command being set: UPDATE DBM CFG USING SVCENAME db2c_serv1.
  3. Update the services file on the database server, if appropriate. The TCP/IP services file identifies ports where the server applications will listen for requests from clients, so if you specified a service name in the svceneame parameter in the Database Manager configuration file, the correct service name-to-port number/protocol mapping must be added to the services file. If instead a port number was put into the svcename parameter, you do not have to update the services file. Here is an example of an entry in the services file for DB2: db2c_serv1 50001/tcp.

DB2 directory files

DB2 uses directory files to keep track of the locations of the databases on the network. These files also gives the DB2 instances an idea of how to establish connections to those databases with regard to users and applications.

There are four types of directories:

  • System database directory— Contains information, including name and location, for each database cataloged for this instance.
  • Local database directory— Contains information, including name and location, about the databases accessible from that location.
  • Node directory— Contains information that identifies how and where remote systems or instances can be found.
  • Database Connection Services (DCS) directory— Contains information needed to connect to DRDA host databases

Cataloging remote servers and databases

After a server is configured for communications, all clients that wish to access the database on the server must be configured to communicate with the server. After that entries from the server and the remote database must be added to the system database and node directories on the client. If the client intends to connect to a System z or System i database via DB2 Connect, entries must also be added to the DCS directory. This is done through a process called cataloging, in which entries are added to DB2's directories.

Cataloging a DB2 database

Most users never have to be concerned with the cataloging process since databases are cataloged implicitly upon creation. But, if you intend on accessing a database stored on a remote server, you must get familiar with the process of cataloging DB2 databases. It can be done using Data Studio or by executing the CATALOG DATABASE command.

Listing 1. Cataloging a database syntax
CATALOG [DATABASE | DB] [DatabaseName]
<AS [Alias]>
<ON [Path] | AT NODE [NodeName]>
<AUTHENTICATION [AuthenticationType]>
<WITH "[Description]">
Table 1. Cataloging a database attributes
DatabaseNameAliasPathNodeNameAuthenticationTypeDescription
Name assigned to database being catalogedAlias assigned to database when catalogedLocation (drive or directory) where directory hierarchy and files associated with the database to be cataloged are physically storedNode where database to be cataloged resides; should match an intro in node directory fileIdentifies where and how authentication is to take place when user attempts to access the databaseComment describing the database entry to be made in the database directory for the database to be cataloged (must be enclosed in quotation marks)

Example: To catalog a database physically residing in directory /home/db2info and has been given the name DUMMY_DB, execute the following CATALOG DATABASE command:

CATALOG DATABASE dummy_db AS test
ON /home/db2info
AUTHENTICATION SERVER

Cataloging a remote server (node)

The process involved in cataloging nodes (servers) is different from the one used to catalog databases. Usually, nodes are implicitly cataloged when a remote database is cataloged via Data Studio. To explicitly catalog a node (server) you can execute the CATALOG … NODE command that corresponds to the communications protocol being used to access the server being cataloged. There are different forms of the command, including:

  • CATALOG LOCAL NODE
  • CATALOG LDAP NODE
  • CATALOG NAMED PIPE NODE
  • CATALOG TCPIP NODE

The syntax for these commands are similar except that many options available are specific to the communications protocol for which the command is tailored. Since TCP/IP is the most common communication protocol used, we'll look at the syntax for that form of the CATALOG … NODE command.

Listing 2. Cataloging a remote server syntax
CATALOG <ADMIN> [TCPIP | TCPIP4 | TCPIP6] NODE [NodeName]
REMOTE [IPAddress | HostName]
SERVER [ServiceName | PortNumber]
<SECURITY SOCKS>
<REMOTE INSTANCE [InstanceName]>
<SYSTEM [SystemName]>
<OSTYPE [SystemType]>
<WITH "[Description]">
Table 2. Cataloging remote server attributes
NodeNameIPAddressHostNameServiceNamePortNumberInstanceNameSystemNameSystemNameDescription
Alias to be assigned to the node to be catalogedIP address of the server where the remote database you are trying to communicate with resides (IPv4/IPv6)Host name as it is known to the TCP/IP network (the name of the server where remote database you are trying to communicate with resides)Service name that the DB2 Database Manger instance on the server uses to communicatePort number the DB2 Database Manager instance on the server uses to communicate Name of the server instance to which an attachment is to be madeDB2 system name used to identify the server workstationType of OS being used on the server workstation (AIX®, Windows®, HP-UX, Sun, OS/390®, OS/400®, VM, VSE, and Linux®)Comment used to describe the node entry to be made in the node directory for the node being cataloged (must be enclosed in quotation marks)

Either the remote TCP/IP hostname or the remote IP address can be used to catalog a node. Similarly, the remote TCP/IP service name or the remote TCP/IP port number can be used when cataloging a node.

Example 1: To catalog a node for an AIX server named DB2HOST that has a DB2 instance named DB2INST1 that listens on port 60001, and assign it the alias REMOTE_SV, execute the following command:

CATALOG TCPIP NODE remote_sv
REMOTE db2host
SERVER 60001
OSTYPE AIX
WITH "A remote AIX TCP/IP node"

Example 2: To catalog a node for a Linux server that has the IPv4 address 192.0.32.71 and a DB2 instance named DB2INST1 listening on port 50001, and assign it the alias SERVER1, you can do so by executing a command that looks like this:

CATALOG TCPIP4 NODE server1
REMOTE 192.0.32.71
SERVER 50001
OSTYPE LINUX

More examples are available: Configuring client-to-server connections using the command line processor.

Cataloging a DCS database

Cataloging a Database Connection Services (DCS) database is similar to cataloging a regular DB2 database. To catalog the database, you use the CATALOG DCS DATABASE command with the following syntax:

Listing 3. CATALOG DCS DATABASE command syntax
CATALOG DCS [DATABASE | DB] [ALIAS]
<AS [TargetName]>
<AR [LibraryName]>
<PARMS "[ParameterString]">
<WITH "[Description]">
Table 3. CATALOG DCS DATABASE attributes
AliasTargetNameLibraryNameParameterStringDescription
Alias of the target database to be catalogedName of the target host database to be catalogedName of the application requester library to be loaded and used to access the remote database listed in the DCS directory (must be enclosed in quotation marks)Parameter string to be passed to the application requester when invokedComment describing the database entry to be made in the DCS directory for the database to be cataloged (must be enclosed in quotation marks)

Example: To catalog a DB2 for z/OS database residing in the TEST_DB subsystem on the z/OS server that has the name INFO and assign it the alias DATA_SYS, you could do so by executing a CATALOG DCS DATABASE command:

CATALOG DCS DATABASE data_sys
AS test_db
WITH "DB2 for z/OS LOCATION NAME TEST_DB"

More information is available: Configuring client-to-server connections using the command line processor.


Configuring communications to System z and System I database servers

System z and System i communications

To access the data stored in a DB2 for z/OS or a DB2 for i5/OS database:

  1. Configure TCP/IP communications on the DB2 Connect server.
  2. Catalog the TCP/IP node.
  3. Catalog the System z or System i database as a DCS database.
  4. Catalog the System z or System i database.
  5. Bind utilities and applications to the System z or System i database server.

Most steps to establish a connection between a DB2 Connect and a System z or System i host database are the same as the steps used to configure a client to access a database stored on a remote server. The difference is the host database must be cataloged as a DCS database, and DB2 utilities and applications must be bound to the System z or System i host database.

Binding utilities and applications

To bind utilities and applications the following steps must be taken from the DB2 Connect server:

  1. Go to the directory on the DB2 Connect server where the DB2 utility and application bind files are located (Linux/UNIX - sqllib/bnd Windows - bnd sub directory of the sqllib directory where DB2 is installed)
  2. Establish a connection to the database stored on the System z or System i server by executing CONNECT TO [DatabaseAlias].

    DatabaseAlias: Alias assigned to the database on the System z or System i server when the database was cataloged.

    A note about db2schema.bnd bind file

    When databases are created are migrated to a Linux, UNIX, or Windows DB2 server, the db2schema.bnd file is automatically bound to the database as part of the creation/migration process. It only exists on these kinds of servers and is used to create a package providing system catalog function support. If for some reason this package is missing, it must be rebound to the database.

    The file can be found in the sqllib/bnd subdirectory on Linux/UNIX and the bnd subdirectory of the sqllib directory where DB2 was installed for Windows. This file can be bound to the database by executing BIND db2schema.bnd BLOCKING ALL GRANT PUBLIC.

  3. Bind the DB2 utilities and applications to the database on the System z or System i server by executing the following: BIND @db2ubind.lst MESSAGES ubind.msg GRANT PUBLIC; BIND @db2cli.lst MESSAGES clibind.msg GRANT PUBLIC;

    db2ubind: List of the bind files needed to create packages for DB2 database utilities
    db2cli.lst: List of the bind files needed to create packages for the DB2 Call-Level Interface (CLI) and the DB2 ODBC driver.

  4. Terminate connection to the database stored on the System z or System i server by executing a command like CONNECT RESET;.

DB2 discovery

DB2 discovery provides an easy way to catalog a remote server and a database without having to know detailed communication-specific information. DB2 discovery broadcasts a discovery request over the network when invoked by a client. Every DB2 server on the network configured to support the discovery process provides a response in the form of a list of instances found on the server, information about the communication protocol each instance supports, and a list of databases found within each instance.

DB2 discovery uses one of two methods to process a discovery request: search and known. When search discovery method is used, the network is searched for valid DB2 servers and databases, and a list of all servers, instances, and databases found is returned to the client with the communications information needed to catalog and connect to each. When using the known discovery method, the network is searched for a specific server using a specific communications protocol. Like the search method, when the specified server is found, a list of all instances and databases found on the server is returned to the client with the information needed to catalog and connect to each.

The parameter values in the DAS instance configuration file, DB2 Database Manager configuration file for each instance (on client and server), and the database configuration file for each database within an instance determines whether a client can launch a DB2 discovery request, how it could be accomplished, and whether a particular server will respond. These parameters control:

  • If a client can launch a DB2 discovery request.
  • If a server can be located by DB2 discovery, whether the server can be located only when search discovery method is used, or when either the search or known discovery method is used.
  • If an instance can be located with a discovery request.
  • If a database can be located with a discovery request.

Table 1 describes the configuration parameters used to control DB2 discovery behavior.

Table 4. Configuration parameters that control the behavior of DB2 discovery
ParameterValues/DefaultDescription
Client Instance (DB2 Database Manager Configuration File)
discoverDISABLE, KNOWN, or SEARCHIdentifies the DB2 discovery action to be used by the client instance.
If this parameter is set to SEARCH, the client instance can issue search or known discovery requests. If set to KNOWN, the client instance can issue only known discovery requests. If set to DISABLE, the client instance cannot issue discover requests.
discover_instENABLE or DISABLE
Default: ENABLE
Specifies whether this instance can be detected by other DB2 discovery requests.
Server DAS Instance (DAS Configuration File)
discoverDISABLE, KNOWN, or SEARCH
Default: SEARCH
Identifies the DB2 discovery action to be used by the client instance.
If this parameter is set to SEARCH, the server responds to search and known discovery requests. If set to KNOWN, the server will respond only to known discovery requests. If set to DISABLE, the server will not respond to discovery requests.
Server Instance (DB2 Database Manager Configuration File)
discoverDISABLE, KNOWN, or SEARCH
Default: SEARCH
Identifies the DB2 discovery action to be used by the server instance.
If this parameter is set to SEARCH, the server instance can issue search or known discovery requests. If set to KNOWN, the server instance can issue only known discovery requests. If set to DISABLE, the server instance cannot issue discovery requests.
discover_instENABLE or DISABLE
Default: ENABLE
Identifies whether information about a particular instance found on a server will be included in the server's response to a discovery request.
If this parameter is set to ENABLE, the server will include information about the instance in its response to search and known discovery requests. If set to DISABLE, the server will not include information about the instance (and will not include information about any databases that come under the instance's control) in its response to discovery requests.
This parameter provides a way to hide an instance and all of its databases from DB2 discovery.
Server Database (Database Configuration File)
discover_dbENABLE or DISABLE
Default: ENABLE
Identifies whether information about a particular database found on a server will be included in the server's response to a discovery request.
If this parameter is set to ENABLE, the server will include information about the database in its response to search and known discovery requests. If set to DISABLE, the server will not include information about the database in its response to discovery requests.
This parameter provides a way to hide an individual database from DB2 discovery.

At the server level, instance level, and database level, you can enable or disable DB2 discovery and control how discovery requests are initiated. You can also configure a server so DB2 discovery will not see one or more of its instances or databases when discovery requests are made. In Figure 1, you can see how configuration parameters controlling the behavior of DB2 discovery can be used to prevent it from seeing specific instances and databases stored on a server.

Figure 1. Example of how configuration parameters can affect DB2 discovery behavior
Example of how configuration parameters can affect DB2 discovery behavior

Click to see larger image

Figure 1. Example of how configuration parameters can affect DB2 discovery behavior

Example of how configuration parameters can affect DB2 discovery behavior

Lightweight Directory Access Protocol

What is LDAP?

LDAP is an industry-standard access method to directory services. A directory service is a repository of resource information about multiple systems and services within a distributed environment. It also provides the client and servers with access to these resources. Each database server provides database information to the LDAP directory when the databases are created. When a client connects to a database, the catalog information for the server can be retrieved from the LDAP directory. Because of this, each client does not have to store catalog information locally on each machine. Client applications search the LDAP directory for information required to connect to the database. After information is retrieved from the LDAP directory server, it is stored or cached on the local computer based on the dir_cache database manager configuration parameter and the DB2LDAPCACHE registry variable. The dir_chache database manager configuration parameter is used to store database, node, and DCS directory files in memory cache. The directory cache is used by an application until the application closes. The DB2LDAPCACHE registry variable is used to store database, node, and DCS directory files in a local disk cache.

Before accessing information in the LDAP directory, an application or user is authenticated by the LDAP server. The authentication process is called binding to the LDAP server. It is important to apply access control on the information stored in the LDAP directory to prevent anonymous users from adding, deleting, or modifying the information. Access control by default, grants read access to everyone for database and node entries in LDAP. Read and write access is only granted to the directory administrator and the owner or creator of the object for database and node entries, as well as user profiles. A user cannot access the profile of another user if that user does not have directory administrator access.

DB2 supports IBM LDAP client on AIX, Solaris, HP-UX 11.11, Windows, and Linux. The table below shows the LDAP client and server configurations supported by DB2.

Table 5. Supported LDAP client and server configurations
Supported LDAP client and server configurationsIBM Tivoli® Directory serverMicrosoft® Active Directory serverSun One LDAP server
IBM LDAP ClientSupportedSupportedSupported
Microsoft LDAP/ADSI ClientSupportedSupportedSupported
Adapted from Table 1, found under Supported LDAP client and server configurations in the IBM DB2 10.1 Information Center for Linux, UNIX, and Windows (http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/r0006009.html)

Registering DB2 servers with LDAP

DB2 server instances must be registered in LDAP to publish the protocol configuration information used by the client applications to connect to the DB2 server instance. You must specify a node name when registering an instance of the database server. The node name is used by client applications when they connect or attach to the server. You can catalog another alias for the LDAP node by using the CATALOG LDAP NODE command.

The REGISTER command is shown below for registering a server:

db2 register db2 server in ldap
as ldap_node_name
protocol tcpip

The protocol clause refers to the communication protocol to use when connecting to this database server. The ldap_node_name must be unique in LDAP for each computer.

The REGISTER command can be issued for a remote DB2 server. To do so, you must specify the remote computer name, instance name, and the protocol configuration parameters when registering a remote server. The command can be used as follows:

db2 register db2 server in ldap
as ldap_node_name
protocol tcpip
hostname host_name
svcename tcpip_service_name
remote remote_computer_name
instance instance_name

When registering a remote DB2 server in LDAP, if TCP/IP is configured, the computer name must be the same as the TCP/IP hostname.

Registering DB2 database with LDAP

During the creation of a database within an instance, the database is automatically registered in LDAP. Registration allows remote client connection to the database without having to catalog the database and node on the client computer. When a client attempts to connect to a database, if the database does not exist in the database directory on the local computer, the LDAP directory is searched.

If the name exists in the LDAP directory, the database is still created on the local computer, but a warning message is returned stating the naming conflict in the LDAP directory. For this reason, you can manually catalog a database in the LDAP directory. The user can register databases on a remote server in LDAP by using the CATALOG LDAP DATABASE command. When registering a remote database, you specify the name of the LDAP node that represents the remote database server. You must register the remote database server in LDAP using the REGISTER DB2 SERVER IN LDAP command before registering the database.

To register a database manually in LDAP, use the CATALOG LDAP DATABASE command.

db2 catalog ldap database dbname
at node node_name
with "My LDAP database"

To register a database in LDAP from a client application, call the db2LdapCatalogDatabase API.

Creating LDAP users

When using the IBM Tivoli directory, defining an LDAP user before you can store user-level information in LDAP is a requirement. You can create an LDAP user by creating an LDIF file to contain all attributes for the user object, then run the LDIF import utility to import the object into the LDAP directory. The LDIF utility for the IBM Tivoli Directory Server is LDIF2DB.

Here is an example of the LDIF command to import an LDIF file using the IBM LDIF import utility: LDIF2DB -i newuser.ldif .

Configuring LDAP users

When you use the Microsoft LDAP client, the LDAP user is the same as the operating system user account. However, when you use the IBM LDAP client, before you use the DB2 database manager, you must configure the LDAP user distinguished name (DN) and password for the current logged-on user.

To configure the LDAP user distinguished name (DN) and password, use the db2ldcfg utility:

db2ldcfg -u userDN -w password --> set the user's DN and password
         -r                    --> clear the user's DN and password

Conclusion

Databases stored on a server are accessed by remotely stored applications using a distributed connection, which allows administrators to remotely manage databases and servers. For this to take place, recognized communication protocols must be used. The following communication protocols are recognized by DB2:

  • NetBios
  • TCP/IP (most frequently used)
  • Named pipe

To access a database stored on a remote server, you must catalog the database. You must also catalog the node on the local server containing the database.

To access the data stored in a DB2 for z/OS or a DB2 for i5/OS database:

  1. Configure TCP/IP communications on the DB2 Connect server
  2. Catalog the TCP/IP node
  3. Catalog the System z or System i database as a DCS database
  4. Catalog the System z or System i database
  5. Bind utilities and applications to the System z or System i database server

DB2 discovery provides an easy way to catalog a remote server and a database without having to know detailed communication-specific information. DB2 discovery uses one of two methods to process a discovery request: search and known. At the server level, instance level, and database level, you can enable or disable DB2 discovery and control how discovery requests are initiated.

LDAP is an industry-standard access method to directory services. Each database server provides database information to the LDAP directory when the databases are created. DB2 supports IBM LDAP client on AIX, Solaris, HP-UX 11.11, Windows, and Linux.

This tutorial was created to provide you with the processes for configuring communications and cataloging databases/servers, as well as introduce to you the concepts of DB2 discovery and LDAP. It was also designed to help you prepare for the DB2 10.1 DBA for Linux, UNIX, and Windows certification exam (exam 611). You should now have a better understanding of DB2 connectivity and networking, as well as be able to:

  • Catalog a local/remote DB2 database
  • Catalog a remote server
  • Identify the steps to access data stored on DB2 for z/OS or DB2 for i5/OS database
  • Identify characteristics of DB2 locks (common locks shared across all platforms)
  • Understand how configuration parameters control the behavior of DB2 discovery
  • Register a database/server with LDAP

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.
  • Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2 Express Edition for the community that offers the same core data features as DB2 Express Edition and provides a solid base to build and deploy applications.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=842457
ArticleTitle=DB2 10.1 DBA for Linux, UNIX, and Windows certification exam 611 prep, Part 8: Connectivity and networking
publish-date=10252012