Informix To DB2 Migration White Paper

Informix to DB2 Migration
Comparison White Paper
Software Migration Project Office

DB2 Migration Team
www.ibm.com/solutions/softwaremigration
Informix to DB2 Migration - Comparison White Paper IBM
Table of Contents
INTRODUCTION ........................................................................................................................................ 1
WHY MIGRATE TO DB2 UDB ? .............................................................................................................. 2

INTEGRATED SUPPORT FOR WINDOWS NT................................................................................................... 2
INTEGRATED SYSTEM MANAGEMENT TOOLS .............................................................................................. 2
DATA REPLICATION..................................................................................................................................... 4
INTEGRATED WEB ACCESS.......................................................................................................................... 4
INTEGRATED SUPPORT FOR COMPLEX DATA ............................................................................................... 4
INTEGRATED SUPPORT FOR DEVELOPMENT ENVIRONMENTS ...................................................................... 5
IBM SOLUTION DEVELOPER PROGRAM ...................................................................................................... 5
DB2 UNIVERSAL DATABASE PRODUCT FAMILY............................................................................ 6
DB2 UNIVERSAL DATABASE PERSONAL EDITION ....................................................................................... 7
DB2 UNIVERSAL DATABASE WORKGROUP EDITION................................................................................... 7
DB2 UNIVERSAL DATABASE ENTERPRISE EDITION .................................................................................... 7
DB2 UNIVERSAL DATABASE EXTENDED ENTERPRISE EDITION .................................................................. 7
DB2 SOFTWARE DEVELOPER'S KIT (DB2 SDK) ......................................................................................... 8
DB2 UDB AND INFORMIX DIFFERENCES OVERVIEW ................................................................... 9
HIGH LEVEL DIFFERENCES .......................................................................................................................... 9
DATABASE ENGINES .................................................................................................................................... 9
DB2 Universal Database DB2 UDB ...................................................................................................... 9
DB2 Tools............................................................................................................................................. 10
Additional DB2 servers......................................................................................................................... 10
Informix ................................................................................................................................................ 10
Informix Web Integration Option ......................................................................................................... 10
CLIENT CONNECTIVITY ............................................................................................................................. 11
APPLICATION DEVELOPMENT SUPPORT ..................................................................................................... 11
SQL EXTENDERS....................................................................................................................................... 12
GATEWAYS ................................................................................................................................................ 12
WEB SUPPORT ........................................................................................................................................... 13
DATA WAREHOUSING ............................................................................................................................... 13
DATABASE ADMINISTRATION ........................................................................................................... 14
ARCHITECTURE ......................................................................................................................................... 14
DB2 UDB.............................................................................................................................................. 14
Informix ................................................................................................................................................ 14
OPTIMIZERS ............................................................................................................................................... 15
DB2 UDB.............................................................................................................................................. 15
Informix ................................................................................................................................................ 15
PARALLELISM ............................................................................................................................................ 15
Intra-Parallelism .................................................................................................................................. 16
Inter-Parallelism .................................................................................................................................. 16
BUFFERPOOL MANAGEMENT ..................................................................................................................... 17
DB2 UDB.............................................................................................................................................. 17
Informix ................................................................................................................................................ 17
STORAGE MANAGEMENT........................................................................................................................... 17
DB2 UDB.............................................................................................................................................. 17
Informix ................................................................................................................................................ 18
© IBM Corporation Page i

CONFIGURING AND CONNECTING CLIENTS ............................................................................................... 18

DB2 UDB.............................................................................................................................................. 18
Informix ................................................................................................................................................ 19
EMBEDDED SQL DEVELOPMENT............................................................................................................... 19
DB2 UDB.............................................................................................................................................. 19
Informix ................................................................................................................................................ 19
CONCURRENCY ......................................................................................................................................... 20
Isolation Levels..................................................................................................................................... 20
Locking ................................................................................................................................................. 21
SECURITY .................................................................................................................................................. 22
DB2 UDB.............................................................................................................................................. 22
Informix ................................................................................................................................................ 22
ACCESS PATHS .......................................................................................................................................... 23
Clustering/Clustered Index................................................................................................................... 23
PCTFREE/FILLFACTOR..................................................................................................................... 23
LOGGING, BACKUPS AND RECOVERY ........................................................................................................ 24
DB2 UDB.............................................................................................................................................. 24
Informix ................................................................................................................................................ 26
MOVING AND MANAGING DATA ............................................................................................................... 28
DB2 UDB.............................................................................................................................................. 28
Informix ................................................................................................................................................ 29
REPLICATION ............................................................................................................................................. 31
DB2 UDB.............................................................................................................................................. 31
Informix ................................................................................................................................................ 31
INFORMIX TO DB2 MIGRATION CHECKLIST ................................................................................ 32
THE SERIAL DATATYPE ......................................................................................................................... 32
LOB DATATYPES ...................................................................................................................................... 32
MONEY DATATYPE ................................................................................................................................. 32
INTERVAL DATATYPE ............................................................................................................................ 32
DATE/TIME DATATYPES......................................................................................................................... 32
TYPEDEFS .............................................................................................................................................. 32
OUTER JOINS ............................................................................................................................................. 33
STORED PROCEDURES CALLING OTHER STORED PROCEDURES................................................................. 33
TRIGGERS CALLING STORED PROCEDURES ............................................................................................... 33
STORED PROCEDURE CALLED FROM A SELECT LIST ................................................................................ 33
MATCHES PREDICATE ............................................................................................................................... 33
TEMPORARY TABLES ................................................................................................................................. 33
SELECT UNIQUE ...................................................................................................................................... 33
PAGE LOCKING .......................................................................................................................................... 33
ISOLATION LEVELS .................................................................................................................................... 33
CR ISOLATION LEVEL ............................................................................................................................... 33
STORED PROCEDURES ............................................................................................................................... 33
OPEN CURSOR WITH HOLD...................................................................................................................... 34
UPDATEABLE SCROLLABLE CURSORS ....................................................................................................... 34
DYNAMIC SQL .......................................................................................................................................... 34
FRAGMENTATION ...................................................................................................................................... 34
APPLICATION DEVELOPMENT AND SQL DIFFERENCES........................................................... 35
DATA TYPES CONVERSION ........................................................................................................................ 35
INTERVAL DATA TYPE .............................................................................................................................. 35
SERIAL DATA TYPE ................................................................................................................................... 35
HOST VARIABLES DECLARATION .............................................................................................................. 36
OUTER JOINS ............................................................................................................................................. 36
© IBM Corporation Page ii

SELECT UNIQUE ................................................................................................................................... 37

BUILT-IN FUNCTION .................................................................................................................................. 37
EMBEDDED STATIC AND DYNAMIC SQL ................................................................................................... 37
COMPOUND SQL ....................................................................................................................................... 37
CLI/ODBC................................................................................................................................................ 38
JAVA DATABASE CONNECTIVITY (JDBC) ................................................................................................. 38
TRIGGERS .................................................................................................................................................. 38
ERROR HANDLING ..................................................................................................................................... 38
STORED PROCEDURES ............................................................................................................................... 38
CALLING DB2 STORED PROCEDURE FROM CLIENT APPLICATIONS........................................................... 39
INSTALLATION OF A STORED PROCEDURE ................................................................................................. 41
CONVERTING INFORMIX STORED PROCEDURES TO DB2........................................................ 42
DB2 UDB STORED PROCEDURE OVERVIEW ............................................................................................. 42
THE CLIENT PROGRAM .............................................................................................................................. 42
THE SERVER PROGRAM ............................................................................................................................. 44
INSTALLING A STORED PROCEDURE .......................................................................................................... 45
STORED PROCEDURE DIFFERENCES............................................................................................... 47
EXAMPLE OF CONVERTED STORED PROCEDURE ....................................................................................... 49
EXAMPLE OF CLIENT PROGRAM CALLING A DB2 STORED PROCEDURE.................................................... 51
TRADEMARKS ......................................................................................................................................... 53
© IBM Corporation Page iii

Introduction
DB2® Universal Database (DB2 UDB) can help improve the performance of database
applications. Many solution developers have already chosen DB2 UDB as their primary
development database environment, and have ported and continue to enable
applications to it to take advantage of its unique features.
DB2 UDB is a true cross-platform DBMS, running on a wide variety of systems including
Windows NT and 95, Solaris, HP-UX, AIX®, SCO UnixWare and OS/2®. It scales from
single-processor workstations or servers, to symmetrical multiprocessor (SMP) servers,
and on up to massively parallel processing (MPP) computers.
A real database leader in several technologies, it provides integrated support for complex
data such as text documents; images; video and audio clips; integrated Web access
through native support for Java, JDBC, SQLJ and Net.Data; integrated system
management tools; and data replication service.
This paper highlights the differences between the Informix Dynamic Server 7.3 and DB2
Universal Database (UDB) V5.2. DB2 UDB is now at version 6.1 and an updated version
of this paper is being prepared and will be available at a later date.
The document is divided into two sections:
• Product Overview
• Database Administration
Note: All the information contained in this document is based on publicly available
information and is subject to change. IBM® disclaims all warranties as to the accuracy,
completeness, or adequacy of such information. IBM shall have no liability for errors,
omissions or inadequacies in the information contained herein or for interpretations
thereof.
© IBM Corporation Page 1

Why Migrate to DB2 UDB ?
DB2 UDB is a database leader in several technologies, and offers true multi-platform
support and scalability. The same database is able to mix workloads on a single server.
The DB2 UDB design handles workloads from high-volume online transaction processing
(OLTP) to complex multi-user queries while maintaining excellent performance.
On December 1, 1998, the IBM Personal Systems Group and the IBM Software Group
published a 100GB TPC-D benchmark (Transaction Processing Performance Council
Benchmark D) using DB2 UDB 5.2.0 under Windows NT on an IBM Netfinity 7000 M10
server with four Pentium II Xeon 400 MHz processors. This benchmark achieved a multi-
user throughput result of 831.2 QthD@100GB, a price/performance result of
$130/QphD@100GB, and a power result of 3450 QppD@100GB. It has also since been
published by TPC.
In addition to affordability and performance, DB2 UDB offers the following advantages:
• Integrated support for Windows NT

• Integrated system management tools
• Data replication service
• Integrated Web access
• Integrated support for complex data
• Integrated support for development environments
• IBM solution developer program
Each of these is described in detail below.
Integrated support for Windows NT
DB2 UDB conforms to Windows NT standards. It maps closely onto Windows NT

internals for performance, and scales across all Windows NT hardware. It uses native
Windows NT threads, and its architecture relies on Windows NT for task dispatching and
other internal operating system functions. All these considerations make it more reliable
and more tightly integrated to the operating system.
Integrated System Management Tools
DB2 administration tools allow users to perform database administration tasks for DB2
UDB servers that are available locally or remotely. The Control Center (Figure 1) is a
graphical interface that can be used to perform server administrative tasks such as
configuring, backing up and recovering data, managing directories, scheduling jobs and
managing media, as well as accessing and manipulating databases. This tool can be
installed on OS/2, Windows NT, or Windows 95/98 workstations.

The Control Center provides the following additional facilities to manage DB2 UDB
servers:
• Command Center, to enter DB2 commands and SQL statements in an interactive

window and see the execution output in a result window.
• Script Center, to create scripts, which can be stored and invoked at a later time.
These scripts can contain DB2 commands, SQL statements and operating system
commands. Scripts can be scheduled to run unattended, in which case they are
called jobs. Jobs can be scheduled to run once only, at a later date or at regular
intervals (for tasks such as backups).
• Journal, to view all available information in the history and alter a message in the log
files about jobs that are pending, being executed or completed. It can also be used to
review the results of unattended jobs.
• Alert Center, to monitor the system for early warnings of potential problems or to
automate actions to correct problems that are discovered.
• DB2 Performance Monitor, to monitor the performance of a DB2 system and to
create snapshots of data over a period of time or data for a particular event, which
can be used to monitor activities.
• Visual Explain, to graphically analyze and tune SQL statements, as well as analyze
query access plans.
• SmartGuides, to help perform administration tasks. For example, a SmartGuide is
available to help tune the performance of the database server.
• The Web Control Center, the Java version of the DB2 UDB Control Center. The
Web Control Center is implemented as a Java applet that uses DB2 JDBC support.
Currently, the Web Control Center requires Netscape Navigator 4.04 for Windows 95
or Windows NT, and the JDK 1.1.4 patch for Navigator 4.04.
Figure 1 Control Center Main Window

Data Replication
DB2 UDB includes a complete data replication solution by supporting sources and targets
that include the DB2 family, IMS, VSAM, Oracle, Sybase, Microsoft, Lotus Notes, and
others to ensure timely, reliable, and consistent data across an enterprise. IBM offers the
following data replication tools:
• IBM Replication – the DataPropagator® Relational Version 1 (DPROPR V1) products
have been updated for Version 5 (V5) of the DB2 database.
• DB2 Universal Database V5 replication tools – the Control Center replication

