DSXchange

Hello,

I am using DataStage to read from Azure SQL Server and Writing into Azure Sql Server. During the process of reading and writing using ODBC connector Job is performing the CDC .

For the High Data volume jobs, if the job runs for more than 30 minutes, I get this error message

ODBC_Target,5: ODBC function "SQLEndTran(SQL_COMMIT)" reported: SQLSTATE = 08S01: Native Error Code = 0: Msg = [IBM(DataDirect OEM)][ODBC SQL Server Wire Protocol driver]Socket closed.
ODBC function "SQLEndTran(SQL_COMMIT)" reported: SQLSTATE = 08S01: Native Error Code = 0: Msg = [IBM(DataDirect OEM)][ODBC SQL Server Wire Protocol driver]SSL I/O Error.
ODBC function "SQLEndTran(SQL_COMMIT)" reported: SQLSTATE = HY000: Native Error Code = 5: Msg = [IBM(DataDirect OEM)][ODBC SQL Server Wire Protocol driver]01006 (CC_OdbcConnection::commit, file CC_OdbcConnection.cpp, line 1,241)

I tried to work with IBM and Data Direct but could not find any solution.

Have anyone faced this issue and aware about the solution.

Regards
Neeraj

"Socket closed" suggests a problem with your network software. Involve your network administrator. Perhaps boost the "keep alive" setting.

Along those lines, it could be a keep alive or connection timeout setting in a firewall. We ran into that before with a different type of database connection.

Was thinking the same thing, especially if you meant "if the job runs for more than 30 minutes before it starts returning data". Now, if data is actively flowing through the job for those 30 minutes then something else is going on.

Hello,

Thanks for the reply.

We have added keepAlive variable in odbc.ini file but still getting the problem and involved the network team, they are not saying any connection break during the process.

What change you performed to mitigate the issue?

Regards
Neeraj

In my situation I did not have to change any settings on Information Server. I had to request the firewall team to change the "extended session timeout" firewall settings. But like Craig said, that usually depends on idleness, so if your job was actively transferring data, then maybe a different setting is needed or it has a different cause. Any chance the database server has a hard limit on connection time?

You still need to clarify exactly what's going on when it fails.