pajama

When installing a 32-bit IBM Informix Client SDK product on a 64-bit Windows machine, you may see a message stating that you cannot install becuase you are using a 64 bit machine.

The problem is due to the Windows redirection path not being included in your systems PATH environment variable setting.

Windows 64-bit machine

1. Open a Windows command window ('cmd')
2. run: "set PATH=C:\WINDOWS\SysWOW64\;%PATH%"
3. Run the setup.exe for IBM Informix Client SDK

"C:\windows\syswow64\odbcad32.exe" and look under the Drivers tab.

Using JDBC, we may get errors like -79784 (" Locale not supported.") or -908 ("Attempt to connect to database server NAME failed.") when trying to connect to a database using the following locale: ko_kr.cp_949

For example, the following connection:
jdbc:informix-sqli://myhost:ids_port/mydatabase:informixserver=myidsserver;user=mylogin;password=mypasswd;DB_LOCALE=ko_kr.cp_949;CLIENT_LOCALE=ko_kr.cp_949

might return error -79784 or -908 if used with JDK earlier than 1.6 and/or JDBC earlier than 3.50.JC8

When using JDBC, in order to be able to connect properly to a database using locale ko_kr.cp_949 you have to use JDK1.6 or later and JDBC 3.50.JC8 or later.

OAT is first bundled with CSDK in 3.70.xC4 fixpaks. This does not include the 64-bit CSDK 3.70.FC4 on Windows.

You can install the 32-bit OAT on a Windows 64-bit machine.

You currently have a typical en_us (US English) database, which is a normal, default style database with no extra intervention needed for the setup. You want to expand your company database into another country and use a multi-byte character set, or a different locale for the database. What is needed for the setup?

There are several issues to consider when setting up a database with a locale which is non-US. Here is an overview of the considerations, which are discussed below:

1. An understanding of code-sets and their impact on a database.
2. An understanding of default vs nondefault locale code-sets.
3. Unicode vs language code-set usage

Code-sets and their impact

An ASCII code-set is based on 128 printable characters that occupy 7 bits of a single byte representation. Some characters encoded in other languages can not be represented by a single byte value. one example of a multibyte code-set is the Japanese code set known as Kanji. The technical name is SJIS (ja_jp.sjis). It is a multibyte code-set, with characters that are encoded in 2 or 3 bytes. Some code-sets can have up to 4 bytes to represent a printable character. There are several issues to consider in using any code-set:

• Column info: With variations in number of bytes per character, a column size for non-integers in a table must be either CHAR or NCHAR (or VARCHAR vs NVARCHAR). How the data type is defined for the column will determine collation order.
  • CHAR data type follows code set order.
  • NCHAR data type follows collation order determined by DB_LOCALE, and can be single or multibyte.
  • LVARCHAR can be single or multibyte and can hold data in the code set of the client or database locale -- if you write the input and output support functions to interpret the LVARCHAR data in the correct locale.
  
  

A default code-set is relative to the language base in which is is used. Some languages have the same letter characters as English, but they also have character variations. The character variations cause the result that some code-sets are nondefault.. Some considerations for default and nondefault code-sets:

• Default code-sets depend on the platform, and allow for character variations. If your database connects with another default code-set , it is automatically supported.
• Nondefault code-sets may or may not support default code-sets. If your database connects with a nondefault code-set it may or ay not work correctly. Nondefault locales that will work with the default english UNIX code-set (8859-1) include British English (en_gb.8859-1), French (fr_fr.8859-1), Spanish (es_es.8859-1), and German (de_de.8859-1).
• Nondefault locales, such as Japanese SJIS (ja_jp.sjis), Korean (ko_kr.ksc), and Chinese (zh_cn.gb), contain multibyte code-sets. (The unified Chinese code-set is GB18030-2000.)
• When locales between client and server are nondefault locale, data movement can be complex. Characters may not have a mapped equivalent between client and server at the time of transfer. In some cases, the inserting of a nondefault character into a different locale could mean that the result is not going to display correctly, or it may have an incorrect character substitution. Informix Servers support only one locale per database. When words are transliterated to a different locale the process is handled by a conversion object (.cvo) file. Note that this can only happen if appropriate rules, locales, and .cvo files are present. See the IBM Informix GLS User's Guide (GLS=Global Language Service) for more information in the section Performing Code Set Conversion.
• Unicode code-sets permit much greater flexibility. Rather than using a single standard for each language, Unicode provides a unique number representation for every character, no matter what the platform, program, or language. If you want a database that handles 2 or more locales at the same time, you will want to use a Unicode locale. As an example, Unicode sets for English and European languages are mostly UTF-8 (Unicode, 8 bit). Some Asian locales are UTF-16, and some code-sets have allowances for UTF-32. Informix Servers only work with UTF-8.
• Collation order refers to the concept of how printable characters for the code-set will be arranged for sorting and index purposes. The default locale will determine how things will be arranged in terms of sorting. When Unicode is in use, GLS for Unicode (GLU) is a feature that allows your application to use the International Components for Unicode (ICU) libraries instead of the usual GLS libraries. The main advantage of using the ICU libraries is that they take the locale into account when collating Unicode characters, the GLS libraries do not. To force use of GLS library collation, set GL_USEGLU=1 in the client and server environment, or compile your application using the -glu option with the esql command. For more information on compiling, see the ESQL/C Programmers Guide.