administration features and the Capture and Apply programs.
• IBM Capture and Apply for MVS V5.1
• Capture for VSE and VM V5.1 – integrated with IBM DB2 Server for VSE and VM
V5.1.
• DPROPR V1 for support of DataJoiner
• DataPropagator Relational Capture and Apply for OS/400 V3.1
• IBM DataPropagator NonRelational
• IBM DataJoiner®
• Lotus NotesPump
Integrated Web Access
DB2 UDB provides web access to enterprise data on DB2 databases through native
support for Java, Java Database Connectivity (JDBC), Embedded SQL for Java (SQLJ)
and Net.Data®.
JDBC can be used to create applications or applets that access data in DB2 databases.
These applets can be run inside HTML web pages on any system with a Java-enabled
browser, independent of the client’s platform. The processing of JDBC applets is shared
between the client and the server.
DB2 SQLJ support facilitates the creation, building and running of SQLJ programs
against DB2 UDB databases.
DB2 Net.Data enables application developers to create Internet applications that access
data from DB2 databases, are stored on a web server and are viewable from any web
browser. While viewing these documents, users can either select automated queries or
define new ones that retrieve the specified information directly from a DB2 UDB
database.
Integrated Support for Complex Data
DB2 Universal Database Extenders allow storage and manipulation in the database of
nontraditional data such as images, video, voice, complex documents, spatial objects and
more. All these data types can be brought together in one SQL query and can then be
manipulated with powerful built-in functions.

Each extender defines a new type of data in DB2 UDB by using built-in support for user-
defined types and user-defined functions. Each extender also exploits DB2 Version 5
support for large objects of up to 2 gigabytes, and uses DB2 triggers to ensure referential
integrity of image data.
The DB2 Extenders exploit the DB2 client/server model. Supported platforms are AIX,
OS/2, Windows NT, HP-UX and Solaris Operating Environment.
Integrated Support for Development Environments
DB2 provides a Software Developer's Kit (SDK) that contains a collection of tools
specially designed for database application developers. The DB2 SDK includes libraries,
header files, documented Application Programming Interfaces (APIs) and sample
programs to build database applications.
IBM Solution Developer Program

The IBM Solution Developer Program provides business, technical and marketing
services to partners to help them develop and market applications. The strategic focuses
of this program are network computing and e-business.
Benefits offered by this program include the following:
• Hardware and software discounts, equipment lease and loaner programs and
business discounts to reduce development costs
• On-site and remote access to fully equipped testing and porting facilities at full-
service IBM Solution Partnership Center (SPC) locations around the world
• Exclusive, focused development support
• Examples of how to interface with and exploit the newest technologies
• Technical information based on actual development experience in the form of
“Frequently Asked Questions” and “Hints And Tips”
• The IBM Developer Connection, which is loaded with development tools, software
and late-breaking news from IBM
• The Global Software Solutions Guide, an online catalog providing worldwide
exposure to new customers for partners' solutions
• In-depth technical seminars and hands-on workshops
• Partners In Development specialty areas, with specialized technical, business,
marketing and information services for areas of expertise
• A technical library, complete with the latest white papers, road maps and a calendar
of upcoming events
• The IBM Solution Developer Program worldwide web site,
http://www.developer.ibm.com/, which is a dynamic, 24-hour, 7-day-a-week service
that provides information about all services.

DB2 Universal Database Product Family
The DB2 product family scales through a variety of platforms: AS/400® systems, RISC
System/6000® hardware, IBM S390 systems, Intel systems and non-IBM machines from
Hewlett-Packard and Sun Microsystems. Figure 2 provides a pictorial representation of
the DB2 UDB connectivity.
DB2 UDB version 5.2 database software servers run on the following software
environments: AIX, HP-UX, OS/2, SCO UnixWare, SINIX, Linux, Sun Solaris, Windows
NT, Windows 98 and Windows 95.
Client access is provided for all these platforms, as well as for DOS, Apple MacOS, and
Silicon Graphics IRIX. In addition, web access is provided with popular browsers and
Java applications using DB2's native Java/JDBC support and Net.Data.
Figure 2 DB2 UDB Connectivity

The DB2 UDB products and components include:
• DB2 Personal Edition

• DB2 Workgroup Edition
• DB2 Enterprise Edition
• DB2 Extended Enterprise Edition
• DB2 Software Developer’s Kit
DB2 Universal Database Personal Edition
DB2 Universal Database Personal Edition allows for the creation and use of local
databases. It also allows access to remote relational databases when they are available.
This product is available for the OS/2, Windows NT, and Windows 95 operating systems.
DB2 Universal Database Workgroup Edition
The DB2 Universal Database Workgroup Edition server enables local clients, remote
clients and applications to create, update, control and manage relational databases using
Structured Query Language (SQL), ODBC, or CLI. It contains all the latest DB2® Client
Application Enablers, which enable client workstations to access the DB2 UDB server
and all supported DB2 Net.Data products.
DB2 Universal Database Enterprise Edition
The DB2 Enterprise Edition includes all functions provided in the DB2 Workgroup Edition,
plus DB2® Connect Enterprise Edition to allow support for host connectivity. This
provides multi-user access to DB2 databases residing on host systems such as
MVS/ESA, OS/390, AS/400, VM, and VSE. The DB2 Enterprise Edition supports
unlimited LAN database access.
DB2 Universal Database Extended Enterprise Edition
DB2 Universal Database Extended Enterprise Edition (formerly known as DB2 Parallel
Edition) enables a database to be partitioned across multiple independent computers of a
common platform. SQL operations and utilities can operate in parallel on the individual
database partitions. Performance is enhanced by speeding up the execution time of a
single query or utility.

DB2 Software Developer's Kit (DB2 SDK)
DB2 SDK is a collection of tools that enable database application developers to build
character-based, multimedia or object-oriented applications. It includes libraries, header
files, documented APIs and sample programs.
The DB2 SDK can be used to develop applications that use the following interfaces:
• Embedded SQL, both static and dynamic

• Call Level Interface (CLI) development environment (compatible with ODBC from
Microsoft)
• Java Database Connectivity (JDBC)
• Application programming interfaces to access database utilities
DB2 SDK supports several programming languages (including COBOL, FORTRAN,

Java, C, and C++) for application development, and provides precompilers for the
supported languages. It is available on all DB2 UDB-supported platforms. The same
application does not require any source changes to run against DB2 UDB on any Intel or
UNIX platform; therefore, only one base code allows support for several platforms.
DB2 SDK also supports SQLJ. Along with DB2 JDBC support provided by the DB2 Client
Application Enabler (DB2 CAE), DB2 SQLJ support allows for the creation, build, and run
of embedded SQL for Java applications, applets, stored procedures and user-defined
functions (UDFs). These contain static SQL and use embedded SQL statements that are
bound to a DB2 database.
Other important DB2 products are:
• DB2® Connect Personal Edition, which provides access from a single workstation to
DB2 databases residing on host systems such as MVS/ESA, OS/390, OS/400, VM
and VSE, as well as access to DB2 Universal Databases. This product is available
for the OS/2, Windows 3.1x, Windows NT, and Windows 95 operating systems. DB2
Connect Enterprise Edition provides similar capabilities in a multi-user environment
including UNIX systems, OS/2, and Windows NT.
• DB2® OLAP (online analytical processing) Server, which is designed for
multidimensional planning, analysis, and reporting applications.
• DB2 for Domino, which extends the capabilities of DB2 Universal Database to Lotus
Notes and Domino users.
• DB2 DataJoiner 2.1.2, which provides a single interface to heterogeneous
databases. It provides global query optimization, and supports most relational and
non-relational database systems.

DB2 UDB and Informix Differences Overview
High Level Differences

The major packaging difference between the Informix and DB2 UDB product line is that
object-relational capabilities such as support for complex data types, user-defined types,
and user-defined functions, are built into all levels of the DB2 UDB database engine. All
DB2 UDB servers have the same components and can make use of SQL extensions. For
object relational support, Informix offers the Universal Data Option which must be
purchased separately and includes DataBlades® to extend the capabilities of the
Dynamic Server engine. For data warehousing, DB2 UDB/EEE is packaged as a total
solution that also provides object-relational support. With Informix’s Dynamic Server, two
options must be purchased, the Advanced Decision support option and the Extended
Parallel Option. The Universal Data option for object relational support cannot execute in
Informix’s parallel environment. It is important to note that each level of the DB2 UDB
server is the full product while some levels of the Informix Dynamic Server such as the
Personal Edition and Workgroup Edition are subsets of the full product.
Another major difference between the Informix Dynamic Server and DB2 UDB is the level
of scope on which configuration parameters and components operate on. For the most
part, DB2 UDB’s level of operational granularity is the database while many of Informix’s
parameters and components are global to the entire Informix Instance. For example,
logging is performed globally in the Informix Instance and so all databases in the Informix
Instance share the same logs. If the logs fill up and require a backup, use of other
databases in the Instance may be affected. In DB2 UDB, each database has its own set
of logs and a backup of one database does not affect the availability of other databases
in the Instance.
In addition, certain Informix tools, utilities and components such as Enterprise
Replication, the High Performance Loader, the On-Bar backup facility and the Enterprise
Command Center require separate installation and/or extensive configuration after the
Informix server and client code have been installed and configured. In contrast,
installation of the client code includes the installation of the Control Center which includes
all DB2 tools and user-interfaces. Installation of the server code includes replication
capability, the DB2 UDB backup/restore facility, the load utility and all other database
maintenance utilities.
Database Engines
DB2 Universal Database DB2 UDB

Personal Edition – is the full product for single user system available on Windows 95/98,
NT and OS/2 and has 100% portability between it and other levels. This level is good for
development or small standalone applications.
Workgroup Edition – is the full product and support OS/2 and NT on Intel platforms of
up to four processors.
Enterprise Edition (EE) – is the full product for multi-user applications and is available
for UNIX, NT and OS/2 platforms on single or multiprocessor machines.
Enterprise-Extended Edition (EEE) – is the full product for large scale SMP and multi-
node (MPP/Cluster) configurations.

DB2 Tools
Control Center – a GUI user-interface that is packaged with DB2 UDB and runs on a
workstation. It is used to control and manage the DB2 UDB server. Its components can
administer all aspects of the database server, run queries, commands, scripts, schedule
and execute utilities, journal database events such as backups and recovery, and monitor
performance. The SmartGuide feature of the Control Center guides the novice user by
providing information about parameters and other options used for creating database
objects or running utilities.
Command Line Processor (CLP) – a text-based tool that is installed and used on the
server. SQL statements and database commands may be executed from within the CLP
environment or from the command line of the operating system.
Additional DB2 servers

DB2 for OS/390 – DB2 database server for the S/390 environment
DB2 for AS/400 – DB2 database server for the AS/400 environment
DB2 for VM – DB2 database server for the VM environment
Informix
Developer’s Edition – single-user version for workstations that is used as a
development platform
Personal Edition – a subset of Dynamic Server for use in single-user mode
Workgroup Server- a subset of Informix Dynamic Server that is used for smaller
applications running on low-end processors
Informix Dynamic Server (ODS) – full product, multi-user version for Intel and UNIX
platforms. Does not support user-defined types, user-defined functions or other object
relational features without the Universal Data Option. ODS alone will support two types of
large object data types, Byte and Text.
Advanced Decision Support Option – extends the capabilities of Dynamic Server’s
indexing and optimizer for decision support applications.
Extended Parallel Option (XPS – 8.2) – extends the capabilities of Dynamic Server for
inter-parallelism.
Universal Data Option (9.1) – extends the capabilities of Dynamic Server for object
relational support.
Informix Web Integration Option

Dbaccess – a character-based, user interface that is installed and used on the server for
manipulating database objects, running queries and scripts. Dbaccess is packaged with
the server code.
Dbcockpit – a graphical user interface (GUI) for the workstation that is used to manage
Informix databases. Dbcockpit is packaged separately.
Enterprise Command Center – a graphical user interface that runs on the workstation
for managing Informix databases and data. Used for managing database objects, running
queries and utilities. Provides a single point of control for managing all remote database
servers. Enterprise Command Center is packaged separately.

OnWeb – Web based administration tool that is similar to Control Center but not as
powerful.
Client Connectivity
DB2 UDB
Client Application Enabler (CAE) – software installed on client machines to enable
connection to DB2 UDB database servers.
Client Configuration Assistant (CCA) – a GUI tool, used from the workstation, that is
designed to automate the configuration of clients for connectivity to remote DB2 UDB
database servers.
Informix
INFORMIX-Net (I-Net) - software required on a client machine in order to talk to an
Informix server.
Informix-Connect – provides runtime libraries for INFORMIX-ESQL for C and COBOL
and INFORMIX-CLI.
Application Development Support

DB2 UDB
Personal Developer’s Edition – includes all the tools needed to develop application
programs in C, C++, Java and COBOL for DB2 UDB Personal Edition. It is only available
for Windows NT, Windows 95 and OS/2 platforms.
Universal Developer’s Edition – includes all the tools needed to develop application
programs in C, C++, Java and COBOL for all DB2 UDB servers and includes the
Software Developer’s Kits for Windows NT, OS/2 and UNIX platforms.
DB2 UDB CLI – is a built-in Call Level Interface that enables application developers to
dynamically access DB2 UDB database servers, eliminating the need of an SQL
preprocessor and the recompilation of source code. It is based on Microsoft’s Open
Database Connectivity (ODBC) architecture.
VisualAge – is a collection of application development environments for various
programming languages, including C++, Java, BASIC and COBOL. It supports the object-
oriented programming paradigm and provides class libraries that are useful in developing
user interfaces and database applications.
DB2 DataJoiner – enables users to interact with data from multiple heterogeneous
sources, providing an image of single relational database. DataJoiner also allows users
to connect to databases managed by other DB2 systems and other relational systems
such as Informix, Oracle® and Sybase®.
Data Propagator – used to keep databases consistent by propagating changes from one
database to another. This feature is built into DB2 UDB and enables changes to be
captured and applied from one DB2 UDB database to another. Data Propagator can also
be purchased as a separate product to capture and apply changes between DB2 UDB
and other members of the DB2 family.

