Appendix B, Directory Customization Worksheet shows the information that you need to collect. You may find it convenient to make a copy of the worksheet and enter your system values.
You can specify the following information in the node directory:
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.
For DB2 for OS/390 remote hosts, the hostname appears in the DSNL004I message (DOMAIN=hostname) when the Distributed Data Facility (DDF) is started.
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 Universal Database for OS/390 bootstrap dataset assigns a port number (RESPORT) to be used for resynchronization for inbound connections to DB2 Universal Database for OS/390 only. No service name need be defined for this. |
You can specify the following information in the DCS directory:
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.
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
LOCATION NAME is also defined in the MVS/ESA 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 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
LOCATION NAME is 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.
Format: AR <application_requester_name>
The default is the DB2 Connect application requester.
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. |
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 AS/400 database server, in order to process additional database requests. On platforms other than AIX V4.1 and later, SNA Server V3.1 and later, OS/2, Windows NT and Windows 2000, 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 Universal Database 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. |
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.
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. 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) 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.
For the date mask to be valid, ALL of the following must be true:
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:
Changing Your MVS Password shows an example of cataloging a dcs database directory using CHGPWD_SDN, as follows:
catalog dcs database db1 as dsn_db_1 parms
",,,,,,,CHGPWD_SDN=pempgm"
",,,,,,,,BIDI=xyz"
where xyz represents the CCSID override (see (BIDI_NOTE1)).
For a list of what BiDi CCSIDs are supported along with their string types, refer to the Administration Guide.
The following BiDi attributes are required for correct handling of BiDi data on different platforms:
Since defaults on different platforms are not the same, problems appear when DB2 data is sent from one platform to another. For example, Windows platforms use LOGICAL UNSHAPED data, while data on MVS and OS/390 is usually in SHAPED VISUAL format. Therefore, without any support for BiDi attributes, data sent from DB2 for MVS or OS/390 to DB2 Connect on Windows displays incorrectly.
When data is exchanged between DB2 Connect and a database on a server, it is usually the receiver that performs conversion on the incoming data. The same convention would normally apply to BiDi layout transformation also, which is in addition to the usual code page conversion. However, currently no host DB2 product supports BiDi-specific CCSIDs or BiDi layout transformation. Therefore, DB2 Connect has been enhanced with the optional ability to perform BiDi layout transformation on data it is about to send to the server database in addition to data received from the server database.
For DB2 Connect to perform BiDi layout transformation on outgoing data to a server database, the BiDi CCSID of the server database will have to be overridden (see (BIDI_NOTE2)). This is accomplished through the use of the BIDI parameter in the PARMS field of the DCS database directory entry for the server database.
The use of this feature is best illustrated with an example.
Consider a Hebrew DB2 client running CCSID 62213 (BiDi string type 5) and you would like to access a DB2 host database running CCSID 424 (BiDi string type 4). However, you know that the data contained in the DB2 host database is instead based on CCSID 8616 (BiDi string type 6).
There are two problems in this situation. The first is that the DB2 host database does not know the difference between the BiDi string types with CCSIDs 424 and 8616. The second problem is that the DB2 host database does not recognize the DB2 client CCSID of 62213. It only supports CCSID 862, which is based on the same code page as CCSID 62213.
You will need to make sure that data sent to the DB2 host database is in BiDi string type 6 format to begin with and also let DB2 Connect know that it has to perform BiDi layout transformation on data it receives from the DB2 host database. You will use the following cataloging for the DB2 host database:
catalog dcs database nydb1 as TELAVIV parms ",,,,,,,,BIDI=8616"
This tells DB2 Connect to override the DB2 host database CCSID of 424 with 8616. This override includes the following processing:
Notes:
If a specific bidirectional CCSID is causing problems which cannot be rectified by following these recommendations, then you should set the environment variable or registry value DB2BIDI to NO.
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, Windows NT, or Windows 2000:
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
|
You can specify the following information in the system database directory:
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.
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 host or AS/400 database 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.