• If you want an entire software instance in a specific language, set the OS environment variable (LANG) for your specific language first. For example, when prompted, a user can specify the French language as spoken in Canada during the installation process. The code set automatically defaults to the ISO8859-1 code-set. With this information, the system sets the value of the default locale, specified by the LANG environment variable, to fr_CA (fr for ISO8859-1 French and CA for Canada). Every process uses this locale unless the LC_* or LANGenvironment variables are modified. (Note: The default locale assumes 7 bit ASCII character set, however, Extended Parallel Server (XPS) rejects any filename usage that is not 7 bit ASCII.)
• The available code-sets are in the $INFORMIXDIR/gls directory. Many additional languages, especially UTF-8 language sets, are included in the International Language Support (ILS) product, available as a separate purchase.
• There are 3 environment settings needed for any change in locale: CLIENT_LOCALE, DB_LOCALE, and SERVER_LOCALE.
• The setup steps for using different languages and code-sets is documented in the

PROBLEM

Shadow passwords are not supported in either IBM® IDS versions 7.31 or 9.40. This operating system enhancement is not available until the release of HP-UX® 11i (11.11), and for purposes of backward compatibility IDS 7.31 and 9.40 are ported to earlier releases of HP-UX 11. 


SCOPE

The following products and operating systems are affected:

• Use Trusting Computing Based (TCB) as an alternative password shadowing scheme.
• Upgrade to IBM® Informix® Dynamic Server™ version 10

• During connection establishment, the IP address of the client is used by the IDS server to look up its host name. The method used to accomplish this is dependent on the configuration of the operating system. If the Domain Name System (DNS) is used, an operation known as a reverse query is used to map the IP address to host name. If the configuration of the DNS server is incomplete this type of query may take some time.
  
  The command line utility nslookup may be used to perform DNS queries. If a reverse lookup operation takes a long time to complete using nslookup then the IDS server will also take a long time to complete the same operation.
  
  The first example shows a reverse lookup operation for an IP address that is known to the DNS server and completes immediately. The second example uses an IP address that is unknown taking several seconds before returning an error.
  
  C:\>nslookup 1.2.3.4
  Server:  host1.domain.com
  Address:  9.8.7.6
  
  Name:    host222.domain.com
  Address:  1.2.3.4
  
  C:\>nslookup 9.69.1.126
  Server:  host1.domain.com
  Address:  9.8.7.6
  
  DNS request timed out.
  timeout was 2 seconds.
  *** Request to host1.domain.com timed-out

• The lookup for the service name could be taking a while.

• Another cause may by the use of IPv6 addresses with DNS servers that are not configured for IPv6.

To isolate the problem to tcp/ip connections try to connect by way of a shared memory connection. If the connection is now completed quickly then the problem outlined above may be the cause of poor connection performance.

Follow this link if you need instructions for setting up shared memory connections:
A shared-memory connection (UNIX)

• Refer to your operating system documentation for details of how to configure DNS. If the DNS server runs on the Microsoft Windows® platform then it is possible that the zone used to implement reverse lookup is not implemented. Details regarding DNS on the Windows operating system can be found in the related URLs below. Ensure that the reverse-lookup zone is populated for all clients that connect to the IDS server.
  
• Ensure that local hostname resolution is performed before other methods of hostname resolution (NIS, NIS+, DNS, and so on). Files like these are used on various operating systems to determine lookup order:
  
  /etc/netsrv.conf
  /etc/irs.conf
  /etc/nsswitch.conf
  
• Reconfigure your operating system to not use DNS, for example by including the host names and IP addresses of all client machines in the local hosts file /etc/hosts or %WINDIR%\system32\drivers\etc\hosts on Windows.

• Change the host name in the sqlhosts file to an IP address.
  
• Change the service name in the sqlhosts file to the port number.
  
• Connections to IDS hang

Transactions are able to continue working during checkpoints. To avoid blocked transactions,the database server must have enough physical log space to contain all of the transaction activity that occurs during checkpoint processing. Checkpoints can be triggered when the physical log is 75 percent full and checkpoint processing must complete before the remaining 25 percent of the physical log is used. Transaction blocking occurs as soon as the system detects a potential for a physical log overflow, because every active transaction could generate physical log activity.

The optimal size of the physical log depends on two factors:

1.The rate at which transactions generate physical log activity.

[1]Buffer Pool Space less than 4G.
For systems with less that four gigabytes of buffer pool space, the physical log can
be sized at 110 percent of the combined size of all the buffer pools.

[2]For larger buffer pools (Commonly larger than 4G)
Start with four gigabytes of physical log space and then monitor checkpoint activity. If checkpoints occur too frequently and appear to impact performance, increase the physical log size,and look into the Trigger column of the onstat -g ckp output. If the trigger events occur frequently by PLOG, then increase the size of the physical log.

2.Whether or not you set the RTO_SERVER_RESTART configuration parameter.

If RTO_SERVER_RESTART is enabled, the physical log size must be less than all buffer pools to maintain the RTO_SERVER_RESTART policy.

INTRODUCTION

The Scheduler is a component of IBM Informix® Dynamic Server™ (IDS) that executes tasks defined in the sysadmin database. These tasks are coordinated by the dbScheduler and dbWorker threads within the server. There may be occasions when it is required to prevent the startup of these threads, for example if an assert failure occurs during initialization of the server. This article describes a method to temporarily prevent the startup of the threads used by the Scheduler.


STEPS

1. As the root or informix user create the empty file $INFORMIXDIR/etc/sysadmin/stop. one way to do this is to use the Unix command touch.
2. Stop and restart IDS.
3. During initialization the following message will appear in the message log:

SCHAPI: "INFORMIXDIR/etc/sysadmin/stop" file is present.
Bypassing dbScheduler and dbWorker threads startup.