DB2 Connect Version 10.5 for Linux, UNIX, and Windows

DCS directory values

You can use the Database Connection Services (DCS) to specify values that are used to define how an application connects to a database and what database it connects to.

You can specify the following information in the DCS directory:
Database name
A user-defined nickname for the IBM mainframe 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 IBM mainframe database server system, as follows:
System z®
A DB2® for z/OS® 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.

VSE or VM
The database name (DBNAME)
IBM® Power Systems™
The relational database name (RDBNAME)
Other
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.
map-file
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.
,D
This is the second positional parameter. If it is specified the application will disconnect from the IBM mainframe 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.
,,INTERRUPT_ENABLED
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 IBM mainframe 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 IBM Mainframe 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 for z/OS 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.
,,,,,SYSPLEX
This parameter, the 6th positional parameter, can be used to explicitly enable DB2 Connect SYSPLEX support for a particular database. The 6th parameter is disabled by default unless it is explicitly specified.
,,,,,,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 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 conditions 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 date format masks 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 date format masks 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 conditions 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.
,,,,,,,,BIDI=<ccsid>
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:
    ",,,,,,,,BIDI=xyz" 
where xyz represents the CCSID override.