Informix
Informix-SQL (ISQL) – is a separate product that is used for interactive SQL access, as
a forms builder, report writer (Ace) and menu builder.
Informix Client Software Developer’s Kits – provides single packaging for several
application programming interfaces. It includes C, C++, Java and ESQL.
Informix-4GL – is a rapid development language that compiles into C.
ESQL – is an SQL API that permits the embedding of both static and dynamic SQL
statements directly into a 3GL program.. Informix has ESQL product releases for C and
COBOL. Informix embedded static SQL means that all the components of an SQL
statement are available at compile time. Informix embedded dynamic SQL does not have
all the SQL statement components at compile time, but rather, receives all or part of the
statement at runtime.
NewEra – is a graphical development environment.
Informix CLI – is a Call Level Interface that enables application developers to
dynamically access Informix database servers, eliminating the need of an SQL
preprocessor and the recompilation of source code. It is based on Microsoft’s Open
Database Connectivity (ODBC) architecture.
SQL Extenders
DB2 UDB
DB2 Extenders – contain sets of predefined data types and functions. Each extender
helps to manage a particular kind of data, such as text, images, audio or video. For
example, the text extender can construct a linguistic index that supports fast content-
based retrieval of large text documents. The text, image, audio, and video extenders are
included with the Developer’s Editions of DB2 UDB.
Informix
DataBlades – are object extensions that expand the capabilities of Informix Dynamic
Server to manage complex data types such as video, audio and image, as well as to
develop and use functions to manipulate these data types. These are included with
Informix’s Universal Data Option.
Gateways
DB2 UDB
DB2 Connect (formerly DDCS) – enables users to connect to any database server that
supports the Distributed Relational Database Architecture protocol. All the functionality of
DB2 Connect is included in the Enterprise Edition of DB2 UDB. In addition, DB2 Connect
is available in a Personal Edition and Enterprise Edition. Personal Edition provides a
single workstation remote access to a DRDA server, while Enterprise Edition supports
many workstations on a LAN sending requests to a DRDA server.
Informix
Informix-Gateway with DRDA – provides access to non-Informix databases such as
Oracle, Sybase, and DB2.

Web Support
DB2 UDB
Net.data – is a tool kit that enables development of applications that are accessible from
the Web. Net.data is called from a Web server to and expands a macro that can handle
requests made by a Web browser. The macro can contain SQL statements that retrieve
data from a database and then display the content on a Web page.
Web Sphere Studio – is a Web development environment
Informix
Internet Foundation 2000 – is similar to DB2’s Net.data
Universal Web Connect – provides connectivity between Web servers and Informix
Dynamic Server. Enables Web developers to create, manage and deploy Web
applications (pages) and content to Internet users.
Data Director for Web – is a suite of graphical user interface tools designed to enable a
developer to build and manage Informix-based Web sites and applications.
Data Warehousing
DB2 UDB
Intelligent Miner – is a set of applications that can search large volumes of data for
patterns or trends.
OLAP Server – is a joint product of IBM and Arbor that provides operations for online
analytical processing of large volumes of historical data.
Visual Warehouse – provides for the periodic extraction of data from an operational
database for archiving and analysis into a data warehouse. It includes a catalog facility
for storing metadata about the extracted data.
Informix
MetaCube – is a suite of software products designed to analyze, query, aggregate,
report, administer and maintain a data warehouse.

Database Administration
Architecture
DB2 UDB
An installation of DB2 UDB is called an Instance, and each Instance may have one or
more databases. Each Instance has one Database Manager Configuration file. In
addition, each database has its own Database Configuration file, catalog tables, logs,
reserved bufferpool area and table spaces. Table spaces can be regular, long (for LOB
data) and temporary. Tuning parameters, resource management, and logging may differ
for each database in the Instance and may be controlled at the database level.
Configuration parameters at the Instance and database level can be set using the Control
Center.
Temporary Table Spaces are used to store temporary tables that are created and
managed by the database management system. By default, one temporary table space,
TEMPSPACE1 is created but additional temporary table spaces can be created at
different page sizes, (i.e., 4K, 8K, 32K). Temporary objects are allocated to temporary
table spaces in round robin fashion.
Informix
An installation of Informix is also called an Instance. When an Informix ODS Instance is
initially created, only one dbspace, the ROOT dbspace (rootdbs), exists. The
SYSMASTER catalog tables and logs are created in the ROOT dbspace. For best
performance, the logs must be moved out of the ROOT dbspace into new dbspaces
created for the physical and logical logs. Within each Instance, one or more databases
may be created. The log mode for an individual database is specified at creation time,
and each database in the Instance may have a different log mode.
Each database that is created has its own set of database system tables. Catalog tables
at the database level contain information about tables, columns, indexes, views, users,
triggers, stored procedures and authorities. This is in addition to the SYSMASTER tables,
the global set of catalog tables at the Instance level. SYSMASTER contains information
about databases, dbspaces, chunks, extents, locks, logs and sessions.
The Informix database configuration file, ONCONFIG, is global to the entire Instance and
all tuning parameters affect all databases in the Instance. In addition, bufferpool space is
global to all databases and can only be tuned at the Instance level. Database logs are
also defined at the Instance level and are used by all databases in the Instance.
Configuration parameters in the ONCONFIG file can be set using a menu-based utility on
the server called ON-MONITOR. Only the informix user or ROOT can initialize an
Instance. If a database is created in LOG MODE ANSI, then tables may have the same
name as long as the owner is different. If the database is created using any other log
mode or NO LOG, then each table name must be unique within the database.

Optimizers
Both DB2 UDB and Informix have cost-based optimizers which determine costs based on
statistics stored in catalog tables.
DB2 UDB
DB2 UDB allows for seven levels of optimization. The QUERYOPT parameter is used to
specify the optimization level for static SQL and is done with the PREP or BIND
command. The optimization level is set for dynamic SQL using the SET command as:
SET CURRENT QUERY OPTIMZATION = 3. If not specified, the default setting of the
database configuration parameter DFT_QUERYOPT is used.
DB2 UDB has a query rewrite feature and the order of tables in a join are not important
as the optimizer will rewrite the order for the optimal access path. Catalog statistics are
updated using the RUNSTATS utility. If an application uses static SQL, the access paths
that are generated at bind time by using the statistics in the catalogs are stored with the
SQL executable code on the database. If an application uses dynamic SQL, the access
path is generated at runtime by using the statistics recorded in the catalog tables.
Dynamic caching of SQL executable may allow for quick reuse of the optimized code.
Informix
For Informix, the optimization level is set using SET OPTIMZATION HIGH or LOW. You
can specify a default setting for the optimizer by running the OPTCOMPIND command.
OPTCOMPIND is used to influence the optimizer to select a different join method. Three
settings can be used with this command. Since there is minimal query rewrite, selecting
the best table order is important.
Optimization or access path selection for static SQL is determined each time an
application is invoked and is not stored before runtime. Static or dynamic SQL may be
reused if found in the SQL cache area. Catalog statistics are updated using the UPDATE
STATISTICS utility.
Parallelism
DB2 UDB and Informix both support two types of parallelism: parallelism within a
database instance and parallelism between database instances. The former most
commonly runs on a symmetric multiprocessor (SMP) machine in which multiple
processors share common memory and disks. The latter usually involves a collection of
processors each of which has its own main memory and disks that are not shared with
other processors (“shared-nothing”).

Intra-Parallelism
With intra-parallelism on an SMP machine, multiple processes can serve a given user
simultaneously. The optimizer generates access plans containing multiple threads that
can be active simultaneously during processing of an SQL statement. The number of
threads generated is called the “degree”. This type of parallelism is used by DB2 UDB EE
and Informix ODS. In addition, both products facilitate parallel I/O by “fragmenting” or
striping (round robin) data across multiple storage devices. Unless the storage device is
RAID, striping of data in Informix is a task performed by the DBA while in DB2 UDB it is
handled automatically by the database management system.
DB2 UDB
For a DB2 UDB database to exploit this type of parallelism, the database manager
configuration parameter INTRA_PARALLEL must be set to YES. When performing a
PREP or a BIND, the DEGREE parameter can be set to a specific integer indicating the
number of threads to be generated, or it may be set to ANY.
If set to ANY, the optimizer determines the number of threads to generate. Each thread
may be processed by a separate processor. The degree for dynamic SQL can be
specified by setting the CURRENT DEGREE register. The default value for DEGREE is
controlled by a database configuration parameter named DFT_DEGREE.
Informix
Informix uses PDQ (Parallel Data Query) to control parallelism or the number of threads
generated. To make the most efficient use of PDQ parallelism with Informix, values for
the number of scan threads, memory size, number of queries and the query’s priority
must be set. The four parameters in the ONCONFIG file that must be set are
DS_MAX_QUERY, DS_MAX_SCANS, DS_TOTAL_MEMORY and
MAX_PDQPRIORITY. Several Environment variables must also be set to enhance PDQ
processing.
Inter-Parallelism
With inter-parallelism on an MPP (massively parallel processor) or a cluster of SMP
machines connected by a LAN, each database instance runs on a separate machine and
has its own memory and disks. A single table may have rows that are owned by many
instances of the database. This type of parallelism is used by DB2 UDB EEE and
Informix XPS. In DB2 UDB, each instance is called a Partition; in XPS, each instance is
called a Co-server.
DB2 UDB/EEE
DB2 UDB/EEE supports an SP AIX availability feature called HACMP. This function
allows automatic takeover of a failing node’s DASD by another node. The takeover node
could be a hot standby or another working node. In either case, the DASD is “wired” to
the partner nodes. When a failure occurs, DB2 will be started on the standby node and
access to the DASD of the failed node will be automated. If a query is in progress when a
node fails, and the query needs data on the failed node, backout will occur automatically
and the query can be restarted, accessing the failed node’s DASD through the takeover
node. This improves availability.
When loading data, DB2 UDB/EEE automatically spreads data evenly across the
processors in a parallel complex, thus providing the ability for each processor to process
a subset of data in parallel. As the data warehouse grows, additional SP nodes must be
added to the configuration to allow the complex to support additional data. When this

happens, data must be redistributed across the new configuration to spread the data
evenly on the processors. DB2 UDB/EEE has a Redistribute Utility that allows the data to
be automatically distributed when adding or removing processors. This feature enhances
availability of the warehouse.
Informix/XPS
Informix does not support HACMP or automated takeover of a failing node. Informix also
does not support a Redistribute Utility. The user must drop the database, redefine it, and
then reload the entire database. This could take considerable time, thus affecting the
availability of the warehouse.
Bufferpool Management
DB2 UDB
Each database has a default bufferpool area named IBMDEFBP. Additional bufferpools
can be created, and table spaces can be created or altered to use specific bufferpools.
By assigning table spaces to a particular bufferpool, data pages from tables that are read
often can be made to reside in memory. By separating bufferpools for highly accessed
read-only tables from bufferpools for tables with high update activity, it is possible to
insure that data pages will reside in memory longer and thus, enhance performance.
Informix
Buffers make up the largest part of the Resident portion of Informix’s Shared Memory.
The size for Resident memory and the size of the buffers within the Resident memory is
specified in the ONCONFIG file. Buffer space is global to the entire Instance and
dbspaces or tables are not assigned to specific buffer areas; however, tables or parts of
tables and indexes can be made to remain resident in memory.
Storage Management
DB2 UDB
The physical space within a database is organized into a collection of table spaces. Each
table space consists of a collection of containers, each of which is either a directory in the
machine’s file system, a physical file or a raw device. When creating a table space, an
extent size in the number of 4K pages is specified. If an extent size is not specified, then
a default extent, which is specified in the database configuration file, is used. When a
table is created, it is assigned to a table space. An extent contains data for only one table
and all extents are the same size. After the initial extent fills, all additional extents are
created on each additional container in the table space in round robin fashion.
Distributing data in this way, enables parallel input and output and optimizes
performance. Indexes for a table may be contained in the same table space or in a
separate table space as long as the table space type is DMS. Large objects can be
stored in special table spaces named LONG.
Two types of table spaces are available: SMS and DMS. SMS table spaces are managed
by the operating system and DMS are managed by DB2 UDB. SMS table spaces are
better suited for smaller tables where performance is not a prime consideration and
where they are also easier to maintain. The space in a SMS table space is defined as a
directory and is not pre-allocated. Data can be added as long as there is enough physical
space available. More than one directory can be assigned to the table space. With the

