StarQuest Technical Documents

How to Report a StarSQL ODBC Driver for UNIX Problem

Last Update: 26 February 2015
Product: StarSQL
Version: All
Article ID: SQV00SU002

Abstract

Before you report a problem to StarQuest Customer Support, review the StarQuest Customer Support knowledge base because it may have the answer you need. There are many technical documents that address common problems and provide helpful suggestions and sample code.

Before contacting StarQuest Customer Support, collect as much information as you can about the problem. By sending in a complete problem description, you can help expedite finding a solution to your problem.

This article describes how to find the information you need to report a StarSQL ODBC Driver for UNIX problem and a few additional steps that you can do to help the Customer Support staff better serve your requests.

Solution

Step 1: Locate the StarSQL for UNIX Version.

To find the StarSQL for UNIX driver version, change to the lib directory in the /starsql or /starsql64 directory (e.g., /opt/starsql/lib) and run one of the comamnd below.

  • On Solaris, Linux or FreeBSD run the command to display the exact version:

strings - libSWODBC.so | grep "^5\."

On HP-UX run the command to display the exact version:

strings - libSWODBC.sl | grep "^5\."

On AIX run the command to display the exact version:

strings - libSWODBC.a | grep "^I5\."

If you have a working connection to the database, you can also run the starping, simpleconn, or simpleconn.odbc sample application to display the driver version in the output.

Step 2: Gather StarSQL for UNIX Data Source Configuration Information.

  1. Locate the data source configuration file.

For user data sources: The .odbc.ini in the user's home directory contains the data source configuration.

For system data sources: Run odbcinst -j to determine the location of the odbc.ini with the system data sources.

  1. Make a copy of this file to send to StarQuest Customer Support.

Step 3: Record Environment Configuration.

The environment configuration information will help us to understand how StarSQL is used in your environment. The configuration is divided into three layers: client, network, and host.

  1. For the client, collect the following information:
  • Operating system (e.g., SUSE Linux Enterprise 10, Solaris 10).
  • The application and version that you are using with StarSQL for UNIX (e.g., Informatica v. 7). If it is a custom application, specify what tools were used to build it (e.g., Perl, PHP). If this is a Web application, note the Web server type and version (e.g., Apache 2.0).
  • Whether the application is 32-bit or 64-bit.
  • The environment variables for the StarSQL user (e.g., $PATH, $LD_LIBRARY_PATH, etc.).
  • A list of shared libraries obtained by running the UNIX ldd (or equivalent) command.
  1. For the network, note the network protocol used with your StarSQL for UNIX data source. In most cases, it will be TCP/IP. If connecting through a StarPipes gateway to a Host Integration or SNA Server, please note the StarPipes version as well as the Host Integration/SNA Server version and service pack level.
  1. For the DB2 host, record the DB2 software version and the operating system and its version. The most common choices are:
  • DB2 for z/OS 9, 10, 11
  • IBM i v5r4, 6.1, 7.1, 7.2 . In addition, use GO PTF, option 12 - Work with PTF Groups (WRKPTFGRP) to display the levels for Cumulative PTF Package, Group HIPER, and DB2 for i groups. (Use F11 to change the displayed information).
  • DB2 Universal Database for Linux, UNIX and Windows 9.7, 10.1, 10.5 (include fix pack level). Type db2level at a command prompt to obtain this information.

Step 4: Describe Symptoms of Problem and Reproduction Scenario.

When you describe the problem, keep in mind the following questions:

  • Is this a new problem? If yes, what has changed recently?
  • Can this problem be reproduced? If so, what is the reproduction scenario?
  • What are the symptoms of the problem? Is it an empty result set when data is expected, an unexpected error message, a crash in the application, or is the application not responding? If there is an error message, write it down exactly as it appears or capture a screen shot of it.
  • If you are experiencing an error related to StarSQL licensing, please provide the type of license being used (e.g., node-locked client license or StarLicense server license).

Step 5: Collect Traces.

Trace data can greatly expedite the problem resolution process. There are two types of traces that can be collected, ODBC and DRDA. However, the ODBC trace can only be captured if the application uses an ODBC driver manager such as unixODBC or the DataDirect driver manager. ODBC and DRDA tracing can be enabled at the same time, and we request that you provide both types of traces whenever possible.

  1. Create an ODBC trace.
    • For unixODBC, set the following in /usr/local/etc/odbcinst.ini:

      [ODBC]
      Trace = 1
      Trace File = /tmp/sql.log
  • For DataDirect, in the [ODBC] stanza of .odbc.ini, set Trace = 1, and set TraceFile & TraceDLL to appropriate values. For example:

    [ODBC]
    Trace = 1
    TraceFile = /tmp/sql.log
    TraceDll = /opt/odbc/lib/odbctrac.so

In both examples, a trace file will be created in /tmp/sql.log. Be sure to turn off the trace feature when it is no longer needed by setting the Trace value to 0. 

  1. Create a DRDA trace.
    • Verify that you have .swodbc.ini file in the user's home directory and that it is writable. For example: $ cp $STARSQL/etc/swodbc.ini .swodbc.ini $ ls -l .swodbc.ini $ chmod 644 .swodbc.ini
    • Execute this command to enable tracing:

      $ trcstart -on /tmp/mytrace.sqd

      After collecting the trace, turn off tracing:

    $ trcstart -off

If the application or application server generates its own log files or trace data, please include those in the problem report.

Step 6: Collect StarLicense information:

If a licensing issue is involved, please collect the following information:

  • Include a copy of /etc/starlicense.rc
  • Collect StarLicense server logs, client logs, and journal logs:
    1. Edit the Global section of /etc/starlicense.rc

    [Global]
    ServerLogLevel=FFFFFFFF
    ClientLogLevel=FFFFFFFF
    JournalLevel=3

    or enter

    # cd /opt/starlicense
    (or /usr/lpp/starlicense for AIX, /usr/share/starlicense for Linux, etc.)
    # ./starlic-admin server-loglevel-set FFFFFFFF
    # ./starlic-admin client-loglevel-set FFFFFFFF
    # ./starlic-admin server-journallevel-set 3

    1. Stop and restart the StarLicense service (e.g. using the /opt/starlicense/configure menu).
    2. After collecting logs and journals, set the parameters back to their original values and restart the StarLicense service.

A log level of FFFFFFFF turns on all logging. The log files are created in /tmp with the filename format starliccli.<processID>.log for the client and starlic.log for the server. Refer to the StarLicense Server for UNIX User's Guide for more information.

JournalLevel 3 captures both server and client statistics. The journal is created with a filename of YYYY-MM-DD.jrn and stored in the /var/tmp directory. Refer to the StarLicense Documentation Addendum for details about the journal logs.

Step 7: Contact StarQuest Customer Support.

To open a problem report with StarQuest Customer Support, go to http://support.starquest.com, and include the following information:

  • Company/Organization name
  • Your name, email address, and contact phone number
  • All information gathered in Steps 1 - 5.  Any attachments, such as traces or data source configuration files, should be compressed into a single archive file before sending.
  • Indicate whether or not this problem affects a production environment.

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.