StarQuest Technical Documents

Using a DSN-less Connection with StarSQL

Last Update: 05 February 2009
Product: StarSQL
Versions: 5.x
Article ID: SQV00SQ036

Abstract

This technical document describes how to create a StarSQL connection to DB2 that does not use a data source name (DSN). This type of connection is known as a DSN-less connection. The use of DSN-less connections eliminates the need to create ODBC DSNs in order to access the database server. 

Solution

A DSN-less connection string must contain all of the required connection parameters in order for StarSQL to connect to the DB2 system. The parameters that are required for TCP/IP connections differ from those required for SNA connections. The following table lists the required parameters for TCP/IP and SNA connections, respectively. Sample connection strings for both types of connections are provided later in the document.

The examples provided with this solution work with applications that use Microsoft RDO, ADO/RDS, and ODBC.NET data access technologies. 

Required Parameters for TCP/IP Connections

Parameter Name
Description
Driver

This value must be set to either:

  • StarSQL 32-bit: {StarSQL 32}
  • StarSQL 64-bit: {StarSQL (64-bit)}
Server
This value corresponds to the Database Server Name in a StarSQL DSN.
  • On DB2 for OS/390, the database server name is the Location Name in the Distributed Data Facility (DDF). You can get the Location Name by examining the DDF Communication record on the host.
  • On DB2/400, the database server name is the RDB or Relational Database Name. To find or create the relational database name, use the AS/400 command WRKRDBIRE on the host.
  • On DB2 UDB for Linux, UNIX, and Windows, the database server name is the Database Name.
  • On DB2 for VSE & VM the database server name is the Global Resource Name.
NetLib This value must be set to SWTCP32.DLL.
HostName
The host name refers to the TCP/IP server, which is the same as the host name of the database server. Use either a TCP/IP host name or an IP address in dotted decimal notation.
UID
Enter your username or authorization identifier for connecting to the database.
PWD
Enter your password for connecting to the database.

Required Parameters for SNA Connections

Parameter Name Description
Driver This value must be set to {StarSQL 32}. Note: StarSQL (64-bit) does not currently support the SNA networking protocol.
Server This value corresponds to the Database Server Name in a StarSQL DSN.
  • On DB2 for OS/390, the database server name is the Location Name in the Distributed Data Facility (DDF). You can get this by examining the DDF Communication record on the host.
  • On DB2/400, the database server name is the RDB or Relational Database Name. To find or create the relational database name, use the AS/400 command WRKRDBIRE on the host.
  • On DB2 UDB for Linux, UNIX, and Windows, the database server name is the Database Name.
  • On DB2 for VSE & VM the database server name is the Global Resource Name.
NetLib This value must be set to SWAPPCNT.DLL.
LocalLU
Specify the name of the local LU.
RemoteLU
Specify the name of the remote LU.
ModeName
Specify the mode name for the SNA session.
UID Enter your username or authorization identifier for connecting to the database.
PWD Enter your password for connecting to the database.

Optional Parameters for Both Types of Connections

There are many optional parameters that may be specified in a DSN-less connection string. To view a complete list of the available parameters and the valid values, create a StarSQL System or User DSN using the ODBC Data Source Administrator and review the Data Source Entry list on the Expert Page panel. With this panel active, click Help to display the topic that describes the optional parameters.

Following are some of the most commonly-used optional parameters:

Parameter Name Description
PkgColId Enter the location on the DB2 host of the packages required by StarSQL to execute Dynamic SQL. The default is STARSQL.
Port This parameter is only used for TCP/IP connections. The default is 446. Set this value only if your DB2 system listens for requests on a port other than 446.
CatFilters For the Catalog Filters you can select one or more (up to ten) qualifiers to restrict the amount of data retrieved by ODBC. Each filter must be within single quotes and separated by a comma, such as 'QAUSER','PRODUSER'.

Parameters that are not specified in the connection string use default values. Refer to the StarSQL Help for the default values that are used for the optional parameters.

DSN-less Connection String Examples

To construct a DSN-less connection string, create a string that contains the required and optional parameters with their appropriate values, each in the format of parameter=value. Each parameter=value pair must be separated by a semi-colon as shown in the below examples.

TCP/IP Example

The following strings will work with RDO, ADO/RDS, and ODBC.NET.  Use the Provider parameter only with ADO or RDS connections.

StarSQL 32-bit:

"Driver={StarSQL 32};Provider=MSDASQL;Server=DB2PROD;NetLib=SWTCP32.DLL;
HostName=db2host.company.com;Port=7446;PkgColID=STARSQL53;UID=db2user;PWD=secret"

StarSQL 64-bit:

"Driver={StarSQL (64-bit)};Provider=MSDASQL;Server=DB2PROD;NetLib=SWTCP32.DLL;
HostName=db2host.company.com;Port=7446;PkgColID=STARSQL53;UID=db2user;PWD=secret"

SNA Example

The following string will work with RDO, ADO/RDS, and ODBC.NET.  Use the Provider parameter only with ADO or RDS connections. Note: StarSQL (64-bit) does not currently support the SNA networking protocol.

"Driver={StarSQL 32};Provider=MSDASQL;Server=DB2PROD;NetLib=SWAPPCNT.DLL;LocalLU=MYSYS; RemoteLU=DB2PROD;ModeName=LU62STAR;CatFilters='QAUSER';UID=db2user;PWD=secret"


DISCLAIMER

The information in technical documents comes without any warranty or applicability for a specific purpose. The author(s) or distributor(s) will not accept responsibility for any damage incurred directly or indirectly through use of the information contained in these documents. The instructions may need to be modified to be appropriate for the hardware and software that has been installed and configured within a particular organization.  The information in technical documents should be considered only as an example and may include information from various sources, including IBM, Microsoft, and other organizations.