SMS type table space, data, indexes and large objects are all stored in the same table
space.
DMS table spaces are better suited for large data where performance is a key factor.
Containers are added to DMS table spaces in the form of a file or physical disk device.
The space is pre-allocated and fixed in size. Additional containers may be added to
support growth. DMS table spaces support the separation of data, indexes and large
objects.
DB2 UDB provides two types of GUI panels to assist the DBA in table space creation, the
Create Table space Smartguide and the Create Table space Notebook.
Informix
The dbspace is the equivalent of DB2 UDB’s table space. Unlike, a DB2 UDB table
space, which is created using DDL, dbspaces are created by executing the ONSPACES
command. Each dbspace is composed of physical storage called chunks. Chunks are
either raw devices or files and correspond to the container of DB2 UDB. Chunks may be
added to a dbspace when more space is required. Indexes may be stored in separate
dbspaces from data. (Informix has a concept of a “Table space,” but in Informix, “Table
space” has a different meaning than DB2 UDB’s table space). Blobspaces are used for
storing the large binary objects of data types Byte and Text.
Data is not distributed across chunks automatically by Informix. In order to distribute data
across physical storage, a fragmented table with several dbspaces must be created and
the type of “fragmentation” must be specified. Fragmentation is specified in the Create
Table DDL by assigning each fragment into a different dbspace. Data for fragments are
distributed either by round robin or by an expression.
Extent size is also specified by the Create Table DDL. A size is given in 4K pages for the
Initial and Next extent and these sizes may be different. If the table is not fragmented,
then the Initial and all Next extents will be assigned to the same dbspace and may be
contained on the same Chunk. Having many noncontiguous extents unevenly distributed
across physical devices may impact performance.
Configuring And Connecting Clients
DB2 UDB
A client is configured to connect to a database. Several directories are used to allow
clients to access local and remote databases. The System Database Directory identified
the name, alias and physical location of each database. All clients and servers must have
a system directory. A local directory exists at the location where each database is created
and contains the name of a database and the subdirectory pathname in which the
database files are stored.
For a client to connect to a remote database, each client machine must have a Node
directory which contains an entry for all nodes to which a database client can connect.
Each entry contains the node’s name, communication information and Instance
information. These directories can be configured by using the Client Configuration
Assistant or the Control Center.

Informix
A client is configured to connect to an Instance also referred to as a database server. The
Sqlhosts file resides on a database server machine and lists all the Instances that have
been created for the local machine and any other server machine on the network. Also
specified for each Instance is the type of connection to be used and a service name that
represents a port and the protocol for that connection.
On the client side, Setnet32 is used to set parameters for the client connection. Using
Setnet32, the client can establish connectivity to the all the databases found on an
Instance by specifying the database server name (Instance name), the machine name,
the service name and the protocol used for each Instance to which the client wants
connectivity. Setnet32 is also used to set environmental variables on the client machine.
Embedded SQL Development
DB2 UDB
SQL can be embedded within 3GL languages such as C, C++, COBOL, FORTRAN and
Java. Embedded SQL can be static or dynamic. Static SQL means that the entire SQL
statement is known at compile time. Dynamic SQL means that the complete SQL
statement may not be known until runtime at which time the SQL statement can be
compiled using an EXEC PREPARE statement.
In either case, the host language program with embedded SQL statements is
preprocessed using the PREP statement. The embedded SQL statements are replaced
with host language procedure calls, and the SQL statements are placed into a file with a
file extension of .bnd. The BIND statement is used to compile the .bnd file into a package
of executable SQL, and together with an access path strategy, the Package is stored and
cataloged on the DB2 UDB database. Static SQL is simply executed each time it is
invoked and dynamic SQL is prepped and executed at runtime unless the prepared code
is already in the cache, in which case it is simply executed. Stored procedures are
prepared and compiled for execution just like embedded SQL programs.
Informix
ESQL is the Informix product that allows SQL development with C and COBOL. The
source language with embedded SQL is preprocessed and the SQL statements are
converted into procedures and data structures of the source language. The source
language is then compiled using an ESQL compiler. The executable code is linked with
SQL APIs procedures. The SQL APIs are a library of procedures that are part of the
ESQL product. Only the source language statements are compiled.
The SQL API’s are compiled at runtime when they are invoked for execution. Although
Informix embedded SQL is always compiled and executed like DB2 UDB dynamic SQL,
Informix refers to SQL statements that are completely known at preprocessor time as
“Static” SQL.
Stored procedures are embedded SQL in a proprietary source language known as SPL.
With Informix stored procedures, SQL is parsed, validated, optimized and stored in an
executable format on the database. In this way, Informix stored procedures are similar to
a static SQL package in DB2 UDB.

Concurrency
Isolation Levels
DB2 UDB
DB2 UDB has four isolation levels: Repeatable Read, Cursor Stability, Uncommitted
Read (dirty read) and Read Stability. Read Stability is the only isolation level that does
not exist in Informix. Read Stability keeps a lock only on those rows accessed that
actually qualify for the query of an application program. Since read locks are not held on
unqualifying rows, the next time the same query is executed, unqualifying rows may have
been changed to qualifying rows and as a result, new rows may appear in the result set.
This isolation level permits a little more concurrency to Repeatable Read where the
application keeps a lock on all rows that are accessed by an application program.
The isolation level is specified at pre-compile time as a parameter to the PREP command
or when an application is bound to the database using the BIND command. The default
isolation level is Cursor Stability.
Informix
The four types of Isolation levels that affect shared locks in Informix are: Repeatable
Read, Cursor Stability, Committed Read and Dirty Read, which is also known as
Uncommitted Read. All Isolation levels except for Committed Read behave like the
Isolations levels of DB2 UDB.
The Committed Read Isolation level does not exist in DB2 UDB and is the default
Isolation level used by a logged database except for mode ANSI. (If the database is in
mode ANSI, then the default isolation level is Repeatable Read.) Committed Read will
not return a row to an application if it is locked for update, insert or deletion. When using
Committed Read, the instance checks to see if a shared (read) lock can be placed on the
row, but does not actually put a read lock on the row. The advantage of using this type of
Isolation level is speed. Committed Read does not prevent a row that is being read by an
application from being changed by another application. It only prevents reading a row that
is being changed.
Isolation levels for an application are set in Informix by issuing the SET ISOLATION TO
xxxx command. This command is either entered interactively or embedded within the
application program.

Locking
DB2 UDB
DB2 UDB provides row and table lock levels. All locks are at the row level by default
unless the LOCK TABLE IN xxxx MODE statement is used to enable locking at the table
level. Locks are held in shared or exclusive modes. When the number of locks issued
exceeds the capacity specified by maxlocks (calculated by the DBA) and locklist in the
database configuration file, lock escalation occurs. When this happens many row locks
are freed and converted into one table lock. A deadlock detector periodically looks for
deadlock situations and rolls back one of the transactions involved. The deadlock
detection interval is set in the database configuration file. A timeout parameter for waiting
on a lock to release is also set in the database configuration file.
Informix
Informix supports row, page, table and database locking. Page locking is the default.
Lock levels are defined in the Create Table DDL by using the LOCK MODE xxxx clause.
To lock an entire table, the LOCK TABLE IN xxxx MODE (xxxx = shared or exclusive)
can be used in application code. It is also possible to lock an entire database in exclusive
mode.
The types of locks in Informix are shared, exclusive and promoteable. A promoteable lock
is one which is first a shared lock with the intent of becoming an exclusive lock (i.e.,
SELECT FOR UPDATE). How long a process waits to get an exclusive on a data item
that is currently being held by another exclusive lock before it times out is determined by
the SET LOCK MODE TO xxxx command in the application code. The lock mode can be
set to a time in seconds, to an indefinite wait or to no wait at all.
An ONCONFIG configuration parameter called LOCKS determines the maximum number
of locks that can be held by a process at one time. Informix ODS has a limit of 8,000,000
locks per user process. If the number of locks is exceeded, all data affected is rolled back
and there is no lock escalation.

Security
DB2 UDB
DB2 UDB supports authorities at the instance and database levels. Userids can be
authenticated at the server level, the client level, or by DCS. The authentication type is
specified in the database manager configuration file. If the userid is authenticated at the
server level, then the userid must be a valid operating system userid.
Three levels of authority exist at the Instance level that span the entire Instance. These
levels of authority are defined in terms of groups and are recorded in the Database
Manager Configuration file. Groups are created and maintained at the operating system
level by the system administrator. The three levels of authority are SYSADM, SYSCTRL,
and SYSMAINT.
When a DB2 UDB Instance is created, the group to which the creator of the Instance
belongs is given SYSADM authority. This SYSADM group is recorded in the Database
Manager Configuration file. SYSADM is the highest level of authority for an DB2 UDB
installation and is used to create other levels of authorities in an Instance. SYSCTRL is
an Instance level of authority that has the right to control resources in the Instance.
SYSCTRL can create and destroy databases and table spaces. SYSMAINT is a level of
authority that can maintain the Instance. SYSMAINT can start and stop the Instance,
backup and restore databases and perform monitoring tasks.
At the Database level, certain authorities (DBADM, BINDADD, CONNECT and
CREATAB) must be granted for each database within an Instance by the SYSADM. The
highest level of database authority is DBADM. The DBADM authority can be granted to a
userid or a group, and can access and modify all objects within a database, as well as
grant database authorities to other userids.
Another Database authority, the BINDADD authority, provides the right to create new
packages in the database for their own userid or for other users. The BINDADD authority
is needed when installing SQL applications on the database. The user with BINDADD
authority or the owner of a package can grant the BIND authority on a package to other
users.
A third Database authority is CONNECT. This authority conveys the right to connect to
the database. A user with CONNECT authority can only manipulate tables that they own
or tables to which they have been granted the specific privileges of SELECT, INSERT,
UPDATE or DELETE.
A fourth Database authority, the CREATAB authority, provides the right to create tables
in a database. The userid that creates objects in the database is the owner and inherently
has the right to fully manipulate those objects. If the owner of an object would like another
user to have privileges on those objects, the owner must GRANT those privileges to the
other user's userid. All users who can connect to a database can automatically SELECT
from the catalog tables.
Other database authorities and privileges can control various operations within a
database. A discussion of these authorities and privileges, however, is beyond the scope
of this paper.
Informix
After a client has connectivity to a database server, the userid that is used to connect
must exist at the operating system level on the server. After that, users can be granted
authority at the database level.

The three Informix levels of authority for a database are CONNECT, RESOURCE and
DBA. Users with CONNECT database authority can perform select, insert, update and
delete statements if they have been granted these privileges by the owner of the tables.
Users with RESOURCE authority can create, alter, and drop their own tables and place
indexes on these tables and grant privileges to others users for their tables. The creator
or owner of the database is automatically given DBA privileges. Users with DBA authority
can grant and revoke CONNECT, RESOURCE and DBA authorities to other users;
create, drop and alter other users’ tables and views; and drop, start, stop and recover the
database. Informix has the keyword PUBLIC that represents all users who can access
the database server. Informix supports the use of roles (similar in functionality to groups
in DB2 UDB) and the use of an administrator group.
In addition to Database authorities, Informix uses the informix userid role. A user and
group each with the name informix must exist and be used to install the server. On UNIX,
the informix user’s home directory is the same directory where the server is installed. The
informix userid has super-user authority at the instance level and can be used to grant
database authorities to other userids.
Access Paths
Clustering/Clustered Index
In DB2 UDB, an index can be defined as a clustering index. In this case, rows in a table
will be ordered according to that index, and that order will be maintained as long as there
is free space on a page to allow for insertions of future rows. Similar to DB2 UDB, an
index may be created in Informix with the CLUSTER keyword; however, since no free
space is allocated to data pages, the table will not maintain rows in the same order as the
index as new rows are inserted.
PCTFREE/FILLFACTOR
In DB2 UDB, PCTFREE is the amount of free space on an index or data page that is left
free for future insertions of indexes or data rows. PCTFREE is a parameter of the
CREATE INDEX and CREATE TABLE statement. The percent of free space left on each
index page in Informix is controlled by the FILLFACTOR parameter which is set in the
ONCONFIG file. This value applies to all indexes in the Instance. If the FILLFACTOR is
set to 90, then 10 percent of the page is left free for future inserts to the index. This helps
to maintain the ordering of index insertions. The FILLFACTOR is similar in concept to
DB2 UDB’s PCTFREE for index pages. In Informix, however, FILLFACTOR cannot be
used for data pages.

