Filter
Top Products
systems and security folks. This is not to say that differences do not exist, just
that they are minor and should not be perceived by most end users. QMF users
should see virtually no differences. The one possible exception is the
TRANSLATE scalar function which is not supported by DB2.
8.2.1.2 Application Developers
While end users will see little or no differences, application developers can
expect to see more differences between the two products. However, it is
important to realize that the basic job of developing an application is the same.
•
Developers can use the same design process.
•
The method of making an SQL call in a program is the same (through the
use of the EXEC SQL statement).
•
The operators - DECLARE, OPEN, FETCH and CLOSE - are the same. These
are statements used in application programs to handle cursors.
•
Application program preparation using precompile and bind is essentially the
same - very few differences.
Both products have facilities to enter one or more SQL statements at a terminal
for execution against a relational database. This could be done for testing or to
do some work without having to write a program, for example, a one time
requirement. In SQL/DS this facility is called ′
ISQL
′ that runs under CICS/VSE
and in DB2 it is called ′
SPUFI
′ and runs under ISPF in TSO. SPUFI does not have
the limited answer set formatting and printing capability of ISQL.
Application developers should consider that while the program preparation
process is similar, some differences exist. For example, DB2 preparation occurs
in two phases - precompile and bind. For SQL/DS both phases are done in the
same step. Because of DB2′s separation of these functions, the database does
not need to be available during the precompile phase. SQL/DS does have the
ability via the DBSU to UNLOAD and LOAD packages. DB2 does not have a utility
capable of unloading and loading a package. If you are using this SQL/DS
capability, you will need to save the DB2 DBRM or preprocess the program
again to create the DB2 DBRM.
For application programming languages, DB2 supports all of the languages
supported by SQL/DS except RPG. It should be noted however, that SQL/DS
V3R5 was the last release which provided this support; it was dropped in V5.
There are some minor variations in the application programming interfaces for
the two products. For example, the meaning of SQLCODE values other than 100,
0, -803, and -911 is product specific. Thus, how an application program′s logic
handles SQLCODEs other than these will need to be examined and modified
appropriately. A major improvement was provided with the introduction of
DB2/VSE V5: SQLSTATEs are now at the SQL92 level as is DB2/OS390. That
means that an application can use the SQLSTATE to determine an error and that
the SQLSTATE is no longer platform specific.
Besides differences in SQL return codes, other differences exist in the SQLCA
(SQL Communications Area) following a negative SQL return code. The SQLCA
has a number of fields that indicate the condition of the most recently executed
SQL statement. You should update your program logic that processes, records,
and displays this information.
Chapter 8. Databases 179