Dec 10, 1997

    Fixed a pair of errors which resulted in the infamous
      "DBI Handle has uncleared implementors data" on finishing
      statements prior to disconnect.

NOTE:  For UDB EEE users ************************************ 

In DB2 CLI Version 5, deferred prepare is on by default. This is
the EXACT opposite of DB2 CLI Version 2. The PREPARE request is 
not sent to the server until the corresponding execute request 
is issued. The two requests are then combined into one command/reply 
flow (instead of two) to minimize network flow and to improve 
performance. This is of greatest benefit when the application 
generates queries where the answer set is very small, and the 
overhead of separate requests and replies is not spread across 
multiple blocks of query data. In an environment where a 
DB2 Connect or DDCS gateway is used, there is a greater opportunity 
for cost reduction because four request and reply combinations are
reduced to two. 
     
DB2 CLI Version 2 applications that expect the PREPARE to be 
executed as soon as it requested may not operate as expected. (An 
application may, for instance, rely on the row and cost estimates 
that are normally returned in the SQLERRD(3) and SQLERRD(4) of the 
SQLCA of a prepare statement; with deferred prepare, these values 
may become zeros.) To ensure these programs work as they did with 
Version 2, the DB2 CLI/ODBC configuration keyword DEFERREDPREPARE 
can be set to disable deferred prepare. See "DEFERREDPREPARE"
for more information. 
     
The statement attribute SQL_ATTR_DEFERRED_PREPARE can also be used 
to force DB2 CLI to prepare the statement as soon as it is issued. 
See the attribute in SQLSetStmtAttr - Set Options Related to a 
Statement for more information. 
     
In version 2, a DB2 CLI application could use the function
SQLSetColAttributes() to reduce network traffic by describing
the result descriptor information for every column in the result 
set. With deferred prepare this is no longer of any benefit,
and the SQLSetColAttributes() function has been deprecated. If your
application does call this function it will ignore all arguments, 
and will always return SQL_SUCCESS. 

With Thanks to "Colin Ruthven"<colin_ruthven@smb.com> for the
research on UDB EEE     
****************************************************************************
Caveats:
    DBD::DB2 assumes the following:
        1.  That the DBD::DB2 is built against
            DB2 v2.1.0 or higher (AIX/UNIX, OS/2 versions)

        2.  DB2 is installed in /usr/lpp/db2_02_01
            or DB2_HOME points to the installed location

        3.  That the following have been exported in the current
            environment:

            export DBI_DRIVER=DB2
            export DBI_NAME="instance"  where "instance" is the DB2
                                        instance name

    Immediately prior to calling $sth->execute() you must call
    $sth->bind_param(index, name, type_hash_ref).   Note, that a
    minimal set of type_hash_refs are provided by DB2.pm and they
    may be used to create new type_hash_refs
        $new_type = { %$existing_type, 'Stype' => SQL_"NewTYPE" };

    Fetching of CLOB and DLOBS is not currently supported.

    Fetching any type of blob directly to a file is not implemented.
   
    Writing of blobs is currently unsupported ( It doesn't work...yet).

    All requested columns are returned.  So if you don't want the
    column, don't ask for it.