Logging, Backups and Recovery
DB2 UDB
Logging
Logging occurs at the database level in DB2 UDB and can be enabled differently for each
database in the Instance. The Control Center is used to select a database for backup and
recovery operations. The database log, which can be used in several ways, is an
important part of the backup and recovery processes. The system log records all
committed changes to the database, and it is used to bring the database to a consistent
point after a power failure. It can also be used to restore a database to its current state
after media failure or application failure.
The system log is maintained as a set of files in a directory whose path name is specified
by the database configuration parameter named LOGPATH. The number of log files is
controlled by the LOGPRIMARY parameter and the size of the log files is controlled by
the LOGFILSIZ parameter. In addition to the primary logs, DB2 UDB also uses a number
(between 0 and 126) of secondary logs as specified in the LOGSECOND parameter.
Secondary logs do not occupy permanent file space, but are allocated one at a time as
needed and de-allocated as they are not needed. Secondary logs are used when the
primary logs fill up and more log space is required.
When a database is created, the default logging mode is circular logging. As circular
logging is performed, the log files are reused and overwritten when more space is
needed. This type of logging is used to protect against power failure and is used by
applications to rollback uncommitted changes. When this type of logging is enabled, the
LOGRETAIN and USEREXIT parameters in the database configuration file are set to NO.
Only off-line, full database backups can be performed with this type of logging. A
database can only be recovered to the last full backup.
Rollforward is another log mode that can be used. With this type of logging, logs are not
reused, but are maintained online until they are archived. The online and archived logs
are used, along with the last full backup, to recover a database back to the current state
just before a media or application failure. The LOGRETAIN and USEREXIT parameters
must be set to YES for Rollforward to be enabled. If the USEREXIT parameter is set to
YES, a user-written program controls moving the online logs to archived off-line logs.
With Rollforward logging, the database backup can be online or off-line, and can be a full
database backup or a selected table space backup. Recovery of a database can be
performed to the last current committed transaction before the failure or to some specific
point in time. Also, with this type of logging, recovery can be performed on a table space
basis.
In DB2, UDB logging must be either circular or Rollforward. The option of NO LOG,
available with Informix, does not exist in DB2 UDB.
Long Transactions
When primary logs are full, secondary log files are allocated one at a time as needed. If
more space is needed than what the secondary log parameter allows for, then the
database will automatically rollback the work. When the secondary logs are no longer
needed, the space that they occupy is freed.
Backups
Backups can be performed at the database level or table space level in DB2 UDB and be
written to disk, a tape device, or to a location managed by a storage management system

such as ADSTAR. Backups can be either off-line or online depending on the log mode
used. To perform a backup, a user must have SYSADM, SYSCTRL or SYSMAINT
authority. The Control Center can be used to perform a backup on demand or to
schedule a backup for a specific time.
Recovery
The RESTORE command is used to recover a database or can be used to create a copy
of a database. In order to restore a database, a user must have the SYSADM, SYSCTRL
or SYSMAINT authority. If Rollforward logging is used, recovering from an online backup
copy will leave the database in a roll-forward pending state. The database cannot be
used until a ROLLFORWARD command is applied. This is also true if recovery is done
on a table space basis. If the restore comes from an off-line, whole-database backup,
then the phrase WITHOUT ROLLING FORWARD can be added to the RESTORE
command. This will avoid the roll-forward pending state, and the database will be usable
immediately. Each backup used to restore a database is identified by its directory and a
timestamp. A single table space may be restored from a whole-database backup.
Roll-Forward Recovery
The ROLLFORWARD command is used to apply log changes to the database or table
space recovered from a backup. The ROLLFORWARD may be done to the end of the
logs or to a specific point in time in the logs by specifying a date and time. A directory for
archived logs is specified along with the online logs specified by the LOGPATH
parameter.
DB2 UDB has a graphical tool called the Journal that can be used to manage recovery of
a database. The Journal is part of the Control Center and records all events for a
database. The Journal’s recovery panel displays a history of the backups and restores for
a database. To restore a database from particular recovery, simply select the backup
from the Recovery panel. A SmartGuide can be used to guide the user through the
selection of options that can be used with a RESTORE.
Logging for Work Tables

If a table is used to temporarily store data, it may be created with the NO LOG INITIALLY
clause. All data that is inserted into the table in the same unit of work in which the table
was created will not be logged. However, the catalog tables will be updated when the
table is created.
Load Utility
Data is not logged when loading data using the Load utility.
LOB Data
Data with the BLOB or CLOB data types can be stored in a table with the NOT LOGGED
option.
Mirroring
Mirroring for DB2 UDB is managed at the hardware level.

Informix
Logging
Informix uses two types of logging, one set of logical logs and one set of physical logs, for
the entire Instance. The physical logs are used to capture the before image of data prior
to any changes. Physical logs are used primarily for fast forward recovery, and by
Informix backup procedures. The logical logs are where all data changes made by
transactions and whether or not they have been committed are tracked.
The number of logs to configure, their sizes and other parameters affecting logging are
set in the ONCONFIG configuration file. Each database in an Instance can be created to
use a different log mode. Informix supports NO LOG, ANSI LOG MODE and LOG MODE
of BUFFERED or UNBUFFERED.
Long Transaction
It is important to set the LTXHWM (percent of the logical log that can be filled by a long
transaction before it will be rolled back.) parameter in the ONCONFIG file correctly. If a
long transaction runs out of log space the transaction will be rolled back. Rolling back a
transaction, however, generates additional log records and requires adequate log space
in order to be successful. If the logical log space is not sufficient to support the rollback of
the long transaction, the Instance will crash and will not come up without the assistance
of the Informix Support Center.
Temporary Tables with NO LOG

Temporary tables must be created with the NO LOG clause in order to avoid logging of
data on a logging database.
Ontape
The Ontape utility has a command line interface. Archives can only be done at the entire
Instance level Ontape supports the incremental archive levels of 0, 1 and 2. Ontape is
also used to backup the logical logs. Log files can be backup up in continuous mode or
on-demand. Continuous mode requires sufficient disk space or a dedicated tape device.
On demand mode requires a monitor of the logs. Databases that are logging will suspend
processing of transactions if the logs fill up. Only the informix user can execute Ontape.
The Ontape configuration parameters are set in the ONCONFIG configuration file for the
Instance.
The Ontape utility is also used to perform a restore. The restore can be one of the entire
Instance or an individual dbspace. If the restore is for an entire database, it must be done
off-line. If the restore is for one or more dbspaces, then the restore can be done online.
OnBar
Configuring OnBar involves setting parameters in the ONCONFIG configuration file of the
Instance and configuring a storage management system if one is used. In addition, a
native storage manager called ISM is available. OnBar can also be invoked from the
command line on the server or from the Informix Enterprise Command Center. OnBar
supports the backup and restore of the entire Instance or individual dbspaces. Backups
and restores can be done either online or off-line. OnBar also supports the backup of the
log files as continuous or on demand. Point-in-time recovery can only be done at the
entire Instance level.

Mirroring
The mirroring mechanism provides instantaneous fail-over protection of the physical
media in case of a disk crash. If Informix receives a disk failure, it automatically moves
the disk off-line and converts the mirror from being a read-only device to the active,
updateable device. When the primary disk is placed, the mirroring mechanism
resynchronizes the primary and mirror copies. The use of mirroring is controlled by the
DBA and specified in the ONSPACES command. To use mirroring, it must first be
enabled in the ONCONFIG file.
High Performance Loader

Data that is loaded using the Express mode of the HPL is not logged.
Blobspaces
LOB data that is stored in BLOBSPACES is not logged.
Backups and Restores

Backups and restores for Informix occur at the Instance level or the dbspace level, but
not at the database level. To backup at the database level, each database must have its
own set of dbspaces, or a logical backup may be done using dbexport. Setting up
Informix for backups and restores can be quite an involved process. Two types of
facilities, Ontape and OnBar, can be used. Ontape is a backup utility that is included with
the database management system. It is easy to use, but it is not very flexible. OnBar is a
backup system designed to interact with a third party storage management system such
as Legatto or Adstar. Configuring the OnBar system is not a trivial process; however, it
provides for more flexibility than Ontape.
Informix implements three levels of backups: level 0, level 1 and level 2. Level 0 copies
all pages in a dbspace; level 1 copies only the pages that have changed since the last
level 0 backup; and level 2 copies all pages that have changed since the last level 1
backup. Informix can perform a backup while in online mode or in quiescent mode.

Moving and Managing Data
DB2 UDB
Import
The import utility can be used at the table level. It is used to insert rows into a table from
an external file using the SQL INSERT statement. Data that is imported is logged. During
the import, data in the table remains accessible. All constraints and triggers remain in
effect during the import and are activated in the usual way as rows are inserted. Data
may be imported to a client location.
Export
This utility can be used at the table level and extracts data from the database and saves
it in a file, using one of several file formats. The data to be extracted is specified by an
SQL query. Exports may be performed from a client location.
Load
Load inserts data into an existing table a page at a time. Load is intended for the initial
load, for replacing existing data or for appending new data to existing data. The data
being loaded must be local to the server. Indexes are constructed in a separate step after
the bulk loading of data. Statistics may be updated as part of the Load process or
afterwards. During Load, the table spaces that contain the table being loaded are not
accessible to other applications. During the loading of a table, constraints and triggers
attached to that table are temporarily suspended. After the load, the constraints are
reactivated. and a check on the new data is performed to verify that constraints have not
been violated. Data that is loaded is not logged. Instead of logging loaded data, a copy
of the loaded data must be performed after the Load. If the load is used with the non-
recoverable option, a copy of the loaded data may be omitted. Loading data may take
advantage of parallel processing if multiple storage devices are used. The SET
CONSTRAINTS statement is used to verify that referential integrity and Check
constraints have not been violated. Violations of a unique key are written to an
exceptions table.
File Formats for Import, Export and Load

All file formats may be used by Import, Export and Load except where indicated below.
Delimited ASCII – columns are delimited by commas by default. Any other delimiter may
be used instead of commas. Character data is enclosed in quotes. NULLs are
represented as either empty spaces or as no spaces between column delimiters. This file
format is used to transfer data between databases and DRDA systems. When exporting
using delimited files, all dates by default are in YYYYMMDD format. To get ISO format
(YYYY-MM-DD), DATEISO must be specified in the FILETMOD attribute.
Nondelimited ASCII – positions are fixed for each column of data.
IXF – binary file that contains data and description of a table. The table does not have to
be created when using this file type for import or Load. This file format is used to transfer
tables and data between databases and systems.
Worksheet – used for exchanging data with products like Lotus 1-2-3. The Load utility
does not support this file type.

db2move
db2move is a tool used to help move large numbers of tables between DB2 databases
located on workstations. Db2move queries the system catalog tables for a particular
database and compiles a list of all user tables. The tool then exports these tables in IXF
format. This utility is similar to Dbimport and Dbexport in Informix.
Data Replication for Moving Data

Replication can be used to move data from one DB2 database and/or system to another
DB2 system. Replication allows for the customization of the data that is being copied and
stored. The copied data can be aggregated or modified using SQL.
Runstats
The Control Center may be used to run this utility by selecting a table and then invoking
Run Statistics. Statistics may be updated for columns and indexes and are stored in the
catalog tables. In order to run statistics, the user must have the SYSADM, SYSCTRL,
SYSMAINT or DBADM authority or the CONTROL privilege on the table. Statistics in
some catalog tables may also be updated manually. After updating statistics, a rebind
should be performed so that the new information can be used to update access
strategies for application programs.
DB2look
This utility is a tool used to collect statistical information from catalog tables and save it in
a file. The tool is also used to capture DDL for tables and indexes, and it can be used to
clone databases and statistics for testing purposes.
Reorg
Reorg is a data and index management utility that helps maintain rows in physical pages
of a table in the clustering sequence of an index. Reorg prevents fragmentation of the
data and indexes as a result of deletes, and reestablishes the free space on a data page
(PCTFREE) for newly inserted rows that are ordered by a clustering index. The Control
Center may be used to select a table or index for reorganization.
Reorgchk
This command helps to identify tables that need to be reorganized.
Informix
Dbimport
The import utility can be used only at the database level and is used to create or move a
complete database environment. Only a user with the DBA authority or the informix user
can perform an import. This utility is not available in Informix XPS.
Dbexport
The export utility operates only at the database level and exports every table and index in
the database and its schema. An exclusive lock is placed on the database during export.
Only a user with the DBA authority or the informix user can perform an export. This utility
is not available in Informix XPS.

SQL Load and Unload Statement

This SQL statement allows for the loading and unloading of data to and from a file. The
statement performs SQL inserts that are logged if the database is a logging database.
Dbload
This command line utility is for loading data from text files of the delimited or fixed column
type into one or more existing tables. This utility performs SQL insert statements.
Onload
This utility is used to create a database or table in a specified, pre-existing dbspace. Only
data that is unloaded using the Onunload utility can be loaded using Onload.
Onunload
This unloads one or more tables and indexes, a page at a time, into a file in binary
format.
High Performance Parallel Loader (onpload)

The HPL has two modes, deluxe and express. Express mode is faster, rebuilds indexes
after data is loaded and does not maintain constraints. A level 0 archive must be taken
after the load is complete since logging is not performed. Deluxe mode is slower, but
maintains all the constraints. Data is logged. To take advantage of parallelism, the load
data must be split into several files and the table must be fragmented. The High
Performance Loader cannot be used with Online Workgroup Servers or Developer
Editions.
Alter Index to Cluster

This statement forces all existing rows in the table to be reordered according to the index.
This is the closest feature that Informix has that compares to DB2 UDB’s Reorg utility.
Using this feature of Informix, data can be reordered according to a clustered index, but
that reordering cannot be maintained since there is no concept of PCTFREE for data in
table pages. Newly inserted rows may or may not be maintained in order.
In order to consolidate data that has been fragmented over many extents due to a high
insert and delete activity, the data may also be unloaded and reloaded.
Update Statistics
The Update Statistics utility operates on a table basis and is the equivalent of DB2 UDB’s
Runstats utility. This utility inserts statistical information about database data in the
catalog tables. The information is used by the optimizer to select the best access path to
the data.
Dbschema
This utility is used to dump the entire schema of a database or of one object into a file.
Objects include tables, indexes, views and privileges.

