DCS directory values


You can specify the following information in the DCS directory:

Database name

A user-defined nickname for the host or System i™ database server. 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 host or System i database server system, as follows:

OS/390® and z/OS®

A DB2 Universal Database™ for z/OS and OS/390 subsystem identified by its LOCATION NAME or one of the alias LOCATION names defined on the z/OS server. The LOCATION NAME can be determined by logging in to TSO and issuing the following SQL query using one of the available query tools:

   select current server from sysibm.sysdummy1
multiple LOCATION NAMEs are also defined in the Boot Strap Data Set (BSDS) as well as the DSNL004I message (LOCATION=location), which is written when the Distributed Data Facility (DDF) is started. The -DISplay DDF command could also be used.

If accessing a z/OS data sharing group, the domain name should map to the DB2® group dynamic VIPA address. This address routes to the least loaded DB2 member. To access a specific member use the specific DB2 member dynamic VIPA address and turn off sysplex routing. Each member DSNL004I message displays the member specific domain name.


The database name (DBNAME)

OS/400® and z/OS

The relational database name (RDBNAME)


For Windows®, Linux®, and UNIX® operating systems, the database alias found in the database directory.

Parameter string

If you want to change the defaults, specify any or all the following parameters in the following order.


The name of an SQLCODE mapping file that overrides the default SQLCODE mapping. To turn off SQLCODE mapping, specify NOMAP.

Note: When processing a query request, the DRDA® server returns data in the form of a set of rows that represent the result set. With each row, there is also an SQLCA returned, usually containing a zero or positive sqlcode (such as +12 or +802). If you use a customized mapping file at a DB2 Connect™ server, such positive sqlcodes will not be mapped if they are contained in the customized mapping file and have customized mappings (for example, they are mapped to a different sqlcode or have customized token mappings). It is important to emphasize that:

  1. Positive sqlcodes represent warnings, as opposed to negative sqlcodes which indicate error conditions. All the negative sqlcodes will always be mapped in all circumstances, regardless of which mapping file is being used. All the positive sqlcodes, contained in the customized mapping file and mapped to themselves with no change, will always be mapped as well. Also, those positive sqlcodes that are not contained in the customized mapping file at the DB2 Connect server will also always be mapped.

  2. If you use the default mapping file, or you connect to the host database directly, the sqlcode mapping will always be performed for all sqlcodes.


This is the second positional parameter. If it is specified the application will disconnect from the host or System i database 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, refer to the Message Reference.

Note: If DB2 Connect disconnects due to an error, a rollback will be done automatically.


This is the third positional parameter. INTERRUPT_ENABLED only applies if the end server does not support interrupts. If a server supports the DRDA interrupt flow DB2 Connect will simply pass the interrupt request on to the server.

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 host or System i database 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®, and Windows.

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 host or System i database server, in order to process additional database requests. On platforms other than AIX V5.2 and later and Windows, 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 might kill the socket, but - depending on the server implementation - there might or might not be an outstanding receive. DB2 Universal Database for z/OS and OS/390 uses 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.


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


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 TCPIP node nynode remote myhost server myport 
   catalog dcs database nydb1 as new_york    catalog database nydb1 as newyork1 at node nynode 
        authentication server
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. In this case, because the CLP is being used, and the parameter string is itself being specified using double quotation marks, the LOCALDATE value has to be specified inside two pairs of double quotation marks. Note the use of the operating system escape character "\" (backslash) to ensure that the double quotation marks are not stripped from the LOCALDATE specification.

   catalog dcs database nydb2 as new_york         parms \",,,,,,LOCALDATE=\"\"YYYYMMDD\"\"\"
   catalog database nydb2 as newyork2 at node nynode         authentication server
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. 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 there are 5 Y's in a sequence    "YYYYMDDM"   - invalid 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.


This parameter, the ninth positional parameter, is used to specify the Bidirectional (BiDi) CCSID to be used to override the default server database BiDi CCSID. For example:

where xyz represents the CCSID override.

Parent topic: Updating database directories