- There is no support for "USER" in the CBND parameter
ISOLATION. When specified, the system will override USER with
CS.
- 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).
- 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.
- 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:
- SET ISOLATION
- COUNTER
- 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.
- 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.
- 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.
- 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 data
8
is captured by the server
and put into accounting records.
- 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. This check will be performed during handshaking after having
established an APPC conversation with a DRDA server that supports security
handshaking.
- 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.
- The following DBSU commands are not supported when using the DRDA
protocol, because they request functions specific to DB2 Server for VSE:
- UNLOAD DBSPACE
- UNLOAD TABLE
- UNLOAD PACKAGE
- RELOAD DBSPACE
- RELOAD TABLE
- SET ISOLATION
- SET UPDATE STATISTICS
- REBIND PACKAGE
- REORGANIZE INDEX