Replication
DB2 UDB
Replication uses the changes stored in the database log from the source table and
applies them to a target table in any database in the Enterprise. Specifications for how to
apply changed data are known as replication subscriptions. Two programs, Capture and
Apply, perform the ongoing replication. Capture reads the database log and copies the
changes to a staging area for replication at a later time. The Apply program reads the
changes and applies them to the target table. The target table can be read-only or can be
updateable, and the changes can be captured and applied back to the original source
table.
Replication can be enabled using the Control Center. A table can be defined as a
Replication source. Once this is done, a Subscription can be defined that allows all
updates to the replication source to be automatically replicated into a target table.
Mirroring in DB2 UDB is not performed at the database level. Instead, it is performed
outside of the database at the hardware level.
Informix
Informix supports High-Availability Data Replication (HADR) which is built into the product
and Informix Enterprise Replication which is a separate option. HADR is enabled by
sending the logical logs from the primary server to the secondary server where all the
changes are applied. The primary server is updateable and the secondary server is read-
only. If the primary server fails, users can be redirected to the secondary server.
Informix‘s Enterprise Replication option also supports peer-to-peer replication with the
update anywhere feature.
Mirroring is enabled by defining a secondary chunk and linking it to the primary chunk.
Every write to the primary chunk is also written to the secondary or “mirror” chunk.

Informix to DB2 Migration Checklist
THE SERIAL Datatype

UDB does not have a sequencing datatype similar to SERIAL, which is often used to
generate unique keys for inserting rows. This capability can be mimicked in UDB by using
a trigger and a UDF. The UDF can be coded to generate unique numbers in sequence.
An alternative approach to generating unique keys in UDB is to use the
generate_unique() function. This function should be used if the keys do not need to be in
sequence.
Another approach is to define the key column as a TIMESTAMP datatype. As rows are
inserted, UDB will generate timestamp values for each row. If this method is used, a
unique index should exist on the table and the application should check for the
occasional generation of a duplicate timestamp value by checking for SQLCODE –803
after the INSERT. If this SQLCODE is returned, the application should retry the INSERT
so that a new timestamp value will be generated.
LOB Datatypes
Informix uses the TEXT and BYTE datatypes for large character and byte data
respectively. UDB has comparable datatypes, CLOB and BLOB. Unlike Informix, UDB
requires that the maximum length of the CLOB or BLOB be specified.
MONEY Datatype
UDB does not have a money datatype. A user-defined type named MONEY with a
datatype of DECIMAL with a scale of 2 should be created and used in the DDL to create
tables.
INTERVAL Datatype
UDB allows date/time arithmetic, which can be used within a DB2 application to
manipulate DATE, TIME and TIMESTAMP fields to generate intervals of time. The
following provides an example of this procedure:
SELECT col1 FROM table 1 WHERE CURRENT DATE < (DATE1 + 10 YEARS);
DATE/TIME Datatypes
The character string formats for representing these date/time datatypes differ from the
Informix format. Internally, UDB stores these values in a packed decimal format. Informix
stores these values as integers. UDB applications use Character datatypes to declare
host variables in the EXEC SQL DECLARE BEGIN section to hold date/time values.
Informix applications use Integer datatypes or use DATE/TIME typedefs to declare host
variables for date/time values in the EXEC SQL DECLARE BEGIN section.
TYPEDEFS
Informix allows the use of typedefs when declaring host variables in ‘C’. A typedef allows
the application developer to rename a datatype such as INTEGER with a more
descriptive name such as DATE. DATE can then be used as a datatype throughout the
program, including the host variable declare section, in place of INTEGER. UDB does not

allow the use of typedefs in the EXEC SQL DECLARE BEGIN section. All SQL host
variables must be declared using the datatypes of the host language.
Outer Joins
The syntax for Informix outer joins differs from that of UDB’s syntax for outer joins.
Stored Procedures Calling Other Stored Procedures

UDB does not allow a stored procedure to call another stored procedure.
Triggers Calling Stored Procedures

UDB does not allow a trigger to call a stored procedure.
Stored Procedure Called From A Select List

UDB does not support a call to a stored procedure from a select list.
Matches Predicate
In UDB, the LIKE predicate should be used in place of MATCHES.
Temporary Tables
Informix allows a SELECT statement to select into a temporary table. Data inserted into a
temporary table is not logged or cataloged. UDB allows the use of a not logged initially
clause on CREATE TABLE. Summary tables may also be used.
Select UNIQUE
Informix uses SELECT UNIQUE and SELECT DISTINCT. UDB uses only SELECT
DISTINCT.
Page Locking
UDB does not have a lock type at the page level. A row or table should be used instead.
Isolation Levels
Isolation levels cannot be set in application programs. Isolation levels are specified at
bind time.
CR Isolation Level
UDB does not have a CR isolation level. UR should be used instead.
Stored Procedures
In UDB, stored procedures are written in a 3 GL such as C or COBOL. Stored procedures
must be converted from Informix’s SPL to one of UDB’s host languages.

Open Cursor With HOLD

Informix allows a cursor to stay open with hold even after a ROLLBACK. UDB closes the
cursor with HOLD whenever a ROLLBACK occurs.
Updateable Scrollable Cursors

UDB only allows scrollable cursors when using CLI. But CLI does not support updateable
scrollable cursors. Informix supports scrollable cursors in ESQL.
Dynamic SQL
All SQL in Informix is dynamic, but Informix calls SQL statements that are enclosed as
strings “dynamic SQL.” This is only important to note if an automated tool is used to
convert the application programs, in which case the way in which the tool handles this
type of SQL should be determined.
Fragmentation
UDB does not support fragmented or partitioned tablespaces or tables. A determination
should be made as to whether or not this database storage feature impacts the design of
the application.

Application Development and SQL Differences
Data Types Conversion

Most of the Informix data types can be converted to DB2 data types. The following table
maps Informix and DB2 data types:
Informix Data Type DB2 Data Type
CHAR(n) CHAR(n)
VARCHAR(n) VARCHAR(n)
TEXT CLOB(2GB)
INTEGER , INT INTEGER, INT
SMALLINT SMALLINT
DECIMAL(p,s) DEC(p,s) , DECIMAL(p,s)
FLOAT FLOAT
DOUBLE PRECISION DOUBLE PRECISION
MONEY NUMERIC(19,4)
SMALLMONEY NUMERIC(10,4)
BYTE BLOB(2GB)
DATETIME TIMESTAMP
DATE (MM/DD/YYYY) DATE (MM/DD/YYYY)
SERIAL not supported (see below)
INTERVAL not supported (see below)
Interval Data Type

UDB allows date/time arithmetic that can be used within a DB2 application to manipulate
DATE, TIME and TIMESTAMP fields to generate intervals of time. The following provides
an example of this procedure:
SELECT col1 FROM table 1 WHERE CURRENT DATE < (DATE1 + 10 YEARS);
Serial Data Type

DB2 does not support a serial data type. Use a trigger, as shown below, to generate a
sequential number.
CREATE TRIGGER AutoIncrement NO CASCADE BEFORE
INSERT ON Tablename
REFERENCING NEW AS n
FOR EACH ROW MODE DB2SQL
SET (n.key) = (SELECT value(MAX(key),0) +1) FROM Tablename

The "value(MAX(key),0)" statement will return the first non-null value. Thus, if the table is
empty, it will return 0 and increment it by one.
Host Variables Declaration

Host variables should be not only compatible with DB2 data types but also acceptable for
the programming language compilation. The following table maps appropriate C data
type to DB2 data types:
DB2 Data Type C Host Variable Declaration
CHAR(n) char hs_var[n+1]

VARCHAR(n) struct{short len;
char data[n]} varchar_var;
CLOB(2GB) SQL TYPE IS CLOB(n) v-name;
INTEGER, INT long int hs_var;
SMALLINT short int hs_var;
DEC(p,s) , DECIMAL(p,s) double hs_var;
FLOAT double hs_var;
DOUBLE PRECISION double hs_var;
BLOB(2GB) SQL TYPE IS BLOB(n) v_name;
TIMESTAMP char tms_var[27];
DATE char dt_var[11];
TIME char tm_var[11];
Embedding DB2/SQL into a C program or into a stored procedure written in C requires

that all host variables be declared in special declaration section. An example of this is
shown below:
EXEC SQL BEGIN DECLARE SECTION;
char v_firstname[31];
double salary;
long int ret_code=0;
EXEC SQL END DECLARE SECTION;
Outer Joins
The syntax for Informix outer joins differs from that of UDB’s syntax for outer joins. For
example, the Informix outer join statement:
SELECT c.cust_num, c.lname, d. call_dtime
FROM customer c, OUTER cust_calls d
WHERE c. cust_num = d.cust_num

Needs to be written for DB2 as follows:

SELECT c.cust_num, c.lname, d. call_dtime
FROM customer c LEFT OUTER cust_calls d
ON c. cust_num = d.cust_num
SELECT UNIQUE
Informix uses SELECT UNIQUE and SELECT DISTINCT. UDB uses SELECT DISTINCT
only.
Built-In Function
Both database products provide a variety of built-in functions. Some of these functions
are identical in Informix and DB2 UDB, some function the same, but have different
names. Informix has one built-in function that does not have match in DB2; however, it
can usually be converted to a DB2 user-defined function.
Embedded Static and Dynamic SQL

Embedding SQL statements into C programs is basically the same for Informix and DB2
UDB. In Informix you may prefix SQL statements with dollar signs ($) or ANSI standard
EXEC SQL. Only the EXEC SQL prefix is allowed in DB2. Both Informix and DB2 require
prefixing of the host variables by colons (:).
Compound SQL
To reduce network traffic and improve efficiency, DB2 provides a way for a program to
wrap two or more SQL statements into a bundle and send it to the server in a single
request. This bundle is called a compound SQL statement. Only static SQL statements
may be compound. DB2 distinguishes atomic and not atomic compound SQL.
For atomic statements, all individual statements inside the compound statement are
rolled back if any individual statement fails. If not atomic, the changes made by
successful statements within compound SQL statement remain effective even if some
individual statements are not successful. The following example illustrates use of
Compound SQL:
EXEC SQL
BEGIN COMPOUND ATOMIC STATIC
INSERT INTO org (dept, deptname, location)
VALUES (:dn, :dname,:dloc);
UPDATE employee
SET dept =:dn
WHERE empnum > :empnum;
END COMPOUND;

CLI/ODBC
The Call Level Interface (CLI) is based on Microsoft’s Open Database Connectivity
(ODBC) interface, supporting ODBC 3.0, Level 1, plus certain additional features. At
present, CLI is supported only for the C and C++ languages.
An advantage of CLI is that application programs that use it do not need to be
precompiled. An application written using CLI can be ported to other database systems
that support ODBC.
Java Database Connectivity (JDBC)

JDBC might be thought of as a CLI for the Java programming language. Its functionality
is equivalent to that of CLI, but in keeping with its host language, it uses an object-
oriented programming style. JDBC also allows for the development of applets, which can
be downloaded and run by Java-enabled web browsers, thus making the UDB data
accessible to any web-based client.
Triggers
DB2 has two types of triggers: BEFORE and AFTER. Informix triggers may be converted
to DB2 triggers with very few changes in syntax. The differences between Informix and
DB2 triggers are as follows:
• DB2 does not allow calls to stored procedures from the trigger, while Informix
does.
• Order of firing for DB2 triggers is based on creation time, while in Informix order
of firing can be coded.
• DB2 triggers can use the CASE expression, while Informix uses WHEN().
If the trigger body contains more than one SQL statement DB2 allows COMPOUND SQL
to be used. The SQL statements are enclosed between BEGIN ATOMIC and END, and
separated by semicolons.
Error Handling
DB2 and Informix use similar syntax for automatic exception testing:
EXEC SQL WHENEVER SQLERROR GOTO label;
Unlike Informix, however, DB2 cannot use call within WHENEVER statement.
To get diagnostics for an error, DB2 Universal Database provides a special run-time API
function to return an error message based on SQLCODE:
rc=sqlaintp(msg_buffer, 1024, 80, sqlca.sqlcode);
Note that sqlaintp requires that a large error message text buffer be defined and
available prior to the function invocation; e.g., char msg_buffer[1024].
Stored Procedures
Informix uses the SQL extension procedural language SPL as its stored procedure
language. The executable procedure and information about the procedure are stored on
the Informix database in the SYSPROCEDURES, SYSPROCBODY AND
SYSPROCPLAN tables as opposed to DB2 stored procedures which are stored on the

database server in a library. DB2 stored procedures can be written using most popular
programming languages: C, COBOL, Java, FORTRAN, REXX.
For DB2 stored procedures written in C, all SQL statements must be preceded by EXEC
SQL for the precompiler to distinguish them from native C statements. All Informix SPL
statements must be converted to the C statements. The following table maps SPL
statements to C statements:
Informix SPL Statements C Statements
let var = expression var = expession;

IF cond1 THEN statements if (condition) {C statements};
ELIF cond2 THEN statements else { C statements};
ELSE statements
END IF;
FOREACH curs_name FOR while ( SQLCODE !=100){
SELECT statement EXEC SQL FETCH c1....
statements statements
END FOREACH };
WHILE (condition) while(condition)
SPL statements { executable_C_statements};
END WHILE
BEGIN … END; (block of statements) {};
BEGIN …END; (compound) BEGIN…. END;
Calling DB2 Stored Procedure From Client Applications

