Oracle® Access Manager for AS/400 Installation and User's Guide 10g Release 2 (10.2) for IBM iSeries OS/400 Part Number B16223-01 |
|
|
View PDF |
This chapter contains release information for Oracle Access Manager for AS/400. It includes the following sections:
The following products and component versions are included on the product CD-ROM. All components are at production level.
Oracle Access Manager for AS/400: 10.2.0.1.0
Oracle Net, TCP/IP adapter: 10.2.0.1.0
The following changes and enhancements have been made in release 10.2.0.1.0 of Oracle Access Manager for AS/400.
The following changes have been made in this release of the Oracle Access Manager:
The following bugs have been fixed for this release of the Oracle Access Manager for AS/400:
4969332
Intermittent connection problems using Access Manager; ORA-12154 failures
4907795
Function called once but runs twice and gets errors ORA-00001 and ORA-06512
4873885
ORA-00020 Maximum number of processes exceeded
4771629
ORA00110, CPF7CFF errors when running CHGSQLNET under some CCSID
4683381
MCH3601 in AM400_RIDI at Stmt 61
4631655
AM400_RID Fails to run after changing system name
4610071
SQLSTATE 08000, SQLCODE -30080 when trying to CONNECT
4555789
AM400_RIDI job always has ORASRV0001 added to library list but other AM/400 programs use different ice program library
4006699
COBOL program fails with MCH3402 due to commitment control resource not being released at activation group end
3921461
Target Oracle Server runs out of processes
2966985
SQL0969 error when no precision is specified
5080676
Number format in Oracle, when access via AM is returning exponential format
NUMBER
fields that Oracle describes as having a precision of 0 and a scale of -127 are now taken as having a precision and scale of 0.
The following problems and restrictions are known to exist in the Oracle Access Manager for AS/400 products on the product CD-ROM. The description of problems includes suggestions for dealing with them, when possible.
A current list of problems is available online. Contact your local Oracle Corporation office for information about gaining access to this list.
The following problems are known to exist in the Oracle Access Manager for AS/400.
When using STRSQL, an ORA-1457 might occur on columns of type NUMBER
where no precision or scale is specified. Access Manager supplies default data types precision
and scale
, for these situations. Even the use of these data types, however, may not be sufficient, and you could still receive the ORA-1457 error. To check the default data type precision and scale values, use the Oracle Access Manager for AS/400 CHKSQLDFLT
command.
The AS/400 is shipped with the following default settings:
Datatype *PKDEC (packed decimal) Precision 7 Scale 2
For example, when using STRSQL with these settings, a column of type NUMBER
with a value of 123456 results in an ORA-1457 error. This error occurs because the setting of 7 for precision with the setting of 2 for scale allows for only five digits to the left of the decimal point (precision - scale = 7 - 2 = 5) To avoid this error, you can change the default data type to *FLOAT
or keep the data type as *PKDEC
and change the precision to 8 while keeping the default scale of 2. This will allow six digits to the left of the decimal point (precision - scale = 8 - 2 = 6).
Oracle hints cannot be specified in a SQL statement that is explicitly part of any EXEC
SQL statement. The IBM preprocessor strips out the Oracle hints, as if they were comments.
If you want Oracle hints in a DELETE
, SELECT
, or UPDATE
statement, then you must:
Copy the text of the relevant DELETE
, SELECT
, or UPDATE
statement to a host variable.
PREPARE
a statement from that host variable.
For a SELECT
, you must DECLARE
a cursor for that prepared statement. Open the cursor, and then FETCH
from that cursor.
For an UPDATE
or DELETE
, you must EXECUTE
the prepared statement.
The following limitations are known to exist with Oracle stored procedures:
You must use the DB2/400 DECLARE PROCEDURE
statement in preparation to call an Oracle stored procedure from an AS/400 program.
The DECLARE PROCEDURE
statement must have the same number of arguments as the Oracle PL/SQL procedure. The input and output modes must also be the same.
The SIMPLE CALL WITH NULLS
phrase is not supported. The SIMPLE CALL
phrase is supported.
The following restrictions are known to exist in the Oracle Access Manager for AS/400.
When using two-phase commit processing, COMMIT
or ROLLBACK
commands PREPARED
as dynamic SQL statements are rejected with the following error:
SQL0969: Error occurred while passing request to application requester driver program.
The following information is available in the job log:
ARDARPS: cannot PREPARE a COMMIT or ROLLBACK
For additional information on two-phase commit processing, refer to Chapter 8, "Using Access Manager".
Access Manager requires that the RDBCNNMTH
parameter be set to *DUW for any SQL package that is preprocessed with any of the CRTSQL
xxx
commands.
When using two-phase commit processing, CONNECT
is the only non-Data Manipulation Language (DML) SQL statement that is supported by Access Manager. Use of such non-DML statements results in the following error:
ORA-2089 COMMIT is not allowed in a subordinate session
The HOLD
parameter on an EXEC SQL COMMIT HOLD
command is not honored. All cursors are closed at each logical unit of work boundary (COMMIT
and ROLLBACK
).
Only the first 32,740 bytes in a LONG
or LONG RAW
column can be retrieved. This is because of the DB2/400 length limit on a LONG VARCHAR
column. Also note that the total data length on a SELECT
ed row is 32,760 bytes. The maximum length for a LONG
or LONG RAW
column will be further diminished by the amount of data in the OTHER
columns that are retrieved in that row.
The Access Manager can not be installed into a library that is part of an independent auxiliary storage pool (IASP). This is an IBM restriction on the placement of exit programs and subsystem descriptions. To get around this, just install the Access Manager in normal libraries on the machines/partitions that will be participating in the IASP. You should modify the user profiles of those users that will be using the Access Manager to retrieve DB2/400 data in an IASP so that the initial program (as defined in the User Profile) sets the current IASP group using the SETASPGRP
command.