DB2 Server for VSE System Administration (Version 7 Release 5) - page 9
Syntax
►► SQLDBDEF
ID
(userid) PW
(pw) Target
(
OS390
)
►
DBname
(dbname)
OS400
OTHER db2 udb
VSE
VM
Grants (YES)
Storedprocs (YES)
►
►◄
Grants (NO)
Storedprocs (NO)
DBspaces
(*)
NOPRint
DBSpaces
(dbsp_vals)
Objects
(
object-types
)
object-types:
Dbspaces
Auth (YES)
Tables
Auth (NO)
Synonyms
Indexes
Views
Figure 126. SQLDBDEF Utility
The job control member ARIS215D is provided to invoke the SQLDBDEF utility.
The following is a sample invocation:
// JOB SQLDBDFJ
// LIBDEF *,SEARCH=(PRD2.DB2730)
// EXEC REXX=SQLDBDEF PARM=’DB(DB2VSE) ID(userid) PW(password)’
/*
/&
Description
The parameters for the SQLDBDEF utility are as follows:
DBname (dbname)
dbname is the DB2 Server for VSE & VM database from which SQL object
definitions will be extracted. If the DB parameter is not specified, the database
currently defined as the default in the DBname directory will be used.
ID (userid)
userid is the connect ID to be used when running the SQLDBDEF utility. The
user ID must have DBA authority in order to load the package.
The ID parameter is required in VSE.
PW (pw)
pw is the connect password to be used when running the SQLDBDEF utility.
Like the ID parameter, the PW parameter is required in VSE.
Target (OS390), Target (OS400), Target (OTHER db2 udb), Target (VSE), Target
(VM)
This parameter indicates the platform on which the target database runs.
382
System Administration
OS390 indicates that the output DBSU job will be run on a DB2 database on
MVS, OS/390, or z/OS. OS400, VSE, and VM indicate that the output DBSU
job will be run on a DB2 database on OS/400, VSE, or VM respectively.
OTHER db2 udb indicates that the output DBSU job will be run on a DB2
database on an Intel™ or UNIX platform, for example, Windows, AIX, or Linux.
Grants (YES) Grants (NO)
The Grants parameter determines whether GRANT statements for user
authorities should be generated. Note that for GRANT CONNECT statements,
the passwords in effect on the source system will not be displayed in the
output DBSU job. Instead, the string ″<PW>″ will be displayed. The default is
YES, which causes the utility to generate the GRANT statements.
Storedprocs (YES), Storedprocs (NO)
The Storedprocs parameter determines whether CREATE PROCEDURE
statements and (if the target platform is VM or VSE) CREATE PSERVER
statements are to be generated. The default is YES, which causes the utility to
generate these CREATE statements.
DBSpaces (*), DBSpaces (dbsp_val)
This parameter indicates that the SQLDBDEF utility is to generate SQL
statements to recreate all objects in one dbspace or in all dbspaces. If this
parameter is specified, the utility extracts dbspace, table, view, synonym, and
index definitions, as well as table and column privileges, from the system
catalog.
If ″*″ is specified, the output DBSU job contains SQL statements to recreate all
objects in all dbspaces, and the statements are grouped by dbspace.
If dbsp_val is specified, the output DBSU job contains SQL statements to
recreate the objects in that dbspace only. Dbsp_val can be a dbspace number or
a qualified or unqualified dbspace name. If an unqualified dbspace name is
provided, SQLDBDEF looks first for a private dbspace with the specified name
that is owned by the connected user. If no private dbspace is found,
SQLDBDEF looks for a public dbspace with the specified name.
Note that either the DBSpaces parameter or the Objects parameter can be
specified, but not both. If neither is specified, the SQLDBDEF utility does not
generate SQL statements to create dbspaces, tables, synonyms, indexes, or
views.
Objects (*), Objects (Dbspaces), Objects (Tables), Objects (Synonyms), Objects
(Indexes), Objects (Views)
This parameter indicates that the SQLDBDEF utility is to generate SQL
statements to recreate one particular type of object, or all objects.
If ″*″ is specified, the output DBSU job contains SQL statements to recreate all
object types, and the statements are grouped by object type.
If a specific object type is specified, the output DBSU job contains SQL
statements to recreate objects of that type only.
Note that either the Objects parameter or the DBSpaces parameter can be
specified, but not both. If neither is specified, the SQLDBDEF utility does not
generate SQL statements to create dbspaces, tables, synonyms, indexes, or
views.
Auth (YES), Auth (NO)
If you are generating SQL statements to create all table objects, you can direct
the SQLDBDEF utility to generate SQL statements to GRANT existing table
Appendix G. Service and Maintenance Utilities
383
and column privileges as well. The Auth parameter determines whether
GRANT statements for table and column privileges are generated. The default
is YES.
NOPRint
Specifying NOPRint indicates that no listing file is to be generated. If NOPRint
is not specified, a listing file is sent to SYSLST.
The utility generates a DBSU job that can be run to create the database objects (or
equivalent objects) on the target database. In order to do this, it must map
platform specific SQL statements to their equivalents on the target platform. For
example, if the target database is DB2 UDB for OS/390, ACQUIRE DBSPACE
statements are mapped to CREATE TABLESPACE.
For SQL clauses that are the same for both the source and target database, the
value that was specified for the source database will be used. SQL clauses that can
be specified on the target database but are not applicable on the source database
do not appear in the generated SQL statement. SQL clauses that can be specified
on the source database but are not applicable on the target database do not appear
in the generated SQL statement.
The listing goes to SYSLST, and the DBSU job goes to SYSPCH.
Customize the output DBSU job as follows:
1. Ensure that the CONNECT statement specifies the userid and password of a
user who has DBA, DBADM, or SYSADM authority (depending on the target
platform).
2. Provide valid passwords on the GRANT statements, if applicable.
3. Ensure that the user authorities being granted are appropriate for your
installation.
4. Ensure that the CREATE TABLESPACE and ACQUIRE DBSPACE statements
are appropriate for your installation.
It is recommended that you review the entire DBSU job prior to running it, to
verify that the objects it will create are appropriate for your installation.
384
System Administration
Appendix H. DRDA Considerations
Users who are planning to design applications that
v run on non-VSE platforms and use the Distributed Relational Database
Architecture (DRDA) protocol to connect to DB2 Server for VSE & VM servers,
or
v run on VSE/ESA and use the Distributed Relational Database Architecture
(DRDA) protocol to connect to servers other than DB2 Server for VSE & VM
need to be aware that DB2 Server for VSE & VM’s support of SQL does not exactly
match the IBM SQL standard6 or the SQL Entry Level standard.7 This appendix
attempts to provide some guidance in discrepancies to these standards.
Omissions from the Standards
For a list of where DB2 Server for VSE & VM does not support the IBM SQL or
SQL92 entry level standards, please consult the DB2 Server for VSE & VM SQL
Reference manual.
Extensions to the Standards
1.
There is no support for modifiable packages created by using extended
dynamic statements. If you request such support by specifying the MODIFY
option on the CREATE PACKAGE statement, the system will override this
option with NOMODIFY.
2.
Nonmodifiable packages created by using extended dynamic statements are
supported with the following restrictions:
a. There is no support for the positioned UPDATE and positioned DELETE
statements.
b. If the Basic Extended PREPARE form of the extended PREPARE statement
prepares a statement that contains parameter markers, the USING
DESCRIPTOR clause must be used to identify an input SQLDA structure.
c. There is no support for the Single Row Extended PREPARE form of the
extended PREPARE statement.
d. There is no support for the NODESCRIBE option of the CREATE PACKAGE
statement. If specified, it will be ignored.
e. There is no support for “USER” in the ISOLATION option of the CREATE
PACKAGE statement. The system will override USER with CS.
f. There is no support for “LOCAL” in the DATE or TIME option of the
CREATE PACKAGE statement. If specified, SQLCODE -168 (SQLSTATE
42615) will be generated, indicating an incorrect parameter.
g. DB2 Server for VSE & VM servers do not support cursors declared with the
“WITH HOLD” clause. However, applications may use the “WITH HOLD”
clause against other DRDA servers if they support it, except when extended
dynamic statements are involved.
6. IBM SQL is a superset of the SQL92 Entry Level standard
7. Entry Level of the International Organization for Standardization (ISO) 9075-1992 Database Language SQL specification
385
3. There is no support for the semantics checking of the Flagger, but the syntax
checking of static SQL against the SAA and SQL-89 standards will still be
carried out.
DB2
Server for VSE Facility Restrictions
1.
There is no support for “USER” in the CBND parameter ISOLATION. When
specified, the system will override USER with CS.
2.
There is no support for “LOCAL” in the CBND parameters DATE and TIME.
When specified, the remote DRDA application server will return SQLCODE
-168
(SQLSTATE 42615).
3.
In a private flow environment, there is no support for the blocking of PUTs.
However, the PUT operation will still be supported one row at a time as
unblocked inserts. In a DRDA flow environment with the DB2 Server for VSE
Batch AR, no blocking is provided on a PUT. Each PUT will result in the
execution of a single INSERT. Therefore, if large amounts of data are loaded
into a remote server, it may be better to transfer the data through some other
means to the target site, and then use the local utility to load the data into the
database.
4.
The following ISQL commands are not supported when ISQL is connected to
a remote DRDA application server, because they request functions or depend
on the DB2 Server for VSE system catalogs:
v SET ISOLATION
v COUNTER
v SHOW.
When ISQL is connected to a remote application server and a long-running
SQL statement is processed. ISQL will NOT display message ARI7044I to
allow the user to enter ISQL CANCEL to cancel the long-running SQL
statement. The user cancel exit is not supported on DRDA connections.
5.
The DRDA Online Resource Adapter does not provide the user cancel exit to
allow online DRDA applications to perform a CANCEL function. For example,
a long-running SQL statement cannot be cancelled on a remote connection.
6.
The DRDA Online Resource Adapter does not call ARIUXIT when a CICS user
tries to connect to a remote DRDA application server either implicitly or
explicitly and the accounting exit is link-edited in AMODE 24.
If the accounting exit is link-edited in AMODE 24 and the CICS user tries to
connect to a remote DRDA application server, SQLCODE=-947 will be
generated, indicating ARIUXIT in AMODE 24 is not supported.
7.
If accounting data is sent from a DRDA application requester to a DB2 for
VSE & VM server, only the first 16 bytes of user-defined data8 is captured by
the server and put into accounting records.
8.
The current CICS/VSE implementation provides no facility for establishing
APPC conversations that use a security level of PGM (for example, a user ID
and password are required to allocate the conversation). CICS transactions can
only establish SECURITY=SAME conversations to remote APPC partners.
Due to this limitation, DB2 Server for VSE online application requester may
use the ″userid IDENTIFICATION BY password″ clause on the CONNECT
statement when connecting to a remote application server. In this case, the
VSE online application requester performs DRDA security checking as
described in the Distributed Relational Database Architecture Reference manual.
8. For example, from DDCS for OS/2 user-defined data can be set by the DFT_ACCOUNT_STR configuration parameter.
386
System Administration
This check will be performed during handshaking after having established an
APPC conversation with a DRDA server that supports security handshaking.
9. A user must sign on to CICS first before executing a transaction that accesses
a remote DRDA application server. If a user failed to sign on to CICS and
executes a transaction to access a remote DRDA application server, the connect
will fail because CICS passes a null user ID to the remote system, which is
invalid. DRDA does not support security NONE.
10. The following DBSU commands are not supported when using the DRDA
protocol, because they request functions specific to DB2 Server for VSE:
v UNLOAD DBSPACE
v UNLOAD TABLE
v UNLOAD PACKAGE
v RELOAD DBSPACE
v RELOAD TABLE
v SET ISOLATION
v SET UPDATE STATISTICS
v REBIND PACKAGE
v REORGANIZE INDEX
Appendix H. DRDA Considerations
387
Appendix I. Incompatibilities Between Releases
This appendix identifies the incompatibilities that exist between each release of the
product and the previous release, going back to Version 1 Release 3.5. There is a
separate section in the appendix for each release.
Note on Skipping Releases: If your migration plans call for skipping one or more
releases (for example, migrating directly from V2R2
to V3R4), you will still be affected by the
incompatibilities introduced by the releases that you
are skipping.
Within each section, the incompatibility items are grouped into the following
categories:
v SQL and Data
v Application Programming
v System Environment
Definition of an Incompatibility
For the purpose of this appendix, an “incompatibility” is defined to be a part of
the product that works differently than it did in the previous release, in such a
way that if used in an existing application, it will produce a different result,
necessitate a change to the application, or reduce performance. In this definition,
“application” can apply to a broad range of things (singly or in combination), such
as:
v Application program code
v Specifications for preprocessing application programs
v Interactive SQL queries
v ISQL functions
v DBS Utility functions
v Miscellaneous tools in your operating environment.
This appendix does not describe incompatibilities where certain operations in the
current release are less likely to generate an error condition than they did in the
previous release, as those changes will only have a positive impact on your
applications. (For example, the SUM and AVG column functions no longer
overflow as easily because they now use a larger accumulator, and a change to the
use of the equal (=) compare predicate with a negative indicator variable now
evaluates to UNKNOWN rather than generating an error condition.)
Impact on Existing Applications
Read the appropriate section of this appendix carefully to determine what changes
you will need to make to your applications when migrating from one release to the
next. You may also want to review the chapter in the DB2 Server for VSE System
Administration manual on migration considerations which discusses some of these
incompatibilities in more detail, plus other considerations for each
release-to-release migration.
This appendix excludes the numerous changes and enhancements for which no
impact on existing applications is anticipated. These are listed in the Summary of
Changes section (included with each manual) of the appropriate release of the
389
library. Review that section to see where you could make changes to your existing
applications in order to take advantage of some of these enhancements.
V2R1
and V1R3.5 Incompatibilities
SQL and Data
1.
Evaluation of HAVING and SELECT Clauses
Prior to V2R1, the HAVING clause was evaluated after the SELECT clause. This
caused a statement such as the following to fail on a zero divide and generate
SQLCODE -802, if a zero part number was encountered:
SELECT 200/PARTNO FROM T1
GROUP BY PARTNO HAVING PARTNO > 0
In V2R1, the HAVING clause is evaluated before the SELECT clause. This
means your applications now have the potential of producing different results.
In the above example, if a zero part number is encountered, the query does not
fail and SQLCODE -802 is not generated.
2.
Null Values as a Grouping Criterion
Prior to V2R1, if any row had a null value in one of the columns referenced in
a GROUP BY clause, each such row was treated as a separate group.
In V2R1, null values are considered identical for purposes of grouping.
This means that your existing applications may generate fewer rows in the
result table than they did in previous releases, since multiple null-value-groups
are now consolidated into one group. Any derived column function values will
reflect this consolidation (for example, SUM(BONUS)).
3.
Negative Decimal Zero Support
Prior to V2R1, the system recognized negative decimal zero as a valid value.
However, it did not evaluate positive and negative decimal zero values as
equivalent.
In V2R2, any negative decimal zeros found in SQL statements are converted to
positive decimal zeros before execution. This means that inserting, updating, or
deriving negative decimal zeros, or using them in a comparison, is no longer
possible. A utility called SQLZERO is provided which converts all negative
decimal zeros in the database to positive decimal zeros.
For a detailed discussion of this topic, see “Elimination of Negative Decimal
Zero” in the chapter which discusses migrating from V1R3.5 in the System
Planning and Administration manual, V2R1 or later.
4.
Insertion of Invalid Decimal Values
Prior to V2R1, it was possible to insert invalid decimal data into the database
during DATALOAD by specifying string values that were invalid for
DECIMAL columns. For example, X'0000' has no sign value.
In V2R1, this is no longer allowed. Doing so will generate SQLCODE -424.
Application Programming
5. Use of ORDER BY Clause with SELECT INTO
Prior to V2R1, the SELECT INTO statement was allowed to contain an ORDER
BY clause.
In V2R1, this is no longer allowed. Doing so will generate SQLCODE -524.
6. Scope of Prepared Statements
Prior to V2R1, a prepared statement could sometimes, but not always, be
referenced in subsequent logical units of work (LUWs).
390
System Administration
In V2R1, this inconsistency is removed. A prepared statement may now only be
referenced within the same LUW in which it was prepared.
If your applications contain code that references prepared statements across
LUWs, they will have to be restructured accordingly.
7. SQLCODE Returned After a Format 2 INSERT
Prior to V2R1, when a format 2 INSERT (known as “INSERT via subselect” in
V2R2 and later releases) returned an empty answer set for insertion, SQLCODE
+0 was generated.
In V2R1, SQLCODE +100 is generated instead.
8. Preprocessor Errors Converted to Warnings
Prior to V2R1, a certain set of conditions generated errors during preprocessing.
In V2R1, these conditions now generate warnings, although the associated
SQLCODEs are still negative (starting with V3R1, the codes are presented as
positive numbers). These conditions and their corresponding SQLCODEs are
shown in the table below.
SQLCODE
DESCRIPTION
-134
IMPROPER USE OF THE LONG FIELD COLUMN column.
-135
THE INPUT FOR A LONG FIELD COLUMN IN AN INSERT OR UPDATE
MUST BE FROM A HOST VARIABLE OR THE KEYWORD NULL.
-150
THE VIEW CANNOT BE USED TO MODIFY DATA SINCE IT IS BASED
ON MORE THAN ONE TABLE.
-151
A COLUMN OF A VIEW CANNOT BE UPDATED SINCE IT IS DERIVED
FROM AN EXPRESSION.
-152
A COLUMN OF A VIEW CANNOT BE USED IN A WHERE-CLAUSE
SINCE IT IS DERIVED FROM A COLUMN FUNCTION.
-154
VIEW LIMITATIONS DO NOT ALLOW THE USE OF THE FOLLOWING
OPERATION: operation
-155
YOU CANNOT PERFORM A JOIN ON A VIEW CONTAINING A
GROUP-BY CLAUSE OR A DISTINCT KEYWORD.
-156
RESTRICTIONS APPLY WHEN SELECTING FROM A VIEW CREATED
WITH THE DISTINCT OR GROUP BY KEYWORD.
-202
COLUMN column WAS NOT FOUND IN ANY TABLE REFERENCED BY
THE COMMAND.
-205
COLUMN column WAS NOT FOUND IN TABLE creator.table.
-401
INCOMPATIBLE DATA TYPES FOUND IN AN EXPRESSION OR
COMPARE OPERATION.
-404
A CHARACTER STRING SPECIFIED IN AN INSERT OR UPDATE IS
TOO LARGE FOR THE TARGET COLUMN.
-405
THE NUMERIC VALUE, value, IS NOT WITHIN THE RANGE OF THE
DATA TYPE.
-407
AN UPDATE OR INSERT OF A NULL VALUE FOR A COLUMN
DEFINED AS NOT NULL IS NOT ALLOWED.
-408
AN UPDATE OR INSERT OF A DATA VALUE IS INCOMPATIBLE WITH
THE DATA TYPE OF THE ASSOCIATED TARGET COLUMN.
-414
LIKE WAS USED FOR A NUMERIC OR DATE/TIME COLUMN TYPE. IT
MUST ONLY BE USED WITH CHAR OR VARCHAR TYPE COLUMNS.
-415
THE DATA TYPES OF CORRESPONDING ITEMS IN THE
SELECT-CLAUSES CONNECTED BY A UNION ARE NOT IDENTICAL.
Appendix I. Incompatibilities Between Releases
391
SQLCODE
DESCRIPTION
-416
YOU CANNOT SPECIFY A LONG FIELD COLUMN IN THE
SELECT-CLAUSE OF A UNION.
-419
THE PRECISION OF THE NUMERATOR AND/OR THE SCALE OF THE
DENOMINATOR ARE TOO LARGE FOR DECIMAL DIVISION.
-421
A HEXADECIMAL LITERAL WITH AN ODD LENGTH MAY NOT BE
USED WITH A DBCS COLUMN IN A PREDICATE.
V2R2
and V2R1 Incompatibilities
SQL and Data
1.
Leading and Trailing zeros in Decimal Constants
Prior to V2R2, leading and trailing zeros of decimal constants were removed by
the system when calculating their scale and precision.
In V2R2, if the precision of a decimal constant is greater than 15, leading zeros
are removed to bring the precision down to 15. Trailing zeros are not removed.
If your current applications provide output from the result table without any
intervening formatting, this change has the potential of altering that output. If
formatting is involved, you may have to change the formatting logic to obtain
the same output.
Similarly, input to the database by means of INSERT or UPDATE may be
affected, if a decimal constant is involved.
2.
Use of Host Variables with UNION
Prior to V2R2, two select-lists could be successfully UNION’ed even when they
contained corresponding items that were host variables of different data types
and different lengths. The statement below is an example of this, where host
variables :hw and :fw are halfword fixed binary (15) and fullword fixed binary
(31), respectively.
SELECT :hw FROM T1
UNION
SELECT :fw FROM T1
In V2R2, the above statement is no longer allowed. Issuing it will generate
SQLCODE -415.
Note: In V3R1, some restrictions on the use of data types within a UNION are
removed, including the above incompatibility.
Application Programming
3.
Atomic Operations Against the Database
Prior to V2R2, many types of operational errors (that is, SQL statement errors)
against the database caused the system to roll back the entire current logical
unit of work (LUW), leaving the application with no control over the status of
the LUW.
In V2R2, all operations against the database are now atomic. That is, within an
LUW, each operation can succeed or fail separately, with no effect on other
operations, provided they do not depend on it. If an operation fails, the
application is free to either continue working on the same LUW, or commit the
changes made so far, or roll back the LUW. Some system errors, such as
deadlocks, still require the entire LUW to be rolled back by the system. Also,
atomic operation is not supported for:
v Operations on data located in nonrecoverable storage pools
392
System Administration
v Operations on data when running without a log (LOGMODE=N).
As a result of this change, you may want to extend the logic of your LUW
processing in your applications.
Note: The next incompatibility item contains a special case of atomic operation.
4.
Multiple Row Changes Within an Atomic Operation
Prior to V2R2, if an error occurred during a single operation involving multiple
row changes to the database, the database was potentially left in an
inconsistent state. (This was one of those operational errors that was not rolled
back by the system.) Some of the rows were processed; the rest were not. The
only practical way to avoid this inconsistency was to have the application roll
back the entire current LUW.
There was one exception to this: in the case of a data definition statement, such
as CREATE TABLE, the system itself rolled back the LUW to avoid a partial
definition of a table in the catalog. The application had no control over the
status of the LUW.
In V2R2, with atomic operation in place, the system automatically undoes that
portion of the multiple row operation that was processed prior to the error.
This eliminates the potential of an inconsistent database resulting from such an
operation, and leaves the application free to control the current LUW as it sees
fit.
See “Detailed Notes on V2R2-V2R1 Incompatibilities” on page 394 for an
example.
5.
Four-Byte Floating-point Data
Prior to V2R2, all floating-point data had to be eight bytes.
In V2R2, it can be four bytes.
This leads to a potential problem in V2R2 for programs that allocate eight bytes
when using DESCRIBE on a FLOAT column. When using DESCRIBE,
applications should allocate storage based on the SQLLEN of a column (as
given in the SQLDA), not the SQLTYPE.
6.
Arithmetic and Conversion Errors
Prior to V2R2, an arithmetic or conversion error terminated processing of the
statement and generated SQLCODE -802.
In V2R2, these types of errors are tolerated when they involve a host variable
that has an indicator variable. In such cases, processing of the SQL statement
continues; SQLCODE +802 is generated; a -2 is placed in the indicator variable;
and the associated database variable remains unchanged.
If your application is checking for these errors, this could impact its logic. The
types of errors that can now be tolerated are:
v Fixed point overflow
v Decimal overflow
v Exponent overflow
v Exponent underflow
v Divide exception.
For more detail, see the Messages and Codes manual, V2R2 or later, for
SQLCODEs +802 and -802.
7.
GRANT Authority for PUBLIC
Prior to V2R2, “WITH GRANT OPTION” in a GRANT statement passed
GRANT authority to the user receiving the privilege in question, even when
the user was PUBLIC.
Appendix I. Incompatibilities Between Releases
393
In V2R2, when “PUBLIC” and “WITH GRANT OPTION” are used together, the
privilege is granted to PUBLIC, but without GRANT authority. In such cases, a
warning is given to that effect.
This can impact your current authorization of views or programs, since these
objects, which previously could have been grantable (for example, a value of 'G'
recorded for a program in catalog table SYSPROGAUTH), will no longer be so
(a value of 'Y' now in SYSPROGAUTH) if they depend on PUBLIC access to an
object.
For example, if a program contains a static SELECT statement involving table
T1, and the owner of the program is dependent on PUBLIC access to T1, then
'Y' is the highest authorization value attainable for that statement — and
therefore for the program. This means that the owner is still able to run the
program, but not to grant the RUN privilege on it to others. This, in turn,
means that when this program is preprocessed under V2R2, users who
previously may have had authority to run it (by virtue of receiving RUN
authority from the owner) will no longer have that authority.
System Environment
8.
Change to Message Numbers
Prior to V2R2, the ARI message numbers were three digits long and were
followed by an action indicator. This identification formed a header for each
line of the message text, as illustrated below:
ARI297A RESPONSE TO ARCHIVE PROMPT
ARI297A IS NOT VALID.
In V2R2, these message numbers are expanded to four digits to accommodate
future expansion of the system. Message numbers existing in the earlier
releases now contain a high-order zero. Also, the message header is now only
used on the first line of the message. The above example becomes:
ARI0297A RESPONSE TO ARCHIVE PROMPT
IS NOT VALID.
This could impact any automated operating system facility that you may be
using (for example, the VM Programmable Operator) to scan the message
number and text.
Detailed Notes on V2R2-V2R1 Incompatibilities
1.
Multiple Row Changes Within an Atomic Operation
In the following example, the operations are contained in one LUW. The second
operation involves multiple row changes to the database.
DELETE FROM SUPPLIER WHERE SUPPNO = 64
UPDATE INVENTORY SET PARTNO = PARTNO + 1
INSERT INTO QUOTATIONS VALUES (64, 221, .25, 5, 100)
The DELETE statement removes a supplier from the SUPPLIER table. The
UPDATE statement changes the first two rows of the INVENTORY table, but
fails on the third row because the operation would create a duplicate primary
key value.9
Prior to V2R2, the system would have left the new values in the first two rows
of INVENTORY, with the rest of the table unchanged. To avoid this undesirable
inconsistency, the application would have had to contain logic to recognize this
error and roll back the entire LUW, thus undoing the DELETE.
9. In V3R2 this error will not occur, because the enforcement of uniqueness is done after all the rows are updated.
394
System Administration
In V2R2, when this error occurs, the system undoes the UPDATE statement by
reversing the changes made to the first two rows. Because neither the DELETE
nor the INSERT depends on the success of the UPDATE (these operations are
atomic), the application has the following options open to it:
v Proceed and perform the INSERT, or
v Commit the successful DELETE, or
v Roll back the LUW to undo the DELETE.
V3R1
and V2R2 Incompatibilities
SQL and Data
1.
Table Designation Rules
Prior to V3R1, the following set of ANS/ISO SQL rules for table designation
in FROM clauses were not fully enforced:
v Duplicate table or view names in a FROM clause must all have a correlation
name assigned to them.
v Correlation names in a FROM clause must be distinct from each other.
v Correlation names in a FROM clause must be distinct from the table or
view names in the same clause.
When the application contained ambiguities, such as
SELECT A.COL1
FROM A B, B A
where COL1 appeared in both table A and table B, the system accepted the
statement, employing its own set of rules to resolve the ambiguity. This
example represents only one type of ambiguity that could occur.
In V3R1, the ANS/ISO rules are fully enforced. Any violations generate
SQLCODE -211 (SQLSTATE 52012).
2.
New Reserved Words
Prior to V3R1, the following were not reserved words in SQL and could
therefore be used as ordinary identifiers:
v CHAR
v CHARACTER
v DOUBLE
v EXECUTE
v FIELDPROC
v GRAPHIC
v LONG
v PACKAGE.
Similarly, the following were not reserved words for the DBS Utility:
v REORGANIZE
v SCHEMA.
In V3R1, these are reserved words, so an existing application that uses any
words in the SQL group above as an ordinary identifier will have to be
changed before it is preprocessed, or SQLCODE -105 (SQLSTATE 37501) will
be generated. Similarly, the words in the DBS Utility group above can no
longer be used in DBS Utility commands as ordinary identifiers.
You can address this incompatibility by changing these ordinary identifiers to
use nonreserved words, or you can retain the original names by redefining
them as delimited identifiers.
3.
Significance of Trailing Blanks
Appendix I. Incompatibilities Between Releases
395
Prior to V3R1, trailing blanks were treated as significant in both object names
and VARCHAR and VARGRAPHIC column values.
In V3R1, such trailing blanks are not considered significant.
If your applications must continue to treat trailing blanks as significant, you
may have to undertake some redesign. See “Detailed Notes on V3R1-V2R2
Incompatibilities” on page 399 for further discussion and examples.
4. Timestamp at the 24th Hour
Prior to V3R1, a timestamp value in which the hour portion was 24 and the
minute, second, or microsecond portion was not zero, was accepted as valid
data for insertion or updating.
In V3R1, an attempt to insert or update a column with such a value generates
SQLCODE -181 (SQLSTATE 22007). When the hour portion is 24, the other
time portions must now be zero.
If you have any of these invalid values in your tables after migrating to V3R1,
they will prevent you from doing a DBS Utility unload/reload operation or an
INSERT using a subselect. You will have to first correct these values to
conform to the rule mentioned above.
Application Programming
5.
Invalid Pointers in SQLDA and RDIIN
Prior to V3R1, the system checked for invalid pointers in the SQLDA and
RDIIN structures. This checking was extensive, often resulting in poor
performance.
In V3R1, in the interest of better performance, this checking has been
eliminated. It is up to the application programmer to follow the rules on
setting pointers in the SQLDA, as outlined in the chapter “Using Dynamic
Statements” in the V3R1 Application Programming manual. Pointers in the
RDIIN must not be changed by the application. If your application does not
satisfy these rules, the results will be unpredictable.
6.
Continuation Characters in Fortran
Prior to V3R1, the Fortran preprocessor ignored any continuation character
located in front of an EXEC SQL on the same line, provided it was not part of
an IF or ELSE statement — even though such coding was incorrect.
In V3R1, the continuation character is acknowledged and the EXEC SQL is
ignored.
7.
Missing Comma in COBOL Continuation Lines
Prior to V3R1, if you left out an intended comma from a list of parameters in
an SQL statement embedded in a COBOL program (as illustrated below) and
did not code a continuation character in the next line, the system would
assume a continuation character and misinterpret the parameter list, giving
potentially wrong results.
SELECT *
FROM T1
WHERE COL1 IN (’AB’
<--- missing comma
’CD’,
<--- no continuation character
’EF’)
In V3R1, this error is detected and reported at preprocessor time.
8.
DROP PROGRAM Statement Containing Host Variables
Prior to V3R1, the processing of a DROP PROGRAM statement that contained
host variables required a specific section in the access module. (In this form of
396
System Administration
the statement, the name of the owner of the program or the name of the
program or both are expressed as host variables.)
Note on New Terminology: As of V3R1, PACKAGE becomes the new
reserved word for PROGRAM, the latter
remaining as a synonym. Access modules are
now referred to as packages. This new
terminology is used below.
In V3R1, the host variable form of the DROP PACKAGE statement no longer
requires a section in the package. All the information required to execute the
statement is sent with the execution-time request. You will be affected if you
have this form of the DROP PACKAGE coded in your application programs.
If the programs that use these packages are explicitly repreprocessed, they will
have to be recompiled (or reassembled) and relinked in order to execute
successfully. Otherwise, errors will result, since there will be fewer sections in
the new package and this will cause a mismatch between section numbers in
the RDIIN structure and the new package.
9.
Data Type of String Constants
Prior to V3R1, application programs that assumed that string constants have a
data type of VARGRAPHIC because they are used in the context of GRAPHIC
and VARGRAPHIC data, were accepted.
In V3R1, such constants are considered to be VARCHAR, and if used in
conjunction with GRAPHIC or VARGRAPHIC data will result in an error,
such as SQLCODE -171 (SQLSTATE 53015) or SQLCODE -408 (SQLSTATE
53021).
If the host language is COBOL, PL/I, or C, you should use explicitly coded
graphic constants. See the section of the V3R1 SQL Reference manual that
discusses graphic string constants.
10.
New Options in CREATE PROGRAM Statement
Prior to V3R1, when the following three options:
ISOL({RR|CS|USER})
DATE({ISO|USA|EUR|JIS|LOCAL})
TIME({ISO|USA|EUR|JIS|LOCAL})
were used in conjunction with an extended dynamic access module, the
values for these options were determined when statements referencing the
extended dynamic access module were executed. The values were set based
on the corresponding preprocessing options of the program containing the
extended dynamic statements.
Note on New Terminology: As of V3R1, PACKAGE becomes the new
reserved word for PROGRAM, the latter
remaining as a synonym of the former. Access
modules are now referred to as packages. This
new terminology is used below.
In V3R1, these options are added to the CREATE PACKAGE statement, so that
they become preprocessing options. This means that their values are stored
with the package itself, and are enforced when the sections of the package are
executed. Consequently, your programs may now run at a different isolation
level than they did in V2R2.
Appendix I. Incompatibilities Between Releases
397
See “Detailed Notes on V3R1-V2R2 Incompatibilities” on page 399 for
examples that illustrate how incompatibilities may arise as a result of this
change.
11.
Views Created from SELECT *
Prior to V3R1, views created as SELECT * FROM T1 required no special
attention when being migrated from release to release, even when columns
had been added to table T1 after the creation of the view.
In V3R1, a necessary change to the system now requires special attention in
the above situation. The first time the system encounters such a view in an
application, it attempts to rebuild the view, and fails with SQLCODE -835
(SQLSTATE 56049).
To avoid this failure, drop and recreate the view before running the
application on V3R1. Depending on how your application logic is coded, you
may have to change that logic in order to handle the extra columns that were
added to table T1. The best practice is to avoid the use of SELECT * for view
creation, and specify the explicit columns that the application requires.
12.
Semicolon Delimiter in SYSVIEW Table
Prior to V3R1, when a view was created through the DBS Utility or by
running a preprocessed program, the CREATE VIEW statement was inserted
into column VIEWTEXT of catalog table SYSVIEWS with a semicolon
delimiter.
In V3R1, this delimiter is no longer included.
If your application has a dependency on the existence of this delimiter in the
SYSVIEWS table, you will need to change it accordingly.
13.
Replacement of Error Message ARI0565E
Prior to V3R1, error message ARI0565E was issued during preprocessing of
Fortran programs whenever the input source contained no SQL statements
that required creation of a package.
In V3R1, this message is replaced by information message ARI0565I. In
addition, related message, ARI0598I, dealing with the status of the package, is
modified.
This could impact any automated operating system facility that you may be
using (for example, the VM Programmable Operator) to scan the message
number and text.
14.
Replacement of SQLCODE -150
Prior to V3R1, an attempt to modify data through a view based on more than
one table generated SQLCODE -150.
In V3R1, this is replaced with SQLCODE +149 at preprocessor time, and
SQLCODE -149 (SQLSTATE 53007) at run time.
15.
New Positive SQLCODEs
Prior to V3R1, a number of negative SQLCODEs and associated positive
RDSCODEs were returned during preprocessing to indicate a warning
situation.
In V3R1, new positive SQLCODEs are returned instead, which correspond
identically to the above negative SQLCODEs in code number and (in most
cases) message text and explanation. If the error is not removed, the
corresponding negative SQLCODEs will be issued at run time.
See “Detailed Notes on V3R1-V2R2 Incompatibilities” on page 399 for a list of
these new positive SQLCODEs.
System Environment
398
System Administration
16.
Uppercase and Mixed Case in Message Text
Prior to V3R1, all message text was in uppercase for all the languages
available in the product except German, which was available only in mixed
case.
Note: The uppercase applied to both English language offerings, AMENG and
UCENG. It also applied to the English text embedded in the DBCS
languages Japanese and Korean (for example, “FORCE”, “SQLEND”).
In V3R1, the message text of three more languages is now changed to mixed
case only. These languages are AMENG (the default language setting), Italian,
and Spanish. If you are using any of these three languages and you have
existing case-sensitive applications that scan for specific message text in
uppercase only, you will have to modify them to detect lowercase as well.
This could impact any automated operating system facility that you may be
using for this purpose (for example, the VM Programmable Operator).
An alternative approach (for English users only) to modifying your
applications would be to specify UCENG instead of AMENG, through the SET
LANGUAGE command.
17.
Authorization for Changing System Catalog Tables
Prior to V3R1, certain portions of the catalog could be updated, deleted, or
inserted into, by any user with DBA authority.
In V3R1, the number of columns in the catalog tables for which these changes
are allowed is reduced.
This change may affect the authorization of some of your applications. See
Appendix E of the V3R1 SQL Reference manual for a list of the columns that
can now be updated, deleted, or inserted.
18.
Modification of Sample Tables and Applications
Prior to V3R1, the sample tables shipped with the product consisted of five
Manufacturing tables and four Organizational-project tables. The sample
applications shipped with the product used the Manufacturing tables.
In V3R1, the Manufacturing tables are not included, but can be installed
optionally. The Organization-project tables are enhanced to provide more
guidance on referential integrity and also consistency across the IBM relational
database products. The enhancements include:
v Two new tables
v A new column in an existing table
v Renaming of a table
v Modification of a foreign key definition.
The sample applications are now modified to use the enhanced
Organization-project tables. They now issue a ROLLBACK instead of a
COMMIT, so that they can be rerun without having to first restore the sample
database.
If you have any applications that use these tables, such as an online tutorial or
a test package for new releases, you will need to upgrade them accordingly.
Detailed Notes on V3R1-V2R2 Incompatibilities
1.
Significance of Trailing Blanks
Prior to V3R1, delimited identifiers "TABLE1" and "TABLE1" would be
considered two different tables, and VARCHAR values 'ABC' and 'ABC' two
different values, where '' represents a blank character.
In V3R1, in the case of the table names, the system would not accept the two
tables because they now have identical names. In the case of the VARCHAR
Appendix I. Incompatibilities Between Releases
399
values, they are considered equal, except in a LIKE comparison. However, if
specified at INSERT or UPDATE time, trailing blanks are included in the
varying length string data stored in the database.
If your applications must continue to treat trailing blanks as significant, you
may have to undertake some redesign. For example, prior to V3R1, if your
table had a VARCHAR column, COLX, containing 'AAA' and you wanted to
select all values from COLX that were not equal to 'AAA', the following search
condition would satisfy this requirement, because it would return value
'AAA' along with any other values not equal to 'AAA':
WHERE COLX <> 'AAA'
In V3R1, value 'AAA' does not get returned in the above example. This
search condition must be redesigned in order to get the same results as in prior
releases. One solution is:
WHERE COLX NOT LIKE 'AAA'
For more discussion on migration considerations for this item, see
“Considerations for VARCHAR and VARGRAPHIC Compare” in the chapter
which discusses migrating from V2R2, in the System Administration manual,
V3R1 or later.
2.
New Options in CREATE PROGRAM Statement
The following examples illustrate the incompatibilities that may arise when you
migrate to V3R1.
2.2
3.1
Load Module
Package
Execution
Figure 127. Legend
400
System Administration
PROG1 (ISOL=RR)
PROG4 (ISOL=USER)
PACKA
PACKB
CREATE PROGRAM PACKA
CREATE PROGRAM PACKB
PREPARE FROM :STMTSTR
PREPARE FROM :STMTSTR
SETTING :SECTION IN PACKA
section n
section n
SETTING :SECTION IN PACKB
PROG2 (ISOL=CS)
EXECUTE :SECTION IN PACK A
(run at CS)
PROG3 (ISOL=USER)
SQLISL = C
EXECUTE :SECTION IN PACKA
(run at CS)
EXECUTE :SECTION IN PACKB
(run at CS)
SQLISL = R
EXECUTE :SECTION IN PACKB
(run at RR)
Figure 128. Version 2 Release 2
Figure 128 illustrates how isolation levels are determined for packages created
using extended dynamic SQL in V2R2. For example, program PROG1 contains
the CREATE PROGRAM statement for package PACKA, and prepares a section
in the package. Program PROG2 subsequently executes the section in PACKA.
Since program PROG2 was preprocessed with isolation level cursor stability
(CS), the section executes using CS.
Appendix I. Incompatibilities Between Releases
401
PROG1 (ISOL=RR)
PROG4 (ISOL=USER)
PACKA
PACKB
CREATE PACKAGE PACKA
CREATE PACKAGE PACKB
OPTION ISOL(RR)
OPTION ISOL(USER)
PREPARE FROM :STMTSTR
section n
section n
PREPARE FROM :STMTSTR
SETTING :SECTION IN PACKA
SETTING :SECTION IN PACKB
PROG2 (ISOL=CS)
EXECUTE :SECTION IN PACK A
(run at RR)
PROG3 (ISOL=USER)
SQLISL = C
EXECUTE :SECTION IN PACKA
(run at RR)
EXECUTE :SECTION IN PACKB
(run at CS)
SQLISL = R
EXECUTE :SECTION IN PACKB
(run at RR)
Figure 129. Version 3 Release 1
Figure 129 shows the same scenario in V3R1. In this case, the isolation level RR
is specified when the PACKA package is created. When program PROG2
executes a section in PACKA, isolation level RR is used.
402
System Administration
PACKA
PACKB
section n
section n
MIGRATION
PACKA (ISOL=USER)
PACKB (ISOL=USER)
section n
section n
PROG2 (ISOL=CS)
EXECUTE :SECTION IN PACK A
(run at CS)
PROG3 (ISOL=USER)
SQLISL = C
EXECUTE :SECTION IN PACKA
(run at CS)
EXECUTE :SECTION IN PACKB
(run at CS)
SQLISL = R
EXECUTE :SECTION IN PACKB
(run at RR)
Figure 130. Migration
Figure 130 shows packages being migrated to V3R1. In this case, the isolation
level bind option will be automatically set to USER. Applications will notice no
change in isolation level handling from previous releases.
Appendix I. Incompatibilities Between Releases
403
PROG1 (ISOL=RR)
PACKA
CREATE PACKAGE PACKA
OPTION ISOL(RR)
PREPARE FROM :STMTSTR
section n
SETTING :SECTION IN PACKA
PROG2 (ISOL=CS)
EXECUTE :SECTION IN PACK A
(run at CS)
Figure 131. Dropping and Re-creating PACKA Without Repreprocessing PROG2
PACKA
section n
PROG2 (ISOL=CS)
EXECUTE :SECTION IN PACK A
(run at RR)
Figure 132. Re-preprocessing PROG2
Figure 131 and Figure 132 show that once an extended dynamic package has
been dropped and recreated in V3R1 with an isolation level other than USER,
the isolation level bind option will be enforced whenever the executing
application has also been preprocessed, assembled, and re-linked under V3R1.
If the PACKA package has been dropped and recreated in V3R1, with an
isolation level of RR, then:
v If program PROG2 is still pre-V3R1, when the section in PACKA is executed,
isolation level CS will be used.
v Otherwise, isolation level RR will be enforced whenever sections in PACKA
are executed.
3. New Positive SQLCODEs
These codes are shown in the table below.
SQLCODE
SQLSTATE
DESCRIPTION
+117
01525
The number of data values to be inserted does not equal
the number of columns specified or implied.
+134
Improper use of long string.
404
System Administration
SQLCODE
SQLSTATE
DESCRIPTION
+135
The input for a long string column in an INSERT
statement or UPDATE statement must be from a host
variable or be the keyword NULL.
+149
The view cannot be used to modify data because it is
based on more than one table.
+151
A column of a view cannot be updated since it is derived
from an expression.
+154
View limitations do not allow you to use the following
operation: xxxxxx
+202
01533
Column xxxxxx was not found in any table referenced by
the statement.
+204
01532
xxxxxx was not found in the system catalog.
+205
01533
Column xxxxxx was not found in table yyyyyy.
+206
01533
The xxxxxx on yyyyyy was not found.
+401
Incompatible data types found in an expression or
compare operation.
+404
A character string specified in an INSERT or UPDATE
statement is too large for the target column.
+405
The numeric value, xxxxxx, is not within the range of the
data type.
+407
Either an UPDATE statement or an INSERT statement
with a null value for a column defined as NOT NULL is
not allowed, or a null host variable value is not allowed in
a SELECT list.
+408
An UPDATE or INSERT of a data value is incompatible
with the data type of the associated target column.
+414
The LIKE clause was used for a numeric or date/time
column type. LIKE must only be used with character or
graphic compatible columns.
+415
The corresponding columns, n, of the operand of a
UNION or a UNION ALL do not have comparable
column descriptions.
+416
You cannot specify a long string column in the SELECT
clause of a UNION.
+419
The precision of the numerator and/or the scale of the
denominator are too large for decimal division.
+421
A hexadecimal literal associated with a graphic compatible
column in a predicate cannot have an odd length.
+551
01548
User xxxxxx does not have the yyyyyy privilege.
+552
01542
xxxxxx is not authorized to perform this statement.
+668
Table xxxxxx is inactive and you cannot access it.
V3R2 and V3R1 Incompatibilities
SQL and Data
1. Nonexposed Table Names
Appendix I. Incompatibilities Between Releases
405
Prior to V3R2, nonexposed table names (those that have an associated
correlation name in the FROM clause) could be referenced within the SQL
statement containing such a name.
In V3R2, this is no longer the case. Any application code that makes such a
reference will have to be changed to reference the associated correlation name
instead. Otherwise, SQLCODE -201 (SQLSTATE 52003) will be generated.
For example, if both tables in the FROM clause
FROM TABLE1, TABLE2 A
have a column named DESCR, any reference in the query to this column for
the second table would have to be written as A.DESCR, not TABLE2.DESCR,
because TABLE2 is a nonexposed table name.
2.
DISTINCT Column Functions in HAVING Clauses
Prior to V3R2, a DISTINCT column function was allowed in conjunction with
a dyadic operator in the predicate of a HAVING clause. (A dyadic operator is
an operator having two operands.) For example, the following would be
accepted as valid:
SELECT JOB, AVG(SALARY), AVG(BONUS)
FROM EMPLOYEE
GROUP BY JOB
HAVING AVG(DISTINCT BONUS) + 50 > 100
In V3R2, as part of the product’s compliance with SQL-89 in the introduction
of unary minus in DISTINCT column functions, this code is no longer
allowed. Using it will generate SQLCODE -112 (SQLSTATE 37507).
3.
New Reserved Word, SOME
Prior to V3R2, SOME was not a reserved word in SQL and could therefore be
used as an ordinary identifier.
In V3R2, SOME is a reserved word that is used in quantified predicates as a
synonym for ANY, so any existing applications that use it as an ordinary
identifier will have to be changed before they are preprocessed under V3R2.
Id SOME is used as an ordinary identifier, SQLCODE -105 (SQLSTATE 37501)
will be generated.
You can address this incompatibility by changing this ordinary identifier to
use a nonreserved word, or you can retain the original name by redefining it
as a delimited identifier.
4.
Comparing Character Data with Unquoted Numeric Data
Prior to V3R2, applications that compared character data type columns to an
unquoted numeric, represented invalid SQL code that was accepted. For
example,
WHERE C1 = 3
where C1 was defined as CHAR(1).
In V3R2, this is no longer accepted. Doing this comparison will generate
SQLCODE -401 (SQLSTATE 53018).
5.
CHAR Scalar Function with a Timestamp Argument
Prior to V3R2, applications that used a second argument for the CHAR scalar
function, when the first argument was a timestamp expression, represented
invalid SQL code that was accepted. The second argument was ignored.
In V3R2, this is no longer accepted. Using this argument will generate
SQLCODE -171 (SQLSTATE 53015).
6.
No Column Name in a Column Function Within a HAVING Clause
406
System Administration
Prior to V3R2, applications that used a column function within a HAVING
clause with no explicit column name in its argument, represented invalid SQL
code that was accepted. For example:
HAVING MIN(1) > 30
In V3R2, this is no longer accepted. Using this function will generate
SQLCODE -111 (SQLSTATE 56001).
7.
Even-numbered Precision for Columns
Prior to V3R2, columns that were specified with even-numbered precision
were rounded up to the next odd-numbered precision, when creating or
altering a table. For example, DECIMAL(6,2) became DECIMAL(7,2) at
CREATE time.
Similar rounding up is also performed for arithmetic expressions found inside
statements. For example, the expression 99.9999/12*(12+3) will become
099.9999/12*(12+3) during processing.
In V3R2, this rounding is no longer done. In the above example, any
application code that relies on such rounding in order to store seven digits in
the column will require a redefinition of the column to DECIMAL(7,2), if the
table gets recreated in V3R2. Otherwise, one of the following error conditions
(depending on where the mismatch between column and length of the
variable occurs) will be generated: SQLCODE -302 (SQLSTATE 22003),
SQLCODE -405 (SQLSTATE 53020), or SQLCODE -413 (SQLSTATE 22003).
Arithmetic expression that relies on such rounding to obtain enough precision
to accommodate the result of the calculation will need modification. In the
above example, the 99.9999 in the expression 99.9999/12*(12+3) must be
changed to 099.9999 in order to accommodate the result which is 124.99988.
Otherwise, SQLCODE -802 (SQLSTATE 22003) will be generated.
Date/time Durations: Date and time durations are specified as DECIMAL(8,0)
and DECIMAL(6,0) respectively, but if stored in the
database prior to V3R2, they became DECIMAL(9,0)
and DECIMAL(7,0) columns. Because of this, V3R2 still
accepts the odd-numbered precision for these durations,
when they are used as input.
Performance of Assembler Programs: Assembler does not support
even-numbered precision. If such table
columns are referenced in a predicate
containing a comparative host variable
in an Assembler program, the latter
must be declared with a precision one
higher than the column. This leads to
inefficient processing. You should
consider redefining such table columns
to odd-numbered precision to avoid
this reduction in performance.
8.
Floating-point Ranges
Prior to V3R2, there was a certain range of floating-point values that went
beyond the allowable values for the database and if encountered, would
generate SQLCODE -405 (SQLSTATE 53020).
In V3R2, because of a necessary change in the checking algorithm for
floating-point constants, the following two narrow ranges have been added to
the original range and will now also trigger SQLCODE -405 when
encountered:
v Approximately +7.2370055773322608E+75 to +7.23700557733622E+75
Appendix I. Incompatibilities Between Releases
407
v Approximately -7.2370055773322608E+75 to -7.23700557733622E+75.
9.
Decimal Precision in Internal Sorts
Prior to V3R2, an arithmetic operation involving decimal columns, such as
COL1*COL2/100 or SUM(COL3), allowed a precision of up to 15 digits,
unless the SQL query specified something less.
In V3R2, with the enhancement of decimal precision, this allowable precision
is now expanded to 31 digits. As a result, it is possible for a query that has
been migrated from V3R1 to generate SQLCODE -101 (SQLSTATE 54001) with
a value of 'ARIXECK' in the SQLERRP field of the SQLCA. This error
indicates that the maximum allowable size (255) of an internal sort key has
been exceeded. This can only occur if the query is fairly complex and requires
an internal sort.
Note: Queries that use internal sorts are typically those that use ORDER BY,
UNION, or DISTINCT.
If you experience this error, you can reduce the precision of the arithmetic
operations in the select list of your query by applying the DECIMAL scalar
function. This, in turn, may reduce the internal sort key to an acceptable
length.
10.
Quantified Predicates Involving Null Values
Prior to V3R2, null values in quantified predicates (ALL, ANY) were not
handled according to the FIPS standard.
In V3R2, the FIPS standard applies. As a result, the truth value of these
predicates is different from previous releases for some cases involving null
values.
See “Detailed Notes on V3R2-V3R1 Incompatibilities” on page 409 for a
discussion on these cases and examples to illustrate the incompatibilities.
Application Programming
11. Negative Indicator Variables in Predicates
Prior to V3R2, the use of negative indicator variables in predicates was limited
to the basic equal-to (=) predicate in static, dynamic, and extended dynamic
SQL.
In V3R2, the use of negative indicator variables in predicates is extended in
some areas and restricted in others. This use is now allowed in all predicates
of static SQL and extended dynamic SQL when a descriptor is specified on the
PREPARE statement. SQLCODE -309 (SQLSTATE 22512) is generated when a
negative indicator variable is used in any predicate within dynamic SQL, or
extended dynamic SQL when no descriptor is specified on the PREPARE
statement.
12. Declaration of Indicator Variables
Prior to V3R2, existing application programs that used indicator variables
declared with a data type other than the equivalent of SMALLINT were
accepted.
In V3R2, these programs are no longer accepted. For FORTRAN programs,
error message ARI0550E is generated at preprocessing time; for Assembler, C,
COBOL, and PL/I programs, SQLCODE -326 (SQLSTATE spaces) is generated
at preprocessor time.
13. Incorrect Data Inserted from Variable Length Host Variables
Prior to V3R2, incorrect data could get inserted into the database from a
variable length host variable that had a length value greater than the
maximum that was defined at preprocessing time.
408
System Administration
In V3R2, this is prevented. If it is attempted, SQLCODE -311 (SQLSTATE
22501) will be generated.
14.
Incorrect String Representations of Date/time Values
Prior to V3R2, incorrect string representations of date/time values generated
errors at preprocessor time.
In V3R2, warning messages are issued instead; then if the string
representations are not corrected, they will result in errors at run time.
15.
COBOL Host Variable Names
Prior to V3R2, if a COBOL program contained a hyphen (-) in the declaration
of a host variable name, this hyphen could be represented as an underscore
(_) where the name was used within an SQL statement.
In V3R2, the preprocessor no longer accepts this substitution within the
program.
If you have any such substitutions in your COBOL source code, they will have
to be converted to hyphens before preprocessing under V3R2.
16.
Validation of Host Variables
Prior to Version 3, applications containing any of the SQL statements SELECT,
SELECT INTO, UPDATE, INSERT, or DELETE, could be preprocessed from a
user machine on one release of the product to a database machine on another
release of the same version.
In V3R2, there is a change to the validation of host variables for these
statements. As a result, this preprocessing fails when the two releases
involved are V3R1 and a later release of Version 3. To circumvent this
problem, you must preprocess the application from a user machine at the
same release level as the database machine on which you would like the
package created before compiling, linking, and executing the application from
the user machine.
Detailed Notes on V3R2-V3R1 Incompatibilities
1.
Quantified Predicates Involving Null Values
Those cases for which your applications will give different results than they did
in earlier releases can be divided into three types, as described below. The
accompanying examples are based on these two tables, where the question
mark represents a null value:
Table T1: C1
C2
Table T2: C3
--
--
--
?
1
?
2
2
2
Recalling that a quantified predicate involves the structure
<expression> <quantifier> <subquery>
the three types can be described as follows:
a. Prior to V3R2, when
v The value of the expression is NULL, and
v The subselect returns an empty set,
the truth value of the quantified predicate was UNKNOWN.
In V3R2, the truth value is TRUE if the quantifier is ALL, and FALSE if the
quantifier is ANY.
In the example below, the second row of T1 is returned by any release of
the database manager, but the first row of T1 is only returned by V3R2.
Appendix I. Incompatibilities Between Releases
409
SELECT * FROM T1
WHERE C1 > ALL (SELECT C3 FROM T2 WHERE C3 > 2)
b.
Prior to V3R2, when
v The quantifier is ALL, and
v The subselect returns at least one NULL, and
v There are no values in the result of the subselect for which the implied
predicate (the predicate applied to just one value in the result) is FALSE;
or when
v The quantifier is ANY, and
v The subselect returns at least one NULL, and
v There are no values in the result of the subselect for which the implied
predicate (the predicate applied to just one value in the result) is TRUE,
the truth value of the quantified predicate was FALSE, except when the
expression was NULL.
In V3R2, the truth value is UNKNOWN.
Note: This change will only affect the results of queries in which a NOT
has been applied to the quantified predicate in the situations
described above. When a NOT is applied, the truth value is TRUE for
prior releases, but is UNKNOWN for V3R2.
In the example below, both rows of T1 are returned by previous releases,
but only the first row of T1 is returned by V3R2:
SELECT * FROM T1
WHERE NOT C2 = ALL (SELECT C3 FROM T2)
See the following references for performance implications of queries similar
to those shown in the above examples:
v Chapter 2 of the V3R2 Database Administration manual for a discussion on
nulls in quantified predicates where null columns are allowed, under
“Creating Tables”.
v Chapter 5 of the V3R2 Diagnosis Guide and Reference manual for a
discussion on inefficient search where nullable expressions are involved,
under “Analysis of Performance Problems”.
c.
Prior to V3R2, when:
v The expression contains an arithmetic expression, scalar function or
column function
v The quantifier is ALL
v The subselect returns at least one NULL, and
v There are no values in the result of the subselect for which the implied
predicate (the predicate applied to just one value in the result) is FALSE,
the truth value of the quantified predicate was TRUE, except when the
expression was NULL.
In V3R2, the truth value is UNKNOWN.
In the example below, the second row of T1 is not returned by any release
of the database manager. However, the first row of T1 is returned by
previous releases, but not by V3R2.
SELECT * FROM T1
WHERE C2 + 1 = ALL (SELECT C3 FROM T2)
410
System Administration
Comparison of types (b) and (c): Type (c) is really a subset of the more general
case outlined in type (b), by virtue of its
extra condition about the expression.
However, type (c) is included separately
here, because it represents an exception to
the more general case. The exception lies in
the fact that these two types generated
different results for the truth value prior to
V3R2. In V3R2, however, this exception
disappears, because their results are now the
same (truth value = UNKNOWN).
V3R4
and V3R2 Incompatibilities (VSE Only)
SQL and Data
1.
New Reserved Word, CONCAT
Prior to V3R4, CONCAT was not a reserved word in SQL and could therefore
be used as an ordinary identifier.
In V3R4, CONCAT is a reserved word, and can be used as an alternative to
the concatenation operator (||). Any existing applications that use it as an
ordinary identifier will have to be changed before they are preprocessed
under V3R4; otherwise SQLCODE -105 (SQLSTATE 37501) will be generated.
You can address this incompatibility by changing this ordinary identifier to
use a nonreserved word, or you can retain the original name by redefining it
as a delimited identifier.
2.
REVOKE UPDATE
Prior to V3R4, the REVOKE statement for the UPDATE privilege ignored any
column names that might be present as parameters of the UPDATE option —
even though such coding was invalid. (This statement is only done on a table
basis, never a column basis.)
In V3R4, such parameters are not allowed. If they are used, SQLCODE -105
(SQLSTATE 37501) will be generated.
3.
Numeric Data in Character Strings
Prior to V3R4, columns with a data type of CHAR or VARCHAR accepted
numeric data, including FLOAT, on insert or update. For example, the
following statements did not create an error:
CREATE TABLE T1 (COL CHAR(8))
CREATE TABLE T2 (COL VARCHAR(8))
INSERT INTO T1 (123)
INSERT INTO T2 (123)
INSERT INTO T1 (1E1)
INSERT INTO T2 (1E1)
UPDATE T1 SET COL = 123
UPDATE T2 SET COL = 123
UPDATE T1 SET COL = 1E1
UPDATE T2 SET COL = 1E1
In V3R4, these inserts and updates now generate SQLCODE -408 (SQLSTATE
53021).
If you want to use the value 123, you must now use it as a character literal
('123'). Float literals are no longer allowed for character columns.
4.
Invalid String Representation of Datetime
Prior to V3R4, when a predicate was being evaluated that contained an
operand that was one of the special registers CURRENT DATE, CURRENT
Appendix I. Incompatibilities Between Releases
411
TIME, or CURRENT TIMESTAMP, and one of the other operands was a
character column of the correct length but containing a value that was not a
valid string representation of a datetime, the application ran successfully. Any
row containing such an invalid value was returned if it met the search
condition. For example, all invalid date values in column, ORDERDATE, were
returned for the following condition:
WHERE CURRENT DATE <> ORDERDATE
In V3R4, SQLCODE -180 (SQLSTATE 22007) is generated under the above
condition.
5.
Internally Generated Table Names
Prior to V3R4, the system internally built a composite table name that
included the name of the relational database, based on a certain maximum
length.
In V3R4, this length is slightly increased, and the internal process is the same,
whether DRDA server support is involved or not. As a result, there is a very
small probability that some of your SQL statements could exceed an internal
limitation of the system and generate an SQLCODE -101 (SQLSTATE 54001).
The more table names you have in a statement, the greater the probability of
this occurring. If you experience this error, one possible solution would be to
break the statement down into two separate statements.
6.
Enhanced EXPLAIN Tables
Prior to V3R4, the tables used by the EXPLAIN statement had some major
differences from the corresponding tables in the DB2* product.
In V3R4, these differences are minimized to enhance the EXPLAIN functions
and make them more compatible with those in the DB2 product. As a result,
there are significant changes to the design of these tables and the EXPLAIN
statement no longer works on the old tables. These changes include new
columns dispersed among old ones, the loss of one column, a column data
type change, and a column length change.
See the DB2 Server for VSE & VM SQL Reference manual for the new design of
these tables.
If you have used the EXPLAIN tables in prior releases, you will have to
recreate the revised tables before using the EXPLAIN statement in V3R4. To
assist you in this task, a DBSU job file containing the necessary create
statements is now included as an A-type member (called ARIXEXP) with the
product.
Similarly, if you have applications which depend upon the design of the old
EXPLAIN tables, you will need to modify these applications to reflect the new
design.
Application Programming
7. Setting of SQLN Field
Prior to V3R4, if field SQLD in the SQLDA area held a greater value than the
SQLN field after a DESCRIBE, the system set SQLN to zero.
In V3R4, the value of SQLN is not changed.
If your application tests SQLN for zero to verify successful completion of the
DESCRIBE, the logic will have to be revised to test for SQLD > SQLN.
8. C NUL-Terminated Strings - Variable Length
Prior to V3R4, a C input string with a length greater than 1 was treated as a
fixed length character host variable. It was not mandatory to have a NUL
present in it except when the input host variable length was 255, in which
case SQLCODE -426 (SQLSTATE 22523) was generated.
412
System Administration
In V3R4, a C input string is no longer treated as fixed length. A NUL must be
present on all C NUL-terminated input strings except those with a length of 1;
otherwise SQLCODE -302 (SQLSTATE 22001) is generated. SQLCODE -426
(SQLSTATE 22523) is no longer generated.
9.
C NUL-Terminated Strings - NUL Byte
Prior to V3R4, the NUL byte in a C NUL-terminated string was treated as a
blank.
In V3R4, it is treated as a string terminator.
10.
C NUL-Terminated Strings - Trailing Blanks
Prior to V3R4, any trailing blanks in a C NUL-terminated string were
removed when using the string to update or insert a VARCHAR column or to
compare to a VARCHAR column.
In V3R4, these blanks will no longer be removed.
11.
C NUL-Terminated Strings - Length
Prior to V3R4, the SQL/DS scalar function, LENGTH, with a C
NUL-terminated string as its argument, returned the defined length.
In V3R4, this function now returns the length according to the position of the
NUL terminator. (This length excludes the terminator itself.)
12.
SQL Statement String
Prior to V3R4, an SQL statement string could end with a statement terminator,
when used in conjunction with EXECUTE IMMEDIATE, PREPARE, or
Extended PREPARE. An example of such a statement is
DROP TABLE T1;
which has a trailing semicolon. This was allowed in application programs,
even though such coding was invalid. It was also allowed in ISQL and QMF*,
since those facilities also use the above three statements to process
interactively issued statements.
In V3R4, this statement terminator is not allowed. If it is used, SQLCODE -104
(SQLSTATE 37501) will be generated.
If you have been using such a terminator for the CREATE VIEW statement,
your use of catalog table SYSVIEWS could be affected, as described in the DB2
Server for VSE & VM SQL Reference manual.
13.
SQL/DS Preprocessing of Extended Dynamic Statements
Prior to V3R4, a cursor-variable with a defined length greater than 18 was
accepted by the preprocessor, even though such variables should only be
defined with a length of 18.
In V3R4, the preprocessor traps this condition and generates SQLCODE -324
(SQLSTATE spaces). You will have to change any applications that use these
invalid cursor-variable lengths in your extended dynamic statements.
14.
Reason Codes for Incorrect Host Variable Declarations
Prior to V3R4, a large number of SQLERRD1 codes were associated with
SQLCODE -314 (SQLSTATE spaces) at preprocessor time for invalid host
variables.
In V3R4, with the introduction of host structures and the associated parsing of
declaration statements by the preprocessor, the values of some of these
SQLERRD1 codes have changed.
If your application has dependencies on specific SQLERRD1 values, you
should look for these changes in the DB2 Server for VM Messages and Codes or
DB2 Server for VSE Messages and Codes manual and modify your application
accordingly.
Appendix I. Incompatibilities Between Releases
413
15. Structured Declarations in COBOL and C
Prior to V3R4, there were a number of error situations for structure
declarations in the SQL DECLARE SECTION that were not checked by the
COBOL and C preprocessors.
In V3R4, these situations are subjected to validation checks, resulting in the
following potential errors, which must be corrected before compilation:
SQLCODE
SQLSTATE
Condition
-107
54003
Host variable name too long
-307
spaces
Duplicate host variable names
-314
spaces
Syntax and semantic errors in a host variable
16.
Data Type of Hexadecimal Constants
Prior to V3R4, application programs that assumed that hexadecimal constants
have a data type of VARGRAPHIC, because they are used in the context of
GRAPHIC and VARGRAPHIC data, were accepted.
In V3R4, such constants are considered to be VARCHAR. If used in
conjunction with GRAPHIC or VARGRAPHIC data, they will cause a number
of specific SQLCODEs and corresponding SQLSTATEs, dependent on
individual cases.
This also means that SQLCODE -421 (SQLSTATE 53055), dealing with
hexadecimal literals of odd length, is no longer generated.
17.
Non-updatable View
Prior to V3R4, a user with DBA authority who tried to update a view that was
not updatable got an appropriate error, such as SQLCODE -154 (SQLSTATE
56009). A user without DBA authority, however, got an authorization error,
SQLCODE -551 (SQLSTATE 59001).
In V3R4, the latter user receives the same error message as the DBA user,
instead of the authorization message.
18.
SYSTEM Table Missing from the System Catalog
Prior to V3R4, if you tried to INSERT, DELETE, or UPDATE a table or view
created by 'SYSTEM', but which was not in the system catalog, SQLCODE
-823
(SQLSTATE 53032) was generated, indicating that you lacked proper
authorization.
In V3R4, SQLCODE -204 (SQLCODE 52004) is generated instead, indicating
that the object could not be found in the system catalog.
19.
Folding of Lowercase in PREP and DBSU
Prior to V3R4, folding of lowercase into uppercase in PREP and the DBS
Utility was done by adding X’40’ to the hexadecimal representation of the
lowercase character. Sometimes this resulted in characters being folded
incorrectly (for example, in the Katakana character set).
In V3R4, this is done using the 370 built-in Assembler instruction
TRANSLATE and the user-specified character translation table, in order to be
consistent with how the application server handles this operation. One
exception to this is when the DBS Utility processes SCHEMA input files.
Folding is no longer done on these files; this makes it consistent with the DBS
Utility control file, which only allows uppercase input.
If your applications have built-in dependencies on the previous folding
scheme, you could get different results. For example, a Katakana user may
have a character in his or her coding scheme that has a hexadecimal value
that appears to the SQL/DS system as one of the 26 lowercase English letters.
414
System Administration
Instead of being folded to uppercase English, the Katakana character will now
be folded according to the Katakana character translation table.
If you have lowercase in your DBS Utility SCHEMA input file, you will have
to change it to uppercase.
20.
Loading Audit Trace
Prior to V3R4, the Database Administration manual contained sample table
definition and DATALOAD parameters for creating a security audit table and
loading trace records into it.
In V3R4, the position of the columns within the table are changed and a new
column, EXTLUWID, added. If you have been loading audit trace data using
this table definition and a DATALOAD job, you will need to change the
DATALOAD job, as documented in the V3R4 Database Administration manual.
If you also want to make use of the new EXTLUWID column, you will need
to recreate the table as well.
21.
Use of Host Variables in CONNECT Statement
Prior to V3R4, if you used a host variable for the userid or password in a
CONNECT statement and the data type of that variable did not satisfy one of
the conditions listed below, an error was generated at run time:
v C programs: C-NUL string of length 9
v Assembler, COBOL, or PL/I programs: fixed length character string of
length 8.
In V3R4, these conditions are checked by the preprocessor. If they fail the
check, SQLCODE -324 (SQLSTATE spaces) is generated.
22.
Data Types of Parameter Markers in Predicates
Prior to V3R4, the resolution of data types for a parameter marker was
dependent on the highest order of the data types of all the operands to the
left of the parameter marker. Highest order, in the case of numeric operands,
implies FLOAT > DECIMAL > INTEGER > SMALLINT.
In V3R4, this resolution process is changed to become more consistent with
the DB2 product. If there is an operand expressed as a column name in a
BETWEEN predicate, the data type of any parameter marker is resolved as
that of the leftmost such operand. Otherwise, the data type of the parameter
marker is resolved as that of the leftmost operand that is not a parameter
marker — whether in a BETWEEN predicate or an IN predicate.
This could cause a different result from previous releases for predicates that
can have more than two operands (namely BETWEEN and IN), but only if
your application assigns parameter marker values that are inappropriate for
your data.
See “Detailed Notes on V3R4-V3R2 Incompatibilities” on page 418 for some
examples and further discussion.
23.
Bad Input Records in DATALOAD
Prior to V3R4, a bad input record would terminate DATALOAD command
processing on multiple tables when the DBS Utility was running in multiple
user mode — whether or not it was preprocessed with the NOBLOCK option.
An insert error would be indicated with one of the following codes, followed
by message ARI0862E:
SQLCODE SQLSTATE
-405
53020
-424
22502
-530
23503
-802
22003, 22012, or 22502
-803
23505
Appendix I. Incompatibilities Between Releases
415
In V3R4, such command processing is no longer terminated, if the DBS Utility
is preprocessed with the NOBLOCK option. The error indications are still
generated, but the processing skips over the bad record and continues.
If you have a dependency in your application on this termination approach
prior to V3R4, you may want to address this change in the case of the
NOBLOCK option.
24.
Index Dependency of a Package
Prior to V3R4, when a SELECT DISTINCT was applied to a single column
that had a unique index, the system assumed uniqueness within the column,
rather than applying a sort. However, this kind of index dependency was not
recorded in the package.
In V3R4, this technique now records the index dependency in the package (for
system integrity), even though the index is not actually used to access the
table. In addition, the technique is extended to column functions that use
DISTINCT — for example, SELECT COUNT(DISTINCT(COL4)), where COL4
has a unique index.
If the index is dropped, the package will now be marked as invalid, causing a
dynamic reprep. After the reprep, the application will take longer to execute,
because a sort will be needed to process DISTINCT correctly.
25.
SQLSTATE Changes
Prior to V3R4, certain SQLCODEs had associated SQLSTATEs that did not
conform to the SAA standards.
In V3R4, these SQLSTATEs are replaced with ones that do conform. See
“Detailed Notes on V3R4-V3R2 Incompatibilities” on page 418 for a list of
these codes, along with their old and new SQLSTATEs.
System Environment
26.
The Use of DBCS Characters with the CHARNAME Setting
Prior to V3R4, you could use graphic or mixed constants, the VARGRAPHIC
scalar function, or you could define columns as GRAPHIC or FOR MIXED
DATA, independent of the CHARNAME setting on the application server.
Furthermore, you could use graphic or mixed constants, independent of the
CHARNAME setting on the application requester.
In V3R4, the above usages result in error conditions such as SQLCODE -640
(SQLSTATE 56031) and SQLCODE -332 (SQLSTATE 57017), if the
corresponding CHARNAME does not define a character set with mixed
CCSID (that is, if CCSIDMIXED = 0).
27.
Setting of CHARNAME
Prior to V3R4, if no CHARNAME is specified, SQLSTART defaulted to
CHARNAME = ENGLISH.
In V3R4, it defaults to the CHARNAME used on the previous invocation. If
the CHARNAME setting does not define a character set with mixed CCSID
(that is, if CCSIDMIXED = 0), then the default character subtype (CHARSUB)
will be forced to a value of SBCS.
See the V3R4 System Administration manual for the initial default
CHARNAME value after installation or migration.
28.
Addressing Mode 31-Bit
Prior to V3R4, user exits and field procedures , executed in a VSE
environment, only ran in 24-bit addressing mode.
In V3R4, with VSE/ESA* 1.3 or later releases, they can be executed in 31-bit
addressing mode. If the SQL/DS system is running in 31-bit addressing mode
416
System Administration
(that is, ESA or VMESA supervisor mode) on the application server, then user
exits (except accounting) will be executed in 31-bit addressing mode.
If you have user exits (except accounting) that fit into this category, you must
do one of the following to avoid any potential problems:
v Ensure that they can accommodate 31-bit addressing mode
v Operate the application server in 370 or VM supervisor mode.
For more information on user exits, see the DB2 Server for VSE System
Administration manual.
29.
Section Size in a Package
Prior to V3R4, during the preprocessing of a program, the system allocated a
section size for each statement in the package.
In V3R4, due to other design changes, it is necessary to increase the size of
these sections for SELECT statements. As a result, when an existing package is
subjected to a dynamic repreparation, it may cause the dbspace to become
full, generating SQLCODE -946 (SQLSTATE 57025).
If this occurs in your installation, you will have to explicitly prepare the
program with the SQLPREP EXEC, making sure that you have a dbspace that
can accommodate the revised package.
Also, the larger sections increase the amount of virtual storage required to run
the package. For example, if you have many dynamic SELECT statements in a
logical unit of work, they will use up more storage than in the previous
release.
30.
Three-Part Object Names
Prior to V3R4, an object that was created on a database named (for example)
DBX could be successfully referenced later by an application, even though the
name for that database had been changed (to, say, DBY). All you had to do
was use the revised name, DBY, when you established the database for the
application.
In V3R4, the system maintains the name of the database that was used at the
time of the object’s creation (DBX in this example), as the first part of the
object name, thereby making it a three-part name. If you now establish the
database for the application under a different name (for example, DBY), the
system uses that name as the new qualifier when you try to reference the
object. This results in a mismatch of object names, and causes SQLCODE -114
(SQLSTATE 56061) to be generated.
This problem can be avoided by simply not changing the names of your
databases.
31.
Special Characters for CONCAT Operation and Not Equal Condition
Prior to V3R4, the class of the hexadecimal values in the table below was 0.
CHARNAME
Hexadecimal Values
ENGLISH
X'5A', X'B0'
FRENCH
X'BA', X'BB'
GERMAN
X'BA', X'BB'
ITALIAN
X'BA', X'BB'
KATAKANA
X'5A', X'B0'
SPANISH
X'BA', X'BB'
In V3R4, the class of these hexadecimal characters is changed to 6. This is
reflected in the CHARCLASS column values of the SYSTEM.SYSCHARSETS
catalog table. This change provides additional special characters that can be
Appendix I. Incompatibilities Between Releases
417
used to depict the CONCAT operation and the not equal condition in SQL
syntax. This, in turn, provides greater flexibility in the use of these two SQL
facilities between application requesters and servers that are assigned different
CHARNAMES.
This could affect your applications, if they are dependent on previous
reclassifications of any of the above characters from class 0 to class 3, for use
in ordinary identifiers. For example, if you had reclassified the explanation
mark (!) so that DANGER! could be used as an ordinary identifier, this will no
longer work because the explanation mark is one of the characters that is now
assigned to class 6.
See the DB2 Server for VSE System Administration manual for details on these
classifications.
32.
Invocation of TRACE for Storage
Prior to V3R4, if you specified level 2 trace for the STAT or PA component of
the TRACDBSS or TRACRDS parameter, respectively, when starting the
SQL/DS system, you received the Working Storage Manager tracing.
In V3R4, you can use the same specifications, but the Working Storage
manager tracing is no longer part of the output.
In order to get this part, you must now use the TRACSTG parameter, or select
the STG component when using the TRACE operator command. The format
from this trace is different.
33.
Change to Headers in Multiline Operator Console Messages
Prior to V3R4, for ease of reading, only the first line of a multiline message
contained the message header identification, as illustrated below:
ARI0418A SQL/DS is not ready. Retry the enable
transaction CIRB after SQL/DS starts.
However, operator console messages which were multiline could not be
handled by the VSE Programmed Operator tool, because the system sent such
messages one line at a line. The tool could not identify the extra lines.
In V3R4, these operating console messages are sent as one multiline record, so
that the VSE Programmed Operator tool can handle them. (For the console
operator, there is no change to the appearance of these messages.)
If you have your own application equivalent to the above tool, it could be
affected by this change.
Detailed Notes on V3R4-V3R2 Incompatibilities
1.
Data Types of Parameter Markers in Predicates
In this first example, prior releases would resolve the data type of the
parameter marker as DEC(4,2), whereas V3R4 would resolve it as INTEGER
(assuming INTEGERCOL is the name of a column with a data type of
INTEGER).
23.55 BETWEEN ? AND INTEGERCOL
The next two examples illustrate how these data type differences can produce
quite different end results when the SQL statement is executed. In this next
example, the predicate would generate SQLCODE -302 (SQLSTATE 22003) in
prior releases, when the leftmost parameter marker is assigned a value of 345
and the rightmost parameter marker is assigned a value of 206.7. This error will
not occur in V3R4.
EDLEVEL IN (16, ?, 17.3, ?)
418
System Administration
This is because the prior releases assign a data type of DEC(3,1) to the
rightmost parameter marker, to which the value 206.7 cannot be assigned. V3R4
assigns a data type of SMALLINT to the rightmost parameter marker (based on
the column EDLEVEL) and then truncates 206.7 to accommodate this data type.
In the next example, the predicate would generate SQLCODE -302 (SQLSTATE
22001) in V3R4, but not in prior releases, when the parameter marker is
assigned a value of 'GHIJKL'.
DEPTNO IN (’ABCDEF’, ?, ’ABC’)
This is because V3R4 assigns a data type of CHAR(3) to the parameter marker
(based on column DEPTNO), to which the value 'GHIJKL' cannot be assigned.
Prior releases assign a data type of CHAR(6) to the parameter marker.
2. SQLSTATE Changes
These changes are shown in the following table.
Old
New
SQLCODE
SQLSTATE
SQLSTATE
DESCRIPTION
-131
53004
22019
Either the LIKE predicate has an invalid escape character, or the
string pattern contains an invalid occurrence of the escape
character.
-551
59001
42501
User wwwwww does not have the xxxxxx privilege to perform
yyyyyy on zzzzzz.
-552
59002
42502
xxxxxx is not authorized to yyyyyy.
-554
59002
42502
You cannot grant a privilege to yourself.
-555
59002
42502
You cannot revoke an authority or a privilege from yourself.
-556
59002
42502
An attempt to revoke a privilege from xxxxxx was denied.
Either xxxxxx does not have this privilege, or yyyyyy does not
have this authority to revoke this privilege.
-556
59004
42504
An attempt to revoke a privilege from xxxxxx was denied.
Either xxxxxx does not have this privilege, or yyyyyy does not
have this authority to revoke this privilege.
-558
59004
42504
You cannot revoke an authority from xxxxxx because xxxxxx
has DBA authority.
-560
59005
42505
A CONNECT statement contains an incorrect password for
xxxxxx.
-561
59005
42505
User xxxxxx does not have CONNECT authority.
-566
59001
42501
User ID xxxxxx does not have authorization to modify package
yyyyyy.
-606
59002
42502
The COMMENT ON or LABEL on statement failed because the
specified table or column is not owned by xxxxxx.
-610
59002
42502
The statement failed because a user without DBA authority
attempted to create a table in a DBSPACE owner by another
user or by the system.
-708
59002
42502
You cannot ALTER, LOCK, or DROP a PUBLIC DBSPACE
because you do not have DBA authority.
-713
37515
53015
Incorrect isolation level value xxxxxx specified. Only values C
or R may be used.
-801
22004
22003
Exception error xxxxxx occurred during yyyyyy operation on
zzzzzz data.
-802
22004
22003
Exception error xxxxxx occurred during yyyyyy operation on
zzzzzz data, position nnnnnn. psw1 psw2.
Appendix I. Incompatibilities Between Releases
419
Old
New
SQLCODE
SQLSTATE
SQLSTATE
DESCRIPTION
-815
59005
42502
CONNECT denied by accounting user exit routine.
-30053
59006
42506
Owner xxxxxx authorization failed.
V3R5
and V3R4 Incompatibilities
1.
SQL/DS Database Archive Incompatibilities
Archives that were created on prior releases of SQL/DS cannot be restored by
the SQL/DS V3R5 database manager. If this is attempted, the database manager
will issue message ARI2038E and terminate. See the DB2 Server for VM Messages
and Codes or DB2 Server for VSE Messages and Codes manual for more details on
this message.
2.
SQL/DS VSAM Shareoptions Changes under VSE
In prior releases of SQL/DS (VSE), the VSAM SQL/DS directory, data and log
data sets were defined with SHAREOPTIONS(1). In SQL/DS V3R5, these
VSAM files must now be defined with SHAREOPTIONS(2).
3.
SQLSTATE Values Changes
Many SQLSTATE values have changed in SQL/DS V3R5. The new SQLSTATE
values and their former values can be found in the DB2 Server for VM Messages
and Codes or DB2 Server for VSE Messages and Codes manuals. Changing
SQLSTATEs is an incompatible change since many SQLSTATE values that are
returned from diagnostic situations will be different from previous releases of
SQL/DS. Application programmers should review any programs that use
SQLSTATE in the SQLCA each time an SQL statement is executed.
4.
Messages and Codes Changes
Some SQL/DS messages and codes have changed, and some new ones have
been added in SQL/DS V3R5. See the DB2 Server for VM Messages and Codes
and DB2 Server for VSE Messages and Codes manuals for details.
5.
Display CICS Information on SHOW CONNECT
If the package that the connected user is running was created in SQL/DS
Version 2 Release 2 or earlier, the CICS information will not be displayed by
the SHOW CONNECT command because the RDIIN for V2R2 or earlier does
not contain the RDIIN extension area. The package must be reprepped with
SQL/DS V3R5 and recompiled to make the CICS information available.
V5R1
and V3R5 Incompatibilities
1. Messages and Codes Changes
Many messages and codes have changed, and some new ones have been added
in DB2 Server for VSE & VM Version 5 Release 1. See the DB2 Server for VM
Messages and Codes and DB2 Server for VSE Messages and Codes manuals.
2. DB2 Database Archive Incompatibilities
Archives that were created on prior releases cannot be restored by the DB2
Server for VSE & VM Version 5 Release 1 database manager. If this is
attempted the database manager will issue message ARI2038E and terminate.
See the DB2 Server for VSE Messages and Codes manual.
3. DBSU
If you use R350 DBSU to unload and reload a table in a R510 database, the
value of the DATACAPTURE column will be lost.
4. Date/Time Exits and Field Procedures
420
System Administration
VM Users with Date/Time or Field Procedure Exits that are dependant on
running in a 370 Mode virtual machine must convert to execute in a ESA mode
virtual machine. Note that exits requiring AMODE=24 are not affected, as we
still support running the Server code in AMODE=24. The above also applies to
Single User Mode application programs. The above also applies to Vendor
programs that run on the Server, such as database monitoring or tape mount
handling programs.
V6R1
and V5R1 Incompatibilities
1. Exploiting RDS above the 16 Megabyte Line
With Version 7 Release 5, the RDS component is linkedited with the ″RMODE
ANY″ option. This allows RDS to be loaded and executed above the 16MB line.
This will free up valuable storage below the 16 MB line. As the RDS code will
be loaded above the 16MB line before other storage is allocated, extremely
storage constrained systems may need to increase their partition size to
maximize their below the 16MB line free storage.
2. DBNAME Directory format change
The format of the DBNAME directory source member, ARISDIRD, has been
changed to support DRDA Online Requester support. See “Setting Up the
DBNAME Directory” on page 23. See the DB2 Server for VSE System
Administration manual.
V7R1
and V6R1 Incompatibilities
1. DBNAME Directory format change
ARISDIRD has been restructured to improve readability and flexibility. Each
DBNAME entry is now defined explicitly by its type (Local, Remote or Host
VM (Guest Sharing)). CICS AXE Transaction TPNs (Transaction Program
Names) are still included in the directory as a type of ’LOCALAXE’. The
DBNAME Directory Builder program, ARICBDID has been rewritten as a
REXX/VSE procedure with extensive error and dependency checking. Support
for TCP/IP information is added and ’alias’ DBNAMEs are supported. ALL
DBNAMEs must be specified in the new DBNAME Directory, including the
Product Default DBNAME ″SQLDS″. A migration REXX/VSE procedure,
ARICCDID, is provided to assist in migrating to the new format.
V7R2
and V7R1 Incompatibilities
There are no incompatibilities between DB2 Server for VSE V7R2 and DB2 Server
for VSE V7R1.
V7R3
and V7R2 Incompatibilities
There are no incompatibilities between DB2 Server for VSE V7R3 and DB2 Server
for VSE V7R2.
Appendix I. Incompatibilities Between Releases
421
422
System Administration
Notices
IBM may not offer the products, services, or features discussed in this document in
all countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user’s responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10594-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement may not apply
to you.
This information could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
423
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
Mail Station P300
522 South Road
Poughkeepsie, NY 12601-5400
U.S.A
Such information may be available, subject to appropriate terms and conditions,
including in some cases, payment of a fee.
The licensed program described in this information and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement, or any equivalent agreement
between us.
Any performance data contained herein was determined in a controlled
environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurement may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of
those products, their published announcements, or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility, or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
All statements regarding IBM’s future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.
This information may contain examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information may contain sample application programs in source language,
which illustrates programming techniques on various operating platforms. You
may copy, modify, and distribute these sample programs in any form without
payment to IBM, for the purposes of developing, using, marketing, or distributing
application programs conforming to the application programming interface for the
operating platform for which the sample programs are written. These examples
have not been thoroughly tested under all conditions. IBM, therefore, cannot
guarantee or imply reliability, serviceability, or function of these programs.
424
System Administration
Programming Interface Information
This manual is intended to help system administrators plan and maintain the DB2
Server for VSE database manager.
This manual also documents General-Use Programming Interface and Associated
Guidance Information provided by the DB2 Server for VSE database manager.
General-Use programming interfaces allow the customer to write programs that
obtain the services of the DB2 Server for VSE database manager.
General-Use Programming Interface and Associated Guidance Information is
identified where it occurs, either by an introductory statement to a chapter or
section or by the following marking:
General-Use Programming Interface
General-Use Programming Interface and Associated Guidance Information...
End of General-Use Programming Interface
Trademarks
The following terms are trademarks of International Business Machines
Corporation in the United States, or other countries, or both:
AIX/6000
CICS
CICS/VSE
DATABASE 2
DB2
DB2 for AIX
DB2 Server for VM
DB2 Server for VSE
DB2 Server for VSE & VM
Distributed Relational Database Architecture
DRDA
IBM
OS/2
OS/400
SQL/DS
System/370
System/390
Virtual Machine/Enterprise Systems Architecture
VM/ESA
VSE/ESA
VTAM
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States other countries, or both.
Intel and Intel-based trademarks and logos are trademarks or registered
trademarks of Intel Corp.
Unix and Unix-based trademarks and logos are trademarks or registered
trademarks of The Open Group.
Other company, product, and service names may be trademarks or service marks
of others.
Notices
425
426
System Administration
Bibliography
This bibliography lists publications that are
v IBM VSE/ESA Messages & Codes, SC33-6507
referenced in this manual or that may be helpful.
v IBM VSE/ESA Networking Support, SC33-6508
v IBM VSE/ESA Operation, SC33-6506
DB2 Server for VSE Publications
v IBM VSE/ESA Planning, SC33-6503
v DB2 Server for VSE & VM Application
v IBM VSE/ESA System Control Statements,
Programming, SC09-2889
SC33-6513
v DB2 Server for VSE & VM Database
v IBM VSE/ESA System Macros User’s Guide,
Administration, SC09-2888
SC33-6515
v DB2 Server for VSE & VM Database Services
v IBM VSE/ESA System Macros Reference,
Utility, SC09-2983
SC33-6516
v DB2 Server for VSE & VM Diagnosis Guide and
v IBM VSE/ESA System Utilities, SC33-6517
Reference, LC09-2907
v IBM VSE/ESA Unattended Node Support,
v DB2 Server for VSE & VM Overivew, GC09-2995
SC33-6512
v DB2 Server for VSE & VM Interactive SQL Guide
v IBM VSE/ESA Using IBM Workstations,
and Reference, SC09-2990
SC33-6509
v DB2 Server for VSE & VM Master Index and
Glossary, SC09-2890
CICS/VSE Publications
v DB2 Server for VSE Messages and Codes,
v
CICS/VSE Application Programming Reference,
GC09-2985
SC33-0713
v DB2 Server for VSE & VM Operation, SC09-2986
v
CICS/VSE Application Programming Guide,
v DB2 Server for VSE System Administration,
SC33-0712
SC09-2981
v
CICS Application Programming Primer (VS
v DB2 Server for VSE & VM Performance Tuning
COBOL II), SC33-0674
Handbook, GC09-2987
v
CICS/VSE CICS-Supplied Transactions, SC33-0710
v DB2 Server for VSE & VM SQL Reference,
v
CICS/VSE Customization Guide, SC33-0707
SC09-2989
v
CICS/VSE Facilities and Planning Guide,
SC33-0718
Related Publications
v
CICS/VSE Intercommunication Guide, SC33-0701
v DB2 Server for VSE & VM Data Restore,
SC09-2991
v
CICS/VSE Performance Guide, SC33-0703
v DRDA: Every Manager's Guide, GC26-3195
v
CICS/VSE Problem Determination Guide,
SC33-0716
v IBM SQL Reference, Version 2, Volume 1,
SC26-8416
v
CICS/VSE Recovery and Restart Guide, SC33-0702
v IBM SQL Reference, SC26-8415
v
CICS/VSE Release Guide, GC33-1645
v
CICS/VSE Report Controller User’s Guide,
Virtual Storage Extended/Enterprise Systems
SC33-0705
Architecture (VSE/ESA) Publications
v
CICS Transaction Server for VSE/ESA V1R1.0
v IBM VSE/ESA Administration, SC33-6505
Resource Definition Guide, SC33-0709
v IBM VSE/ESA Diagnosis Tools, SC33-6514
v
CICS/VSE Resource Definition (Online),
v IBM VSE/ESA General Information, GC33-6501
SC33-0708
v IBM VSE/ESA Guide for Solving Problems,
v
CICS/VSE System Definition and Operations
SC33-6510
Guide, SC33-0706
v IBM VSE/ESA Guide to System Functions,
v
CICS/VSE System Programming Reference,
SC33-6511
SC33-0711
v IBM VSE/ESA Installation, SC33-6504
v
CICS/VSE User’s Handbook, SX33-6079
427
v CICS/VSE XRF Guide, SC33-0704
Other Distributed Data Publications
v IBM Distributed Data Management (DDM)
CICS/ESA Publications
Architecture, Architecture Reference, Level 4,
v CICS/ESA General Information, GC33-0803
SC21-9526
v IBM Distributed Data Management (DDM)
VSE/Virtual Storage Access Method (VSE/VSAM)
Architecture, Implementation Programmer’s Guide,
Publications
SC21-9529
v VSE/VSAM Commands and Macros, SC33-6532
v VM/Directory Maintenance Licensed Program
v VSE/VSAM Introduction, GC33-6531
Specification, GC20-1836
v VSE/VSAM Messages and Codes, SC24-5146
v IBM Distributed Relational Database Architecture
Reference, SC26-4651
v VSE/VSAM Programmer’s Reference, SC33-6535
v IBM Systems Network Architecture, Format and
VSE/Interactive Computing and Control Facility
Protocol Reference, SC30-3112
(VSE/ICCF) Publications
v SNA LU 6.2 Reference: Peer Protocols, SC31-6808
v VSE/ICCF Administration and Operation,
v Reference Manual: Architecture Logic for LU Type
SC33-6562
6.2, SC30-3269
v VSE/ICCF Primer, SC33-6561
v IBM Systems Network Architecture, Logical Unit
v VSE/ICCF User’s Guide, SC33-6563
6.2 Reference: Peer Protocols, SC31-6808
v Distributed Data Management (DDM) General
VSE/POWER Publications
Information, GC21-9527
v VSE/POWER Administration and Operation,
SC33-6571
CCSID Publications
v VSE/POWER Application Programming,
v Character Data Representation Architecture,
SC33-6574
Executive Overview, GC09-2207
v VSE/POWER Networking, SC33-6573
v Character Data Representation Architecture
Reference and Registry, SC09-2190
v VSE/POWER Remote Job Entry, SC33-6572
C/370 Publications
Distributed Relational Database Architecture
(DRDA) Library
v IBM C/370 Installation and Customization Guide,
GC09-1387
v Application Programming Guide, SC26-4773
v IBM C/370 Programming Guide, SC09-1384
v Architecture Reference, SC26-4651
v Connectivity Guide, SC26-4783
Communication Server for OS/2 Publications
v DRDA: Every Manager's Guide, GC26-3195
v Up and Running!, GC31-8189
v Planning for Distributed Relational Database,
v Network Administration and Subsystem
SC26-4650
Management Guide, SC31-8181
v Problem Determination Guide, SC26-4782
v Command Reference, SC31-8183
v Message Reference, SC31-8185
C/370 for VSE Publications
v Problem Determination Guide, SC31-8186
v IBM C/370 General Information, GC09-1386
v IBM C/370 Programming Guide for VSE,
Distributed Database Connection Services
SC09-1399
(DDCS) Publications
v IBM C/370 Installation and Customization Guide
v DDCS User’s Guide for Common Servers,
for VSE, GC09-1417
S20H-4793
v IBM C/370 Reference Summary for VSE,
v DDCS for OS/2 Installation and Configuration
SX09-1246
Guide, S20H-4795
v IBM C/370 Diagnosis Guide and Reference for
VSE, LY09-1805
VTAM Publications
v VTAM Messages and Codes, SC31-6493
VSE/REXX Publication
v VTAM Network Implementation Guide, SC31-6494
v VSE/REXX Reference, SC33-6642
428
System Administration
v VTAM Operation, SC31-6495
v VS COBOL II Application Programming
Debugging, SC26-4049
v VTAM Programming, SC31-6496
v VS COBOL II Installation and Customization for
v VTAM Programming for LU 6.2, SC31-6497
CMS, SC26-4213
v VTAM Resource Definition Reference, SC31-6498
v VS COBOL II Installation and Customization for
v VTAM Resource Definition Samples, SC31-6499
VSE, SC26-4696
v VS COBOL II Application Programming Guide for
CSP/AD and CSP/AE Publications
VSE, SC26-4697
v Developing Applications, SH20-6435
v CSP/AD and CSP/AE Installation Planning Guide,
Systems Network Architecture (SNA)
GH20-6764
Publications
v Administering CSP/AD and CSP/AE on VM,
v SNA Transaction Programmer’s Reference Manual
SH20-6766
for LU Type 6.2, GC30-3084
v Administering CSP/AD and CSP/AE on VSE,
v SNA Format and Protocol Reference: Architecture
SH20-6767
Logic for LU Type 6.2, SC30-3269
v CSP/AD and CSP/AE Planning, SH20-6770
v SNA LU 6.2 Reference: Peer Protocols, SC31-6808
v Cross System Product General Information,
v SNA Synch Point Services Architecture Reference,
GH23-0500
SC31-8134
Query Management Facility (QMF) Publications
Miscellaneous Publications
v Introducing QMF, GC27-0714
v IBM 3990 Storage Control Planning, Installation,
v Installing and Managing QMF for VSE,
and Storage Administration Guide, GA32-0100
GC27-0721
v Dictionary of Computing, ZC20-1699
v QMF Reference, SC27-0715
v APL2 Programming: Using Structured Query
v Installing and Managing QMF for VM,
Language, SH21-1056
GC27-0720
v ESA/390 Principles of Operation, SA22-7201
v Developing QMF Applications, SC27-0718
Related Feature Publications
v QMF Messages and Codes, GC27-0717
v
DB2 for VSE Control Center Operations Guide,
v Using QMF, SC27-0716
GC09-2992
Query Management Facility (QMF) for Windows
v
DB2 Replication Guide and Reference, SC26-9920
Publications
v Getting Started with QMF for Windows,
SC27-0723
v Installing and Managing QMF for Windows,
GC27-0722
DL/I DOS/VS Publications
v DL/I DOS/VS Application Programming,
SH24-5009
COBOL Publications
v VS COBOL II Migration Guide for VSE,
GC26-3150
v VS COBOL II Migration Guide for MVS and
CMS, GC26-3151
v VS COBOL II General Information, GC26-4042
v VS COBOL II Language Reference, GC26-4047
v VS COBOL II Application Programming Guide,
SC26-4045
Bibliography
429