DB2 client applications have two options for passing parameters to a stored procedure.
They can use host variables or explicitly use the SQL Dynamic Area (SQLDA) by
specifying the USING DESCRIPTOR clause. The CALL statement has the following
syntax:
CALL procedure_name (:host_var1, …:host_varn);
or
CALL procedure_name USING DESCRIPTOR host_var;
The parameters of the SQL CALL statement are treated as both input and output
parameters and are converted into an SQLDA structure with the number of variables
equal to the number of parameters on the CALL statement.
To avoid sending unnecessary data between the client and the server, the client
application should provide an indicator variable with each parameter and set the indicator
to –1 if the parameter is not used to pass data to a stored procedure (output-only). The
stored procedure should set the indicator variable to –128 for any input-only parameter
that is not used to return data from a stored procedure.
The client program allocates the SQLDA and SQLCA data structures and assigns values
to the input variables that are passed by the SQLDA. SQLVAR structure is part of
SQLDA and is provided for each parameter. The SQLVAR structures are used to

describe the data types, lengths and values for each parameter required in the order
specified in the parameter list of the CALL statement.
The SQLDA and SQLVAR data structures are described below:
struct sqlda
(
char sqldaid(8); /* contains ‘SQLDA ‘ */
long sqldabc; /* SQLDA size in bytes 44*SQLN */
short sqln; /* number of sqlvar elements=2 */
short sqld; /* # of host variables =2 */
struct sqlvar sqlvar[1] /* first sqlvar element */
);
struct sqlvar
(
short sqltype; /* typecode/datatype code */
short sqllen; /* length of data value */
char *sqldata; /* pointer to data value */
short *sqlind; /* pointer to Null indicator */
struct sqlname sqlname; /* variable name */
);
A stored procedure takes four parameters. Two parameters are used as pointers to the
SQLDA and SQLCA data structures. The other two parameters are unused, but still exist
to support DARI calling conventions from earlier DB2 releases. In C, the declaration of
the stored procedure would look like the following:
SQL_API_RC SQL_API_FN procname(
void *reserved1, /* not used */
void *reserved2, /* not used */
struct sqlda * inout_sqlda, /* input and output
*/
STRUCT SQLCA *OUT_SQLCA /* OUTPUT ONLY */
);
SQL_API_RC and SQL_API_FN are macros (defined in sqlsystm.h ) that expand in a

platform-dependent way to declare that the result type of the stored procedure as an
integer. The stored procedure accesses the data from the client program as follows:
à sqlvar[0].sqldata
inout_sqldaà /* data */
à sqlvar[0].sqlind
inout_sqldaà /* indicator value */

The stored procedure returns values to the client program by copying them into the
buffers pointed to by the SQLVARs and by copying a set of return codes into the SQLCA
structure pointed to by the out_sqlca.
Finally, the stored procedure ends by returning one of two possible integer codes which
are defined in sql.h: SQLZ_HOLD_PROC, indicating that the procedure should be
retained in memory for further invocations, or SQLZ_DISCONNECT_PROC, indicating
that the procedure should be removed from memory. These values are not returned to
the client program.
Installation of a Stored Procedure

Installing a stored procedure on the server machine is similar to building an application
program. All tables that the stored procedure accesses must exist before the stored
procedure can be installed. For AIX environment the steps are following:
1. Create export file spname.exp.
#! spname export file
spname
2. Connect to the database and precompile, compile and link the file with the stored
procedure. Use script bldxlcsrv provided with UDB in the sqllib/samples/c
directories.
3. Take the executable file resulting from the compile process and place it in the
directory on the server machine from which it will run. The default directory for
the stored procedure executable is named sqllib/function.
4. Grant the EXECUTE database privilege for the package created by the stored
procedure to other users. The package is created by binding the stprocs.sqc that
was created by the precompile and is stored on the database.
GRANT EXECUTE ON PACKAGE spname to PUBLIC:
5. Register the stored procedure by executing the CREATE PROCEDURE
statement on the database where the procedure will be used. The CREATE
PROCEDURE statement places entries in the SYSCAT.PROCEDURES and
PROCPARMS catalog tables. Two procedures may have the same name as long
as the schema names are different. Although registering the stored procedure is
only required if the stored procedure is written in Java, it is recommended that
the procedure always be registered.
The following is an example of the CREATE PROCEDURE statement:
CREATE PROCEDURE spname (IN n_updates INTEGER,

OUT update_list CLOB(8000),
INOUT result INTEGER)
EXTERNAL NAME ‘spname!server1’
LANGUAGE C
PARAMETER STYLE DB2DARI;

Converting Informix Stored Procedures to DB2
DB2 UDB Stored Procedure Overview

A UDB stored procedure consists of two programs:
• Stored procedure program, which resides as a dynamically loadable library on
the server
• Client program, which is used to invoke the stored procedure on the server
The client program, which can reside remotely, uses the CALL statement as either a
static embedded SQL statement or as dynamically prepared and executed CLI statement
(i.e., SQLPrepare(), SQLExecute() ) to pass input and output arguments to the stored
procedure at execution time. The stored procedure is compiled, linked into a DLL or
export library, and physically stored on the DB2 server.
A stored procedure is similar to a user-defined function, but unlike a UDF, stored
procedures may use SQL to access DB2 resources.
Stored procedures can be written in C/C++, Java, FORTRAN, COBOL, REXX and IBM’s
VisualAge for Basic. Implementation of Java and Basic stored procedures vary somewhat
from implementations for the other host languages.
Data is exchanged between the client application and the stored procedure using the
SQLDA data structure or host variables. An SQLCA data structure is also passed to
communicate the success or failure of any SQL statements contained in the stored
procedure.
The stored procedure returns an integer return code to ensure that the library is released
on the DB2 server. This return code is not returned to the calling client application.
Stored procedures can be fenced or not fenced. A fenced procedure executes as a
separate process from the database server process and is the recommended mode of
execution. Special database privileges are required to execute the procedure as not
fenced.
The Client Program

An application running on the client machine can invoke a stored procedure on the server
machine by using the CALL statement. The CALL statement names the procedure to be
called and specifies its parameters. The parameters are specified in the form of a list of
host variables, which UDB will automatically pack into an SQLDA structure. Alternatively,
the DESCRIPTOR syntax of the CALL statement can be used to create the SQLDA to be
passed to the stored procedure.
A CALL statement cannot be executed from an interactive interface such as the
Command Center. Nor can it be executed by using the Embedded Dynamic SQL
statements PREPARE and EXECUTE.
The name of stored procedure can be specified explicitly or represented as a host
variable in the CALL statement. The procedure name is folded to uppercase unless it is
enclosed in double quotes.
Note: The case of the procedure name must match that used in the CREATE
PROCEDURE statement. The CREATE PPOCEDURE statement is described starting on
page 47.

