IBM Books

DB2 Connect User's Guide


Collecting Information

Appendix A. "Directory Customization Worksheet" shows the information that you need to collect. You may find it convenient to make a copy of the worksheet and write in the values for your system.

Node Directory

You can specify the following information in the node directory:

Node name
A nickname for the DRDA server system on which the remote database resides. This name is user-defined. Write the same node name in both the Node Directory Parameters table and the System Database Directory Parameters table.

Format: 1-8 single-byte alphanumeric characters, including the number sign (#), at sign (@), dollar sign ($), and underscore (_). It cannot begin with an underscore or a number.

Protocol
Can be APPC or TCPIP.

Symbolic destination name
When defining an APPC node, use the symbolic destination name that was specified in the CPI Communications Side Information Table (for example, the name of the CPI-C Symbolic Destination Properties when using Microsoft SNA Server). You should get this value from the person who either installed and/or configured SNA. The symbolic destination name is case sensitive (you may encounter an SQL1338 return code).

Security type
The type of security checking that will be done. For APPC nodes, the valid options are SAME and PROGRAM. For TCP/IP nodes, SECURITY SOCKS is an option which specifies that the node will be SOCKS-enabled, in which case the SOCKS_NS and SOCKS_SERVER environment variables are mandatory and must be set to enable SOCKS. For more information, see Chapter 7. "Security", and refer to the Command Reference.

TCP/IP remote hostname
When defining a TCP/IP node, either the remote TCP/IP hostname, or the remote TCP/IP address. If a hostname is specified, then it must be resolved at the DB2 Connect workstation, either through Domain Name Server (DNS) lookup, or by an entry in the local TCP/IP hosts file.

For DB2 for OS/390 remote hosts, the hostname appears in the DSNL004I message (DOMAIN=hostname) when the Distributed Data Facility (DDF) is started.

TCP/IP service name
When defining a TCP/IP node, either the remote TCP/IP service name or port number. This must be defined to TCP/IP at the remote host. Port number 446 has been registered as the default port number for DRDA.

For DB2 for OS/390 remote hosts, the port number is defined in the Boot Strap Data Set (BSDS) as PORT and is also provided in the DSNL004I message (TCPPORT=portnumber) when the Distributed Data Facility (DDF) is started.
Note:A second port used for two-phase commit resynchronization operations over TCP/IP connections is assigned by the server. For example, the DB2 for OS/390 bootstrap dataset assigns a port number (RESPORT) to be used for resynchronization for inbound connections to DB2 for OS/390 only. No service name need be defined for this.

DCS Directory

You can specify the following information in the DCS directory:

Database name
A user-defined nickname for the DRDA server database. Use the same database name in both the DCS Directory Parameters table and the System Database Directory Parameters table.

Format: 1-8 single-byte alphanumeric characters, including the number sign (#), at sign (@), dollar sign ($), and underscore (_). It cannot begin with an underscore or a number.

Target database name
The database on the DRDA server system, as follows:
MVS/ESA
The LOCATION value as defined in the DB2 for MVS/ESA Bootstrap Dataset (BSDS) "LOCATION=locname" field and which is also provided in the DSNL004I message (LOCATION=location) when the Distributed Data Facility (DDF) is started.
OS/390
The LOCATION value as defined in the DB2 for OS/390 Bootstrap Dataset (BSDS) "LOCATION=locname" field and which is also provided in the DSNL004I message (LOCATION=location) when the Distributed Data Facility (DDF) is started.
VSE or VM
The database name (DBNAME)
OS/400
The relational database name (RDBNAME)
Other
For OS/2, Windows NT, and UNIX-based systems, the database alias.

Format: AS <target_database_name>

The default is the value that you specify for Database name.

Application requester name
The name of the application requester that forwards SQL requests to DRDA application servers. The application requester handles requests on behalf of an application program.

Format: AR <application_requester_name>

The default is the DB2 Connect application requester.

Parameter string
If you want to change the defaults, specify any or all the following parameters in the following order. Note that the parameter string cannot be set using the Client Configuration Assistant, and that when using the CLP the parameter string must be enclosed in either single quotes (for example on OS/2 or Windows NT), or in double quotes (for example on AIX):

map-file
The name of an SQLCODE mapping file that overrides the default SQLCODE mapping. To turn off SQLCODE mapping, specify NOMAP. For more information, see Chapter 9. "SQLCODE Mapping".

,D
This is the second positional parameter. If it is specified the application will disconnect from the DRDA server database when one of the following SQLCODES is returned:
   SQL30000N
   SQL30040N
   SQL30050N
   SQL30051N
   SQL30053N
   SQL30060N
   SQL30070N
   SQL30071N
   SQL30072N
   SQL30073N
   SQL30074N
   SQL30090N

When the disconnect parameter ,D is not specified, a disconnect will be performed only when the following SQLCODEs are returned:

   SQL30020N
   SQL30021N
   SQL30041N
   SQL30061N
   SQL30081N

For explanations of these codes, see the Messages Reference.
Note:If DB2 Connect disconnects due to an error, a rollback will be done automatically.

,,INTERRUPT_ENABLED
This is the third positional parameter. If INTERRUPT_ENABLED is configured in the DCS directory at the DB2 Connect workstation, and a client application issues an interrupt while connected to the DRDA server, DB2 Connect will perform the interrupt by dropping the connection and rolling back the unit of work. This interrupt behavior is supported on AIX, OS/2, and Windows NT.

The application will receive sqlcode (-30081) indicating that the connection to the server has been terminated. The application must then establish a new connection with the DRDA server, in order to process additional database requests. Note that on platforms other than AIX V4.1 with SNA Server V3.1, OS/2, and Windows NT, DB2 Connect does not support the option of automatically disconnecting when an application using it receives an interrupt request.
Note:This support works for TCP/IP connections on any platforms. The client may kill the socket, but - depending on the server implementation - there may or may not be an outstanding receive. DB2 for OS/390 utilizes asynchronous socket calls and therefore is able to detect the loss of the connection and roll back any long-running SQL statements that are in progress.

,,,,,SYSPLEX
This parameter, the 6th positional parameter, can be used to explicitly enable DB2 Connect SYSPLEX support for a particular database.

Note that a new profile (environment or registry) variable has also been introduced, called DB2SYSPLEX_SERVER, and it can be used to disable the SYSPLEX support at the workstation level.

,,,,,,LOCALDATE="<value>"
This parameter, the seventh positional parameter, is used to enable DB2 Connect date formatting support. This is implemented using a date mask for the <value> as follows:

Suppose you issue the following CLP (command line processor) statements:

   catalog appc node nynode remote nycpic security program 
   catalog dcs database nydb1 as new_york
   catalog database nydb1 as newyork1 at node nynode 
        authentication dcs

The database alias "newyork1" is to be used for accessing a host database without date transformation because no date mask has been specified.

However, with the new date formatting support, you can now use the following CLP commands. Note that in this case, because the CLP is being used, and the parameter string is itself being specified using double quotes, the LOCALDATE value has to be specified inside two pairs of double quotes.Note the use of the operating system escape character "\" (backslash) in order to ensure that the double quotes are not stripped from the LOCALDATE specification. See also "Specifying the Parameter String".

   catalog dcs database nydb2 as new_york
        parms \",,,,,,LOCALDATE=\"\"YYYYMMDD\"\"\"
   catalog database nydb2 as newyork2 at node nynode
        authentication dcs

The database alias "newyork2" gives you access to the same host database but, in addition, it has a date format mask specified. This example illustrates that the date format mask is specified using the keyword LOCALDATE and is the seventh positional parameter in the PARMS field of a DCS directory entry.

In order for the date mask to be valid, ALL of the following must be true:

  1. There can only be at most one sequence each of Y's, M's, and D's where Y is a year digit, M is a month digit, and D is a day digit.

  2. The maximum number of Y's in a sequence is 4.

  3. The maximum number of M's in a sequence is 2.

  4. The maximum number of D's in a sequence is 2.

For instance, the following are all valid date masks:

   "YYyyMmDd"   - Y, M, and D digits are case-insensitive
   "MM+DD+YYYY" - OK to have a mask longer than 10 bytes
                  and to have characters other than Y, M,
                  and D in the mask
   "abcYY+MM"   - OK not to have a sequence of D's

The following are all invalid date masks:

   "YYYYyMMDD"  - invalid because there are 5 Y's in a sequence
   "YYYYMDDM"   - invalid because there are 2 sequences of M's

If a date format mask is invalid, no error will be issued. It will just be ignored. Just because a date mask is valid does not mean it will be used. Date format transformation based on a valid date mask will only be performed if ALL of the following are true:

  1. There is no SQL error.

  2. The output is a date value in ISO-like (ISO and JIS) format.

  3. The output data area is at least 10 bytes long. This is the minimum size of an output data area in order for a data value to be stored there even if NO date format transformation is to be performed. This requirement applies even if the date format mask ends up being shorter than 10 bytes.

  4. There is a valid date format mask specified in the DCS directory entry and this mask fits in the output data area.

Specifying the Parameter String

Here are examples of some parameter strings you could specify.

For example, you could specify any of the following where "\" (backslash) is the operating system escape character:

On AIX:
 
   NOMAP
   /u/username/sqllib/map/dcs1new.map,D
   ,D
   ,,INTERRUPT_ENABLED
   NOMAP,D,INTERRUPT_ENABLED,,,SYSPLEX,LOCALDATE=\"\"YYMMDD\"\"
 
On OS/2 or Windows NT:
 
   NOMAP
   d:\sqllib\map\dcs1new.map,D
   ,,INTERRUPT_ENABLED
   NOMAP,D,INTERRUPT_ENABLED,,,SYSPLEX,LOCALDATE=\"\"YYMMDD\"\"
 

Alternatively you can accept the defaults by not specifying a parameter string.
Note:Because of the need to specify two pairs of double quotes when specifying the LOCALDATE mask in the parameter string, you must use the operating system escape character "\" (backslash), for example:
   db2 catalog dcs db x as y parms \",,,,,,LOCALDATE=\"\"YYMMDD\"\"\"
This results in the following DCS directory entry:
   DCS 1 entry:
 
    Local database name                = X
    Target database name               = Y
    Application requestor name         =
    DCS parameters                     = ,,,,,,LOCALDATE="YYMMDD"
    Comment                            =
    DCS directory release level        = 0x0100

System Database Directory

You can specify the following information in the system database directory:

Database name
The same value that you wrote in the DCS Directory Parameters table.

Database alias
An alias for the DRDA server database. This name will be used by any application program that accesses the database. By default, the value that you specify for Database name is used.

Format: 1-8 single-byte alphanumeric characters, including the number sign (#), at sign (@), dollar sign ($), and underscore (_). It cannot begin with an underscore or a number.

Node name
The same value that you wrote in the Node Directory Parameters table.

Authentication
Specifies where the validation of the user's name and password will be done. The valid options are: SERVER, CLIENT, DCE, and DCS. For more information, see Chapter 7. "Security".

Defining Multiple Entries for the Same Database

For each database, you must define at least one entry in each of the three directories (node directory, DCS directory, and system database directory). In some cases, you might want to define more than one entry for the database.

For example, you might want to turn off SQLCODE mapping for applications that were ported from the DRDA server but accept the default mapping for applications that were developed for the client/server environment. You would do this as follows:

Both aliases access the same database, one with SQLCODE mapping and the other without SQLCODE mapping.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]