Hi,

I have been encountering problems with the some data flows erroring out due to connection problems between the
application and the data base servers. I am not sure if there is a setting within the DMC tool that needs to
be set to address this problem.

Listed below is some information about this problem.

-> The data flow is pretty straightforward. It reads a table from the i-series and writes out to a flat file.

-> During peak times on the i-series box that is the data source, the data flow will always get this error. During
less busy times the problem occurs less frequently.

-> The DMC tool resides on a Linux box and the data resides on an i-series.

-> The jdbc driver used to access the i-series box is com.ibm.as400.access.AS400JDBCDriver.

-> Java classes were written to access the same tables as the data flows do using the same jdbc driver and there were
no errors thrown. With this in mind, I am leaning towards there being a setting that needs to be changed.

-> I am on version 7.6.8 of the DMC.

-> Below is a section of the server log for the failed test run. As you will see, the process times out pretty quickly.

DEP_9: procedure detaildemand_processreservations_test started.
Request - detaildemand_processreservations_test (Owner: wfadmin) submitted.
synonyms_flatfiles/dwrsvdimpf_flatfile type Flat File New target
Issuing PREPARE
Request will process data via NON-Pass Through (NON-APT)
HOLD file will be created for output file named: SQLIN.
(FOC1400) SQLCODE IS -99999 (HEX: FFFE7961) XOPEN: 08S01
: (-99999) [08S01] Communication link failure. (Read timed out)
(FOC1407) SQL FETCH CURSOR ERROR. : DWRSVDIMPF
1
0 NUMBER OF RECORDS IN TABLE= 3300 LINES= 3300
0
Return Code = 1407
Request: detaildemand_processreservations_test - finished processing
CPU Time : 70
DEP_9 detaildemand_processreservations_test Return Code = 1407
DEP_13: procedure detaildemand_processrequests_test started.
Request - detaildemand_processrequests_test (Owner: wfadmin) submitted.
synonyms_flatfiles/dwrqsdimpf_flatfile type Flat File New target
Issuing PREPARE
Request will process data via NON-Pass Through (NON-APT)
HOLD file will be created for output file named: SQLIN.
(FOC1400) SQLCODE IS -99999 (HEX: FFFE7961) XOPEN: 08003
: (-99999) [08003] The connection does not exist.
(FOC1406) SQL OPEN CURSOR ERROR. : DWRQSDIMPF
1
0 NUMBER OF RECORDS IN TABLE= 0 LINES= 0
0
Return Code = 18708
Request: detaildemand_processrequests_test - finished processing
CPU Time : 10
DEP_13 detaildemand_processrequests_test Return Code = 18708
Output retrieved
Elapsed run time 0:00:40



If you need more information on the above mentioned, please let me know.

Thank you in advance.

Tom

Hi Tom,

What database are you going against for the source data that they believe there is a performance problem with? Is it MySQL? More information may be of help to better understand the problem.

Cheers,

Kerry

Hi Kerry,

Sorry for the late response to your question - I have not been on the bulletin
board lately.

The database being accessed is a DB2 database that resides on an i-series box. Also,
we are using the generic jdbc driver and not the jdbc driver for db2.

As an fyi, the error seems to surface when there is a heavy usage taking place on
the i-series. When the activity level tapers off during the day, the process flow
runs without any issue. It looks like the request to get the data from the i-series
gets deprived of the resources it needs for the request and as a result the connection
error gets thrown.

Thanks in advance for any information you can proive on this.

Tom

Hi Tom,

We do not support access to DB2 with the JDBC Adapter. It is not sure if it will make a difference here, but you may want to try using the DB2 adapter and retest. This sounds like some resource issues outside of our product, so the recommendation would be to consult with your system people.

Cheers,

Kerry

Hi Kerry,

A ticket was just opened up for this. Thanks
for your help on this.

Tom

Hi Tom,

Thanks for the update. When you hear some info from the case, would you please post it later? Many thanks for sharing with all.

Cheers,

Kerry