In a CALL statement, the arguments passed to the stored procedure must be host
variables. The host variables are defined in the EXEC SQL BEGIN DECLARE SECTION
of the client program. The following is an example of the CALL statement in an
embedded static SQL program:
EXEC SQL CALL “stprocs!server1”(:x :xind, :y :yind);
The procedure named in the above example of the CALL statement is stprocs!server1.
The name of the file where the procedure is found is stprocs and the name of the entry
point for the procedure is server1. A host variable may be used for the name of the
procedure.
The same example CALL statement passes two variables (:x, :y), each with a null
indicator variable (:xind, :yind). An SQLDA structure will be dynamically allocated that will
have two SQLVAR structures, SQLVAR[0] and SQLVAR[1]. The SQLVAR structures are
used to describe the datatypes, lengths and values for each parameter required in the
order they are specified in the parameter list of the CALL statement.
The SQLDA and SQLVAR data structures are described below:
struct sqlda
(
char sqldaid(8); /* contains ‘SQLDA ‘ */
long sqldabc; /* SQLDA size in bytes=16+44*SQLN */
short sqln; /* number of sqlvar elements=2 */
short sqld; /* # of host variables =2 */
struct sqlvar sqlvar[1] /* first sqlvar element */
);
struct sqlvar
(
short sqltype; /* typecode/datatype code */
short sqllen; /* length of data value */
char *sqldata; /* pointer to data value */
short *sqlind; /* pointer to Null indicator */
struct sqlname sqlname; /* variable name */
If a parameter is used only for input and not output, a null indicator variable must be
assigned to the parameter. The stored procedure program assigns a NULL value to that
parameter indicating that no data is returned.
If a parameter is used only for output and no input data is passed, the client should
assign the null indicator variable for that variable to a –1 to indicate that no data is
passed.
The C declarations for the SQLDA structures can be found in sqllib/include/sqlda.h on the
UDB AIX server.
If a full path name for the procedure is not provided in the CALL statement, UDB first
searches the default directory sqllib/function. If not found, UDB then searches the

PROCEDURES catalog table for a stored procedure that was registered with the name
used in the CALL statement.
No special installation procedures are required for the use of the client program. Simply
precompile, compile and bind it as for any other UDB application program.
The Server Program

The server program uses the SQLDA data structure for receiving input data from the
client program and for returning results to the client program. An SQLCA data structure is
used to pass messages back to the client program to indicate the success or failure of
the SQL statements in the procedure.
A stored procedure takes four parameters. Two parameters are used as pointers to the
SQLDA and SQLCA data structures. The other two parameters are unused in UDB
Version 5, but still exist to support stored procedure calling conventions from earlier DB2
releases. In ‘C’ the declaration of the stored procedure would look like the following:
SQL_API_RC SQL_API_FN procname(
VOID *DUMMY1, / NOT USED */

void *dummy2, /* not used */
struct sqlda * exchange_da, /* input and output */
struct sqlca *out_sqlca /* output only */
);
SQL_API_RC and SQL_API_FN are macros (defined in sqlsystm.h ) that expand in a

platform-dependent way to declare that the result type of the stored procedure is an
integer.
The client program allocates the SQLDA and SQLCA data structures and assigns values
to the input variables that are passed by the SQLDA. The SQLDA contains entries that
include datatypes, lengths and addresses of each parameter to be passed. Several input
and output parameters can be contained by the SQLDA. The SQLDA will contain an
SQLVAR structure for each parameter required.
The stored procedure accesses the data values passed to it from the client Program as
follows:
exchange_da à sqlvar[0].sqldata /* data */
exchange_da à sqlvar[0].sqlind /* indicator value
*/
The stored procedure returns values to the client program by copying them into the
buffers pointed to by the SQLVARs and by copying a set of return codes into the SQLCA
structure pointed to by the out_sqlca.
If an entry contained by the SQLDA is not to be used for returning a value, that entry is
assigned a null value by assigning the sqlind field of the SQLVAR the value of –128.
The server program defines a local copy of the SQLCA structure to capture the return
codes of SQL statements using the EXEC SQL INCLUDE SQLCA statement.
The stored procedure does not issue the CONNECT statement but relies on a connection
established by the client program. A stored procedure can issue a COMMIT or

ROLLBACK only if the client issued a type 1 connection (a non-distributed unit of work).
Since the stored procedure runs in the same transaction as the client program, any
commit or rollback also affects any changes performed by the client program since the
last commit.
A stored procedure cannot issue printf statements since it runs in background mode.
Finally, the stored procedure ends by returning one of two possible integer codes which
are defined in sql.h: SQLZ_HOLD_PROC, indicating that the procedure should be
retained in memory for further invocations, or SQLZ_DISCONNECT_PROC, indicating
that the procedure should be removed from memory. These values are not returned to
the client program.
Return(SQLZ_DISCONNECT_PROC);
Installing a Stored Procedure

Installing a stored procedure on the server machine is similar to building an application
program. All tables that the stored procedure accesses must exist before the stored
procedure can be installed.
1. Create a module definition file that lists all the entry points (functions) that are
exported by the file containing the stored procedure. A single file can implement
multiple stored procedures. The module definition file should be in the same
directory as the stored procedure source file. The name and format of the module
definition file are platform and compiler specific.
2. Create a module definition file. The way in which this procedure is performed
depends on the platform and compiler being used. Two examples are provided
below:
On Windows NT…
Suppose a source file named stprocs.c contains two stored procedures named
server1 and server2. If using the Microsoft Visual C++ compiler, a module
definition file named stprocs.def should be created with the following contents:
LIBRARY stprocs
EXPORTS server1
Server2
On AIX…
The module definition file is called an export file. If using the IBM XLC compiler,
an export file named stprocs.exp should be created with the following contents:
#! Stprocs export file
server1
server2
3. For each database will execute the stored procedure:
a. Connect to the database and precompile, compile and link the file with the
stored procedure. Use the command files provided with UDB in the
sqllib/samples/c directories.
Bldmsstp.bat can be used with the Microsoft Visual C++ compiler on Windows NT
Bldxlcsrv and be used with the IBM XLC compiler on AIX.
b. Modify required these files with the include and link libraries. These files
require four parameters: the name of the stored procedure, the name of the

database on which it is to be installed, and the userid and password under

which it is to be installed.
4. Place the executable file resulting from the compile process, on Windows NT the
stprocs.dll file, on AIX just stprocs, in the directory on the server machine from
which is will run. The default directory for the stored procedure executable is
named sqllib/function. Make the file executable. (chmod a+x stprocs)
5. Grant the EXECUTE database privilege for the package created by the stored
procedure to other users. The package is created by binding the stprocs.sqc that
was created by the precompile and is stored on the database. This privilege can
be granted interactively using the UDB Command Center.
GRANT EXECUTE ON PACKAGE stprocs to PUBLIC:
6. Register the stored procedure by executing the CREATE PROCEDURE
statement on the database where the procedure will be used. The CREATE
PROCEDURE statement places entries in the SYSCAT.PROCEDURES and
PROCPARMS catalog tables. Two procedures may have the same name as long
as the schema names are different. Although registering the stored procedure is
only required if the stored procedure is written in Java, it is recommended to
always register the procedure.
The following is an example of the CREATE PROCEDURE statement:
CREATE PROCEDURE SCORESHEET (IN n_updates INTEGER,
OUT update_list CLOB(8000),
INOUT result INTEGER)
RESULT SETS integer /* only used in CLI */
EXTERNAL NAME ‘stprocs!server1’
LANGUAGE C
PARAMETER STYLE DB2DARI;
The CREATE PROCEDURE statement can be executed either interactively or in a script

by using the Command Center component of the UDB Control Center.
The CREATE PROCEDURE statement lists the names and datatypes of the parameters
of the procedure. These parameters correspond to the arguments of the CALL statement
used to invoke the procedure. The parameters also correspond to the individual SQLVAR
entries inside the SQLDA structure that is passed to the procedure program. Each
parameter is labeled IN, OUT, or INOUT, which indicate whether the parameter is to be
passed into the procedure, out from the procedure or passed in and out of the procedure.
In addition to returning data to the client program through its OUT and INOUT
parameters, a stored procedure can return one or more result sets to the client program.
Each result set is a set of rows, represented by a cursor that is left open by the stored
procedure. This can be only be implemented by using CLI call statements. Result sets
are beyond the scope of this paper.
The EXTERNAL clause tells UDB how to find the executable program that implements
the stored procedure. The EXTERNAL clause gives the full path name of the executable
file, followed by a “!”, then by the name of the proper entry point in that file. The above
CREATE PROCEDURE example assumes that “stprocs!server1” exists in the default
directory, sqllib/function. If the executable does not exist in the default directory, the full
path name is required.

Stored Procedure Differences
Informix stored procedures are written in an SQL procedural language known as SPL.
The executable procedure and information about the procedure are stored on the
Informix database in the SYSPROCEDURES, SYSPROCBODY AND SYSPROCPLAN
tables as opposed to UDB stored procedures, which are stored on the database server in
a library.
Unlike Informix’s embedded SQL, which is parsed, optimized and executed dynamically
at run-time, Informix’s stored procedures are precompiled, and an optimized execution
plan is stored in the database for future use. When an Informix stored procedure is called
for the first time, the plan is simply cached and executed. Since Informix’s stored
procedures are precompiled, they are similar to the way UDB’s static embedded SQL is
implemented.
An Informix stored procedure is created using the CREATE PROCEDURE command.
This command can be run from DBACCESS, Informix’s interactive interface. Unlike UDB,
where the CREATE PROCEDURE statement is used primarily to document the
procedure and define the parameter list, the Informix CREATE PROCEDURE statement
contains the entire body of the procedure code, including the SPL, and is used to install
the procedure on the database. The Informix CREATE PROCEDURE command parses,
optimizes, builds and stores the execution plan in the database. The procedure’s source
code is also stored in the Informix database’s catalog tables. UDB stored procedures are
compiled and linked in the same way that other application programs are built.
Any user that has the DBA or RESOURCE privilege may create a stored procedure and
may grant other users the privilege to execute the procedure. When creating UDB stored
procedures, only unfenced procedures require the SYSADM, DBADM or a special create
unfenced procedure privilege.
The Informix stored procedure can be executed from an ESQL, Informix 4GL, or
Powerbuilder programs or from DBACCESS using the EXECUTE PROCEDURE
statement. In UDB, the stored procedure is executed from a client program by using the
CALL statement.
Variables can be passed into the stored procedure at run-time by the calling program
using the EXECUTE PROCEDURE statement with a parameter list. The EXECUTE
PROCEDURE parameter list may contains data values, as well as host variables. In
contrast, the UDB parameter list must contain only host variables. When passing
parameters, the Informix CREATE PROCEDURE statement must define a matching
parameter list with datatypes for each of the input parameters passed into the procedure.
Output variables are returned to the calling program by using a CREATE PROCEDURE
command with a RETURNING clause that defines the datatype for each parameter to be
returned. A RETURN statement with a parameter list in the body of the procedure is used
to return the values. With UDB stored procedures, both input and output parameters are
passed by using the SQLDA data structure. The following is an example of an Informix
CREATE PROCEDURE command:
CREATE PROCEDURE read_many (lastname char(15))
RETURNING char(15), char(20);
DEFINE a char(15);
DEFINE b char(20);
……..
RETURN a, b;

Variables in Informix’s stored procedures are declared by using the SPL DEFINE
statement. Variables in UDB’s stored procedures are defined in the EXEC SQL
DECLARE BEGIN section. Host variables used in SQL statements in the procedure are
not required to have semicolons, and SQL statements in the procedure are not preceded
by EXEC SQL. UDB stored procedures require host variables with semicolons in SQL
and EXEC SQL precedes each SQL statement.
Informix stored procedures can call other Informix stored procedures, and can be called
from a SELECT list and a trigger. UDB stored procedures cannot be called from a trigger
or SELECT list, and a UDB stored procedure cannot be called from within another UDB
stored procedure. When converting a nested Informix stored procedures to UDB stored
procedures, the nested Informix procedure can be converted to a UDB ‘C’ application
with embedded SQL. The only drawback to this method is that the nested ‘C’ function is
not truly a UDB stored procedure and, therefore, cannot be directly invoked as a stored
procedure from a client program.
Informix procedures can also return multiple sets of values when using a cursor. Only
UDB stored procedures that use CLI calls to the procedure can return multiple result sets.

Example of Converted Stored Procedure
/* Informix stored procedure source

--------------------------------
drop procedure read_cust;
create procedure read_cust (c_num int)

returning char(15), char(15);
define v_lname, v_fname char(15);
select lname, fname into v_lname, v_fname from customer where customer_num
=c_num;
return v_lname, v_fname;
end procedure
*/
/* DB2 stored procedure Source (converted to Embedded Static SQL in C)

------------------------------------------------------------------- */
#include <sqlenv.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <memory.h>
SQL_API_RC SQL_API_FN proc2(

void *dummy1,
void *dummy2,
struct sqlda *exchange_da,
struct sqlca *out_sqlca)
{
EXEC SQL INCLUDE SQLCA;

long c_num;
char v_lname[16];
char v_fname[16];
EXEC SQL WHENEVER SQLERROR GOTO errorExitL;

EXEC SQL WHENEVER SQLWARNING CONTINUE;

FILE * fp;
fp = fopen("proc2.out", "w+");
fprintf (fp, " Server SP: Begin log file (optional) \n");
/* read SQLDA input values */

c_num = *(long *)(exchange_da->sqlvar[0].sqldata);
fprintf (fp, " Server SP: customer_num = %d \n", c_num);

EXEC SQL SELECT lname, fname INTO :v_lname, :v_fname FROM informix.customer
WHERE customer_num = :c_num;
fprintf (fp, " Server SP: v_lname = %s \n", v_lname);

fprintf (fp, " Server SP: v_fname = %s \n", v_fname);
/* -- update SQLDA with return values ... and */

/* -- set ind var for input only parms to -128 */
*(short *)(exchange_da->sqlvar[0].sqlind) = -128;
strcpy((char *)(exchange_da->sqlvar[1].sqldata), v_lname);
strcpy((char *)(exchange_da->sqlvar[2].sqldata), v_fname);
errorExitL:
fprintf (fp, " Server SP: End log file \n");
fclose (fp);
memcpy((char *)out_sqlca, (char *)&sqlca, sizeof(struct sqlca));

Example of Client Program Calling a DB2 Stored Procedure
#include <sqlenv.h>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
int main()
{
EXEC SQL INCLUDE SQLCA;

long c_num;
char v_lname[16];
char v_fname[16];
short c_num_ind;
short v_lname_ind;
short v_fname_ind;
EXEC SQL WHENEVER SQLERROR GOTO errorExitL;

EXEC SQL WHENEVER SQLWARNING CONTINUE;
EXEC SQL CONNECT TO stores7 user informix using informix;
c_num = 125;
v_lname_ind = -1;
v_fname_ind = -1;
/* -- good practise to initialize ind var ... and */
/* -- set ind var for output only parms to -1 */
printf ("Client: c_num = %d \n", c_num);

printf ("Client: -> Calling Server Stored Procedure ... \n");
EXEC SQL CALL proc2(:c_num :c_num_ind, :v_fname :v_fname_ind, :v_lname

:v_lname_ind);
/* -- emp_id must be passed in if setting empid ind var to NULL in SP */
printf ("Client: <- Return from Server Stored Procedure ... \n");
printf ("Client: lname = %s \n", v_lname);
printf ("Client: fname = %s \n", v_fname);

EXEC SQL COMMIT WORK;

EXEC SQL CONNECT RESET;
return (0);
errorExitL:
printf ("Client: *** Error ... SQLCODE = %d \n", SQLCODE);
EXEC SQL ROLLBACK WORK;
EXEC SQL CONNECT RESET;
return (-1);
}

Trademarks
The following terms are trademarks or registered trademarks of the IBM Corporation in
the United States and/or other countries:
AIX IMS
AIXwindows MVS/ESA
AS/400 MVS/XA
C Set++ OS/400
C/370 OS/390
DATABASE 2 OS/2
DataJoiner RISC System/6000
DataPropagator SQL/DS
DataRefresher SQL/400
DB2 S/370
DB2 Connect System/370
DB2 Universal Database System/390
DB2 OLAP Server VisualAge
Distributed Relational Database VM/ESA
Architecture VSE/ESA
DRDA VTAM
IBM WIN-OS/2
The following terms are trademarks or registered trademarks of the companies listed:
Java and all Java-based trademarks and logos are trademarks or registered trademarks
of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, Windows 95 and the Windows 98 are trademarks or
registered trademarks of Microsoft Corporation in the United States, other countries, or
both.
UNIX is a registered trademark in the United States, other countries, or both and is
licensed exclusively through X/Open Company Limited.
Other trademarks and trade names mentioned herein are the property of their respective
owners.

Informix To DB2 Migration White Paper

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Informix To DB2 Migration White Paper

Transféré par

Droits d'auteur :

Formats disponibles

Informix to DB2 Migration

Comparison White Paper

Software Migration Project Office

WHY MIGRATE TO DB2 UDB ? .............................................................................................................. 2

© IBM Corporation Page i

CONFIGURING AND CONNECTING CLIENTS ............................................................................................... 18

© IBM Corporation Page ii

SELECT UNIQUE ................................................................................................................................... 37

© IBM Corporation Page iii

The document is divided into two sections:

© IBM Corporation Page 1

Why Migrate to DB2 UDB ?

• Integrated support for Windows NT

Each of these is described in detail below.

Integrated support for Windows NT

DB2 UDB conforms to Windows NT standards. It maps closely onto Windows NT

Integrated System Management Tools

© IBM Corporation Page 2

• Command Center, to enter DB2 commands and SQL statements in an interactive

Figure 1 Control Center Main Window

© IBM Corporation Page 3

• DB2 Universal Database V5 replication tools – the Control Center replication

Integrated Web Access

Integrated Support for Complex Data

© IBM Corporation Page 4

Integrated Support for Development Environments

IBM Solution Developer Program

Benefits offered by this program include the following:

© IBM Corporation Page 5

DB2 Universal Database Product Family

Figure 2 DB2 UDB Connectivity

© IBM Corporation Page 6

The DB2 UDB products and components include:

• DB2 Personal Edition

DB2 Universal Database Personal Edition

DB2 Universal Database Workgroup Edition

DB2 Universal Database Enterprise Edition

DB2 Universal Database Extended Enterprise Edition

© IBM Corporation Page 7

DB2 Software Developer's Kit (DB2 SDK)

• Embedded SQL, both static and dynamic

DB2 SDK supports several programming languages (including COBOL, FORTRAN,

© IBM Corporation Page 8

DB2 UDB and Informix Differences Overview

High Level Differences

DB2 Universal Database DB2 UDB

© IBM Corporation Page 9

Additional DB2 servers

Informix Web Integration Option

© IBM Corporation Page 10

Application Development Support

© IBM Corporation Page 11

© IBM Corporation Page 12

© IBM Corporation Page 13

© IBM Corporation Page 14

© IBM Corporation Page 15

© IBM Corporation Page 16

© IBM Corporation Page 17

Configuring And Connecting Clients

© IBM Corporation Page 18

Embedded SQL Development

© IBM Corporation Page 19

© IBM Corporation Page 20

STRUCT SQLCA OUT_SQLCA / OUTPUT ONLY */

VOID DUMMY1, / NOT USED /