When creating a new profile for the DirectConnect DB2 access service using the ODBC interface driver, a DB=; and a PWD=; are added to the dbparm after the first successful connection to DirectConnect in the profile painter. This causes errors the next time powerbuilder uses that profile which occurs immediately, since you are in the select dialogue window following the profile being created.

To solve the DB=; problem, edit the profile and remove the DB=; from the dbparm.

To solve the PWD=; problem:

• edit the profile, remove the PWD=; from the dbparm and have the driver prompt for the password.

  OR

• edit the profile and enter the correct password after the PWD=; in the dbparm parameter.

When migrating from an MDI gateway and Powerbuilder using the MDI interface driver (dbms: MDI) (pbmdi040.dll, pbmdi050.dll, pbmdi060.dll) to DirectConnect and Powerbuilder using the ODBC interface (dbms : ODBC) (pbodb040.dll, pbodb050.dll, pbodb060.dll), any datawindows with date columns that are being modified in the development environment, after migrating, will cause a -104 error in db2 when the update is sent to DB2.

To solve the problem:

• export the datawindow, change the date columns datatypes from datetime back to date and import the datawindow.
  

  OR
  

• configure the service in DirectConnect to gateway compatible=yes, and use the MDI interface. This will only work if you are using the EBF soon to be released (version 11.1.1P2). This EBF follows EBFi0063 (version 11.1.1P1).

When you are connecting to your database and a wrong userid and password is supplied to DB2, the following ambiguous error is returned:

[INTERSOLV][ODBC SQL server driver][SQL Server][VENDORLIB] Vendor Library Error: No error message is available.

This is the error in the DirectConnect log:
Error: 30252 Severity [VENDORLIB] Vendor Library Error: No error message is available from the host. <DB2>.
NETWORK ERROR:SYBLU62 ERROR INFO:,Request (recv), SubFunc (Unknown SubFunc), SYBLU^@ retCode (-7)
Description (SYBLU62_ERR_INVALID_SECURITY), LU62 APIRet2 (080F6051)
Description (SYBLU62_ERR_INVALID_SECURITY), LU62 APIRet2 (080F6051)
Description (SNA Sense Data (080F6051),
Description (Sense Category (08, Request reject),
Sense Code (080F, End User or LU Not Authorized), SECURITY FAILURE).}
<LocalLU=LOCAL>, <RemoteLU=DWMC141M>, <Logmode Name=MVSMODE>, <TPName=AMD2>

We are currently working on a solution to the problem.

Identifier delimiters in PowerBuilder 4.0

Within PowerBuilder 4.0, a default value asks PowerBuilder to put double quotes (") around table and column identifiers in the SQL statement.

For example, PB issues its SQL:

SELECT "DWMK52"."AUTHORS"."AU_ID", "DWMK52"."AUTHORS"."AU_LNAME" FROM "DWMK52"."AUTHORS"

This statement worked fine through the Database Gateway. PowerBuilder’s "Database Gateway" (DB-Lib) interface has a DBParm configuration option to set Identifier Delimiters on or off. PB 4.0 documentation states the default is "No" (off), however, in reality it defaults to "Yes"(on). This worked fine with the DB Gateways, so probably very few programmers ever specifically set it to "No".

However, the DB2 Access Service does not support double-quoted delimiters. The net effect is that PB applications will have to change and potentially be re-compiled with DirectConnect.

There are two possible workarounds:

1. Manually set the DBParm configuration option to "No" (off).
2. Use PowerBuilder’s ODBC interface with the DirectConnect ODBC driver.

In PowerBuilder releases of version 4.04 and higher, changes in its error handling policy have created issues with using Powerbuilder for RPC invocation in a non-DB2 environment.

The Powerbuilder Net Gateway interface issues Catalog Stored Procedures (CSPs) at initial Connect time. In a non-DB2 (and non-InfoHub) environment, these CSPs don’t exist, however. Prior to version 4.04, the PowerBuilder interface simply digested the errors and continued processing. Beginning with the 4.04 release, PowerBuilder issues an error and closes its Connection to Net Gateway when it receives no response to the CSPs it issues.

The workaround is to provide a set of mainframe transactions that return the appropriate CSP format descriptors without any data rows. We’ve written these transactions and they are available through Sybase Technical Support. These "dummy" CSPs will be incorporated into the standard product line.

The DirectConnect ships two separate Transaction Router service libraries, one each for APPC and TCP/IP.

The DB2 Access Service Library ships one service library and a couple stub DLLs to satisfy Windows NT.

Please follow the steps below if you are using TCP/IP Connectivity to MVS and do not have an SNA package installed. This is detectable if your installed DirectConnect application fails to run properly due to its inability to find WAPPC32.DLL:

1. In the %SYBASE%\eConnect\bin directory, copy or move the DLL named astubmsg.dll into your %systemroot%\system32 directory. This is the wappc32.dllevent log DLL.
2. In the %SYBASE%\eConnect\bindirectory, rename the DLL named appcstub.dll to wappc32.dll. This is a stubbed-out version of wappc32.dll that allows native TCP/IP customers to use the DB2 access libraries without installing SNA.

If a DB2 service is configured to use SNA, and SNA Server is not installed, the stub DLL provides the correct entry point functions, but the functions write a message to the Windows NT Application Event Log and throw an exception. This causes DirectConnect to stop and leaves an orphan copy of DIRECTC.EXE running. You must query the DirectConnect log file, find the DIRECTC process ID, and kill that process.

If you experience this behavior, reconfigure the offending service to use TCP/IP or correctly install SNA Server. If SNA Server is installed, then rename the %SYBASE%\eConnect\bin\wappc32.dll back to appcstub.dll to allow DirectConnect services to use SNA correctly.

If you attempt to insert data into a NUMERIC field using OmniConnect v. 10.5, and the backend database is the Transaction Router Service, the insert fails with an invalid Open Server datatype error.

As a workaround, create the table on OmniConnect using a DECIMAL(18,0) value instead of a NUMERIC value.